==== Channel ##pypy: 05/25/05 ====

[00:03] mayall (~mayall@212-70-200-6.ath.dialup.tee.gr) joined #pypy.

[00:16] <mayall> Anybody knows the plans for the compiler package?

[00:19] <mayall> later....

[00:22] mayall (~mayall@212-70-200-6.ath.dialup.tee.gr) left irc: "ChatZilla 0.9.52B [Mozilla rv:1.6/20040113]"

----- silence for 26 minutes -----

[00:48] stakkars (fzbdnwrv@i528C1C2E.versanet.de) joined #pypy.

[00:49] <stakkars> hi again

----- silence for 1 hr and 13 minutes -----

[02:02] yuuh (~yuuhu@i528C1C2E.versanet.de) left irc: Read error: 54 (Connection reset by peer)

[02:15] <Rhamphoryncus> hiya stakkars

[02:15] <stakkars> hez!

[02:15] <stakkars> s/z/y

[02:15] <Rhamphoryncus> how goes it? :)

[02:16] <stakkars> fine. I just trashed 3 days of work :-)

[02:16] <stakkars> because I found out that we have it, already.

[02:16] <stakkars> just nobody noticed.

[02:16] <Rhamphoryncus> heh

[02:17] <Rhamphoryncus> been there, done that :)

[02:17] <Rhamphoryncus> But I think it was a little more than three days in my case

[02:17] <stakkars> I discussed the pickling issue for hours with Armin, then we found a concept, the I started coding and thinking.

[02:17] Action: Rhamphoryncus nods

[02:17] <stakkars> (had that, too. By a factor of 200)

[02:18] <stakkars> then I tried to convincepickle to do what I want. Bad stuff, too many assumptions which I cannot

[02:18] <stakkars> override without patching.

[02:19] Action: Rhamphoryncus nods

[02:19] <stakkars> then I looked trough the latest refactoring and saw that we are creating init code for genc

[02:19] <stakkars> which builds all kind of difficult objects, perfectly.

[02:19] <Rhamphoryncus> fun :)

[02:19] <stakkars> very verbose code, but fast enough.

[02:20] <stakkars> It turned out, that by deriving from that and with a little extending, Ican create the whole translator state.

[02:20] <stakkars> this is exactly what we are after :-))

[02:20] suman (~suman1@221.135.200.203) left irc: Read error: 110 (Connection timed out)

[02:20] <Rhamphoryncus> :)

[02:21] <Rhamphoryncus> It's nice to find easy solutions, even if they make you want to swear because you spent all that time on the difficult one ;)

[02:21] <stakkars> yes. It is hard to trash all the work. Then, it is nice to say that you found a much shorter path.

[02:21] <stakkars> what are you doing?

[02:22] <Rhamphoryncus> right now? Tossing a penny in the air :)

[02:22] <stakkars> takes some time until it is rubbed away...

[02:22] <Rhamphoryncus> the penny?

[02:23] <stakkars> yes. just by friction

[02:23] <Rhamphoryncus> yeah I don't think that's gonna happen any time soon ;)

[02:24] <Rhamphoryncus> I've also been playing with the syntax for my concurrency stuff

[02:24] <stakkars> half-way you'll loose it, and go back to work, disappointedly

[02:24] <Rhamphoryncus> heh

[02:24] <stakkars> @syntax

[02:25] <Rhamphoryncus> I'm actually thinking of use a pie/at-symbol for some stuff :)

[02:25] <stakkars> it had always the lowest priority forme,and I tried to get along without it

[02:25] <stakkars> not just decorators?

[02:26] <Rhamphoryncus> no, I don't want to use wait(func) as the syntax for calling func

[02:26] <Rhamphoryncus> I'd rather func@()

[02:27] <stakkars> just a whispered warning: new syntax tends to stop people from adopting a nice idea

[02:27] <Rhamphoryncus> Yeah, I can understand

[02:27] <Rhamphoryncus> I am a bit squeamish over that detail

[02:28] <Rhamphoryncus> It's not required but I think it would result in more reliable, easier to write code

[02:29] <Rhamphoryncus> Much easier to impliment too, since it is the feature that excludes C functions (and thus the C stack)

[02:29] <stakkars> it's a good idea to offer a syntactic shortcut which has a "Normal" equivalence existing

[02:29] <Rhamphoryncus> not sure what you mean

[02:30] <stakkars> with decorators, the introductionary stuff is nice, since you see how they work,

[02:30] <stakkars> and that they don'tdo tjing which you can'tdo without them.

[02:30] <Rhamphoryncus> ahh, well I use @concurrent to mark a function and then wait() and passivewait() to call it

[02:30] <stakkars> A little later, you ecognize that you can do much much more with decorator, and it is rahter impossible without.

[02:31] <stakkars> that strikes back :-)

[02:31] <stakkars> It makes me feel trapped

[02:32] <stakkars> wotis func@() ?

[02:33] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.

[02:34] <Rhamphoryncus> That tells it that func is a concurrent function and it needs to use the concurrent call mechanism

[02:34] <Rhamphoryncus> to put it another way, that means "don't use the C stack for this call" ;)

[02:35] <stakkars> the C stack is of little interest for the user, you know

[02:35] <Rhamphoryncus> right

[02:36] <Rhamphoryncus> For the user it means "this call will let other threads run, so you better be done everything you expect to be atomic"

[02:36] <stakkars> what I mean, it is no point to show what is doable. That has been done in the most cases.

[02:36] <stakkars> The problem is to show things in a way that they get accepted.

[02:36] Action: Rhamphoryncus nods

[02:37] <stakkars> ok, the user should just thing this call *is* atomic?

[02:37] <stakkars> think

[02:37] <Rhamphoryncus> no. Everything *between* these calls is atomic

[02:38] <stakkars> ah. the AT splits atomicness.

[02:38] <Rhamphoryncus> yeah

[02:38] <stakkars> right befor the call

[02:38] <Rhamphoryncus> Sort of like releasing the GIL :)

[02:38] <stakkars> unGIL me quickly, and then continue alone, again. nice

[02:38] <Rhamphoryncus> yup

[02:39] <stakkars> I have the opposite logic in Stackless.

[02:39] <stakkars> There were atomic objects to ensure atomicness.

[02:40] <stakkars> meanwhile gone, but still there is an atomic flag.

[02:40] <Rhamphoryncus> Which I believe gives you the "sweet spot" for granularity. You can have very big operations be atomic if you need to, but you also don't worry much about it never getting released

[02:40] <stakkars> becuase I thought to default enable concurrency.

[02:40] Action: Rhamphoryncus nods

[02:40] <stakkars> maybe you are better off

[02:40] <Rhamphoryncus> Are you familiar with Erlang?

[02:40] <stakkars> just read a little.

[02:41] <Rhamphoryncus> Their "processes" seem the ideal way to do concurrency if you *need* to scale to multiple CPUs

[02:41] <stakkars> I'mnot the best sparrings partner for Erlang.

[02:41] <stakkars> Can you express it in LIMBO?

[02:42] <Rhamphoryncus> LIMBO?

[02:42] <stakkars> yes, from the Plan 9 people.

[02:42] <Rhamphoryncus> hrm. not familiar with it

[02:42] <stakkars> The language for the Inferno system. That's where I'm stealing my ideas from.

[02:43] Action: Rhamphoryncus nods

[02:43] Action: stakkars wonders why he nods. knew that?

[02:43] <Rhamphoryncus> The reason I bring up erlang is that it does preemptive threading FAR better than python does

[02:43] <Rhamphoryncus> no. Just to indicate that I'm listening :)

[02:44] <stakkars> ok. well, preemptive threading better than Python is probably default for every real threading systtem :-)

[02:44] <stakkars> Python is veeery limited here, due to early decisions which I doubt very much.

[02:45] <stakkars> they caused the wholeproblem by themselves.

[02:46] <stakkars> making theoretical every object accessible from everywhere is the cause of artifacts like GIL.

[02:46] <Rhamphoryncus> My point is that if you don't need SMP support then my solution is far easier than the erlang one

[02:46] <Rhamphoryncus> That and threads being expensive ;)

[02:47] <Rhamphoryncus> I think I could come up with an erlang-like approach though, and you should get much better performance from it

[02:47] <stakkars> by default forbid it, when it makes sense,allow it is my idea, too.

[02:47] <stakkars> but it is limited.

[02:47] <Rhamphoryncus> erk, I meant locks are expensive, not threads. (Although threads are expensive too)

[02:48] <stakkars> I was vehemently arguing against real threads for years.

[02:48] <stakkars> yes, correct.

[02:48] <Rhamphoryncus> yeah

[02:48] <stakkars> The *only* point why I meanwhile think that threads are needed is multiple processors.

[02:49] <Rhamphoryncus> Kernel threads are used primarily to call blocking syscalls or to deal with proprietary third-party software that you can't change. Not really a good market

[02:49] <Rhamphoryncus> Aye, but I'd use them in the way erlang uses them

[02:49] <stakkars> (I will not become an Erlang expert tonite)

[02:50] <Rhamphoryncus> Meaning you have 1 kernel thread per CPU, map a hundred or a thousand application "processes" on to them as needed

[02:50] <stakkars> aha, thank you!

[02:50] <Rhamphoryncus> The language gives your "processes" a seperate address space so it's impossible to clobber eachother and switching is cheap

[02:51] <Rhamphoryncus> They use message passing to talk

[02:51] <stakkars> so the optimization/seperation must be per CPU. Make disjoint name spaces and explicit communication.

[02:51] <Rhamphoryncus> yeah

[02:52] <stakkars> use low-cost tiny threads/cooperative scheduling inside the CPUs.

[02:52] <stakkars> that'sPython's major fault.

[02:52] <Rhamphoryncus> Now if you took the "reactor" in my stuff, which is the thing that uses poll/select for I/O, you could use that as the basis for application "processes"

[02:53] <stakkars> I see!

[02:53] <Rhamphoryncus> After that it's fairly easy to have seperate interpreters and have them switch between CPUs as needed

[02:53] <stakkars> one interpreterperCPU, that's it.

[02:53] <Rhamphoryncus> No

[02:53] <Rhamphoryncus> many interpreters, few CPUs

[02:54] <stakkars> why many interpreters?

[02:54] <Rhamphoryncus> An interpreter should be extremely cheap, so you can have many of them and create them as needed

[02:54] <stakkars> I see no benefit for that

[02:54] <Rhamphoryncus> You would however only have one kernel thread per CPU, and thus one active interpreter

[02:55] <Rhamphoryncus> It's a design benefit. If you write a webserver that handles a thousand connections and you want them all in their own address space you'd create a seperate interpreter for each

[02:56] <stakkars> I'm too much tasklet bound. I'd do it that way, one interpreter per CPU, 1,000,000 tasklets per interpreter

[02:56] <Rhamphoryncus> Hum. This would be difficult to mesh well with python. You'd want the messages to be any sort of immutable object, yet there's no easy way to do that without copying the objects every time (which is expensive)

[02:57] <stakkars> they are allindependent enough. Complete seperation by different interpreters is not

[02:57] <stakkars> necessary, and I learned that everything not necessary strikes back as a later extra cost.

[02:57] <Rhamphoryncus> If each connection has it's own interpreter you can migrate them between CPUs

[02:57] <stakkars> would be copying, too.

[02:58] <Rhamphoryncus> No, seperate interpreters wouldn't require copying to switch between

[02:59] <stakkars> you mena interpreters in Python's way?

[02:59] <Rhamphoryncus> yeah

[02:59] <stakkars> than how expensice is a switch bewteen these?

[02:59] <Rhamphoryncus> Currently? You can't :)

[03:00] <stakkars> see. forget about it.

[03:00] <Rhamphoryncus> But in an ideal situation there'd only be a single pointer to refer to the "interpreter context", and that's all you'd have to switch

[03:01] <Rhamphoryncus> oh, another problem is that C extensions would bugger this up. They are are unlikely to do things safely

[03:01] <stakkars> sure.I'm emulating this inside the tasklets.

[03:01] <Rhamphoryncus> But PyPy could fix that :)

[03:01] <stakkars> C extensions are solved.

[03:02] <stakkars> They would increase the cost,but I do detect this.

[03:02] Action: Rhamphoryncus nods

[03:04] <stakkars> well, I have some experience, but it may be bound to existing compiler technology. PyPy might change this:

[03:04] <stakkars> I have two modes of tasklet switching, orbetter three.

[03:05] <stakkars> 1) copy stack slices around

