==== Channel ##pypy: 05/23/05 ====

[00:43] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";

[00:52] <Rhamphoryncus> heya stakkars

[00:53] <stakkars> howdy

[00:53] <Rhamphoryncus> wazzup?

[00:53] <stakkars> trying to make parts of PyPy's structures picklable, notjing special.#

[00:53] Action: Rhamphoryncus nods

[00:54] <stakkars> we need to save some time during flow graph analysis and code generation,so I want to freeze the first one.

[00:54] Action: Rhamphoryncus nods

----- silence for 1 hr and 40 minutes -----

[02:34] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"

[02:42] yuuh (~yuuhu@82.140.29.233) left irc: "utz utz utz"

----- silence for 1 hr and 9 minutes -----

[03:51] Rhamphoryncus (~rhamph@rhamphoryncus.user) left irc: ""What do you mean, how many hit points do I have?" || Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html";

----- silence for 1 hr and 6 minutes -----

[04:57] senra (~rodrigo@200-158-46-180.dsl.telesp.net.br) joined #pypy.

----- silence for 1 hr and 21 minutes -----

[06:18] rodsenra (~rodrigo@200-158-46-180.dsl.telesp.net.br) joined #pypy.

[06:19] senra (~rodrigo@200-158-46-180.dsl.telesp.net.br) left irc: Read error: 110 (Connection timed out)

[06:29] rodsenra (~rodrigo@200-158-46-180.dsl.telesp.net.br) left irc: "Leaving"

----- silence for 1 hr and 45 minutes -----

[08:14] adim (~adim@logilab.net2.nerim.net) joined #pypy.

----- silence for 29 minutes -----

[08:43] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.

----- silence for 31 minutes -----

[09:14] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.

----- silence for 1 hr and 24 minutes -----

[10:38] <arre> hpk: You there?

[10:38] <hpk> arre: kind of, yes

[10:38] <arre> Ok.

[10:38] <arre> I have found a problem with running the conformance test test_unicodedata.

[10:39] <arre> It amounts to tearDown (and setUp) being called two times.

[10:39] <arre> And test_unicodedata can't handle that.

[10:40] <hpk> you mean with 'py.test -E'?

[10:40] <arre> I found that the first call is from the function run_testcase_method() in conftest.

[10:41] <arre> Then run_testcase_method calls the method, which itself has machinery for running setUp and tearDown.

[10:41] <arre> Yes, with py.test -S

[10:41] <arre> s/S/E/

[10:43] <arre> So, what breaks if we remove the calls to setUp/tearDown in run_testcase_method?

[10:44] <hpk> if you are right, nothing :-)

[10:45] <arre> Ok, I'll commit that change and listen if i here any screams :)

[10:46] <hpk> it should be fine

[10:46] <hpk> the code can be further simplified then

[10:46] <hpk> but nevermind, i care about that later

[10:47] <hpk> there is still some work left for the '-E' option to become the default (e.g. it needs to generate testresult-files)

[10:47] <arre> Yep, if no problems are found we refactor later. If any problems crops up it's a small change to revert.

[10:47] <hpk> yip

[10:49] <ericvrp> goodmorning all, who should I talk to about sideeffects of the Translator.c method?

[10:50] <hpk> currently, armin or samuele i guess or maybe stakkars?

[10:50] <stakkars> hi!

[10:50] <hpk> hi christian

[10:50] <stakkars> hi Holgi

[10:51] Gerald (~bear@B74d0.b.pppool.de) joined #pypy.

[10:51] <stakkars> ericvrp: you mean the new c folder in translator? That's rahter new forme, too.

[10:52] <ericvrp> stakkers: no. I mean the c method in translator/Translator.py

[10:53] <ericvrp> I was playing with something I call compyle.py , which is a wrapper around the various backends. With pyrec and llvm backend I can show the code to be compiled and then still compile the thing. With the genc backend this does not work.

[10:53] <stakkars> I see. that's just calling genc

[10:54] <ericvrp> It had the sideeffect that the 2nd time I try to show the c-code it showns less c-code.

[10:54] <ericvrp> s/had/has/

[10:54] <stakkars> you are running translator.c twice?

[10:54] Gerald (bear@B74d0.b.pppool.de) left #pypy ("Client Exiting").

[10:54] <ericvrp> yes

[10:55] <stakkars> that doesn't work I guess. as a shorthand, you'd needa new instance.

[10:55] <ericvrp> to test yes. I run translator.c and then translator.ccompile

[10:57] <ericvrp> stakkars: a new Translator instance. Does the c backend modify the translator as opposed to the other backends that do not change it (or is this a stupd question?)

[10:58] <stakkars> yes, no

[10:58] <stakkars> not absolutely sure, but if you look into goal/translate_pypy.py,

[10:59] <stakkars> you see that ccompile is used, only, with the option to compile or not.

[10:59] <stakkars> GenC is called once with self(the translator) as parameter, and I believe

[10:59] <stakkars> that GenC does some irreversible things. Would have to look.

[11:01] <ericvrp> ok, thank you for clearing that up. I will use recreate a Translator after translator.c . BTW stakkars is that Christian?

[11:01] <stakkars> I'm looking through GenC where it might write to the translator, no success, yet.

[11:01] <stakkars> yes it's me :-)

[11:02] <stakkars> got it!

[11:03] <stakkars> not sure, but I *think* you can trash the following, after I shrunk memory requirements so drastically:

[11:03] <stakkars> And I also did it to geninterp, because I had the effect that this actually rendered functions twice:

[11:04] <stakkars> line 171 might be better to avoid.

[11:04] <aleale> is subversion working ?

[11:04] <arre> I'm allso having problems with svn.

[11:07] <arre> hpk: svn tells me to run a recovery on the database. Is it something i can do or does it need someone with special privliges?

[11:10] hpk (~hpk@merlinux.de) left irc: Read error: 110 (Connection timed out)

[11:11] hpk (~hpk@merlinux.de) joined #pypy.

[11:14] <arre> It might be my actions that have given the svn hickups as i'm the owner of one of the files in /svn/db.

[11:14] cfbolz (~cfbolz@hdlb-d9b95ee3.pool.mediaWays.net) joined #pypy.

[11:15] <cfbolz> hi!

[11:15] <stakkars> hi

[11:15] <cfbolz> is svn down?

[11:16] <stakkars> ericvrp: got that working, the genc line 171 thing?

