#pypy IRC log for Wednesday, 2011-04-13

pyrony (~epic@office1.klout.com) left irc: 00:02
dgl (~dgl@109.86.165.231) joined #pypy.00:05
ltbarcly (~Adium@67.228.133.35-static.reverse.softlayer.com) left irc: Ping timeout: 248 seconds00:10
Trundle (~andy@python/site-packages/trundle) left irc: Remote host closed the connection00:26
asabil (~asabil@48.249.16.62.customer.cdi.no) left irc: Read error: Operation timed out00:26
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy.00:37
daniloaf (~daniloaf@150.165.63.86) left irc: Quit: Saindo00:49
etrepum (~bob@accessnat4.mochimedia.net) left irc: Ping timeout: 248 seconds00:51
derdon (~derdon@p54A6D919.dip.t-dialin.net) left irc: Ping timeout: 276 seconds01:00
derdon (~derdon@p54A6D919.dip.t-dialin.net) joined #pypy.01:03
aat (~aat@rrcs-184-75-54-130.nyc.biz.rr.com) left irc: Quit: Computer has gone to sleep.01:30
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep.01:32
dgl (~dgl@109.86.165.231) left irc: Quit: Leaving...01:34
derdon (~derdon@p54A6D919.dip.t-dialin.net) left irc: Ping timeout: 248 seconds01:41
derdon (~derdon@p54A6D919.dip.t-dialin.net) joined #pypy.01:44
derdon (~derdon@p54A6D919.dip.t-dialin.net) left irc: Remote host closed the connection01:49
derdon (~derdon@p54A6D919.dip.t-dialin.net) joined #pypy.01:49
Nick change: Varriount -> Varraway01:53
whyking (~quassel@ip68-14-22-39.ri.ri.cox.net) left irc: Remote host closed the connection01:53
derdon (~derdon@p54A6D919.dip.t-dialin.net) left irc: Ping timeout: 276 seconds01:54
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) joined #pypy.01:58
nettok (~quassel@200.119.190.80) joined #pypy.01:58
Nick change: Varraway -> Varriount02:10
Nick change: Varriount -> Varraway02:11
nettok (~quassel@200.119.190.80) left irc: Remote host closed the connection02:19
nettok (~quassel@200.119.190.80) joined #pypy.02:19
nettok (~quassel@200.119.190.80) left irc: Client Quit02:23
nettok_ (~quassel@200.119.190.80) joined #pypy.02:23
bobbyz (~bobbyz@12.131.26.130) left irc: Ping timeout: 246 seconds02:24
diffoperator (cb6ef315@gateway/web/freenode/ip.203.110.243.21) joined #pypy.02:30
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) left irc: Read error: Connection reset by peer02:35
bobbyz (~bobbyz@c-24-14-151-193.hsd1.il.comcast.net) joined #pypy.02:36
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) joined #pypy.02:52
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) left irc: Client Quit02:55
verte (~verte@python/site-packages/verte) left irc: Quit: ~~~ Crash in JIT!02:55
etrepum (~bob@c-67-180-34-190.hsd1.ca.comcast.net) joined #pypy.03:05
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) joined #pypy.03:24
cafesofie (~cafesofie@ool-4a5a6ee5.dyn.optonline.net) left irc: Remote host closed the connection03:33
qbproger (~qbproger@184.91.177.52) left irc: Remote host closed the connection03:39
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) left irc: Quit: Ex-Chat04:19
zrbecker (~zrbecker@ip98-164-227-211.oc.oc.cox.net) joined #pypy.04:41
lac (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Read error: Connection reset by peer04:44
lac (~quassel@c-c4c4e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.04:46
nettok_ (~quassel@200.119.190.80) left irc: Ping timeout: 248 seconds04:51
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy.05:18
ahmed-tux (~kvirc@41.140.47.12) left irc: Ping timeout: 246 seconds05:28
ahmed-tux (~kvirc@41.140.44.4) joined #pypy.05:41
mat^2 (~mathias@212.130.113.35) left irc: Ping timeout: 276 seconds05:50
sakesun (~sakesun@ppp-124-121-106-92.revip2.asianet.co.th) joined #pypy.05:53
antocuni (~antocuni@host188-86-dynamic.7-79-r.retail.telecomitalia.it) joined #pypy.05:55
verte (~verte@python/site-packages/verte) joined #pypy.06:08
kleptog (~kleptog@86.93.96.92) joined #pypy.06:27
antocunihi06:30
kleptoghoi06:30
verteHi Anto!06:30
kleptogis afa == amuray?06:30
antocuniyes06:30
kleptogok06:32
kleptogthanks06:32
verte (~verte@python/site-packages/verte) left irc: Ping timeout: 258 seconds06:43
verte (~verte@python/site-packages/verte) joined #pypy.06:43
fijalhi06:46
antocunihi maciek06:48
antocunipff, "hg pull failed" for nightly tests :-(06:48
fijaldid it?06:49
fijalit run some06:49
antocuniah no06:49
antocuniit's old06:49
antocuniI think that the summary page should start with all the "H" for old days turned on06:50
fijalI think it should not :)06:50
kenaan12fijal default 113ecefd7254ef 15/pypy/rlib/rsre/test/test_zjit.py: fix the test06:51
kenaan12fijal default 11661e61aa9cf2 15/: merge06:51
fijalantocuni: can we remove test_pypy_c now?06:51
fijalor does it merely run test_pypy_c_new?06:51
antocunifijal: why not? Is it so important to know which tests failed 5 days ago?06:51
antocunifijal: no, there are still tests which needs to be ported to test_pypy_c_new06:51
fijalok06:52
antocunieven a lot of those, that's why I didn't feel like finishing the work :)06:52
Action: antocuni should do it at some point06:52
fijalwhat with those that are repeats06:53
fijal?06:53
antocuniyou mean the tests which have already been ported to test_pypy_c_new?06:54
fijalyes06:54
antocuniyes, I think we can individually kill thos06:54
antocunithose06:54
fijalcause we got double failures06:55
fijalone harder to understand than other06:55
antocuniI hope that the one in test_pypy_c is harder :-)06:56
fijal:]06:56
kleptog (~kleptog@86.93.96.92) left irc: Ping timeout: 248 seconds06:58
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) joined #pypy.07:01
kenaan12antocuni default 1181e98ec04e5d 15/pypy/module/pypyjit/test/test_pypy_c.py: kill all these tests, which have already been ported to test_pypy_c_new07:03
verte (~verte@python/site-packages/verte) left irc: Remote host closed the connection07:04
verte (~verte@python/site-packages/verte) joined #pypy.07:04
antocuniyes, there are still 24 tests left in the old test_pypy_c07:05
fijalcool, thanks07:08
fijalI'll fix the failing one07:08
fijal(and unskip one)07:08
antocunieven more cool :-)07:08
fijalI wonder if we can have pypy run nightly translations07:09
fijalantocuni: how hard it is to fix all tests and release 1.5?07:11
antocunino clue, I've not looked into the failing tests for a while07:12
antocuniI suppose that ctypes is a bit annoying07:12
fijalmaybe we should?07:12
fijalyes, and distutils as well07:12
antocunialso, we should decide whether we want to include jitypes2 or not in 1.507:13
antocuniarmin said he wants to review it before merging07:13
fijalwhat's the current status?07:14
carljmurg. i need to find some time to look at those failing distutils tests again (and the merge-stdlib branch)07:14
fijalcarljm: hi07:15
fijalwe didn't decide what to do with your branch did we?07:15
fijalor what's it's status anyway?07:15
antocunifijal: it seems to be working, although the speedup is not as high as expected, because we need to allocate all the frames whenever we do an ffi call07:15
carljmfijal: status is i need to get back to it and figure out if it breaks anything or not07:15
fijalantocuni: and we do it because?07:16
carljmI was having confusing test-failures and trunk was a bit unstable during sprints so I wasn't sure if the failures were even my fault.07:16
antocunifijal: because ffi calls are now call_release_gil, which has this effect07:16
fijalhow call_release_gil forces frames?07:16
antocuni(because it might invoke callbacks)07:16
fijalyes, sure07:17
fijalhow is different than call_may_force?07:17
antocunifijal: they are not really forced, they are "just" allocated at the end of the loop07:17
fijalok, but that has a solution07:18
fijalwell, but those are virtual frames, not virtualizable frames, right?07:18
antocuniyes07:18
fijaldo you happen to have exceptions?07:18
fijalhandling of exceptions07:19
fijalbecause if not it's as simple as clearing the frame somewhere07:19
fijalin leave_frame or so07:19
antocuniactually, I don't know :-)07:20
antocuniwhat happens if you raise an exception inside a ctypes callback on CPython?07:20
kenaan12fijal default 114be4cb558143 15/pypy/module/pypyjit/test_pypy_c/test_pypy_c_new.py: Unskip one test, keep one skipped until we merge quasi-immut fields and fix one 64bit test07:20
kenaan12fijal default 117f8040abfc71 15/pypy/module/pypyjit/test/test_pypy_c.py: merge07:20
fijalit's caught, displayed and forgot07:20
fijalwhat else you can do?07:20
fijalanyway, I'm talking about different level of exceptions07:20
antocuniah, you mean rpython exceptions07:21
fijalno07:21
fijalhttp://paste.pocoo.org/show/370820/07:21
fijalthis is the case for which you need to allocate this frame07:21
antocuniok, but what has it to do with ffi calls?07:23
fijalthat should be my question07:26
fijalif you don't do it you don't need to allocate the frame07:26
fijalfind out why the reference survives and clear it then07:27
fijalcall_release_gil has nothing to do with it07:27
antocuniuhm... what I can say is that before armin switched to call_release_gil, the frame was not created07:28
antocunibut maybe it's unrelated and there was some other change in between07:28
fijalit might be related07:32
fijalbut it should not be a bit07:32
fijalI know, virtualrefs are working in strange ways07:32
fijalwhat I'm saying is that call_release_gil doesn't create a need for the frame to be allocated07:33
fijalif it does, it's accidental and should be addressed07:33
antocuniyes, makes sense07:33
antocuniI just did not investigate much07:33
fijalok07:35
fijalneed help?07:35
fijalwell, in short all I'm saying is that it should not allocate the frame :)07:35
fijalso how does the trace look like?07:35
antocunilet me find an example07:37
antocunifijal: this is the code07:39
antocunihttp://paste.pocoo.org/show/370822/07:39
antocuniand this is the trace: http://paste.pocoo.org/show/370823/07:40
fijalp35 = new_with_vtable(19535888)07:42
fijalwhat's this?07:42
antocuniit's the virtualref07:42
fijalright07:43
fijalwe don't even need this frame, it could be hidden ;-)07:43
antocunihidden?07:43
fijallike not put on top of framestack07:44
fijalthe way he hide frames of appcode07:44
fijalappexec07:44
fijalwell, an obscure hack07:44
antocuniwhere is this hack, btw?07:45
fijalI'm not sure it even really prevents07:45
fijalanything07:46
fijalbut there is hidden_applevel on code07:46
fijal(it could)07:46
antocuniah, I see07:46
antocuniis it used to avoid to have them in the traceback07:47
diffoperator (cb6ef315@gateway/web/freenode/ip.203.110.243.21) left irc: Ping timeout: 252 seconds07:47
fijalyes07:48
fijalnot sure if it's worth it, but then again we don't need them to be alive at the end of the loop07:49
fijalso it's a matter of careful cleaning of frame reference from *somewhere*07:49
michaelh (c1beac85@gateway/web/freenode/ip.193.190.172.133) joined #pypy.08:02
Nick change: DasIch_ -> DasIch08:12
kirmawas the change for "branch unlikely taken" an assembler level hint or what?08:20
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) left irc: Ping timeout: 246 seconds08:20
fijalkirma: yop08:22
fijaldidn't seem to work08:22
kirmaassembler level hints are ignored by modern (intel) CPUs, I believe they are even in the random state they were left by previous branch predictor at that spot08:23
kirmaalso, branch direction (forward or backward) doesn't matter to the predictors nowadays if I remember right08:23
kirmaonly thing one can do is reduce amount of branches, and keep likely path executing in a "fall-through" manner, but I suppose those are pretty well taken care of with pypy jit...08:24
kirmasome other architectures/microarchitectures might benefit from hinting, but intel core or newer certainly not.08:25
fijalI'm a bit afraid that our loops are too long08:26
fijalfor branch predictors08:26
kirmaI believe intel has thought out quite a bit before dropping branch predictor hinting from their hardware08:29
kirmawhen in doubt, first check http://www.agner.org/optimize/microarchitecture.pdf :)08:29
fijalwell, yes08:29
fijalbut they also usually have certain model in mind08:29
kirmatrue of course08:30
kirmaI bet they also consider typical jvm/javascript JIT result code as a benchmark target08:30
antocuniprobably not javascript benchmarks, they have been available only lately08:31
antocunijavascript JITs, I mean08:31
asabil (~asabil@48.249.16.62.customer.cdi.no) joined #pypy.08:31
kirmagenerating dynamic jumps could be much worse than having relatively large number of likely-not-taken conditional branches08:38
kirmaif there are lots of them, or they are truly dynamic08:38
fijalwe have lots of them08:40
fijalbut they're very unlikely08:40
fijalall of them08:40
fijalor most08:40
kirmaI've also felt despair of this... difficultatem facit doctrina08:43
kirmaignorance is bliss :)08:43
jonanin (~jonanin@24-183-48-154.dhcp.mdsn.wi.charter.com) left irc: Ping timeout: 258 seconds08:44
antocunifijal: btw, even a blog post like "don't worry, we are working on pypy/numpy, but it takes time" would be useful, IMHO08:58
antocuni(re: your comment on the blog)08:59
jonanin (~jonanin@24-183-48-154.dhcp.mdsn.wi.charter.com) joined #pypy.08:59
fijalok08:59
fijalI can even show some results08:59
fijalthey're not as awesome though :)08:59
antocunieh :-)08:59
fijalok, I'll stop waiting for them to be more awesome08:59
fijalthey can be 2x easily ;-)08:59
antocunifijal: and you don't know how to make them better, or it's just that you didn't have time?09:00
fijalI was on holiday09:00
fijalto make them better is to use SSE09:00
fijaland I have a dayjob09:01
fijalit's kind of easy09:01
antocunisure09:01
fijalbut lots of work09:01
antocunimy question was "do you have a plan or not"09:01
fijalyeah09:01
antocunicool09:01
witulski (~stupsi@fwstups.cs.uni-duesseldorf.de) joined #pypy.09:10
witulski (~stupsi@fwstups.cs.uni-duesseldorf.de) left irc: Client Quit09:11
witulski (~stupsi@fwstups.cs.uni-duesseldorf.de) joined #pypy.09:13
voidspace (~voidspace@python/psf/voidspace) joined #pypy.09:18
Arnold (~Arnold@86.122.210.12) joined #pypy.09:18
asabil (~asabil@48.249.16.62.customer.cdi.no) left irc: Ping timeout: 276 seconds09:23
witulski (stupsi@fwstups.cs.uni-duesseldorf.de) left #pypy.09:30
mwhudson_ (~mwh@121-73-77-183.cable.telstraclear.net) joined #pypy.09:34
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) left irc: Quit: Leaving09:44
efaust (~efaust@unaffiliated/efaust) joined #pypy.09:44
efaust (efaust@unaffiliated/efaust) left #pypy.09:45
verte (~verte@python/site-packages/verte) left irc: Ping timeout: 260 seconds09:52
squiddy (~squiddy@x027.wh17.tu-dresden.de) joined #pypy.09:54
verte (~verte@python/site-packages/verte) joined #pypy.09:58
voidspace_ (~voidspace@python/psf/voidspace) joined #pypy.10:08
voidspace (~voidspace@python/psf/voidspace) left irc: Quit: Uhm... gotta go10:08
Nick change: voidspace_ -> voidspace10:08
apoirier_away (~apoirier@sakura.nagare.org) joined #pypy.10:15
Nick change: apoirier_away -> apoirier10:15
antocuniuhm, I wonder if using this could give any speedup to pypy10:30
antocunihttp://google-opensource.blogspot.com/2011/04/introducing-cityhash.html10:30
jcea_BT (~jcea@jabber.hst.ru) joined #pypy.10:31
ronnyantocuni: what for?10:31
antocunironny: the hashing functions for strings10:31
Action: antocuni --> lunch10:31
fijaleasy to test :)10:32
ronnyantocuni: looks only suitable for strings tho, and dont strings cache the hash anyway?10:32
fijalronny: they do10:33
Trundle (~andy@scc-wkit-clx-208-105.scc.kit.edu) joined #pypy.10:34
Trundle (~andy@scc-wkit-clx-208-105.scc.kit.edu) left irc: Changing host10:34
Trundle (~andy@python/site-packages/trundle) joined #pypy.10:34
lizardo (~lizardo@189.2.128.130) joined #pypy.10:35
kenaan12fijal out-of-line-guards-2 11bb74a3f1a9ae 15/pypy/jit/metainterp/quasiimmut.py: typo10:35
fijaleh10:45
fijalarmin lied a bit10:45
kenaan12fijal out-of-line-guards-2 11df9144938d0a 15/pypy/jit/metainterp/test/test_quasiimmut.py: write a failing test10:46
cfbolzantocuni: I fear that string hashing is very rare, most of the time it hits the cache10:48
fijalwe can check how many times it's called10:49
kenaan12fijal out-of-line-guards-2 11463f4df577de 15/pypy/jit/metainterp/test/test_quasiimmut.py: Write another failing test for missing piece of invalidating in the backend10:49
fijalit's easy by doing valgrind10:49
fijalyou can't store the hash on char*10:49
fijalI wonder if a good benchmark can come out of this10:49
cfbolzfijal: you mean if you re-implement it in pure python?10:50
fijal"pypy is faster than c++"10:50
cfbolzno way10:50
fijalcfbolz: I meant a benchmark that shows our dictionaries are faster than c++ because we cache hashes10:50
fijalno?10:50
cfbolzah10:50
cfbolzmaybe10:50
cfbolzbut well10:50
cfbolzapples and oranges10:51
fijalthat's a valid usecase10:51
fijalyes and no10:51
fijal"how fast can you use a builtin dictionary"10:51
fijalis something pretty valid10:51
verteconsidering the way people worship STL, it would be interesting10:55
squiddy (~squiddy@x027.wh17.tu-dresden.de) left irc: Remote host closed the connection10:56
fijalcfbolz: we also win by the immutability of strings10:56
fijalbut that's really our win10:57
Trundle (~andy@python/site-packages/trundle) left irc: Remote host closed the connection11:34
Rhy0lite (~dje@nat/ibm/x-ibciptyegiabtcdp) joined #pypy.11:56
intgr_ (~ack@zombie.life.ee) joined #pypy.12:09
squiddy (~squiddy@x027.wh17.tu-dresden.de) joined #pypy.12:10
ousadois that to say you can't do exactly the same thing in c++?12:10
derdon (~derdon@p54A6EB22.dip.t-dialin.net) joined #pypy.12:11
fijalousado: not in STL at least12:12
kenaan12fijal out-of-line-guards-2 116d4d86899596 15/pypy/jit/: Progress on out-of-line-guards-2. This is the poor-man's version, we can do better.  * Record a guard ...12:12
vertesure you can. but it's effort.12:12
intgr_ (~ack@zombie.life.ee) left irc: Remote host closed the connection12:12
vertewhat you can't do is convince C++ people to pay for an extra int to store the precomputed hash!12:12
fijalverte: hey, mutable strings12:12
intgr_ (~ack@zombie.life.ee) joined #pypy.12:12
Action: verte shudders12:13
intgr (~ack@zombie.life.ee) left irc: Ping timeout: 260 seconds12:13
fijalok, armin convinced me to do the simplest possible thing for out of line guards :)12:15
fijal8G of RAM is awesome :)12:16
whyking (~quassel@ip68-14-22-39.ri.ri.cox.net) joined #pypy.12:17
Da_Blitzis there anyway to parallelize the initial build process and not the gcc compile?12:18
antocuniDa_Blitz: no, the initial phase of translation is inherently sequential12:19
vertethere is not.12:19
derdon (~derdon@p54A6EB22.dip.t-dialin.net) left irc: Remote host closed the connection12:19
Da_Blitzin that case12:19
Action: Da_Blitz adds another 8GB of ram to the list12:19
derdon (~derdon@p54A6EB22.dip.t-dialin.net) joined #pypy.12:19
fijalwell12:20
fijalnot inherently, but with the GIL it's really hard to do something else12:20
antocunifijal: well, annotation *is* sequential12:20
ousadoyeah, the ugrade to 8G RAM is the best computer-related buy I ever did 12:20
fijalantocuni: no, you have multiple pending blocks12:20
antocunialthough with clever locks you could maybe parallelize it a bit12:21
antocuniyes ok12:21
Da_Blitzi just ahve a bunch of unused cores during compalation and unfortuantly a compile can use up to 4.5GB of ram12:21
fijalyes, there are mutable structures, true12:21
Da_Blitzwill just upgrade the ram and do more translations at a time12:21
antocunifijal: everything is parallelizable in some way or the other12:21
antocuni(sequentially is a special form of parallelization :-))12:21
fijalantocuni: right, but translation is easier than a lot of other things12:21
fijaland harder than say raytracing12:22
fijalfor example inlining and such is almost trivially parallelizable12:22
Da_Blitzout of intrest, how long does somthing like ./translate.py -O jit --make-jobs=9 ./targetpypystandalone.py --translationmodules  take for you?12:22
fijal30-40min on tannit I think12:23
fijalif you use pypy12:23
Da_Blitzi am, and that matches about what i am getting12:23
Da_Blitzi jsut saw mention of 20 minute translation times and i am now wondering if that info is out of date12:24
Da_Blitzi thought i had been doing somthing wrong12:24
derdon (~derdon@p54A6EB22.dip.t-dialin.net) left irc: Ping timeout: 240 seconds12:24
fijalannotation is taking a shitload of time these days12:24
fijal55min on my laptop12:25
Da_Blitzcool so its not just me12:25
verteantocuni: it's really the opposite that is true. even if you generate each bit of output in parallel, as a big function of the input, the amount of time it takes for data to travel from source to destination makes it appear sequential.12:26
Da_Blitzone or two other quick questions while i am at it, does anyone know what the translation/build flags are for the interpreters on speed.pypy.org (for refrence)12:26
Rhy0litedo you assume you can write the output in parallel?12:26
Da_Blitzand is there a list of things done to package for a release12:26
antocuniDa_Blitz: I think that the standard time for a translation on tannit is ~2600 seconds, i.e. 43 minuts12:27
antocuniminutes12:27
verteantocuni: although there is a lot of parallelism there to extract, I think. (or, hope, because I've been working on extracting just that.)12:27
antocuniverte: are you talking in general or for the specific case of pypy translation?12:28
fijalDa_Blitz: -Ojit and yes12:28
Da_Blitzthanks and thanks12:28
antocuniDa_Blitz: re 4.5 GB of RAM12:28
antocuniby default, pypy reserves a fraction of the total ram available for its gc12:29
Da_Blitzthats peak usage during a translation12:29
Da_Blitz64bit i7 box12:29
antocuniyes, but what I'm saying that you can translate it even with 4 GB of RAM12:30
antocuniand in that case, the peek usage is lower12:30
antocuniat the price of more frequent major collections12:30
Da_Blitzi tried running 2 builds in parralell and had the kernel OOM killer come in at one point12:30
Da_Blitzkilled one build job12:30
fijalyou have to pass GC flags by hand12:31
fijalotherwise it assumes it can have all the RAM12:31
Da_Blitzi actually use the RSS as a way to guage the status of the build job as it increases in a fairly liner manner12:31
Da_Blitzah12:31
verteantocuni: in general12:31
Da_Blitzthats an intresting peice of info12:31
Arnold (Arnold@86.122.210.12) left #pypy ("Leaving").12:31
antocuniDa_Blitz: you can try to use the PYPY_GC_MAX env variable12:32
Da_Blitzwould be nice if i could pass that into pypy like in jvm12:32
antocunilike PYPY_GC_MAX=4GB12:32
fijalantocuni: less12:32
fijal3 or 2G12:32
Da_Blitz--max-ram=4GB or somthing12:32
Da_Blitzand --reserve=128MB12:32
fijalyou want12:33
fijalPYPY_GC_MAX_DELTA=500M12:33
Da_Blitzthis is in the header of minimark.py correct?12:34
fijalyou want to pass this as an evironment variable12:34
antocuniDa_Blitz: yes12:34
fijalantocuni: that was "yes" to what?12:35
antocuni<Da_Blitz> this is in the header of minimark.py correct?12:35
fijalwell, so the answer is no12:36
kkris (~kris@93-82-34-202.adsl.highway.telekom.at) joined #pypy.12:36
fijalor the explanation is there, yes12:36
Da_Blitzi think that alone justifies pypy's use on servers12:38
fijalDa_Blitz: "that alone" being?12:39
Da_Blitzbeing able to enforce maximum memory usage12:39
Da_Blitzhas a nicer failure mode than rlimits12:39
fijalI think a failure mode is MemoryError12:40
fijalunless you're unlucky, then it's a segfault12:40
fijalalso, it's not a hard limit12:40
fijalit doesn't count all possible mem usages12:40
fijalonly those tracked by the GC12:40
Da_Blitzwell rlimit will just refuse a malloc, tends to crash most apps12:41
Da_Blitztoo many programs not checking hte return value of malloc12:41
fijalnot being able to allocate memory will also crash most python apps :)12:42
fijalalthough GC will try a bit harder if it's near it's limit12:42
Da_Blitztrue, but i canmake the rlimit a couple MB higher than pypy's limit and let pypy deal with it12:42
mvt (~mvantelli@53530442.cm-6-4a.dynamic.ziggo.nl) joined #pypy.12:42
Action: Da_Blitz comes from a web hosting background12:42
Da_Blitzseen more than one fork bomb or person try and eat all the ram12:43
fijalekhem12:45
fijalantocuni: I fear improvements to hash function would help, but that's because multimethods suck12:45
squiddy (~squiddy@x027.wh17.tu-dresden.de) left irc: Remote host closed the connection12:46
fijalI'm at 2e-9 characters considered in _hash_string12:47
fijal(running translate.py --annotate)12:47
whyking__ (~quassel@ip68-14-22-39.ri.ri.cox.net) joined #pypy.12:47
fijalcrap I overflowed 32bit int12:48
whyking (~quassel@ip68-14-22-39.ri.ri.cox.net) left irc: Ping timeout: 240 seconds12:48
DanielHolth (~dholth@ip98-180-34-112.ga.at.cox.net) joined #pypy.12:48
fijalalthough currently hashing a character takes about 2 clock cycles12:52
fijal(almost exactly)12:52
fijalso I really wonder if we can win anything12:52
verteperhaps you could hash a word at a time?12:54
fijalI would kind of expect a smart enough compiler to do it12:55
fijalor even 128 bit12:55
fijalit's a very tight loop12:55
kost-bebix (~kost-bebi@195.177.74.243) joined #pypy.12:55
verteI wonder if gcc generates duff's device for such tight loops12:57
fprimex (~fprimex@brent-macbook.sc.fsu.edu) joined #pypy.12:58
antocunifijal: 0.0000000002 characters? :-)12:58
fijalantocuni: ?13:10
fijalverte: is duff device faster than SSE?13:10
antocuni2e-9 ==  0.000000000213:10
fijalyeas13:10
fijalthat'13:10
vertefijal: you could use the two together13:10
fijaland what's the unit?13:10
fijalverte: is it any faster though?13:11
fijalwith branch prediction and whatnot I would think no13:11
verteyeah, you probably do get the increment for free13:11
fijalI'm unhappy with armin removing ropaque13:11
fijaland inventing hacks instead13:11
vertesince most CPU are 2- or 3- issue13:12
fijalso hashing seems to take on the order of 9s during annotation13:21
verte:)13:23
cfbolzfijal: seems not a lot13:24
fijalcfbolz: well, it really takes little time to hash13:24
kenaan12fijal out-of-line-guards-2 11d5cf3b70d497 15/pypy/jit/: write a test and note first problem13:24
fijalcfbolz: the simplest version of out of line guards seems to be done13:25
fijalexcept x86 backend13:25
fijalI'll try to finish maybe tonight, if not tomorrow13:25
cfbolzfijal: what is not measured now is how much time we lose due to hash collisions because of a bad hash function13:25
fijalyes13:25
voidspace (~voidspace@python/psf/voidspace) left irc: Quit: voidspace13:28
squiddy (~squiddy@x027.wh17.tu-dresden.de) joined #pypy.13:30
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) joined #pypy.13:31
lucian (~lucian@78-86-217-168.zone2.bethere.co.uk) joined #pypy.13:34
Shanita (~John@osbk-4db06cfe.pool.mediaWays.net) joined #pypy.13:38
Moku (~John@osbk-4db0647a.pool.mediaWays.net) left irc: Ping timeout: 240 seconds13:39
aat (~aat@rrcs-184-75-54-130.nyc.biz.rr.com) joined #pypy.13:48
sakesun (~sakesun@ppp-124-121-106-92.revip2.asianet.co.th) left irc: Remote host closed the connection13:49
whyking__ (~quassel@ip68-14-22-39.ri.ri.cox.net) left irc: Ping timeout: 276 seconds13:53
derdon (~derdon@p54A6EE72.dip.t-dialin.net) joined #pypy.13:53
voidspace (~voidspace@87-194-212-65.bethere.co.uk) joined #pypy.13:53
voidspace (~voidspace@87-194-212-65.bethere.co.uk) left irc: Changing host13:53
voidspace (~voidspace@python/psf/voidspace) joined #pypy.13:53
apoirier (apoirier@sakura.nagare.org) left #pypy ("Leaving...").13:57
voidspace (~voidspace@python/psf/voidspace) left irc: Ping timeout: 252 seconds13:58
bobbyz_ (~bobbyz@12.131.26.130) joined #pypy.13:59
voidspace (~voidspace@87-194-212-65.bethere.co.uk) joined #pypy.14:00
voidspace (~voidspace@87-194-212-65.bethere.co.uk) left irc: Changing host14:00
voidspace (~voidspace@python/psf/voidspace) joined #pypy.14:00
DasIch (~DasIch@p4FFDFF62.dip.t-dialin.net) left irc: Quit: Leaving14:11
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy.14:13
kenaan12cfbolz extradoc 11f563410ac3de 15/talk/icooolps2011/paper.tex: some comments from Peng Wu14:18
lucian (~lucian@78-86-217-168.zone2.bethere.co.uk) left irc: Remote host closed the connection14:20
kenaan12cfbolz extradoc 11fd57ef390cb4 15/talk/icooolps2011/: comments by rhy0lite14:26
witulski (~stupsi@fwstups.cs.uni-duesseldorf.de) joined #pypy.14:30
Arfrever (~Arfrever@gentoo/developer/Arfrever) joined #pypy.14:32
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) joined #pypy.14:46
harrison (~sr@adsl-76-217-35-217.dsl.chcgil.sbcglobal.net) joined #pypy.14:48
vertewhat is the easiest way to examine the output of test_all ?14:55
cfbolzverte: examine?14:59
antocunipff, translation is broken on jitypes2: http://paste.pocoo.org/show/371020/15:02
verteI'd really just like a list of the tests that failed. I haven't sat through the whole thing before, does it give you a neat list at the end, or a million tracebacks?15:02
cfbolzverte: the latter15:03
cfbolzverte: but there is a way to get more structured output15:03
cfbolztry --help15:03
vertewill do.15:03
vertelike right now I see test_zpy failing - probably for configuration reasons unrelated to my latest changes.15:04
derdon (~derdon@p54A6EE72.dip.t-dialin.net) left irc: Remote host closed the connection15:07
derdon (~derdon@p54A6EE72.dip.t-dialin.net) joined #pypy.15:07
derdon (~derdon@p54A6EE72.dip.t-dialin.net) left irc: Ping timeout: 240 seconds15:12
verteit segfaults with only 4 gig of ram anyway - hit 24 gig of virtual memory beforehand15:18
cfbolzverte: you need to run it per-dir15:18
verteis there an option for that, or manually?15:20
cfbolzno clue how the buildbots do it15:21
kenaan12cfbolz extradoc 115ec3af1eeb7e 15/talk/icooolps2011/: change x = hint(x, promote=True) to just promote(x) to reduce confusion15:23
kenaan12cfbolz extradoc 111f698977d63c 15/talk/icooolps2011/paper.tex: michael's notes15:23
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) left irc: Ping timeout: 246 seconds15:30
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) left irc: Ping timeout: 246 seconds15:34
verte (~verte@python/site-packages/verte) left irc: Quit: ~~~ Crash in JIT!15:36
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) joined #pypy.15:38
etrepum (~bob@c-67-180-34-190.hsd1.ca.comcast.net) left irc: Quit: etrepum15:43
witulski (~stupsi@fwstups.cs.uni-duesseldorf.de) left irc: Quit: Leaving.15:43
mat^2 (~mathias@212.130.113.35) joined #pypy.15:50
arigato (~arigo@82.113.98.162) joined #pypy.15:58
zrbecker (zrbecker@ip98-164-227-211.oc.oc.cox.net) left #pypy ("Leaving").16:01
kost-bebix (~kost-bebi@195.177.74.243) left irc: Quit: kost-bebix16:05
kenaan12antocuni jitypes2 11489e9af0684e 15/pypy/module/pypyjit/test_pypy_c/test_pypy_c_new.py: add a test that fails if we do not emit CALL_RELEASE_GIL for _ffi calls16:23
kenaan12antocuni jitypes2 114aa00ab09876 15/pypy/module/pypyjit/test_pypy_c/test_pypy_c_new.py: try not to have newlines, to make merging easier16:23
kenaan12antocuni jitypes2 116ebb73be4f72 15/: merge heads16:23
kenaan12antocuni jitypes2 1183bc8bc305fb 15/pypy/module/pypyjit/test_pypy_c/test_pypy_c_new.py: this test hangs :-(16:23
antocuniarigato: I wrote a test to CALL_RELEASE_GIL (in 489e9af0684e)16:24
antocunihowever, it hangs :-(16:24
arigato:-/16:24
DasIch (~DasIch@p4FFDD7A8.dip.t-dialin.net) joined #pypy.16:24
arigatodoes it help if you remove "import time" from the threads?16:25
antocuniarigato: uhm... maybe it's not related to CALL_RELEASE_GIL16:25
arigato(it shouldn't I hope)16:26
antocuniit also hangs with a pypy-c-13434937a514, which is just before your checkin16:26
ronnyhmm, anything interesting about pypy i could show at the python barcamp in cologne this weekend?16:27
antocuniarigato: yes, it helps :-916:27
antocuni:-/16:27
antocuniwithout "import time", it doesn't hangs16:27
arigatoantocuni: ah16:27
rguillebert (~hardshoot@089-101-122219.ntlworld.ie) left irc: Ping timeout: 246 seconds16:27
antocunibut then I'm confused16:27
antocuninow even pypy-c-13434937a514 passes the test16:27
arigatonote that the libc sleep() is maybe dangerous to use like this; it says in BUGS that it may be implemented using SIGALRM16:27
arigatoI don't know exactly how this plays with signal processing of pypy16:27
arigatowell I suppose it works as expected in this case, but it's still marginally strange16:28
arigato...anyway, yes, I'm not surprized that you have this problem :-)16:29
antocuniah no16:29
antocunistrange16:29
antocunithe program which didn't hang was a single script which is the same as the test16:30
antocunibut the test still hangs, even without "import time" :-(16:30
antocunibah, I suppose I need to investigate further16:30
arigatorun also with --threshold and --trace-eagerness?16:30
antocuniaah16:31
antocuniI ran it with a threshold which is too high16:31
antocuniindeed, it still hangs16:31
antocuniso, the import is harmless16:31
arigatook16:32
antocuniok, I'll investigate more later/tomorrow16:33
harrison (~sr@adsl-76-217-35-217.dsl.chcgil.sbcglobal.net) left irc: Read error: Operation timed out16:33
Trundle (~andy@p5B13237F.dip.t-dialin.net) joined #pypy.16:36
Trundle (~andy@p5B13237F.dip.t-dialin.net) left irc: Changing host16:36
Trundle (~andy@python/site-packages/trundle) joined #pypy.16:36
rguillebert (~hardshoot@089-101-122219.ntlworld.ie) joined #pypy.16:40
hakanardorguillebert: have you reached some conclution about accommodation for the sprint?16:43
asabil (~asabil@195.159.219.65) joined #pypy.16:44
etrepum (~bob@38.102.129.100) joined #pypy.16:49
ltbarcly (~Adium@67.228.133.35-static.reverse.softlayer.com) joined #pypy.16:59
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) joined #pypy.17:00
daniloaf (~daniloaf@189.71.125.49) joined #pypy.17:01
cfbolzarigato: ping?17:07
voidspace (~voidspace@python/psf/voidspace) left irc: Read error: Connection reset by peer17:07
arigatopong17:07
voidspace (~voidspace@87-194-212-65.bethere.co.uk) joined #pypy.17:07
voidspace (~voidspace@87-194-212-65.bethere.co.uk) left irc: Changing host17:07
voidspace (~voidspace@python/psf/voidspace) joined #pypy.17:07
cfbolzarigato: one of the comments from somebody external who read the paper was that the usage of "pure" as a term is confusing17:07
cfbolzarigato: because it's a different definition than the usual one17:07
arigatowhich is...?17:08
cfbolz1) only depends on input arguments 2) no side effects17:08
cfbolzso I am thinking of simply using a different term17:08
arigatook17:08
arigatomakes sense17:08
cfbolzwould "trace-foldable" make sense to you?17:09
voidspace (~voidspace@python/psf/voidspace) left irc: Client Quit17:09
voidspace_ (~voidspace@python/psf/voidspace) joined #pypy.17:09
cfbolzor "trace-deterministic"?17:09
ltbarcly (~Adium@67.228.133.35-static.reverse.softlayer.com) left irc: Quit: Leaving.17:09
arigatoonce again, the precise definition is that two different actual calls return the same result if called with the same arguments17:11
cfbolzexcept that this is not true for the version usage17:12
arigato?17:12
cfbolzif you call it after you changed the class, you get a different result17:12
lachow about a word like invariant?17:12
JStoker (jstoker@unaffiliated/jstoker) left irc: Excess Flood17:12
arigatocfbolz: yes, but the point is that there is no *actual* call17:12
cfbolzyes, but we don't explain that yet17:13
cfbolzlac: that's a possibility too17:13
arigatowell, I'm trying to find the exact definition of what we have, in order to know how to call it17:13
arigato"invariant" makes sense to me, yes17:14
cfbolzarigato: wouldn't the definition be "if the call in the trace has constant argument, it is valid to reuse the result seen during tracing"17:14
arigatoyes, but more generally, if we want a definition to make a bit more sense, it has to be independent of our details of tracing,17:15
arigatoso that's why I proposed what I did17:15
JStoker (jstoker@unaffiliated/jstoker) joined #pypy.17:15
cfbolzarigato: ok17:15
cfbolzarigato: but I still have the fear that the getattr with versions doesn't really fit the definition17:16
cfbolzah17:16
arigato:-/17:16
cfbolzwait17:16
cfbolzI guess the important part is the "actual"17:16
cfbolzbut that's rather subtle17:16
arigatoyes17:16
cfbolzok, I missed that on first reading17:16
arigatoif, during the execution of the program, then two calls occur, and if the two calls have the same arguments, then they have the same results17:16
cfbolzthat makes sense17:17
cfbolzand then "trace-invariant" sounds like a good name?17:17
kenaan12hakanardo jit-short_from_state 1196c29f01f750 15/pypy/jit/metainterp/optimizeopt/unroll.py: produce a short preamble that is actualy usefull17:17
arigatoinvariant?17:17
cfbolzyes, though that's an overloaded term too?17:18
arigatoI mean, I'm proposing just "invariant"17:18
cfbolzyes, I see17:18
cfbolzjust saying that this word has meaning in other contexts17:19
cfbolzand I wonder whether this could confuse17:19
arigatook, but it's a bit less clear what it could be confused with17:19
cfbolzabsolutely17:19
cfbolzarigato: thanks for the definition, it's much more precise than what I came up with17:20
arigatomaybe some obscure name like "execution invariant"17:20
arigatobut I'm fine with just "invariant"17:20
cfbolzarigato: I think I will define a latex macro, so we can change it :)17:20
arigato:-)17:20
lac:-)17:21
pedronisjit terminology :)17:22
cfbolzheh17:22
cfbolzpedronis: invariant makes sense to you?17:22
pedronisyes, though indeed is used for other things17:23
mat^2 (~mathias@212.130.113.35) left irc: Read error: Connection reset by peer17:35
[mat^2] (~mathias@212.130.113.35) joined #pypy.17:35
[mat^2] (~mathias@212.130.113.35) left irc: Read error: Connection reset by peer17:35
mat^2 (~mathias@212.130.113.35) joined #pypy.17:36
cfbolzarigato: the definition is cool17:36
cfbolzit's quite subtle though, because "invariant" is not really only a property of a function17:37
cfbolzbut also how it is used17:37
antocunicfbolz: I don't like "trace-invariant", because it's a property which is not really related to tracing17:50
cfbolzyes, agreed17:50
cfbolzso it would have to be "execution invariant"17:50
antocuniyes, that one seems better17:50
cfbolzI will go with just "invariant"17:52
cfbolzunless michaeL complains17:52
antocuniwhat about "foldable"?17:53
davisagli (~davisagli@davisagli.com) left irc: Excess Flood17:54
cfbolzthey are not really17:54
antocuniwhy not? Fold them is exactly what we do17:54
cfbolzno, it's more subtle17:54
cfbolzwe never call them during optimization17:54
cfbolzand that would be forbidden17:54
antocuniah, I see the subtlety17:55
kenaan12cfbolz extradoc 11b56ca2a0e014 15/talk/icooolps2011/: replace "pure" with "invariant", add a precise definition of the term17:55
davisagli (~davisagli@davisagli.com) joined #pypy.17:55
mattheww (~mjw@cpc3-cmbg10-0-0-cust455.5-4.cable.virginmedia.com) joined #pypy.17:57
zrbecker (~zrbecker@ip98-164-227-211.oc.oc.cox.net) joined #pypy.18:07
ronnyhum18:08
cfbolz?18:11
__name__ (~name@sburn/devel/name) joined #pypy.18:17
ronny (~ronny@pida/ronny) left irc: Ping timeout: 246 seconds18:17
ronny (~ronny@pida/ronny) joined #pypy.18:17
ronny24 hour i hate disconnects18:17
ronnycfbolz: i'd like to promote pypy a bit at the python barcamp in cologne, im just a bit clueless how to work that best18:18
cfbolzhow long do you have?18:18
ronnycfbolz: its this weekend, nothing planned so far18:18
cfbolzpypy makes boring demos18:18
cfbolz"here it is slow"18:19
arigato:-)18:19
cfbolz"here the same behaviour, but fast"18:19
kenaan12cfbolz extradoc 11f011879ee9ad 15/talk/icooolps2011/paper.tex: fix a typo and an XXX18:19
kenaan12cfbolz extradoc 11a34441a3ce79 15/talk/icooolps2011/paper.tex: footnotize a paragraph18:19
arigatocfbolz: about {invariant}, how about a footnote saying something like "this is slightly more general than pure, because..."18:19
cfbolzand then killing the "observably pure functions"?18:20
cfbolzsection18:20
ronnycfbolz: i suppose a practical session for proting apps to pypy that are problematic would be nice (so people get a hands on oh MY MY APP IS SOOO FAST)18:20
ronny*porting18:20
arigatocfbolz: ah18:21
cfbolzI renamed it to "observably invariant"18:21
cfbolzwhich makes a bit no sense18:21
arigatocfbolz: maybe too indeed, but I had in mind "...because it's only about actual calls during execution"18:21
cfbolzah18:21
Action: cfbolz tries a bit18:22
cfbolzarigato: problem18:24
cfbolzarigato: what if a function prints?18:24
cfbolzis it invariant?18:24
cfbolzthe current definition does not work18:27
arigatoI suppose it needs to also have no observable side effect18:28
cfbolzyes, but then what is "observable"18:29
cfbolzhow about the following: if a function is called with the same arguments a second time, it is correct to reuse the result of the previous call18:29
arigatoI suppose, yes18:29
michaelh (c1beac85@gateway/web/freenode/ip.193.190.172.133) left irc: Ping timeout: 252 seconds18:32
hakanardoconserning boring demos for pypy: I actually got started on some simple realtime video processing 18:40
cfbolz!18:40
hakanardothat's not realtime at all when running cpython18:40
hakanardonot much to show yet but it's here: https://bitbucket.org/hakanardo/hakanardo18:41
cfbolzon pypy it's better?18:41
hakanardowell I can negate the image in realtime18:41
hakanardoa simple sobel edge detector does not become fast enough to be impressive18:41
cfbolz:-(18:42
carrus85 (~carrus85@216.83.145.38) joined #pypy.18:44
hakanardolooking back at the code it's a quite facy design, it might be possible to get it working with a more straigh forward design18:45
cfbolzhakanardo: nice code18:47
cfbolzhakanardo: I fear the generators kill pypy a bit18:47
hakanardoright, we should fix that :)18:47
cfbolzyes :-)18:47
cfbolzhakanardo: also, tests please :-)18:48
hakanardoyea, I know18:49
antocuni (~antocuni@host188-86-dynamic.7-79-r.retail.telecomitalia.it) left irc: Ping timeout: 276 seconds18:50
cfbolzhakanardo: can you see the jit warming up with this code?18:52
cfbolzI mean, does the video get less laggy?18:52
hakanardonope18:53
hakanardomaybe if you use lower resolution18:53
hakanardoother wise you'll loop 640*480 time before showing first frame18:53
cfbolzoh, right18:53
hakanardoor increase threashold significantly18:53
Action: cfbolz goes home18:54
cfbolz (~cfbolz@fwstups.cs.uni-duesseldorf.de) left irc: Quit: Leaving18:56
DanielHolth (~dholth@ip98-180-34-112.ga.at.cox.net) left irc: Ping timeout: 276 seconds18:57
DanielHolth (~dholth@ip98-180-34-112.ga.at.cox.net) joined #pypy.18:57
kenaan12cfbolz extradoc 1111b9039d379e 15/talk/icooolps2011/paper.tex: update definition, not too great and a bit circular18:57
voidspace (~voidspace@python/psf/voidspace) joined #pypy.18:58
hakanardoskipping all the fancy stuff did not increase speed...19:04
voidspace (~voidspace@python/psf/voidspace) left irc: Quit: voidspace19:06
Nick change: voidspace_ -> voidspace19:06
Nick change: Varraway -> Varriount19:10
kenaan12hakanardo jit-short_from_state 112af533e2b048 15/pypy/jit/metainterp/optimizeopt/unroll.py: overflow support19:11
kenaan12hakanardo jit-short_from_state 1114f72e53598a 15/: hg merge default19:11
kenaan12hakanardo jit-short_from_state 114b26e5e188f5 15/pypy/jit/metainterp/: added test_loop_variant_mul1_ovf19:11
fijal_ (~fijal@197.169.239.228) joined #pypy.19:16
fijal_hi19:17
derdon (~derdon@p54A6DA6E.dip.t-dialin.net) joined #pypy.19:17
lacfijal_: hi there19:17
dmalcolm (~david@nat/redhat/x-hqfjhkbwycxwfuku) joined #pypy.19:19
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) left irc: Read error: Connection reset by peer19:21
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) joined #pypy.19:22
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) left irc: Remote host closed the connection19:22
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) joined #pypy.19:22
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) left irc: Client Quit19:25
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) joined #pypy.19:25
kkris (~kris@93-82-34-202.adsl.highway.telekom.at) left irc: Quit: Leaving.19:28
Nick change: Varriount -> Varraway19:31
mvt (~mvantelli@53530442.cm-6-4a.dynamic.ziggo.nl) left irc: Quit: This computer has gone to sleep19:32
shager (~shager@dslb-094-221-245-069.pools.arcor-ip.net) joined #pypy.19:39
Nick change: intgr_ -> intgr19:39
shager (~shager@dslb-094-221-245-069.pools.arcor-ip.net) left irc: Client Quit19:39
fijal_ (~fijal@197.169.239.228) left irc: Ping timeout: 240 seconds19:48
Taggnostr (~quassel@dyn57-215.yok.fi) left irc: Quit: No Ping reply in 180 seconds.19:51
Taggnostr (~quassel@dyn57-215.yok.fi) joined #pypy.19:53
asabil (~asabil@195.159.219.65) left irc: Ping timeout: 260 seconds19:56
hruske (~Gasper@188-230-156-183.dynamic.t-2.net) left irc: Ping timeout: 250 seconds19:58
Nick change: Varraway -> Varriount19:59
Rhy0lite (~dje@nat/ibm/x-ibciptyegiabtcdp) left irc: Quit: Leaving20:00
fijal_ (~fijal@41.48.27.6) joined #pypy.20:02
fijal_<fijal_> arigato: I got stopped because QuasiImmut instances are not nicely castable to int20:07
fijal_<fijal_> for the purpose of the x86 backend20:07
arigatoI'm not sure because I didn't look, but they were never meant to be cast to int...20:07
arigatothe backend should handle Descrs, not QuasiImmut instances20:08
fijal_the bh_setfield_r20:08
fijal_casts a gc arg to int20:08
fijal_(as a value)20:08
arigatohum, yes?20:08
arigatois bh_setfield_r somehow called with a QuasiImmut instance as argument?20:09
fijal__ (~fijal@197.171.84.74) joined #pypy.20:10
arigatois bh_setfield_r somehow called with a QuasiImmut instance as argument?20:10
fijal__yes, the last argument20:10
fijal__value of a field20:10
arigatothat sounds bogus20:10
fijal__it's in get_current_qmut_instance20:10
fijal__qmut.hide()20:11
fijal__is actually the arg20:11
arigatoright20:11
fijal_ (~fijal@41.48.27.6) left irc: Ping timeout: 252 seconds20:12
fijal__arigato: is it ok or bogus?20:13
Nick change: fijal__ -> fijal_20:13
arigatono, it's ok I think now20:13
arigatocast_instance_to_base_ref() is a hack to start with, when untranslated20:13
arigatofwiw I've the same problem in the ptr32-on-64bit branch20:14
fijal_but then we have to do stuff with x8620:14
fijal_I swear I did it with ropaque20:14
arigatobecause GcStructs containing fields of type HiddenGcRef32 are not handled by ll2ctypes at all20:14
fijal_I see20:16
fijal_I really swear ropaque could be casted nicely :)20:16
arigatoI don't see how it helps, but I'm surely missing something20:16
fijal_there is special code for ropaque in ll2ctypes20:17
fijal_(I think)20:17
fijal_abort: untracked file in working directory differs from file in requested revision: '.hgsubstate'20:18
fijal_this is a terminal message about a repo?20:18
arigatorm .hgsubstate20:18
fijal_hm20:20
fijal_maybe not20:20
Action: arigato -> sleep20:21
fijal_arigato: see yuo20:21
arigatobye20:22
arigato (~arigo@82.113.98.162) left irc: Quit: See you20:22
fmilo (~mist0@64.17.253.218) joined #pypy.20:42
fprimex (~fprimex@brent-macbook.sc.fsu.edu) left irc: Quit: http://www.fprimex.com20:45
lac fijal_: you get this message when you have a file in your working directory which hg is not tracking (.hgsubstate) and then somebody else has added a file by the same name.  20:49
fijal_yeah20:50
fijal_but who creates .hgsubstate?20:50
ronnyi suppose you guys merged a branch with a subrepo that got removed20:54
ronnyrm + hg rm helps20:54
ronnyhgsubstate is managed by hg20:54
ronnyits content declares the exact state of the subrepos, 20:55
fijal_yeah, can hg manage it better so I don't have to worry about aborts?20:55
ronnywhat hg version? recent ones manage better i think20:56
fijal_1.7.220:56
davisagli (~davisagli@davisagli.com) left irc: Excess Flood21:02
davisagli (~davisagli@davisagli.com) joined #pypy.21:02
lizardo (~lizardo@189.2.128.130) left irc: Quit: Leaving21:02
ronnyfijal_: try 1.8.3 i guess21:05
ronnyfijal_: wha distro are you running?21:05
fijal_ubuntu21:05
ronnyyou might want to add the ppa21:06
ronny(ubuntu ships notoriously outdated mercurial packages)21:06
raymondh (~raymondhe@cpe-76-94-45-111.socal.res.rr.com) joined #pypy.21:06
DanielHolth (~dholth@ip98-180-34-112.ga.at.cox.net) left irc: Quit: Ex-Chat21:08
xorAxAxlol, http://vimeo.com/2236054021:19
cafesofie (~cafesofie@ool-4a5a6ee5.dyn.optonline.net) joined #pypy.21:20
mwhudson_ (~mwh@121-73-77-183.cable.telstraclear.net) left irc: Quit: Ex-Chat21:24
fijal_ (~fijal@197.171.84.74) left irc: Quit: Leaving21:24
mcfletch (~mcfletch@CPE0014bf07ffd2-CM001ac30d4aca.cpe.net.cable.rogers.com) left irc: Quit: Leaving.21:26
qbproger (~qbproger@184.91.177.52) joined #pypy.21:29
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) joined #pypy.21:31
harrison (~sr@adsl-69-209-208-65.dsl.chcgil.ameritech.net) joined #pypy.21:33
mat^2 (~mathias@212.130.113.35) left irc: 21:34
qbprogerAlex_Gaynor: ping21:38
mat^2 (~mathias@212.130.113.35) joined #pypy.21:38
qbprogerdamn21:45
etrepum (~bob@38.102.129.100) left irc: Quit: etrepum21:50
etrepum (~bob@accessnat4.mochimedia.net) joined #pypy.21:50
qbproger_ (~qbproger@52.177.91.184.cfl.res.rr.com) joined #pypy.21:51
qbproger (~qbproger@184.91.177.52) left irc: Ping timeout: 246 seconds21:52
mwhudson_ (~mwh@121-73-77-183.cable.telstraclear.net) joined #pypy.21:53
gtaylor (~gtaylor@99-5-124-9.lightspeed.gnvlsc.sbcglobal.net) left irc: Quit: Ex-Chat21:59
Arfrever (~Arfrever@gentoo/developer/Arfrever) left irc: Quit: Ex+re (KVIrc 4)22:01
mwhudson_ (~mwh@121-73-77-183.cable.telstraclear.net) left irc: Quit: Ex-Chat22:03
Nick change: Varriount -> Varraway22:06
Ademan (~dan@74.95.2.225) joined #pypy.22:12
Nick change: Varraway -> Varriount22:13
Nick change: qbproger_ -> qbproger22:21
Nick change: daniloaf -> daniloafk22:21
bobbyz_ (~bobbyz@12.131.26.130) left irc: Ping timeout: 248 seconds22:22
mwhudson (~mwh@linaro/mwhudson) left irc: Ping timeout: 258 seconds22:22
mat^2 (~mathias@212.130.113.35) left irc: 22:27
mwhudson (~mwh@linaro/mwhudson) joined #pypy.22:31
ivan (~ivan@unaffiliated/ivan/x-000001) left irc: Quit: ERC Version 5.3 (IRC client for Emacs)22:34
ivan (~ivan@unaffiliated/ivan/x-000001) joined #pypy.22:34
kenneth_reitz (~kenneth_r@c-24-127-96-129.hsd1.va.comcast.net) left irc: Read error: Connection reset by peer22:42
mat^2 (~mathias@212.130.113.35) joined #pypy.22:43
Ademanam I crazy? is -0x80000000 == 0x80000000 ?22:43
qbproger>>> -0x80000000 == 0x8000000022:46
qbprogerFalse22:46
mwhudsonAdeman: in 32 bit arithmetic yes22:46
Ademanqbproger: python will use longs22:47
Ademanmwhudson: ah thanks22:47
qbprogerah ok22:47
mattheww (~mjw@cpc3-cmbg10-0-0-cust455.5-4.cable.virginmedia.com) left irc: Quit: Leaving22:55
Nick change: Varriount -> Varraway22:59
raymondh (~raymondhe@cpe-76-94-45-111.socal.res.rr.com) left irc: Quit: This computer has gone to sleep23:01
Action: Ademan away23:02
Ademan (~dan@74.95.2.225) left irc: Quit: leaving23:02
Nick change: Varraway -> Varriount23:03
dmalcolm (~david@nat/redhat/x-hqfjhkbwycxwfuku) left irc: Quit: Leaving23:06
etrepum (~bob@accessnat4.mochimedia.net) left irc: Ping timeout: 240 seconds23:26
carrus85 (~carrus85@216.83.145.38) left irc: Read error: Connection reset by peer23:31
carrus85 (~carrus85@216.83.145.38) joined #pypy.23:31
squiddy (~squiddy@x027.wh17.tu-dresden.de) left irc: Quit: Leaving23:33
Alex_Gaynorqbproger: pong23:38
__name__ (~name@sburn/devel/name) left irc: Remote host closed the connection23:42
carrus85 (~carrus85@216.83.145.38) left irc: Read error: Connection reset by peer23:46
carrus85 (~carrus85@216.83.145.38) joined #pypy.23:47
carrus85 (~carrus85@216.83.145.38) left irc: Client Quit23:47
qbprogerAlex_Gaynor: hey want to work on sqrt? ;)23:50
Alex_Gaynorqbproger: I'm around and can answer questions, not working ATM though (just got up from a nap)23:50
Alex_Gaynorhow did I get 40+ emails while napping :/23:50
qbprogerwow23:51
qbprogerdinner is almost done anyway, so it might be better to resume another time23:51
harrison (~sr@adsl-69-209-208-65.dsl.chcgil.ameritech.net) left irc: Ping timeout: 240 seconds23:57
--- Thu Apr 14 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!