[03:05] <stakkars> 2) avoid touching stack, just swich frames

[03:05] <stakkars> 3) do a real thread switch

[03:05] <Rhamphoryncus> python frames?

[03:05] <stakkars> there are other variants, but these are currently alive.

[03:05] <stakkars> yes

[03:06] <Rhamphoryncus> 2 is the one I plan on using

[03:06] <stakkars> the interesting observation is:

[03:06] <stakkars> 3) is 10 * expensive like 1) is 10 * expensive like 2)

[03:07] <Rhamphoryncus> yeah

[03:07] <stakkars> so when I can do 1 million switches with threads, Ican do 100 million with cooperative tasklets.

[03:07] <stakkars> *and they use 1/10000 of their size.

[03:07] <Rhamphoryncus> 2 is basically like a generator, and creating a generator is the same cost as calling a function

[03:08] <stakkars> makes a time*space improvement of 10**8

[03:08] <Rhamphoryncus> yeah

[03:08] <stakkars> yes.mine is two times generator.

[03:08] <Rhamphoryncus> It seems stupid to use kernel threads in comparison

[03:08] <stakkars> they are much beter than userthreads

[03:16] <Rhamphoryncus> Hrm. I really should decide if my design is "done" and write up a PEP :)

[03:19] <stakkars> there are more fun things than writing PEPs about things Guido regards as "just for I/O stuff"

[03:20] <Rhamphoryncus> heh

[03:20] <Rhamphoryncus> yeah, the fear of getting shot down has been discouraging me :(

[03:20] <stakkars> bin there, seen this, was burnt

[03:20] <stakkars> been

[03:20] Action: Rhamphoryncus nods

[03:21] <Rhamphoryncus> But some of us respect what you've done ;)

[03:21] <stakkars> and the big head won'tmove,even after he was taught you were right

[03:21] <stakkars> (not taling about stackless anymore)

[03:21] <Rhamphoryncus> oh :)

[03:22] <stakkars> I mean it was the cause for my reactions, but meanwhile this is into a "careful with convincing people"

[03:23] <Rhamphoryncus> yeah

[03:23] <Rhamphoryncus> I've had a very hard time explaining my concurrency stuff to people

[03:23] <Rhamphoryncus> I posted on comp.lang.python a couple months ago and barely got a response

[03:25] <Rhamphoryncus> And what little response I do get is usually "I don't understand" or "why bother.."

[03:25] <stakkars> yeah. comp.lang.python is now as dumb as comp.lang.perl was 10 years ago.

[03:26] Action: Rhamphoryncus nods

[03:26] <stakkars> and python-dev won't react ,either, but for different reasons, which put me up even more.

[03:26] <Rhamphoryncus> hmm. Actually, what I need most right now is simple example apps to write using my stuff. Everything I think of is too big (like an entire http lib)

[03:27] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"

[03:27] <stakkars> why is http too much?

[03:27] <Rhamphoryncus> I suspect the real trick is explaining it just right, so that the understand it

[03:27] <stakkars> take asyncore,make it half as long and get rid of its FIFO nature, that's its bottleneck.

[03:27] <Rhamphoryncus> Have you read the RFC? :)

[03:28] <stakkars> Did it with Stackless,but never published, because it was paid work.

[03:28] <Rhamphoryncus> I'd need to rewrite it to be sequential

[03:28] <Rhamphoryncus> I'd also need to rewrite the rfc822 module to be sequential

[03:28] <Rhamphoryncus> huh

[03:28] <stakkars> lost my brain somewhere... what was 822?

[03:29] <sanxiyn> Email headers.

[03:29] <Rhamphoryncus> email message format

[03:29] <stakkars> ah

[03:29] <Rhamphoryncus> which is also used by http

[03:29] <stakkars> sure (here it is -- how did it get into the fridge?)

[03:29] <Rhamphoryncus> heh

[03:30] <stakkars> what's the point about sequentiality?

[03:30] <Rhamphoryncus> That's the big benefit of my design, you can write code sequentially using normal loop operations. You don't need to use callbacks for every I/O event

[03:31] <stakkars> that's wha I love. Make things as simple as possible. No simpler.

[03:31] <stakkars> if things can be sequential, fine.

[03:31] <stakkars> If they need to branch, well. You can split.

[03:31] <Rhamphoryncus> yup

[03:32] <stakkars> basically what flowgraphs do. But for different reasons.

[03:34] <Rhamphoryncus> I wonder, how feature-complete is httplib in python?

[03:36] <stakkars> notsovery. A usable compromise.

[03:36] Action: Rhamphoryncus nods

[03:37] <stakkars> I'd just use asyncore, because it was the heart of Medusa, which was the heart of Zope.

[03:37] <stakkars> before the Zopistas went out and made it threaded :-(

[03:37] <Rhamphoryncus> I didn't think asyncore supported http?

[03:38] <sanxiyn> Then why not start from Medusa?

[03:38] <stakkars> that's not the point, the kernel thing isthe point. Everything else is an add-on.

[03:38] <stakkars> asyncore is the "threading" kernel.

[03:39] <stakkars> you rewrite itwith your approach.

[03:39] <Rhamphoryncus> I already have I/O support

[03:39] <stakkars> by that, you remove the "asyncore is I/O bound optimized, not computation bound" issue.

[03:40] <stakkars> The point for ZHope to add threading is its computation boundness.

[03:40] <stakkars> this asyncore cannot handle. It assumes that computation is cheap and comes round-robin.

[03:40] Action: Rhamphoryncus nods

[03:41] <stakkars> I solved that with Stackless andcould have made a much fatserZope kernel, if I had ahd time.

[03:41] <stakkars> you can do that of course.

[03:41] <stakkars> and sell the magic "Zope site accelerator" (tm)

[03:42] <Rhamphoryncus> heh

[03:43] <stakkars> I already was in a project and would have done if PyPy didn'tcatch up :-]

[03:43] <Rhamphoryncus> :)

[03:43] <Rhamphoryncus> Well I'm not gonna complain about PyPy taking priority ;)

[03:44] <stakkars> it is a huge challenge and a high risk,but incredible fun

----- silence for 2 hr and 25 minutes -----

[06:09] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 110 (Connection timed out)

----- silence for 18 minutes -----

[06:27] stakkars (fzbdnwrv@i528C1C2E.versanet.de) left irc: Read error: 113 (No route to host)

[06:30] Rhamphoryncus (~rhamph@rhamphoryncus.user) left irc: ""What do you mean, how many hit points do I have?" || Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html";

----- silence for 20 minutes -----

[06:50] dialtone (~dialtone@host27-8.pool80116.interbusiness.it) joined #pypy.

----- silence for 31 minutes -----

[07:21] sanxiyn (~tinuviel@211.104.100.115) left irc: "Bye"

----- silence for 41 minutes -----

[08:02] tic (~vision@c-a86e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.

[08:17] adim (~adim@logilab.net2.nerim.net) joined #pypy.

----- silence for 49 minutes -----

[09:06] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.

[09:13] thingie24 (~rmt38@valhalla.ccp.cc) joined #pypy.

[09:15] lac (~jacob@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) got netsplit.

[09:15] tic (~vision@c-a86e73d5.019-35-67626717.cust.bredbandsbolaget.se) got netsplit.

[09:15] idnar (mithrandi@idnar.user) got netsplit.

[09:15] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.

[09:15] dialtone (~dialtone@host27-8.pool80116.interbusiness.it) got netsplit.

[09:15] thingie25 (~rmt38@valhalla.ccp.cc) got netsplit.

[09:15] tic (~vision@c-a86e73d5.019-35-67626717.cust.bredbandsbolaget.se) returned to #pypy.

[09:15] dialtone (~dialtone@host27-8.pool80116.interbusiness.it) returned to #pypy.

[09:15] lac (~jacob@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) returned to #pypy.

[09:15] idnar (mithrandi@idnar.user) returned to #pypy.

[09:15] thingie25 (~rmt38@valhalla.ccp.cc) returned to #pypy.

[09:15] mwh (~user@pc150.maths.bris.ac.uk) returned to #pypy.

[09:19] thingie25 (~rmt38@valhalla.ccp.cc) left irc: Operation timed out

[09:25] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.

----- silence for 21 minutes -----

[09:46] <ericvrp> cfbolz: Carl, good morning

[09:56] <ericvrp> hi have a minute?

----- silence for 1 hr and 31 minutes -----

[11:27] cfbolz_ (~cfbolz@hdlb-d9b94691.pool.mediaWays.net) joined #pypy.

[11:27] cfbolz_ (~cfbolz@hdlb-d9b94691.pool.mediaWays.net) left irc: Client Quit

----- silence for 20 minutes -----

[11:47] jacob22 (jacob@enzo.strakt.com) left irc: Remote closed the connection

----- silence for 59 minutes -----

[12:46] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection

[12:49] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

----- silence for 31 minutes -----

[13:20] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.

[13:31] yuuh (~yuuhu@i528C1C2E.versanet.de) joined #pypy.

[13:44] yuuh (~yuuhu@i528C1C2E.versanet.de) left irc: Read error: 60 (Operation timed out)

[13:50] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) left irc: "Leaving"

[13:50] cfbolz (~cfbolz@edv01.physi.uni-heidelberg.de) joined #pypy.

[13:50] <cfbolz> hi all!

[13:51] <mwh> when's this translator explaining happening?

[13:51] <arigo> mwh: in one hour

[13:52] <mwh> ah, ok

[13:52] <mwh> i may miss the beginning

[13:53] <cfbolz> ericvrp: you there?

[13:57] <ericvrp> cfbolz: am now, was out for lunch

[13:57] <ericvrp> seen my two commits?

[13:58] <ericvrp> back in 15 minutes...

[13:58] <cfbolz> yes. They are fine

[14:05] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.

[14:12] thingie25 (~rmt38@valhalla.ccp.cc) joined #pypy.

[14:13] thingie24 (~rmt38@valhalla.ccp.cc) left irc: Read error: 104 (Connection reset by peer)

[14:17] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.

----- silence for 26 minutes -----

[14:43] loyalist (~doug@qlink-ppp144.tele.QueensU.CA) joined #pypy.

[14:53] loyalist (doug@qlink-ppp144.tele.QueensU.CA) left #pypy.

[14:55] loyalist (~doug@qlink-ppp124.tele.QueensU.CA) joined #pypy.

[14:56] hpk (~hpk@merlinux.de) joined #pypy.

[14:56] <hpk> good morning, so to say

[14:56] <cfbolz> huh?

[14:57] <hpk> nothing special, i just have been relaxing today a bit and so it still feels more or less like morning

[14:57] <cfbolz> :-)

[14:57] <hpk> cfbolz: how was your exam?

[14:57] <ericvrp> here

[14:57] <cfbolz> very good: 1.3

[14:58] <hpk> cool, congrats

[14:58] <hpk> so the professor didn't detect the weak points, i guess :-)

[14:58] <cfbolz> thanks. She actually did

[14:58] <cfbolz> but somehow she found it still good :-)

[14:59] <hpk> yeah, actually my professor told me that especially when confronted with a weak spot it becomes interesting how you deal with it

[15:00] <hpk> (unless it's some fundamental thing that you really should now, of course :-)

[15:00] <hpk> arigo: did you prepare some points for the meeting by chance?

[15:00] <mwh> woo, i made it back

[15:00] <cfbolz> hpk: no, it was not _so_ fundamental

[15:01] stakkars (hpxhaomw@dsl-62-220-11-192.berlikomm.net) joined #pypy.

[15:02] <arigo> hi (oups, bad timing, back in a couple of minutes...)

[15:02] <pedronis> hi all

[15:02] <hpk> hi samuele

[15:02] <hpk> mwh: hi michael, btw, long time not really "seen" ...

[15:03] <mwh> yeah, i know

[15:03] <stakkars> hi all

[15:04] <aleale> hi

[15:04] <hpk> mwh: was meant as a cheerful comment (you cannot really note this over IRC)

[15:05] <mwh> ok :)

[15:05] <mwh> but i've been slack about some things too

[15:06] <arigo> the meeting points should depend on point 1, which is: looking for the common background here

[15:07] <hpk> i think we should start talking about the rtyper

[15:07] <mwh> well, for me: i haven't really followed much since the .ch sprint

[15:08] <hpk> arigo: maybe you can give some context about the rtyper like some basic statements and we start asking questions?

[15:08] <stakkars> I'd like to know what the reason was for the typer to become an rtyper