[11:17] <ericvrp> stakkars: not yet. I removed my version of genc.py (with my debug info) so I could checkout a clean version. But svn is currently down on codespeak

[11:19] <ericvrp> I did try to use another Translator and that seems to work better. I am a little surprised that FROZEN_INITCODE_SIZE is 423 the first time and the second time 'round it is only 422

[11:19] <stakkars> *gulp*

[11:20] <stakkars> first I'm mailing you the genc source.

[11:20] <cfbolz> you can also download the release, genc probably didn't change

[11:20] <stakkars> yes (and I don't have your email at hand)

[11:22] <ericvrp> eric atmysite vanrietpaap.nl

[11:25] <stakkars> you got it

[11:25] <stakkars> that frozen issue interests me as well. I always doubted if we get that right, all the time.

[11:28] <ericvrp> stakkars: removing genc.py:171 "del self.translator.flowgraphs[funcdef.func]" did not have an effect

[11:33] <ericvrp> stakkars: you have mail

[11:34] <stakkars> hum. then we need to trace translator attribute access in a way.

[11:35] cfbolz (~cfbolz@hdlb-d9b95ee3.pool.mediaWays.net) left irc: "Verlassend"

[11:36] <ericvrp> Let me know if I can help. In the meantime I will write a test to see if all backends can regenerate identical code

[11:37] <stakkars> ericvrp: side note -- we never use tabs

[11:38] <ericvrp> yes sorry. But then again, I have never committed anything to PyPy :) I will switch editor, or do you know how to set vi to use spaces instead?

[11:39] <stakkars> I'm no vi specialist, all others hereare:-)

----- silence for 21 minutes -----

[12:00] <hpk> ericvrp: insert the line "set expandtab" into your .vimrc

[12:01] <hpk> ericvrp: actually armin and samuele are using emacs among others

[12:02] <ericvrp> hpk: thankyou, will do that. I think I will return to using eric3 IDE

[12:12] <stakkars> ericvrp: something is weird. The entrypoint is not triggered again in genc.__init__. somecache not cleared.

[12:24] <adim> Hi everyone

[12:25] <adim> hpk: is it possible for us to make a (SVN) branch to work on the compiler / parser integration ?

[12:26] <hpk> adim: yes, i guess so

[12:26] <hpk> i'd try to make sure that you don't have a branch with a long time window though

[12:26] <adim> just to prevent too much impact on baseobjspace / interpreter /etc. until it doesn't interoperate nicely

[12:26] <hpk> hum, is it neccessary to do a branch?

[12:27] <hpk> in basobjspace you can switch the module impl's pretty easily

[12:27] <hpk> so you could leave that one modified and commit the other parts in pypy/module/recparser i guess

[12:28] <hpk> if you need small fixes/changes somewhere else than you can easily keep in sync

[12:28] <hpk> and commit them

[12:29] <hpk> am i making sense?

[12:29] Action: adim is thinking about how he understands this

[12:29] <adim> :)

[12:29] <hpk> in short: modify baseobjspace.py locally but never commit it

[12:30] <hpk> this way PyPy will use your parser module in your WC and the C-one in all others

[12:30] <adim> well, you also need to impact interpreter.py if I'm not wrong

[12:30] <adim> compiler.py, sorry

[12:31] <adim> and executioncontext ?

[12:31] <hpk> we should figure out a way to make this seamless

[12:32] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.

[12:32] <hpk> but ok, if you like, just work in a branch

[12:33] <hpk> just try to make sure it's not a very long lasting one

[12:33] <hpk> ludal: hi ludovic

[12:33] <adim> we probably also want to make it as short as possible

[12:34] <ludal> hi, just got back from vacation, catching up...

[12:36] <hpk> i'd suggest to talk to jonathan after you examined the double-parser situation a bit

[12:36] <ludal> regarding branches, the trouble is we keep exchanging manual patches with adrien to keep in sync

[12:36] <stakkars> ericvrp: coming closer. CPyObjectType seems to be instantiated just once which is bad becuase it caches generated things.

[12:37] <ludal> which is just going backwards from when we were using darcs

[12:37] <hpk> i see

[12:37] <ericvrp> stakkars: this is all over my head at the moment, but will try to learn

[12:37] <adim> hpk: Can you confirm Jonathan is jriehl ?

[12:37] <hpk> ludal: well, i think it makes sense to really use svn for that

[12:37] <hpk> adim: yes

[12:37] <adim> ok

[12:38] <hpk> it's just he has been at two sprints, contributed especially his parser module and there should be some technical discussion

[12:38] <hpk> he doesn't have strong feelings as far as i know

[12:38] <hpk> so it's not going to be difficult but good style anyway (he attended two sprints and all)

[12:39] <ludal> me neither, I would just put options to use either parser

[12:39] <hpk> well, i'd really like to settle on one of them

[12:39] <hpk> possibly combining some ideas

[12:39] <hpk> worse than no-parser is two-half-parsers :-)

[12:40] <stakkars> ericvrp: sure. I just found out that we are still using a DEPRECATED thing, which caches something on the translator and this is wrong. thanks, this helped!

[12:40] <hpk> arigo is scheduled to support you decision/coding wise on this, btw

[12:40] <hpk> (refering to ludal, of course)

[12:42] <hpk> therefore, he headed into the compiler.py direction

