[00:13] nik_ (n=chatzill@21.206.78.83.cust.bluewin.ch) left irc: "zzzz"
[00:25] vruz (n=vruz@r200-40-206-118.adsl.anteldata.net.uy) left irc: Read error: 104 (Connection reset by peer)
[00:25] <lac> nik_ yes
[00:25] <lac> what do I do with this great cheese?
[00:26] <cfbolz> he's already gone again
[00:29] vruz (n=vruz@r200-40-206-118.adsl.anteldata.net.uy) joined #pypy.
[00:37] _hannes (n=yuuhu@i577B64ED.versanet.de) left irc: "utz utz utz"
[00:51] cfbolz (n=cfbolz@p54ABA38D.dip0.t-ipconnect.de) left irc: "Leaving"
[00:53] <sabi> hrm, my attempt to call warnings.warn from applevel code is failing to translate
[00:54] <sabi> [translation:ERROR] v0 = getattr((module sys), ('_getframe'))
[00:54] <sabi> maybe i should use warn_explicit?
[00:56] <sabi> this code shouldn't be translating anyway, it's marked as suggested_primitive = True. grr.
[01:06] <sabi> i guess this makes some sense, since it needs to figure out the return value of these functions...
[01:08] Action: sabi tries more ways to hide this code from the translator
[01:19] Action: sabi gives up and comments it out for now
----- silence for 16 minutes ----- [01:35] Shoragan (n=shoragan@d072.apm.etc.tu-bs.de) left irc: "Leaving"
[01:39] <lac> sabi: where are you?
[01:39] <sabi> urbana, illinois, usa
[01:41] Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) left irc: "It's just a flesh wound. | Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html";
[01:47] <lac> aha. so its not too too late for you
[01:48] <sabi> no, only about 7pm
[01:48] <sabi> i wish i could adjust my schedule to keep european hours :)
[01:51] <sabi> ah, i figured out my problem, missing entry in extfunctable.py
[01:58] <sabi> gah, that doesn't seem to work for the ll_* functions, just module functions
----- silence for 17 minutes ----- [02:15] <sabi> i can't figure out what i'm doing wrong here, i added a new module to pypy/module and it doesn't let me import it.
[02:16] Action: sabi sighs.
[02:19] <sabi> guess everyone is asleep :)
[02:19] <vruz> :-)
[02:20] Action: vruz is 4 hours from IL timezone, he's just not python/pypy literate enough
[02:21] <sabi> heh, np
[02:29] stakkars (i=ufazeof@i577B64ED.versanet.de) left irc: Read error: 110 (Connection timed out)
----- silence for 21 minutes ----- [02:50] <lac> sabi: you there?
[02:51] <sabi> lac: yes
[02:51] <lac> sabi:most likely you are not doing anything wrong
[02:51] <sabi> oh, fun :/
[02:51] <lac> the actual thing of imporint is hard
[02:52] <sabi> yeah it seems like it, i notice that when i do 'import sys' for example it is nowhere on sys.path
[02:52] <sabi> but yet sys.__file__ shows up in pypy.module
[02:52] <sabi> i bet the problem is nobody ever tried to implement modules in pypy that don't exist in CPython
[02:53] <lac> I would not take the other side of that bet
[02:53] <sabi> :)
[02:53] <lac> because I am pretty sure we did not
[02:53] <lac> also I am sure that when I read the code
[02:53] <sabi> where is this code?
[02:53] <lac> there is no obvious test for
[02:54] <lac> did thisexist before
[02:54] <sabi> the other problem was in extfunctable.py, when i attempted to do "import foo" but of course foo is not on the path in that case
[02:54] <lac> we have no ch
[02:54] <sabi> although i guess i could implement a dummy module in CPython
[02:54] <sabi> (or actually a functional one)
[02:54] <lac> that should be ok if foo is a cpythoingf module
[02:54] <lac> you must understand it is 300 here
[02:55] <sabi> yes, i was just planning on going home and asking again in the morning :)
[02:55] <lac> I am feeling glee to figire
[02:55] <sabi> hehe
[02:55] <lac> aha. this is a problem with w module that is not known
[02:56] <lac> can you renamae it to something you are not likely to ever want
[02:56] <sabi> an existing module name?
[02:56] <lac> yes
[02:56] <lac> but I rhink, no
[02:56] <sabi> haha, neat trick. sure i can do that for now, this code is never going to see external use :)
[02:56] <lac> wroing methods,
[02:56] <sabi> oh, good point
[02:56] <lac> w2ill make code go to hell but ould be nice test
[02:56] <sabi> what are you typing on? :)
[02:57] <lac> my laptop is a 1bm thinkpad x40
[02:57] <sabi> hrm, those laptops have nice keyboards
[02:57] <sabi> i don't know what the problem is :)
[02:57] <sabi> a bit small i guess
[02:58] <lac> i tnink i know what it ism but i am too trired to look more,
[02:58] <sabi> anyway thanks for the help, i will try creating a CPython module with the same name
[02:58] <sabi> i don't mean to keep you up
[02:58] <lac> and better experts awake in 4hours
[02:58] <sabi> i'll be asleep in 4 hours, of course :)
[02:58] <lac> see if it loads
[02:58] Action: sabi trise
[02:58] <lac> if loads, reportsthat as aproble,
[02:59] <lac> I thinbk we only can load things we expect, that is shameful
[03:00] <lac> but i need to sleep now, type badly but was in an irc meeting until 0300 my time,
[03:00] <lac> ie ver soon ago
[03:01] <sabi> if i put it in site-packages/ it seems it loads my module
[03:01] <sabi> i.e. the wrong one
[03:03] <sabi> oops, nevermind, i forgot to remove pyc
[03:04] <sabi> no, it doesn't import at all if it is a pure-python module
[03:04] <sabi> i might have to create a dummy extension module
[03:04] <sabi> but i'll do that tomorrow. :)
[03:06] hpk (n=hpk@200-140-204-123.ctame7004.dsl.brasiltelecom.net.br) left irc: "This computer has gone to sleep"
[03:18] Action: lac is away: sleeps late
----- silence for 30 minutes ----- [03:48] braintone (n=brainton@merlinux.de) left irc: Remote closed the connection
[03:48] braintone (n=brainton@merlinux.de) joined #pypy.
[03:52] braintone (n=brainton@merlinux.de) left irc: Remote closed the connection
[03:53] braintone (n=brainton@merlinux.de) joined #pypy.
----- silence for 2 hr and 24 minutes ----- [06:17] braintone (n=brainton@merlinux.de) left irc: Remote closed the connection
[06:17] braintone (n=brainton@merlinux.de) joined #pypy.
----- silence for 1 hr and 26 minutes ----- [07:43] Shoragan (n=shoragan@d072.apm.etc.tu-bs.de) joined #pypy.
----- silence for 23 minutes ----- [08:06] Gromit (n=klix@does-d9b90aec.pool.mediaWays.net) joined #pypy.
----- silence for 27 minutes ----- [08:33] arigo (n=arigo@c-188b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[08:43] stakkars (i=ypkizv@i577B426C.versanet.de) joined #pypy.
[08:45] adim (n=adim@logilab.net2.nerim.net) joined #pypy.
[08:45] <adim> Hi everyone
[08:47] <stakkars> hi all
[08:47] <arigo> good morning
[08:47] <adim> arigo: will you have some time to help me ? (I guess 10 minutes should be enough for you :) )
[08:47] <stakkars> arigo: did you have a little rest, hopefully?
[08:52] <arigo> stakkars: yes, for once I'm not that much tired after the sprint
[08:52] <arigo> adim: sure
[08:53] <stakkars> arigo: during the sprint, I worried about you a bit
[08:54] ericvrp (n=eric@ericvrp.demon.nl) joined #pypy.
[08:56] <arigo> stakkars: I was very tired for some periods of time between the Paris and Gothenburg sprints
[08:56] <adim> ericvrp: Goede dag !
[08:56] <arigo> :-)
[08:57] <ericvrp> adin: heel goed! voor jou ook een goede dag
[08:57] <ericvrp> :)
[08:57] <adim> ericvrp: of course
[08:57] <adim> :)
[08:58] <stakkars> arigo: just let's keep an eye on it. I've seen people burning out, before
[08:58] <adim> arigo: Is Samuele feeling a bit better ?
[08:59] <stakkars> quoting Samuele: "There is more danger to a programmer than being hit by a bus" ;-)
[09:00] <adim> :)
[09:02] <arigo> :-)
[09:02] <arigo> Samuele is getting better, yes
[09:02] <adim> great
[09:03] <ericvrp> glad to hear that
[09:05] <stakkars> arigo: I got the coroutines right, in the train. they are 10 lines, now.
[09:05] <arigo> ah, I knew 5 lines was too short :-)
[09:05] <stakkars> dealing with continuations had somehow vanished from by brain. Now it is dirt simple, again
[09:06] <arigo> how does it look like?
[09:06] <stakkars> well, the point is that you need to store the new continuation in the coro that you leave.
[09:06] <arigo> yes
[09:06] <stakkars> a global current coroutine, which represents the running stuff
[09:07] <stakkars> wehn we switch, this gets frozen, and the continuation of the switching is stored there, while the one of the target coro is Nulled.
[09:08] <stakkars> need to talk to Richard, his resumable is not only a bit too big, the "caller" part is actually wrong.
[09:08] <stakkars> nice thing is that this is much less than a tasklet, and even less than a greenlet.
[09:09] <stakkars> so I can derive them, both.
[09:09] <adim> arigo: Can I connect to the snake server to try and compile pypy ?
[09:09] <stakkars> no time for finishing today, will do that tomorrow between flights.
[09:09] <arigo> adim: sure
[09:09] <adim> arigo: ok, now the question is : what is the server full address ? :)
[09:10] <adim> snake.xxx.yyy ?
[09:12] <arigo> I recommend to start the translation in a "screen -S adim/adim" session
[09:12] <arigo> this way not only can log off for a while, but I can also have a look at the crash :-)
[09:12] <adim> arigo: sure :)
----- silence for 22 minutes ----- [09:34] aleale (n=andersle@83.72.68.168.ip.tele2adsl.dk) joined #pypy.
----- silence for 23 minutes ----- [09:57] <adim> arigo: pypy translation (session is adim/adim) should crash in a few seconds now :)
[09:58] <adim> done
[09:59] <arigo> it's still the same problem
[10:00] <arigo> there is a missing 'assert isinstance(_, Node)'
[10:00] <arigo> the attributes of Node escape up to Wrappable
[10:00] <adim> arigo: yes, but it seems that I fixed all of them
[10:00] <arigo> well, let's go hunting :-)
[10:00] <adim> ok
[10:00] <adim> you first :)
[10:01] <stakkars> commenting out larger parts has helpedme quite much with this
[10:04] <arigo> note that descr_Node_new() will not automatically instantiate subclasses of Node
[10:05] <arigo> this will always create instances of either exactly Node or internal auto-generated subclasses like UserWithSlotsNode
[10:05] <arigo> but not FunctionNode etc.
[10:05] <adim> arigo: each Node's subclass has its specific descr_new method
[10:05] <arigo> ah
[10:05] <adim> except 2 or 3 which are not used
[10:06] <arigo> I see, sorry
[10:06] <adim> no pb
[10:12] arre (i=ac@kourier.strakt.com) joined #pypy.
[10:13] _hannes (n=yuuhu@i577B426C.versanet.de) joined #pypy.
[10:16] Action: arigo bangs graphviz on the head
[10:18] <arigo> argh
[10:18] <arigo> you can't have a graph called "Node" in dot because "node" is a keyword
[10:18] <adim> :)
[10:26] <adim> hmm
[10:27] arre (i=ac@kourier.strakt.com) left irc: Read error: 104 (Connection reset by peer)
[10:28] arre (i=ac@kourier.strakt.com) joined #pypy.
[10:29] <adim> arigo: is there a way for me to see the graph ?
[10:29] <arigo> yes, but these flowg and showg commands don't work very well
[10:29] <arigo> I have to keep connecting/disconnecting for them to control my viewer
[10:30] <adim> I see
[10:30] <arigo> I don't know how a second viewer interacts with this
[10:30] <arigo> otherwise, it would be pypy/bin/dotviewer.py
[10:39] <arigo> adim: found it
[10:39] <arigo> it's CallFunc.fset_args()
[10:40] <adim> huh
[10:40] <adim> it's not mine :)
[10:40] <arigo> well, it's not mine either :-)
[10:41] <adim> ok, got it
[10:41] <adim> I'll track missing isinstance() in those functions
[10:41] <adim> thank you
[10:41] <arigo> hum, indeed, most of them seem to be in the same situation
[10:41] <arigo> you're welcome
[10:41] <adim> *very* mich
[10:41] <adim> much
[10:42] <arigo> hum
[10:42] <arigo> I *really* think we should change space.interclass_w
[10:42] <adim> accepting a "expecting" arugment
[10:42] <arigo> yes
[10:43] <adim> would result in nicer code :)
[10:43] <arigo> yes, and also the checking done in ast.py is slightly wrong
[10:43] <adim> ah ?
[10:43] <arigo> if the user passes a non-interpreter-internal object like an integer, interpclass_w() returns None
[10:43] <adim> I see
[10:43] <arigo> which should result in an app-level TypeError, but is ignored
[10:43] <arigo> is there a case where you would like to accept an app-level None ?
[10:44] <adim> there are somes
[10:44] <adim> like While's else_ attribute for instance
[10:44] <arigo> maybe we can add space.interpclassorNone_w()...
[10:45] <adim> I can still make a space.is_w(w_else_, space.w_None) before
[10:45] <arigo> I suppose so, but maybe it's useful to have a helper anyway
[10:47] <adim> Why doesn't interpclass_w raise a TypeError when the object passed is not a Wrappable ?
[10:48] <arigo> indeed
[10:48] <arigo> but there are a few places that rely on this
[10:49] <arigo> where interpclass_w is used only to check if the object is, say, a Function, and ignore other cases
[10:49] <adim> I see
[10:49] braintone (n=brainton@merlinux.de) left irc: Remote closed the connection
[10:49] braintone (n=brainton@merlinux.de) joined #pypy.
[10:52] <arigo> does it make sense to add the helper on snake in your WC?
[10:53] <adim> WC means ?
[10:53] <arigo> working copy
[10:54] <adim> oh, well, why not ?
[10:54] <arigo> space.interp_w(Class, w_obj) ?
[10:54] <arigo> space.interp_w(Class, w_obj, can_be_None=False) ?
[10:55] <adim> second one seems better
[10:55] <arigo> it needs to be specialized on the Class argument
[10:55] Action: arigo tries to remember if there is a problem with specialization and default arguments
[10:55] <arigo> probably not in the somepbc-branch refactoring
[10:57] <arigo> indeed, it works.
[11:09] hpk (n=hpk@200-140-204-123.ctame7004.dsl.brasiltelecom.net.br) joined #pypy.
[11:13] <braintone> rxe - r21121 - API change. Now Resumable is longer (!) as it also includes the function. Funny how inheritance seems so much more useful in a static language. :-)
[11:13] <arigo> adim: ok to check this in?
[11:14] <adim> yop
[11:15] <arigo> your terminal is reeeally large :-)
[11:15] <adim> :)
[11:15] rxe (n=rxe@host-n4-53.homerun.telia.com) joined #pypy.
[11:15] <adim> fullscreen :)
[11:15] <rxe> Hi!
[11:15] <braintone> adim - r21122 - (adim, arigo) A helper space.interp_w() with proper type checking.
[11:15] <arigo> hi Richard!
[11:15] <adim> Hi Richard
[11:16] <adim> arigo: thanks for the tutorial
[11:16] <arigo> :-)
[11:16] <arigo> I'll convert a few interpclass_w() to interp_w()
[11:16] <arigo> in the meantime I hope I didn't break translation :-)
[11:16] <adim> well, you could still claim it's my fault then :)
[11:16] <rxe> stakkars: you still there?
[11:17] cfbolz (n=cfbolz@p54ABA038.dip0.t-ipconnect.de) joined #pypy.
[11:17] <mwh> morning
[11:17] <hpk> morning
[11:17] <arigo> morning!
[11:17] <adim> morning
[11:17] <rxe> morning!!
[11:18] <rxe> stakkars: checking in a version without caller on Resumable... is that what you mean?
[11:19] <rxe> I am not too sure why you think the other version was wrong - depends on the sense of wrong? :-)
[11:20] <braintone> rxe - r21123 - Move caller out to a global - as I am guessing there will only ever be on per thread?
[11:20] <rxe> one per thread
[11:21] <mwh> wow, that's a big response :)
[11:22] <cfbolz> rxe: where are you now?
[11:22] <stakkars> rxe: Hi! Not urgent, I'm still playing.
[11:22] <rxe> Gothenborg... leave tomorrow... was hoping to go to directly to London for interview
[11:23] <cfbolz> rxe: cool
[11:23] <cfbolz> interview?
[11:23] <stakkars> I just looked more closely and found out that the caller,as it is, is not really as you think
[11:24] <stakkars> by assigning it once on initialization time, you freeze an old version of the caller (which is your scheduler)
[11:24] <rxe> cfbolz: visa thingy
[11:24] <hpk> rxe: i also wanted to get a visa-card lately ... please ask them :)
[11:24] <stakkars> this works just by chance, because you are sitting in a scheduler loop and the continuation is always the same.
[11:24] <cfbolz> rxe: an american visa, not a visa card, right?:
[11:25] <stakkars> actually a real caller is not a continuation, but the coroutine which holds it and gets updated.
[11:25] <rxe> hpk: will do - wish you just get a global pass anywhere :-)
[11:25] <hpk> rxe: indeed, plus world wide GPRS-internet access - flatrate
[11:26] <cfbolz> yes, that would be cool :-)
[11:26] <rxe> :-)
[11:26] Action: hpk is currently trying to get brazil-wide grps-flatrate so we can move around the country-side some more :)
[11:26] <cfbolz> does it work?
[11:27] <hpk> yes, latency time is horrible (700 milliseconds) but it basically works, just a contract/paperwork issue by now
[11:27] <hpk> "just"
[11:27] <cfbolz> latency on the ferry was similar
[11:27] <cfbolz> I figure you won't play any online games then
[11:27] <hpk> so we will need to revisit the shped/remote-working tool front some time soon :)
[11:28] <hpk> well, i play IRC regularly
[11:28] <rxe> stakkars: well yes - Resumables arent suppose to coroutines, they were just to help my way of switching back and forth to scheduler
[11:29] Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) joined #pypy.
[11:29] <cfbolz> hpk: yes, but there the latency is just about bearable
[11:30] <stakkars> rxe: sure, and I got no time for a closer look. I just wanted to point out that regardless the design, if you something.switch(),
[11:30] <stakkars> then the point where you re-enter receives the continuation of the caller. And the code there must make
[11:31] <stakkars> sure that this continuation is placed into the coroutine you left. Updating "yourself" is only correct by chance.
[11:31] <stakkars> happens to work for you, because you always jump forth and back between one schedule and some tasklet.
[11:32] <stakkars> I will check in a minimal implementation with very detailed comments, tomorrow between flights.
[11:33] <stakkars> will build the rest on top of it. This can also serve as an in-depth introduction how things work, for the web site.
[11:33] <rxe> I think "by chance" is unfair, as that was what it is was suppose to do. :-) But a lighter weight mechanism is most welcome to build on top of.
[11:34] <stakkars> I don't intend to be unfair :-)
[11:34] <stakkars> I just looked at it verylong, until I realized that it only works when it is used as it is used.
[11:34] <rxe> I guess Resumables should never of been abstracted out, as they give the impression of something more.
[11:35] <rxe> Look forward to seeing the lighter approach... can you check something in?
[11:35] <stakkars> as said, not today, very busy.
[11:36] <rxe> ok - I am travelling anyways next few days. :-)
[11:36] <stakkars> you know how hard it was for me, because I lost this. Yesterday, this memory came back all at a sudden
[11:37] <cfbolz> stakkars: where are you flying to?
[11:37] <stakkars> Iceland
[11:38] <cfbolz> cool
[11:39] <stakkars> indeed. needlong undertrousers
[11:39] <cfbolz> :-)
[11:40] <arigo> adim: by the way, pypy.module.recparser.pyparser.descr_*_getitem/setitem/delitem()
[11:40] <arigo> are a bit dangerous, because they don't check if the index is within bounds
[11:42] <stakkars> rxe: in scheduler, thereis exactly one switching point, which says:
[11:42] <stakkars> if t.resume():
[11:42] <stakkars> self.runnables.append(self.current_tasklet)
[11:43] <stakkars> this is the point where all resumables return to.
[11:43] <rxe> Indeed
[11:43] <stakkars> If there was more than one such place (which is absolutely possible in a different implementation),
[11:43] <adim> arigo: noted
[11:44] <stakkars> then we get into trouble, because the resumables return there via this:
[11:44] <stakkars> def suspend(self):
[11:44] <stakkars> # we suspend ourself
[11:44] <stakkars> self.caller = self.caller.switch()
[11:44] <stakkars> this caller is not the current state of the scheduler, but the one that was captured as some time before.
[11:45] <stakkars> this is the time of tasklet creation and does not respect the current history of the scheduler.
[11:45] <stakkars> so it works "by chance" (sorry), because these targets happen to be that single point of return.
[11:46] <stakkars> instead, we should update the caller (scheduler, here) whenever we hump at a resumable. And every resumable would hold a reference to that scheduler object, not just its continuation, which is not fresh.
[11:48] <stakkars> (hard to explain, but crystal clear after reloading a "continuation workspace" :-)
[11:49] <cfbolz> does anybody know or can find out when the berlin sprint was?
[11:49] <rxe> Well I need to take a look at that. It was my impression that switch() returned a new "continuation" so caller was being update... Right now I am need to do some Xmas shopping!
[11:50] <hpk> cfbolz: the one in 2003?
[11:50] <cfbolz> yes
[11:50] <cfbolz> it is not in the graphs :-(
[11:50] <hpk> did you check the archives? (pypy-dev)
[11:50] <cfbolz> nor in our sprint docs
[11:50] <stakkars> you are right, but you need to store it for everybody, whatever jumps at it next time. It can't be kept by one resumable at a time, only
[11:50] <cfbolz> hpk: not yet. which month was it?
[11:51] <hpk> um, something at the end of 2003, october or november i'd guess
[11:51] <cfbolz> ok, I'll check
[11:51] <stakkars> not just "your" caller, but the overll state of the scheduler needs to change. Well, sorry, have fun with XMas shopping! :-)
[11:51] <stakkars> overall
[11:51] <rxe> Well yes - but it was only designed for this purpose - so we are in total agreement! :-)
[11:51] <cfbolz> rxe: don't remind me, I have to do that too...
[11:52] <stakkars> I have no chance this year :-(
[11:52] <rxe> cfbolz: I thought Xmas cards that noone could understand would be fun
[11:52] <cfbolz> rxe: cool idea
[11:53] <stakkars> rxe: I told my wife that you might come along. Do you have an idea when? You're very welcome!
[11:54] <LarstiQ> might I abuse this channel looking for people with python commit access? https://sourceforge.net/tracker/index.php?func=detail&aid=1365916&group_id=5470&atid=305470 has been lingering in the patch tracker
[11:54] <rxe> stakkars: thanks! :-) Cant be sure when, my life is largely revolving around the visa issue right now
[11:55] <rxe> Bye!
[11:55] <hpk> rxe: bye!
[11:55] rxe (n=rxe@host-n4-53.homerun.telia.com) left #pypy.
[11:58] <cfbolz> LarstiQ: won't help you much, I fear. mwh is still gone and I doubt that armin has time :-)
[11:59] <hpk> in general the answer is "no", i guess, but you might be lucky sometimes
[11:59] <LarstiQ> cfbolz: seeing as how it's been there for 20 days, waiting a bit longer won't hurt that much
[11:59] <LarstiQ> hpk: any suggestions on other ways to approach this?
[12:01] <hpk> review patches yourself - add comments - and then get back to cpython-develoeprs, i think Martin van Loewis once said that if someone reviews 5 patches he can require a review from him or something like that
[12:01] <cfbolz> yes, that rule exists
[12:01] <cfbolz> not only martin does it, I think
[12:01] <cfbolz> (but might be wrong)
[12:05] <arigo> well, the rule is more about larger patches that add some functionality
[12:05] <arigo> in this case, it's a small bug fix
[12:05] <arigo> it's just sad that core Python developers don't follow up too closely, even on such obvious trivial fixes
[12:05] Action: arigo adds a comment on the SF tracker
[12:06] <LarstiQ> arigo: thanks
[12:06] <cfbolz> arigo: I did not really look at it
[12:06] <LarstiQ> hpk: ok, good to know about that
[12:07] <braintone> arigo - r21124 - Try to propagate non-concrete constants, until they merge.
[12:07] <braintone> arigo - r21125 - Use the new space.interp_w() instead of space.interpclass_w() where it makes sense to do so.
[12:08] <LarstiQ> arigo: fwiw, piman is working on a static analysis tool to find similar bugs
[12:08] <arigo> the joys of C :-)
[12:09] <cfbolz> so glad we don't have to put up with that :-)
[12:10] Action: stakkars afk, python course (giving, not taking)
[12:10] sanxiyn (n=tinuviel@211.104.100.240) joined #pypy.
[12:13] Gromit (n=klix@does-d9b90aec.pool.mediaWays.net) left irc: Read error: 113 (No route to host)
[12:14] <braintone> cfbolz - r21126 - fix off by one error in mailing list data
[12:14] Gromit (n=klix@does-d9b91935.pool.mediaWays.net) joined #pypy.
[12:15] <sanxiyn> sabi: There?
[12:18] <cfbolz> could somebody of the long-timers look at http://codespeak.net/~cfbolz/plots/post.png to see whether I am still missing sprints?
[12:18] <sanxiyn> sabi: If you're adding stuffs to pypy/module, you need to modify get_builtinmodule_to_install in baseobjspace.py.
[12:18] <sanxiyn> I think.
[12:19] <cfbolz> he might also be missing a proper __init__
[12:19] <sanxiyn> (That was re: [02:15] <sabi> i can't figure out what i'm doing wrong here, i added a new module to pypy/module and it doesn't let me import it.)
[12:19] <cfbolz> (maybe he really wants a pure applevel-module in which case he should put it to lib, I think)
[12:20] <sanxiyn> I doubt that... he mentions sys.__file__.
[12:20] <sanxiyn> (Well, that doesn't prove any...)
[12:21] <sanxiyn> cfbolz: Is --usemodules simpler?
[12:21] <sanxiyn> maybe.
[12:21] <cfbolz> simpler than what?
[12:22] Action: sanxiyn tries some test
[12:27] <sanxiyn> cfbolz: Simpler than modifying baseobjspace.py.
[12:27] <cfbolz> ah
[12:27] Action: sanxiyn created "xyzzy" mixedmodule and confirmed it working with --usemodules=xyzzy
[12:28] <cfbolz> yep, that works
[12:39] _hannes (n=yuuhu@i577B426C.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[12:40] <cfbolz> sanxiyn: all this is related to the problem that we don't really support adding mixed modules on the fly -- everything needs to be compiled in at the moment
[12:40] <sanxiyn> Yes.
[12:41] <cfbolz> although changing this is probably a really big task
[12:41] <sanxiyn> I wonder what sabi is doing with PyPy. Any idea?
[12:42] <sanxiyn> Anyway, I cooked up "minimal mixedmodule example" here: http://sparcs.kaist.ac.kr/~tinuviel/pypy/diff/example.diff
[12:42] <sanxiyn> Eh, decrease doesn't decrease. fixed.
[12:48] <sanxiyn> cfbolz: btw, I don't see any sprint missing in the plot, if my opinion is anything.
[12:48] <cfbolz> sanxiyn: yes, thanks (you were longer around than I am, so it counts :-)
[12:49] Action: sanxiyn was around for a long time, without doing much. :-)
[12:51] <sanxiyn> bye
[12:51] sanxiyn (n=tinuviel@211.104.100.240) left irc: "Bye"
[12:59] <braintone> arigo - r21127 - More on eager constant propagation: don't be too eager :-) This fixes the merging detection, and adds a second phase after a graph is complete to "compactify" it by linking blocks for old states direc
[13:04] Action: arigo tries to make a factorial function in Toy Language
[13:04] <cfbolz> :-)
[13:04] <cfbolz> arigo: do you have a few minutes?
[13:04] <ericvrp> arigo: having fun?
[13:04] <arigo> anybody did HP48 programming recently? :-)
[13:04] <arigo> cfbolz: as soon as I get this straight :-)
[13:05] <cfbolz> ok
[13:07] <arigo> good, now let me run the JIT on that...
[13:08] <cfbolz> just tell me when it's conventient
[13:09] <arigo> argh!
[13:09] <arigo> it works too well
[13:09] <cfbolz> in what sense?
[13:09] <arigo> it turns into "return 5040"
[13:10] <idnar> heh
[13:10] <cfbolz> hahaha
[13:10] <arigo> it should not unroll the loops in the TL bytecode...
[13:15] <cfbolz> quite impressive, actually
[13:19] <arigo> not an easy fix :-(
[13:19] <cfbolz> indeed
[13:20] <arigo> what did you want to ask?
[13:21] <cfbolz> well, it seems that boehm does not support weakrefs
[13:21] <cfbolz> the docs propose to use an ~pointer and register a finalizer
[13:22] <cfbolz> so we are back to square -1
[13:22] <arigo> are we?
[13:22] <cfbolz> are we not?
[13:22] <cfbolz> :-)
[13:25] <cfbolz> we cannot easily add a finalizer to an object later, because it might have one from __del__ already
[13:25] <cfbolz> or am I missing something really obvious
[13:26] <arigo> no, but we can "uneasily" add such a finalizer later
[13:26] <Gromit> cfbolz: can't you query the object for an existing finalizer?
[13:26] <arigo> it's mostly a matter of replacing whatever finalizer is already there with a new one, which can handle both weakrefs and __del__
[13:26] <cfbolz> ah right
[13:26] <cfbolz> and for refcounting"
[13:26] <cfbolz> ?
[13:27] <arigo> well, for refcounting we can go the CPython way
[13:27] <cfbolz> so we need a module that knows about the gc that is used
[13:27] <cfbolz> fun
[13:28] <arigo> maybe we can find a way to express it so that only the back-end has to care about the difference
[13:28] <cfbolz> yes, I hope so. need to think about it a bit more
[13:37] <braintone> cfbolz - r21128 - add script to rebin data
[13:41] <arigo> adim: interp_w() solved the warnings (both in your working copy and in the current HEAD), but indeed the problem is still there. I'm investigating more...
[13:50] <adim> arigo: I'm back
[13:51] <arigo> the screen window appears to have crashed
[13:51] <arigo> ah? working againback
[13:52] <xorAxAx> XON/XOFF? :-)
[13:52] <arigo> no, I thought about that
[13:54] <adim> arigo: Btw, the problem is not *strictly* the same, but it looks quite similar
[14:00] <arigo> hum, it appears to me more specialize:memo fun...
[14:02] <cfbolz> arigo: where does your nifty ssh mounting stuff live?
[14:02] <mwh> aaaaaaaaaargh
[14:03] <cfbolz> good morning michael!
[14:03] <arigo> cfbolz: http://codespeak.net/svn/user/arigo/hack/pylufs/
[14:03] <arigo> mwh: indeed!
[14:03] <cfbolz> thanks
[14:04] <arigo> (cfbolz: I just checked in some old changes I have in my working copy)
[14:04] <cfbolz> cool. I will try to use it a bit
[14:08] aleale (n=andersle@83.72.68.168.ip.tele2adsl.dk) left irc: Read error: 110 (Connection timed out)
[14:23] <mwh> instead of worrying about specialize:memo, i'm going to go and talk to my bank
[14:29] <arigo> good plan
----- silence for 27 minutes ----- [14:56] arigo (n=arigo@c-188b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[15:03] rhymes (n=rhymes@host72-75.pool8254.interbusiness.it) joined #pypy.
----- silence for 1 hr and 10 minutes ----- [16:13] _hannes (i=ore@i577B426C.versanet.de) joined #pypy.
----- silence for 49 minutes ----- [17:02] arre (i=ac@kourier.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[17:06] arigo (n=arigo@c-188b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[17:08] [rhymes] (n=rhymes@host132-14.pool8248.interbusiness.it) joined #pypy.
[17:09] rhymes (n=rhymes@host72-75.pool8254.interbusiness.it) left irc: Nick collision from services.
[17:09] Nick change: [rhymes] -> rhymes
----- silence for 35 minutes ----- [17:44] <arigo> ?
[17:44] <arigo> test_casttoandfromint
[17:44] <arigo> why would cast_object_to_int(a) always return a positive number?
[17:44] <arigo> the test fails on snake
[17:46] <braintone> arigo - r21141 - Replaced the many calls 'Constant(last_exception)' with a prebuilt 'c_last_exception'.
----- silence for 18 minutes ----- [18:04] Gromit_ (n=klix@does-d9b91930.pool.mediaWays.net) joined #pypy.
[18:05] Gromit (n=klix@does-d9b91935.pool.mediaWays.net) left irc: Nick collision from services.
[18:05] Nick change: Gromit_ -> Gromit
----- silence for 30 minutes ----- [18:35] Action: sabi thanks sanxiyn for answering his question while he slept :)
[18:37] <sabi> so --usemodules works for py.py
[18:42] <sabi> but i still need to figure out what to do for translated pypy.
[18:44] <sabi> before i just start hacking, any guidance would be helpful :)
[18:45] <arigo> sabi: there is no cmd-line option, it should probably be added
[18:46] <arigo> in targetpypystandalone, see list 'usemodules'
[18:56] <hpk> there are still hard-coded paths in translated pypy, aren't there? I mean you can not remove the whole tree and just have pypy-c + x somewhere, can you?
[18:56] [rhymes] (n=rhymes@host167-10.pool8250.interbusiness.it) joined #pypy.
[19:01] <cfbolz> hpk: I think you can, but the stdlib doesn't work
[19:01] <cfbolz> duh
[19:01] <cfbolz> that was a contradiction of course
[19:01] <cfbolz> :-)
[19:01] adim (n=adim@logilab.net2.nerim.net) left #pypy.
[19:01] <cfbolz> because code does not work
[19:01] <hpk> :)
[19:03] <cfbolz> when is the eu review again?
[19:03] <hpk> 20th january
[19:04] <hpk> + 19 th review preparation i guess
[19:06] <cfbolz> some preparation would be good, yes :-)
[19:06] rhymes (n=rhymes@host132-14.pool8248.interbusiness.it) left irc: Nick collision from services.
[19:07] Nick change: [rhymes] -> rhymes
[19:08] <sabi> arigo: ah, so i can do something similar
[19:08] Action: sabi will try after lunch, bbiab
----- silence for 38 minutes ----- [19:46] <braintone> arigo - r21143 - Append an underscore to graph name, to avoid collision with the keywords of dot, like 'Node' when we try to see the class ast.Node...
[19:47] <mwh> good evening
[19:48] <cfbolz> was your bank cooperative?
[19:48] <mwh> yes
[19:48] <mwh> i got lost on the way to the town hall and got there too late, so i still have that entertainment tomorrow
[19:49] <cfbolz> what do you want from them?
[19:51] <mwh> i need to tell them my new address, i think
[19:51] <mwh> arigo: i could do with breaking in to your post box
[19:51] <mwh> any ideas? :-)
[19:51] <cfbolz> oh, fun. then you will become a duesseldorf citizen :-)
[19:51] <mwh> i am already!
[19:51] <hpk> dusseldorf
[19:52] <hpk> mwh: hallo
[19:52] <mwh> just allegedly living in the same place as armin
[19:52] <mwh> hpk: guten tag!
[19:52] <cfbolz> mwh: haha
[19:52] <hpk> same room? You will have to step down in 20 years when you are prime minister ...
[19:52] <mwh> which is when i need to break into his postbox, my bank has sent stuff there
[19:53] <mwh> s/when/why/
[19:53] <mwh> hpk: i find this unlikely
[19:55] <arigo> mwh: nothing obvious comes to mind
[19:55] <mwh> no, i know
[19:55] <mwh> it's not that important
[19:56] <braintone> arigo - r21144 - (pedronis, arigo) Yet Another Refacoring of The Memo Mess (tm). There are again two phases, discovery of the possible argument values (at which point the specializer returns the most precise annotatio
[19:59] bima (n=jifuf@adsl-157-192-192-81.adsl.iam.net.ma) joined #pypy.
[20:03] <mwh> anyone for bub-n-bros? :)
[20:03] <cfbolz> don't temp me!
[20:04] <hpk> and they were gone
[20:05] <cfbolz> no, I am not. I am quite deeply into rest stuff right now :-)
[20:10] <dialtone> I'm writing a webtoirc client
[20:10] <dialtone> are you happy guys?
[20:10] <cfbolz> what's webtoirc?
[20:10] <dialtone> http://img175.imageshack.us/img175/1884/irc5vt.jpg
[20:10] <dialtone> this
[20:11] <cfbolz> do you have to much time or something?
[20:11] <sabi> haha
[20:11] <dialtone> cfbolz: it's 60 lines
[20:11] <cfbolz> not 5?
[20:12] <dialtone> http://rafb.net/paste/results/EjWbTi42.html (72 lines of Python)
[20:12] <dialtone> this is all the code
[20:12] <cfbolz> mwh: actually I could really do with a round of b&b
[20:12] bima (n=jifuf@adsl-157-192-192-81.adsl.iam.net.ma) left #pypy.
[20:12] <cfbolz> dialtone: do you want to join too?
[20:13] <mwh> heh
[20:13] <dialtone> nop, I'm going to eat soon
[20:13] <dialtone> :)
[20:13] <cfbolz> damn
[20:13] <mwh> you'll have to host, i'm natted
[20:13] <dialtone> thanks anyway :)
[20:13] <cfbolz> arigo: you, maybe?
[20:13] <cfbolz> mwh: uh, could be a problem for me too
[20:13] <mwh> there's usually a game an ima...
[20:13] <cfbolz> ah
[20:14] <mwh> apparently not right now though
[20:14] <stakkars> arigo: HP48? I was good on that one, loong ago
[20:14] <arigo> stakkars: :-)
[20:14] <cfbolz> what do you need on the server?
[20:15] <stakkars> do you need stack tricks?
[20:16] <arigo> stakkars: no, thanks, I managed to write that factorial function in Toy Language :-)
[20:16] <cfbolz> cool
[20:17] <cfbolz> mwh: so what do we do?
[20:17] <mwh> i'm just playing locally...
[20:18] <cfbolz> which I can't join :-(
[20:18] <mwh> you could try hosting, see what happens
[20:18] <cfbolz> tried it, doesn't work
[20:18] <cfbolz> the server needs plain python only, right?
[20:18] <stakkars> : fac dup 1 > if dup fac * then ;
[20:20] Action: stakkars is not sure if the smudge bit hits me there
[20:20] <arigo> ah, but a non-recursive version...
[20:21] Action: arigo tries to run a server on snake
[20:21] <cfbolz> cool
[20:23] <stakkars> : fac 1 swap 0 swap for i * loop ;
[20:23] <arigo> Client.py snake.cs.uni-duesseldorf.de:8000
[20:24] <mwh> how do i name my snake?
[20:25] <mwh> dragon, even
[20:25] <cfbolz> hehe
[20:25] <arigo> by running through the BubBob.py program
[20:25] <arigo> link "set player names"
[20:26] <mwh> oh WHAT
[20:26] <arigo> :-)
[20:26] <mwh> how on earth did you get that first
[20:26] <arigo> I died...
[20:26] <cfbolz> for some reason it crashes... getting new version
[20:27] <arigo> crashes? how?
[20:27] <cfbolz> I have a 1.3 version
[20:27] <arigo> should work anyway
[20:27] <cfbolz> File "/old/home/cfbolz/source-files/bubbros-1.3/display/caching.py", line 61, in overwrite
[20:27] <cfbolz> print >> sys.stderr, "cache write error:", self.filename
[20:27] <cfbolz> NameError: global name 'sys' is not defined
[20:28] <arigo> hum
[20:28] <arigo> import sys missing...
[20:28] <cfbolz> yep
[20:28] <cfbolz> and it only finds it in some error condition
[20:28] <cfbolz> aha
[20:28] <cfbolz> I cannot write to the dir
[20:28] <arigo> yes, indeed
[20:28] <cfbolz> sec
[20:29] <cfbolz> works
[20:30] <arigo> it kind of lags horribly here
[20:30] <cfbolz> works for me
[20:36] <cfbolz> wua, usb keyboards sucl
[20:36] <cfbolz> suck
[20:40] <mwh> hmm
[20:41] <mwh> i hate this level already
[20:41] <mwh> dialtone: ?
[20:42] <stakkars> maybe using a different channel for gaming would be more apropriate?
[20:42] <cfbolz> sorry
[20:42] <cfbolz> #bub-n-bros?
[20:43] <arigo> yes, it's already used for that purpose :-)
[20:43] <stakkars> just because we're logged.
[20:48] ericvrp (n=eric@ericvrp.demon.nl) left irc: Read error: 110 (Connection timed out)
[20:53] nik_ (n=chatzill@21.206.78.83.cust.bluewin.ch) joined #pypy.
[20:58] <xorAxAx> stakkars: and the EU might punish the team because some are playing and talking about it in the channel? %-)
[21:00] <cfbolz> sure, that happens all the time
[21:00] heatsink (n=heatsink@tongue.crhc.uiuc.edu) joined #pypy.
[21:00] <xorAxAx> hi heatsink
[21:01] <heatsink> hiya.
[21:01] <heatsink> So I just mentioned in the other channel, I've been doing some work on dynamic optimization in CPython.
[21:01] <heatsink> The focus of the project was having complete language compatibility.
[21:02] <heatsink> As far as I know, no one has tried to do both of those at the same time :)
[21:02] <cfbolz> psyco?
[21:02] <heatsink> Psyco makes some assumptions
[21:02] <heatsink> that usually hold
[21:02] <cfbolz> um, no
[21:03] <heatsink> but you can break it by, for example, changing __class__
[21:03] <heatsink> or reassinging fields of type objects
[21:03] <heatsink> or changing the base classes of type objects
[21:05] <heatsink> That's hardly ever done, but still
[21:05] <heatsink> it's something of a barrier to using an optimizing interpeter and trusting it to _just work_.
[21:06] <heatsink> I thought there should be a way to handle such things and still do dynamic optimization... so I designed one.
[21:07] <heatsink> Well, I'm not sure how much people care about the compatibility issue.
[21:08] <heatsink> PyPy for example uses a restricted dialect of Python...
[21:08] <cfbolz> well, we know that much
[21:08] <heatsink> so I'd like to find out whether people think the project is interesting.
[21:08] <stakkars> xorAxAx: no, it's just no fun for interested readers to filter off lots of OT stuff
[21:08] <xorAxAx> stakkars: i agree
[21:09] <xorAxAx> heatsink: do you know brian's work about the attempt of optimising cpython?
[21:09] <heatsink> I don't think so, does the project have a name?
[21:10] <xorAxAx> no, it was a thesis
[21:10] <heatsink> Starkiller?
[21:10] <xorAxAx> and he concluded that python got slower by his work
[21:10] <xorAxAx> no
[21:10] <xorAxAx> he tried to optimise the interpreter cycle
[21:11] <stakkars> a fractal-ish untertaking
[21:11] <heatsink> what?
[21:11] <heatsink> is the thesis online?
[21:11] <xorAxAx> arigo knows the address
[21:11] <stakkars> due to caching and hard-to-foresee assumptions of the optimizer, it is easy to have opposite effects
[21:12] <xorAxAx> i think his biggest problem was trashed cache lines
[21:13] <xorAxAx> and pipelines
[21:13] <heatsink> Instruction cache or data cache?
[21:13] <xorAxAx> no idea, he didnt conclude like that :)
[21:13] <heatsink> oh :)
[21:13] <stakkars> on L2 cache, there is no distinction. On L1, it is.
[21:14] <heatsink> The two optis that I do right now actually reduce the number of dictionary lookups performed by the . operator.
[21:14] <heatsink> It doesn't usually produce a speedup... but it's not just making the interpreter loop faster.
[21:14] <sabi> heatsink: did you post your report anywhere?
[21:15] <heatsink> No... just turned it in to instructor today, actually.
[21:15] <sabi> oh, version i looked at must have been a draft
[21:15] <heatsink> And it does produce a speedup in pystone if the "Record" class is converted to a new-style class.
[21:16] Shoragan (n=shoragan@d072.apm.etc.tu-bs.de) left irc: "Leaving"
[21:18] <hpk> stakkars: i don't think having a bit of not strictly on-topic things here is really so bad - especially if it comes from active developers
[21:19] <arigo> heatsink: any link, or any hint about how you are trying to approach the problem?
[21:19] <arigo> (btw the not-100%-compatibility issues in Psyco can be solved at the expense of a bit of slowdown, but still the basic idea works)
[21:19] <cfbolz> hpk: it was not so bad to go to bub-n-bros. not that this channel is always ontopic
[21:19] <heatsink> arigo: A few things...
[21:19] <hpk> cfbolz: sure
[21:20] <heatsink> First, since modifications to the type system are very rare, assume they don't happen and de-optimize if they do.
[21:21] <heatsink> Second, have a mechanism to record what needs to be deoptimized if each assumption about the type system is violated.
[21:21] <arigo> so far so good
[21:22] <arigo> but what is the start of the approach? you need some basics things working before you can tackle this
[21:22] <heatsink> I don't know what you mean by the "start"
[21:22] <hpk> practically coding-wise
[21:22] <arigo> heatsink: well, how you approach the problem to start with
[21:23] <arigo> is it some kind of static compiler producing guards?
[21:23] <heatsink> Oh
[21:23] <arigo> or is it something like Psyco, or still something else?
[21:23] <hpk> arigo: psyco is following these two strategies as well, isn't it?
[21:23] <arigo> hpk: no
[21:24] <arigo> it's just assuming that some rare modifications don't happen at all
[21:24] <arigo> and crashes if they do
[21:24] <heatsink> We did a dynamic bytecode optimizer, and added new bytecodes to the interpreter that are only produced by the optimizer.
[21:24] <arigo> ah, so extending the CPython interpreter main loop
[21:24] <hpk> arigo: ok, i meant the question not specifically tied to the type system, actually
[21:24] <heatsink> We would have liked to do a dynamic compiler like Psyco, but we wanted to test a simpler implementation first.
[21:25] <heatsink> arigo: yes.
[21:25] <heatsink> I think the same techniques could be used with a JIT like Psyco.
[21:25] <hpk> arigo: but i see that this is not the case either, coming to think of it
[21:25] <heatsink> Well, I haven't really looked at the Psyco code, but I've read the paper.
[21:25] <arigo> hpk: hum, I'm not sure which two strategies you were mentioning then :-)
[21:26] <arigo> heatsink: yes, similar techniques could be used, but of course it's more work in a machine-code-generating environment
[21:26] <arigo> definitely not something I'd like to do with Psyco -- that's the point of PyPy
[21:27] <hpk> arigo: i was basically refering to the idea of optimizing things (like dict-accesses) by assuming they remain constant - and deoptimizing the places when things actually get changed
[21:27] <heatsink> I don't think Psyco deoptimizes anything.
[21:27] <arigo> hpk: ah, right -- indeed, global dict accesses use guards, but in general the rest doesn't go so far
[21:27] <hpk> arigo: so i was generalizing a bit i guess
[21:28] <arigo> heatsink: indeed, it's a guard in this case, not deoptimizing running code per se
[21:28] <arigo> with a callback etc.
[21:28] <hpk> arigo: right, but for PyPy a more general approach would be feasible ... i think
[21:29] <arigo> I hope so :-)
[21:29] <mwh> oh, i should check my checkgraph tests in
[21:30] <heatsink> I've been kind of confused aboyt what PyPy's goals are. There's interpreting Python, and there's compiling RPython...
[21:30] <hpk> you are not the first one :)
[21:30] <heatsink> heh :)
[21:31] <mwh> i also rewrote it to use iterblocks and added another check, so i guess i should run aaaaalllll the tests first...
[21:31] <hpk> we are sometimes confused as well but maybe less seldomly, um, maybe :)
[21:31] <hpk> heatsink: you read the architecture document, right?
[21:32] <heatsink> it's not clear in my head yet
[21:32] <arigo> Samuele suggests that when we're trying to explain the "big picture" people don't believe us anyway :-)
[21:32] <heatsink> Is this the document that described object spaces, using them for abstract interpretation, and some other things?
[21:32] <cfbolz> this statement is true for several docs, I fear :-)
[21:33] <hpk> heatsink: http://codespeak.net/pypy/dist/pypy/doc/architecture.html
[21:33] <heatsink> Incidentially, parts of the dynamic optimizer that I worked on were written in Python... and yes, they optimized themselves :)
[21:33] <arigo> indeed, we're not really explaining how we want to generate a just-in-time compiler from PyPy in architecture.html
[21:33] <hpk> heatsink: if you have a link to your work at some point, would be interested
[21:34] <hpk> arigo: true, maybe because we haven't it fully figured out yet? :)
[21:34] <arigo> well, 'architecture' tends to describe only what's already done
[21:34] <cfbolz> not necessarily
[21:34] <hpk> to a certain point, but it always looked a bit into the future
[21:34] <cfbolz> there are projects that put it all done first
[21:35] <cfbolz> :-)
[21:36] <heatsink> Okay, I see... it's an implementation-independent compiler toolsuite for Python :)
[21:37] <cfbolz> not only
[21:37] <hpk> and a full python implementation
[21:37] <hpk> parser/pycode-compiler/vm implementation
[21:37] <hpk> and types and builtins and whatnotsa
[21:39] <arigo> heatsink: the missing part is that the JIT will be generated by a "small" modification to the compiler toolsuite
[21:40] <heatsink> Small in that it requires little modification to the static compiler and interpreter?
[21:41] <cfbolz> the hope is that the modification to the interpreter is minimal
[21:41] <arigo> yes, but in the compiler we generate code differently
[21:42] <arigo> i.e. not just "compiling" but producing code that does abstract interpretation instead of interpretation (as a regular compile does)
[21:44] <heatsink> Usually abstract interpretation is a means to an end...
[21:45] <arigo> yes: more precisely, a regular "compilation" produces something similar to CPython;
[21:45] <arigo> a modified "compilation" produces something similar to Psyco.
[21:45] <arigo> there are large parts of Psyco that are in one-to-one correspondance with parts of CPython, doing operations abstractedly instead of concretely
[21:45] <heatsink> So the output of the compiler is the runtime packaged with the bytecode?
[21:46] <arigo> ah, no, the "compiler" here means the "translator", taking the PyPy interpreter itself as input
[21:47] <arigo> we are only statically compiling this (it's even RPython, not full Python), and not user programs
[21:47] <heatsink> Okay, so the compiler you're talking about is a generator for compilers or runtimes.
[21:47] <heatsink> *or interpreters
[21:48] <cfbolz> it is the "compiler toolsuite for Python" you were mentioning above
[21:48] <cfbolz> it can compile RPython programs
[21:48] <arigo> er, in some sense... this compiler takes any RPython code as input and can compile it as normally done by compilers
[21:48] <arigo> and produce good C code
[21:48] <cfbolz> for some values of good :-)
[21:48] <sabi> well, somewhat fast at least :)
[21:49] <arigo> we compile the PyPy interpreter in this way, so we get a not-too-slow interpreter in C
[21:49] <sabi> (or llvm)
[21:50] <heatsink> right.
[21:50] <arigo> (or JavaScript :-)
[21:50] <heatsink> what? WHY?
[21:50] <cfbolz> hehe
[21:50] <sabi> that one doesn't qualify as "not-too-slow" :0
[21:50] <arigo> at the moment this compiler could be applied to any other RPython programs
[21:51] <heatsink> okay. So what part of the compiler changes for it to output a JIT?
[21:51] <heatsink> instead of an interpreter?
[21:51] <arigo> instead of producing regular C code doing operations,
[21:51] <arigo> it would produce C code doing "partial evaluation" of what the original C code would have been
[21:52] <arigo> so we get C code to which we can send, at run-time, some constant values (like bytecodes from the user program); at this point the C code generates "residual" code.
[21:53] <arigo> This works by abstractedly interpreting the bytecode, but it's only a point of vie
[21:53] <arigo> w
[21:54] <heatsink> Is there a useful distinction between this and just calling every compiler an abstract interpreter?
[21:54] <arigo> the static compiler generates a partially-evaluating version of whatever input program it's given (given a few manual hints)
[21:54] <heatsink> hmm wait...
[21:55] <arigo> heatsink: compilers can work by abstract interpretation or not; it's a technique.
[21:55] <heatsink> ok
[21:55] <arigo> so our static compiler is indeed generating a compiler that works by abstract interpretation, if the input of the static compiler was an interpreter in the first place ....
[21:55] <cfbolz> :-)
[21:56] <heatsink> okay...
[22:01] <heatsink> So the code that actually does the computation is not generated by the compiler. The compiler generates code that generates code that does the computation.
[22:04] <heatsink> If I've got that right, then the "doing the computation" is like the code created at runtime by psyco, and the step before that is the JIT compiler.
[22:05] <heatsink> But then I don't know what the first step, the "compiler", would be doing, besides bundling a JIT with some bytecode.
[22:07] <cfbolz> wait. what is "the code that actually does the computation"?
[22:07] <heatsink> machine code to unbox, do primitive computation, rebox, branch to next code
[22:08] <heatsink> as opposed to virtual method dispatch
[22:08] <heatsink> which figures out which computation to do
[22:08] <arigo> heatsink: not having boxed values is the whole point
[22:08] <mwh> uh, socket test failures here
[22:08] <mwh> i wonder when i last updated, though
[22:09] <braintone> adim - r21146 - export __new__ methods to be able to create AST nodes at applevel. Thanks a lot to Armin who helped me to find out why PyPy refused to compile.
[22:10] <arigo> heatsink: I don't get the "bundling a JIT with some bytecode" point
[22:10] <arigo> the bytecode comes from application-level user code
[22:11] <arigo> this is not known in advance
[22:11] <arigo> (btw most of what I'm describing is heavily work-in-progress)
[22:11] <heatsink> Hmm...
[22:12] <heatsink> In what you described, there are two translation steps: one at compile time, one at run time, right?
[22:12] <arigo> yes
[22:12] <heatsink> I know the input to the first step is the source code of a compiler or interpreter, and the output of the last step is executable machine code of the compiler or interpreter.
[22:13] <heatsink> I don't understand what's in between the two steps.
[22:13] <arigo> no, the output of the last step is machine code that does whatever the user program does
[22:13] <braintone> adim - r21147 - export each AST type through the parser module
[22:13] <arigo> the user program is only provided incrementally at run-time
[22:13] <heatsink> oh
[22:14] <arigo> just like in CPython -- the user program is imported bit by bit, can change, etc.
[22:14] <heatsink> So you described the process of compiling a compiler.
[22:14] <heatsink> I thought you were explaining how PyPy uses abstract interpretation. That's why I was confused.
[22:14] <heatsink> *how PyPy does abstract interpretation
[22:15] <arigo> well, I described "step 1" which is a process that turns an interpreter into a run-time compiler
[22:17] <heatsink> Sorry, I'm not understanding.
[22:18] <heatsink> I don't want to keep heckling you with this, though.
[22:18] <arigo> NP
[22:19] <arigo> PyPy contains a normal Python interpreter written in RPython, and a translator ("step 1").
[22:20] <arigo> at the moment, "step 1" is good to turn any RPython code into C code that performs just the same operations
[22:20] <xorAxAx> (or into JS :))
[22:20] <arigo> so, if we plug "Python interpreter" into "step 1" we get a not-too-slow Python interpreter
[22:21] <heatsink> so it essentially produces an executable by converting a bytecode into the corresponding lines of C from the interpreter loop, with a little extra work to convert control flow?
[22:21] <arigo> no
[22:21] <heatsink> *by converting an instruction
[22:21] <heatsink> That's what I took "just the same operations" to mean.
[22:22] <arigo> sorry, I meant that it has the same function, it observably does the same thing
[22:22] <heatsink> oh, ok
[22:22] <arigo> it does it fast become the "Python interpreter" here is written in RPython, not Python
[22:23] <arigo> RPython is a subset of Python on which we can perform kind-of-usual type inference statically
[22:23] <arigo> ("kind-of")
[22:24] <arigo> this is what we have done already
[22:24] <heatsink> The translator is from what language to what language?
[22:24] <arigo> from RPython to C
[22:24] <heatsink> ok
[22:25] <heatsink> so you have an interpreter and a compiler, and the compiler can compile both of these things.
[22:25] <heatsink> and the interpreter can interpret both of these things :)
[22:25] <heatsink> a compiler to C
[22:25] <arigo> ?
[22:26] <arigo> let's try to stick to "translator" instead of the confusing "compiler"
[22:26] <heatsink> ok
[22:27] <arigo> the translator is from RPython to C, and the PyPy full Python interpreter is written in RPython
[22:27] <heatsink> right
[22:27] <arigo> so it can be translated into C :-)
[22:28] <arigo> this way we get something that would look like CPython (if the C produced weren't so unreadable)
[22:29] <hpk> which is all only roughly true of course
[22:30] <hpk> (e.g. the python interpreter also has parts that are written in "application-level" code, not rpython-restricted, but that is just a detail and complicates the picture unneccessarily at this point)
[22:31] mwh (n=mwh@fwstups.cs.uni-duesseldorf.de) left irc: "good night"
[22:31] -ChanServ (ChanServ@services.)- You do not have channel operator access to [#pypy-sync]
[22:36] <arigo> all this is the basis on top of which we will introduce the JIT in the next months
[22:36] <arigo> the translator will produce C code and package it into an executable that contains:
[22:36] <arigo> * a copy of the C version of the full Python interpreter, as above
[22:36] <arigo> plus
[22:36] <arigo> * what looks like a systematically-modified version of that same C code
[22:36] <arigo> (or parts of it, at least -- the parts close to the C version of the interpreter main loop)
[22:36] <arigo> ok so far?
[22:37] <heatsink> ok
[22:37] <arigo> the systematically-modified version of the same C code is just like Psyco
[22:37] <arigo> (or should be)
[22:38] <arigo> you could have a look at
[22:38] <heatsink> alright
[22:38] <arigo> http://codespeak.net/svn/psyco/dist/c/Python/pycompiler.c
[22:39] <arigo> the 2nd half of this file is a "copy" of the CPython interpreter loop
[22:39] <arigo> e.g. look for BINARY_POWER
[22:39] <heatsink> heh, yea
[22:39] <arigo> it superficially looks much like BINARY_POWER in ceval.c
[22:40] <arigo> however, the "values" it manipulates are not PyObject* but values that can be either PyObject* or abstract (e.g. "stored in the machine register eax")
[22:41] <heatsink> ok
[22:41] <arigo> so by "executing" this main loop over a user bytecode at run-time, we are following a code path similar to the one that CPython would have taken,
[22:42] <arigo> up to the point of the actual operations between abstract values (e.g. an addition between the content of two integers)
[22:42] <heatsink> That's what you meant by abstract interpretation?
[22:42] <arigo> which then generates machine code to perform the addition, as a side-effect, and returns another abstract value describing where the result will be
[22:42] <arigo> yes
[22:42] <psykotic> that's very elegant
[22:42] <heatsink> ok
[22:42] <arigo> we're using the term at many levels, though :-/
[22:43] <psykotic> what do you do for conditional jumps? explore both "paths"?
[22:43] <arigo> yes, potentially
[22:44] <arigo> actually in Psyco only one path is followed, and the other is "suspended"; pycompiler.c gets resumed if the actual execution of the machine code reaches the suspended poin
[22:44] <arigo> t
[22:44] <arigo> so the PyPy Plan (tm) is: because we can already generate code like ceval.c, we should be able to generate code like pycompiler.c with minor changes to the translator...
[22:44] <psykotic> that's very cool
[22:44] <heatsink> I see.
[22:45] <psykotic> i'm assuming for other uses of "abstract interpretation", for e.g. the flow object space, both paths are always followed?
[22:47] <arigo> yes
[22:48] <psykotic> man, this is a really powerful general approach.
[22:48] <hpk> can we cite this in the EU review we are facing january? :)
[22:48] <psykotic> hehe
[22:48] <heatsink> Can't do backwards analysis though.
[22:49] <psykotic> heatsink: you mean where if you know that e.g. f expects an int then f(x) implies x is an int--that kind of backward flow of information?
[22:49] <sabi> no reason you can't take the abstract-interpretation analysis and postprocess it
[22:49] <heatsink> psykotic: I mean like dead code elimination
[22:50] <heatsink> sabi: true.
[22:50] <cfbolz> arigo: doesn't the flow object space do some amount of constant folding? so in the case of if 0: xxx the path is not followed, right?
[22:50] <psykotic> heatsink: no-one says you have to do everything in one pass. you can use the pass to build whatever data structures are useful, e.g. basic blocks in your suggested case.
[22:50] <psykotic> and then go crazy with SSA or whatever
[22:51] <xorAxAx> hmm, folding the SSA graphs until you have the literal 42. that would rock.
[22:51] <arigo> cfbolz: a bit, but let's keep the flow space out of this discussion for sanity's sake :-)
[22:51] <cfbolz> sure :-)
[22:51] <cfbolz> sorry
[22:51] <hpk> haha, sanity
[22:51] <heatsink> The interpreter-generator idea is nifty.
[22:51] Action: cfbolz laughs manically
[22:51] <arigo> hpk: -<:-)
[22:52] <arigo> dead code elemination is not a problem, though
[22:52] <psykotic> i'm familiar with abstract interpretation as a general concept but this way of organizing it via custom object spaces is clever.
[22:52] <arigo> code paths never followed are never analysed
[22:52] <arigo> hum, too many confusing uses of "abstract interpretation"...
[22:52] <arigo> psykotic: that's the flow space one
[22:53] <heatsink> I've gotta do some work, thanks for the explanation.
[22:53] <arigo> it's not really related to the JIT one
[22:53] heatsink (n=heatsink@tongue.crhc.uiuc.edu) left irc: "Leaving"
[23:05] <xorAxAx> hmm, creative pythonic task. given a python interpreter where you dont have builtins, how can you get an __import__? type = "".__class__.__class__ works of course, but you dont get such builtins easily
[23:07] <xorAxAx> ( type.__base__.__subclasses__() gives you things like file etc.)
[23:08] <xorAxAx> btw, why doesnt pypy have __subclasses__?
[23:09] <psykotic> i didn't even know about __subclasses__(). i don't think that's documented in the cpython docs? :)
[23:09] <cfbolz> to prevent such hacks, obviously :-)
[23:09] <sabi> huh, i never knew such a thing existed
[23:09] <xorAxAx> :-)
[23:10] <cfbolz> it's an implementation detail, I would say :-)
[23:10] <sabi> __subclasses__() -> list of immediate subclasses
[23:10] <sabi> well, it is at least documented :)
[23:10] <xorAxAx> dir() doesnt give it
[23:10] <xorAxAx> dir(type) does, though
[23:10] <sabi> does that work in pypy?
[23:10] <sabi> AttributeError: type object 'object' has no attribute '__subclasses__'
[23:10] <sabi> i guess that's my answer ;)
[23:13] <xorAxAx> hmm, "23:13:21 < xorAxAx> btw, why doesnt pypy have __subclasses__?
[23:13] <sabi> oh, heh, i completely failed to see that line
[23:13] <xorAxAx> :-)
[23:13] <xorAxAx> hmm, that restricted bit in the current frame seems to work
[23:14] <xorAxAx> it stops the user from using file
----- silence for 20 minutes ----- [23:34] <arigo> xorAxAx: __subclasses__() requires weakrefs to be implemented properly, we don't have them
[23:35] <xorAxAx> arigo: hmm, ok
[23:35] Action: xorAxAx wonders if he asked that already some months ago
[23:36] <stakkars> arigo: I saw a lot of messages about JIT,probably. Do I need to read, or did I know that all? :-)
[23:37] <arigo> :-)
[23:37] <arigo> who knows :-)
[23:38] <stakkars> hmm, no, I know.
[23:39] <stakkars> was just curious about a discussion, which was more like a strory :)
[23:42] <sabi> alright, so i've got --usemodules implemented in translate_pypy.py
[23:42] <sabi> so the only other problem is in extfunctable.py, because it expects to be able to import CPython modules with the same name as the pypy modules
[23:43] <sabi> i could implement a stub module
[23:43] <sabi> unless it'd be useful to have a more general solution at this point
[23:44] <cfbolz> what does extfunctable expect?
[23:44] <sabi> AttributeError: type object 'object' has no attribute '__subclasses__'
[23:44] <sabi> oops
[23:44] <sabi> declare(math.frexp , frexpannotation, 'll_math/frexp')
[23:45] <sabi> you do things like that, where 'math' is actually the CPython math module
[23:45] <cfbolz> well
[23:45] <cfbolz> but you can also say declare(mymodel.function, ...)
[23:45] <sabi> you can? :)
[23:45] <cfbolz> yes
[23:45] <cfbolz> declare(rstack.stack_frames_depth, int, 'll_stackless/stack_frames_depth')
[23:46] <cfbolz> since when is rstack in the stdlib?
[23:46] <sabi> oh, i see
[23:46] <cfbolz> you have to give it a function, you can import it from wherever you want
[23:47] <sabi> i could import my dummy functions from pypy.module.foo then i guess
[23:48] <cfbolz> yes
[23:48] <cfbolz> usually you add a dummy module to rpython/rXXX.py
[23:48] <cfbolz> that then contains only the external functions
[23:48] <sabi> in my case all the functions are external functions
[23:49] <cfbolz> wait
[23:49] <sabi> the interp_* versions just raise an exception because they can't be emulated
[23:49] <cfbolz> you want to expose this module to pypy-applevel?
[23:49] <cfbolz> or you want just a module that can be used from an rpython program?
[23:49] <sabi> well, i've got a ll version too. i have both interplevel and applevel implementations
[23:50] <cfbolz> LevelOverflowError
[23:50] <cfbolz> you have external functions, that you want to expose in a module to the pypy interpreter?
[23:50] <sabi> hehe
[23:51] <cfbolz> is that a yes? :-)
[23:51] Action: sabi is confused a bit about the terminology himself
[23:51] <sabi> basically i want to be able to call my functions from inside the implementation of pypy
[23:51] <sabi> as well as from code running on top of pypy
[23:51] <cfbolz> aha. but that is two different things :-)
[23:51] <sabi> yes, in the case of extfunctable i think we're only talking about the second one
[23:51] <cfbolz> no!
[23:52] <sabi> i'm wrong? :)
[23:52] Action: sabi is even more confused than he thought then
[23:52] <cfbolz> the extfunctable-functions can only be invoked from interplevel
[23:52] <cfbolz> that means stuff written in rpython
[23:52] <sabi> ok
[23:52] <cfbolz> you have to expose them then to applevel
[23:52] <sabi> that is fine
[23:52] <cfbolz> using a special pypy module
[23:52] <cfbolz> should we meet in a screen somewhere and look at it?
[23:53] <sabi> um, sure... instructions on how to set up?
[23:53] <cfbolz> do you have a codespeak account?
[23:53] <arigo> sabi: the option --usemodules should go in targetpypystandalone.py, not translate_pypy
[23:54] <cfbolz> sabi: or another unix machine where we can both login?
[23:55] <sabi> cfbolz: no codespeak account, i could create you an account somewhere else
[23:55] <sabi> hold a sec
[23:55] <sabi> arigo: i thought of doing that
[23:55] <sabi> but usemodules is used by the other target* stuff too
[23:55] <sabi> i can easily move it though
[23:56] <arigo> sabi: not all of them, only a few, possibly
[23:56] <sabi> well i found something that said "usemodules=[]" or had a usemodules argument to the Space constructor
[23:56] <arigo> there is already much code duplication :-/
[23:56] <sabi> yeah, i noticed, the code was not so clean :)
[23:56] <arigo> sure, we could do with some common support code
[23:56] <sabi> i was trying to cut down on it
[23:56] <sabi> it just gets passed as options.usemodules to everything
[23:57] <arigo> just not in translate_pypy (misnamed!!) because it's generic to translate anything not necessary related to PyPy, i.e. not with an objspace
[23:57] <sabi> arigo: ohh. i see. :)
[23:57] <sabi> well, pardon me for being so literal :)
[23:58] <arigo> argh. translate_pypy is not about translating PyPy.
[23:58] <sabi> i see this now
[23:59] <arigo> (historical reasons of course)
[23:59] <sabi> svn does support renames :)
[23:59] Action: sabi tries to figure out how to make this screen sharable
[00:00] --- Wed Dec 14 2005