[15:08] <cfbolz> arigo: I read the rtyper docs and thought a bit about the concept

[15:08] <hpk> ericvrp: clisp is ready, llvm in the making on codespeak

[15:09] <hpk> ericvrp: thanks for giving a heads up!

[15:09] <ericvrp> hpk: thank you!

[15:09] <arigo> ok, first the context, for this meeting we should assume that what we are working with is a fully annotated flow graph

[15:09] <arigo> something like you see in the pygame viewer, after t.annotate().

[15:10] <arigo> so this is what the typer sees

[15:11] <stakkars> typer always == rtyper?

[15:11] <arigo> yes

[15:11] <arigo> the RPython Typer == rtyper for short (to avoid confusion with the old translator/typer.py)

[15:11] <arigo> the typer's goal is to produce operations between so-called "low-level types"

[15:12] <arigo> if you haven't done so, please follow the "quick tour" in the section http://codespeak.net/pypy/index.cgi?doc/translation.html#low-level-types

[15:12] <arigo> to see what kind of things the low-level types are

[15:12] <stakkars> this is what you ripped out of the backends, becuase it is independent from the target.

[15:12] <cfbolz> for some targets at least

[15:12] <pedronis> yes

[15:13] <pedronis> we may need some slight variation for some targets

[15:13] <arigo> yes

[15:13] <pedronis> but it does not make sense to work on that

[15:13] <pedronis> until we have the concept implemented for at least one target

[15:13] <cfbolz> right. And it should work reasonably well for at least C and LLVM

[15:13] <pedronis> in a way that seems working

[15:14] <stakkars> so the main idea is to pull this complication awayfrom the backend, rewrite the graph with new types and let the backend not worry about that.

[15:14] <arigo> stakkars: exactly

[15:14] <pedronis> yes, the backend should deal with the low-level aspects of gc and exceptions

[15:14] <stakkars> I just wondered why this goes so far, reaching pointer types, which is not that general for backends?

[15:14] <pedronis> those are the "hard" tasks left to the backends

[15:15] <arigo> the motivation is C:

[15:15] <cfbolz> pedronis: well, at least reference counting could be "lowered" to low level operations, too

[15:15] <pedronis> cfbolz: no

[15:15] <pedronis> it interacts with exception handling for example

[15:15] <arigo> stakkars: in C you want to distinguish between structures that contain substructures, or pointers to independently-allocated structures

[15:16] <stakkars> and I think the optimization of what needs ref and what can be borrowed is not for the backend?

[15:16] <arigo> yes, the typer produces NonGcPtr and GcPtr to Struct and GcStruct

[15:16] <stakkars> arigo: yes. I tend to forget about that when doing too much of Python.

[15:16] <arigo> "Gc" == "with a ref counter"

[15:17] <pedronis> or more in general with gc info header attached

[15:17] <hpk> arigo: not as general as "Gc" == "with a tracking mechanism" ?

[15:17] <arigo> hpk: yes, sorry

[15:18] <stakkars> but at somepoint I assume that the GC algorithm will be rendered, too, and again by a higher level thing like rtyper?

[15:18] <arigo> stakkars: that's a possibility, yes

[15:18] <arigo> for now, for C we kind of assume ref-counting

[15:18] <pedronis> stakkars: could be

[15:19] <pedronis> but mixing that in with what the rtypes does now

[15:19] <hpk> arigo: Are PyObject's a special case for Gc objects then?

[15:19] <arigo> hpk: "PyObject" for the low-level types is a container,

[15:19] <stakkars> ok, that's goodto know. When reading code, it is always not clear if something is meant as the final concept, or just a starting point

[15:19] <pedronis> stakars: would be likely too much

[15:19] <arigo> hpk: which means that you can take a GcPtr or a NonGcPtr to them

[15:20] <arigo> hpk: so the low-level types are GcPtr(PyObject) and NonGcPtr(PyObject) depending on if we want the C backend to produce incref/decref or not

[15:20] <arigo> hpk: PyObject's are a special case for Gc, yes, in the sense that we have to use CPython's refcounts for them, instead of choosing our own model

[15:21] <arigo> let's have a look at pypy/rpython/rlist.py (the current version! it changed yesterday evening)

[15:21] <stakkars> besides refcounting, do we have a distinction of the objects themselves, whether they are meant to

[15:22] <stakkars> be embedded into a structure or the stack, or if they are floating around?

[15:22] <arigo> stakkars: yes, GcStruct is on the heap, Struct is meant to be embedded

[15:22] <stakkars> and we can have both representations for the same object type?

[15:22] <arigo> with some exceptions to this rule (described in the documentation)

[15:22] <arigo> stakkars: not really

[15:22] <hpk> arigo: screen -x ? (make sure you have ericvrp and cfbolz in your .screenrc list then, btw)

[15:23] <arigo> ok

[15:23] <arigo> screen -x arigo/arigo

[15:23] <stakkars> I'd prefer IRC for the logs

[15:23] <hpk> arigo: we/you should explain '__extend__' in the coding-guide at some point :-)

[15:23] <arigo> stakkars: it's to point around in the file, not to type comments

[15:24] <hpk> stakkars: let's not talk on the screen session, just have it in parallel and talk here

[15:24] <stakkars> good.

[15:24] <arigo> hpk: __extend__: yes :-)

[15:24] <hpk> ericvrp: on codespeak enter 'screen -x arigo/arigo'

[15:25] <hpk> arigo: let's start

[15:26] <arre> arigo: I think you'll have to give me access to your screen

[15:26] <arigo> oups sorry

[15:26] <arigo> do we need to restart?

[15:26] <mwh> where has translate_pypy gone?

[15:26] <hpk> arigo: you have to restart screen

[15:26] <arigo> ok

[15:26] <hpk> mwh: pypy/translator/goal

[15:26] <arigo> restarted...

[15:27] <mwh> hpk: gah

[15:27] <arre> arigo: Eh, my account on codepseak is 'ac' while my nick is 'arre' just to confuse people.

[15:27] <arigo> uh.

[15:27] <stakkars> well, the __extend__ just adds something new to the type

[15:27] <mwh> i forgot how to drive find(1)

[15:27] <pedronis> mwh: :)

[15:27] <arigo> restarted :-)

[15:28] Action: hpk wistles something about shpies

[15:28] <arre> arigo: Works fine for me now!

[15:28] <stakkars> why do we start using ALL CAPS identifiers now?

[15:28] <arigo> so we stick a method lowleveltype() on each SomeXxx annotation, here SomeList

[15:28] Action: arigo points at pedronis

[15:29] <arigo> ALL CAPS are types, like POINT=GcStruct(....) in the quick tour in the doc...

[15:29] <stakkars> this looks very macro-ish to me

[15:29] <pedronis> pedronis is indeed guilty for this

[15:29] <arigo> "low-level types"

[15:29] paulb (~chatzilla@c5100913D.inet.catch.no) joined #pypy.

[15:30] <arigo> ITEM is the lowleveltype() of what the annotation things are the list items

[15:30] <arigo> LIST is a C struct that contains only a pointer to an array

[15:30] <arigo> the indirection is needed because the RPython list can be resized, and the array cannot (like in C)

[15:31] <arigo> lots of parenthesis around

[15:31] <pedronis> (java arrays also cannot be resized)

[15:31] <mwh> i take it an array knows it's length, then?

[15:31] <cfbolz> (LLVM is mostly like C anyway)

[15:31] <arigo> "list" is the name of the Struct; "items" is the name of the single field in it

[15:31] <arigo> mwh: yes

[15:32] <mwh> its, but ok :)

[15:32] <pedronis> mwh: yes

[15:32] <arigo> and arrays are always of substructures

[15:32] <arigo> in this case the substructure has a single field "item"

[15:32] <arigo> so it's really an array of ITEMs

[15:32] <stakkars> arigo: even if it simplycontains integers, they are in a struct, right?

[15:32] <arigo> but more precisely an array of struct { item: ITEM }

[15:32] <arigo> stakkars: yes

[15:33] <arigo> for simplicity of the model, basically

[15:33] <stakkars> comes for no cost, so it's fine

[15:33] <pedronis> basically to avoid the notion of pointer to primitive types

[15:33] <stakkars> always having boxes instead of confusion, I know

[15:34] <arigo> the rest looks like the annotator, with __extend__ on a pairtype

[15:34] <hpk> arigo: could you quickly show the "caller" side of this code?

[15:34] yuuh (~yuuhu@dsl-62-220-11-192.berlikomm.net) joined #pypy.

[15:34] <arigo> hpk: more obscure :-/

[15:34] <arigo> RPythonTyper.specialize()

[15:34] <arigo> specialize all blocks one by one

[15:35] <arigo> for each op in the bloc

[15:35] <arigo> k

[15:35] <arigo> "consider" it

[15:35] <arigo> which means produce equivalent low-level operations

[15:35] <stakkars> that's one of my problems: consider what?

[15:35] <arigo> consider the original operation

[15:35] <mwh> is this mutating the flow graph?

[15:35] <arigo> yes

[15:36] <arigo> it's actually producing a new list of operations

[15:36] <stakkars> consider is to consider an action. consider to do what?

[15:36] <pedronis> hpk: at first is easier to think that is just there to do the right thing(tm) with the code in rlist.py

[15:36] <arigo> which is stick into block.operations at the end.

[15:36] <cfbolz> arigo: how much can the flow graph mutated? just new ops?

[15:36] <mwh> arigo: eh?

[15:36] <hpk> arigo: consider() an inplace operation, right?

[15:36] <mwh> "yes it's mutated, but it's producing a new list"?

[15:36] <arigo> mwh: sorry:

[15:36] <mwh> ^mutating

[15:36] <arigo> mwh: consider_() itself doesn't mutate, but produce a new list

[15:37] <stakkars> I think consider is an awfully misleading name :-)

[15:37] <arigo> but at the end of a block, we mutate the block

[15:37] <mwh> ahh

[15:37] <arigo> stakkars: yes, it comes straight from annrpython.py

[15:37] <pedronis> stakkars: but we use it consistently :)

[15:37] <mwh> my how we could do with CL's dynamic variables

[15:38] <arigo> there is this code like in annrpython.py

[15:38] <pedronis> mwh: indeed

[15:38] <stakkars> no long name needed, just someting that does look like something with a side effect.

[15:38] <arigo> which calls the rtype_xxx() method on the proper SomeXxx class or pair of classes

[15:38] <stakkars> ok, good to know

[15:38] <stakkars> actually consider is a hammer :-)

[15:39] <arigo> so each rtype_xxx method in rlist.py should produce new operations

[15:39] <arigo> using global helpers here:

[15:39] <arigo> e.g. direct_op() means "produce an operation"

[15:39] <arigo> which gets stored into the 'newops' list

[15:39] <stakkars> argh, and that's hidden in TLS

[15:39] <arigo> it's more convenient to have a global TLS variable than pass it around everywhere

[15:40] <cfbolz> TLS means?

[15:40] <stakkars> thread local storage

[15:40] <arigo> it's like the annotator doing getbookkeeper() out of thin air

[15:40] <mwh> threadlocalstorage

[15:40] <cfbolz> ok (nice TLA)

[15:40] <stakkars> actually it is like "print a new statement"

[15:40] <arigo> exactly

[15:41] <arigo> for example rtype_len()

[15:41] <arigo> called on the SomeList annotation

[15:41] <arigo> does a magic "receive()" call, which means

[15:41] <arigo> "I want to get the variable op.args[0] of the current operation,

[15:41] <arigo> but converted if needed to the low-level type corresponding to s_lst"

[15:42] <cfbolz> how's the conversion done?

[15:42] <arigo> remember that s_lst is a SomeList, i.e. an annotation, and we need the real Variable of the operation in order to write a new operation working on the same variable

[15:42] <stakkars> has receive a side effect of printing ops, too?

[15:42] <arigo> stakkars: yes

[15:42] <arigo> cfbolz: but usually, no conversion is needed

[15:42] <pedronis> yes

[15:42] <stakkars> explicit is better than implicit comestomind ;-)

[15:43] <arigo> rtype_newlist is maybe easier to follow

[15:43] <arigo> it's for the operation v5 = newlist(v1,v2,v3...)

[15:43] <arigo> it's a special case because the SomeList is the result variable, not an argument

[15:44] <pedronis> (conversions can be implemented/registered like other rtype_* operations)

[15:44] <arigo> so we use peek_at_result_annotation()

[15:44] <arigo> s_listitem is the annotation the list expects for its items