[12:42] <hpk> the goal is to have a fully RPython-implemented yet flexible parser (so that it's translatable)

[12:42] <adim> targetted for Europython sprint ?

[12:43] <ericvrp> stakkars: getconcretetype right?

[12:43] <ludal> I'd keep them both so we can see how they both translate

[12:43] <ludal> since it's really two different approaches

[12:43] <hpk> getting them translated ready might require quite some work, i am not sure we want to continue to duplicate efforts there

[12:44] <hpk> adim: quite possibly, yes

[12:45] <adim> hpk: ok

[12:45] <ludal> hpk: I'm working at making the compiler rpython right now,

[12:46] <ludal> is having a dict of classes rpython or is it better implemented with if name="Toto" : return Toto() elif ...

[12:46] <ludal> ?

[12:46] <hpk> a dict of classes is fine as long as it is fully constructed at translation time

[12:47] <hpk> i.e. if building the dict happens at initialization time

[12:47] <ludal> that's fine then, thanks

[12:47] <ludal> it's for the AST classes which can be constructed at initialization time

[12:48] yuuh (ore@82.140.29.233) joined #pypy.

[12:51] <stakkars> ericvrp: yes. Then I disabled that and created a fresh object and I get all the code,but still it is wrong.

[12:53] <ericvrp> stakkars: I forced a KeyError in the try part (that disables the caching I think?) and noticed that "typedef PyObject* pyobj;" is twice in the generated output

[12:55] <stakkars> hum. I guess we should not waste time and just stick with double-instancing the translator. This is under flux, anyway.

[13:01] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

[13:03] <stakkars> hi armin!

[13:03] <arigo> hi!

[13:04] <stakkars> I just tried to make translator.c be able to generate twice, but there are several places which are quite sticky

[13:04] <stakkars> and you need to reinstantiate the translator.

[13:04] <arigo> yes, I guess so. but genc is going away

[13:05] <stakkars> yes, that's why I stopped it after a while.

[13:05] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.

[13:05] <arigo> in a few days already I hope to be able to "svn rm genc"

[13:05] <arigo> ok.

[13:05] <hpk> arigo: you may want to read a bit in the IRC log, just so you know

[13:10] <stakkars> arigo: well, as far as I understand c/pyobj.py, it is essential not to make ReprPyObject() a sticky

[13:10] <stakkars> property of the translator, or to clean it up after use.

[13:11] <arigo> genc/pyobj.py ?

[13:11] <stakkars> because self.cnames hinders generating twice.

[13:12] <stakkars> no, c/pyobj.py, because you said genc is dead, I thought to see where the codemoved :-)

[13:12] <arigo> ah, I see

[13:12] <arigo> c/pyobj.py is not used at the moment

[13:12] <arigo> it's a copy of genc/pyobj.py which is not yet in any shape

[13:12] <stakkars> just wanted to point you at the problem

[13:13] <arigo> we're doing this dependency tracking differently

[13:13] <arigo> one problem is the method getconcretetype() of the Translator, which is going away too

[13:13] <stakkars> is it in svn already? where to look

[13:13] <arigo> no, it's in planning only

[13:13] <stakkars> yes, I saw that

[13:14] <arigo> the relevant files in svn are c/database.py, c/node.py and c/primitive.py only

[13:14] <stakkars> thanks

[13:15] <stakkars> I also had some trouble with pickling because there are a lot of dependencies.

[13:15] <stakkars> would like to shrink-cut as much as possible.

[13:16] <arigo> what kind of object are you finding out?

[13:16] <stakkars> the flowgraphs always have the func attribute, which gives trouble,sometimes.

[13:17] <hpk> arre: very minor nit regarding your merge: can you use 'function.py' according to http://codespeak.net/pypy/index.cgi?doc/coding-guide.html#directory-and-file-naming ?

[13:17] <stakkars> if I pickle them natively, then they expose references to type_, which I also can pickle, but gives again probs...

[13:17] <arigo> the func attribute is a real function, right?

[13:17] <stakkars> all not that bad, but finally I get at the generated exceptions.py -- yes

[13:17] <stakkars> I think from the way weuse the functions, I could rewrite them with something simpler.

[13:18] <arigo> you should pickle a dummy placeholder in all cases, not the real thing

[13:18] <arigo> yes.

[13:18] <stakkars> so how relevant are the attributes? I found closures with cell instances, for instance

[13:18] <arigo> this information is already captured in the flow graph constants

[13:19] <stakkars> in that case I expect out flow blocks contain a getattr on this object, and it needs to be bound and generated in C as well.

[13:19] <arigo> as far as I know, the func is only relevant for the func_defaults, at the moment

[13:19] <arigo> possibly func_code.co_flags

[13:19] <stakkars> that's fine, then I create a dummy.

[13:20] <stakkars> as a side question: I still don't understand why we need to instantiate functions space-wise?

[13:20] <arigo> which functions?

[13:21] <stakkars> for instance the generated stuff. The init function produces all func anew, which makes easy pickling impossible

[13:21] <stakkars> geninterp output I meant

[13:22] <arigo> as a side-side-note, that's by far not the single place that makes easy pickling impossible

[13:22] <arigo> but for geninterp output, it's to capture all space-dependent constants

[13:23] <stakkars> I know. I'm already ableto pickle most multimethods, but stopped that after I realized that this is never-ending

[13:24] <stakkars> ah, I begin to unsertand.

[13:25] <stakkars> ok, well that's the problem:

[13:25] <stakkars> we do that for every space instance.

[13:25] <stakkars> But we only need to do it per space class, right?

[13:30] <hpk> arre: thanks, your merge looks good on first glimpse

[13:30] <hpk> arre: we might want to think about a bit more packed format for unicodedata (although svn uses gzip-compression usually, anyway)

[13:31] <arigo> stakkars: no, we need it per instance, because of all the prebuilt constants that are per-instance

[13:33] <stakkars> I see the reason. Is this just a fact, or could we use PBCs per class with more effort (just to know)

[13:33] <arigo> it's just a fact :-)

[13:34] <stakkars> puuh. I feared I missed something substantial. good.

[13:34] yuuh (ore@82.140.29.233) left irc: Read error: 104 (Connection reset by peer)

[13:34] stakkars (itwukm@82.140.29.233) left irc: Read error: 104 (Connection reset by peer)

[13:35] cfbolz (~cfbolz@hdlb-d9b946fd.pool.mediaWays.net) joined #pypy.

[13:36] stakkars (gdyggr@dsl-62-220-10-98.berlikomm.net) joined #pypy.

[13:36] Action: stakkars oppsed

[13:36] <cfbolz> hi!

[13:36] <hpk> hi carl and see you

[13:36] <arigo> hi!

[13:36] Action: hpk -> lunch

[13:37] <stakkars> but there are cases which are hard to track, and I end uppickling spaces, which we decided to avoid,now.

[13:37] <stakkars> with the "reduced func" shortcut, I think it will be ready, soon.

[13:37] <arigo> good.

[13:38] <stakkars> (I want to get it done and do more important things you know)

[13:40] <stakkars> do I trash existing pickling additions, or keepit formaybe later?

