[00:00] <xorAxAx> switch-blocks using gcc are fast because gcc dumps a dispatch table into the code block
[00:00] <xorAxAx> i.e. it somehow transforms the var into an offset, relocates using the table and jumps to the correct location
[00:01] <cfbolz> well, but the worst case is that the switch is as fast as the series of conditions
[00:01] <ericvrp> yes and it can still inline a lot of small opcode handlers. Which it could not do in the current situation.
[00:01] <xorAxAx> cfbolz: sure
[00:01] <cfbolz> good
[00:03] <xorAxAx> but - there are some compilers that choke on long switches
[00:03] <xorAxAx> even cpython has a workaorund in the main loop
[00:03] <cfbolz> let's hope we are not using those :-)
[00:04] <xorAxAx> and i dont know in which cases the dispatch table might be larger than the ifs and therefore trash more cache lines. that might slow things down
[00:04] <xorAxAx> but thats gcc internals, it should try to avoid those cases :)
[00:05] <cfbolz> hum, of course the opcode swith would be rather large
[00:05] <xorAxAx> i wonder what output you get with listing (asm) generation and -o2/-o3. maybe you just see the table as a dw series
[00:05] <cfbolz> well, we are not so far yet :-)
[00:06] <xorAxAx> stakkars prefers to read asm listings :)
[00:06] <cfbolz> yip
[00:09] <pedronis_lurkm> xorAxAx: what's your point exactly?
[00:10] <xorAxAx> pedronis_lurkm: hmm, my initial point was that pypy is a compiler and might possibly directly do what gcc does (the dispatch table), at least at some layer
[00:11] <cfbolz> xorAxAx: note that samuele cannot type
[00:11] <cfbolz> not fast, at least
[00:11] <xorAxAx> cfbolz: yeah, considering that
[00:12] <xorAxAx> he doesnt need to, it was a quick thought anyway
[00:16] pedronis_lurkm_ (n=Samuele_@9.135.79.83.cust.bluewin.ch) joined #pypy.
[00:18] <ericvrp> goodnight everyone!
[00:18] <xorAxAx> gn ericvrp
[00:19] ericvrp (n=eric@ericvrp.demon.nl) left irc:
[00:19] -ChanServ (ChanServ@services.)- You do not have channel operator access to [#pypy-sync]
[00:23] <pedronis_lurkm_> g'night
[00:24] pedronis_lurkm_ (n=Samuele_@9.135.79.83.cust.bluewin.ch) left irc: Remote closed the connection
[00:27] pedronis_lurkm (n=Samuele_@228.160.77.83.cust.bluewin.ch) left irc: Read error: 110 (Connection timed out)
----- silence for 18 minutes ----- [00:45] cfbolz (n=cfbolz@p54AB84FC.dip0.t-ipconnect.de) left irc: "Leaving"
[00:46] Action: lac is away: bed
[00:50] Thunder- (n=cpisto@router3.nmxs.com) left irc: "Leaving"
[01:00] _hannes (i=ore@i577B4DB8.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[01:06] Shoragan (n=shoragan@d072.apm.etc.tu-bs.de) left irc: "Leaving"
----- silence for 1 hr and 2 minutes ----- [02:08] xyz359 (n=xyz359@pool-71-251-79-251.tampfl.fios.verizon.net) joined #pypy.
----- silence for 19 minutes ----- [02:27] hpk (n=hpk@200.103.133.2) left #pypy ("Leaving").
----- silence for 53 minutes ----- [03:20] sabi (i=njriley@shrug.csl.uiuc.edu) left irc: Remote closed the connection
[03:30] xyz359 (n=xyz359@pool-71-251-79-251.tampfl.fios.verizon.net) left irc: "Wtf."
----- silence for 33 minutes ----- [04:03] sabi (n=nicholas@dynpool-astatine.cs.uiuc.edu) joined #pypy.
----- silence for 59 minutes ----- [05:02] 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";
----- silence for 2 hr and 31 minutes ----- [07:33] Shoragan (n=shoragan@d072.apm.etc.tu-bs.de) joined #pypy.
[07:43] sabi (n=nicholas@dynpool-astatine.cs.uiuc.edu) left irc:
----- silence for 28 minutes ----- [08:11] aleale (n=andersle@83.72.68.168.ip.tele2adsl.dk) joined #pypy.
[08:12] thingie99 (n=foo@dsl-213-54.hive.is) left irc: Read error: 110 (Connection timed out)
----- silence for 22 minutes ----- [08:34] adim (n=adim@logilab.net2.nerim.net) joined #pypy.
[08:43] ericvrp (n=eric@ericvrp.demon.nl) joined #pypy.
[08:45] Gromit (n=klix@does-d9b9191f.pool.mediaWays.net) joined #pypy.
[08:50] mwh (n=mwh@fwstups.cs.uni-duesseldorf.de) joined #pypy.
[08:59] <mwh> good morning
[09:00] <adim> Hi
[09:07] <Gromit> hi
[09:07] sabi (i=njriley@shrug.csl.uiuc.edu) joined #pypy.
[09:14] rhymes (n=rhymes@host201-12.pool8250.interbusiness.it) left irc: "supercalifragiliblahblah"
----- silence for 24 minutes ----- [09:38] thingie24 (n=asdf@87.237.32.254) joined #pypy.
----- silence for 19 minutes ----- [09:57] rhymes (n=rhymes@host201-12.pool8250.interbusiness.it) joined #pypy.
[09:59] mwh (n=mwh@fwstups.cs.uni-duesseldorf.de) left irc:
[10:11] cfbolz (n=cfbolz@p54ABB5B8.dip0.t-ipconnect.de) joined #pypy.
[10:11] <cfbolz> morning!
[10:11] <adim> Hi
[10:21] odie (n=odie@62-2-77-204.business.cablecom.ch) joined #pypy.
[10:22] <ericvrp> cfbolz: goodmorning
[10:23] <cfbolz> hi eric!
[10:24] <ericvrp> LLVM did convert the ifs to a switch and is now down to 6.8x
[10:24] <cfbolz> whew
[10:24] <ericvrp> slower then CPython with richards
[10:25] <cfbolz> time to write that transformation
[10:25] <cfbolz> :-)
[10:25] <cfbolz> my inlining stuff seem to have a slight improvement as well
[10:26] arigo (n=arigo@c-188b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[10:26] <cfbolz> hi armin!
[10:26] <ericvrp> great
[10:26] <ericvrp> hi armin!
[10:26] <adim> Hi Armin
[10:26] <braintone> ale - r21164 - First checkin of OWL parser/inferer. This is work in progress. The tests are disabled if rdflib and/or logilab.constraint is not installed. There is still a lot missing
[10:27] <arigo> hi!
[10:27] <lac> morning
[10:27] Action: lac is back
[10:27] <ericvrp> morning Laura
[10:27] <adim> Hi Laura
[10:29] <lac> only 6.8x slower, eh ....
[10:29] <cfbolz> although with a hack
[10:33] <cfbolz> ericvrp: would you mind if I did the "series of if" -> switch transformation? or did you want to do that today? I don't want to steal this, but I would find it fun to do it.
[10:34] <ericvrp> I have started work on that about 30 minutes ago
[10:34] <ericvrp> shall we pair on snake?
[10:34] <cfbolz> ok
[10:34] <ericvrp> screen -x ericvrp/ericvrp
[10:35] stakkars (n=tismer@87.237.32.254) joined #pypy.
[10:35] <cfbolz> ericvrp: and discussion in #carleric?
[10:40] <stakkars> hi all from Iceland!
[10:40] <cfbolz> hi christian!
[10:40] <cfbolz> how was the trip?
[10:40] <adim> Hi
[10:41] <stakkars> quite bad, took almost as long as going to the states
[10:41] <stakkars> the machine was broken in Copenhagen, and I lost most of the day.
[10:41] <cfbolz> oops
[10:42] <lac> poor you.
[10:42] <lac> at least there is decent food at that airport
[10:43] <stakkars> yes, the airport is very nice. Actually they told us that a machine with the spare parts would come at 6pm
[10:43] <stakkars> and we thought there is enogh time. Then they repaired the plane earlier and didn't reach quite a coupleof people, so my next flight was on 20:10
[10:44] <stakkars> well, it's ok. You arrive in the night, you get up in the night. Iceland has about 4 hours of light, now :-)
[10:46] <Gromit> Hi Christian
[10:46] <stakkars> hi Gromit
[10:58] <stakkars> lac: I guess you too have no signs of life from LA?
[10:58] arre (i=ac@kourier.strakt.com) joined #pypy.
[11:03] <Gromit> ?-(
[11:07] <stakkars> well, maybe they are just very busy. Will try to call somebody today
[11:07] <Gromit> :-)
----- silence for 16 minutes ----- [11:23] <braintone> adim - r21165 - fixed bug for setters() in ast.py
[11:25] cfbolz (n=cfbolz@p54ABB5B8.dip0.t-ipconnect.de) left irc: Remote closed the connection
[11:26] cfbolz (n=cfbolz@p54ABB5B8.dip0.t-ipconnect.de) joined #pypy.
[11:33] <adim> someone willing to help me understand the rtyping problem I have ?
[11:35] <cfbolz> I am, but not _right_ now
[11:35] <cfbolz> (and if someone more capable is, even better)
[11:35] <adim> cfbolz: ok, thanks
[11:36] <adim> I will be out in 15 minutes anyway
[11:37] <cfbolz> ok, then I'll help you know
[11:37] Action: arigo gives it a look
[11:37] <cfbolz> ok :-)
[11:37] <adim> arigo: screen -are adim/adim then :)
[11:38] <adim> stupid gaim
[11:38] <lac> no life from LA, no.
[11:40] <stakkars> :-[]
[11:40] <arigo> adim: can you resize your window down? it's really too big
[11:40] <adim> arigo: should be done
[11:41] <stakkars> arigo: I got a problem with coroutines debugging.
[11:41] <arigo> adim: doesn't seem to have worked
[11:41] <stakkars> arigo: my problem is that I cannot assing None to a variabole that holds a frame top
[11:41] <adim> arigo: Well, it might be a "Ion3" problem then. Let me try something else
[11:42] <arigo> eek! you killed the screen?
[11:42] <stakkars> any idea how I should fix this? the ExternalObject thinkie seems to say that it can be None
[11:42] <adim> arigo: yes, but will be back in 1 minute
[11:43] <adim> session back
[11:43] <arigo> better, thanks
[11:46] <cfbolz> ok. I wouldn't be of any help there :-)
[11:47] <arigo> stakkars: can you check in a test case, e.g. in translator/c/test/test_stackless ?
[11:47] <arigo> I'd have expected it to work
[11:50] <stakkars> arigo: yes (may take a while since I'm supposed to work on something different, just waiting for my machine)
[11:53] <arigo> adim: ah
[11:54] <arigo> I see. It's indeed a bug in our call normalization
[11:54] <adim> arigo: I was sure it couldn't be my fault ;)
[11:54] <stakkars> arigo: I'm also able to produce a compile error, don't ask me how. May I just check my test_coroutine.py in?
[11:55] <arigo> sure, go ahead (py.test.skip("in-progress") if it fails for now)
[11:57] <adim> arigo: I have to go *now*, thanks for the help again. Feel free to postpone the fix if you've got something else to do right now
[11:57] <arigo> np
[11:57] <adim> I'll be back at 1 pm
[12:00] <arigo> damn, of course the test case works
[12:01] <arigo> ah, got it
[12:09] <braintone> arigo - r21166 - casting an object to an int doesn't always return a positive number.
[12:10] <braintone> tismer - r21167 - trying to build a minimal coroutine implementation. There seem to be some issues left which keep me from verifying if this is right.
[12:13] Gromit (n=klix@does-d9b9191f.pool.mediaWays.net) left irc: Read error: 113 (No route to host)
[12:16] <arigo> stakkars: I'm puzzled by your comment line 119
[12:16] <arigo> return self.frame # just for the annotator
[12:17] <stakkars> yes, comment it out and it won't annotate.
[12:17] <arigo> well, indeed
[12:17] <stakkars> this is because we are doing too much magiv
[12:17] <stakkars> magic
[12:17] <arigo> my point is different
[12:17] <stakkars> I'm really i favor of doing a graph transform
[12:17] <stakkars> ah
[12:18] <arigo> you really have to return a meaningful value here
[12:18] <arigo> it's not just for the annotator
[12:18] <stakkars> this is really used? oupps
[12:18] <stakkars> because we really return twice?
[12:18] <stakkars> that might be the trouble I have. Anyway, itis in progress, and the other probs are blocking a bit
[12:19] <arigo> http://codespeak.net/svn/pypy/extradoc/sprintinfo/paris/stackless-discussion.txt
[12:19] <arigo> it's clearly explained here
[12:19] <stakkars> from what I saw so far, a frame should allow to be None, but rtyper thinks it is an object
[12:20] <stakkars> heh, I remember. :-)
[12:21] <arigo> wah
[12:21] <arigo> the annotator is missing the merging logic for SomeExternalObject with s_None
[12:21] <arigo> this part of binaryop.py should be cleaned up...
[12:22] <stakkars> that's what I was missing.
[12:23] <stakkars> the mentioned return statement is where I have to go to drop the coroutine as I understand.
[12:23] <arigo> I think so
[12:24] <stakkars> we might re-think the interface at some point. Right now it looks like my hard-switching code
[12:25] <stakkars> in Stackless, and I cannot produce tail-calls. Everything must be updated after the switch. But ok for now.
[12:34] <stakkars> arigo: should I cintinue on this, or are you working on something?
[12:35] <arigo> I'm fixing binaryop
[12:35] <arigo> running some tests before I check in...
[12:35] <stakkars> very good! I think being able to check for None-ness in debug mode is the best thing to do
[12:36] <stakkars> or it might be done all the time, to get rid of references, early.
[12:42] nik_ (n=nik@132.207.79.83.cust.bluewin.ch) joined #pypy.
[12:42] <cfbolz> hi nik!
[12:42] <nik_> hi!
[12:43] <ericvrp> hi Nik, ear improving somewhat?
[12:43] <nik_> it's somewhat better, not fully recovered though ...
[12:44] <ericvrp> nice
[12:44] <stakkars> your ears still hurting?
[12:44] hpk (n=hpk@200.103.133.2) joined #pypy.
[12:44] <nik_> no hurting, thankfully, but impaired hearing
[12:45] <stakkars> harthörig :-)
[12:46] <nik_> ;-)
[12:49] <braintone> arigo - r21169 - Added support for merging SomeExternalObjects and None (thanks Christian). Cleaned up a bit the corresponding code in binaryop.py.
[12:50] <arigo> hum, test_coroutine segfaults now, with USE_NONE=True
[12:50] <arigo> but if you're indeed returning a dummy value when a real continuation is expected, I'm not surprized :-)
[12:50] <cfbolz> hehe
[12:50] <stakkars> it actually is something different.
[12:51] <stakkars> I just changed that, but the crash appears after "g appended 4"
[12:51] <stakkars> so nothing is finished, still, it just crashes. And I know I get an undefined state but don't know why, yet.
[12:52] <stakkars> will try a bit more with the extra None checking. Thanks!!
[12:52] <stakkars> btw.: if you enable the DEBUGflag, you get code generated that does not compile
[12:53] <stakkars> D:\pypy\dist\pypy\translator\c\src\ll_stackless.h(207) : error C2120: 'void' mit Typen nicht zulässig
[12:53] <arigo> yes, I'm looking at it
[12:54] <stakkars> thanks, I'm trashing that code now and continue with None
[12:54] <arigo> it's because the entry point can never return -- it always raises an exception (or so the annotator thinks)
[12:54] <arigo> so you get a 'void' instead of an 'int' answer
[12:54] pedronis_lurkm (n=Samuele_@176.175.76.83.cust.bluewin.ch) joined #pypy.
[12:54] <stakkars> aha
[12:55] <ericvrp> * notes that #pypy-sync is about to start
[12:55] <arigo> thanks
[12:56] <stakkars> oups, it's 12:00 here :-)
[12:56] Nick change: pedronis_lurkm -> pedronis_reco
[13:00] <stakkars> arigo: wonderful, now I get the assertion errors which I needed :-)
[13:01] <arigo> the annotator seems to constant-propagate a bit too much
[13:02] <arigo> I think that the test on costate.current._switchable is constant-folded :-(
[13:16] <arigo> no, non-sense. works fine
----- silence for 17 minutes ----- [13:33] <braintone> arigo - r21170 - Some more cast_object_to_int-can-return-a-negative-value.
[13:36] <braintone> arigo - r21171 - More precise function and method calls, to fix the following (now-tested) buggy case: at the end of annotation, consider_call_site() fills a call table using the SomePBCs of each call site; later, the
[13:36] <arigo> adim: this should help
[13:38] <pedronis_reco> arre: ?
[13:39] ericvrp (n=eric@ericvrp.demon.nl) left irc:
[13:39] <adim> arigo: ok I'll try again
[13:39] <adim> oops, too late :)
[13:39] <arigo> yes, I just restarted it :-)
[13:40] <arigo> did you suspend it?
[13:40] <adim> no
[13:40] <arigo> screen crash?
[13:40] <arigo> fun fun fun
[13:40] <adim> might be.
[13:41] <arigo> I have to let you kill the mess it left behind :-(
[13:43] Nick change: pedronis_reco -> pedronis_afk
[13:46] <adim> arigo: seems to work, thanks
[13:58] <cfbolz> arigo: a question about the switching stuff me and eric are working on:
[13:58] <cfbolz> what should the fallback case (else) have as an exitcase? None?
[13:59] <arigo> stakkars: re pypy-sync discussion:
[13:59] <arigo> writing an rpython socket module that uses non-blocking calls but presents a blocking stackless interface
[14:00] <arigo> if you'd do it on CPython, you wouldn't write it in C, but as a Python layer on top of the existing _socketmodule.c
[14:01] <arigo> except for debatable performance considerations
[14:01] <arigo> but in our case even these considerations don't apply
[14:01] <stakkars> yes, probably. And it doesn't save any of the issues we need to solve anyway
[14:01] <arigo> such a module should clearly not try to fight interfacing with C *again*
[14:05] <stakkars> I think his idea was mainly to use RPython Stackless, to make things work without requiring PyPy
[14:06] <arigo> I don't really see what it changes
[14:07] <stakkars> just see it under the goal "produce a fast extension module for CPython"
[14:07] <arigo> no, precisely, I don't see how it helps this goal
[14:07] <stakkars> (we didn't talk so much about this, he just mentioned it)
[14:07] <stakkars> so please don't discuss this with me
[14:08] <stakkars> well, sorry you may :-)
[14:08] <stakkars> we probably have him on IRC some time soon, while he's in England?
[14:15] <cfbolz> arigo: did you see my question?
[14:15] <arigo> cfbolz: sorry, forgot it
[14:16] <cfbolz> np
[14:16] <arigo> ah oh... good question
[14:17] <cfbolz> :-)
[14:17] <arigo> there is also the llexitcase to worry about
[14:18] <cfbolz> indeed. I assume that for the non-else cases it is just the int
[14:18] <arigo> yes
[14:20] <arigo> probably None indeed, as long as it's the last exit...
[14:20] <arigo> both for exitcase and llexitcase
[14:20] <cfbolz> ok
[14:21] <arigo> or even some dummy thing for exitcase, and None for llexitcase
[14:21] <arigo> like exitcase="default"
[14:21] <cfbolz> ok
[14:21] <arigo> a bit obscure but well
[14:21] <cfbolz> doesn't make the model much worse
[14:21] <arigo> just a bit :-)
[14:22] <cfbolz> :-)
[14:22] <cfbolz> eric gets impressive speedups with llvm when doing his dispatch-switching hack
[14:22] <arigo> ah ha
[14:22] <cfbolz> (because llvm does the chain-of-ifs -> switch conversion itself)
[14:24] <cfbolz> another thing: should I go for the two inlining passes, one as it was until now and one that inlines functions that have only one callsite?
[14:24] <arigo> possibly
[14:25] <arigo> as usual with inlining heuristics, it's all guesswork
[14:25] <cfbolz> so the answer is to try it out and see, I guess
[14:26] <arigo> indeed
----- silence for 23 minutes ----- [14:49] arre (i=ac@kourier.strakt.com) left irc: Remote closed the connection
[14:49] <braintone> ericvrp - r21172 - (cfbolz, ericvrp): start of a transformation to merge consecutive equality tests on the same variable into a switch (taking that variable as an exitswitch and having several exits with the cases)
[14:50] <stakkars> (k)
[14:50] <cfbolz> ?
[14:53] Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) joined #pypy.
[15:02] mwh (n=mwh@inat15.ams.attingo.nl) joined #pypy.
[15:03] <arigo> hi Michael
[15:03] <mwh> hello
[15:03] <mwh> my super-efficiently german train was 40 minutes late
[15:03] <arigo> :-(
[15:03] <mwh> just as well i was due to arrive about 80 minutes before i needed to, eh?
[15:04] <xorAxAx> mwh: hmm, you are lucky. thats kinda on time for german trains <duck>
[15:04] <mwh> and people are always so rude about english trains
[15:04] <xorAxAx> they are worse?
[15:04] <cfbolz> mwh: did your ticket work out?
[15:04] <mwh> cfbolz: no, i had to buy a new one
[15:05] <cfbolz> darn
[15:05] <braintone> cfbolz - r21173 - merge as many blocks as possible per graph
[15:05] <cfbolz> mwh: where did you leave it?
[15:05] <mwh> cfbolz: i had it on the platform in düsseldorf hbf
[15:05] <mwh> i didn't have it on the train
[15:06] <cfbolz> argh
[15:06] <cfbolz> and it will probably turn up once you unpack your stuff :-(
[15:06] <mwh> it wasn't too bad, about 45 EUR
[15:06] <mwh> cfbolz: i doubt that, i pretty much unpacked on the train
[15:07] <cfbolz> that sucks
[15:07] <mwh> yes, i also lost my temporary bahncard
[15:08] <cfbolz> :-(
[15:08] <cfbolz> so much for saving some money
[15:08] <mwh> yeah
[15:08] <mwh> however by a complicated relay system, i can probably get my real bahncard mailed to me before i actually need to use it, so...
[15:09] <mwh> pypy/lib/pyontology ?
[15:09] Action: mwh heads off to read pypy-svn
[15:09] <cfbolz> what address did you give them?
[15:09] <mwh> my düsseldorf address
[15:09] <mwh> but another member of the group is going to use the room in january
[15:10] <cfbolz> good :-)
[15:10] <mwh> so he hopefully can fish it from my mailbox and mail it to me
[15:10] <mwh> december and january are going to involve a _lot_ of travelling for me
[15:10] <mwh> how was pypy-sync/
[15:11] <mwh> ?
[15:11] <cfbolz> short
[15:11] <cfbolz> :-)
[15:11] <cfbolz> no, it was ok
[15:11] <mwh> in a good way?
[15:11] <cfbolz> quite good actually
[15:11] <cfbolz> yes
[15:11] <mwh> cool
[15:12] <mwh> i see you've been backendoptimizing again :)
[15:13] <cfbolz> indeed :-)
[15:13] <cfbolz> eric discovered a potentially big speedup
[15:13] <cfbolz> (llvm is 6 times slower using it, but genc is missing an optimization, which I am now writing on graph-level)
[15:17] <braintone> cfbolz - r21174 - oops! don't merge chains of ifs, only chains of one if and elifs.
[15:17] <mwh> cool
[15:17] <mwh> easily explained?
[15:18] <cfbolz> yes, we discussed it on the sprint
[15:18] <cfbolz> the bytecode dispatch is done with a switch, basically
[15:18] <cfbolz> that's all
[15:18] <xorAxAx> that allows the compiler to implement a dispatch table
[15:19] <cfbolz> for now eric wrote code that replaces the dispatch by a long chain of if/elif
[15:19] <cfbolz> and we are writing a transformation from such a chain to a switch
[15:20] Nick change: pedronis_afk -> pedronis_reco
[15:21] <pedronis_reco> cfbolz: notice that the disp tbl is not the exctly the same for all frame subclss
[15:22] <braintone> ericvrp - r21176 - (ericvrp, cfbolz): adding a switch so that the if merging can be done for all graphs
[15:22] <cfbolz> pedronis_reco: yes, eric is doing it in the __initcls__. but he is really doing it by hand, I want to do the generic rtyper thing in the end
[15:22] <cfbolz> but for now it is a nice hack
[15:23] <pedronis_reco> ok, just that it makes the rtyper transf not only the most elegant sol but also the more robust
[15:24] <cfbolz> yes, I agree. but I also think that it makes sense to go for the quick hack first to see whether it is usefull at all
[15:25] <pedronis_reco> but indeed it would good to see things faster before "messing" with the rtyper
[15:25] Nick change: pedronis_reco -> pedronis_afk
[15:25] <cfbolz> yep, that's the plan. actually, we do see things faster with llvm, which has its own if->switch transformation
[15:27] <mwh> reco?
[15:28] <cfbolz> recovering
[15:28] <mwh> ah
[15:28] <mwh> good :)
[15:36] <braintone> cfbolz - r21178 - fixes to llinterp to be able to cope with the switches. make the tests use llinterp
[15:49] mwh (n=mwh@inat15.ams.attingo.nl) left irc: Read error: 113 (No route to host)
[16:00] <cfbolz> bye all! see you tonight
[16:01] <arigo> bye!
[16:01] cfbolz (n=cfbolz@p54ABB5B8.dip0.t-ipconnect.de) left irc: "Leaving"
----- silence for 17 minutes ----- [16:18] aleale (n=andersle@83.72.68.168.ip.tele2adsl.dk) left #pypy.
----- silence for 49 minutes ----- [17:07] arigo (n=arigo@c-188b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "[x]chat"
[17:14] odie (n=odie@62-2-77-204.business.cablecom.ch) left #pypy.
[17:19] sabi (i=njriley@shrug.csl.uiuc.edu) left irc: Remote closed the connection
[17:20] sabi (n=njriley@frey.cs.uiuc.edu) joined #pypy.
[17:25] adim (n=adim@logilab.net2.nerim.net) left #pypy.
----- silence for 55 minutes ----- [18:20] _hannes (n=yuuhu@i577B45DF.versanet.de) joined #pypy.
[18:31] <stakkars> has anybody seen mwh? Got a problem with signals and VC8.0
[18:36] nik_ (n=nik@132.207.79.83.cust.bluewin.ch) left irc: Read error: 110 (Connection timed out)
[18:37] nik_ (n=nik@51.221.78.83.cust.bluewin.ch) joined #pypy.
[18:44] <stakkars> solved - used a patch from CCP
[18:46] <xorAxAx> CCP?
[18:47] <stakkars> http://www.ccpgames.com/company/contact.asp
[18:47] <xorAxAx> ah
----- silence for 1 hr and 39 minutes ----- [20:26] ericvrp (n=eric@ericvrp.demon.nl) joined #pypy.
[20:31] ericvrp (n=eric@ericvrp.demon.nl) left irc: Client Quit
----- silence for 32 minutes ----- [21:03] sabi- (i=njriley@shrug.csl.uiuc.edu) joined #pypy.
[21:03] sabi (n=njriley@frey.cs.uiuc.edu) left irc: "back to shrug, finally"
[21:03] Nick change: sabi- -> sabi
----- silence for 1 hr and 56 minutes ----- [22:59] pedronis_afk (n=Samuele_@176.175.76.83.cust.bluewin.ch) left irc: "Chatzilla 0.9.68a [Firefox 1.0.4/20050511]"
[22:59] -ChanServ (ChanServ@services.)- You do not have channel operator access to [#pypy-sync]
----- silence for 35 minutes ----- [23:34] cfbolz (n=cfbolz@p54ABC2A7.dip0.t-ipconnect.de) joined #pypy.
[23:34] <cfbolz> hi!
[23:35] <stakkars> hi (yawn)
[23:44] <sabi> cfbolz: btw i got everything working
[23:44] <sabi> yesterday... happy :)
[23:45] <cfbolz> cool!
[23:46] <lac> is armin still in Gbg?
[23:47] <cfbolz> yes
[23:47] <lac> because it is snowing. :-)
[23:47] <lac> Let us hope he does not sleep through it.
[23:47] <cfbolz> hehe
[23:48] <sabi> i dunno what to do about my changes (--usemodules and --tsc), i'm not sure if they are worth submitting, but i could if it is not too much trouble
[23:48] <cfbolz> --tsc?
[23:48] <sabi> like --with-tsc for CPython
[23:49] <sabi> gives per-bytecode timings
[23:49] <cfbolz> hm, sounds interesting
[23:49] <cfbolz> more benchmarks :-)
[23:49] <cfbolz> is it even translatable?
[23:49] <cfbolz> (I don't know what --with-tsc does for CPython)
[23:49] <sabi> it uses processor cycle/timestamp counters
[23:50] <sabi> >>>> import sys; sys.settscdump(True)
[23:50] <sabi> opcode=100 t=0 inst=23397
[23:50] <sabi> opcode=83 t=0 inst=427
[23:50] <sabi> etc.
[23:50] <sabi> (t=X indicates ticked on that opcode)
[23:51] <xorAxAx> but it just works for opcodes that are faster than ~ 1 second, right? :-)
[23:51] <sabi> xorAxAx: indeed :)
[23:51] <xorAxAx> so imagine a busy machine ... :-)
[23:51] <sabi> well, i could use long longs with about 2 lines of code change
[23:52] <sabi> i'm not sure what happens though, it might slow it down quite a bit to go back and forth to python longs
[23:52] <cfbolz> sounds very interesting. could you send a patch? (whether long long or not doesn't matter much)
[23:52] <sabi> cfbolz: sure, where to send?
[23:52] <cfbolz> just to pypy-dev
[23:52] <sabi> ok
[23:52] Action: sabi prepares
[23:53] <cfbolz> or, if you plan to do more, just apply for checkin rights
[23:53] <sabi> how to do that?
[23:54] <cfbolz> ask michael/holger nicely
[23:54] <cfbolz> :-)
[23:54] <sabi> ahh
[23:54] <sabi> well i'll just get this patch ready first :)
[23:54] <cfbolz> cool
[23:54] <sabi> michael did some of the --with-tsc stuff for CPython so he will at least know what it is :)
[23:55] <cfbolz> if you really intend to use pypy in your thesis and plan do work a bit on/with it you should probably get checkin rights -- if you promise to adhere to the coding guide and if MIT license is fine for you
[23:56] <sabi> cfbolz: i do, and i will
[23:56] <stakkars> amen
[23:56] <lac> where are you doing this thesis?
[23:56] <sabi> uiuc.edu
[23:56] <cfbolz> sabi: and if you write tests, of course :-)
[23:56] <sabi> cfbolz: haha. ok. :)
[23:57] <sabi> when i start messing with data structures i think tests will be rather important
[23:57] Action: sabi is currently wrestling with memory dumps from opcode execution
[23:57] <cfbolz> tests are _always_ important
[23:58] <sabi> i don't have much experience with test-driven development but i will try :)
[23:58] <lac> in 2 weeks you won't be able to stand working any other way.
[23:58] <lac> Plus it is incredibly useful for the rest of us to figure out exactly what you were trying to do when you did this thing that didn't work.
[23:59] <sabi> would it be a problem if i used a branch for my work?
[23:59] <sabi> right now i am using svk and it is very flaky
[23:59] <lac> which is often the illuminatiion we need.
[23:59] <cfbolz> sabi: this should probably be discussed with more developpers
[00:00] --- Fri Dec 16 2005