[01:10] yuuh (smpkcmo@i528C1F27.versanet.de) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 27 minutes ----- [02:37] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Remote closed the connection
----- silence for 23 minutes ----- [03:00] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
----- silence for 1 hr and 10 minutes ----- [04:10] tea (~tea@cap011-170.kcn.ne.jp) left irc: Read error: 104 (Connection reset by peer)
----- silence for 3 hr and 12 minutes ----- [07:22] idnar (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
----- silence for 1 hr and 56 minutes ----- [09:18] idnar (mithy@idnar.user) joined #pypy.
----- silence for 1 hr and 54 minutes ----- [11:12] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[11:14] poseidon (~poseidon@host66-30.pool8174.interbusiness.it) left irc: "Verlassend"
----- silence for 23 minutes ----- [11:37] thingie24 (~rmt38@213.167.138.65) left irc:
----- silence for 54 minutes ----- [12:31] idnar (mithy@idnar.user) left irc: Nick collision from services.
[12:31] idnar_ (mithy@idnar.user) joined #pypy.
----- silence for 20 minutes ----- [12:51] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[12:55] <arigo> codespeak.net/pypy says PyCon sprint is 18-21th
[12:55] <arigo> but all other sources say 19-22th
[13:02] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[13:04] <hpk> arigo: hi armin
[13:04] <hpk> i just changed it
[13:05] <hpk> the wrong info was checked in from jacob apparently
[13:08] <arigo> hi
[13:08] <arigo> thanks!
[13:15] Action: hpk is back at working on finishing the "py-collect" branch
----- silence for 18 minutes ----- [13:33] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "lunch"
----- silence for 1 hr and 6 minutes ----- [14:39] arigo (~arigo@d213-103-152-231.cust.tele2.ch) joined #pypy.
----- silence for 18 minutes ----- [14:57] tea (~tea@cap011-170.kcn.ne.jp) joined #pypy.
----- silence for 40 minutes ----- [15:37] <arigo> hey hey hey
[15:37] <arigo> I can't believe it, something must be messed up
[15:38] <mwh> why?
[15:38] <mwh> it's all too easy?
[15:38] <arigo> translate_pypy with annotation for the goal 6*7 now takes 5 seconds, produce 400kb of code, and runs just fine
[15:38] <arigo> in the branch I just checked in
[15:39] <mwh> hum!
[15:39] <arigo> I got rid of SomeInstance's revision numbers
[15:42] <arigo> that's with a slightly modified translate_pypy.py, though
[15:43] <hpk> hum!!
[15:45] <arigo> I modified it to only include the call to the correct multimethod, instead of via descroperation,
[15:45] <arigo> the full thing still takes time of course...
[15:46] <dialtone> how far is a standalone pypy?
[15:46] <mwh> arigo: oh
[15:46] <mwh> dialtone: some way yet
[15:47] <dialtone> mwh: are you on track for the pycon sprint? I read that you plan to do that work at the next sprint
[15:47] <mwh> dialtone: where?
[15:47] <mwh> i'm not going to be there...
[15:47] <mwh> oh
[15:47] <mwh> a more general "you"?
[15:47] <dialtone> yep
[15:48] <dialtone> 'you' the sprinters and the team
[15:48] <mwh> dialtone: better ask someone else :)
[15:49] <arigo> I expect the PyCon sprint to be more introductive than hard work in style...
[15:49] <arigo> I think we'd need a good long sprint to really get somewhere interesting now.
[15:49] <arigo> one in which mwh is here, preferrably :-)
[15:52] <mwh> well, i guess much more technical stuff is happening in between sprints now
[16:00] <mwh> kind of chages the focus
[16:01] Action: mwh shuffles off again
[16:03] _hannes (ztecnmfi@i528C1F27.versanet.de) joined #pypy.
[16:14] <arigo> the annotator points real bugs in our source base
[16:14] <arigo> e.g. an untested function taking the wrong number of arguments
----- silence for 18 minutes ----- [16:32] Nick change: idnar_ -> idnar
[16:35] <mwh> oh yes
[16:46] <mwh> arigo: when do we use math.floor?
[16:48] thingie24 (~rmt38@213.167.138.65) joined #pypy.
[16:52] <arigo> in floatobject.py
[16:53] <arigo> ah, now the next crash is more subtle
[16:53] <mwh> oh, ok
[16:54] <arigo> the infamous "assert s_new_value.contains(s_old_value)" in annrpython's setbinding()
[16:54] <arigo> is finding a funny problem:
[16:54] <arigo> related to function specialization
[16:55] <mwh> aiee
[16:55] <arigo> a function specialized for more general arguments gives a less general return value, temporarily
[16:57] <mwh> uh>
[16:57] <mwh> ?
[16:57] <arigo> v3 = simple_call(v1,v2)
[16:58] <arigo> the first time, the function in v1 is specialized for a very specific v2;
[16:58] <arigo> after several reflow the answer is a general SomeStuff()
[16:58] <arigo> but later, a more general binding for v2 arrives
[16:58] <arigo> we make a fresh "template", another specialization of v1
[16:59] <arigo> which at first gives very specific return values
[16:59] <arigo> (which eventually will certainly be at least as general as SomeStuff, after some reflows)
[16:59] <arigo> the problem is that very specific SomeXxx try to go into v3.
[16:59] <mwh> i don't immediately see how this can give a very specific return value even at first
[16:59] <mwh> but i'm probably being dumb
[17:00] <arigo> actually I think it gives SomeImpossibleValue at first
[17:00] <arigo> because flowing isn't recursive
[17:01] <arigo> actually flowing into the new function will be done later
[17:02] <mwh> ah
[17:03] <mwh> should a blockedinference be being raised somewhere?
[17:03] <arigo> if it's really SomeImpossibleValue, yes
[17:04] <arigo> but next time it might be a real SomeXxx, which corresponds to only a single control flow path through the specialized function, for example
[17:04] <arigo> where the other control flow paths are still pending.
[17:10] stakkars (~tismer@82.144.60.19) joined #pypy.
[17:10] <arigo> hi
[17:10] <stakkars> heho
[17:11] pedronis (~Samuele_P@ratthing-b409.strakt.com) joined #pypy.
[17:11] <arigo> hohe
[17:11] <hpk> seems some people read the commits :-)
[17:11] <arigo> oups :-)
[17:11] <pedronis> we have some problems with out main server here
[17:12] <pedronis> yes, I saw the commit
[17:12] <pedronis> makes sense
[17:12] <hpk> arigo: that must have been the shortest lifetime of our branches: like 50 minutes :-)
[17:12] <arigo> :-)
[17:13] <arigo> next funny problem: in function specialization by type
[17:13] <arigo> the function actually called depends on the input arg types
[17:14] <arigo> so if these input types change (by becoming more general), a completely different function gets called
[17:14] <arigo> which might have a *less* general result value so far
[17:14] <pedronis> yes
[17:14] <arigo> it breaks the assert checking for this in annrpython.py.
[17:14] <pedronis> today I was thinking about doing specialization
[17:14] <pedronis> for classes
[17:15] <arigo> if it is by-call-location, we don't have this problem
[17:15] <pedronis> based on the type of some attribute
[17:15] <arigo> ah oh
[17:15] <stakkars> arigo: OT I have problems compiling goal under windows. The initializer string is way too huge for the C compiler.
[17:15] <pedronis> we would have to keep track of the origin points of the instances
[17:15] <pedronis> but we would also have the same kind of problem
[17:16] <pedronis> we would then try to reflow a less general thing
[17:16] Action: arigo hits stakkars' compiler
[17:16] <stakkars> would you mind if I a) break the string into smaller pieces b) use zlib and base64 for encoding?
[17:16] <arigo> b) yes
[17:16] <arigo> a) no
[17:17] <arigo> for b) this huge string is supposed a temporary hack
[17:17] <arigo> s//to be
[17:17] <arigo> but if breaking the string in pieces helps, fine...
[17:18] <stakkars> but you don't like it to be packed intoa form more suitable for the compiler? I even think that size would be small enough if I compress it.
[17:18] <arigo> well
[17:18] <arigo> actually, so far, if it were just a file on disk, loaded at start-up, that would be enough (but I'm not sure I know how to find this file at run-time)
[17:18] <stakkars> this would be probably a five-liner and would not involve the C code.
[17:19] <stakkars> ok, I guessed you wanted it self-contained by principle.
[17:19] <arigo> kind of...
[17:19] <stakkars> what's the problem with zlib?
[17:19] <arigo> well, none really
[17:20] <stakkars> by compressing, I will probably get a gain of 4-5,
[17:20] <stakkars> by base64 encoding, I can pack 6 bits into one byte, while right now we have one byte in four.
[17:20] <arigo> base64 is bad; the C compiler compiles one byte to one byte
[17:21] <arigo> even if it takes several bytes in the source to mean it.
[17:21] <arigo> pedronis: a dumb specialize-by-position doesn't have these problems.
[17:21] <pedronis> btw it is strange
[17:21] <stakkars> yes, I'm talking of source code size. This is my problem, and I hate redundancy
[17:22] <pedronis> arigo: yes
[17:22] <pedronis> in fact we should activate
[17:22] <pedronis> it for classes
[17:22] <pedronis> because Stack needs it
[17:22] <pedronis> I think
[17:22] <arigo> ah, right
[17:22] <arigo> yes, there is a value stack and a frame stack, at least
[17:22] <pedronis> and a block statck
[17:23] <arigo> and a block stack a la CPython even
[17:23] <pedronis> we need to copy functions in the class dict
[17:23] <arigo> guess so
[17:23] <pedronis> I think is the missing bit of the code that's already
[17:23] <pedronis> but is protected by an failing assert
[17:23] <arigo> guess so.
[17:24] <arigo> note that if we are confident about our annotator otherwise working right (cough),
[17:24] <arigo> we could add a hack to prevent less-general values from coming out of the same op_call.
[17:25] <pedronis> I see
[17:25] <pedronis> for the function problem above
[17:26] <arigo> yes
[17:26] <pedronis> we could limit that behavior
[17:26] <pedronis> to the specific case
[17:26] <pedronis> I suppose
[17:27] <arigo> a cleaner solution:
[17:27] <arigo> be more subtle about specialization by types
[17:27] <pedronis> well we could
[17:27] <arigo> and merge in all the results given so far by other, more specific specializations
[17:28] <pedronis> well you probably
[17:28] <pedronis> want to do it per position
[17:28] <arigo> per position is fragile
[17:28] <arigo> because we can have several pycall() per position
[17:29] <pedronis> I'm not saying just per position
[17:29] <pedronis> I think to factor in both aspects
[17:29] <pedronis> you need to
[17:31] <arigo> on the other hand
[17:31] <arigo> if you think about specialization of classes by attr type
[17:32] <arigo> how?
[17:33] <pedronis> I don't see a way for that
[17:33] <pedronis> that would not imply restarting the annotation process
[17:33] <arigo> we could have specialization by the type of *all* attributes
[17:34] <arigo> by specializing-by-position, and then identifying identical classes
[17:34] <arigo> at the end of the process
[17:34] <arigo> it would also be a way to specialize functions by argtypes: do it by position, and identify at the end
[17:35] <arigo> btw two specialized-by-position functions that have the same input args should be completely identical at the end, no?
[17:36] <pedronis> yes
[17:36] <arigo> so there is no real point in choosing between the two modes
[17:37] <pedronis> yes we could basically
[17:37] <pedronis> just support by position
[17:37] <pedronis> and especially for classes
[17:37] <pedronis> have a way to specify
[17:37] <pedronis> a policy
[17:37] <pedronis> on how to merge
[17:38] <pedronis> afterward
[17:38] <arigo> it's difficult to merge classes not completely identical
[17:39] <arigo> because the result of the merge is more general, so we might have to reflow
[17:39] <arigo> at least if we want a correctly typed static source code to generate
[17:39] <pedronis> yes
[17:39] <arigo> we don't have to reflow for correctness, though.
[17:40] <arigo> well, reflowing isn't difficult anyway.
[17:40] <pedronis> well, from the point of view
[17:40] <pedronis> of annotation itself
[17:40] <pedronis> yes, things are still correct
[17:40] <pedronis> on the other hand it depends on how
[17:41] <pedronis> the generator
[17:41] <pedronis> work
[17:41] <pedronis> to know whether it would want the more
[17:41] <pedronis> general types
[17:41] <pedronis> explicitly
[17:41] <pedronis> diffused
[17:42] <arigo> yes.
[17:42] <pedronis> i.e. can the more general type be stored
[17:42] <pedronis> in more specific ones
[17:42] Action: arigo tries to turn all _specialize_ into 'location'
[17:43] <arigo> if the code generator can write explicit typecasts
[17:43] <arigo> or not.
[17:43] Action: arigo must reboot
[17:45] <pedronis> ok
[17:50] idnar (mithy@idnar.user) left irc: "kbye"
[17:56] alsh (~chatzilla@213.142.200.101) joined #pypy.
[18:02] arigo (~arigo@d213-103-152-231.cust.tele2.ch) left irc: Read error: 110 (Connection timed out)
[18:05] alsh (chatzilla@213.142.200.101) left #pypy.
[18:09] arigo (~arigo@d213-103-152-231.cust.tele2.ch) joined #pypy.
[18:11] _hannes (ztecnmfi@i528C1F27.versanet.de) left irc: "utz utz utz"
[18:11] <pedronis> arigo: one good thing about the change is that we do not have the BlockedInference in the annotation code of getattr/setattr for instances anymore
[18:13] <stakkars> I need the function newcode frompy.code.Source. Anything bad if I make this function public?
[18:16] <pedronis> arigo: btw translate_pypy1 does not touch that translate_pypy0 does
[18:17] <pedronis> not touch most of the code
[18:17] <hpk> stakkars: what do you mean by "make public"?
[18:17] <hpk> pedronis: not really suprising, is it
[18:17] <pedronis> no
[18:19] <pedronis> in fact pypy0 annotation
[18:19] <pedronis> still do not finish
[18:19] <pedronis> we have a likely shallow MI problem
[18:19] <pedronis> with things that inherit from both Exception and BaseWrappable
[18:19] <stakkars> hpk: it is sitting in source.py as a utility, but not exported via the package __init__.py
[18:20] <pedronis> and we have an issue with code that does a setattr on a PBC
[18:20] <stakkars> but it is of general use.
[18:20] <pedronis> wich means that we should think about our globals state supprt
[18:20] <hpk> stakkars: ah sure, i see
[18:21] <hpk> stakkars: i guess i would put it on the py.code.Code object so that
[18:21] <hpk> py.code.Code(somecodeobject).newcode() does it
[18:22] <hpk> maybe a better name than newcode() though
[18:22] <stakkars> hpk: that's fine with me.
[18:23] <hpk> codewithsourceonfilename()
[18:23] <hpk> hard to name that thing in an sensible way
[18:23] <hpk> maybe getrawcode(hackfilename=True)
[18:24] <stakkars> that one is not that urgently needed.
[18:24] <stakkars> I'm just after a better interface to code.new, which is hard to use directly.
[18:33] <stakkars> py.Code(some).modify(...)
[18:33] <stakkars> py.Code(some).modify_filename(...)
[18:33] <hpk> that suggests an inplace operation
[18:33] <hpk> py.code.* usually provide immutable objects
[18:34] <stakkars> hum. yes
[18:34] <hpk> i think py.code.Code(...).newcode(...kwargs..) is nice
[18:35] <hpk> you just provide the keyword args you want (and the special hackfilename=True)
[18:35] <hpk> and get back a raw code object with the given params modified
[18:35] <stakkars> ok.
[18:36] <stakkars> can you do that? Probably faster
[18:36] <hpk> maybe just new() and that returns a py.code.Code() which always has the 'raw' attribute pointing to the raw cpython code object
[18:36] <hpk> ok
[18:36] <hpk> i do a basic version which you can adjust to your needs
[18:36] <stakkars> that's great
[18:37] <stakkars> I'm compressing the genc init code, and by a code trick, I can save another level of marshalling and string repr.
[18:38] ludal (ludal@logilab.net2.nerim.net) left #pypy.
[18:41] <arigo> AssertionError: expected function, got <built-in function exc_info>
[18:41] <arigo> pypy.objspace.std.fake:19
[18:42] <pedronis> yes
[18:42] <pedronis> that an issue also in pypy0
[18:43] <pedronis> locally I hacked an annotation for the thing
[18:43] <pedronis> but is not the correct thing
[18:44] <arigo> well
[18:44] <pedronis> wrap_exception is not RPython at all
[18:44] <pedronis> btw
[18:45] <arigo> the whole of fake.py isn't supposed to be there, we just have to hack around for now
[18:45] <pedronis> yes
[18:47] <pedronis> we need a way at least to say
[18:47] <pedronis> don't look into this function
[18:48] <pedronis> and assume it is this return type
[18:48] <pedronis> it has
[18:49] <arigo> makes sense
[18:49] <pedronis> basically a generalisation of what we do for builtins now
[18:50] <arigo> yes
[18:56] <pedronis> arigo: do you remember
[18:56] <pedronis> why in the code for specializing functions
[18:56] <pedronis> and there's a HAAACK
[18:56] <pedronis> and we ask for the flowgraph
[18:56] <pedronis> of the original function?
[19:00] <arigo> no
[19:00] <pedronis> I commented that out
[19:00] <pedronis> and at least pypy1 still works
[19:00] <pedronis> I don't really understand why it was there
[19:01] <arigo> svn log? run tests?
[19:01] <pedronis> the tests pass
[19:01] <arigo> maybe to keep the interfunction call graph connected in pygame?
[19:04] <mwh> pedronis: it's there so you don't try to generate new flowgraphs while the generator is running
[19:05] <mwh> i think
[19:07] idnar (mithrandi@idnar.user) joined #pypy.
[19:09] <pedronis> I see, btw how does the generator know about the specialized function?
[19:10] <arigo> ah, good question
[19:10] <arigo> I think it doesn't
[19:10] <pedronis> ah
[19:10] <pedronis> yes
[19:10] <pedronis> wrap
[19:10] <pedronis> gets compiled
[19:11] <pedronis> messy
[19:11] <arigo> indeed
[19:11] <arigo> ---see you later
----- silence for 16 minutes ----- [19:27] <hpk> stakkars: just committed the new() py.code.Code interface
[19:29] arigo (~arigo@d213-103-152-231.cust.tele2.ch) left irc: Read error: 110 (Connection timed out)
[19:42] <stakkars> hpk: thanks!
----- silence for 1 hr and 6 minutes ----- [20:48] Action: pedronis going home
[20:48] pedronis (~Samuele_P@ratthing-b409.strakt.com) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
----- silence for 17 minutes ----- [21:05] jacob22 (jacob@enzo.strakt.com) left irc: Remote closed the connection
----- silence for 41 minutes ----- [21:46] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 1 hr and 23 minutes ----- [23:09] Continuity (kittish@host81-153-48-22.range81-153.btcentralplus.com) joined #pypy.
----- silence for 21 minutes ----- [23:30] pedronis_ (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[23:30] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Read error: 104 (Connection reset by peer)
[23:39] stakkars (~tismer@82.144.60.19) left irc: Read error: 60 (Operation timed out)
[23:42] pedronis_ (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
[23:43] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[00:00] --- Sat Mar 5 2005