[13:41] <arigo> as you like (but trash isn't permanent with svn)

[13:41] <stakkars> well, I don't want to burden us with maintaining this

[13:42] <arigo> makes sense I guess

[13:42] <arigo> cfbolz: we'd like to set up an irc step-by-step state-of-the-translator overview for later this week,

[13:42] <stakkars> I hoped I covered almost all cases,so we would have to make sure a complete space is set up,

[13:43] <arigo> cfbolz: would you be around and when?

[13:43] <stakkars> then certain fake modules are filled with objects the unpickler can find.

[13:43] <stakkars> but when I figured out the problems with geninterp() instances, I gave up.

[13:43] <arigo> stakkars: never-ending indeed :-(

[13:44] <cfbolz> arigo: my analysis exam is tommorrow, but afterwards that's no problem

[13:44] <arre> hpk: About the unicodeformat. Yep, the current one is a 'use for now until we settle for a good one'.

[13:45] <hpk> arre: right, it's not a major thing right now

[13:45] <cfbolz> hpk: you back?

[13:45] <hpk> didn't really go it seems :-)

[13:45] <arigo> ericvrp: what about you?

[13:45] <hpk> cfbolz: problem is i got distracted by examining arre's diff :-)

[13:46] <cfbolz> hpk: :-) you looked at my accession thingy?

[13:46] <arigo> (anyone else listening, feel free to have a date opinion too)

[13:46] <ericvrp> I'm here

[13:46] <cfbolz> arigo: wednesday or thursday?

[13:46] <hpk> cfbolz: yes, we are just finalizing it, you still need to contact Jacob to get a copy of accession forms to sign and send back though (alternatively we can do it at EP which should be fine for getting the refund)

[13:46] <arigo> yes, wednesday or thursay

[13:47] <cfbolz> hpk: is the document more or less ok?

[13:47] <pedronis> thursday I'm flying

[13:47] <arigo> pedronis: right

[13:47] <ericvrp> wednesday

[13:47] <arigo> stakkars: wednesday works for you too?

[13:47] Action: pedronis is taking some days off (thurs to monday)

[13:47] <cfbolz> arigo: fine with me

[13:47] <stakkars> thursday 14:00-xx:00 I'm giving my Python course

[13:48] <stakkars> yes,works. About the translation meeting,or what is it?

[13:48] <arigo> yes

[13:48] <arigo> wednesday 15:00?

[13:48] <stakkars> fine

[13:48] <pedronis> ok

[13:48] <cfbolz> arigo: ok

[13:48] <hpk> fine for me as well, i think

[13:48] <ericvrp> fine

[13:48] <arigo> ok :-)

[13:49] <ericvrp> What timezone do you people live by?

[13:49] <arigo> CET

[13:49] <hpk> cfbolz: hey, you are having an examn tomorrow, what are you doing here? :-)

[13:49] <stakkars> GMT+1 (daylight?)

[13:50] <cfbolz> hpk: relaxing. I can only concentrate on math for so many hours.

[13:50] <ericvrp> My clock now says it is 13:52

[13:50] <arigo> Nederlands' in any case :-)

[13:50] <stakkars> cfbolz: please tell memore about your math, after the exam

[13:50] <hpk> ericvrp: same here :-)

[13:50] <arigo> ericvrp: yes.

[13:50] <stakkars> mines says 13:53, fits well

[13:51] <cfbolz> mine says 13.58 :-)

[13:51] <stakkars> moon-light cheapo-watch

[13:55] <cfbolz> ok, see you wednesday then

[13:55] <cfbolz> (or tommorrow, of course)

[13:55] <arigo> good luck

[13:56] <cfbolz> thanks

[13:56] cfbolz (~cfbolz@hdlb-d9b946fd.pool.mediaWays.net) left irc: "Verlassend"

[14:01] <arigo> hpk: I'm getting strange errors on codespeak (just what you need now)

[14:02] <hpk> arigo: open a screen session and show

[14:02] <arigo> ok

[14:07] vfff (xIg@host61-86.pool8256.interbusiness.it) joined #pypy.

[14:15] vfff (xIg@host61-86.pool8256.interbusiness.it) left #pypy.

[14:24] <arigo> thinking aloud: if we had chosen another name for "object space" for clarity, it might have been "object library"

[14:25] <arigo> but then the "std object space" would have been the "standard library"

[14:25] <arigo> that would certainly have been confusing

[14:25] <arigo> or "standard object library". hum, maybe not so confusing after all.

[14:26] <pedronis> well but flow object library would have been pretty strange ;)

[14:28] <arigo> :-)

[14:28] Action: arigo -> lunch

[14:28] bbailey (bbailey@adsl-146-20-126.mia.bellsouth.net) left #pypy ("Leaving").

[14:38] <stakkars> thinking aloud too: implementation could be a good word

[14:38] <stakkars> standard obj impl

[14:38] <stakkars> flow object impl

[14:39] <stakkars> much simpler to thik of an impl than to be in outer space :-)

[14:45] Gerald (~bear@A3685.a.pppool.de) joined #pypy.

[14:47] <aleale> I get some failures in "test_int_object.py"

[14:54] Rhamphoryncus (~rhamph@rhamphoryncus.user) joined #pypy.

----- silence for 33 minutes -----

[15:27] <arigo> aleale: ah?

[15:35] yuuh (~yuuhu@dsl-62-220-10-98.berlikomm.net) joined #pypy.

[15:38] <aleale> arigo: It looks like a signature has been changed and some overflow errors. Just a heads up for arre.

[15:39] <arigo> I can't reproduce the error, though

[15:39] <aleale> I'll try again later - gotta go

[15:39] <arigo> ok, see you

[15:51] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.

----- silence for 21 minutes -----

[16:12] Action: arigo adds SomeUnicodeChar to annotation/model.py

[16:12] Gerald (~bear@A3685.a.pppool.de) left irc: Read error: 104 (Connection reset by peer)

[16:17] <pedronis> arigo: I'm working on that

[16:17] <arigo> ah ok

[16:17] <pedronis> already done

[16:17] <pedronis> I'm dealing with deeper things

[16:18] <arigo> translate_pypy?

[16:18] <pedronis> sorry, I should have given an heads up

[16:18] Gerald (~bear@B74cc.b.pppool.de) joined #pypy.

[16:18] <pedronis> arigo: yes

[16:18] <arigo> I just started, np

[16:18] <arigo> hum, lots of red warnings...

[16:19] Gerald (~bear@B74cc.b.pppool.de) left irc: Client Quit

[16:19] <pedronis> yes, I'm fixing the problems

[16:19] <arigo> I guess so.

