| stakkars | tried a fresh svn checkout and newly installed everything but compilation breaks on amd64 as well | 01:39 |
|---|---|---|
| drystone | simonb - r46313 - views are working well now | 01:52 |
| jcea2 (n=jcea@jabber.hst.ru) left irc: Remote closed the connection | 02: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 | |
| idnar | drystone: rename drugs | 02:42 |
| Nick change: drystone -> drugstone | 02:42 | |
| nilton (n=nilton@loco-gw.ic.unicamp.br) left irc: Remote closed the connection | 03: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 | |
| arigato | merging! | 10:37 |
| drugstone | arigo - r46314 - A temporary branch to hold the result of the merging of the rffi branch. | 10:37 |
| antocuni | hi armin | 10:38 |
| arigato | hi! | 10:38 |
| antocuni | I was just about asking to you when you plan to merge :-) | 10:39 |
| arigato | :-) | 10:39 |
| drugstone | arigo - r46315 - module/thread: the changes in the trunk were merged early into the branch. Overwrite the trunk version with the branch version. | 10:40 |
| arigato | antocuni: any local changes that you'd still like to check in? | 10:42 |
| Action: antocuni is checking | 10:42 | |
| antocuni | no | 10:42 |
| antocuni | go on | 10:42 |
| arigato | ok | 10:42 |
| arigato | I can't ask simonpy, he is marked away | 10:42 |
| arigato | he's been working on numpy in the branch | 10:43 |
| antocuni | arigato: I don't know if you remember, but I already merged most of cli/jvm/oosupport changes in the branch | 10:43 |
| arigato | is there anything at all in the trunk? | 10:43 |
| arigato | I mean is it ok to delete the trunk's cli, jvm and oosupport and replace them with the branch'? | 10:44 |
| antocuni | no | 10:44 |
| antocuni | sorry, I was wrong | 10:44 |
| antocuni | for cli most of stuff has been merged | 10:44 |
| antocuni | for jvm/oosupport, not | 10:44 |
| antocuni | but I don't remember if I changed something else on cli/ | 10:45 |
| antocuni | let me check | 10:45 |
| arigato | I see just a couple of conflicts | 10:45 |
| arigato | if you have a second, can you check with me on codespeak? | 10:45 |
| antocuni | sure | 10:45 |
| mwh | hm, keynote 07 and svn are not friends, it seems | 10:46 |
| arigato | screen -x arigo/arigo | 10:46 |
| drugstone | mwh - r46316 - updates | 10:47 |
| DR0ID_ (n=DR0ID_@edu-34.227.zhaw.ch) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org" | 10:47 | |
| antocuni | arigato: for this conflict probably it's easier to re-apply revision 46294 | 10:47 |
| arigato | looks like an easy conflict, though | 10:48 |
| arigato | couldn'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 |
| antocuni | no, we need to keep it | 10:49 |
| arigato | and the other copy here? | 10:49 |
| antocuni | ok | 10:50 |
| arigato | the two copies look quite identical actually | 10:51 |
| antocuni | so, we need to keep the one above | 10:51 |
| arigato | ok | 10:51 |
| antocuni | and I guess we can delete the conflicting one | 10:51 |
| antocuni | if they are the same | 10:51 |
| antocuni | ok, looks good | 10:52 |
| arigato | indeed | 10:52 |
| arigato | I see :-/ | 10:52 |
| antocuni | what? | 10:52 |
| arigato | no, looks ok | 10:53 |
| antocuni | yes | 10:53 |
| arigato | just that there is a bit of manual writing required here | 10:53 |
| arigato | like this I guess? | 10:53 |
| arigato | ah no, you said the tests pass | 10:54 |
| antocuni | yes | 10:54 |
| arigato | ok | 10:54 |
| antocuni | wait | 10:54 |
| antocuni | I guess test_cast_to_primitive fails | 10:54 |
| arigato | ah yes, the skips are there in the branch | 10:55 |
| antocuni | should be ok now | 10:57 |
| arigato | phone call....... | 11:01 |
| antocuni | ok :-) | 11:01 |
| arigato | back | 11:12 |
| arigato | ok | 11:12 |
| antocuni | is this excpetiontransformer? | 11:13 |
| arigato | yes | 11:13 |
| arigato | the test actually | 11:14 |
| antocuni | I think I already merged it | 11:14 |
| arigato | yes, exceptiontransform.py are equal | 11:14 |
| antocuni | probably it's safe to just copy the test from the branch | 11:14 |
| arigato | just checking | 11:15 |
| arigato | there are no classes in the test in the branch | 11:16 |
| antocuni | ouch | 11:17 |
| arigato | we want to keep the classes, right? | 11:17 |
| antocuni | yes | 11:17 |
| arigato | ok | 11:17 |
| arigato | looks like test_llexternal() was added | 11:17 |
| antocuni | and probably put test_ll_external into one | 11:18 |
| arigato | yes | 11:18 |
| arigato | this can be removed, it's in the class now? | 11:18 |
| antocuni | I think so | 11:18 |
| arigato | except the new test needs the new backendopt argument | 11:19 |
| antocuni | I was writing this :-) | 11:19 |
| arigato | ok :-) | 11:19 |
| antocuni | self.transform_func | 11:20 |
| antocuni | ok :-) | 11:20 |
| arigato | looks ok? | 11:21 |
| antocuni | yes, but why do we import genc? | 11:21 |
| arigato | who knows | 11:21 |
| antocuni | and also, exceptiontranform is now in translator, not translator/c | 11:21 |
| arigato | we'll have to run the test, obviously, | 11:22 |
| antocuni | sure | 11:22 |
| arigato | but at the moment it's a bit hard | 11:22 |
| arigato | next? | 11:22 |
| antocuni | what's left? | 11:22 |
| arigato | os.*() stuff | 11:23 |
| arigato | probably all to be taken from the branch | 11:23 |
| arigato | we should maybe just check what changed in the trunk here | 11:23 |
| antocuni | why was them modified on the dist? | 11:23 |
| arigato | indeed | 11:23 |
| arigato | os.tmpfile() was added | 11:25 |
| antocuni | I see | 11:26 |
| arigato | let's mark it "to be restored later" and kill it right now | 11:26 |
| arigato | there are too many "ARGH! strange hack" comments for me to feel good about it anyway :-) | 11:26 |
| antocuni | :-) | 11:27 |
| arigato | r45631 just moves a test to another file, let me see | 11:28 |
| arigato | that's it | 11:29 |
| arigato | ok, same, I'll mark it to restore it later | 11:30 |
| antocuni | it looks good now | 11:31 |
| arigato | ok..... | 11:32 |
| antocuni | what are you doing now? | 11:33 |
| arigato | I'm editing the generated file that contains the | 11:34 |
| arigato | operations that "merge3.py" found should be done | 11:34 |
| arigato | so that rpython/module and module/posix are simply copied as a whole | 11:34 |
| antocuni | ah, ok | 11:35 |
| arigato | hack+++ | 11:35 |
| arigato | walking on eggs kind of thing... | 11:36 |
| arigato | ok, the log file should be ok, we can start the merge by checking in what we edited to resolve the conflicts | 11:36 |
| arigato | warning, drugstone is about to flood this channel :-/ | 11:37 |
| drugstone | arigo - r46317 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/translator.py revisions 45507 to 46315: ------------------------------------------------------------------------ | 11:38 |
| xorAxAx | drugstone: rename flood | 11:38 |
| Nick change: drugstone -> floodtone | 11:38 | |
| floodtone | arigo - r46318 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/llinterp.py revisions 45507 to 46315: ------------------------------------------------------------------------ r460 | 11:38 |
| floodtone | arigo - r46319 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/config/translationoption.py revisions 45507 to 46315: --------------------------------------------------------------------- | 11:38 |
| floodtone | arigo - r46320 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/module/posix/__init__.py revisions 45507 to 46315: ------------------------------------------------------------------------ | 11:38 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - r46322 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/objspace/flow/objspace.py revisions 45507 to 46315: ----------------------------------------------------------------------- | 11:38 |
| floodtone | arigo - r46324 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/translator/cli/metavm.py revisions 45507 to 46315: ------------------------------------------------------------------------ | 11:38 |
| floodtone | arigo - r46325 - merging of svn+ssh://codespeak.net/svn/pypy/branch/pypy-more-rtti-inprogress/rpython/lltypesystem/lltype.py revisions 45507 to 46315: ------------------------------------------------------------------ | 11:38 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - 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 |
| floodtone | arigo - r46335 - (arigo, antocuni around) Finish merging the rffi branch into the "merging" branch. | 11:40 |
| Action: arigato -> dinner | 11:40 | |
| Action: arigato -> lunch rather | 11:40 | |
| antocuni | arigato: bon apetit | 11:40 |
| arigato | I'll run some tests on the "merging" branch and finally merge it into "dist" | 11:41 |
| arigato | thanks | 11:41 |
| arigato | antocuni: thanks for the help | 11:42 |
| exarkun | wee | 11:54 |
| Arnar | hrm.. | 12:06 |
| Arnar | non-determinism makes things hard | 12:06 |
| floodtone | arigo - r46336 - Repeat r45631: move the test so that it is llinterpreted. | 12:23 |
| floodtone | arigo - r46337 - Repeat the deletion of these two files that occurred on the pypy-more-rtti-inprogress branch. | 12:31 |
| floodtone | arigo - r46338 - Finish the merge of the pypy-more-rtti-inprogress branch. Delete the branches. | 12:34 |
| arigato | antocuni: there is at least one failure in the jvm directory | 12:41 |
| xorAxAx | pypy still depends on ctypes | 12:42 |
| xorAxAx | --> no pypy translation using pypy | 12:42 |
| xorAxAx | the reason is /home/alexander/dev/python/pypy_etc/pypy-dist/pypy/rpython/lltypesystem/rffi.py depending on ll2ctypes.py | 12:42 |
| santagada (n=santagad@201.37.109.48) joined #pypy. | 12:42 | |
| arigato | xorAxAx: can you try this: | 12:44 |
| xorAxAx | remove the import? :) | 12:44 |
| arigato | in ll2ctypes, if the "import ctypes" fails, ignore it | 12:44 |
| arigato | yes | 12:44 |
| arigato | no I mean in ll2ctypes | 12:44 |
| santagada | something very wrong happened with my repository checkout | 12:44 |
| xorAxAx | arigato: its easy to debug - i just create a ctypes.py file with "raise ImportError" :) | 12:44 |
| santagada | but it was probably my fault | 12:44 |
| arigato | xorAxAx: it seems that ctypes is not needed at import-time in ll2ctypes.py | 12:45 |
| arigato | xorAxAx: true enough :-) | 12:45 |
| Action: xorAxAx tries arigato's suggestion | 12:45 | |
| arigato | santagada: what did you do, and what happened? | 12:45 |
| santagada | arigato: 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, etc | 12:46 |
| floodtone | arigo - r46339 - Reimplement os.uname(). | 12:46 |
| arigato | santagada: you did the 'svn switch' at the wrong level? | 12:47 |
| santagada | arigato: but that is no problem | 12:47 |
| xorAxAx | standard_c_lib = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c')) | 12:47 |
| xorAxAx | fails | 12:47 |
| santagada | arigato: I thought I didn't, but maybe I did | 12:47 |
| santagada | arigato: no problem, I just came here to see how the merging is going | 12:47 |
| arigato | santagada: ok | 12:47 |
| xorAxAx | arigato: works, should i check it in? :-) | 12:50 |
| arigato | yes | 12:51 |
| xorAxAx | weeee, hacky wednesday | 12:51 |
| floodtone | xoraxax - r46340 - Do not bail out on missing ctypes (ignore the importerror), now pypy doesnt depend on ctypes for easy targets. | 12:54 |
| arigato | rlib.rmarshal is a bit broken | 12:59 |
| arigato | it needs fixing before sandbox translations can work again | 12:59 |
| jcea2 (n=jcea@jabber.hst.ru) joined #pypy. | 13:05 | |
| santagada (n=santagad@201.37.109.48) left irc: "good bye" | 13:05 | |
| antocuni | arigato: which test fails on jvm? | 13:11 |
| arigato | one about ullong_rshift I think | 13:12 |
| arigato | can't find it again right now, give me 10 minutes... | 13:14 |
| pedronis (i=pedronis@vitaly.openend.se) joined #pypy. | 13:15 | |
| antocuni | arigato: found it | 13:17 |
| arigato | ok | 13:17 |
| floodtone | arigo - r46341 - Fix rlib.rmarshal. | 13:22 |
| antocuni | is 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 | |
| arigato | antocuni: fine for me | 13:25 |
| floodtone | antocuni - r46342 - ullong_rhift for genjvm | 13:25 |
| antocuni | it seems ssh auth tooks forever from my machine (not only to codespeak, also for e.g. wyvern) | 13:26 |
| arigato | I'm thinking about starting a whole test run soon | 13:27 |
| xorAxAx | antocuni: ssh -vvvv | 13:27 |
| arigato | anything you see to fix first? | 13:27 |
| antocuni | arigato: nothing obvious, at least | 13:28 |
| floodtone | arigo - r46343 - Fix the sandlib. | 13:28 |
| arigato | ok, we'll find out about the less obvious problems in a few hours then | 13:28 |
| antocuni | xorAxAx: it hangs here: debug2: we sent a publickey packet, wait for reply | 13:28 |
| antocuni | any clue/ | 13:28 |
| antocuni | ? | 13:28 |
| xorAxAx | antocuni: hmm, it should proceed | 13:28 |
| xorAxAx | did you use 4 vs? | 13:29 |
| Nick change: idnar_ -> idnar | 13:29 | |
| antocuni | yes | 13:29 |
| antocuni | after a while it proceeds | 13:29 |
| xorAxAx | maybe your internet connection is bad | 13:30 |
| gasolin (n=chatzill@61-230-98-135.dynamic.hinet.net) left irc: Read error: 110 (Connection timed out) | 13:30 | |
| antocuni | now I can login to wyvern in less than 1 sec | 13:30 |
| arigato | :-/ | 13:30 |
| antocuni | it's not the first time codespeak has such problems | 13:30 |
| xorAxAx | [translation:ERROR] File "/home/alexander/dev/python/pypy_etc/pypy-dist/pypy/translator/c/database.py", line 95, in gettype | 13:35 |
| xorAxAx | [translation:ERROR] return PrimitiveType[T] | 13:35 |
| xorAxAx | [translation:ERROR] KeyError: <USHORT> | 13:35 |
| arigato | xorAxAx: I don't know why I didn't stumble on that error, but I see what it must be | 13:38 |
| xorAxAx | thats a pypy-c | 13:38 |
| xorAxAx | :) | 13:38 |
| nikomatsakis (n=niko@beauty.inf.ethz.ch) joined #pypy. | 13:42 | |
| nikomatsakis | hello! | 13:43 |
| antocuni | hi niko! | 13:43 |
| nikomatsakis | antocuni: I am looking right now into the best way to spread the constants out over multiple classes. | 13:43 |
| antocuni | nikomatsakis: cool, thanks | 13:44 |
| arigato | xorAxAx: works for me, though | 13:44 |
| nikomatsakis | it's not especially hard, except for the need to interact elegantly with CLI / JavaScript, etc. | 13:44 |
| arigato | xorAxAx: not quite sure how to be honest | 13:45 |
| antocuni | nikomatsakis: can I help in some way? | 13:45 |
| arigato | xorAxAx: ah, you still have no ctypes? | 13:45 |
| nikomatsakis | antocuni: it's ok, bigger problem is distractions :). I guess that JavaScript doesn't really share the same constant code? Do you know? | 13:46 |
| arigato | xorAxAx: in theory there is no reason why this particular problem depends on ctypes, | 13:46 |
| antocuni | I don't think so, but let me check | 13:46 |
| arigato | xorAxAx: it's just historical reasons | 13:46 |
| nikomatsakis | antocuni: I found some relevant-looking code in js/database.py... | 13:47 |
| antocuni | yes, there is a gen_constants method | 13:48 |
| antocuni | so I think js don't depend on oosupport for this | 13:48 |
| nikomatsakis | ok --- 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 way | 13:49 |
| antocuni | I'm slighlty worried about performances | 13:49 |
| nikomatsakis | ok, I will leave the CLI as is | 13:49 |
| antocuni | I don't know if it would make pypy-cli slower | 13:49 |
| antocuni | nikomatsakis: how hard is to leave CLI as is? | 13:49 |
| nikomatsakis | that's probably better anyhow, no need to fix what ain't broken :) | 13:49 |
| antocuni | :-) | 13:50 |
| nikomatsakis | antocuni: I don't think it's hard | 13:50 |
| antocuni | ok, good | 13:50 |
| antocuni | what could make sense is to divide constants into "logical blocks", so that they don't need to be initialized too eagerly | 13:51 |
| antocuni | but it's not trivial/not a priority now | 13:51 |
| nikomatsakis | antocuni: yes, I think that would make sense, but it's a non-trivial edit | 13:51 |
| antocuni | so, let's skip this for now :-) | 13:51 |
| xorAxAx | arigato: did you try on a pypy-c? | 13:51 |
| xorAxAx | arigato: thats pypy-c translate.py | 13:51 |
| nikomatsakis | antocuni: 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 |
| antocuni | nikomatsakis: makes a lot of sense | 13:52 |
| arigato | ah | 13:52 |
| xorAxAx | with targetrpythonedalone | 13:52 |
| gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy. | 13:52 | |
| floodtone | arigo - 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 |
| arigato | xorAxAx: try again? (no need to recompile pypy-c as far as I can tell) | 13:55 |
| xorAxAx | running | 13:58 |
| xorAxAx | .. the translation ... | 13:58 |
| xorAxAx | arigato: works, thanks | 13:59 |
| arigato | good | 13:59 |
| xorAxAx | now pypy has a usable benchmark again | 14:00 |
| mwh | that took a while :) | 14:01 |
| xorAxAx | hehe | 14:01 |
| mwh | how does pypy compare to cpython on this one now? | 14:01 |
| Action: xorAxAx tries | 14:01 | |
| xorAxAx | time ./pypy-c ./translate.py --source --batch targetrpystonedalone.py | 14:02 |
| xorAxAx | real 1m7.320s | 14:03 |
| xorAxAx | user 0m55.003s | 14:03 |
| xorAxAx | sys 0m0.612s | 14:03 |
| xorAxAx | time python ./translate.py --source --batch targetrpystonedalone.py | 14:03 |
| xorAxAx | real 0m14.660s | 14:03 |
| xorAxAx | user 0m11.273s | 14:03 |
| xorAxAx | sys 0m0.320s | 14:03 |
| xorAxAx | thats a faassen build | 14:03 |
| xorAxAx | that makes pypy 5 times as slow as cpython | 14:04 |
| antocuni | it would be interesting to profile it | 14:05 |
| xorAxAx | yeah | 14:06 |
| arigato | the CPython docs about os.tmpfile() seem to be at odds with its implementation | 14:08 |
| mwh | not too slow | 14:11 |
| xorAxAx | with llvm-via-c, it will be even faster, yeah | 14:11 |
| antocuni | arigato: a lot of jit tests fail | 14:12 |
| arigato | antocuni: thanks, will check later | 14:13 |
| floodtone | antocuni - r46345 - port test_runtest to oosupport, and remove duplicated code | 14:25 |
| gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) left irc: Read error: 110 (Connection timed out) | 14:35 | |
| arigato | I'm sure I saw somewhere a Unix function that creates an unnamed file | 14:37 |
| exarkun | arigato: how are the os.tmpfile docs wrong? | 14:37 |
| arigato | the Python docs say that no directory entry is created | 14:37 |
| arigato | this is wrong both on Windows and Linux | 14:37 |
| arigato | according to the MS docs for the C-level tmpfile(), and to "man tmpfile" on my Linux box | 14:38 |
| Action: exarkun nods | 14:38 | |
| gasolin (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy. | 14:38 | |
| arigato | based on this remark, is there any difference at all for Python applications between | 14:56 |
| arigato | os.tmpfile() and tempfile.TemporaryFile() ? | 14:56 |
| exarkun | os.tmpfile is probably better :) | 14:57 |
| exarkun | arigato: TemporaryFile leaves its file linked until it is closed, though | 14:57 |
| exarkun | arigato: tmpfile unlinks it before it returns | 14:57 |
| arigato | exarkun: uh, no | 14:58 |
| exarkun | no? | 14:58 |
| arigato | no | 14:58 |
| arigato | on posix systems (except cygwin), TemporaryFile is not a class but a function | 14:58 |
| arigato | that unlinks the file immediately | 14:58 |
| exarkun | oh | 14:58 |
| exarkun | what does os.tmpfile do on windows? also leave the file linked? | 14:59 |
| arigato | yes | 14:59 |
| arigato | but it gets removed by the C library on a non-crashing exit | 15:00 |
| arigato | ah, on Windows TemporaryFile() returns a Python object that is a wrapper around a file instead of natively a file | 15:01 |
| floodtone | arigo - 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 in | 15:12 |
| arigato | on Windows, TemporaryFile() returns a wrapper for no good reason | 15:12 |
| arigato | the only reason is that TemporaryFile = NamedTemporaryFile on this platform, | 15:12 |
| arigato | and the latter uses a wrapper so that the 'name' attribute is correct | 15:12 |
| antocuni | arigato: is 'platcheck' supposed to be compiled every time? | 15:40 |
| arigato | yes, there is no caching yet | 15:40 |
| antocuni | ok | 15:41 |
| arigato | the thing that has caching is rfficache.py, which is fijal's previous approach | 15:41 |
| arigato | before he started reusing the more powerful code from rctypes's "platcheck" | 15:42 |
| xorAxAx | isnt a bit of autoconf in all of us | 15:42 |
| arigato | so, future work would be to eventually kill rfficache.py, and independently add caching to platcheck | 15:42 |
| arigato | yes, it's clearly autoconf all over again | 15:42 |
| arigato | but at least a pure Python and Windows-friendly one | 15:43 |
| pedronis (i=pedronis@vitaly.openend.se) joined #pypy. | 15:43 | |
| arigato | I haven't given up on autolltype, either :-) | 15:43 |
| DR0ID_ (n=DR0ID_@79.69.3.213.cust.bluewin.ch) joined #pypy. | 15:44 | |
| xorAxAx | hehe | 15:44 |
| stakkars | arigato: hi! | 16:03 |
| arigato | hi! | 16:03 |
| stakkars | I was trying to run the graphviewer on my new machine and | 16:04 |
| stakkars | I think I installed evrerything, dot is there etc. And I can run an X window. | 16:04 |
| stakkars | Is there something missing? | 16:04 |
| arigato | Windows or OS/X? | 16:05 |
| stakkars | no, Debian Linux. Something about GRAPFBUFFER | 16:05 |
| stakkars | (!) DirectFB/Core: Could not initialize 'system' core! | 16:05 |
| arigato | is pygame correctly installed? | 16:05 |
| arigato | python -c "import pygame" | 16:06 |
| stakkars | well, I installed the package, but did not test | 16:06 |
| stakkars | oki..... | 16:06 |
| arigato | try pygame.init() too | 16:06 |
| stakkars | aha. there we go | 16:07 |
| stakkars | ALSA lib confmisc.c:769:(parse_card) cannot find card '' | 16:07 |
| stakkars | so I seem to need to emulate one | 16:07 |
| arigato | hum, no | 16:07 |
| arigato | the dotviewer doesn't actually call pygame.init(), to avoid grabbing the sound card unnecessarily | 16:07 |
| arigato | try again with only these inits: | 16:08 |
| stakkars | maybe it would anyway be better to use my local Mac to do the display | 16:08 |
| arigato | pygame.display.init() | 16:08 |
| arigato | pygame.font.init() | 16:08 |
| arigato | stakkars: ah, yes | 16:08 |
| arigato | there is nice support to display graphs over the network, now | 16:08 |
| arigato | works much better than a remote X display | 16:08 |
| stakkars | pygame.error: DirectFBCreate: Initialization error! | 16:09 |
| stakkars | after I did the display.init() | 16:09 |
| arigato | this pygame is not seeing the X libraries | 16:09 |
| stakkars | so something is missing. not that urgent, btw. | 16:09 |
| arigato | but if it's a remote machine, you should really not use that | 16:09 |
| arigato | try this: | 16:09 |
| arigato | first question, does your local Mac have a public IP with some open ports? | 16:10 |
| arigato | if not, or if you don't want to, we can use an ssh tunnel | 16:10 |
| stakkars | it is dynamic ip, so I would to tell it the number from the provider. Which the X connection seems to do | 16:11 |
| arigato | ok, so let's better try the ssh tunnel | 16:11 |
| stakkars | how do you do it? | 16:11 |
| arigato | from your Mac: | 16:11 |
| stakkars | this is not a speed issue? | 16:11 |
| arigato | no | 16:11 |
| arigato | ssh -R 8060:127.0.0.1:8060 remotemachine.com | 16:11 |
| arigato | once you are on the remote machine, you need to set an env var for dotviewer: | 16:12 |
| stakkars | ah! the first time that I use -R :-) | 16:12 |
| arigato | export GRAPHSERVER=127.0.0.1:8060 | 16:12 |
| stakkars | (always used -L) | 16:12 |
| arigato | :-) | 16:12 |
| stakkars | goody goody goody | 16:13 |
| arigato | on your local Mac in another terminal, you need to start this: | 16:13 |
| arigato | pypy-dist/pypy/dotviewer.py --server 127.0.0.1:8060 | 16:13 |
| arigato | then it should work: | 16:13 |
| arigato | whenever a remote Python process tries to display a graph, | 16:14 |
| arigato | as long as it finds the GRAPHSERVER variable, | 16:14 |
| arigato | it will go to your local "--server" process | 16:14 |
| stakkars | thank you sir! will come back with the result | 16:14 |
| arigato | (you need pygame installed on your Mac, clearly) | 16:14 |
| stakkars | (sure, I have) | 16:14 |
| Action: antocuni afk | 16:25 | |
| stakkars | arigato: yes, it works. After figuring that we have pypy-dist/graphserver/graphserver.py it worked :-) thank you | 16:29 |
| arigato | :-) | 16:29 |
| arigato | running "graphserver.py" is equivalent to running "dotviewer.py --server" as I said above | 16:29 |
| arigato | oups oups | 16:29 |
| stakkars | so I actually could have avoided all the X11 stuff installed. | 16:29 |
| arigato | I gave you a wrong path, sorry | 16:29 |
| arigato | for the records I mean pypy-dist/dotviewer/dotviewer.py | 16:30 |
| stakkars | sorry sorry, this is also what I did. (fuzz) | 16:30 |
| stakkars | ./pypy-dist/dotviewer/dotviewer.py --server 127.0.0.1:8060 | 16:31 |
| arigato | the 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 data | 16:31 |
| Nick change: karltk_ -> karltk | 16:32 | |
| stakkars | but 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 |
| arigato | it 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 |
| stakkars | hmm. 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 hmm | 16:44 |
| stakkars | my Mac | 16:44 |
| stakkars | nice 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 |
| stakkars | this was a fresh checkout of pypy-dist, on OS X | 17:00 |
| xorAxAx | which translation options? | 17:00 |
| stakkars | python translate.py targetpypystandalone.py --faassen --allworkingmodules --withmod-_stackless | 17:01 |
| xorAxAx | and in which function does it crash? | 17:01 |
| stakkars | see above - _rtype_compare_template() | 17:02 |
| xorAxAx | ... | 17:02 |
| xorAxAx | which function graph? | 17:02 |
| rhymes (n=rhymes@213.212.148.34) left irc: "This computer has gone to sleep" | 17:03 | |
| stakkars | no idea. you mean the caller of the func? I killed it, already, but we'll get my Linux build, soon | 17:04 |
| xorAxAx | stakkars: no, the function graph that was being worked on by the rtyper | 17:04 |
| mwh | oh | 17:05 |
| mwh | that's os.times | 17:05 |
| mwh | (clock_t is unsigned on os x) | 17:06 |
| mwh | not sure how to fix it myself | 17:06 |
| stakkars | hi Mike. whow | 17:06 |
| cmd (i=dmc@astray.fragstore.net) joined #pypy. | 17:07 | |
| mwh | at least, that was the cause of the translation i tried the other day failing | 17:07 |
| stakkars | so that happens with all OSX builds, atm. Nice, PyCon UK :-) | 17:07 |
| stakkars | I would love to have an ignore-errors option, since I don't need os.time for my demo | 17:09 |
| xorAxAx | stakkars: easy to fix - just put an "import os; del os.times" into your translate.py | 17:10 |
| xorAxAx | ;-) | 17:10 |
| arigato | I can fix this one easily | 17:10 |
| arigato | with a cast | 17:11 |
| stakkars | hehe | 17:11 |
| mwh | arigato: that would be nice :) | 17:11 |
| stakkars | whow, the Linux build crashed as well... | 17:11 |
| xorAxAx | stakkars: it doesnt for me | 17:11 |
| stakkars | the exact one that I pasted? | 17:12 |
| arigato | might be because of --allworkingmodules | 17:12 |
| arigato | I never tried that on the branch that was just merged, I guess | 17: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 |
| arigato | stakkars, mwh: try again on OS/X? | 17:12 |
| floodtone | arigo - r46348 - clock_t is unsigned on OS/X - missing a cast. | 17:13 |
| stakkars | TypeError': calling <Func ( CInt, CInt ) -> CInt> with wrong argument types: [<Signed>, <Signed>] | 17:13 |
| xorAxAx | arigato: wouldnt it be cleaner to check the type of clock_t? | 17:13 |
| arigato | xorAxAx: uh? no | 17:13 |
| arigato | xorAxAx: even in "clean" C code you're supposed to check if the result value is (clock_t)-1, not -1 | 17:13 |
| xorAxAx | arigato: because it is 64 bits on some platforms | 17:13 |
| stakkars | arigato: yes, compiling | 17:13 |
| xorAxAx | well, didnt look at the patch :) | 17:13 |
| arigato | xorAxAx: please do :-) | 17:13 |
| xorAxAx | hehe | 17:14 |
| arigato | (the type of clock_t is not hard-coded, it's computed by the rfficache magic) | 17:14 |
| xorAxAx | ah, ok | 17:16 |
| stakkars | ok, thn let's see if they both crash consistently, now :-) | 17:18 |
| floodtone | arigo - r46349 - Oups, there is a test for this function. Keep the old signature valid. | 17:19 |
| arigato | failures in rpython.memory.test.test_gc... | 17:19 |
| arigato | most llvm tests fail too | 17:20 |
| arigato | seems to be for shallow reasons | 17:20 |
| floodtone | arigo - r46350 - Skip all llvm tests for now... | 17:23 |
| stakkars | crashed on Linux, amd64 | 17:27 |
| arigato | we explicitly don't support 64-bit machines | 17:27 |
| stakkars | what does this mean, do I set something to behave? | 17:28 |
| arigato | no, in the sense that there are known, shallow, issues | 17:28 |
| arigato | and nobody wanted to fix them yet | 17:28 |
| arigato | shallow but still some work to fix | 17:28 |
| mwh | rtyping completed on os x now | 17:29 |
| arigato | mwh: progress | 17:29 |
| nikomatsakis (n=niko@beauty.inf.ethz.ch) left irc: Read error: 110 (Connection timed out) | 17:29 | |
| stakkars | waah. I had the choice to install 32-bit but choose 64, because they are all moving towards this - hum | 17:29 |
| stakkars | OS X looks happy on my side, too. inlining | 17:30 |
| xorAxAx | stakkars: debootstrap a 32 bit tree | 17:30 |
| xorAxAx | stakkars: works fine | 17:30 |
| stakkars | xorAxAx: after I got so far with my machine, so much running, I should wipe it ??? | 17:32 |
| floodtone | arigo - r46352 - These two tests were too precise. | 17:33 |
| stakkars | or can I leave it intact, just switch and re | 17:33 |
| stakkars | apt-get dist-upgrade? | 17:33 |
| xorAxAx | stakkars: not wipe it! | 17:33 |
| xorAxAx | stakkars: man chroot | 17:34 |
| xorAxAx | stakkars: its described in `man debootstrap` | 17:34 |
| xorAxAx | and pretty easy to use | 17:34 |
| stakkars | a ch-rooted 32 bit system, then I would need to boot into that? | 17:34 |
| xorAxAx | no | 17:35 |
| xorAxAx | chroot /path | 17:35 |
| xorAxAx | finished | 17:35 |
| stakkars | reading... | 17:35 |
| stakkars | xorAxAx: and the same 64 bit kernel would live with that? | 17:40 |
| xorAxAx | stakkars: yes! | 17:41 |
| xorAxAx | thats the magic of 25 years of A20 gate compatiblity | 17:41 |
| stakkars | so it is all about compiler versions etc | 17:41 |
| xorAxAx | stakkars: in your debootstrap env, you will have your own compiler | 17:41 |
| xorAxAx | after you have installed it :) | 17:42 |
| arigato | jacob22: 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 |
| xorAxAx | which makes it pretty troublefree | 17:42 |
| arigato | jacob22: related to the changes in __future__ imports | 17:42 |
| stakkars | ok, I might try this after PyCon uk. | 17:42 |
| stakkars | or 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 | |
| mwh | writing c now | 17:42 |
| stakkars | mine is at 86000 nodes, now | 17:43 |
| arigato | stakkars: fwiw, we have a long-standing stackless pickling failure too | 17:43 |
| arigato | stakkars: http://wyvern.cs.uni-duesseldorf.de/pypytest/46343/failed/lib.test2.test_stackless.py.AppTest_Stacklesstest_pickle.html | 17:43 |
| stakkars | arigato: absolutely. this was I tried to fix last night. Somehow it got me into compiling. | 17:44 |
| arigato | antocuni: while I'm at distributing blames, TestCarbonPython.test_compile_class fails every other day and still failed after the merge | 17:44 |
| arigato | stakkars: ok | 17:45 |
| arigato | thanks | 17:45 |
| stakkars | for some reason, I could not reproduce how to call the test, correctly, without causing some compilation which failed. | 17:45 |
| arigato | ah, my Linux translation on wyvern is in backendopts | 17:46 |
| xorAxAx | stakkars: not much to try about that - debootstrap is less than 1 minute of effort | 17:46 |
| arigato | xorAxAx: well, then you have to reinstall some programs in there, I guess | 17:46 |
| xorAxAx | then you issue apt-get install python2.4-dev build-essential and can start to use pypy | 17:46 |
| arigato | ok :-) | 17:46 |
| xorAxAx | arigato: 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 | |
| stakkars | ah - ok. good to learn | 17:47 |
| arigato | yes, I recently gave up upgrading a gentoo machine and dropped an Ubuntu on it - that was incredibly fast :-) | 17:47 |
| xorAxAx | :-) | 17:47 |
| arigato | mwh: :-) | 17:47 |
| xorAxAx | in fact, ubuntu has some issues on upgrades | 17:47 |
| xorAxAx | e.g. it creates the initrd ~ 10 times on an avg. installation | 17:48 |
| xorAxAx | (with a few driver packages etc.) | 17:48 |
| stakkars | yes, I read about it, so I stick with Debian testing. | 17:48 |
| xorAxAx | so its slow if your machine can only pack slowly | 17: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 |
| xorAxAx | arigato: it asks you if you want to partition yourself | 17:48 |
| xorAxAx | but those ubuntu issues of the slowness would need dpkg extensions that are not yet in debian to be fixes | 17:49 |
| xorAxAx | s/s$/d// | 17:49 |
| stakkars | writing c... | 17:49 |
| arigato | xorAxAx: I chose that option, in fact the partition were already there, but still it wants to reformat the / partition | 17:50 |
| xorAxAx | arigato: ah, indeed, it only likes ext3 for / IIRC | 17:50 |
| xorAxAx | or something like that | 17:50 |
| arigato | ah, that might be the issue | 17:50 |
| xorAxAx | pretty annoying, yes | 17:50 |
| xorAxAx | (the various bugs in the partitioning integration in the fancy installer) | 17:51 |
| arigato | maybe I was just confused by the error message then, and an already-ext3 / would not have required reformatting | 17:51 |
| floodtone | arigo - 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 |
| stakkars | arigato: how exactly is the failing test called, again? | 17:52 |
| arigato | test_pickle | 17:52 |
| arigato | in lib.test2.test_stackless | 17:52 |
| Action: pedronis -> home | 17:52 | |
| pedronis | see you | 17:52 |
| stakkars | no how the test is run. test-all | 17:52 |
| arigato | see you | 17:53 |
| pedronis (i=pedronis@vitaly.openend.se) left irc: "ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072300]" | 17:53 | |
| stakkars | bye | 17:53 |
| stakkars | I must have done something that causes compilation | 17:53 |
| arigato | it'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 |
| arigato | the C compiler is called a few times when you start py.py now | 17:54 |
| arigato | for platform checking | 17:55 |
| stakkars | and that drove me crazy, tonight, because there were failures | 17:55 |
| Action: stakkars going to check this, again | 17:55 | |
| arigato | crashes, or just compilation failures that appeared ignored? | 17:55 |
| arigato | the latter are fine | 17:56 |
| stakkars | something red, not sure, it was late - will try again... | 17:56 |
| arigato | mwh: are you interested in hearing the next framework-gc-related tale? | 17:59 |
| arigato | it's pretty good, it has ordering issues in it | 18:00 |
| mwh | arigato: perhaps? | 18:00 |
| mwh | arigato: is lowleveldatabase still too transparent and simple? | 18:00 |
| mwh | ^.complete | 18:00 |
| arigato | no, it's found by the llinterpreter already | 18:03 |
| arigato | MarkSweepGC.collect() -> print time.time() -> gettimeofday | 18:03 |
| arigato | which is an external function | 18:03 |
| arigato | so it really arrives in a wrapper built by rffi.py | 18:03 |
| arigato | which is called gettimeofday_star2 | 18:03 |
| arigato | notice the star2 | 18:04 |
| arigato | because it takes a *arg | 18:04 |
| arigato | which is a tuple | 18:04 |
| arigato | which needs to be allocated | 18:04 |
| arigato | but it's a tuple of a type that is not seen elsewhere in the program | 18:04 |
| arigato | so the gc transformer didn't allocate a typeid for it | 18:04 |
| mwh | arigato: lets rewrite pypy in prolog | 18:05 |
| stakkars | arigato: this works, today. No idea about yesterday, but now I can fix the piuckling (but should produce slides) | 18:09 |
| simonpy | arigato: did you fix this problem? | 18:09 |
| arigato | simonpy: hi! I hope the branch merge didn't cause too much troubles | 18:10 |
| simonpy | arigato: hi! | 18:10 |
| arigato | which problem, the gc fun above? | 18:10 |
| simonpy | yes | 18:10 |
| arigato | no | 18:10 |
| simonpy | :) | 18:10 |
| arigato | I'm not sure how the 'struct timeval' gets a typeid for the gc transformer, | 18:10 |
| arigato | although it also only appears in time_time_llimpl() | 18:11 |
| arigato | ah, oh, I see - 'struct timeval' is raw-malloced, not it's not handled by the gc at all | 18:12 |
| arigato | I guess I'm going to disable the wrapper around gettimeofday | 18:15 |
| arigato | a bit of a hack in this case | 18:15 |
| simonpy | ok | 18:15 |
| arigato | but well, nothing should really allocate gc-managed data during a gc collection | 18:15 |
| mwh | right, that's already pretty bad | 18:17 |
| floodtone | arigo - r46354 - MarkSweepGC.collect() -> time.time() -> wrapper from rffi The latter takes a *arg, which needs to be GC-allocated -> boom | 18:20 |
| arigato | ah | 18:21 |
| arigato | rgh | 18:21 |
| arigato | rgh! | 18:21 |
| arigato | could 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 | |
| arigato | it doesn't quite know what to do with all these raw-malloc | 18:22 |
| gasolin_ (n=chatzill@220-132-160-66.HINET-IP.hinet.net) joined #pypy. | 18:22 | |
| mwh | is that the very old way of running tests on the llinterp after gc transformation? | 18:22 |
| arigato | yes | 18:22 |
| arigato | it's been sitting on samuele's black list for a long time | 18:23 |
| mwh | isn't it something like there's no other way of testing the semi space collector yet that's keeping it alive? | 18:24 |
| arigato | I think so, yes | 18:25 |
| arigato | however, ah ha, the SemiSpaceGC doesn't call time.time() | 18:25 |
| Action: arigato thinks of disabling just TestMarkSweepGCRunningOnLLinterp | 18:25 | |
| floodtone | arigo - 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 o | 18:28 |
| arigato | yuk about the jit test failures too | 18:30 |
| floodtone | arigo - 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 connection | 19: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 Quit | 19: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 Quit | 19:25 | |
| Action: rhymes is away: Away | 19:25 | |
| floodtone | simonb - r46357 - get transpose to work, add a reshape method | 19:27 |
| pedronis | arigato: working on killing the simulator is the next pypy thing I want to do | 19:30 |
| pedronis | although first I also need to do the preparation work to have support for implicitly releasing the gil around external calls | 19:31 |
| floodtone | antocuni - 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 |
| arigato | pedronis: ah | 20:01 |
| pedronis_ (n=chatzill@c-118b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy. | 20:01 | |
| arigato | pedronis_: I was thinking about the GIL release too | 20:01 |
| arigato | I guess we should simply move towards a global GIL instead of a per-space one | 20:01 |
| arigato | unless you can think about something more clever | 20:01 |
| pedronis_ | did you see my discussion with fijal | 20:02 |
| arigato | no | 20: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/weaved | 20:03 |
| arigato | uh | 20:03 |
| pedronis_ | ? | 20:03 |
| pedronis_ | were you thinking of writing manual release code? | 20:04 |
| pedronis_ | or to make the GIL an rpython concept | 20:04 |
| arigato | couldn't we simply insert calls to these hook in the wrapper function produced by rffi.llexternal? | 20:04 |
| arigato | by insert I mean writing the calls manually there, yes | 20:05 |
| pedronis_ | but then you need to make the GIL part of rpython | 20:05 |
| arigato | I guess I don't see what you propose | 20:05 |
| pedronis_ | how would the intepreter and the code in rffi.llexternal refer to the same GIL? | 20:06 |
| arigato | you need to push hooks from one level to the other, yes | 20:07 |
| arigato | I don't see the bit about flagging ll function pointers | 20: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 you | 20:08 |
| pedronis_ | using hlinvoke like logic | 20:09 |
| pedronis_ | releaseGIL and acquireGIL would be high level functions | 20:09 |
| arigato | and 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 initialization | 20:09 |
| pedronis_ | it would be a special function that does nothing but remembers the information | 20:10 |
| pedronis_ | when annotated | 20:10 |
| arigato | ah | 20:10 |
| arigato | looks obscure, given that we already need special logic for threads at a couple of places, but why not | 20:10 |
| arigato | I mean this information could be attached more directly to the annotation policy or something | 20:11 |
| pedronis_ | that's possible too but then you need the space | 20:11 |
| pedronis_ | unless you make the the GIL global | 20:11 |
| Action: Rhamphoryncus should probably interject on this conversation | 20:11 | |
| pedronis_ | the two hooks can be bound method on some pbc | 20:11 |
| pedronis_ | in the other model | 20:12 |
| pedronis_ | I agree is maybe too general | 20:12 |
| arigato | well, or not enough | 20:12 |
| arigato | you mean 'space.acquireGIL' and 'space.releaseGIL' | 20:12 |
| pedronis_ | but having rffi know about the GIL is strange too | 20:12 |
| arigato | it's not general enough because it wouldn't really work with multiple spaces anyway | 20:12 |
| xorAxAx | pedronis_: why? | 20:12 |
| arigato | so it's just a roundabout way to having a global GIL | 20:12 |
| Rhamphoryncus | hrm. Are you just talking about a simple GIL, or are you talking about different stuff to get scalable threading? | 20:13 |
| xorAxAx | i think the GIL knowledge would fit into rpython | 20:13 |
| xorAxAx | because threads are pretty low-level | 20:13 |
| pedronis_ | you still want at least the control not to have a GIL | 20:13 |
| arigato | Rhamphoryncus: simple GIL | 20:13 |
| xorAxAx | yes | 20:13 |
| pedronis_ | also if you have multiple spaces you have problems at various level anyway | 20:14 |
| Rhamphoryncus | arigato: 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 locals | 20:14 |
| pedronis_ | with thread locals | 20:14 |
| pedronis_ | basically having multiple spaces is not something we have worked out | 20:14 |
| pedronis_ | how it would really work | 20:15 |
| xorAxAx | you could have multiple python modules | 20:15 |
| arigato | well, it worked at some point in time | 20:15 |
| xorAxAx | in sys.modules | 20:15 |
| arigato | (for a fixed number of prebuilt spaces) | 20:15 |
| xorAxAx | arigato: never, only different instances of the same space | 20:15 |
| arigato | xorAxAx: that's what I mean | 20:15 |
| floodtone | antocuni - 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 |
| xorAxAx | the more general solution would be even useful :) | 20:15 |
| arigato | I'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 case | 20:16 |
| arigato | maybe 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 function | 20:17 |
| pedronis_ | you would need to know on behalf of which space | 20:17 |
| pedronis_ | you have been invoked | 20:18 |
| pedronis_ | to release one of the multiple gils | 20:18 |
| arigato | hence the idea of thread-locals... maybe | 20:18 |
| pedronis_ | basically the interface is orthogonal to that problem | 20:19 |
| xorAxAx | hmm | 20:19 |
| arigato | I see | 20:19 |
| simonpy | are we talking about rpython threading (&locking) or app level threading ? | 20:20 |
| pedronis_ | it may still be overkill to do it way I propose | 20:20 |
| pedronis_ | I suppose it would make sense if we could think of other use cases for the functionality | 20:20 |
| arigato | pedronis_: what about a special function gettranslationpolicy() that return the Policy as a frozen constant... | 20:21 |
| arigato | then we can put the calls manually in the wrapper in rffi.py | 20:22 |
| pedronis_ | you mean the annotation policy ? | 20:22 |
| arigato | yes | 20:22 |
| arigato | could be something else - the idea is some frozen object that can be chosen somewhere sane | 20:22 |
| pedronis_ | but releasing the gil needs external calls too | 20:23 |
| pedronis_ | which need not to release it | 20:23 |
| pedronis_ | you need a flag on llexternal | 20:23 |
| arigato | yes, you need that in any case, because there are some external calls that should not release the GIL | 20:23 |
| pedronis_ | also rffi would need to define the GIL | 20:24 |
| pedronis_ | so the intepreter would import it I suppose | 20:24 |
| arigato | I'm just saying that adding the flag to the ll function pointer and knowledge about it in the rtyper looks overkill to me | 20:24 |
| arigato | pedronis_: no, I meant code like: | 20:24 |
| arigato | gettranslationpolicy().before_external_call() | 20:25 |
| arigato | with a default empty method before_external_call() on the policy | 20:25 |
| arigato | which is overridden in PyPyAnnotationPolicy | 20:25 |
| pedronis_ | one issue | 20:25 |
| arigato | (...where there is already GIL-specific code, FWIW) | 20:25 |
| pedronis_ | in the policy? | 20:26 |
| arigato | yes, I just noticed | 20:26 |
| arigato | to handle 'specialize:yield_thread' | 20:26 |
| pedronis_ | one issue is that you need to be careful that the before and after | 20:26 |
| pedronis_ | don't create new annotations | 20:26 |
| pedronis_ | or you need to emulate pbc call them | 20:27 |
| pedronis_ | because the llexternal wrapper | 20:27 |
| arigato | ? confused | 20:27 |
| pedronis_ | are annotated quite late | 20:27 |
| pedronis_ | you could not put code that adds new attributes for example | 20:27 |
| pedronis_ | in there | 20:27 |
| pedronis_ | in the after and the before | 20:27 |
| pedronis_ | unless you pbc emulate call them early | 20:28 |
| arigato | yes, changing classes is definitely forbidden | 20:28 |
| arigato | it's a theoretical issue in both approaches as far as I can tell, | 20:28 |
| arigato | but it doesn't look likely | 20:28 |
| arigato | the before and after should just call the release and acquire methods on a prebuilt object | 20:29 |
| arigato | ah, sorry, I see why your proposed approach doesn't have this issue | 20: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 name | 20:31 |
| xorAxAx | hmmmm | 20:31 |
| arigato | yes | 20:31 |
| xorAxAx | i get a FP trap for 10 / i where i is 0 | 20:32 |
| pedronis_ | unless you pass flags | 20:32 |
| pedronis_ | to a memo on the policy | 20:32 |
| xorAxAx | that sounds certainly b0rked for me - there is no FP involved | 20:32 |
| arigato | xorAxAx: works for me | 20:32 |
| arigato | xorAxAx: it's correct behavior too | 20:32 |
| arigato | to get an "FP trap" | 20:33 |
| xorAxAx | why? | 20:33 |
| arigato | on x86 an integer division by zero is the same signal, if I remember correctly, than an FP error | 20:33 |
| xorAxAx | ah | 20:33 |
| xorAxAx | why doesnt except ZeroDivisionError: help here? | 20:33 |
| xorAxAx | do i need to do the checking myself? | 20:34 |
| arigato | in RPython? yes | 20:34 |
| arigato | er, no | 20:34 |
| arigato | sorry | 20:34 |
| arigato | maybe you need an ovfcheck(x/y) | 20:34 |
| xorAxAx | ah | 20:35 |
| arigato | no, no clue | 20:35 |
| xorAxAx | its generating no exc checks | 20: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 program | 20:48 | |
| xorAxAx | s/rpy/py/ | 20:48 |
| Nick change: pedronis_ -> pedronis | 20:49 | |
| lac_ (n=lac@c-22c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy. | 20:56 | |
| xorAxAx | now you may place your bets - how many raised rpython level exceptions for a pystone run? | 20:58 |
| exarkun | 750k | 20:59 |
| exarkun | (that's exceptions, not dollars) | 20:59 |
| antocuni | xorAxAx: a pypy-c pystone or a rpython? with or without backendopt? | 20:59 |
| xorAxAx | a python pystone | 21:00 |
| xorAxAx | a regular translation | 21:00 |
| xorAxAx | == with backendopts | 21:00 |
| Action: antocuni has really not clue | 21:00 | |
| Action: xorAxAx has no idea how many we will see - still translating :) | 21:00 | |
| xorAxAx | maybe i should have patched the C source | 21:01 |
| antocuni | uh, probably a lot: there is at least an exception for each bytecode executed | 21:01 |
| pedronis | ? | 21:02 |
| exarkun | ouch, an exception per bytecode? that's insane. | 21:02 |
| pedronis | that's not the case | 21:02 |
| pedronis | there's one per function call | 21:02 |
| xorAxAx | maybe on the llinterpreter :) | 21:02 |
| pedronis | and there is iteration | 21:03 |
| xorAxAx | pedronis: iteration doesnt raise | 21:03 |
| xorAxAx | in the end | 21:03 |
| pedronis | the python level one does | 21:03 |
| xorAxAx | yes | 21:03 |
| pedronis | I was not saying rpython iteration | 21:03 |
| xorAxAx | does pystone use iterators? | 21:03 |
| xorAxAx | :-) | 21:03 |
| pedronis | I don't know | 21:03 |
| Action: xorAxAx wonders how expensive this one is: # define RPyCHECK(x) ((x) || (abort(), 0)) | 21:03 | |
| xorAxAx | it should be called rather frequently | 21:04 |
| pedronis | there maybe some key errors | 21:04 |
| pedronis | althoug we added None returning variant | 21:04 |
| pedronis | to cover most cases | 21:04 |
| pedronis | this was a rpython key error | 21:04 |
| floodtone | antocuni - r46360 - implement cast_primitive for jvm | 21:07 |
| antocuni | pedronis: ah sure, as always I was wrong :-) | 21:08 |
| xorAxAx | generating C code | 21: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` -> pedronis | 21:20 | |
| arigato | translate.py --sandbox crashes on the interesting line 198 of rlib/rmarshal.py | 21:28 |
| xorAxAx | pypy interpreter startup and quit - 23940 exceptions | 21:35 |
| xorAxAx | now place your bets (again) for pystone :) | 21:35 |
| exarkun | xorAxAx: is that interpreting site.py? | 21:36 |
| xorAxAx | exarkun: yes | 21:37 |
| xorAxAx | wow, i chose the wrong data type | 21:37 |
| xorAxAx | well, anyway, your bets? :) | 21:37 |
| exarkun | I'll stick with my first guess I guess | 21:37 |
| xorAxAx | nobody else? :) | 21:38 |
| xorAxAx | ./pypy-c -c 'from test import pystone;pystone.main()' | 21:39 |
| xorAxAx | that gives 50000 passes | 21:39 |
| xorAxAx | and our counter says: | 21:39 |
| xorAxAx | Exceptions raised: 2014555 | 21:39 |
| xorAxAx | exarkun: so its about 3 times more | 21:40 |
| antocuni | xorAxAx: do you also know which exceptions are raised more often? | 21:40 |
| xorAxAx | antocuni: nope | 21:41 |
| exarkun | woo within an order of magnitude | 21:41 |
| xorAxAx | exarkun: yes, 1st place, you get the prize | 21:41 |
| xorAxAx | antocuni: but i can extend the code to check that | 21:42 |
| antocuni | I think it would be interesting | 21:42 |
| xorAxAx | arigato, pedronis: is this high amount expected? :) | 21:44 |
| arigato | 40 per loop - it's not that high | 21:46 |
| xorAxAx | well :) | 21:47 |
| xorAxAx | i guess cpython has less | 21:47 |
| pedronis | there's one per function call, as I said | 21:47 |
| exarkun | xorAxAx: CPython has 0 right? C doesn't have exceptions? | 21:47 |
| exarkun | 0 is less than 2014555 I think | 21:48 |
| xorAxAx | exarkun: well | 21:48 |
| xorAxAx | exarkun: even in cpython you get exceptions when executing code (stopiteration for example) | 21:48 |
| xorAxAx | not sure if pystone iterates, though | 21:48 |
| exarkun | xorAxAx: True, I guess. | 21:48 |
| xorAxAx | the above number includes app-level exceptions as well but there arent many | 21:49 |
| exarkun | How does translated rpython exception handling compare to exception handling in the Python C API? | 21:49 |
| exarkun | is 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 |
| xorAxAx | basically, exceptions work similarly | 21:50 |
| exarkun | anthropomorphizing | 21:50 |
| pedronis | yes | 21:50 |
| pedronis | calls alone can easely account for th 40 exc per iteration | 21:57 |
| exarkun | sounds like an easy optimization? :) | 21:58 |
| pedronis | not really | 21:58 |
| pedronis | the current bytecode loop structure is a compromise | 21:59 |
| pedronis | I'm also not sure that 40 exception cost that much in the amount of stuff | 21:59 |
| pedronis | that happens in one pystone iteration | 21:59 |
| Action: exarkun nods | 21:59 | |
| xorAxAx | for 100 loops, its 5246 without site | 22:01 |
| xorAxAx | for 10000 its 41246 | 22:01 |
| xorAxAx | that rather looks like 4 and not 40 | 22:01 |
| xorAxAx | ah, no | 22:02 |
| xorAxAx | for 1000 its 41246 | 22:02 |
| pedronis | well, it's in the expected range I would say | 22:04 |
| pedronis | pystone is calling stuff a bit | 22:04 |
| xorAxAx | hmm | 22:05 |
| rhymes (n=rhymes@host37-78-dynamic.0-79-r.retail.telecomitalia.it) left irc: "python is what you need" | 22:06 | |
| xorAxAx | richards does 9777402 | 22:11 |
| pedronis | the kind of exceptions would be more useful information | 22:12 |
| pedronis | not sure there's any simple win here unless we are doing something very | 22:12 |
| pedronis | stupid somewhere | 22:12 |
| xorAxAx | :) | 22:15 |
| xorAxAx | its not so easy to count the typed ones | 22:15 |
| xorAxAx | i could filter the return value ones, though | 22: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 connection | 23:28 | |
| Action: pedronis goes to sleep | 23:53 | |
| jcea2 (n=jcea@jabber.hst.ru) left irc: Remote closed the connection | 23: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 2007 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!