[15:45] <arigo> we call "receive(s_listitem, arg=i)" to get the ith arg in a format that matches s_listitem

[15:45] <arigo> think about a list of integers: s_listitem == Signed

[15:45] <stakkars> it is confusing tome that we seem to peek into strucutres we are just rewriting

[15:46] <stakkars> or is it like a copy?

[15:46] <arigo> stakkars: yes, peek_at_etc() is a special case, meaning "here I trust the annotator's thought"

[15:46] <arigo> s_list is the annotation, not really the result variable

[15:46] <arigo> alternatively, we should look at all the items_s annotations,

[15:47] <arigo> and make the union of them

[15:47] <arigo> er, no, doesn't work

[15:47] <arigo> because the annotator might have decided later that the list should be more general

[15:47] <pedronis> yes

[15:47] <arigo> so peek_at_result_annotation() is just a way to trust the annotator.

[15:47] <pedronis> a setitem further in the code could have made the list items more general

[15:47] <stakkars> we can only do things that don't break the annotator's assumptions I guess.

[15:48] <hpk> arigo: peek_at_result_annotation() is again working on state via TLS?

[15:48] <arigo> stakkars: exactly

[15:48] <arigo> hpk: sure

[15:48] <arigo> the TLS contains "the current operation" and the "newops" list

[15:48] <arigo> receive() also works on "the current operation".

[15:48] <pedronis> yes, TLS also stores the current operation we are substituting

[15:48] <stakkars> ah, and only one!

[15:49] <arigo> yes, we "consider" a single operation at a time, and replace it with any number of low-level operations.

[15:49] <hpk> arigo: side note: some way to make this more explicit (still using TLS) would make this more readable, i guess

[15:49] <arigo> hpk: a better name, I guess

[15:49] <stakkars> I'd rather prefer to pass an object around, and give it nice properties which are explitly saying what happens

[15:50] <arigo> stakkars: yes, we can discuss this details, there are unpractical issues like we can't use the first argument for that

[15:50] <hpk> arigo: i thought more like 'currentop().get_result_annotation()' actually

[15:50] <arigo> stakkars: because it's used for dispatching in the __extend__ code

[15:50] <arigo> hpk: could be, but it's confusing too because currentop() couldn't just return a SpaceOperation

[15:51] <arigo> anyway we get the idea so far, let's continue

[15:51] <hpk> yes

[15:51] <arigo> direct_call() is the common way to produce a new operation:

[15:51] <stakkars> ok, without an explicit arg, we could use a call that wraps the currentop into something nice.

[15:51] <arigo> it produces a 'direct_call' low-level operation,

[15:51] <arigo> which calls a function like ll_newlist written in a special way

[15:51] <stakkars> I thought direct_call is calling something?

[15:52] <arigo> precisely :-)

[15:52] <arigo> ah, no

[15:52] Action: arigo points at pedronis again

[15:52] <pedronis> it's emitting a call

[15:52] <arigo> should be called produce_direct_call_op or something

[15:52] Action: pedronis points back to arigo this time

[15:52] <arigo> oups?

[15:52] <stakkars> nono, that's fine. like in the flowgraphs. I just wantto be sure that it exactly matches.

[15:53] Action: arigo points at arigo

[15:53] <pedronis> I think you introduced direct_call

[15:53] <pedronis> I then suggested the more primitive direct_op

[15:53] <arigo> :-)

[15:53] <hpk> let's just note that more careful naming would help understanding the code here (which really brings quite a bit of concepts together)

[15:53] <stakkars> what is meant by direct?

[15:54] <arigo> er, it's by opposition to simple_call, which calls a PyObject* callable

[15:54] <pedronis> we could call it lowlevel_call

[15:54] <arigo> good point

[15:54] <stakkars> direct means for me"don'tgo throught something" but do it here

[15:54] <pedronis> one thing is that some of those are good candidates

[15:54] <pedronis> for possibly inlining at graph level

[15:54] <stakkars> for macro expansion

[15:55] <arigo> let's look at ll_newlist

[15:55] <arigo> the first argument is the type "pointer to struct 'list'" that we have seen above,

[15:56] <arigo> LISTPTR.TO is the type that LISTPTR points to, i.e. the struct 'list'

[15:56] <arigo> note that each list of items of a different type gets a different version 'struct list'

[15:56] <stakkars> aah, the CAPS looks like Fortran/Assembly. hurts my eyes

[15:56] <arigo> so we have to pass in what's the type that we want to make a new list of

[15:57] <arigo> I mean the type of the list we expect (not the type of its items)

[15:57] <pedronis> stakkars: I see, but we have too many 'type' and types around

[15:57] <arigo> ooups, sorry

[15:58] <hpk> arigo: sorry, that was me (plus you)

[15:58] <arigo> I see

[15:58] <arigo> everybody's back?

[15:58] <mwh> yes

[15:58] <hpk> yes

[15:58] <pedronis> yup

[15:58] <arre> Yepp.

[15:59] <cfbolz> me too

[15:59] <stakkars> pedronis: I agree. Please let's discuss this at some point, coding style is an issue.

[15:59] <arigo> we can run these ll_* functions for debugging/testing

[15:59] <stakkars> ok

[15:59] <arigo> hum, it's a bit indirect

[16:00] <arigo> so assuming we have a SomeList of SomeIntegers

[16:00] <arigo> lowleveltype() ->

[16:00] <arigo> ptr to struct 'list'

[16:01] <arigo> field 'items': ptr to array of { item:Signed }

[16:01] <stakkars> this computes it all the time?

[16:01] <arigo> at the moment, yes (let's worry about performance later :-)

[16:01] <arigo> == works as expected

[16:01] <stakkars> ah, I guess it is not that intense

[16:02] <arigo> pointers are automatically dereferenced

[16:02] <arigo> we can't actually obtain an instance of a structure

[16:02] <arigo> only pointers to it

[16:02] <hpk> arigo: can youz try import rlcompelter2 and rlcompleter2.setup() and show some attrs around?

[16:02] <pedronis> (pedronis notices that the repr for pointers was nicer at some point)

[16:02] <mwh> so, like python?

[16:03] <arigo> hpk: there are lots of _ attributes, but I can

[16:03] <arigo> mwh: yes, but the difference is still there

[16:03] <arigo> mwh: at the level of types, we need to dereference explicitely

[16:04] <arigo> a bit obscure

[16:04] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.

[16:04] <hpk> arigo: nevermind, just go on

[16:05] alsh (~chatzilla@101.rcu200.teletoria.ru) joined #pypy.

[16:06] <mwh> -ENOGRAMMAR

[16:06] <arigo> arrays are objects like structures

[16:06] <arigo> this array is a GcArray, which has been malloc'ed

[16:06] <arigo> it has a size field

[16:06] <arigo> and, here, 5 substructures after the size field

[16:07] <arigo> as with struct, we can't see an array directly, but only a ptr to an array

[16:07] <pedronis> yes, when you access an inlined substructure you get a pointer: ptr.items[0]

[16:08] <arigo> an array is a kind of struct with one size field and some number of fields afterwards.

[16:08] <stakkars> why is this all expressed in an imperative style? I'm thinking of pattern replacement

[16:08] <pedronis> (items is not an example because it is declared as pointer anyway in the structure)

[16:08] <pedronis> stakkars: we tried that

[16:08] <pedronis> there are enough special cases that it got obscure very fast

[16:10] loyalist (~doug@qlink-ppp124.tele.QueensU.CA) left irc: "Download Gaim: http://gaim.sourceforge.net/";

[16:10] <arigo> it's very low-level-ish, but does the job, basically

[16:10] <cfbolz> arigo: could you save this Python session when we're done?

[16:10] <arigo> cfbolz: I guess so

[16:11] <hpk> arigo: should have done a 'script' session in screen :-)

[16:11] <arigo> anyone knowing how to capture the screen copyback buffer?

[16:12] <mwh> i would be interested in knowing :)

[16:12] Action: hpk is looking

[16:12] <arigo> there is a "copy mode"

[16:13] Action: stakkars consideres to re-animate his interactive session saver

[16:13] <pedronis> there's a log mode but should have been activated

[16:14] <cfbolz> well, not that important

[16:14] <stakkars> what I have no clueabout yes is, how do I actually implement something and interface it to the machinery?

[16:15] <stakkars> clue about, yet

[16:15] <arigo> let's see

[16:16] <arigo> ll_newlist should look familiar now

[16:16] <arigo> mallocates the base 'struct list'

[16:16] <arigo> mallocates the items array

[16:16] <arigo> stick it in l.items

[16:16] <hpk> arigo: hit C-a C-[ move to start pos, hit <space>, move to end pos, hit <space>, hit <C-A> <C-'>'> and /tmp/screen-exchange* contains your marked stuff

[16:17] <arigo> hpk: thanks

[16:17] <arigo> (for nowI did the copy-pasting page by page from the terminal)

[16:17] <cfbolz> hpk: hey, that's very intuitive

[16:18] <arigo> the interface is this direct_call(), which does a lot of things under the hood

[16:18] <arigo> the two input arguments are two constants 'c1' and the one based on nb_args

[16:18] <arigo> receiveconst() is used to build a Constant with an explicit low-level type

[16:19] <arigo> for nb_args it's Signed; for the LISTPTR argument it's Void,

[16:19] <arigo> because we actually want this LISTPTR to be a constant in the produced C code

[16:19] <arigo> expressions like LISTPTR.TO are meant to be considered as constant

[16:20] <arigo> there is no such thing as types manipulation in C

[16:20] <stakkars> by writing these things out, you ar actually producing the new operations, right?

[16:20] <arigo> yes

[16:20] <arigo> direct_call() will make a copy of the ll_newitem function based on the value of the Void constant (it's specialization again)

[16:20] <stakkars> so it is a script that creates operations.I see.

[16:21] <arigo> then it uses the flow space and the annotator to look into ll_newitem

[16:21] <arigo> then it generates call to that specialized, annotated copy of ll_newitem

[16:22] Rhamphoryncus (~rhamph@rhamphoryncus.user) joined #pypy.

[16:22] <arigo> and v_result is a Variable whose low-level type is the one the returned by ll_newlist, as found out by the annotator

[16:22] <pedronis> (the annotator has been extended a bit to be able to deal with low-level types and ops on them)

[16:22] <arigo> "eat your own dog food" (hi lac!)

[16:23] <hpk> so annotation/type inference is deemed to work on lowlevel types as well?

[16:23] <arigo> yes

[16:23] <pedronis> yes it mostly about propagating results

[16:23] <hpk> ah, i had hoped that it could be simpler (just a one-way transformation)

[16:24] <stakkars> confused. are you annotating again?

[16:24] <pedronis> because the type themself are very explicit

[16:24] <arigo> hpk: we thought about it, but then it turned out that just running the annotator is easy...

[16:24] <arigo> stakkars: we run the annotator again on the copy of the ll_newlist function, yes

[16:24] <hpk> and the inferencing rules is mixed with the highlevel ones?

[16:25] <pedronis> yes

[16:25] <pedronis> they are orthogonal enough

[16:25] <stakkars> again, *why* is another inference necessary?

[16:25] <arigo> hpk: they are nicely separated actually, because they all use SomePtr only

[16:25] <arigo> stakkars: to make sense out of ll_newlist

[16:25] <arigo> which is originally a Python function

[16:25] <pedronis> stakkars: only on the low-level helpers

[16:26] <pedronis> we are not annotating everything again

[16:26] <stakkars> I mean, you annotate the whole set of graphs again, or just a part? and where does it happen?

[16:26] <arigo> only ll_newlist

[16:26] <cfbolz> what's allowed in those low level helpers?

[16:26] <pedronis> ... and similar helpers

[16:27] <stakkars> where does this happen, in the source?

[16:27] <pedronis> cfbolz: only low-level types

[16:27] <arigo> cfbolz: and the operations on them, like malloc()

[16:27] <cfbolz> function calls?

[16:27] <arigo> cfbolz: integers and characters are low-level types too.

[16:28] <pedronis> integers are low-level types too

[16:28] <arigo> cfbolz: calling other similarly simple helpers should be ok yes

[16:28] <cfbolz> yes, that was my question

[16:28] <pedronis> OTOH mixing rpython lists in that code would likely provoke funny explosions

[16:29] <pedronis> especially in the rtyper

[16:29] <arigo> ll_append is a slightly larger example

[16:29] <pedronis> which is also applied on that code

[16:30] <arigo> l.items is a pointer to an array; besides __getitem__ it has a __len__

[16:30] <arigo> some funny type expressions to get at the type of the array items we want to allocate...

[16:30] <mwh> Exception: <built-in function backslashreplace_errors> not found in any built-in module

[16:30] <mwh> heh

[16:31] <arigo> no range(), clearly: that would be using a list

[16:31] <arigo> it's really not a style we want to write a lot of code in

[16:31] <pedronis> indeed, but is also really not meant to

[16:32] <hpk> so each backend needs to implement ll_append on its own or am i missing something?

[16:32] <pedronis> hpk: it depends

[16:32] <arigo> pedronis: ?

[16:33] <arigo> the purpose is not to have to implement ll_append anywhere else than here

[16:33] <stakkars> I thought that *is* the implementation?

[16:33] <pedronis> yes

[16:33] <arigo> pedronis: let's talk about Java later :-)

[16:33] <pedronis> I was interpreting needing a slighlty different implementation

[16:33] <hpk> ah, ok, i see

[16:33] <pedronis> ll_append should be ok for any sufficiently c-ish

[16:33] <arigo> this ll_append *is* the implementation, yes

[16:33] <pedronis> backend

[16:34] <arigo> the typer will make a direct_call operation to another flow graph,

[16:34] <stakkars> so I'm wondering what I'm going to produce: more of these? Becuase there is no C left at all :-)

[16:34] <arigo> which happens to be the flow graph of ll_append

[16:34] <pedronis> stakkars: yes

[16:34] <cfbolz> it's funny how similar this is to the append i wrote for LLVM

[16:35] <stakkars> the plain backend it complete I guess.

[16:35] <hpk> arigo: ok, so the code here really needs to be even more lowlevel/static than RPython

[16:35] <arigo> cfbolz: :-)