[16:20] Action: arigo moves on to grabbing bits of c/funcdef.py for c/node.py

[16:21] <pedronis> arigo: the problem is mainly that unicode needs to call method or app-helpers and then assert isinstance are needed to pin-point the return type

[16:21] <pedronis> otherwise _value gets attache to W_Root

[16:21] <arigo> I see

----- silence for 34 minutes -----

[16:55] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection

[17:02] tic (~vision@static-213-115-110-186.sme.bredbandsbolaget.se) left irc: Read error: 60 (Operation timed out)

----- silence for 26 minutes -----

[17:28] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.

----- silence for 27 minutes -----

[17:55] lypanov (~lypanov@119x86.ouraynet.com) joined #pypy.

[17:56] Action: lypanov waves around

[17:57] <stakkars> arigo: short q?

[17:57] <arigo> yes?

[17:57] <stakkars> after simplifying the way functions are pickled, I get quite afr. quite.

[17:58] <stakkars> far

[17:58] <stakkars> I am not stuck in some operations with constant values

[17:59] <stakkars> like W_StringObject("getattr")

[18:00] <stakkars> I guess these objects must be supported, fully. ?

[18:00] <arigo> argh

[18:00] <stakkars> I am now stuck was the right sentence

[18:00] <lypanov> oops, gotta run already. bbiab :)

[18:00] lypanov (~lypanov@119x86.ouraynet.com) left irc: "leaving"

[18:01] <stakkars> is that expected to show up?

[18:01] <arigo> I guess so

[18:01] <arigo> there are tons of them precisely coming from the generated exceptions module

[18:01] <stakkars> that means, constant evaluation has done the wrapping

[18:02] <arigo> there are probably a few from other places too.

[18:02] <arigo> would it be reasonable to pickle a placeholder for the "space" object?

[18:02] <arigo> it could be restored at unpickle time from a real rebuilt space...

[18:03] <arigo> this should allow W_StringObject and other stuff to be pickled effortlessly

[18:03] <stakkars> ah!?! sounds good. You mean, when I encounter such a thing, I encode the real string and an unpickler that wraps, again?

[18:04] <arigo> no,

[18:04] <arigo> I just mean that the instance 'space' should be pickled as a single global placeholder, and restored to the new 'space' when unpickling

[18:04] <arigo> then W_StringObject is a normal instance with attributes, pickled in the normal way

[18:06] <arigo> pickling space as an "external object", in the terminology of the pickle documentation

[18:06] <stakkars> the problem is all the funncy methods W_StringObject has. ??

[18:06] <arigo> methods?

[18:07] <stakkars> yeah, I end up with

[18:07] <stakkars> problem while pickling type <class 'pypy.interpreter.gateway.BuiltinFrame_for_py

[18:07] <stakkars> py.objspace.descroperation_descr__setattr__'>

[18:07] <arigo> ?

[18:07] <arigo> if you're using the standard "pickle" or "cPickle" modules, methods are not pickled, only instance attributes

[18:07] <stakkars> which is somehowpulled in by the Stringobj.

[18:07] <arigo> and not types either

[18:08] <arigo> which pickler are you using?

[18:08] <stakkars> yes but for instances you need to pickle the class.

[18:08] <stakkars> and our types/classes are not easilypicklable

[18:08] <stakkars> but floating around without source file

[18:08] <pedronis> well, they can be made so

[18:08] <arigo> very confused. which pickler are you using?

[18:09] <stakkars> standard pickler but a bit of mine where it doesn't work. yes,maybe I should reduce again.

[18:10] <stakkars> I'veoverridden function type, to just give the reduced view that we need. that's fine.

[18:10] <arigo> if we find a prebuilt instance of a strange class, we are probably in trouble; but for W_StringObject the standard pickling method should work just fine

[18:10] <stakkars> but standard pickling cannot pickle any instance of stuff that has a non-global class.

[18:10] <pedronis> yes

[18:10] <pedronis> but as I said that fixable

[18:11] <pedronis> we have few places that generate classes on the fly

[18:11] <stakkars> yes, I captured most of them. I gues this one is still missing.

[18:11] <pedronis> we could store them in some virtual module

[18:11] <pedronis> one problem is some of that creation is lazy

[18:11] <stakkars> yes yes, I'm doing so all the time :-)

[18:11] <arigo> wait a minute

[18:12] <stakkars> right, also a problem. So I'd love to get rid of it somehow.

[18:12] <arigo> is the goal here to pickle the flowgraphs after annotation?

[18:12] <stakkars> or do something that really doesn't need the space and builds everything from scratch.

[18:12] <stakkars> yes, with -no-t -no-c you said

[18:13] <arigo> ah I see. then all classes are pickled in a custom way, as we discussed

[18:13] <stakkars> but don't you need them later, maybe?

[18:14] <arigo> we need something that look like a class, only for the purpose of reading some attributes out of them

[18:14] <arigo> the precise set of attributes that we'll need is given by the ClassDef built by the annotator

[18:14] <pedronis> it's a bit tricky because I think that you need the classes to disambiguate some situations

[18:15] <arigo> pedronis: even after annotation?

[18:15] <pedronis> I fear so

[18:15] <pedronis> maybe I'm wrong

[18:15] <arigo> how much do you need the classes?

[18:15] <stakkars> maybe it's easier to tryto fake everything than trying to find where it was created?

[18:15] <arigo> stakkars: yes, could be

[18:16] <arigo> sorry for the confusion above about W_StringObject

[18:16] <pedronis> for example you need the classes to disambiguate things like dispatch tables because in the annotation they get mixed up

[18:16] <pedronis> I think they may be other cases like that

[18:16] <stakkars> I found myself digging around for a long time. could have used the time to just invent something that doesn't care about using anything but introspection.

[18:16] <arigo> pedronis: sure, I'm only suggesting to rebuild fake classes that have the same attributes at the same place

[18:17] <arigo> stakkars: to avoid strange effects with strange methods you'll probably need to ignore class attributes that are not listed in the ClassDef.

[18:17] <arigo> stakkars: also ignore instance attributes not listed there, I guess.

[18:17] <stakkars> ok

[18:19] <arigo> I wonder if we won't end up being able to unpickle the data without importing all of PyPy at all?

[18:19] <arigo> e.g. you'd get in a fresh process without all the modules and their unlazified data in memory

