| arigo | how far are we now? | 00:00 |
|---|---|---|
| pedronis | well after | 00:01 |
| pedronis | the work we did on interpapp | 00:01 |
| pedronis | and my last improvements | 00:02 |
| pedronis | on exception handling annotations | 00:02 |
| pedronis | it spew | 00:02 |
| pedronis | s | 00:02 |
| pedronis | cannot follow SomeObject() much rarely | 00:02 |
| arigo | oh hoo | 00:02 |
| pedronis | but now it goes to subtle issues | 00:02 |
| pedronis | like wrap(str) | 00:02 |
| pedronis | gets annotated to W_Object | 00:03 |
| pedronis | because the path that considers None | 00:03 |
| pedronis | is also included | 00:03 |
| arigo | why? | 00:03 |
| pedronis | because I presume | 00:04 |
| pedronis | SomeString() is None | 00:04 |
| pedronis | return SomeBool() | 00:04 |
| arigo | ah, yes I see | 00:04 |
| pedronis | which is not wrong in general terms | 00:04 |
| pedronis | but yes None inclusive or exclusive | 00:04 |
| arigo | always the same problem indeed | 00:05 |
| pedronis | can be an issue | 00:05 |
| arigo | anyway W_Object should be a good enough answer for str("x") now | 00:05 |
| pedronis | then we have an issue | 00:05 |
| pedronis | with str_w and int_w | 00:05 |
| pedronis | but that's our fault | 00:06 |
| pedronis | because we are wrapping them like all others | 00:06 |
| pedronis | multimethods | 00:06 |
| pedronis | which means they also get if ... is None | 00:06 |
| pedronis | return w_None | 00:06 |
| pedronis | path | 00:06 |
| pedronis | but for them that's wrong | 00:06 |
| arigo | argh I see | 00:07 |
| pedronis | but if we solve that | 00:07 |
| pedronis | they should be properly annotated | 00:07 |
| arigo | good | 00:07 |
| pedronis | I checked in a simple test | 00:07 |
| pedronis | that shows that | 00:07 |
| pedronis | test_annmm | 00:08 |
| arigo | (it would have been more difficult to separate the mms with the previous mm implementation) | 00:09 |
| pedronis | yes | 00:09 |
| arigo | I cannot find test_annmm? | 00:09 |
| pedronis | it's under translator/test | 00:09 |
| arigo | oh it's a file name, sorry | 00:10 |
| pedronis | one problem is that the codebasa is huge | 00:11 |
| pedronis | that means that we can get to a shallow problem | 00:11 |
| pedronis | missing builtin etc | 00:11 |
| pedronis | before the significant paths | 00:11 |
| pedronis | of some important | 00:12 |
| pedronis | function | 00:12 |
| pedronis | have benn explored | 00:12 |
| arigo | I imagine so | 00:12 |
| pedronis | so the impression is that things have improved a lot | 00:13 |
| arigo | in stdtypedef.py, make_perform_trampoline() | 00:15 |
| arigo | takes a 'allow_NotImplemented_results=False' arg, but is only called once with allow_NotImplemented_results=True? | 00:16 |
| arigo | oh sorry | 00:16 |
| arigo | I missed another call from objspace.py. | 00:16 |
| pedronis | yes | 00:16 |
| pedronis | btw is the call that is wrapping also str_w int_w | 00:17 |
| pedronis | which need to be treated a bit differently | 00:17 |
| arigo | also, None -> w_None isn't really needed for some of the operations like 'setitem' | 00:17 |
| pedronis | yes, I thought about that | 00:18 |
| pedronis | we could be more precise | 00:18 |
| pedronis | in general | 00:18 |
| pedronis | another thing is that we need a precise approach about cheating code | 00:20 |
| pedronis | because for example sometimes | 00:20 |
| pedronis | it dies | 00:20 |
| pedronis | on sys.exc_info | 00:20 |
| pedronis | calls inside fake | 00:20 |
| pedronis | or I had to remove by hand | 00:21 |
| pedronis | pypy_getudir from sys | 00:22 |
| pedronis | in the new buildcache code | 00:22 |
| arigo | pypy_getudir should probably be added by hand from the conftest, instead | 00:23 |
| arigo | for fake.py we might need special tags "annotator, don't look here" | 00:25 |
| pedronis | we will also have a problem | 00:26 |
| pedronis | with the compile builtin | 00:27 |
| pedronis | which uses python one | 00:27 |
| arigo | are you thinking about a full CPython-independent translation? | 00:28 |
| pedronis | no | 00:28 |
| pedronis | just that typing | 00:28 |
| pedronis | some costructs is tricky | 00:29 |
| pedronis | my point is not that we cannot assign a type to result | 00:29 |
| pedronis | of cpython compile | 00:29 |
| pedronis | but that then we use PyCode._from_code | 00:29 |
| pedronis | on it | 00:29 |
| pedronis | which is marked NOT_RPYTHON | 00:29 |
| pedronis | and the annotator dies on call to NOT_RPYTHON | 00:30 |
| pedronis | stuff | 00:30 |
| arigo | PyCode._from_code() is not NOT_RPYTHON | 00:30 |
| arigo | but its type-checking assertions are too weak | 00:30 |
| arigo | like co_names becomes a list, but we don't know of what | 00:30 |
| pedronis | yes, it also mixing tuple and lists | 00:31 |
| arigo | right | 00:31 |
| pedronis | wich results in SomeObject | 00:31 |
| pedronis | for the annotator | 00:31 |
| arigo | shouldn't be too hard, e.g. self.co_names = [str(x) for x in code.co_names] | 00:31 |
| pedronis | yes | 00:32 |
| arigo | with a comment about the str() | 00:32 |
| pedronis | as I said the question is whether there's a way | 00:32 |
| pedronis | to pick smaller subset | 00:32 |
| pedronis | s | 00:32 |
| pedronis | instead of the whole | 00:32 |
| pedronis | because it seems we have a series of more or less shallow problems | 00:32 |
| pedronis | or maybe some serious problems but hidden away | 00:33 |
| pedronis | but a pile of shallow ones | 00:33 |
| pedronis | s/but/by | 00:33 |
| arigo | we could use special-case tables | 00:33 |
| arigo | manually-specified input and output argument types for a set of functions | 00:34 |
| arigo | e.g. for all the space operations | 00:34 |
| arigo | then we'd be able to annotate the interpreter/ directory alone | 00:34 |
| pedronis | yes | 00:34 |
| pedronis | something along those line | 00:34 |
| arigo | actually we could have a dummy 'space' | 00:34 |
| pedronis | yes | 00:34 |
| pedronis | I thought about that | 00:35 |
| pedronis | on the reverse side | 00:36 |
| pedronis | I'm thinking about how many dependecies | 00:36 |
| pedronis | are there between the space and the interpreter | 00:36 |
| pedronis | a part all the OperationError | 00:36 |
| pedronis | constructions | 00:36 |
| arigo | dependencies should go through space.getexecutioncontext() | 00:37 |
| arigo | but it seems the stdobjspace never calls that | 00:37 |
| arigo | so it's quite possible that we could annotate the stdobjspace alone by not putting any interpreter/typedef in the mm model | 00:39 |
| arigo | hum no, they are not in the mm model... | 00:39 |
| pedronis | no | 00:39 |
| pedronis | they constructed on the fly | 00:39 |
| pedronis | on the other hand | 00:40 |
| pedronis | we have some manual references to Function etc | 00:40 |
| pedronis | in space code | 00:40 |
| arigo | ah, right | 00:41 |
| arigo | we cannot really annotate the space without knowing about Functions and Methods, right? | 00:41 |
| arigo | unless we don't annotate stdtypedef.py nor the prebuilt type objects, and only start from one of the installed mm entry points | 00:43 |
| arigo | then we'd probably be able to annotate very small bits one at a time | 00:43 |
| pedronis | but isn't that what the current entry_point is doing | 00:45 |
| pedronis | ah, no | 00:47 |
| arigo | no because now it uses the type objects' Function entries | 00:47 |
| arigo | via descroperation.py | 00:47 |
| pedronis | yes | 00:47 |
| arigo | let's try with space.MM.mul instead of space.mul... | 00:47 |
| arigo | ah, but it's never installed | 00:48 |
| pedronis | well we could install it manually | 00:50 |
| pedronis | but it is true that the first space.op | 00:50 |
| pedronis | would start again from descroperation | 00:51 |
| pedronis | and what it entails | 00:51 |
| arigo | that's a point | 00:52 |
| pedronis | so I agree | 00:52 |
| pedronis | it's probably easier to write a dummy space | 00:52 |
| pedronis | and try only the interpreter | 00:52 |
| arigo | we might try the manually installed entry points with a dummy space... | 00:53 |
| arigo | but let's start with the interpreter :-) | 00:54 |
| pedronis | well | 00:54 |
| pedronis | we could probably manage to fake the interpreter | 00:54 |
| pedronis | too | 00:54 |
| pedronis | although it would involved some hacking import manipulations | 00:54 |
| arigo | guess so | 00:55 |
| _hannes (sckjkn@i3ED6B211.versanet.de) left irc: "utz utz utz" | 01:25 | |
| arigo | reading the three commits about generating a temp file or not in test_geninterp.py :-) | 01:26 |
| arigo | too bad you cannot insert empty commits with the log message "oups!" | 01:26 |
| pedronis | arigo: btw, about the commits | 01:31 |
| pedronis | the change about how we use __new__ in the python init code | 01:31 |
| pedronis | also save us from a segfault | 01:32 |
| pedronis | we spent quite a bit chasing that one | 01:33 |
| arigo | what change is that? | 01:34 |
| pedronis | you wrote code that did for new-style classes | 01:34 |
| pedronis | ourcls.__new__(orucls) | 01:35 |
| pedronis | and extended it to do | 01:35 |
| pedronis | ourcls.__new__(ourcls,state) | 01:35 |
| pedronis | to deal with immutable types | 01:35 |
| pedronis | but the right thing to do is | 01:35 |
| pedronis | builtinbase.__new__(ourcls[,state]) | 01:36 |
| pedronis | the old code ended up calling some of our __new__ functions | 01:36 |
| pedronis | before the global constants were set | 01:36 |
| arigo | I see | 01:36 |
| pedronis | => seg fault ! | 01:36 |
| arigo | (I didn't do the ",state" part, though) | 01:36 |
| pedronis | I did it | 01:37 |
| pedronis | s/extended/I extended | 01:37 |
| arigo | :-) | 01:37 |
| arigo | argh | 01:37 |
| pedronis | well both old versions | 01:37 |
| pedronis | could call some of our functions | 01:37 |
| pedronis | wich can potentially access the globals | 01:37 |
| pedronis | and fun follows | 01:38 |
| arigo | indeed | 01:38 |
| pedronis | anyway __new__ | 01:39 |
| pedronis | seem the only candidate | 01:39 |
| pedronis | for this problem | 01:39 |
| pedronis | but I presume | 01:39 |
| pedronis | that a class defining __setattr__ | 01:39 |
| pedronis | could end up in the same situation | 01:39 |
| arigo | ouack | 01:39 |
| pedronis | although we don't have such things | 01:39 |
| arigo | we could do '%s.__dict__[%r] = %s' instead | 01:40 |
| arigo | and hope that there is no __getattribute__ | 01:40 |
| pedronis | well, I don't think right now we should cater to the general case | 01:41 |
| pedronis | but it is something to keep in minde | 01:41 |
| arigo | I don't think code handling the general case would look sane | 01:41 |
| pedronis | no | 01:41 |
| arigo | I'm not even sure it's possible at all | 01:41 |
| pedronis | my keep in mind | 01:42 |
| pedronis | of in the sense of paying attention | 01:42 |
| pedronis | not to end up with this problems | 01:42 |
| arigo | yes | 01:42 |
| pedronis | because the first time around | 01:42 |
| pedronis | as I said chasing the seg fault | 01:42 |
| pedronis | was hard | 01:42 |
| arigo | I'm just having fun imagining class X(object): pass; del X.__dict__ | 01:42 |
| arigo | I can imagine it was hard to figure out | 01:42 |
| pedronis | well Christian managed | 01:43 |
| pedronis | to understand that the problem was happening in one of our __new__ | 01:43 |
| pedronis | then I understood how we ended up there | 01:43 |
| pedronis | but he had to use VC debugger | 01:43 |
| arigo | I guess so | 01:43 |
| pedronis | and wait a lot of time to get an executable to debug | 01:43 |
| pedronis | on Linux | 01:44 |
| pedronis | an extension built with tcc and -g | 01:44 |
| pedronis | and a debug Python | 01:44 |
| pedronis | crashed in the dynamic linking code :( | 01:44 |
| arigo | :-( | 01:44 |
| pedronis | Christian also tried | 01:44 |
| pedronis | that got the same crash from gdb | 01:45 |
| pedronis | so we also discussed again the issue | 01:47 |
| pedronis | that we should try to produce code | 01:47 |
| pedronis | that does not kill our toolchain | 01:47 |
| arigo | you mean by being too huge? | 01:48 |
| pedronis | yes | 01:48 |
| arigo | hum | 01:49 |
| pedronis | gcc dies on it | 01:49 |
| pedronis | tcc can compile it | 01:49 |
| pedronis | it seems you cannot debug the result | 01:49 |
| arigo | clearly, separate compilation would be the next step to try | 01:49 |
| pedronis | yes | 01:52 |
| arigo | g'nite | 02:20 |
| pedronis | nite | 02:24 |
| pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]" | 02:24 | |
| arigo (~arigo@d83-176-48-217.cust.tele2.ch) left irc: Read error: 110 (Connection timed out) | 02:42 | |
| Continuity (~kittish@host81-155-190-53.range81-155.btcentralplus.com) left irc: "What is this, this face, So murderous in its strangle of branches?" | 02:55 | |
| dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host) | 03:00 | |
| sanxiyn (~tinuviel@218.145.51.39) joined #pypy. | 05:41 | |
| {aqKj (kuzey_ist@HSE-Toronto-ppp169119.sympatico.ca) joined #pypy. | 06:28 | |
| {aqKj (kuzey_ist@HSE-Toronto-ppp169119.sympatico.ca) left #pypy. | 06:28 | |
| idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out) | 07:10 | |
| sanxiyn (~tinuviel@218.145.51.39) left irc: "Bye" | 07:57 | |
| arigo (~arigo@d212-152-20-194.cust.tele2.ch) joined #pypy. | 09:50 | |
| sanxiyn (~tinuviel@218.145.51.39) joined #pypy. | 11:09 | |
| arigo | hi seo | 11:17 |
| sanxiyn | hi | 11:17 |
| sanxiyn | I am trying to comprehend LLVM generator -- it seems to be very well written. | 11:18 |
| sanxiyn | Should do complete rewrite of current GenCL. | 11:19 |
| arigo | well, all our Gen* are extremely messy. | 11:20 |
| sanxiyn | Except perhaps GenLLVM. :-) | 11:20 |
| arigo | yes :-) | 11:20 |
| arigo | we need a way to factorize the common code with better abstractions | 11:20 |
| arigo | and looking at GenLLVM might be a good start | 11:20 |
| sanxiyn | http://rafb.net/paste/results/gMqA5r20.html | 11:21 |
| sanxiyn | (GenLLVM compiles it just fine!) | 11:21 |
| sanxiyn | Generated code includes: | 11:24 |
| sanxiyn | %glb.class.B = type {int*, int, bool} | 11:24 |
| sanxiyn | %glb.class.C = type {int*, %glb.class.B*, int} | 11:24 |
| sanxiyn | I am also thinking about compiling CL to Python module, like other Gen* do. | 11:30 |
| sanxiyn | And tomorrow is a holiday. | 11:31 |
| arigo | what is the first int* in the type{} declarations? | 11:35 |
| sanxiyn | I have no idea. | 11:46 |
| sanxiyn | (After trying to comprehend...) | 11:46 |
| arigo | I'm still trying to install llvm... | 11:47 |
| arigo | what a huge set of implicit dependencies | 11:51 |
| sanxiyn | It depends on pax, for one. | 11:51 |
| arigo | so I saw | 11:52 |
| arigo | but only to install its include files?? | 11:52 |
| sanxiyn | I have no idea why LLVM requires that. | 11:53 |
| arigo | I'm still trying to make sense of the big interlinked Makefiles | 11:53 |
| arigo | but maybe I shouldn't try | 11:53 |
| sanxiyn | I am lazy, so I used Debian package from http://www.toolchain.org/~ahs3/ :( | 11:58 |
| arigo | /bin/install: invalid option -- C | 11:59 |
| arigo | argh | 12:00 |
| sanxiyn | Indeed. | 12:00 |
| arigo | did you get this problem too? | 12:00 |
| sanxiyn | No, I used .deb, but Debian packaing guy experienced it. | 12:01 |
| arigo | ah, you got the llvm deb package | 12:02 |
| arigo | I see | 12:02 |
| sanxiyn | s/ -C// on llvm/docs/Makefile and llvm/docs/CommandGuide/Makefile. | 12:02 |
| arigo | thanks | 12:02 |
| sanxiyn | (That's what Debian package is doing. Yuk.) | 12:02 |
| arigo | genc.py needs two refactorings: | 12:11 |
| arigo | a major cleanup along the lines of genllvm | 12:11 |
| arigo | and the ability to generate smaller .c files, | 12:11 |
| arigo | for separate compilation | 12:11 |
| arigo | currently we're killing gcc trying to translate PyPy! | 12:11 |
| sanxiyn | Killing GCC. Heh. | 12:12 |
| arigo | we're running into the 2GB address space limit, essentially | 12:12 |
| sanxiyn | Are there some other LLVM installation headache? | 12:23 |
| arigo | no, it's done now | 12:23 |
| arigo | and the translator/llvm tests pass. | 12:23 |
| sanxiyn | Good. | 12:23 |
| arigo | the last installation bug was a script calling /bin/gcc directly | 12:24 |
| arigo | easy to fix. | 12:24 |
| arigo | I tried again to run PyPy under Psyco | 12:25 |
| arigo | with a "filter" that tells Psyco not to compile PyPy's functions marked as NOT_RPYTHON | 12:25 |
| arigo | the results aren't extremely good, I get 2.3 pystones/sec instead of 2.0 | 12:26 |
| arigo | but at least, memory usage is kept reasonable, which is more than I could have said with older versions of Psyco | 12:27 |
| sanxiyn | PyPy has >70000 lines of Python now. (With ~10000 lines of generated *interp.py) | 12:35 |
| arigo | impressive | 12:36 |
| ludal (~ludal@logilab.net2.nerim.net) joined #pypy. | 12:47 | |
| idnar (mithy@idnar.user) joined #pypy. | 12:52 | |
| sanxiyn | Is it okay to babble offtopicities? | 12:58 |
| sanxiyn | It seems not. :-) | 12:59 |
| sanxiyn | Bye. | 12:59 |
| sanxiyn (tinuviel@218.145.51.39) left #pypy ("Bye"). | 12:59 | |
| arigo | oups too late | 12:59 |
| stakkars (~tismer@82.144.60.19) joined #pypy. | 13:40 | |
| arigo | hi | 13:41 |
| stakkars | hi | 13:41 |
| Action: arigo -> lunch | 13:42 | |
| idnar (mithy@idnar.user) left irc: "brb, reconnecting" | 14:19 | |
| pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy. | 14:31 | |
| arigo_ (~arigo@d212-152-27-122.cust.tele2.ch) joined #pypy. | 14:32 | |
| idnar (mithy@idnar.user) joined #pypy. | 14:36 | |
| arigo_ (~arigo@d212-152-27-122.cust.tele2.ch) left irc: Client Quit | 14:36 | |
| arigo (~arigo@d212-152-20-194.cust.tele2.ch) left irc: Read error: 110 (Connection timed out) | 14:36 | |
| lac (lac@smartwheels-wlan.strakt.com) joined #pypy. | 16:03 | |
| lac2 (lac@smartwheels.strakt.com) joined #pypy. | 16:26 | |
| Nick change: lac2 -> _lac | 16:27 | |
| Nick change: _lac -> lac-lunch | 16:27 | |
| Nick change: lac-lunch -> lac2 | 16:27 | |
| idnar (mithy@idnar.user) left irc: "kbye" | 16:32 | |
| lac (lac@smartwheels-wlan.strakt.com) left irc: Read error: 60 (Operation timed out) | 16:34 | |
| Nick change: lac2 -> lac | 16:38 | |
| arigo (~arigo@d212-152-17-32.cust.tele2.ch) joined #pypy. | 16:47 | |
| arigo | gcc uses a lot of memory to compile an array-of-chars constant { } | 17:26 |
| arigo | I suspect translate_pypy.py's frozen initialization bytecode is what kills gcc at the end | 17:27 |
| arigo | I'm trying to generate a big string literal now instead | 17:27 |
| pedronis | but it was dying even before the change | 17:27 |
| stakkars | may make sense | 17:27 |
| arigo | pedronis: yes, but before the change the init func was probably what killed it | 17:28 |
| arigo | one week ago, mem consumption of gcc was around 700MB for a long while and jumped up (and crashed) suddenly at the end | 17:28 |
| hpk (~hpk@mail.trillke.de) joined #pypy. | 17:29 | |
| arigo | I measured that a { } constant of 2 million items uses 359MB of gcc | 17:29 |
| arigo | hi! | 17:29 |
| hpk | hi armin, hi all | 17:29 |
| hpk | i am jsut dropping in before i have to pack my computer :-) | 17:29 |
| hpk | i am wondering if we can/want to avoid translating classobjinterp at the moment | 17:31 |
| hpk | i think that translation sees all 7600 lines of it | 17:32 |
| arigo | apart from the init func, yes | 17:33 |
| arigo | I don't know how integrated old-style classes have become now | 17:34 |
| pedronis | it's a matter of whether setup_old_style_classes() is called or not at the end of initialize | 17:38 |
| stakkars | you mean it is incredibly expensive since it generates so much interp code? Not translating it wouldprobably be much smaller,and just 100% slower I guess. | 17:39 |
| stakkars | IOW translation really only pays off if we drastically simplify the code. | 17:40 |
| arigo | pedronis: let me try translate_pypy with a space where setup_old_style_classes() hasn't been called... | 17:45 |
| arigo | stakkars: I guess the kind of 'goto'-ish code produced by geninterplevel.py still produce very bad flow graphs when re-read, right? | 17:46 |
| stakkars | yes, they do. I'm working on getting rid of this. | 17:47 |
| arigo | at which level? | 17:47 |
| stakkars | At Python level. | 17:47 |
| arigo | I was thinking about a flowgraph simplification. | 17:48 |
| arigo | ah ha, without geninterplevel.py and without the big { } array it compiles in a reasonable time (2-3 mins) | 17:50 |
| stakkars | the flowgraphs are simplified. | 17:55 |
| arigo | ah? | 17:55 |
| Action: hpk dared to commit something to multimethod.py | 17:56 | |
| arigo | hpk: yes, you added an XXX in a file that now didn't have any :-) | 17:58 |
| hpk | yes, but it may be a shallow XXX :-) | 17:58 |
| pedronis | conflating functions is always also a delicate thing for the annotator | 17:59 |
| hpk | i know | 17:59 |
| hpk | but in this case i would be surprised if it causes a problem | 18:01 |
| arigo | actually I'm surprized about the number of duplicate functions it avoids | 18:01 |
| arigo | this might point to a bug somewhere | 18:01 |
| hpk | yes, therefore the XXX | 18:01 |
| arigo | def __mm_id(arg0, space): | 18:02 |
| arigo | return id__ANY(space, arg0) | 18:02 |
| hpk | i couldn't hunt this down | 18:02 |
| stakkars | arigo: well, all simplifications available with flowgraphs are applied. But this does not avoid the goto code. | 18:02 |
| arigo | this source is compiled lots of time | 18:02 |
| arigo | stakkars: yes that's what I meant: a new flowgraph simplification should remove the goto variable setting/checking. | 18:02 |
| stakkars | arigo: don't understand. On what level? I cannot express things without goto in flow-graph language. | 18:03 |
| arigo | strange, it's installing the above two-liner on each of the concrete W_XxxObject classes | 18:04 |
| stakkars | I just can arrange blocks in a way that they don't need goto. | 18:04 |
| pedronis | arigo: that's normal probably | 18:04 |
| arigo | stakkars: I mean that if you take a function from classobjinterp.py | 18:04 |
| arigo | stakkars: and run the flow objspace over it again (as translate_pypy will do) | 18:04 |
| arigo | stakkars: then the result is ugly | 18:04 |
| pedronis | arigo: is because of the ANY I think | 18:05 |
| arigo | stakkars: but it could be simplified | 18:05 |
| arigo | stakkars: without changing anything in geninterplevel.py nor classobjinterp.py, just in simplify.py. | 18:05 |
| arigo | pedronis: doesn't make much sense, this method should go to the base class only once. | 18:06 |
| stakkars | arigo: oops? I thought I changed things so that simplify is applied all the time. Maybe I missed something. | 18:06 |
| pedronis | arigo: I don't think so with the current algorithm | 18:06 |
| arigo | stakkars: out of us doesn't understand the other | 18:06 |
| hpk | stakkars: i think armin means introducing a new simplification | 18:06 |
| pedronis | arigo: we don't use subclassing rel much and W_Root/ANY is considered a delegation case | 18:07 |
| stakkars | hpk: ah! That would mean to interpret constant values and to deduce that the gotos are unconditional. | 18:07 |
| arigo | pedronis: ah, I see... too bad | 18:08 |
| arigo | stakkars: exactly | 18:11 |
| Continuity (~kittish@host81-153-48-22.range81-153.btcentralplus.com) joined #pypy. | 18:11 | |
| arigo | pedronis: so we install a failing method on the W_Root, and always the same non-failing method on each of the concrete subclasses... | 18:11 |
| pedronis | yes, that's what happen I think | 18:12 |
| arigo | I guess it's safe to merge these methods as hpk did then | 18:12 |
| pedronis | yes | 18:13 |
| hpk | and if we have cases where such merging is not safe then we should explicitely set specialization by argtypes or so | 18:13 |
| arigo | the result looks like vtables, each (or most) of the concrete subclasses having the same function in the slot... | 18:13 |
| arigo | which is exactly how C++ would compile the classes if we had just one method on the base class instead. | 18:14 |
| stakkars | arigo: what about the duplication of f_xxx and fastf_xxx interfaces? This happens on both levels,one is probablynot necessary? | 18:17 |
| arigo | ah, well I don't really know | 18:17 |
| arigo | genc.py doesn't really use its fastf_xxx interface (I've a patch to do that but it's not compatible with USE_TRACE_CALL) | 18:18 |
| Action: hpk notices that PyPy is only 4659 times slower than CPython on pystone | 18:18 | |
| arigo | hpk: I even got 15% speed-ups with Psyco this morning :-) | 18:19 |
| arigo | with an extension to only Psyco-compile the functions not marked NOT_RPYTHON... | 18:19 |
| hpk | hehe | 18:20 |
| Action: hpk continues packing and moving things ... | 18:20 | |
| _hannes (rrpnpf@i3ED6B20D.versanet.de) joined #pypy. | 18:23 | |
| _hannes | hi people | 18:24 |
| arigo | hi | 18:25 |
| stakkars | arigo: well, f_xxx does parameter checking in CPython style. My f_xxx does parameter checking again, using __args__ methods. Something is wrong, here. | 18:26 |
| stakkars | why only 15%? Probably too many objects with methods, which cannot be inlined | 18:28 |
| arigo | yes and no... | 18:28 |
| arigo | not sure exactly why 15% only | 18:28 |
| arigo | the C-level f_xxx should probably go away automatically | 18:28 |
| arigo | when we figure out that direct calls to the C-level fastf_xxx() are possible | 18:28 |
| arigo | then we don't need to generate f_xxx() any more, if it's not referenced any more | 18:29 |
| arigo | but it's a bit more messy in practice because a lot of functions are stored in classes as methods, so the f_xxx() might be hard to get rid of | 18:29 |
| pedronis | yes, not without types | 18:30 |
| arigo | indeed | 18:31 |
| arigo | but then I wouldn't worry too much about it now | 18:31 |
| Action: arigo plays with simplify.py | 18:31 | |
| stakkars | arigo: goto was really a problem, when I ran flow graphs twice, because it always complained about uninitialized variables. This is why I begun to initialize all the temp variables. If you can teach it to deduce unconditional jumps, this would probably be very fine. | 18:34 |
| arigo | oh right | 18:35 |
| arigo | maybe simplify.py is too late, then? | 18:35 |
| arigo | the FlowObjSpace would complain about UnboundLocalError before simplify.py can do something about it... | 18:36 |
| stakkars | since I didn't want to modify flowgraphs, my approach was to merge blocks into each other. But that cannot be expressedby graphs, right now. | 18:36 |
| stakkars | arigo: yes. This happens when you run flowing over something that produced such gotos. | 18:36 |
| stakkars | It also happens on regular code, btw. | 18:36 |
| stakkars | We just happen to not write such code. | 18:36 |
| arigo | I see | 18:37 |
| stakkars | but I don't see how to solve this without something like annotation. | 18:37 |
| stakkars | _hannes: hi son | 18:38 |
| _hannes | hi pops | 18:38 |
| stakkars | arigo: in this simple case, we have constant assignments, which are then switched upon in the big loop. But in general, this could be any expression, and it is not easy to predict whether a variable is uninitialized or not. | 18:39 |
| arigo | stakkars: definitely | 18:40 |
| stakkars | do you see a way to avoid this, or should I continue with my python level block embedding? | 18:40 |
| arigo | there are ways to avoid this | 18:41 |
| arigo | the question is how difficult they'd be | 18:41 |
| stakkars | I mean without enforcing annotation. | 18:41 |
| arigo | yes | 18:42 |
| arigo | the FlowObjSpace performs a very limited form of annotation ifself, with its Variable/Constant. | 18:42 |
| arigo | that would be enough in our case | 18:42 |
| arigo | I can think about a quick hack | 18:43 |
| stakkars | ok, it's constant tracking. | 18:43 |
| arigo | where we somehow force the flowobjspace to fully specialize for the value of 'goto' | 18:43 |
| arigo | he he | 18:43 |
| stakkars | ANother way would be to change the produced code. I could use a different variable for every block. Would that help? | 18:44 |
| arigo | no no | 18:44 |
| stakkars | goto specialization looksgood, yes. | 18:44 |
| arigo | there are already possible hacks | 18:44 |
| arigo | e.g. in addition to goto in range(N), if you also generate N variables dummy0, ..., dummyN-1 | 18:45 |
| arigo | and if you arrange for dummyJ to be bound if and only if goto==J | 18:45 |
| arigo | then the FlowObjSpace shouldn't be allowed to merge | 18:46 |
| stakkars | wasn't that what you labelled "no no"? | 18:47 |
| arigo | well, indeed | 18:47 |
| arigo | sorry | 18:48 |
| arigo | however, you probably need the common 'goto' variable too | 18:48 |
| arigo | and what I had in mind was to play tricks with this single variable | 18:49 |
| arigo | like using for block numbers, instead of integers, special objects which the FlowObjSpace knows it must not fold | 18:49 |
| stakkars | sounds promising! | 18:50 |
| arigo | right now, if the objects stored in 'goto' are put as keys in objspace.flow.framestate.UNPICKLE_TAGS, they won't be merged | 18:51 |
| arigo | but it should be done more "officially" I guess. | 18:52 |
| arigo | use complex literals, and say that complex numbers are not to be merged :-) | 18:53 |
| stakkars | whow! complex goto's is really great :-) | 18:53 |
| idnar (mithrandi@idnar.user) joined #pypy. | 19:07 | |
| arigo | stakkars: I checked in a reasonable interface | 19:11 |
| arigo | see SpecTag in framestate.py | 19:11 |
| arigo | using global SpecTag instances and putting them in 'goto' instead of numbers should do the trick. | 19:19 |
| arigo | I was considering an int subclass instead but well. | 19:20 |
| stakkars | that means = use some globals label_1 = SpceTag(); label_2 = SpecTag() etc. | 19:31 |
| arigo | yes | 19:32 |
| stakkars | and then use them with if goto is lable_1: | 19:32 |
| stakkars | or eq? | 19:32 |
| arigo | not wonderfully nice, but it should do as a proof of concept | 19:32 |
| arigo | 'is' is fine | 19:32 |
| arigo | you can reuse the labels between functions if you like but you don't have to | 19:33 |
| stakkars | this also would let me drop initialization of the locals | 19:33 |
| arigo | I think so | 19:33 |
| ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/" | 19:59 | |
| dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy. | 20:12 | |
| Action: pedronis leaving the office | 20:31 | |
| pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]" | 20:31 | |
| Action: arigo reads the C standard | 20:49 | |
| arigo | strange things indeed are found in this weird language | 20:50 |
| lac | what are you reading now? | 21:03 |
| arigo | the C99 draft | 21:03 |
| arigo | hello /\ | 21:04 |
| arigo | / world | 21:04 |
| lac | eeee | 21:04 |
| arigo | this is a // comment because of the \ | 21:04 |
| arigo | or | 21:04 |
| arigo | printf("Eh??!\n") | 21:04 |
| arigo | prints Eh| | 21:04 |
| arigo | because it's a trigraph | 21:04 |
| arigo | (but sane C compilers like gcc don't enable trigraphs by default) | 21:05 |
| arigo | also, I had no idea that <% and %> where equivalent to { and } | 21:05 |
| arigo | s/where/were | 21:05 |
| lac | wonder how much code would break if they did on one April 1st or so .... | 21:05 |
| arigo | indeed | 21:06 |
| lac | I knew that, because I lived for a long time with a keyboard that didn't have braces. | 21:06 |
| arigo | and %: for # and <: for [ | 21:07 |
| lac | That I had forgotten if I ever knew. | 21:08 |
| _hannes | oO | 21:13 |
| arigo | ever less known: literal struct expressions: | 21:22 |
| arigo | (struct point){.x=a, .y=a+2} | 21:22 |
| arigo | as in | 21:23 |
| arigo | printf("%d\n", sum((struct point){.x=a+1, .y=a+2})); | 21:23 |
| arigo | hey, keyword argument passing in C :-) | 21:23 |
| stakkars | ugh | 21:23 |
| arigo | that's new in the C99 standard, I believe | 21:23 |
| arigo | but gcc accepts it | 21:24 |
| dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: "Leaving" | 21:24 | |
| pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy. | 21:24 | |
| dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy. | 21:25 | |
| arigo (~arigo@d212-152-17-32.cust.tele2.ch) left irc: "Leaving" | 22:31 | |
| tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 54 (Connection reset by peer) | 22:36 | |
| arigo (~arigo@d212-152-17-32.cust.tele2.ch) joined #pypy. | 22:37 | |
| tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy. | 22:38 | |
| stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out) | 22:55 | |
| arigo (~arigo@d212-152-17-32.cust.tele2.ch) left irc: "Leaving" | 23:04 | |
| lac | samuele: we just ate dinner at the Greek place that just opened at the Tram stop. | 23:07 |
| lac | Open until 2200. | 23:08 |
| lac | Food was decent greek souvlaki. | 23:08 |
| lac | Let us hope this place can stay open ... | 23:08 |
| --- Tue Mar 1 2005 | 00:00 | |
Generated by irclog2html.py 2.2 by Marius Gedminas - find it at mg.pov.lt!