[16:35] <pedronis> we basically need this kind of implementations for all of our rpython types

[16:35] <stakkars> we program the C code generation by writing this funny code, ok?

[16:35] <arigo> hpk: exactly

[16:35] <arigo> hpk: only low-level types

[16:35] <hpk> exceptions are ok, though?

[16:35] <cfbolz> stakkars: yes, but the cool thing is that it works for other backends, too

[16:35] <arigo> stakkars: yes, once the typer has finished its job, the graph only contain direct_calls and low-level-type operations

[16:35] <stakkars> yes, I can plug in a forth interpreter.

[16:36] <arigo> :-)

[16:36] <arigo> hpk: exceptions are harder to do generically, I guess

[16:36] <stakkars> (although the produced code is far away from Forth-ish, no code-threading)

[16:37] <hpk> arigo: but for example, 'typeOf' what would you see in the CFG for that?

[16:37] <stakkars> ah, I see further transformation on top of these graphs: squeezing out code that could become re-used etc.

[16:37] <arigo> hpk: it gets removed from the CFG

[16:37] <pedronis> typeOf need to be special cased in the annotator

[16:37] <pedronis> so that is is computed at annotation time

[16:37] <pedronis> and then removed by the rtyper

[16:37] <hpk> arigo: shouldn't this be 'lltypeOf()'?

[16:38] <arigo> hpk: yes

[16:38] <hpk> pedronis: ok

[16:38] <arigo> we need to figure out a more consistent naming scheme around here, ConceptualLevelsOverflow

[16:38] <hpk> is this robust enough to fail in a meaningful way if you use things that you are not supposed to use? (like range)?

[16:39] <pedronis> malloc and the cast operations are already special-cased

[16:39] <pedronis> hpk: you will get errors at some point

[16:39] <pedronis> some will be less obscure than others

[16:39] <arigo> hum, I wonder now

[16:39] <arigo> using range() here might even work

[16:40] <pedronis> for the annotator yes

[16:40] <arigo> and then the rtyper will replace it with range support code

[16:40] <stakkars> hehe

[16:40] <arigo> the risk is to get an infinite recursion at run-time, while running the generated C code

[16:41] <pedronis> yes, it really depends on how range is implemented at the end

[16:41] <arigo> if ll_append uses lists and the append method of them, it will just cause a recursive call to itself

[16:41] <arigo> "just" :-)

[16:41] <hpk> if we had something like two more separated annotators couldn't you catch this early?

[16:41] <arigo> hpk: I guess so

[16:41] <stakkars> maybe we should have a protection mechanism for that, which we also might use in our call backs to applevel,

[16:42] <pedronis> well, you will most likely get errors when you try to mix

[16:42] <stakkars> like "raise RecursionException, you are calling me while implementing me"

[16:42] <hpk> OTOH, arigo already said that we should avoid writing too much code at this level, anyway

[16:42] <pedronis> hpk: yes

[16:42] <arigo> hpk: definitely :-)

[16:42] <stakkars> how much does it need to be, actually?

[16:43] <pedronis> rpython lists, tuples and strings

[16:43] <stakkars> I hoped to be able to generate these, by some good rules.

[16:43] <arigo> and dicts

[16:43] <pedronis> yes

[16:43] <hpk> so len(lowleveltype) is also specialcased, i guess

[16:43] <arigo> hpk: yes, by a len in __extend__(SomePtr) in the annotator

[16:43] <pedronis> and support code for the rpython object system (classes, instances)

[16:43] <hpk> stakkars: that would introduce another level of indirection, wouldn't it?

[16:44] <pedronis> hpk: the thing is that the low-level type don't generalize their content

[16:44] <pedronis> so if you try to put a list in a low-level int array you get a type error

[16:44] <stakkars> hpk: I was thinking of a ruleset that generates this low level flow graphs

[16:44] <pedronis> ... at annotation time

[16:45] <arigo> hpk: yes, you have a lot of type checks in lltype.py, and the annotator crashes on them early

[16:45] <arigo> hpk: with nice error messages, even

[16:45] <hpk> makes sense

[16:45] <arigo> stakkars: I see. yes, it's just much simpler to write the flow graphs in Python than in a custom language...

[16:46] <cfbolz> all this makes the backends for a C-like language very simple

[16:46] <arigo> stakkars: we've been down that path too, it because very obfuscated just to replace these short def ll_x()

[16:46] <hpk> probably we shouldn't worry about this rpython^2 coding style until it gets really problematic

[16:46] <arigo> s/because/becomes

[16:46] <arigo> hpk: :-)

[16:47] <stakkars> ok, so we write this bit of stuff, and then the C thing should really be done :-)

[16:47] <hpk> llpython :-)

[16:47] <arigo> rrpython... :-/

[16:47] <hpk> really restricted?

[16:47] <stakkars> grrpython

[16:47] <arigo> restricted restricted

[16:47] <arigo> Greatly Restricted RPython

[16:48] <hpk> ok, so let's see where we are now (i also need a small break soon)

[16:48] <stakkars> admit it, is is assembly

[16:48] <pedronis> mmh, you have while and if

[16:48] <arigo> we have only this beginning of rlist

[16:48] <mwh> not quit

[16:48] <mwh> e

[16:49] <arigo> you might want to run this test with the t.view() enabled

[16:49] <stakkars> pedronis: assembly too with macros

[16:49] <arigo> and see the 4 flow graphs with llops only: dummyfn, ll_getitem, ll_setitem, ll_newlist

[16:49] <pedronis> well it's sort of a subset of C with python syntax

[16:50] <arigo> that's about as far as we are for the rtyper.

[16:50] <pedronis> it has also GC support, there's no free