[18:19] <stakkars> yes, the effect of caching dynamic types in virtualmodules as I did is effectively,

[18:19] <stakkars> that we need to squeeze out an object spacelike that what we wanted to avoid.

[18:20] <stakkars> so it doesn't make very much sense. To really save that,

[18:20] <stakkars> I'm thinking of woalking through all of the stuff, collect IDs, build something like a unique table of things

[18:21] <pedronis> mmh SomePBCs may still be a problem, the annotator does not capture much about them

[18:21] <stakkars> which gets saved with the pickle.self-describing or so.

[18:21] <stakkars> pedronis: I thought they were all sitting in the constants of the ops?

[18:21] <arigo> stakkars: something independent of PyPy, that doesn't need to special-case the space

[18:22] <arigo> pedronis: the annotator records which PBC attributes are read, no? should be enough

[18:22] <stakkars> arigo: yes,blindlypickle whatever it is, as long there is a way

[18:23] <pedronis> well, but if understand the idea is to pickle classes too in a neutralized form

[18:23] <stakkars> yes, classes, functions, competelyagainst pickle'sprinciple,because we only want this eact state.

[18:24] <arigo> pedronis: the class of the SomePBCs should never be used anyway; the annotator would complain in this case

[18:24] <stakkars> (sorry, "small q" was a wish)

[18:25] adim (adim@logilab.net2.nerim.net) left #pypy.

[18:26] <arigo> the basic idea is that if code generators are able to "pickle" all this data into some low-level code, then we should be able to do the same here more easily

[18:26] <arigo> where the low-level code is the Python pickle data format

[18:27] <arigo> in this sense, this pickler would be our first complete code generator :-)

[18:28] Nick change: arigo -> arigo|afk

[18:28] <stakkars> nah, this mapping isn't bijective. I'm supposed to pickle the exact data structures which are more complex than what we generate

[18:29] <stakkars> not more complex,but more. the code generator just creates a program, not the describing strucutres.

[18:39] <arigo|afk> right

[18:40] <arigo|afk> so you're doing more than a code generator, and you're still first ;-)

[18:41] <stakkars> :-] (yes but difficult. like you virtually typing from afk)

[18:46] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: "BeOS - Because you don't eat soup with a fork!"

[18:50] Nick change: arigo|afk -> arigo

[18:51] <arigo> difficult, typing away from keyboard? noooo

[18:58] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.

[18:58] yuuh (~yuuhu@dsl-62-220-10-98.berlikomm.net) left irc: "utz utz utz"

[18:59] <stakkars> well if you have arigo.magic

[19:00] <stakkars> conclusion so far: virtualmodule to capture dynamically built types doesn't make so much sense,

[19:00] <stakkars> since you end up with something that needs a similar space to be built before unpickling.

[19:00] <arigo> yes

[19:01] <stakkars> you can keepone long-running process open and restore again and again,but that's not worth the effort.

[19:02] <stakkars> that is, I write a generic type-reconstructor that uses nothing than what it can getfrom inspection, unless the type can be found by defaultpickle.

[19:02] <stakkars> then we don't need to care atall.

[19:03] <arigo> better yet, always use the type-reconstructor

[19:04] <arigo> ah, I see the problem

[19:04] <arigo> some things like SomeObject instances need to use the default pickle way.

[19:04] <arigo> and the flow graph parts etc.

[19:04] <stakkars> to be viewable,again. Sure

[19:05] <arigo> ah yes:

[19:05] <arigo> the rule could be to use the custom pickling approach exactly for types and classes that have a classdef

[19:05] <stakkars> the pickling for those is easy. I added it when I slotted them.

[19:05] <stakkars> ah

[19:06] <arigo> typically, for example W_StringObject has a classdef because is has been processed by the annotator, but Variable doesn't.

[19:07] <stakkars> (Pdb) arg

[19:07] <stakkars> (W_StringObject('getattr'))

[19:07] <stakkars> (Pdb) type(arg)

[19:07] <stakkars> <class 'pypy.objspace.flow.model.Constant_W_StringObject'>

[19:08] <arigo> ??

[19:08] <stakkars> that's the type I'm seeing

[19:09] <stakkars> no classdef to be seen.

[19:09] <arigo> I don't think there are subclasses of Constant in PyPy svn version

[19:09] <arigo> it must have been created by some code of yours

[19:09] <stakkars> *ick* yes ok ok :-))

[19:10] <stakkars> just a space (size) optimization

[19:10] <arigo> in PyPy svn, you'd have a Constant only (pickled in the standard say) with a .value attribute pointing to a W_StringObject (pickled specially because it's got a classdef)

[19:10] <arigo> s/say/way

[19:11] <stakkars> yes yes, I was at the wron level.

[19:11] <arigo> an addition to the rule: annotator.bookkeeper.pbctypes

[19:11] <stakkars> (Pdb) type(arg.value)

[19:11] <stakkars> <class 'pypy.objspace.std.stringobject.W_StringObject'>

[19:12] <arigo> "type(arg.value) in annotator.bookkeeper.userclasses"

[19:12] <arigo> should be True

[19:12] <arigo> annotator.bookkeeper.userclasses and annotator.bookkeeper.pbctypes together should list all the types/classes of all the objects that need the special pickle way

[19:14] <stakkars> (Pdb) type(arg.value) in t.annotator.bookkeeper.userclasses

[19:14] <stakkars> true

[19:18] <stakkars> yep. great, I can see which I captured already (they have a funny module name) and which not. They will become generic.

[19:20] <arigo> the ClassDef has a method about_attribute() to know if a given instance or class attribute should be pickled

[19:20] <arigo> (there are a lot of confusing similarly-named methods on ClassDef)

[19:22] <arigo> for the "x.__class__ in pbctypes" case the bookkeeper is apparently missing a simple interface at the moment

[19:23] <arigo> have a look at how pbc_getattr() is implemented, basically

[19:23] Rhamphoryncus (~rhamph@rhamphoryncus.user) left irc: Remote closed the connection

[19:23] <pedronis> I can add one, what is exactly needed

[19:23] <stakkars> don't know, yet

[19:24] Action: pedronis has been busy chasing SomeObjects and just now managed to get W_UnicodeObject._value to be a sane thing

[19:24] <arigo> :-)

[19:24] <stakkars> whow

[19:24] <arigo> pedronis: probably a method bookkeeper.about_pbc_attribute(pbc, attr)

