#pypy IRC log for Wednesday, 2007-09-05

stakkarstried a fresh svn checkout and newly installed everything but compilation breaks on amd64 as well01:39
drystonesimonb - r46313 - views are working well now01:52
jcea2 (n=jcea@jabber.hst.ru) left irc: Remote closed the connection02:27
nilton (n=nilton@loco-gw.ic.unicamp.br) joined #pypy.02:31
dialtone (n=dialtone@netblock-68-183-69-197.dslextreme.com) left irc: Read error: 104 (Connection reset by peer)02:32
dialtone (n=dialtone@netblock-68-183-69-197.dslextreme.com) joined #pypy.02:33
idnardrystone: rename drugs02:42
Nick change: drystone -> drugstone02:42
nilton (n=nilton@loco-gw.ic.unicamp.br) left irc: Remote closed the connection03:16
ousado_ (n=ousado@p548E9F09.dip0.t-ipconnect.de) left irc: Read error: 110 (Connection timed out)03:34
ousado_ (n=ousado@p548E9F53.dip0.t-ipconnect.de) joined #pypy.03:34
cursor (n=peter@dslb-088-072-255-062.pools.arcor-ip.net) joined #pypy.05:21
idnar (i=mithrand@unaffiliated/idnar) left irc: Nick collision from services.05:32
idnar_ (i=mithrand@unaffiliated/idnar) joined #pypy.05:32
gasolin (n=chatzill@61-230-98-135.dynamic.hinet.net) joined #pypy.05:58
cursor (n=peter@dslb-088-072-255-062.pools.arcor-ip.net) left irc: Read error: 110 (Connection timed out)05:59
Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) joined #pypy.06:05
dialtone (n=dialtone@netblock-68-183-69-197.dslextreme.com) left irc: 06:21
Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) left irc: "Valid HTML! http://validator.w3.org/ | Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html"07:10
DR0ID_ (n=DR0ID_@edu-34.227.zhaw.ch) joined #pypy.08:01
rhymes (n=rhymes@213.212.148.34) joined #pypy.08:42
mwh (n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk) joined #pypy.09:06
mwhudson (n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk) joined #pypy.09:12
antocuni (n=antocuni@host12-47-dynamic.116-80-r.retail.telecomitalia.it) joined #pypy.10:13
arigato (n=arigo@d83-189-153-3.cust.tele2.ch) joined #pypy.10:36
arigatomerging!10:37
drugstonearigo - r46314 - A temporary branch to hold the result of the merging of the rffi branch.10:37
antocunihi armin10:38
arigatohi!10:38
antocuniI was just about asking to you when you plan to merge :-)10:39
arigato:-)10:39
drugstonearigo - r46315 - module/thread: the changes in the trunk were merged early into the branch. Overwrite the trunk version with the branch version.10:40
arigatoantocuni: any local changes that you'd still like to check in?10:42
Action: antocuni is checking10:42
antocunino10:42
antocunigo on10:42
arigatook10:42
arigatoI can't ask simonpy, he is marked away10:42
arigatohe's been working on numpy in the branch10:43
antocuniarigato: I don't know if you remember, but I already merged most of cli/jvm/oosupport changes in the branch10:43
arigatois there anything at all in the trunk?10:43
arigatoI mean is it ok to delete the trunk's cli, jvm and oosupport and replace them with the branch'?10:44
antocunino10:44
antocunisorry, I was wrong10:44
antocunifor cli most of stuff has been merged10:44
antocunifor jvm/oosupport, not10:44
antocunibut I don't remember if I changed something else on cli/10:45
antocunilet me check10:45
arigatoI see just a couple of conflicts10:45
arigatoif you have a second, can you check with me on codespeak?10:45
antocunisure10:45
mwhhm, keynote 07 and svn are not friends, it seems10:46
arigatoscreen -x arigo/arigo10:46
drugstonemwh - r46316 - updates10:47
DR0ID_ (n=DR0ID_@edu-34.227.zhaw.ch) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"10:47
antocuniarigato: for this conflict probably it's easier to re-apply revision 4629410:47
arigatolooks like an easy conflict, though10:48
arigatocouldn't we either keep or drop this function?  or is it more complicated?10:48
arigato(we'll review the svn diff afterwards)10:48
antocunino, we need to keep it10:49
arigatoand the other copy here?10:49
antocuniok10:50
arigatothe two copies look quite identical actually10:51
antocuniso, we need to keep the one above10:51
arigatook10:51
antocuniand I guess we can delete the conflicting one10:51
antocuniif they are the same10:51
antocuniok, looks good10:52
arigatoindeed10:52
arigatoI see :-/10:52
antocuniwhat?10:52
arigatono, looks ok10:53
antocuniyes10:53
arigatojust that there is a bit of manual writing required here10:53
arigatolike this I guess?10:53
arigatoah no, you said the tests pass10:54
antocuniyes10:54
arigatook10:54
antocuniwait10:54
antocuniI guess test_cast_to_primitive fails10:54
arigatoah yes, the skips are there in the branch10:55
antocunishould be ok now10:57
arigatophone call.......11:01
antocuniok :-)11:01
arigatoback11:12
arigatook11:12
antocuniis this excpetiontransformer?11:13
arigatoyes11:13
arigatothe test actually11:14
antocuniI think I already merged it11:14
arigatoyes, exceptiontransform.py are equal11:14
antocuniprobably it's safe to just copy the test from the branch11:14
arigatojust checking11:15
arigatothere are no classes in the test in the branch11:16
antocuniouch11:17
arigatowe want to keep the classes, right?11:17
antocuniyes11:17
arigatook11:17
arigatolooks like test_llexternal() was added11:17
antocuniand probably put test_ll_external into one11:18
arigatoyes11:18
arigatothis can be removed, it's in the class now?11:18
antocuniI think so11:18
arigatoexcept the new test needs the new backendopt argument11:19
antocuniI was writing this :-)11:19
arigatook :-)11:19
antocuniself.transform_func11:20
antocuniok :-)11:20
arigatolooks ok?11:21
antocuniyes, but why do we import genc?11:21
arigatowho knows11:21
antocuniand also, exceptiontranform is now in translator, not translator/c11:21
arigatowe'll have to run the test, obviously,11:22
antocunisure11:22
arigatobut at the moment it's a bit hard11:22
arigatonext?11:22
antocuniwhat's left?11:22
arigatoos.*() stuff11:23
arigatoprobably all to be taken from the branch11:23
arigatowe should maybe just check what changed in the trunk here11:23
antocuniwhy was them modified on the dist?11:23
arigatoindeed11:23
arigatoos.tmpfile() was added11:25
antocuniI see11:26
arigatolet's mark it "to be restored later" and kill it right now11:26
arigatothere are too many "ARGH! strange hack" comments for me to feel good about it anyway :-)11:26
antocuni:-)11:27
arigator45631 just moves a test to another file, let me see11:28
arigatothat's it11:29
arigatook, same, I'll mark it to restore it later11:30
antocuniit looks good now11:31
arigatook.....11:32
antocuniwhat are you doing now?11:33
arigatoI'm editing the generated file that contains the11:34
arigatooperations that "merge3.py" found should be done11:34
arigatoso that rpython/module and module/posix are simply copied as a whole11:34
antocuniah, ok11:35
arigatohack+++11:35
arigatowalking on eggs kind of thing...11:36
arigatook, the log file should be ok, we can start the merge by checking in what we edited to resolve the conflicts11:36
arigatowarning, drugstone is about to flood this channel :-/11:37
drugstonearigo - r46317 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/translator.py revisions 45507 to 46315: ------------------------------------------------------------------------11:38
xorAxAxdrugstone: rename flood11:38
Nick change: drugstone -> floodtone11:38
floodtonearigo - r46318 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/llinterp.py revisions 45507 to 46315: ------------------------------------------------------------------------ r46011:38
floodtonearigo - r46319 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/config/translationoption.py revisions 45507 to 46315: ---------------------------------------------------------------------11:38
floodtonearigo - r46320 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/module/posix/__init__.py revisions 45507 to 46315: ------------------------------------------------------------------------11:38
floodtonearigo - r46321 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/module/posix/interp_posix.py revisions 45507 to 46315: --------------------------------------------------------------------11:38
floodtonearigo - r46323 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/test/test_exceptiontransform.py revisions 45507 to 46315: ------------------------------------------------------11:38
floodtonearigo - r46322 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/objspace/flow/objspace.py revisions 45507 to 46315: -----------------------------------------------------------------------11:38
floodtonearigo - r46324 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/cli/metavm.py revisions 45507 to 46315: ------------------------------------------------------------------------11:38
floodtonearigo - r46325 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/lltypesystem/lltype.py revisions 45507 to 46315: ------------------------------------------------------------------11:38
floodtonearigo - r46326 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/test/test_llinterp.py revisions 45507 to 46315: -------------------------------------------------------------------11:38
floodtonearigo - r46327 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/test/test_rfloat.py revisions 45507 to 46315: ---------------------------------------------------------------------11:39
floodtonearigo - r46329 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/module/posix/test/test_posix2.py revisions 45507 to 46315: ----------------------------------------------------------------11:39
floodtonearigo - r46333 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/module/test/test_ll_os.py revisions 45507 to 46315: ---------------------------------------------------------------11:39
floodtonearigo - r46334 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/module/test/test_posix.py revisions 45507 to 46315: ---------------------------------------------------------------11:39
floodtonearigo - r46328 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/module/ll_os.py revisions 45507 to 46315: ------------------------------------------------------------------------ 11:39
floodtonearigo - r46332 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/numpy/test/test_array.py revisions 45507 to 46315: ----------------------------------------------------------------11:39
floodtonearigo - r46330 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/jvm/test/test_cast.py revisions 45507 to 46315: ----------------------------------------------------------------11:39
floodtonearigo - r46331 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/cli/src/pypylib.cs revisions 45507 to 46315: -------------------------------------------------------------------11:39
floodtonearigo - r46335 - (arigo, antocuni around) Finish merging the rffi branch into the "merging" branch.11:40
Action: arigato -> dinner11:40
Action: arigato -> lunch rather11:40
antocuniarigato: bon apetit 11:40
arigatoI'll run some tests on the "merging" branch and finally merge it into "dist"11:41
arigatothanks11:41
arigatoantocuni: thanks for the help11:42
exarkunwee11:54
Arnarhrm..12:06
Arnarnon-determinism makes things hard12:06
floodtonearigo - r46336 - Repeat r45631: move the test so that it is llinterpreted.12:23
floodtonearigo - r46337 - Repeat the deletion of these two files that occurred on the pypy-more-rtti-inprogress branch.12:31
floodtonearigo - r46338 - Finish the merge of the pypy-more-rtti-inprogress branch. Delete the branches.12:34
arigatoantocuni: there is at least one failure in the jvm directory12:41
xorAxAxpypy still depends on ctypes12:42
xorAxAx--> no pypy translation using pypy12:42
xorAxAxthe reason is /home/alexander/dev/python/pypy_etc/pypy-dist/pypy/rpython/lltypesystem/rffi.py depending on ll2ctypes.py12:42
santagada (n=santagad@201.37.109.48) joined #pypy.12:42
arigatoxorAxAx: can you try this:12:44
xorAxAxremove the import? :)12:44
arigatoin ll2ctypes, if the "import ctypes" fails, ignore it12:44
arigatoyes12:44
arigatono I mean in ll2ctypes12:44
santagadasomething very wrong happened with my repository checkout12:44
xorAxAxarigato: its easy to debug - i just create a ctypes.py file with "raise ImportError" :)12:44
santagadabut it was probably my fault12:44
arigatoxorAxAx: it seems that ctypes is not needed at import-time in ll2ctypes.py12:45
arigatoxorAxAx: true enough :-)12:45
Action: xorAxAx tries arigato's suggestion12:45
arigatosantagada: what did you do, and what happened?12:45
santagadaarigato: svn up my pypy-dist directory, and somehow it thought it was pypy directory, so I got all the subdirectories of pypy in the directory that should have only pypy, py, demo, etc12:46
floodtonearigo - r46339 - Reimplement os.uname().12:46
arigatosantagada: you did the 'svn switch' at the wrong level?12:47
santagadaarigato: but that is no problem12:47
xorAxAxstandard_c_lib = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))12:47
xorAxAxfails12:47
santagadaarigato: I thought I didn't, but maybe I did12:47
santagadaarigato: no problem, I just came here to see how the merging is going12:47
arigatosantagada: ok12:47
xorAxAxarigato: works, should i check it in? :-)12:50
arigatoyes12:51
xorAxAxweeee, hacky wednesday12:51
floodtonexoraxax - r46340 - Do not bail out on missing ctypes (ignore the importerror), now pypy doesnt depend on ctypes for easy targets.12:54
arigatorlib.rmarshal is a bit broken12:59
arigatoit needs fixing before sandbox translations can work again12:59
jcea2 (n=jcea@jabber.hst.ru) joined #pypy.13:05
santagada (n=santagad@201.37.109.48) left irc: "good bye"13:05
antocuniarigato: which test fails on jvm?13:11
arigatoone about ullong_rshift I think13:12
arigatocan't find it again right now, give me 10 minutes...13:14
pedronis (i=pedronis@vitaly.openend.se) joined #pypy.13:15
antocuniarigato: found it13:17
arigatook13:17
floodtonearigo - r46341 - Fix rlib.rmarshal.13:22
antocuniis svn very slow only for me?13:25
pedronis (i=pedronis@vitaly.openend.se) left irc: "ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072300]"13:25
arigatoantocuni: fine for me13:25
floodtoneantocuni - r46342 - ullong_rhift for genjvm13:25
antocuniit seems ssh auth tooks forever from my machine (not only to codespeak, also for e.g. wyvern)13:26
arigatoI'm thinking about starting a whole test run soon13:27
xorAxAxantocuni: ssh -vvvv13:27
arigatoanything you see to fix first?13:27
antocuniarigato: nothing obvious, at least13:28
floodtonearigo - r46343 - Fix the sandlib.13:28
arigatook, we'll find out about the less obvious problems in a few hours then13:28
antocunixorAxAx: it hangs here:      debug2: we sent a publickey packet, wait for reply13:28
antocuniany clue/13:28
antocuni?13:28
xorAxAxantocuni: hmm, it should proceed13:28
xorAxAxdid you use 4 vs?13:29
Nick change: idnar_ -> idnar13:29
antocuniyes13:29
antocuniafter a while it proceeds13:29
xorAxAxmaybe your internet connection is bad13:30
gasolin (n=chatzill@61-230-98-135.dynamic.hinet.net) left irc: Read error: 110 (Connection timed out)13:30
antocuninow I can login to wyvern in less than 1 sec13:30
arigato:-/13:30
antocuniit's not the first time codespeak has such problems13:30
xorAxAx[translation:ERROR]    File "/home/alexander/dev/python/pypy_etc/pypy-dist/pypy/translator/c/database.py", line 95, in gettype13:35
xorAxAx[translation:ERROR]     return PrimitiveType[T]13:35
xorAxAx[translation:ERROR]  KeyError: <USHORT>13:35
arigatoxorAxAx: I don't know why I didn't stumble on that error, but I see what it must be13:38
xorAxAxthats a pypy-c13:38
xorAxAx:)13:38
nikomatsakis (n=niko@beauty.inf.ethz.ch) joined #pypy.13:42
nikomatsakishello!13:43
antocunihi niko!13:43
nikomatsakisantocuni: I am looking right now into the best way to spread the constants out over multiple classes.13:43
antocuninikomatsakis: cool, thanks13:44
arigatoxorAxAx: works for me, though13:44
nikomatsakisit's not especially hard, except for the need to interact elegantly with CLI / JavaScript, etc.13:44
arigatoxorAxAx: not quite sure how to be honest13:45
antocuninikomatsakis: can I help in some way?13:45
arigatoxorAxAx: ah, you still have no ctypes?13:45
nikomatsakisantocuni: it's ok, bigger problem is distractions :).  I guess that JavaScript doesn't really share the same constant code?  Do you know?  13:46
arigatoxorAxAx: in theory there is no reason why this particular problem depends on ctypes,13:46
antocuniI don't think so, but let me check13:46
arigatoxorAxAx: it's just historical reasons13:46
nikomatsakisantocuni: I found some relevant-looking code in js/database.py...13:47
antocuniyes, there is a gen_constants method13:48
antocuniso I think js don't depend on oosupport for this13:48
nikomatsakisok --- do you have an objection if I change cli to also generate multiple classes?  might make the result cleaner, because both will work in more or less the same way13:49
antocuniI'm slighlty worried about performances13:49
nikomatsakisok, I will leave the CLI as is13:49
antocuniI don't know if it would make pypy-cli slower13:49
antocuninikomatsakis: how hard is to leave CLI as is?13:49
nikomatsakisthat's probably better anyhow, no need to fix what ain't broken :)13:49
antocuni:-)13:50
nikomatsakisantocuni: I don't think it's hard13:50
antocuniok, good13:50
antocuniwhat could make sense is to divide constants into "logical blocks", so that they don't need to be initialized too eagerly 13:51
antocunibut it's not trivial/not a priority now13:51
nikomatsakisantocuni: yes, I think that would make sense, but it's a non-trivial edit13:51
antocuniso, let's skip this for now :-)13:51
xorAxAxarigato: did you try on a pypy-c?13:51
xorAxAxarigato: thats pypy-c translate.py13:51
nikomatsakisantocuni: instead, I think I will just modify one of the "overloadable" methods so that it can break the constants into multiple chunks if it wants to.  In this case, CLI can return one big blob, and the JVM can return multiple classes.13:52
antocuninikomatsakis: makes a lot of sense13:52
arigatoah13:52
xorAxAxwith targetrpythonedalone13:52
gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy.13:52
floodtonearigo - r46344 - A test for prebuilt integers of various types in genc. The fix is to make it pass even when ctypes is not installed, and removing a dependency on the rctypes package.13:55
arigatoxorAxAx: try again?  (no need to recompile pypy-c as far as I can tell)13:55
xorAxAxrunning13:58
xorAxAx.. the translation ...13:58
xorAxAxarigato: works, thanks13:59
arigatogood13:59
xorAxAxnow pypy has a usable benchmark again14:00
mwhthat took a while :)14:01
xorAxAxhehe14:01
mwhhow does pypy compare to cpython on this one now?14:01
Action: xorAxAx tries14:01
xorAxAxtime ./pypy-c ./translate.py --source --batch targetrpystonedalone.py14:02
xorAxAxreal    1m7.320s14:03
xorAxAxuser    0m55.003s14:03
xorAxAxsys     0m0.612s14:03
xorAxAxtime python ./translate.py --source --batch targetrpystonedalone.py14:03
xorAxAxreal    0m14.660s14:03
xorAxAxuser    0m11.273s14:03
xorAxAxsys     0m0.320s14:03
xorAxAxthats a faassen build14:03
xorAxAxthat makes pypy 5 times as slow as cpython14:04
antocuniit would be interesting to profile it14:05
xorAxAxyeah14:06
arigatothe CPython docs about os.tmpfile() seem to be at odds with its implementation14:08
mwhnot too slow14:11
xorAxAxwith llvm-via-c, it will be even faster, yeah14:11
antocuniarigato: a lot of jit tests fail14:12
arigatoantocuni: thanks, will check later14:13
floodtoneantocuni - r46345 - port test_runtest to oosupport, and remove duplicated code14:25
gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) left irc: Read error: 110 (Connection timed out)14:35
arigatoI'm sure I saw somewhere a Unix function that creates an unnamed file14:37
exarkunarigato: how are the os.tmpfile docs wrong?14:37
arigatothe Python docs say that no directory entry is created14:37
arigatothis is wrong both on Windows and Linux14:37
arigatoaccording to the MS docs for the C-level tmpfile(), and to "man tmpfile" on my Linux box14:38
Action: exarkun nods14:38
gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy.14:38
arigatobased on this remark, is there any difference at all for Python applications between14:56
arigatoos.tmpfile() and tempfile.TemporaryFile() ?14:56
exarkunos.tmpfile is probably better :)14:57
exarkunarigato: TemporaryFile leaves its file linked until it is closed, though14:57
exarkunarigato: tmpfile unlinks it before it returns14:57
arigatoexarkun: uh, no14:58
exarkunno?14:58
arigatono14:58
arigatoon posix systems (except cygwin), TemporaryFile is not a class but a function14:58
arigatothat unlinks the file immediately14:58
exarkunoh14:58
exarkunwhat does os.tmpfile do on windows?  also leave the file linked?14:59
arigatoyes14:59
arigatobut it gets removed by the C library on a non-crashing exit15:00
arigatoah, on Windows TemporaryFile() returns a Python object that is a wrapper around a file instead of natively a file15:01
floodtonearigo - r46347 - This is a replacement for the revision 45516 and 45517: a pure app-level implementation of os.tmpfile() based on the 'tempfile' module.  The idea is that it nicely avoids the hacks that were needed in15:12
arigatoon Windows, TemporaryFile() returns a wrapper for no good reason15:12
arigatothe only reason is that TemporaryFile = NamedTemporaryFile on this platform,15:12
arigatoand the latter uses a wrapper so that the 'name' attribute is correct15:12
antocuniarigato: is 'platcheck' supposed to be compiled every time?15:40
arigatoyes, there is no caching yet15:40
antocuniok15:41
arigatothe thing that has caching is rfficache.py, which is fijal's previous approach15:41
arigatobefore he started reusing the more powerful code from rctypes's "platcheck"15:42
xorAxAxisnt a bit of autoconf in all of us15:42
arigatoso, future work would be to eventually kill rfficache.py, and independently add caching to platcheck15:42
arigatoyes, it's clearly autoconf all over again15:42
arigatobut at least a pure Python and Windows-friendly one15:43
pedronis (i=pedronis@vitaly.openend.se) joined #pypy.15:43
arigatoI haven't given up on autolltype, either :-)15:43
DR0ID_ (n=DR0ID_@79.69.3.213.cust.bluewin.ch) joined #pypy.15:44
xorAxAxhehe15:44
stakkarsarigato: hi!16:03
arigatohi!16:03
stakkarsI was trying to run the graphviewer on my new machine and16:04
stakkarsI think I installed evrerything, dot is there etc. And I can run an X window.16:04
stakkarsIs there something missing?16:04
arigatoWindows or OS/X?16:05
stakkarsno, Debian Linux. Something about GRAPFBUFFER16:05
stakkars(!) DirectFB/Core: Could not initialize 'system' core!16:05
arigatois pygame correctly installed?16:05
arigatopython -c "import pygame"16:06
stakkarswell, I installed the package, but did not test16:06
stakkarsoki.....16:06
arigatotry    pygame.init()   too16:06
stakkarsaha. there we go16:07
stakkarsALSA lib confmisc.c:769:(parse_card) cannot find card ''16:07
stakkarsso I seem to need to emulate one16:07
arigatohum, no16:07
arigatothe dotviewer doesn't actually call pygame.init(), to avoid grabbing the sound card unnecessarily16:07
arigatotry again with only these inits:16:08
stakkarsmaybe it would anyway be better to use my local Mac to do the display16:08
arigatopygame.display.init()16:08
arigatopygame.font.init()16:08
arigatostakkars: ah, yes16:08
arigatothere is nice support to display graphs over the network, now16:08
arigatoworks much better than a remote X display16:08
stakkarspygame.error: DirectFBCreate: Initialization error!16:09
stakkarsafter I did the display.init()16:09
arigatothis pygame is not seeing the X libraries16:09
stakkarsso something is missing. not that urgent, btw.16:09
arigatobut if it's a remote machine, you should really not use that16:09
arigatotry this:16:09
arigatofirst question, does your local Mac have a public IP with some open ports?16:10
arigatoif not, or if you don't want to, we can use an ssh tunnel16:10
stakkarsit is dynamic ip, so I would to tell it the number from the provider. Which the X connection seems to do16:11
arigatook, so let's better try the ssh tunnel16:11
stakkarshow do you do it?16:11
arigatofrom your Mac:16:11
stakkarsthis is not a speed issue?16:11
arigatono16:11
arigatossh -R 8060:127.0.0.1:8060  remotemachine.com16:11
arigatoonce you are on the remote machine, you need to set an env var for dotviewer:16:12
stakkarsah! the first time that I use -R  :-)16:12
arigatoexport GRAPHSERVER=127.0.0.1:806016:12
stakkars(always used -L)16:12
arigato:-)16:12
stakkarsgoody goody goody16:13
arigatoon your local Mac in another terminal, you need to start this:16:13
arigatopypy-dist/pypy/dotviewer.py --server 127.0.0.1:806016:13
arigatothen it should work:16:13
arigatowhenever a remote Python process tries to display a graph,16:14
arigatoas long as it finds the GRAPHSERVER variable,16:14
arigatoit will go to your local "--server" process16:14
stakkarsthank you sir!  will come back with the result16:14
arigato(you need pygame installed on your Mac, clearly)16:14
stakkars(sure, I have)16:14
Action: antocuni afk16:25
stakkarsarigato: yes, it works. After figuring that we have pypy-dist/graphserver/graphserver.py it worked :-)   thank you16:29
arigato:-)16:29
arigatorunning "graphserver.py" is equivalent to running "dotviewer.py --server" as I said above16:29
arigatooups oups16:29
stakkarsso I actually could have avoided all the X11 stuff installed.16:29
arigatoI gave you a wrong path, sorry16:29
arigatofor the records I mean   pypy-dist/dotviewer/dotviewer.py16:30
stakkarssorry sorry, this is also what I did. (fuzz)16:30
stakkars./pypy-dist/dotviewer/dotviewer.py --server 127.0.0.1:806016:31
arigatothe viewer over X11 is pretty slow and tends to crash in my experience - that's why I refactored to add a wire protocol that only sends the raw graph data16:31
Nick change: karltk_ -> karltk16:32
stakkarsbut my real problem is on the mac. I just used the Linux server to see if I can build, there.16:34
stakkars(a few minutes)16:34
arigatoit requires 'dot' on the remote machine - it's not clever enough to be happy if 'dot' is only installed on any one of the two machines :-)16:34
stakkarshmm. was there some special check-in? I could not compile for hours on my max last night. Today it seems to work after svn up. hmm hmm16:44
stakkarsmy Mac16:44
stakkarsnice fractal...16:45
stakkars> /Users/tismer/pypy-dist/pypy/rpython/rint.py(255)_rtype_compare_template()16:59
stakkars-> raise TyperError("comparing a signed and an unsigned number")16:59
stakkarsthis was a fresh checkout of pypy-dist, on OS X17:00
xorAxAxwhich translation options?17:00
stakkarspython translate.py targetpypystandalone.py --faassen --allworkingmodules --withmod-_stackless17:01
xorAxAxand in which function does it crash?17:01
stakkarssee above - _rtype_compare_template()17:02
xorAxAx...17:02
xorAxAxwhich function graph?17:02
rhymes (n=rhymes@213.212.148.34) left irc: "This computer has gone to sleep"17:03
stakkarsno idea. you mean the caller of the func? I killed it, already, but we'll get my Linux build, soon17:04
xorAxAxstakkars: no, the function graph that was being worked on by the rtyper17:04
mwhoh17:05
mwhthat's os.times17:05
mwh(clock_t is unsigned on os x)17:06
mwhnot sure how to fix it myself17:06
stakkarshi Mike. whow17:06
cmd (i=dmc@astray.fragstore.net) joined #pypy.17:07
mwhat least, that was the cause of the translation i tried the other day failing17:07
stakkarsso that happens with all OSX builds, atm. Nice, PyCon UK :-)17:07
stakkarsI would love to have an ignore-errors option, since I don't need os.time for my demo17:09
xorAxAxstakkars: easy to fix - just put an "import os; del os.times" into your translate.py17:10
xorAxAx;-)17:10
arigatoI can fix this one easily17:10
arigatowith a cast17:11
stakkarshehe17:11
mwharigato: that would be nice :)17:11
stakkarswhow, the Linux build crashed as well...17:11
xorAxAxstakkars: it doesnt for me17:11
stakkarsthe exact one that I pasted?17:12
arigatomight be because of --allworkingmodules17:12
arigatoI never tried that on the branch that was just merged, I guess17:12
stakkars> /home/tismer/pypy-dist/pypy/rpython/lltypesystem/lltype.py(1101)__call__()17:12
stakkars-> raise TypeError,"calling %r with wrong argument types: %r" % (self._T, args_repr)17:12
arigatostakkars, mwh: try again on OS/X?17:12
floodtonearigo - r46348 - clock_t is unsigned on OS/X - missing a cast.17:13
stakkarsTypeError': calling <Func ( CInt, CInt ) -> CInt> with wrong argument types: [<Signed>, <Signed>]17:13
xorAxAxarigato: wouldnt it be cleaner to check the type of clock_t?17:13
arigatoxorAxAx: uh? no17:13
arigatoxorAxAx: even in "clean" C code you're supposed to check if the result value is  (clock_t)-1, not -117:13
xorAxAxarigato: because it is 64 bits on some platforms17:13
stakkarsarigato: yes, compiling17:13
xorAxAxwell, didnt look at the patch :)17:13
arigatoxorAxAx: please do :-)17:13
xorAxAxhehe17:14
arigato(the type of clock_t is not hard-coded, it's computed by the rfficache magic)17:14
xorAxAxah, ok17:16
stakkarsok, thn let's see if they both crash consistently, now :-)17:18
floodtonearigo - r46349 - Oups, there is a test for this function. Keep the old signature valid.17:19
arigatofailures in rpython.memory.test.test_gc...17:19
arigatomost llvm tests fail too17:20
arigatoseems to be for shallow reasons17:20
floodtonearigo - r46350 - Skip all llvm tests for now...17:23
stakkarscrashed on Linux, amd6417:27
arigatowe explicitly don't support 64-bit machines17:27
stakkarswhat does this mean, do I set something to behave?17:28
arigatono, in the sense that there are known, shallow, issues17:28
arigatoand nobody wanted to fix them yet17:28
arigatoshallow but still some work to fix17:28
mwhrtyping completed on os x now17:29
arigatomwh: progress17:29
nikomatsakis (n=niko@beauty.inf.ethz.ch) left irc: Read error: 110 (Connection timed out)17:29
stakkarswaah. I had the choice to install 32-bit but choose 64, because they are all moving towards this - hum17:29
stakkarsOS X looks happy on my side, too. inlining17:30
xorAxAxstakkars: debootstrap a 32 bit tree17:30
xorAxAxstakkars: works fine17:30
stakkarsxorAxAx: after I got so far with my machine, so much running, I should wipe it ???17:32
floodtonearigo - r46352 - These two tests were too precise.17:33
stakkarsor can I leave it intact, just switch and re17:33
stakkarsapt-get dist-upgrade?17:33
xorAxAxstakkars: not wipe it!17:33
xorAxAxstakkars: man chroot17:34
xorAxAxstakkars: its described in `man debootstrap`17:34
xorAxAxand pretty easy to use17:34
stakkarsa ch-rooted 32 bit system, then I would need to boot into that?17:34
xorAxAxno17:35
xorAxAxchroot /path17:35
xorAxAxfinished17:35
stakkarsreading...17:35
stakkarsxorAxAx: and the same 64 bit kernel would live with that?17:40
xorAxAxstakkars: yes!17:41
xorAxAxthats the magic of 25 years of A20 gate compatiblity17:41
stakkarsso it is all about compiler versions etc17:41
xorAxAxstakkars: in your debootstrap env, you will have your own compiler17:41
xorAxAxafter you have installed it :)17:42
arigatojacob22: may I raise your attention, if needed, on the fact that we have a test in PyPy's parser that has been failing since a long time?17:42
xorAxAxwhich makes it pretty troublefree17:42
arigatojacob22: related to the changes in __future__ imports17:42
stakkarsok, I might try this after PyCon uk.17:42
stakkarsor I might try to fix 64bit support :-)17:42
Rhamphoryncus (n=rhamph@unaffiliated/rhamphoryncus) joined #pypy.17:42
dialtone (n=dialtone@netblock-68-183-69-197.dslextreme.com) joined #pypy.17:42
mwhwriting c now17:42
stakkarsmine is at 86000 nodes, now17:43
arigatostakkars: fwiw, we have a long-standing stackless pickling failure too17:43
arigatostakkars: http://wyvern.cs.uni-duesseldorf.de/pypytest/46343/failed/lib.test2.test_stackless.py.AppTest_Stacklesstest_pickle.html17:43
stakkarsarigato: absolutely. this was I tried to fix last night. Somehow it got me into compiling.17:44
arigatoantocuni: while I'm at distributing blames, TestCarbonPython.test_compile_class fails every other day and still failed after the merge17:44
arigatostakkars: ok17:45
arigatothanks17:45
stakkarsfor some reason, I could not reproduce how to call the test, correctly, without causing some compilation which failed.17:45
arigatoah, my Linux translation on wyvern is in backendopts17:46
xorAxAxstakkars: not much to try about that - debootstrap is less than 1 minute of effort17:46
arigatoxorAxAx: well, then you have to reinstall some programs in there, I guess17:46
xorAxAxthen you issue apt-get install python2.4-dev build-essential    and can start to use pypy17:46
arigatook :-)17:46
xorAxAxarigato: he is not using gentoo where you need to wait for your gcc to be build :)17:46
Action: mwh has a pypy-c on os x now, thanks all :)17:47
stakkarsah - ok. good to learn17:47
arigatoyes, I recently gave up upgrading a gentoo machine and dropped an Ubuntu on it - that was incredibly fast :-)17:47
xorAxAx:-)17:47
arigatomwh: :-)17:47
xorAxAxin fact, ubuntu has some issues on upgrades17:47
xorAxAxe.g. it creates the initrd ~ 10 times on an avg. installation17:48
xorAxAx(with a few driver packages etc.)17:48
stakkarsyes, I read about it, so I stick with Debian testing.17:48
xorAxAxso its slow if your machine can only pack slowly17:48
arigato(a minor annoyance of the nice graphical installer is that it really wants to reformat the / partition, so I had to backup data to obscure places)17:48
xorAxAxarigato: it asks you if you want to partition yourself17:48
xorAxAxbut those ubuntu issues of the slowness would need dpkg extensions that are not yet in debian to be fixes17:49
xorAxAxs/s$/d//17:49
stakkarswriting c...17:49
arigatoxorAxAx: I chose that option, in fact the partition were already there, but still it wants to reformat the / partition17:50
xorAxAxarigato: ah, indeed, it only likes ext3 for / IIRC17:50
xorAxAxor something like that17:50
arigatoah, that might be the issue17:50
xorAxAxpretty annoying, yes17:50
xorAxAx(the various bugs in the partitioning integration in the fancy installer)17:51
arigatomaybe I was just confused by the error message then, and an already-ext3 / would not have required reformatting17:51
floodtonearigo - r46353 - These tests are quite slow.  One of them timed out on wyvern, so I'm adding a way to increase the default timeout again...17:52
stakkarsarigato: how exactly is the failing test called, again?17:52
arigatotest_pickle17:52
arigatoin lib.test2.test_stackless17:52
Action: pedronis -> home17:52
pedronissee you17:52
stakkarsno how the test is run. test-all17:52
arigatosee you17:53
pedronis (i=pedronis@vitaly.openend.se) left irc: "ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072300]"17:53
stakkarsbye17:53
stakkarsI must have done something that causes compilation17:53
arigatoit's run at app-level, you can probably copy-paste that function's body in x.py and type "py.py x.py"17:54
arigatothe C compiler is called a few times when you start py.py now17:54
arigatofor platform checking17:55
stakkarsand that drove me crazy, tonight, because there were failures17:55
Action: stakkars going to check this, again17:55
arigatocrashes, or just compilation failures that appeared ignored?17:55
arigatothe latter are fine17:56
stakkarssomething red, not sure, it was late - will try again...17:56
arigatomwh: are you interested in hearing the next framework-gc-related tale?17:59
arigatoit's pretty good, it has ordering issues in it18:00
mwharigato: perhaps?18:00
mwharigato: is lowleveldatabase still too transparent and simple?18:00
mwh^.complete 18:00
arigatono, it's found by the llinterpreter already18:03
arigatoMarkSweepGC.collect() -> print time.time() -> gettimeofday18:03
arigatowhich is an external function18:03
arigatoso it really arrives in a wrapper built by rffi.py18:03
arigatowhich is called gettimeofday_star218:03
arigatonotice the star218:04
arigatobecause it takes a *arg18:04
arigatowhich is a tuple18:04
arigatowhich needs to be allocated18:04
arigatobut it's a tuple of a type that is not seen elsewhere in the program18:04
arigatoso the gc transformer didn't allocate a typeid for it18:04
mwharigato: lets rewrite pypy in prolog18:05
stakkarsarigato: this works, today. No idea about yesterday, but now I can fix the piuckling (but should produce slides)18:09
simonpyarigato: did you fix this problem?18:09
arigatosimonpy: hi!  I hope the branch merge didn't cause too much troubles18:10
simonpyarigato: hi!18:10
arigatowhich problem, the gc fun above?18:10
simonpyyes18:10
arigatono18:10
simonpy:)18:10
arigatoI'm not sure how the 'struct timeval' gets a typeid for the gc transformer,18:10
arigatoalthough it also only appears in time_time_llimpl()18:11
arigatoah, oh, I see - 'struct timeval' is raw-malloced, not it's not handled by the gc at all18:12
arigatoI guess I'm going to disable the wrapper around gettimeofday18:15
arigatoa bit of a hack in this case18:15
simonpyok18:15
arigatobut well, nothing should really allocate gc-managed data during a gc collection18:15
mwhright, that's already pretty bad18:17
floodtonearigo - r46354 - MarkSweepGC.collect() -> time.time() -> wrapper from rffi The latter takes a *arg, which needs to be GC-allocated -> boom18:20
arigatoah18:21
arigatorgh18:21
arigatorgh!18:21
arigatocould we please kill ltypesimulation.py?18:21
gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) left irc: Nick collision from services.18:21
arigatoit doesn't quite know what to do with all these raw-malloc18:22
gasolin_ (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy.18:22
mwhis that the very old way of running tests on the llinterp after gc transformation?18:22
arigatoyes18:22
arigatoit's been sitting on samuele's black list for a long time18:23
mwhisn't it something like there's no other way of testing the semi space collector yet that's keeping it alive?18:24
arigatoI think so, yes18:25
arigatohowever, ah ha, the SemiSpaceGC doesn't call time.time()18:25
Action: arigato thinks of disabling just TestMarkSweepGCRunningOnLLinterp18:25
floodtonearigo - r46355 - Disabling TestMarkSweepGCRunningOnLLinterp.  The idea is that the mark-and-sweep GC is already tested differently. The reason for disabling it is that time.time() now involves performing raw mallocs o18:28
arigatoyuk about the jit test failures too18:30
floodtonearigo - r46356 - Patching lltype._func objects is now forbidden.  This checkin is mostly whacking at the HRTyper source until it doesn't need such patching any more.  It's not clean.18:47
rhymes (n=rhymes@host37-78-dynamic.0-79-r.retail.telecomitalia.it) joined #pypy.18:48
lac (n=lac@pdpc/supporter/gold/lac) left irc: Read error: 110 (Connection timed out)18:54
jacob22 (n=jacob@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Read error: 110 (Connection timed out)18:54
gasolin_ (n=chatzill@220-132-160-66.HINET-IP.hinet.net) left irc: Read error: 110 (Connection timed out)18:55
jacob22 (n=jacob@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.18:55
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.18:58
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection19:14
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.19:17
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Client Quit19:18
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.19:19
pedronis-mk2 (i=pedronis@vitaly.openend.se) joined #pypy.19:25
pedronis-mk2 (i=pedronis@vitaly.openend.se) left irc: Client Quit19:25
Action: rhymes is away: Away19:25
floodtonesimonb - r46357 - get transpose to work, add a reshape method19:27
pedronisarigato: working on killing the simulator is the next pypy thing I want to do19:30
pedronisalthough first I also need to do the preparation work to have support for implicitly releasing the gil around external calls19:31
floodtoneantocuni - r46358 - skip this test for now. I never managed to reproduce it on my machine or wyvern, no clue why it fails sometimes :-(.19:49
arigatopedronis: ah20:01
pedronis_ (n=chatzill@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.20:01
arigatopedronis_: I was thinking about the GIL release too20:01
arigatoI guess we should simply move towards a global GIL instead of a per-space one20:01
arigatounless you can think about something more clever20:01
pedronis_did you see my discussion with fijal20:02
arigatono20:02
pedronis_the idea was to be able to register before and after hook that are waved around external calls if the pointer is flagged in some specific way (when you do the llexternal)20:02
pedronis_s/waved/weaved20:03
arigatouh20:03
pedronis_?20:03
pedronis_were you thinking of writing manual release code?20:04
pedronis_or to make the GIL an rpython concept20:04
arigatocouldn't we simply insert calls to these hook in the wrapper function produced by rffi.llexternal?20:04
arigatoby insert I mean writing the calls manually there, yes20:05
pedronis_but then you need to make the GIL part of rpython20:05
arigatoI guess I don't see what you propose20:05
pedronis_how would the intepreter and the code in rffi.llexternal refer to the same GIL?20:06
arigatoyou need to push hooks from one level to the other, yes20:07
arigatoI don't see the bit about flagging ll function pointers20:07
pedronis_you would do something like this: register_around_external('thread-safe', releaseGIL, acquireGIL)20:08
pedronis_and then put the thread safe flag on the pointers to function you know you can release around (probably that would be the default)20:08
pedronis_and the rtyper would do the job for you20:08
pedronis_using hlinvoke like logic20:09
pedronis_releaseGIL and acquireGIL would be high level functions20:09
arigatoand register_around_external() is a method of the annotation policy or some such place?20:09
pedronis_and the registration would be done in some bit of annotation visible space initialization20:09
pedronis_it would be a special function that does nothing but remembers the information20:10
pedronis_when annotated20:10
arigatoah20:10
arigatolooks obscure, given that we already need special logic for threads at a couple of places, but why not20:10
arigatoI mean this information could be attached more directly to the annotation policy or something20:11
pedronis_that's possible too but then you need the space20:11
pedronis_unless you make the the GIL global20:11
Action: Rhamphoryncus should probably interject on this conversation20:11
pedronis_the two hooks can be bound method on some pbc20:11
pedronis_in the other model20:12
pedronis_I agree is maybe too general20:12
arigatowell, or not enough20:12
arigatoyou mean 'space.acquireGIL' and 'space.releaseGIL'20:12
pedronis_but having rffi know about the GIL is strange too20:12
arigatoit's not general enough because it wouldn't really work with multiple spaces anyway20:12
xorAxAxpedronis_: why?20:12
arigatoso it's just a roundabout way to having a global GIL20:12
Rhamphoryncushrm.  Are you just talking about a simple GIL, or are you talking about different stuff to get scalable threading?20:13
xorAxAxi think the GIL knowledge would fit into rpython20:13
xorAxAxbecause threads are pretty low-level20:13
pedronis_you still want at least the control not to have a GIL20:13
arigatoRhamphoryncus: simple GIL20:13
xorAxAxyes20:13
pedronis_also if you have multiple spaces you have problems at various level anyway20:14
Rhamphoryncusarigato: okay, I can stay out of it then.  My knowledge is on how to change it ;)20:14
pedronis_it would really need to play with thead locals20:14
pedronis_with thread locals20:14
pedronis_basically having multiple spaces is not something we have worked out20:14
pedronis_how it would really work20:15
xorAxAxyou could have multiple python modules20:15
arigatowell, it worked at some point in time20:15
xorAxAxin sys.modules20:15
arigato(for a fixed number of prebuilt spaces)20:15
xorAxAxarigato: never, only different instances of the same space20:15
arigatoxorAxAx: that's what I mean20:15
floodtoneantocuni - r46359 - the old implementation of ulong_to_double was broken. This one is also broken, but only for very large values. Not sure what's the best way to implement ullong_* operations on JVM :-(.20:15
xorAxAxthe more general solution would be even useful :)20:15
arigatoI'm not saying to hard-code GIL knowledge, but I'm just wondering if there is a way to be correctly space-specific in this case20:16
arigatomaybe there isn't, but then the GIL should be a global in some corner instead of attached to the space (but that's really a detail)20:16
pedronis_well if you are inside a os function20:17
pedronis_you would need to  know on behalf of which space20:17
pedronis_you have been invoked20:18
pedronis_to release one of the multiple gils20:18
arigatohence the idea of thread-locals... maybe20:18
pedronis_basically the interface is orthogonal to that problem20:19
xorAxAxhmm20:19
arigatoI see20:19
simonpyare we talking about rpython threading (&locking) or app level threading ?20:20
pedronis_it may still be overkill to do it way I propose20:20
pedronis_I suppose it would make sense if we could think of other use cases for the functionality20:20
arigatopedronis_: what about a special function gettranslationpolicy() that return the Policy as a frozen constant...20:21
arigatothen we can put the calls manually in the wrapper in rffi.py20:22
pedronis_you mean the annotation policy ?20:22
arigatoyes20:22
arigatocould be something else - the idea is some frozen object that can be chosen somewhere sane20:22
pedronis_but releasing the gil needs external calls too20:23
pedronis_which need not to release it20:23
pedronis_you need a flag on llexternal20:23
arigatoyes, you need that in any case, because there are some external calls that should not release the GIL20:23
pedronis_also rffi would need to define the GIL20:24
pedronis_so the intepreter would import it I suppose20:24
arigatoI'm just saying that adding the flag to the ll function pointer and knowledge about it in the rtyper looks overkill to me20:24
arigatopedronis_: no, I meant code like:20:24
arigatogettranslationpolicy().before_external_call()20:25
arigatowith a default empty method before_external_call() on the policy20:25
arigatowhich is overridden in PyPyAnnotationPolicy20:25
pedronis_one issue20:25
arigato(...where there is already GIL-specific code, FWIW)20:25
pedronis_in the policy?20:26
arigatoyes, I just noticed20:26
arigatoto handle 'specialize:yield_thread'20:26
pedronis_one issue is that you need to be careful that the before and after20:26
pedronis_don't create new annotations20:26
pedronis_or you need to emulate pbc call them20:27
pedronis_because the llexternal wrapper20:27
arigato? confused20:27
pedronis_are annotated quite late20:27
pedronis_you could not put code that adds new attributes for example20:27
pedronis_in there20:27
pedronis_in the after and the before20:27
pedronis_unless you pbc emulate call them early20:28
arigatoyes, changing classes is definitely forbidden20:28
arigatoit's a theoretical issue in both approaches as far as I can tell,20:28
arigatobut it doesn't look likely20:28
arigatothe before and after should just call the release and acquire methods on a prebuilt object20:29
arigatoah, sorry, I see why your proposed approach doesn't have this issue20:30
pedronis_but there's not much point for the code in rffi to use generic names because the flag it needs to consider needs to have a thread related name20:31
xorAxAxhmmmm20:31
arigatoyes20:31
xorAxAxi get a FP trap for 10 / i where i is 020:32
pedronis_unless you pass flags20:32
pedronis_to a memo on the policy20:32
xorAxAxthat sounds certainly b0rked for me - there is no FP involved20:32
arigatoxorAxAx: works for me20:32
arigatoxorAxAx: it's correct behavior too20:32
arigatoto get an "FP trap"20:33
xorAxAxwhy?20:33
arigatoon x86 an integer division by zero is the same signal, if I remember correctly, than an FP error20:33
xorAxAxah20:33
xorAxAxwhy doesnt     except ZeroDivisionError: help here?20:33
xorAxAxdo i need to do the checking myself?20:34
arigatoin RPython?  yes20:34
arigatoer, no20:34
arigatosorry20:34
arigatomaybe you need an ovfcheck(x/y)20:34
xorAxAxah20:35
arigatono, no clue20:35
xorAxAxits generating no exc checks20:35
arigato(ah yes, I'm supposed to kill HalfConcreteWrapper one of these days)20:44
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "ERC Version 5.1.4 (IRC client for Emacs)"20:47
Action: xorAxAx tries to count how many exceptions are raised in a normal rpython program20:48
xorAxAxs/rpy/py/20:48
Nick change: pedronis_ -> pedronis20:49
lac_ (n=lac@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.20:56
xorAxAxnow you may place your bets - how many raised rpython level exceptions for a pystone run?20:58
exarkun750k20:59
exarkun(that's exceptions, not dollars)20:59
antocunixorAxAx: a pypy-c pystone or a rpython? with or without backendopt?20:59
xorAxAxa python pystone21:00
xorAxAxa regular translation21:00
xorAxAx== with backendopts21:00
Action: antocuni has really not clue21:00
Action: xorAxAx has no idea how many we will see - still translating :)21:00
xorAxAxmaybe i should have patched the C source21:01
antocuniuh, probably a lot: there is at least an exception for each bytecode executed21:01
pedronis?21:02
exarkunouch, an exception per bytecode?  that's insane.21:02
pedronisthat's not the case21:02
pedronisthere's one per function call21:02
xorAxAxmaybe on the llinterpreter :)21:02
pedronisand there is iteration21:03
xorAxAxpedronis: iteration doesnt raise21:03
xorAxAxin the end21:03
pedronisthe python level one does21:03
xorAxAxyes21:03
pedronisI was not saying rpython iteration21:03
xorAxAxdoes pystone use iterators?21:03
xorAxAx:-)21:03
pedronisI don't know21:03
Action: xorAxAx wonders how expensive this one is: # define RPyCHECK(x) ((x) || (abort(), 0))21:03
xorAxAxit should be called rather frequently21:04
pedronisthere maybe some key errors21:04
pedronisalthoug we added None returning variant21:04
pedronisto cover most cases21:04
pedronisthis was a rpython key error21:04
floodtoneantocuni - r46360 - implement cast_primitive for jvm21:07
antocunipedronis: ah sure, as always I was wrong :-)21:08
xorAxAxgenerating C code21:18
pedronis` (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.21:19
pedronis (n=chatzill@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072517]"21:20
Nick change: pedronis` -> pedronis21:20
arigatotranslate.py --sandbox crashes on the interesting line 198 of rlib/rmarshal.py21:28
xorAxAxpypy interpreter startup and quit  - 23940 exceptions21:35
xorAxAxnow place your bets (again) for pystone :)21:35
exarkunxorAxAx: is that interpreting site.py?21:36
xorAxAxexarkun: yes21:37
xorAxAxwow, i chose the wrong data type21:37
xorAxAxwell, anyway, your bets? :)21:37
exarkunI'll stick with my first guess I guess21:37
xorAxAxnobody else? :)21:38
xorAxAx./pypy-c -c 'from test import pystone;pystone.main()'21:39
xorAxAxthat gives 50000 passes21:39
xorAxAxand our counter says:21:39
xorAxAx Exceptions raised: 201455521:39
xorAxAxexarkun: so its about 3 times more21:40
antocunixorAxAx: do you also know which exceptions are raised more often?21:40
xorAxAxantocuni: nope21:41
exarkunwoo within an order of magnitude21:41
xorAxAxexarkun: yes, 1st place, you get the prize21:41
xorAxAxantocuni: but i can extend the code to check that21:42
antocuniI think it would be interesting21:42
xorAxAxarigato, pedronis: is this high amount expected? :)21:44
arigato40 per loop - it's not that high21:46
xorAxAxwell :)21:47
xorAxAxi guess cpython has less21:47
pedronisthere's one per function call, as I said21:47
exarkunxorAxAx: CPython has 0 right? C doesn't have exceptions?21:47
exarkun0 is less than 2014555 I think21:48
xorAxAxexarkun: well21:48
xorAxAxexarkun: even in cpython you get exceptions when executing code (stopiteration for example)21:48
xorAxAxnot sure if pystone iterates, though21:48
exarkunxorAxAx: True, I guess.21:48
xorAxAxthe above number includes app-level exceptions as well but there arent many21:49
exarkunHow does translated rpython exception handling compare to exception handling in the Python C API?21:49
exarkunis it basically the same?  check a return value and go find the app level exception handling code if it's the wrong thing?21:49
xorAxAx"find"?21:50
xorAxAxbasically, exceptions work similarly21:50
exarkunanthropomorphizing21:50
pedronisyes21:50
pedroniscalls alone can easely account for th 40 exc per iteration21:57
exarkunsounds like an easy optimization? :)21:58
pedronisnot really21:58
pedronisthe current bytecode loop structure is a compromise21:59
pedronisI'm also not sure that 40 exception cost that much in the amount of stuff21:59
pedronisthat happens in one pystone iteration21:59
Action: exarkun nods21:59
xorAxAxfor 100 loops, its 5246 without site22:01
xorAxAxfor 10000 its 4124622:01
xorAxAxthat rather looks like 4 and not 4022:01
xorAxAxah, no22:02
xorAxAxfor 1000 its 4124622:02
pedroniswell, it's in the expected range I would say22:04
pedronispystone is calling stuff a bit22:04
xorAxAxhmm22:05
rhymes (n=rhymes@host37-78-dynamic.0-79-r.retail.telecomitalia.it) left irc: "python is what you need"22:06
xorAxAxrichards does 977740222:11
pedronisthe kind of exceptions would be more useful information22:12
pedronisnot sure there's any simple win here unless we are doing something very22:12
pedronisstupid somewhere22:12
xorAxAx:)22:15
xorAxAxits not so easy to count the typed ones22:15
xorAxAxi could filter the return value ones, though22:15
ousado (n=ousado@p548E8527.dip0.t-ipconnect.de) joined #pypy.22:18
ousado_ (n=ousado@p548E9F53.dip0.t-ipconnect.de) left irc: Read error: 110 (Connection timed out)22:18
nilton (n=nilton@loco-gw.ic.unicamp.br) joined #pypy.22:24
antocuni (n=antocuni@host12-47-dynamic.116-80-r.retail.telecomitalia.it) left irc: "Leaving"22:28
stakkars_ (n=tismer@i577B72FC.versanet.de) joined #pypy.22:49
arigato (n=arigo@d83-189-153-3.cust.tele2.ch) left irc: Read error: 110 (Connection timed out)22:55
stakkars (n=tismer@i577B4A35.versanet.de) left irc: Read error: 110 (Connection timed out)22:59
nilton (n=nilton@loco-gw.ic.unicamp.br) left irc: Remote closed the connection23:28
Action: pedronis goes to sleep23:53
jcea2 (n=jcea@jabber.hst.ru) left irc: Remote closed the connection23:53
pedronis (n=user@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "ERC Version 5.1.4 (IRC client for Emacs)"23:53
--- Thu Sep 6 200700:00

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