[01:46] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050317]"
----- silence for 24 minutes ----- [02:10] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: Remote closed the connection
[02:14] cfbolz (~cfbolz@hdlb-3e34203c.pool.mediaWays.net) joined #pypy.
[02:17] cfbolz (~cfbolz@hdlb-3e34203c.pool.mediaWays.net) left irc: Client Quit
----- silence for 1 hr and 31 minutes ----- [03:48] yuuh (ahpfbz@i528C1413.versanet.de) joined #pypy.
[03:51] _hannes (hxptid@i528C1099.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[03:54] yuuh (ahpfbz@i528C1413.versanet.de) left irc: "utz utz utz"
----- silence for 4 hr and 21 minutes ----- [08:15] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.
----- silence for 1 hr and 6 minutes ----- [09:21] Gromit (~bear@dialin-212-144-177-076.arcor-ip.net) joined #pypy.
----- silence for 27 minutes ----- [09:48] Action: Gromit is away: Debugging
[09:58] Gromit (~bear@dialin-212-144-177-076.arcor-ip.net) left irc: "Und wech"
[10:02] sanxiyn (~tinuviel@211.104.100.115) left irc: "Bye"
----- silence for 57 minutes ----- [10:59] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 42 minutes ----- [11:41] <hpk> arigo: morning
[11:43] <hpk> i am just randomly reading your greenlet documentation and was thinking that "generalized goto" might be a good keyword :-)
----- silence for 16 minutes ----- [11:59] <arigo> morning
[11:59] Action: hpk tries to bring the ppypy-test branch fully up-to-date with the py-collect branch
[12:00] <arigo> hpk: you know that you branched pypy when we were in the middle of another branch, right?
[12:01] <hpk> yes, but i don't think it is a big poblem whatsoever
[12:01] <hpk> i am just modifying conftest.py files basically
[12:01] <arigo> ok, though pytestsupport at least will need manual merging
[12:01] <hpk> yes, no big deal i guess
[12:02] <hpk> i was modifying my local copy heavily already and wanted to checkpoint
[12:03] <arigo> ok
[12:04] <hpk> do you think it would be evil to allow py.path.local(module_or_package) to return the contents of __file__?
[12:04] <hpk> (as a path object, of course)
[12:05] <arigo> you don't want to hear about __file__ that can be remote paths any more, do you? :-)
[12:05] <hpk> not really :-)
[12:05] <hpk> i am quite happy to get rid of the custom importing stuff
[12:06] <hpk> what remains is now is the exporting/selection - magic in initpkg.py
[12:06] <arigo> because I mean in general it would be nice to have a way to say "make a py.path"
[12:06] <hpk> yes, py.magic.autopath() is supposed to do that
[12:07] <arigo> I mean "make a py.path from the given obj", which may be already a py.path (returned unchanged), or a string (py.path.local-ized), or a module etc.
[12:07] <hpk> ah ok, yes, i wanted that a couple of times as well
[12:07] <hpk> py.path.makepath(...) ?
[12:08] <hpk> or patch initpkg to allow py.path(...)
[12:08] <hpk> the py.path(...) would be nice in some ways
[12:08] <hpk> it's short and if people use it instead of py.path.local() it would exaxtly fit the purpose
[12:09] <hpk> but i am not sure how to hack initpkg.py to allow this
[12:09] <arigo> :-)
[12:10] <hpk> it could be a somewhat special case:
[12:10] <hpk> "py.path" : ("./somefile.py", 'somefunction')
[12:11] <hpk> would specify that the custom py.path module object (which we have anyway), grows a __call__
[12:11] <hpk> but of course you probably want "isinstance(x, py.path)" to work, right? :-)
[12:11] <arigo> argh
[12:11] <hpk> argh to what exactly? :-)
[12:12] <arigo> you know that you don't need any initpkg magic at all to get this result in plain Python, if you allow for some indirections...
[12:13] <hpk> ?
[12:13] <arigo> you can define classes in such a way that py.path is the base class, which has attributes 'local', 'svnwc' etc that are subclasses, etc.
[12:13] <hpk> argh
[12:13] <arigo> and obtain exactly the result you want
[12:14] <hpk> probably, but initpkg's purpose is lazyness and clean namespaces
[12:14] <hpk> and i don't see how you easily get that ...
[12:14] <arigo> with an indirection we can expose only what we want
[12:15] <hpk> what would you think about _generating_ __init__.py's from the specification that is now in py/__init__.py?
[12:15] <arigo> with class-level properties instead of attributes for "svnwc", "local", etc you can have laziness
[12:16] <hpk> maintaining this manually seems more than painful
[12:16] <arigo> I think the __init__.py/initpkg.py approach makes sense, but because it's more declarative it's more limited in what you can actually do
[12:16] <hpk> yes, indeed
[12:16] <arigo> so I'm just saying that adding lots and lots of new features to initpkg doesn't really make sense.
[12:17] <hpk> ok
[12:17] <arigo> btw, maintaining manually painful: I don't think so
[12:18] <arigo> it's a one-liner like svnwc = lazyloading("modulename", "svnwc")
[12:18] <arigo> the difference with initpkg is that the line is put in the py.path class instead of in some global definition file.
[12:20] <hpk> maybe, but i am not sure i'd want to open this can of worms
[12:20] <hpk> in practice things usually get more involved
[12:20] <hpk> but maybe i am just punting
[12:21] <arigo> :-)
[12:23] <hpk> the thing is that i don't see any real-life major problems with the current initpkg.py
[12:24] <hpk> and for example, the __package__ thingie comes in handy for pyimport()
[12:24] <hpk> it allows a package to have some control over it's names and import structure ...
[12:25] <hpk> (if you initpkg() something, your package grows a __package__ meta object)
[12:27] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
[12:38] RU}MG[\|c (~Wbj@d3-98.rb2.lax.centurytel.net) joined #pypy.
[12:38] RU}MG[\|c (Wbj@d3-98.rb2.lax.centurytel.net) left #pypy.
[12:40] [RU}MG[\|c!Wbj@d3-98.rb2.lax.centurytel.net] Come watch me on my webcam and chat /w me :-) http://d3-98.rb2.lax.centurytel.net:1128/me.mpg
[12:55] arigo (~arigo@134.99.18.225) left irc: "see you later"
----- silence for 1 hr and 59 minutes ----- [14:54] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 20 minutes ----- [15:14] <arigo> ah ha, py.py crashes psyco
[15:15] <hpk> :-)
[15:15] <hpk> desparately trying to speed up py.py? :-)
[15:16] <arigo> no, actually I'm debugging psyco
[15:16] <arigo> seems to be a memory leak, but I don't have the progams that show up the leak
[15:16] <arigo> so I'm trying with other big programs like py.py
[15:17] <hpk> bwt, does psyco run with greenlets?
[15:18] <arigo> good question
[15:18] <arigo> walking the frame stack might crash
[15:25] <arigo> argh.
[15:26] <arigo> Psyco crashes on an assertion that the globals have a '__builtins__'
[15:27] <arigo> geninterplevel.py is tricky enough to actually *delete* this key from some globals at some point
[15:27] <hpk> oh
[15:27] <hpk> why do you need to assert?
[15:28] <arigo> geninterplevel normally goesn't execute the code it translates
[15:28] <arigo> but there are strange dark corners
[15:28] <arigo> in this case, it reads the classes' __doc__ attribute
[15:28] <arigo> which in app_descriptor.property is actually a computed attribute
[15:28] <arigo> so that makes a call to a def __get__() in app_descriptor
[15:29] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[15:29] <arigo> he he
[15:29] <arigo> hi!
[15:29] <hpk> hi samuele
[15:29] <pedronis> hi
[15:29] <arigo> pedronis: did you know that geninterplevel deletes the '__builtins__' key of the globals to translate
[15:29] <arigo> but still reads a class __doc__ attribute
[15:29] <arigo> which actually calls the def __get__ of our class docstring ?
[15:30] <arigo> if this def __get__ actually used any built-in, it would crash :-)
[15:30] <arigo> and I'm finding out because Psyco crashes when executing this __get__ without builtins.
[15:33] <pedronis> I see
[15:35] <pedronis> arigo: could it be changed to instead of crash on an assert on __builtins__ key in a dictionary to just ignore it?
[15:35] <arigo> yes, I'm fixing Psyco now
[15:36] <arigo> but there is still a potential problem in geninterplevel+docstring
[15:36] <pedronis> I think that assert is still there as a sanity check for genc
[15:36] <pedronis> and geninterpllevel is used to translate global dictionaries
[15:36] <arigo> which assert are you thining about?
[15:36] <pedronis> in nameof_dict
[15:37] <pedronis> the second one
[15:37] <pedronis> and instead skip a __builtins__ key
[15:37] <arigo> oh, I see
[15:38] <arigo> better maybe, translate_as_module could copy the 'dic' before deleting '__builtins__'
[15:39] <pedronis> I'm not sure, because if it encounters the dict again you have a problem
[15:39] <arigo> ok
[15:53] <arigo> py.py+psyco running Pystone doesn't leak
[15:57] <arigo> he he
[15:57] <arigo> about SourceForge categorization of projects
[15:58] <arigo> in "Operating System" each project much choose one (or a few),
[15:58] <arigo> or the entry "OS Independent"
[15:58] <arigo> now Psyco is OS Independent, and portable C code is, probably, too
[15:59] <arigo> the funny thing is that SourceForge modified the name of the category slightly
[15:59] <arigo> now it's called "OS Independent (Written in an interpreted language)"
[15:59] <arigo> so you can't write OS-Independent compiled code, nor OS-specific Python code :-)
[16:00] <arigo> aaah, there is a new category "OS Portable" now
[16:12] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[16:12] <cfbolz> hi all!
[16:12] <arigo> hi!
[16:14] <cfbolz> I'm running into problems with target_pypy1 (would have been really surprising if I didn't).
[16:14] <cfbolz> I'm not yet handling PBCs correctly, so StdObjectSpace bites me :-(
[16:15] <arigo> oh, right
[16:15] <cfbolz> Well, it shouldn't be that diffictult, the attributes that are accessed can all be translated.
[16:17] <cfbolz> The problem is that I don't have a ClassDef for it, so my existing code doesn't work. I can serialize PBCs with a ClassDef easyly.
[16:18] <arigo> I thought that all PBCs had a ClassDef...
[16:18] <arigo> ah
[16:18] <cfbolz> oh irght. it's not a PBC but a Constant
[16:18] <arigo> no, this has been changed to "no PBCs should have a ClassDef"
[16:19] <cfbolz> whatever :-)
[16:19] <cfbolz> it's SomeInstance, if there is ClassDef ?
[16:19] <arigo> yes
[16:19] <cfbolz> ok.
[16:20] <cfbolz> is there a way to get an annotation for existing objects (for example a list of ints)?
[16:20] <arigo> you could try:
[16:21] <arigo> annotator.bookkeeper.immutablevalue(x)
[16:21] <cfbolz> any restriction on that approach?
[16:21] <arigo> I don't think so
[16:21] <arigo> actually, annotator.binding(Variable-or-Constant) uses that for Constants.
[16:22] <cfbolz> ah. Good. One other thing: How can I find out whether a function has been seen annotated?
[16:22] <cfbolz> (at least partially)
[16:23] <arigo> you can check if the graph's startblock is in annotator.annotated (a dict with blocks as keys)
[16:24] <cfbolz> perfect. I checked whether the inputargs of the startblock have bindings
[16:24] <arigo> it's similar but doesn't work if there is no inputarg :-)
[16:24] <cfbolz> then I checked the return argument :-)
[16:24] <arigo> ok ok :-)
[16:25] <pedronis> but I think inputargs are bound when making the block pending
[16:25] <arigo> what if the function has no input arg and only raises exceptions, mmh? :-)
[16:25] <cfbolz> okokok. That's why was asking my question
[16:25] <pedronis> so checking whether the first block is annotated is safer
[16:28] <cfbolz> For prebuit instances of non-ClassDef classes I would try the following: If there is a getattr on them somewhere I try to find a fitting LLVM-repr of that attribute and put it in the struct that is generated. Makes sense?
[16:30] <arigo> I don't remember why we eventually made PBCs the way they are now
[16:30] <arigo> because what you describe looks like the job of the annotator
[16:30] <cfbolz> right
[16:31] <pedronis> arigo: it's when _freeze_ support was added?
[16:31] <arigo> probabl
[16:31] <arigo> y
[16:32] <cfbolz> a way to get classdefs out of existing instances would be good
[16:32] <arigo> the reasoning might have been along the lines of:
[16:32] <arigo> PBCs are only for classes that can't be dynamically instantiated
[16:33] <arigo> so all usages of PBCs are via a getattr() that reads an attribute out of a set of PBCs
[16:33] <arigo> (or via a call(), for function ptrs)
[16:33] <arigo> so it's not actually mandatory to define the correct class in the generated code
[16:34] <cfbolz> yes, but to serialize the instances into init code I have to know about the attributes
[16:34] <arigo> no
[16:34] <arigo> as an extreme example, PBCs could be ints
[16:34] <cfbolz> well, that would be okay, too
[16:34] <arigo> then you can compile getattr() as a switch
[16:34] <arigo> which returns the correct constant based on the "id" number of the PBC
[16:35] <arigo> I don't know if it's a _good_ idea, but it shows what exactly is required of PBCs :-)
[16:35] _hannes (oaxmtv@i528C1413.versanet.de) joined #pypy.
[16:36] <cfbolz> Yes, but I have to find the LLVM types of the attrs somehow.
[16:37] <pedronis> arigo: but are there not cases were a PBC is passed to code that expect a SomeInstance of some class
[16:39] <arigo> pedronis: I don't know, but I believe that the annotator doesn't handle that
[16:39] <pedronis> well there is support for the union of a PBC and SomeInstance
[16:40] <arigo> oh
[16:40] <pedronis> and it's SomeInstance if a common classdef can be constructed
[16:40] <arigo> immutablevalue() makes a SomeInstance for prebuilt non-frozen instances
[16:40] <arigo> so it looks rather like this union() is left over from previous developments
[16:41] <arigo> reading immutablevalue(), it seems that PBCs are really only for objects that don't fit in a ClassDef hierarchy at all (like function ptrs and frozen stuff)
[16:42] <pedronis> I see, we should probably put an assert in that code then
[16:42] <pedronis> I mean the union
[16:42] <arigo> cfbolz: in the example with SomePBC-as-int, we don't need a global attr-to-llvm-type mapping,
[16:43] <arigo> cfbolz: because each getattr() gets its own switch and returns an object whose type is given by the annotation of the result of this particular getattr()
[16:43] <arigo> pedronis: or return SomeObject and issue a warning
[16:43] <cfbolz> ok, I got this. But if I execute such an getattr what would it return?
[16:43] <pedronis> but this should not happen
[16:44] <arigo> pedronis: ok but I bet it will be turned into a warning soon anyway because it will still happen for now :-)
[16:44] <pedronis> ah, ah it can still happen with frozen stuff
[16:44] <arigo> what did I say? :-)
[16:45] <pedronis> if there's frozen stuff constructed at bootstrap and the same stuff constructed at runtime
[16:45] <arigo> cfbolz: a constant value whose type is the type of the result of the getattr()
[16:45] <arigo> cfbolz: each "case" in the "switch" would give a different constant value.
[16:46] <cfbolz> ah, now I get it.
[16:46] <arigo> cfbolz: in other words, it would be replacing the PBC-as-attr-to-value-objects with getattr-as-PBC-to-value-table...
[16:46] <arigo> pedronis: e.g.?
[16:46] <pedronis> well, that's the only case that can happen
[16:47] <cfbolz> arigo: But I could also just use a struct...
[16:47] <pedronis> I don't know whether we have such a case
[16:47] <arigo> cfbolz: sure enough, that's probably more reasonable
[16:48] <arigo> cfbolz: if you need to collect information about how the PBCs are used, maybe this should be done in the annotator
[16:48] <cfbolz> yes
[16:48] <cfbolz> but as I said, it would be very easy to do it in genllvm, for now.
[16:48] <arigo> ah, ok
[16:48] <pedronis> well, we would need to collect at least the attr names used of one them
[16:49] <cfbolz> pedronis: yes that would probably be all I need anyway (maybe the annotations of the results, too)
[16:49] <pedronis> ah
[16:50] <pedronis> but a lot of PBC are result of unifying PBCs
[16:50] <pedronis> that can be tricky
[16:50] <cfbolz> ah. So totally different PBCs are used in the same place?
[16:51] <arigo> the "fully correct" algorithm can be tricky, but we might go away with a good enough approximation
[16:51] <arigo> each SomePBC is "one PBC out of a given set of prebuilt objects"
[16:51] <arigo> and each getattr() reads from such a set
[16:51] <pedronis> for example the dispatch tables of frames are fun
[16:53] <cfbolz> pedronis: ouch. I see.
[16:53] <pedronis> they have some PBCs type, but it really means a func ptr type
[16:54] <cfbolz> do these functions have the same type signature?
[16:54] <pedronis> yes
[16:54] <cfbolz> good :-)
[16:55] <arigo> I'm not 100% sure that we don't have pbcs that are both callables and have attributes used on them
[16:55] <cfbolz> why is that bad?
[16:56] <pedronis> the fact that with union PBC you cannot really resolve what to do
[16:56] <pedronis> at call or gettatr site
[16:56] <pedronis> sometimes they are really jus the type of items in some list
[16:57] <pedronis> so just it just means that you are going to get one among that set at that point
[16:57] <arigo> no, we don't seem to have pbcs with user-defined __call__ any more since the multimethod clean-up
[16:58] <pedronis> we had some in frames but I removed them
[16:58] <arigo> ah, ok
[16:58] <pedronis> they were member of the infamous dispatch tables for opcodes
[16:59] <arigo> :-)
[16:59] <arigo> btw, in targetpypy1, FailedToImplement.args isn't known to be a tuple
[16:59] <arigo> it's because the ClassDef of Exception should have an __init__ method
[17:00] <pedronis> yes but then it also depends whether the args have the same length
[17:00] <arigo> ah I see. Then we can stick a new __init__ in each subclass
[17:00] <arigo> not specially elegant but should do the trick, I believe
[17:01] <cfbolz> Hey, that would remove a screenfull of hacks from genllvm :-)
[17:01] <arigo> ah?
[17:02] <cfbolz> yes, I'm special casing exceptions, since the classdefs don't contain anything useful
[17:02] <arigo> I see
[17:02] <arigo> our fault then :-)
[17:02] <cfbolz> well...
[17:03] <cfbolz> not really. It's probably the things that turn up only if you try to do a translation withouth the help of CPython.
[17:03] <cfbolz> s/the things/one of the things
[17:04] <pedronis> but it seems that at some point we need to write helpers to make sense of SomePBCs
[17:04] <arigo> yes
[17:05] <pedronis> because all the info they contain is quite implicit
[17:05] <arigo> the Correct Thing would probably involve looking at all getatttr and seeing which combinations of PBCs are used together
[17:06] <pedronis> yes
[17:07] <arigo> but if the goal is to assign an annotation to each attr of each PBC such that each getattr returns exactly that
[17:07] <arigo> then it might not be possible without generalizing some getattr's return values
[17:08] <arigo> which means that this kind of processing needs to be done while the annotator is running, in SomePBC.getattr(), incrementally
[17:09] <arigo> but it's all partly back-end-specific :-(
[17:10] <pedronis> well for getattr you can have indetity,name -> value tables for each union used somewhere
[17:10] <pedronis> very wasteful
[17:10] <arigo> yes
[17:11] <arigo> but think about genjava: there, we'd probably like to recreate a class hierarchy that allows each getattr to be a field access
[17:12] <pedronis> yes, I'm not saying I like that solution at all
[17:12] <arigo> :-)
[17:12] <pedronis> well, we can keep track of maximal union of PBC used together
[17:12] <pedronis> unions
[17:12] <pedronis> at least for getattr
[17:13] <pedronis> and then each backend decides what to do with those
[17:13] <arigo> makes sense
[17:13] <arigo> I don't expect big hierarchies of classes used for PBCs
[17:14] <pedronis> most PBC unions are of functions or methods
[17:14] <pedronis> but PBCs of modules like sys, builtin
[17:14] <pedronis> get strange stuff because of the dicts
[17:14] <pedronis> containing gateways
[17:15] <arigo> there is still the problem that two getattrs from the same maximal union could have different annotation results
[17:15] <arigo> if the getattrs are actually from different subsets...
[17:15] <pedronis> no, you treat the unions as we do with classdefs now
[17:16] <arigo> "reflowing" err.. yes, right.
[17:16] <pedronis> yes
[17:16] <arigo> ok
[17:16] <pedronis> yes to keep track of all the getattrs on the maximal union
[17:16] <pedronis> s/to/one would
[17:17] <pedronis> I have no idead what we will end up with, I don't know what getattr(SomePBC patterns we have around
[17:18] <pedronis> annotating is always rich of surprises
[17:18] <arigo> :-)
[17:22] <cfbolz> Ok. I'll hack around it to try target_pypy1 (should be easy, since I only need this for StdObjectSpace).
[17:27] <arigo> hum
[17:27] <arigo> strange py.test behavior?
[17:29] <cfbolz> ?
[17:30] <arigo> I've got a failing assert statement that causes py.test to completely exit with no message
[17:30] <arigo> it's somehow the fault of py.magic
[17:40] <arigo> some code is already special-casing the Exception subclasses to store the .args attribute! where??
[17:43] <cfbolz> you mean in the translator/annotator or genllvm?
[17:43] <arigo> in the annotator
[17:43] <pedronis> arigo: Exception.__init__ is special cases as builtin
[17:43] <arigo> ah
[17:43] <pedronis> builtin.py
[17:43] <arigo> ok...
[17:44] <pedronis> so it's really a .args length issue
[17:46] <arigo> argh! now I see what you mean
[17:46] <arigo> I spent some time reinventing this special-case differently and wondering why the test I wrote also passed if I disabled what I just added :-(
[17:48] <arigo> do you have a test for the existing behavior? if not, I'll check mine in
[17:48] <pedronis> I don't think there's a test
[17:49] <pedronis> but I did not add the __init__ support
[17:49] <pedronis> I found it already there
[17:49] <arigo> :-)
[17:49] <pedronis> I add to special case AssertionError OTOH, that's me before merging the last branch
[17:50] <arigo> of course svn blame pretends it's me that put this support there a while ago
[17:50] <arigo> never believe svn, I'm sure my memory is better than his
[17:51] <pedronis> yes, all the branching and merging and pairing svn blame is not that relevant
[17:51] <arigo> that was meant to be with a ":-)" at the end :-)
[17:52] <arigo> pypy-svn shows it's really from me :-)
[17:52] <pedronis> :) (too many moving parts ...)
[17:52] <arigo> :-)
[17:53] <arigo> er, so, damn, we have a .args that can contain an empty or a 2-tuple
[17:54] <pedronis> yes, args is a tuple and we are not gracious at all handling them with different length
[17:55] <arigo> we could stop using .args and write our own constructors in the source
[17:56] <pedronis> yes
[17:56] <arigo> it would be one special case less, too
[18:02] <arigo> btw: a good way to obtain buggy .pyc files is to move them around, or rename some parent directory
[18:03] <arigo> I just got the case, it generates lots of test failures
[18:03] <pedronis> because of __file__
[18:03] <arigo> yes
[18:04] <pedronis> mmh, maybe py.test should check that __file__ is sane
[18:04] <pedronis> althoug if I understand in the collect branch is not doing it's own imports any more
[18:04] <arigo> yes, I think so, so it wouldn't help
[18:06] <pedronis> well, it could still check the __file__ and emit a warning
[18:06] <pedronis> something like: you probably need to delete your pycs
[18:06] <arigo> I think the test failures are about applevel or applevelinterp not finding the sources
[18:07] <arigo> this error message could hint that buggy .pyc files might be to blame
[18:07] <pedronis> ah, the joys of getting the source
[18:08] <pedronis> I still think that the idea of attaching the source in some way to functions etc, was a good idea but it went nowhere on python-dev
[18:09] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[18:11] <arigo> yes, well, you probably don't want the source in the .pyc files
[18:11] <arigo> so it's not clear that it would help here
[18:13] <pedronis> well, as a optional feature you probaly want the source or the ast in the pyc files
[18:13] <arigo> ok
[18:14] <arigo> I'd prefer a better management of pyc files as cache
[18:15] <pedronis> well, it's a on orthogonal issue
[18:15] <pedronis> but I see
----- silence for 25 minutes ----- [18:40] <hpk> arigo: but you don't think that py's custom hook should be retained, do you?
[18:41] <arigo> hpk: I have no precise idea about the subject :-)
[18:41] <arigo> but no, getting rid of it is probably good
----- silence for 17 minutes ----- [18:58] Action: arigo got rid of the e.args peek-and-poke games
[18:58] <arigo> the numerous exception classes of pyframe.py are now clearer, I think
[18:59] <arigo> I grepped for '.args' and if that's not complete, I just hope that our test coverage is really good.
[19:05] Nick change: pedronis -> pedronis_afk
[19:08] <dialtone> where can I find an example of py.code.Source/Code usage?
[19:08] <hpk> dialtone: in its tests?
[19:08] <dialtone> ah right
[19:14] _hannes (oaxmtv@i528C1413.versanet.de) left irc: "utz utz utz"
[19:15] Nick change: arigo -> arigo`dinner
[19:18] <cfbolz> see you
[19:18] <cfbolz> I'm going home
[19:20] <hpk> see you
[19:20] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
----- silence for 19 minutes ----- [19:39] stakkars (yzopvw@i528C1413.versanet.de) joined #pypy.
[19:50] Nick change: pedronis_afk -> pedronis
[19:51] <pedronis> arigo: I tried targetpypy0, now there are some blocked blocks
[19:51] <stakkars> hi!
[19:54] <stakkars> pedronis: I'm rreading the integer proposal. Do I need to go through the IRC discussion as well?
[19:55] <pedronis> no, unless you have questions. But you can ask them directly
[20:01] <stakkars> what I don't get yet is why the r_int approach doesn't make sense.
[20:02] <stakkars> It has its operations a checking built-in. Why is it better to move that into translation?
[20:03] <pedronis> the problem with the r_int approach is that it explode also out of try except
[20:03] <pedronis> if a r_int for some reason propagate where we don't care about overflow
[20:04] <stakkars> ah
[20:04] <pedronis> so we have different behavior before and after translation
[20:04] <stakkars> and why is r_unint kept?
[20:05] <pedronis> because we need a way to mark unsigned
[20:05] <pedronis> and doesn't raise exceptions so that problem is not there
[20:06] <stakkars> aha. I don't get it, really. There is explosion on r_int, because ti is checked all the time?
[20:06] <pedronis> the semantics of rpython say that you get an overflow only if you check in the same functions
[20:07] <pedronis> but r_int would do that everywhere
[20:07] <stakkars> well, I thought to treat these classes specially, inlining their implementation, so that woukd give local behavior.
[20:07] <pedronis> no, translation will simplfy erase them
[20:08] <pedronis> r_uint just become an unsigned int and that's it
[20:08] <stakkars> that deüends on how we define the mapping.
[20:08] <pedronis> that's the mapping we have in mind
[20:09] <pedronis> the new rules should allow the same behvior before, with unannoted and with annotated translation
[20:09] <stakkars> well, that's the difference between minds.
[20:09] <stakkars> ok, I understand that.
[20:10] <stakkars> is it still true that we want all integers behave C-ish, unless we have exception handlers?
[20:11] <pedronis> yes, but you may need to use intmask in some places
[20:11] <pedronis> to get the same effect before and after translation
[20:11] <stakkars> that is how I make this explicit, in the RPython code, by hand, right?
[20:12] <pedronis> like in hash__String
[20:12] <stakkars> intmask never raises and kills all bits, even making a long into a negative int?
[20:13] <pedronis> yes
[20:13] <stakkars> so it translates to a noop, assuming a word size C variable.
[20:13] <pedronis> yes
[20:28] <stakkars> where is a song about a torero, "Carmen" or "Figaro's wedding"?
[20:33] <stakkars> Carmen (OT)
[20:34] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 48 minutes ----- [22:22] CLI (opera@86.125.128.38) joined #pypy.
[22:23] CLI (opera@86.125.128.38) left #pypy.
[22:26] Nick change: arigo`dinner -> arigo
[22:28] CLI (opera@86.125.128.38) joined #pypy.
[22:29] CLI (opera@86.125.128.38) left #pypy.
----- silence for 19 minutes ----- [22:48] CLI (opera@86.125.128.38) joined #pypy.
[22:48] CLI (opera@86.125.128.38) left #pypy.
----- silence for 28 minutes ----- [23:16] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[23:20] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
[00:00] --- Sun Apr 10 2005