[19:24] Rhamphoryncus (~rhamph@rhamphoryncus.user) joined #pypy.

[19:25] <arigo> similar to classdef.about_attribute(attr)

[19:25] odie (~odie@lsne-catv-dhcp-14-47.urbanet.ch) joined #pypy.

[19:25] <pedronis> I see

[19:25] <stakkars> the greates thing would be something like getpickleargs :-)

[19:25] <pedronis> (Pdb) t.annotator.getuserclasses()[uo.W_UnicodeObject].attrs['_value'].getvalue()

[19:25] <pedronis> SomeList(listdef=<SomeUnicodeCodePoint()>)

[19:26] <arigo> :-) :-)

[19:27] <stakkars> or the very best thing would be to define __reduce__. If I understand things, I will try to express __reduce__ by those things

[19:28] <arigo> stakkars: is there a way in pickle to systematically override the way some instances are pickled?

[19:28] <stakkars> gargll, _reduce__ describes reduction of instances. we cannot atttach it easily to types I guess

[19:28] <stakkars> yes, I have copy_reg to override many types,

[19:29] <stakkars> and I can provide __reduce__ for instance, which should provide the wayto restory the thing

[19:29] <stakkars> there is a bug preventing function object pickling, but I have a fix, that works.

[19:29] <arigo> and to pickle individual types?

[19:30] <arigo> the type objects themselves?

[19:30] <stakkars> the,pickle *always* tries to look up classes and types globally.

[19:30] <pedronis> yes

[19:30] <stakkars> my version captures that and can of course dispatch

[19:30] <stakkars> so after global lookup failed, we can do whatever

[19:31] <stakkars> I could even change this rule, but my patch makes pickle compatible to cpickle

[19:31] <arigo> can you register with copy_reg the type 'type' ?

[19:32] <arigo> ah, I see it's too late for pickle.py to see it

[19:32] <stakkars> did you look into pickle.py?

[19:33] <arigo> looking now

[19:33] <stakkars> line 784

[19:33] <stakkars> dispatch[ClassType] = save_global

[19:33] <stakkars> dispatch[FunctionType] = save_global

[19:33] <stakkars> dispatch[BuiltinFunctionType] = save_global

[19:33] <stakkars> dispatch[TypeType] = save_global

[19:33] <arigo> I see

[19:33] <stakkars> is definately wrong in pickle.py since years.

[19:34] <stakkars> you can ignore this, my extension corrects for that and redirects these

[19:34] <stakkars> if save_global fails.

[19:34] <arigo> you can also override save_global() in a subclass :-)

[19:34] <stakkars> that's the (correct) cPickle way

[19:34] <arigo> ah ok

[19:34] <arigo> I see, cPickle is doing the correct thing and pickle is wrong...

[19:35] <stakkars> yes,but only if save_global fails, for compatibility (should have submitted a patch for a long time. Bon solvedit on the stackless sprint)

[19:35] <stakkars> bob ippolito

[19:35] <arigo> ok

[19:35] <stakkars> I thought he had submitted it...

[19:37] <stakkars> so if a type were able to provide an __reduce__, it could be done inplace.

[19:37] <arigo> I see. All we have to do is use a custom metaclass for all classes in PyPy.

[19:37] <stakkars> but since I think I need to instead install a custom pickler for every type in copy_reg

[19:38] <stakkars> ah, yes, sure. which has the needed introspection and maybe __reduce,saves us registering

[19:38] Action: arigo runs away

[19:38] <stakkars> from me?

[19:38] <arigo> that was a joke

[19:38] <arigo> :-)

[19:39] <arigo> because it's impossible :-/

[19:39] <arigo> if only because some of our classes need to be old-style: the exceptions

[19:39] <stakkars> well, why? two metaclasses,one for class, one for type

[19:40] <arigo> you cannot subclass types.ClassType

[19:40] <stakkars> which only provide the pickling interface. did the same for our SomeObject thingies.

[19:40] <arigo> ??

[19:41] Action: arigo is confused about why you need a custom pickling interface at all for SomeObject

[19:41] <stakkars> well I played a bit

[19:41] <arigo> ok :-)

[19:42] <stakkars> I was just trying slottifications and needed a way to provide pickling for things with slots. It is applied somewhere else.

[19:42] <arigo> plain pickle doesn't support slots??

[19:42] <stakkars> no. you need to supply __getstate__ and __setstate__

[19:42] <arigo> :-(

[19:42] Last message repeated 2 time(s).

[19:42] <stakkars> noproblem, I have a generic baseclass for that.

[19:43] <arigo> I guess so, but I'm confused about why pickle don't support it natively

[19:43] <stakkars> just inherit from slotted and you are fine.

[19:43] <arigo> nobody ever bothered, I guess

[19:44] <stakkars> no. just me ;-)

[19:44] <arigo> I see :-)

[19:45] <stakkars> the remaining problem is old-styleness of exceptions?

[19:45] <arigo> no, the real problem is that we can't expect to impose a custom metaclass to all source code that is meant to be analysed

[19:46] <arigo> better to find a local hack in pickle

[19:46] hpk (~hpk@merlinux.de) left irc: Read error: 104 (Connection reset by peer)

[19:54] <stakkars> when I walk all objects in annotator.bookkeeper.userclasses and count typesof these objects,

[19:54] <stakkars> I get exactly three.

[19:55] <arigo> we probably have one custom metaclass

[19:55] <arigo> plus "type" and "ClassType"

[19:55] <stakkars> type type, typeclassobj, and 'pypy.interpreter.miscutils.InitializedClass

[19:55] <stakkars> yes

[19:56] <arigo> the metaclass is completely equivalent to 'type' at the point

[19:56] <arigo> at this point

[19:56] <stakkars> so there are probably just two cases to handle.

[19:56] <arigo> yes

[19:57] <stakkars> applying these classes/types with the right arguments, and we can pull the rabbit out of the chapeau-claque

[19:58] <arigo> :-)

[19:59] <stakkars> in a few places, I did it by hand, captured type arguments in an attribute of the generated type to restore later.

[20:00] <arigo> but now, things are different, right?

[20:01] <stakkars> well, using this way I'd needto update all places where we invent types. not so bad,maybe

[20:01] <stakkars> unless there is an easy algortihm to guess these

[20:02] <stakkars> as you said kilobytes before