[16:51] <arigo> translator/c/* is coming closer to replace translator/genc/*

[16:51] <hpk> arigo: the CFG view hides exactly the ll-XXX name :-)

[16:51] <arigo> ?

[16:52] <stakkars> erhm, in which file are you?

[16:52] <hpk> arigo: it shows "direct_call(<_ptrytype to func ll...._noneg>) ..."

[16:52] <cfbolz> when you do the t.view in test_rlist

[16:52] <arigo> hpk: I see

[16:52] <hpk> stakkars: in the pygame view that arigo recommended

[16:53] <stakkars> I don't get which file I should test and remove the #

[16:53] <hpk> look at screen

[16:53] <arigo> rpython/test/test_rlist.py

[16:53] <stakkars> ah, I was in C sorry

[16:54] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: " * Blackened *"

[16:54] alsh (chatzilla@101.rcu200.teletoria.ru) left #pypy.

[16:54] <arigo> the pygame viewer shows variable names as follows:

[16:54] <arigo> (low_level_type) v12: SomeXyz(...)

[16:55] <arigo> the backends should only use the (low_level_type) part, and no longer the SomeXxx annotations

[16:55] <arigo> this example shows a bug: the return variable in the exit blocks is missing the (low_level_type)

[16:56] <hpk> ?

[16:56] <pedronis> a bug in the rtyper

[16:56] <arigo> if you have the same numbering as me, then v0, v30, v149, v218

[16:56] <arigo> have only the SomeXyz annotation and not the (low_level_type)

[16:56] <stakkars> I don't see the (low_level_type) v12 notation ???

[16:57] <arigo> v12 was an example

[16:57] <hpk> i don't have any v12 anyway

[16:57] <stakkars> no,not atall. can you give a real name to look at?

[16:57] <arigo> e.g. (Signed) v8: SomeInteger(nonneg=True, unsigned=False)

[16:57] <arigo> all variables should have this format.

[16:57] <arigo> so all names.

[16:58] <pedronis> the first thing in () (Signed) is the low-level type

[16:58] <hpk> arigo, pedronis: sorry, i am not sure i am looking at the same thing

[16:58] <stakkars> I only get v8 = something

[16:59] <cfbolz> If you put the mouse on v8 you see the annotation on the bottom

[16:59] <stakkars> ah, thanks!

[16:59] <hpk> ok

[16:59] <cfbolz> and it shows something like (Signed) v8: SomeInteger

[16:59] <cfbolz> but not in the exit blocks

[16:59] <stakkars> and we return a SomeInteger, which is a bug.

[16:59] <arigo> the bug is the missing (Signed) in the return

[16:59] <hpk> makes sense

[17:00] <hpk> what do you think about making a 15 minute break and then maybe jump to a slightly more higherlevel discussion?

[17:00] <ericvrp> if you look at v211, why does that say (void)

[17:01] <cfbolz> because the function returns None?

[17:01] <cfbolz> implicitly?

[17:01] <arigo> hpk: ok

[17:01] <pedronis> ok

[17:01] Action: stakkars would even like an one hour break

[17:01] <arigo> ericvrp: the hidden function name that is called here is ll_setitem_nonneg

[17:02] <hpk> arigo: we could use '*' instead of '_ptr_type' for the repr :-)

[17:02] <arigo> yes

[17:02] <pedronis> yes

[17:02] Action: mwh could do with a break too

[17:02] <hpk> so how long?

[17:02] <pedronis> at some point there were different ptr subclasses

[17:03] <pedronis> so the repr made sense

[17:03] <arigo> ericvrp: as the call is inserted by the rtyper, it doesn't bother putting a SomeXxx annotation at all, just a low-level-type --- here Void for no return value.

[17:03] <stakkars> how long? I would like to call a customer and eat something

[17:03] <arigo> one hour?

[17:03] <cfbolz> should we say 18.00?

[17:03] <hpk> ok with me

[17:03] <stakkars> very good

[17:03] <arigo> ok

[17:03] <mwh> cfbolz: works for me

[17:03] <cfbolz> :-)

[17:04] <hpk> ericvrp, cfbolz: llvm runs on codespeak now

[17:04] <cfbolz> hey cool. thanks

[17:04] <hpk> and passes the pypy related tests

[17:04] <ericvrp> I will be eating by then. But might aswell read the logs. Not typing much anyway

[17:04] arre (ac@ratthing-b3fa.strakt.com) left #pypy.

[17:05] <cfbolz> eric: still there?

[17:07] <ericvrp> yes

[17:08] <ericvrp> hpk: cool!

[17:09] <cfbolz> the fix you did is really a workaround. in reality we have to be more careful in LLVM to use the correct int types.

[17:09] <ericvrp> I know

[17:09] <arigo> if that's relevant, in C we're going for "longs everywhere" at the moment

[17:10] <ericvrp> I was working on that, a find&replace uint->ulong work somewhat

[17:10] <cfbolz> no, the problem is that llvm long is the same size everywhere

[17:10] <ericvrp> However, the malloc get getelementptr gave bitten me from behind

[17:11] <ericvrp> Yes, that generated bc files that would run faster on x86-64 but not on x86

[17:12] <ericvrp> I think we might have to generate two .ll files :(

[17:12] <ericvrp> s/get/and

[17:13] <cfbolz> no, we have to find out on which platform we're on and replace int in the appropriate places with long, if we're on a 64 bit platform

[17:13] <ericvrp> hpk: and the pypy llvm test still work :)

[17:14] <cfbolz> eric: it's probably not worth it working on this too much, since genllvm has to be rewritten in large parts anyway, to use the new infrastructure

[17:14] <ericvrp> ok, but that only works when you are on the target platform.

[17:14] paulb (chatzilla@c5100913D.inet.catch.no) left #pypy.

[17:14] <cfbolz> we work under this assumption most of the time anyway

[17:15] <ericvrp> you are right. but it gives me an angle to look at genllvm and from there into pypy. It's works better for me then to start hacking in genllvm at the moment

[17:15] <cfbolz> yes, of course

[17:17] <cfbolz> this whole id thing you fixed is a gross hack anyway :-)

[17:20] Action: cfbolz --> away

[17:20] <ericvrp> I agree. (unfortunately). What I tried first is generate a uintorlong type and use that, then I did a global find&replace uint->ulong (except for lines with malloc&getelem..) that also did not work because sometimes malloc size was input through a variable., etc... I learned a lot

[17:22] <cfbolz> ok

[17:22] Action: cfbolz not really away

----- silence for 25 minutes -----

[17:47] <cfbolz> s/not/now :-)

[17:47] Action: cfbolz back

[17:48] ludal (ludal@logilab.net2.nerim.net) left #pypy.

[17:48] arre (~ac@1-1-5-33a.gfa.gbg.bostream.se) joined #pypy.

[17:56] <mwh> time to hurt our heads again? :)

[17:58] <arigo> back

[18:00] <arre> I'm back.

[18:01] <hpk> back

[18:02] <stakkars> back

[18:02] <hpk> arigo: regarding rev 12795: write a test at ll/rrpython level? :-)

[18:03] <arigo> yes, we should write tests calling ll_append and friends

[18:03] <arigo> but my question was how to check that the rtyper did a good job and didn't mess up the graph

[18:05] <pedronis> we would need unit test with just one block or one space op

[18:05] <arigo> ...hum, calling t.checkgraphs() looks like a first thing to do

[18:05] <arigo> pedronis: right

[18:05] <pedronis> but they would still be cumbersome to write

[18:06] <pedronis> also the rtyper should have an interface to allow that kind of use

[18:06] <stakkars> if we are able to write an unrtyper and compare that with the original, would this be good?

[18:07] <pedronis> writing an untyper is a lot of work

[18:07] <stakkars> probably almost impossible...

[18:07] <pedronis> maybe

[18:07] <pedronis> it would need to have its own assumptions

[18:07] <stakkars> hehe,actually astep into reverse engineering

[18:07] <arigo> what about writing another typer and checking that they give the same result -<:-)

[18:08] <stakkars> absolutely, if we can do that differently.

[18:08] <cfbolz> what about a flow graph simulator?

[18:08] <cfbolz> that runs the flow graphs

[18:08] <stakkars> is that a proof of correctness?

[18:08] <arigo> cfbolz: much more sensible suggestion

[18:08] <hpk> sounds interesting

[18:09] <arigo> stakkars: unittests are not proofs of anything

[18:09] <stakkars> didn't say so. reversibility would be.

[18:09] <arigo> anyway, let's move on to the overview of what is done or left to do now that we've seen the details

[18:10] <hpk> well, the testing/cfg interpreter is an high-level adn interesting topic IMO :-)

[18:10] <arigo> yes

[18:10] <arigo> but let's avoid too many forks atm

[18:10] <arigo> I just wanted to say that the translator/c/* is in good shape already

[18:11] <mwh> can it actually create c yet?

[18:11] <pedronis> it needs impl of the decref/incref/free logic

[18:11] <arigo> yes

[18:11] <hpk> arigo: sorry, what has translator/c/* to do with the rtyper/test discussion?

[18:12] <arigo> hpk: the meeting's goal was to give an overview of the current state of the translation

[18:12] <arigo> hpk: annotation is OK, we've seen how far rtyper is, now just a few words about the C back-end

[18:12] <hpk> ah ok, sure

[18:12] <stakkars> yes. there is no discussion now

[18:13] <hpk> but you said "i just wanted to say" which seemed like talking about the past

[18:13] yuuh (~yuuhu@dsl-62-220-11-192.berlikomm.net) left irc: Read error: 113 (No route to host)

[18:13] <arigo> the one-hour-ago past, at the start of the break

[18:13] <arigo> :-)

[18:13] yuuh (~yuuhu@dsl-62-220-11-192.berlikomm.net) joined #pypy.

[18:14] <hpk> arigo: just go on, i am still not making full sense but it doesn't matter probably

[18:14] <arigo> well there isn't much more to say, if you didn't miss Samuele's comments

[18:15] <stakkars> maybe a picture would help, from where to where things flow, what gets involved, how things interact, and where we find ourselves implementing stuff?

[18:15] <pedronis> to recall:

[18:15] <pedronis> we start with annotated rpython graph

[18:15] <pedronis> anotation are about rtpython types

[18:16] <pedronis> the task of the typer is to substitute rpython "high"-level ops and types

[18:16] <pedronis> with low-level types and operations

[18:16] <pedronis> and add low-level helpers for the operation on rpython types

[18:16] <pedronis> translator/c should take the graph set resulting from rtyper

[18:16] <pedronis> and produce c code

[18:17] <pedronis> dealing with last low-level details about GC (ref counting) and somehow exceptions

[18:18] <pedronis> .

[18:18] <mwh> i guess for the first instance, exceptions should be handled the same way CPythn does

[18:18] <mwh> (for the C translator)

[18:19] <stakkars> like it is, now

[18:19] <mwh> also, can i say what a relief to me it is that we shouldn't need to teach the C translator, the LLVM translator and the Java translator independently about all the rpython types

[18:20] <cfbolz> thats the cool thing about it

[18:20] <hpk> yes

[18:20] <arigo> there is preliminary support for low-level types in the existing translator/genc/, but it's going away (too messy)

[18:20] <arigo> this makes me suppose that inserting lltype support in genllvm isn't too big a deal

[18:20] <stakkars> you are going to trash all the header files?

[18:21] <cfbolz> arigo: right

[18:21] <arigo> stakkars: no, probably not -- copied some already

[18:21] <cfbolz> arigo: the difficult part is finding out what to throw away

[18:22] <arigo> for genc too

[18:22] <stakkars> arigo: you might remember the div_int_int implementation which involves more than a simple macro.

[18:22] <cfbolz> genllvm will become _a lot_ simpler

[18:22] <stakkars> do we keep this, or re-implement it in grrpython?

[18:23] <cfbolz> so grrpython is the official name now?

[18:23] <cfbolz> :-)

[18:23] <stakkars> I meand mod_int_int with overflowcheck and these adjustments for the direction of negative mod

[18:24] <arigo> stakkars: not sure about it

[18:24] <arigo> stakkars: at first, that sounds very C-specific

[18:25] <pedronis> operations on Signed and Unsigned are still mostly a final backend task

[18:25] <hpk> cfbolz: it's a funny name but 'll' seems much more correlating to the ll-type level

[18:25] <stakkars> maybe later, when we somehow can read compiler issues into the rtyper and react accordingly

[18:25] <cfbolz> hpk: just a joke

[18:25] <pedronis> the rtyper convert add of Integers into int_add

[18:26] <stakkars> the same way I think of reading descriptions of the taget machine code in and configuring lllevel output.

[18:26] <arigo> pedronis: rtyper could also detect if overflow-checking is needed, and use int_add_ovf

[18:26] <cfbolz> how is the ovfcheck situation now?

[18:26] <arigo> s/use/generate

[18:26] <pedronis> arigo: yes

[18:26] <pedronis> although I think we have a ann-simplification pass that does that now

[18:27] <pedronis> anyway all this things are a bit open, also considering that if we add more backends some slight changes, generalizations may be needed

[18:27] <arigo> cfbolz: I think it's been stabilized in the way specified in the documentation (which I'm not too sure I remember after all these changes :-)

[18:28] adim (adim@logilab.net2.nerim.net) left #pypy.

[18:30] <hpk> regarding overview, i am kind of fine at the moment

[18:30] <pedronis> I think the current behavior is implemented in simplify.transform_ovfcheck

[18:30] <arigo> hpk: yes, seems like we're done

[18:30] <mwh> phew :)

[18:30] <pedronis> so before annotation (I did not remember either)

[18:30] <mwh> arigo, pedronis: thanks!

[18:30] <cfbolz> pedronis: there are some problems with this yet, I get SomeObjects

[18:30] <stakkars> maybe we could try to decide who does what?

[18:31] <pedronis> cfbolz: this = ?

[18:31] <stakkars> and what is needed, in which order?

[18:31] <cfbolz> pedronis: simplify.transform_ovfcheck

[18:31] <arigo> stakkars: good idea

[18:31] <pedronis> ah

[18:32] <pedronis> cfbolz: may some of the things it generates are still missing from the annotator

[18:32] <pedronis> stakkars wrote that code, we haven't that many example in the test about that

[18:32] <pedronis> and some have been disabled because anyway genc was lacking support

[18:32] <cfbolz> I tried to support it with genllvm and found it

[18:33] <stakkars> it is a little incomplete: Itdoes not handle the case where you don't wrap an expcetion around ovfcheck

[18:33] <pedronis> well if you get SomeObject it's probably because the operation it using is not there in the annotator

[18:33] <stakkars> a test is there, I think it was in genc

[18:34] <hpk> so are we at the point to try to identify open tasks?

[18:34] <pedronis> we just rediscovered with arigo that the annotator defaults to SomeObject if it encounters an unknown op

[18:34] <cfbolz> ok. I'll file an issue re ovfcheck

[18:35] <arigo> hpk: yes: I'm trying to write them down in the screen window

[18:36] <hpk> arigo, pedronis: do you have an idea regarding the "rpython object system" already?

[18:37] <stakkars> I gues this is basically adding a little bit to structures

[18:37] <stakkars> because we have no dynamic lookup if I'm not mistaken.

[18:37] <pedronis> no for now the idea is to construct on top of structs

[18:37] <cfbolz> That's what I did for genllvm

[18:38] <pedronis> not to add OO to structs

[18:38] <cfbolz> (plus some hacks)

[18:38] <stakkars> what about dicts?

[18:38] <arigo> we're only to some very basic ideas about the object system

[18:38] <stakkars> I think they were string only. DO we have dynamic dicts, or are allkeys deducable at compile time?

[18:38] <arigo> if I'm not mistaken,

[18:38] <arigo> we have string-keyed dynamic dicts, and non-string-keyed but immutable dicts

[18:39] <pedronis> and probably some stuff breaking those rules

[18:39] <pedronis> that should be teached better

[18:39] <pedronis> hpk: object system: some vague idea about vtables

[18:41] <stakkars> hum. and I hoped dicts would melt away,completely.

[18:41] <arigo> stakkars: yes, that's semi-bad, but on the other hand it's not such a big deal any more with llpython

[18:42] <hpk> pedronis: so there would need to be function pointers, i guess

[18:42] <pedronis> hpk: yes

[18:42] <cfbolz> pedronis: sorry for the fuss about ovfcheck, it seems I tried this on a stale checkout yesterday. :-( It works now.

[18:42] <pedronis> the current low-level model

[18:42] <pedronis> has the notion of function pointers

[18:43] <pedronis> it's one of the C-ish aspects of it

[18:44] <stakkars> why do we need these method pointers?

[18:44] <cfbolz> well, but function pointers could be "lowered", if absolutely neccessary

[18:45] <stakkars> I see, we need them

[18:45] <arigo> stakkars: yes, by default methods are "virtual" in the C++ sense

[18:45] <pedronis> because for now dealing with class impl at the rtyper level is probably the less messy way

[18:46] <pedronis> considering the C translation goal

[18:46] <pedronis> but yes their not completely generalizable thing and sane approach wrt all possible backends

[18:47] <pedronis> s/their/they are

[18:47] <hpk> but probably also makes sense for llvm at least

[18:47] <pedronis> yes, for llvm it makes sense too

[18:47] <pedronis> but I as said I really think that trying to get all the machinery

[18:47] <cfbolz> yes, but can be annoying at times, since there are absolutely no automatic conversions

[18:47] <stakkars> do we really move objects around in a way that the annotator cannot five us an exact type?

[18:48] <pedronis> working end-to-end

[18:48] <stakkars> in that case, we would not need any virtualmehtods.

[18:48] <pedronis> stakkars: we dynamically dispatch in our code

[18:48] <pedronis> rpython is not "so" restricted

[18:49] <hpk> pedronis: but aren't those dispatches from a const-dict/pbc?

[18:49] <stakkars> but we have a fixed number of classes, and after a dispatch, we know where what is,atcompile time.

[18:49] <pedronis> no

[18:49] <arigo> hpk: no, we use subclassing and method overriding all over the place

[18:49] <pedronis> yes

[18:49] <pedronis> mm themself use that all over the place

[18:49] <hpk> sure, i was thinking of explicit dynamic dispatch

[18:49] <pedronis> doing double dispatching

[18:50] <arigo> stakkars: yes, we can do better than C++ in the sense of figuring out at compile time which call site needs to be virtual or not

[18:50] <pedronis> yes

[18:50] <pedronis> we can find out monomorphic call site

[18:50] <arigo> hpk: ah, ok; i think Christian has regular method calls in mind

[18:50] <stakkars> but since we use overriding,we can expect that we need the VMTs

[18:50] <hpk> makes sense

[18:51] <stakkars> hmm, at the moment, I again think we can precompute every method call because we know alltypes.hmm.

[18:52] <arigo> stakkars: no, a given point can call multiple methods;

[18:52] <arigo> stakkars: but what would be possible is to precompute the set of possible methods that it can call

[18:52] <pedronis> yes

[18:52] <hpk> and if that happens to be of length 1 then you can specialcase it

[18:53] <pedronis> yes, monomorphic == just one possible type

[18:53] <stakkars> then it is possible to use VMTs, or local tiny dispatch case tables, or we might specialize the code to make these all monomorphic

[18:54] <stakkars> the latter must be analysed carefully,couldcause explosion

[18:54] <hpk> sure, but that's all a later optimization anyway, i guess

[18:54] <arigo> yes

[18:54] <pedronis> yes

[18:54] <cfbolz> llvm can do some of those things, so we might not do this to early

[18:55] <hpk> i'd really like to think about the ll-cfg interpreter in order to write tests for ll-types

[18:55] <stakkars> just tried to get rid of puncion pointers at all :-)

[18:55] <arigo> cfbolz: interesting to know where we're loosing our time on optimization :-)

[18:55] <cfbolz> :-)

[18:55] <hpk> shouldn't such an cfg-interpreter be rather easy to do?

[18:56] <pedronis> hpk: yes

[18:56] <arigo> (just to summaries, this ll implementation of RPython types is the bulk of what remains to be done at this point)

[18:56] <cfbolz> hpk: yes, I think that's a good idea. at the moment we're always testing the combination of backend and ll implementation

[18:56] <pedronis> hpk: you can use the concrete impl of lltypes in lltype

[18:56] <pedronis> for that

[18:56] <arigo> hpk: yes, as there are only low-level operations left -- should be really easy

[18:57] <hpk> it just seems that it would help to speed up the impl of ll-types and rtyper-work

[18:57] <cfbolz> would it be that much more difficult to do this with "regular" flow graphs?

[18:57] <arigo> definitely

[18:57] <arigo> cfbolz: there are just more operations, you need a space, for starters

[18:58] <cfbolz> ok

[18:58] <arigo> hpk: also note that early testing of lltypes can just run the ll_* functions

[18:58] <arigo> hpk: though that's pretty limited, obviously

[19:00] <hpk> arigo: come on, for you it's an evening exercise to write a ll-graph interpreter :-)

[19:00] <arigo> hpk: just listing ideas :-)

[19:01] <stakkars> yeah, you have a big dict mapping vars to bindings, then you do all the ops... nice

[19:02] <arigo> cfbolz: can you think of a few bullets points for genllvm (in screen)?

[19:02] <hpk> cfbolz: maybe you can tell a bit about the state of genllvm and next steps?

[19:02] <cfbolz> ok. as I said, the biggest problem is that genllvm does to much

[19:03] <stakkars> you would need to refactor as in genc -> c

[19:03] <cfbolz> yes.. I does a lot of the things now moved to the lltypes: object system, virtual method calls, etc

[19:03] <arigo> genc was probably more messy than genllvm, though

[19:04] <arigo> but you may want to give a look to c/database.py,

[19:04] <hpk> cfbolz: can you show a bit of that in code (as far as it maeks sense to you)?

[19:04] <cfbolz> arigo: that's similar to LLVMGenerator, I think. The basic ideas and mechanisms can be kept, I think I can gradually add support for the low level types and then start to remove the current stuff.

[19:04] <arigo> cfbolz: great

[19:04] <cfbolz> hpk: it was mostly very hackish

[19:05] <arigo> genc didn't have any kind of collector, I wasn't sure if genllvm does.

[19:05] <cfbolz> what do you mean by collector?

[19:05] <stakkars> garbitch

[19:06] <cfbolz> stakkars: ah, thanks, that's missing in genllvm, too

[19:06] <arigo> database.py "collects" and organizes a bit all the low-level types and prebuilt structures and functions

[19:06] <arigo> generating code is done only when this is complete

[19:07] <cfbolz> ok. genllvm generates low-level types and when they are used in a function

[19:07] <stakkars> arigo: how does it collect?

[19:08] <arigo> stakkars: you give it an entry point object (can be a function)

[19:08] <hpk> arigo, cfbolz: so does llvm's MemoryLayout relate to c/database ?

[19:08] <arigo> stakkars: then it asks for dependencies, and follow them

[19:08] <cfbolz> hpk: no, that's basically a struct. Don't look at it.

[19:08] <arigo> hpk: doesn't seem so

[19:08] <cfbolz> hpk: lltypes does all that anyway

[19:09] <stakkars> arigo: why that? being ableto generate them all in one place, instead of as a side effect?

[19:09] <hpk> cfbolz: yes, i was just wondering

[19:09] <arigo> stakkars: yes, it's cleaner

[19:09] <cfbolz> arigo: I can confirm that, the side effect approach can get confusing

[19:09] <arigo> stakkars: the idea was to be able to generate several files instead of one huge file

[19:10] <arigo> stakkars: where each file only contains the necessary dependencies and includes

[19:10] <stakkars> arigo: ahaa, makes much sense. To someextent we could also do partial regenerates.

[19:10] <cfbolz> hpk: you still want to work with me on genllvm?

[19:10] <pedronis> we will probably try that at least for implementations (separate files)

[19:10] <cfbolz> or maybe more general: how do we distribute the work?

[19:11] <hpk> cfbolz: yes, but probably not much until june

[19:11] <cfbolz> hpk: well, june starts next week :-) or do you mean EP?

[19:12] <hpk> cfbolz: somewhere first half june i'd like to start diving into llvm more

[19:12] <pedronis> (reminder: we still have interpreter tasks ... btw)

[19:13] <hpk> cfbolz: i am still not completely sorted out with the various things that are going in my (dev and non-dev) life

[19:13] <arigo> (pedronis: yes, we mind want to list them along with beginner-friendliness grades)

[19:13] <cfbolz> hpk: that's perfect: until then the refactoring will hopefully be complete and the cruft gone

[19:14] <pedronis> (arigo: yes, we may want soon want to discuss and list/sort trough that part too)

[19:14] <hpk> cfbolz: sounds good, btw, i was even thinking about meeting for a weekend, my company could invite you (travel cost wise) :-)

[19:15] <pedronis> (not today of course)

[19:15] <arigo> stakkars: what would you like to work about? llpython implementations? C gen?

[19:15] <cfbolz> hpk: that's a good idea. Or alternatively you are also most welcome to visit me in Heidelberg :-)

[19:15] <hpk> cfbolz: sounds good as well, let's talk about it later

[19:15] <stakkars> arigo: C gen. whatever you thoink fits me best, there.

[19:16] <arigo> stakkars: great

[19:16] <stakkars> arigo: I want to see the class structures andlists and strings vanish and see how rpystone looks,then.

[19:16] <arigo> :-)

[19:18] <arigo> stakkars: most of the work left is to catch up with the previous genc's abilities;

[19:18] <arigo> stakkars: we have already what's needed to generate struct defs and prebuilt static structures

[19:19] <stakkars> we have it in genc,yes (and it crashes on empty tuples :-) )

[19:19] <arigo> stakkars: no, I mean in c

[19:19] <cfbolz> how stable are the low level types, btw?

[19:19] <arigo> in translator/c/

[19:19] <stakkars> ok!

[19:19] <arigo> cfbolz: should be stable enough for now, but

[19:19] <arigo> s/but// :-)

[19:20] <arigo> stakkars: try for example:

[19:20] Action: mwh wanders off

[19:20] <arigo> test_all.py translator\c\test\test_database.py -s

[19:20] <mwh> see you soon!

[19:20] <arigo> mwh: see you!

[19:20] <pedronis> mwh: see you

[19:20] <stakkars> arigo: sure, I messed up. tried everything believe!

[19:20] <stakkars> mwh: bye

[19:21] <pedronis> we probably need a low-level Float/Double type

[19:21] <pedronis> (not that it is hard to add)

[19:22] Action: arigo keeps forgetting that people use floats and strings quite often

[19:22] <arigo> strings are supposed to be arrays of char, btw

[19:22] <stakkars> that's straightforward, yes. What about unicode?

[19:22] <arigo> arrays of unicode char :-)

[19:22] <stakkars> ok, all similar stuff,but needed.

[19:22] <pedronis> we need a low-level type correspond to SomeUnicodeCodePoint

[19:23] <stakkars> what's that <:-)

[19:23] <arigo> btw, there is still some thinking to do about how the generated C code calls external functions (e.g. for the 'os' module)

[19:23] <arigo> with the function pointer type in lltype, a reasonable path seems to emerge

[19:23] <stakkars> making these things just into SomeObjects and call them ?

[19:24] <arigo> no, precisely

[19:24] Action: arigo goes to screen

[19:24] <pedronis> stakkars: is the annotation for 1-char unicode string, which should be the equivalent of CPython Py_UNICODE

[19:25] <stakkars> pedronis: this is 16 bit something I guess?Or do we use 32

[19:25] <pedronis> the backend can choose

[19:26] <stakkars> (forgot about unicode,never loved it)

[19:26] <pedronis> that's somehow the point of the abstraction

[19:26] <pedronis> very few operations are supported on that

[19:26] <stakkars> no, I meant if it fits, I thought this would not give the whole unjcode space without escaping

[19:28] <pedronis> well CPython itself let you choose at compilation time between 16 or 32

[19:28] <pedronis> bits

[19:28] <arre> We will need 32-bit if we want to support all currently defined unicode characters.

[19:28] <stakkars> I remember.

[19:30] <cfbolz> arigo: are you putting you're to do list somewhere?

[19:31] <arigo> cfbolz: yes, I'm posting it and the captured Python session to pypy-dev

[19:32] <stakkars> OT: after the first release, Dinu Gherman contacted me and said that we must work on articles and such.

[19:32] <cfbolz> yes. we need better PR, i think

[19:32] <stakkars> OT: I would like to discuss this at some point, maybe we can pay Dinu for writing?

[19:33] <stakkars> there should be resources for that. Just that I don't forget to say it.Should probably be a funding discussion?

[19:34] <pedronis> cfbolz: right now we have slightly hard to market product both because it is of limited practical interest as it is

[19:35] <stakkars> I am thinking of nice articles in magazines

[19:36] <stakkars> telling about what's there and what's the future,possible applications etc.

[19:36] <cfbolz> pedronis: ok, it's dangerous to produce too much hype

[19:36] <cfbolz> stakkars: I bet you could get c't interested :-)

[19:36] <stakkars> I think that's called "disemination" ?

[19:37] <stakkars> cfbolz: yes, probably. I was specially thinking of Dinu who's a good writer and also was on the first sprint. he needs work.

[19:37] <pedronis> cfbolz: no, in this case I'm not talking about hype, just the simple fact that right now we are not really practically useful

[19:38] <stakkars> arre: do I install an option for that, or do I just implement both?

[19:39] <stakkars> arigo: probably both, I guess the C support is very tiny

[19:39] <stakkars> s/arigo/arre/

[19:40] <arre> stakkars: About unicode?

[19:40] Action: stakkars suggests that we use nicknames with unique starting letters :^)

[19:40] <stakkars> yup

[19:41] <arre> I'm happy with 32-bit only.

[19:41] <stakkars> fine with me!

[19:42] <stakkars> I guess this gives fast operations, and people can anyway use utf8later

[19:42] <stakkars> utf8 later

[19:42] <arre> If anyone has problems with memory because of that they do better to store them in utf-8.

[19:43] <pedronis> changing this kind in themself of things should be easy anyway

[19:43] <pedronis> (it's the point of PyPy)

[19:44] <pedronis> our current goal is the overall picture of translating PyPy and getting some reasonable speed back

[19:44] <stakkars> pedronis: sure, I'm just talking of theprimitive C type support. This should be done once in the needed flavors.

[19:44] <stakkars> pedronis: and then never needs to be rewritten. We just change the layer above this.

[19:45] <pedronis> maybe, some issue are open for example whether we want to special case some kind of rpython lists

[19:45] <pedronis> but is to early to tell

[19:46] <pedronis> the current unicode impl uses rpython lists of these unicode units

[19:46] <hpk> arigo: that's really a ll-roadmap :-)

[19:47] <arigo> well :-)

[19:48] <stakkars> arigo: so I guess I should start to get rid of the C things and move to programming the grrpython things?

[19:48] <arigo> stakkars: how so?

[19:48] <stakkars> (I meant implement the primitive stuff and then move to dicts)

[19:49] <arigo> you said you preferred to work on C code generation than implementing this?

[19:49] <stakkars> arigo: I thought life is now on top of the backends, and there is not much fancy work to do for the C code

[19:50] <stakkars> I think it should not take much time. Well, interfacing and getting stuff to work again is somework.

[19:51] <stakkars> arigo: you asked me whether I want C orLLVM, then I said C (and I'm fine with it).

[19:51] <arigo> ah, misunderstanding; I thought I asked between C and rpython/r*.py

[19:51] <stakkars> but since algorithms no longer go into C, I finally want to catch up there, too.

[19:52] <arigo> so your answer to the question I thought I asked is, "both" :-)

[19:52] <stakkars> yes, just starting from the bottom gives me aclearordering of tasks and no interference soo far.

[19:53] <arigo> ok

[19:53] <arigo> great

[19:53] <pedronis> I think the 3 of us will probably work on different part of all that

[19:54] <stakkars> yes,you said lltypes,I got it as llvm :-)

[19:54] <stakkars> if you can in doubt save a little bit of dicts forme, I'd love that :-)

[19:54] <pedronis> there's quite a bit of stuff

[19:55] <pedronis> at least as much or more that is in the annotator

[19:55] <pedronis> in the sense that here a correspondence

[19:55] <pedronis> between the operations annotated there

[19:55] <pedronis> and things needed in rtyper too

[19:56] <pedronis> there are also some issues open about interface/communication between the annotator and rtyper

[19:56] <pedronis> especially about things the annotator specializes

[19:57] <stakkars> pedronis: I don't catch up: was this in the low level tasks list?

[19:57] <pedronis> yes, added it at top at some point

[20:02] <pedronis> I imagine we have finished

[20:02] <pedronis> arigo, hpk: we should probably schedule a non-translator tasks left session at some point

[20:03] <arigo> yes

[20:03] <hpk> pedronis, arigo: yes, do we try that before the 3rd june consortium meeting?

[20:04] <stakkars> pedronis: where did the summary go in svn?

[20:05] <pedronis> stakkars: arigo sent it as attachement in a mail to pypy-dev

[20:05] <stakkars> hpk: OT: need to talk about Form C

[20:05] <stakkars> pedronis ah

[20:06] <pedronis> hpk: maybe

[20:07] <pedronis> arigo: ideas about when?

[20:07] Action: arigo almost afk

[20:08] <hpk> 2nd june (tuesday) would be possible, maybe

[20:08] <cfbolz> is someone trying to work on the flow graph interpreter?

[20:09] <stakkars> if I didn'tmiss something, there was no explicit assignment but mine ???

[20:09] <cfbolz> ok, then I'll give it a shot tonight

[20:09] <pedronis> cfbolz: learning wise, is probably more interesting for someone who is not already familiar with the stuff in lltype

[20:10] <cfbolz> yes, but I don't know anything about the stuff in lltypes

[20:10] <cfbolz> do I qualify?

[20:10] <stakkars> then I think this is an exercise for everybody who wantsto program lltypes:

[20:11] <stakkars> write an intepreter, and at somepoint we have a contest :-)

[20:11] <hpk> :-)

[20:11] <pedronis> stakkars: it seems that cfbolz and hpk will work on llvm ...

[20:12] <stakkars> (I was serious, it is not too hard,and turns you into an expert)

[20:12] <pedronis> I suppose you arigo and me will work on rtyper/ translator/c

[20:12] <stakkars> yes

[20:13] <pedronis> and whatever may still be necessary on annotator's side

[20:13] Action: stakkars gradually afk-ing

[20:13] <stakkars> yes

[20:13] <hpk> stakkars: (ot) regarding form-c i am not too sure i can help too much in the next days

[20:14] <stakkars> hpk: it wasnot about help,but when we need todo it, when it is due, if Goebel is supposedtodo it etc.

[20:15] <stakkars> hpk: and what about money, when do we receive some,again

[20:15] <hpk> stakkars: at my company Lene is doing all this

[20:16] <hpk> stakkars: next prepayments are due after a proper form-c is submitted like stephan wrote

[20:16] <stakkars> hpk: so this one payment was it for the first half year?

[20:18] <stakkars> hpk: are we talking about this at the meeting next wednesday, or am I supposed to have it ready be then?

[20:18] <hpk> stakkars: ready by then

[20:18] <hpk> stakkars: that's real work not just a by-product of adding some numbers

[20:19] <hpk> stakkars: yes, the first payment was for the first half year

[20:19] <hpk> stakkars: let's go to pypy-funding

[20:19] <pedronis> stakkars: the meeting is on friday

[20:19] <stakkars> waah

[20:21] <stakkars> pedronis: next friday as I remember

[20:21] <pedronis> stakkars: Next meeting: 050603 15:00 #pypy-funding.

[20:21] <pedronis> yes

[20:21] <stakkars> puuh

[20:21] <cfbolz> re flow graph interpreter: ok, I'll leave it as an easy introductory task

[20:27] <stakkars> already running?

[20:28] <stakkars> (left as an exercise to the reader :-) )

[20:29] <cfbolz> (exactly :-) )

[20:30] Action: stakkars afk, step parents alert

[20:31] Action: pedronis leaving the office, back later or on late monday

[20:31] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"

[20:34] <cfbolz> I'm going home too -- see you all.

[20:34] <arigo> bye

[20:35] cfbolz (cfbolz@edv01.physi.uni-heidelberg.de) left #pypy ("Leaving").

----- silence for 1 hr and 3 minutes -----

[21:38] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.

[21:38] arre (~ac@1-1-5-33a.gfa.gbg.bostream.se) left irc: "using sirc version 2.211+KSIRC/1.3.11"

[21:41] <aleale> hi

[21:43] <aleale> Is it ok to commit the _codecs.py ( and friends)

[21:44] <aleale> pypy/py.test has no failures (only skipped tests)

[21:45] <aleale> I haven't been able to run the regressiontests in lib-python

[21:45] <arigo> hi

[21:45] <aleale> (by the way should I file an issue to make conftest.py work on windows)

[21:46] <aleale> arigo: hi

[21:46] <arigo> aleale: yes, I guess it needs an issue

[21:46] <arigo> the latest version of _codecs.py is the inprogress__codecs.py?

[21:48] <aleale> yes, but since the unicode branch was merged I have been working on correcting the errors, and made it work with unicode

[21:48] <aleale> So I guess I am asking to change inprogress__codecs to _codecs

[21:49] <arigo> I guess it would be nice to have an idea of how it affects the libpython tests

[21:49] <arigo> is it possible to check into inprogress__codecs?

[21:50] <aleale> yes I could do that

[21:50] <arigo> e.g. have the complete _codecs ready, but off by default -- and then I can rename it locally and run all the tests, for example

[21:50] <aleale> good idea

[21:52] <aleale> I have a initialisation problem - I need to import encodings to get a search function registered

[21:52] <aleale> I have solved this by having a modified codecs.py in lib

[21:53] <aleale> ( it has to be in lib since that is were geninterlevel thinks things are)

[21:54] <aleale> the only modification is a import of encodings.

[21:54] <arigo> but codecs.py starts by importing _codecs?

[21:55] <arigo> would this be a circular import problem if you imported encodings from _codecs?

[21:56] <aleale> I could try . but encodings imports codecs

[21:56] <arigo> ah, so you import encodings from the *end* of codecs.py, I guess

[21:57] <aleale> The only place were _codecs is imported is in codecs

[21:57] <aleale> yes

[21:57] <arigo> in CPython, where is encodings imported from?

[21:58] <aleale> I havent found out

[22:00] <aleale> codecs.c in _PyCodecRegistry_Init

[22:01] <aleale> or the other way around

[22:01] <aleale> It checks if a search function is registered. if not import encodings

[22:02] Nick change: hpk -> hpk_away

[22:02] <aleale> another possible problem is that I am using module level variables for the registry

[22:03] <aleale> In CPython the registry is an attribute of the interpreter

[22:06] <arigo> Python/codecs.c

[22:07] <arigo> ah, encodings are imported in a lazy way when one the functions of Python/codecs.c is called

[22:07] <arigo> basically when _codecs.register() or _codecs.lookup() is first called, then 'encodings' is imported

[22:07] <arigo> in any case, putting codecs.py in lib/ is a problem; having geninterp see codecs.py at all is probably not a good idea

[22:07] <arigo> ah, codec_search_path and friends

[22:07] <arigo> I guess _codecs is not meant to be used directly

[22:07] <arigo> so it shouldn't be a problem

[22:09] <aleale> it gets geninterp'ed by unicode_encode__Unicode_ANY_ANY = app.interphook('unicode_encode__Unicode_ANY_ANY')

[22:10] <aleale> in std/unicodeobject.py

[22:11] <aleale> if codecs isnt in lib geninterplevel gets it from python23/lib

[22:12] <aleale> but maybe I can do as Cpython and import encodings lazily

[22:12] <aleale> will try that thanks

[22:12] <aleale> gotta go for half an hour - see you

[22:13] <arigo> see you

[22:21] <arigo> aleale: the rules about 'import' in applevel snippets like unicode_encode__Unicode_ANY_ANY have changed just before the PyPy 0.6 release

[22:21] <arigo> aleale: if you tried before that date, you should try again,

[22:21] <arigo> aleale: because (I'm not sure at all but I think that) the 'import codecs' in there should now not be seen by geninterp at all

[22:22] <arigo> aleale: and it should just import codecs at app-level using the usual rules from libpython/modified-2.3.4.

[22:23] <aleale> I am working a fresh check out - just dicovered it yesterday

[22:24] <aleale> I regularly delete _cache

[22:30] <aleale> in geninterplevel.py line 419-429 is the template for importing and only pypy/lib is added to the path

[22:30] <arigo> aleale: yes, but this is only if the import statement is at the global level in the app helper

[22:31] <arigo> in this case, it is "hidden" inside the unicode_encode__xxx function

[22:31] <arigo> I tried to put a buggy libpython/modified-2.3.4/codecs.py, and indeed it crashes when do try you'.encode()

[22:33] <aleale> odd - I found this template in _cache and it looked like it came from python23/lib/codecs.py

[22:34] <aleale> anyway I will try to incorporate the lazy import of encodings in _codecs

[22:35] <aleale> what is your take on module level vars for the registry ?

[22:35] <arigo> no problem about them, _codecs is an "internal module"

[22:35] <aleale> cool

----- silence for 25 minutes -----

[23:00] ericvrp (~chatzilla@ericvrp.demon.nl) left irc: "Chatzilla 0.9.68.3 [Firefox 1.0.4/20050516]"

[23:01] ericvrp (~chatzilla@ericvrp.demon.nl) joined #pypy.

----- silence for 25 minutes -----

[23:26] <aleale> svn is down I think

[23:36] yuuh (~yuuhu@dsl-62-220-11-192.berlikomm.net) left irc: "utz utz utz"

[23:40] Action: arigo does recoversvn

[23:41] <arigo> aleale: done

[23:49] <aleale> did my checkin of inprogress__codecs go in ? I didnt get an email

[23:50] <arigo> aleale: yes, I see two of them

[23:51] <aleale> ok good

[00:00] --- Thu May 26 2005