[20:02] <arigo> but the goal now is to write the pickling/unpickling in such a way that no change in the existing code is needed (apart from classes with slots), right?

[20:03] <stakkars> I wouldn't care that much, but if it is not harder, yes. If we have a simple lookup, maybe in the annotator,yes.

[20:03] <stakkars> and if it is extensible, for pickling complete space, *sometime*

[20:03] hpk (~hpk@merlinux.de) joined #pypy.

[20:03] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";

[20:04] <stakkars> I mean, if we can relyon the existence of certain attributes,and registering a few cases, that's it

[20:05] <arigo> the current goal should be to add some support in the annotator, and then everything outside it should be "user program" present as classdefs that give all the information needed to pickle that as pseudo-classes

[20:05] <stakkars> I think even classes with slots are doable without changing code, becuase we can trap apickling error.

[20:06] <arigo> I'm ok with the slot special case because it's only for flow graph and annotator data, not for the "user program"

[20:07] <stakkars> yes. I just remembered my tricksfor Stackless, where I added pickling to types which aren't even subclassable.

[20:07] <arigo> do I make sense? the goal is to look at the "user program" from outside, and never try to pickle anything the normal way that belongs to the user program

[20:08] <stakkars> the user program is everything in translator.flowgraphs?

[20:08] <arigo> no

[20:08] <arigo> the user program is the program that has been annotated

[20:08] <arigo> in this case, everything in interpreter/ and objspace/std/

[20:08] <arigo> and module/

[20:09] <stakkars> ah yes,PyPy is the user program.

[20:09] <arigo> TooManyRecursionLevelsError

[20:09] <arigo> :-)

[20:09] <stakkars> I'm stackless,MemoryError

[20:09] Action: pedronis targetpypymain is again annotated without too many SomeObjects

[20:10] <arigo> :-D

[20:10] <stakkars> !!!

[20:11] <stakkars> then let's try to spell a simple enough strategy for pickling.

[20:11] <stakkars> first,howdoI find out what the user program is, exactly?

[20:12] <arigo> there are two ways:

[20:12] <arigo> 1) instances of, or classes, listed in bookkeeper.classdef or bookkeeper.pbctypes belong to the user program

[20:12] <arigo> 2) alternatively, anything in attribute Constant.value belongs to the user program

[20:13] <arigo> but 1) is probably easier

[20:13] senra (~senra@200.183.92.243) joined #pypy.

[20:13] <stakkars> 1 ( which reduces us to the common case that we must have done annotation, but fine so far)

[20:14] <arigo> ok

[20:14] <stakkars> I don't see much difference, since I walk allCOnstant,anyway.

[20:14] <arigo> so the strategy I had in mind is

[20:14] <arigo> pickle.dump(annotator)

[20:15] <arigo> or pickle.dump(translator)

[20:15] <stakkars> in both cases requiring annotator of course

[20:15] <arigo> yes

[20:15] <arigo> then the pickler has special cases for

[20:15] <arigo> 1) instances and classes as above

[20:15] <arigo> 2) functions

[20:16] <arigo> 3) maybe some obscure stuff -- staticmethod?

[20:16] <arigo> 4) bound methods, I guess

[20:16] <arigo> the idea is to find enough cases to cover all "user program" objects

[20:17] <arigo> and pickle them all as pseudo-objects that will be unpickled into equivalent placeholders

[20:17] <stakkars> yes. a bit like I'm doing now. I have an open shell with a run pypymain, and I add features to gaphpickler.py, reload and test, until it works

[20:17] <arigo> :-)

[20:18] senra (senra@200.183.92.243) left #pypy ("Leaving").

[20:18] <stakkars> it has the great advantage that I don't have to change PyPy code, and to re-run the expensive thing all the time (which I wanted to optimize :-) )

[20:18] <arigo> sure :-)

[20:19] <arigo> so it seems we agree basically agree

[20:19] <arigo> also that we don't need to change anything in the user program?

[20:19] <stakkars> yes we agree agree

[20:19] <arigo> ok -- sorry for the lengthy synchronization :-/

[20:20] <stakkars> if I get atmost 10 cases and not tons of extra code, yes.

[20:21] <stakkars> I mean, if there are many different layouts, then it is beter to handle it where it is caused. general things -- fine

[20:21] <stakkars> what is the result of unpickling, then?

[20:22] <stakkars> complete translator as before? or a subset.

[20:22] <arigo> unpickling should produce the complete translator, for sure

[20:23] <arigo> the question is how to unpickle the user program objects (1-4 above :-)

[20:23] Action: pedronis leaving the office

[20:23] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"

[20:24] <arigo> 1) user program classes

[20:24] <arigo> should be unpickled as a new type, built by the unpickler

[20:25] <arigo> with a subset of the original attributes of the type

[20:25] <arigo> as choosen at pickle-time by the rule "classdef.about_attribute()"

[20:25] <arigo> 1bis) user program instances

[20:25] <arigo> create an instance of the unpickled class (with __new__ I guess), put attributes manually

[20:26] <arigo> same rule, the attributes are the original ones that about_attribute() knows about

[20:26] <arigo> (obviously about_attribute() is used a pickle-time, not unpickle-time)

[20:27] Action: stakkars thinks of simply rebuilding class/inst and pathing those attrs in

[20:27] <stakkars> patching. The difference to the standard way is that I don't use global lookup but build with new()

[20:27] <arigo> yes, that's what I'm saying. create dynamically classes and instances that look like the original ones, without fancy tricks to reuse parts of the original user program

[20:27] <arigo> yes

[20:29] <stakkars> (the user program idea is very good - I may not touch it! good)

[20:30] yuuh (ore@dsl-62-220-10-98.berlikomm.net) joined #pypy.

[20:31] <stakkars> I'll just think of the user program that is just data. I don't have the source :-)

[20:33] <arigo> yes :-)

[20:41] Action: stakkars only needs to switch pickling mode on entering Constant...

----- silence for 2 hr and 4 minutes -----

[22:45] odie (~odie@lsne-catv-dhcp-14-47.urbanet.ch) left irc: "Download Gaim: http://gaim.sourceforge.net/";

----- silence for 40 minutes -----

[23:25] ericvrp (~chatzilla@ericvrp.demon.nl) left irc: "Chatzilla 0.9.68.3 [Firefox 1.0.4/20050516]"

[00:00] --- Tue May 24 2005