[01:22] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[01:30] stakkars (yzopvw@i528C1413.versanet.de) left irc: "(bye)"
----- silence for 6 hr and 27 minutes ----- [07:57] idnar (mithrandi@idnar.user) got netsplit.
[07:59] idnar (mithrandi@idnar.user) returned to #pypy.
[08:06] idnar (mithrandi@idnar.user) left irc: Nick collision from services.
[08:06] idnar_ (mithrandi@idnar.user) joined #pypy.
----- silence for 2 hr and 23 minutes ----- [10:29] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 57 minutes ----- [11:26] stakkars (veisrsf@i528C1305.versanet.de) joined #pypy.
----- silence for 1 hr and 7 minutes ----- [12:33] <hpk> arigo: morning
[12:33] <arigo> morning
[12:35] <hpk> a side note: i changed test collectors/items to (finally) return a list of names on run() :-)
[12:35] <hpk> so one more thing where i am following your suggestion :-)
[12:36] <arigo> :-)
[12:36] <hpk> it just appears more natural from the "custom collectors" side
[12:36] <arigo> yes, I suppose so
[12:36] <hpk> for example, if you want to restrict a directory to only recurse to specific dirs you just write:
[12:36] <hpk> class Directory(py.test.collect.Directory):
[12:36] <hpk> def run(self):
[12:37] <hpk> return ['name1', 'name2']
[12:37] <arigo> :-)
[12:38] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: "shutdown; make desk; make install"
[12:49] idnar_ (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
[12:51] stakkars (veisrsf@i528C1305.versanet.de) left irc: Read error: 113 (No route to host)
[13:01] CLI (opera@86.125.128.38) joined #pypy.
----- silence for 54 minutes ----- [13:55] CLI (opera@86.125.128.38) left #pypy.
[13:55] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
----- silence for 18 minutes ----- [14:13] <cfbolz> hi all!
[14:18] <arigo> hi
[14:18] <arigo> !
[14:19] <arigo> how's targetpypy1 doing? :-)
[14:19] <cfbolz> wel...
[14:19] <cfbolz> it's a bit hard.
[14:19] <cfbolz> I just got enough of it yesterday and did something else :-)
[14:20] <arigo> makes sense :-)
[14:21] <cfbolz> well, I started writing a real implementation of longs :-)
[14:21] <arigo> oh, nice
[14:21] <cfbolz> I'm not really far, adding, substracting, multiplying works allready
[14:22] <arigo> how large are the "digits" ?
[14:22] <cfbolz> they are r_uints
[14:22] <cfbolz> and I do the arithmetic with half an r_uint to get the correct overflow
[14:23] <arigo> but you store full r_uints ?
[14:23] <cfbolz> yes
[14:23] <arigo> ok
[14:23] <arigo> you also use half r_uints for addition ?
[14:23] <cfbolz> yes
[14:23] <arigo> because overflow is easy to detect
[14:24] <cfbolz> ?
[14:24] <cfbolz> you mean with the new ovfchecked?
[14:24] <arigo> no,
[14:24] <arigo> you can add two full r_uints, c = a+b,
[14:24] <arigo> the extra overflow bit is easily computed: 1 if (c<a), 0 otherwise
[14:25] <cfbolz> ah, of course. I'm not really that good with bit fiddling :-)
[14:25] <arigo> ok :-)
[14:25] <cfbolz> I'm keeping to CPythons implementation mostly
[14:26] <arigo> it would be more involved with signed integers, though
[14:26] <arigo> ok.
[14:26] <cfbolz> btw: r_uints are not yet annotated as SomeInteger(unsigned=True), right?
[14:26] <arigo> they should be...
[14:26] <cfbolz> well, they get an SomeInstance
[14:27] <arigo> ah, maybe again it's a problem with prebuilt instances
[14:27] <hpk> cfbolz: just a quick question, you got my mail regarding accession as a partner, right?
[14:27] <cfbolz> hpk: yes, sorry that I didn't respond
[14:27] <hpk> cfbolz: np, just wanted to check, i am always a bit scared of gmx addresses :-)
[14:28] <cfbolz> hpk: They're not that bad.
[14:28] <cfbolz> hpk: thanks a lot, by the way :-)
[14:28] Action: hpk bounces the thanks to cfbolz
[14:29] Action: cfbolz blushes
[14:29] Action: hpk goes back to debug lib-python testing ...
[14:29] <cfbolz> hpk: have fun
[14:30] <cfbolz> arigo: shouldn't at least get r_uint constants get the correct annotation in immutablevalue?
[14:31] _hannes (triaplu@i528C1305.versanet.de) joined #pypy.
[14:31] <arigo> cfbolz: yes, you're right
[14:31] <arigo> r_uint is missing from immutablevalue() and probably also valueoftype() in bookkeeper.py
[14:32] <cfbolz> are you fixing it? and can I watch if you do?
[14:32] <arigo> ok
[14:33] <arigo> screen -x arigo/arigo
[14:33] <cfbolz> I'm there
[14:34] <hpk> would be nice to have an AVI of screen-sessions :-)
[14:41] <cfbolz> I had a dos-tool once, that could do something like that.
[14:51] <arigo> what's going on with the screen session?
[14:51] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: Read error: 104 (Connection reset by peer)
[14:56] <arigo> broken .pyc files again...
[14:56] <hpk> cpython should be more picky about pyc files
[14:56] <arigo> in this case, my .pyc files have a co_filename that is wrong
[14:56] <hpk> exactly, that should be checked
[14:56] idnar (mithrandi@idnar.user) joined #pypy.
[14:57] <hpk> i have had the situation before, i think, with respect to strange nfs-problems
[14:57] <arigo> yes, CPython should checked that when loading a .py file, if there is a .pyc file, then it should only be used if it points back to the same .py file
[14:57] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[14:57] <hpk> arigo: i guess so
[14:58] <arigo> seems sensible, I'll write this down in the bug report
[14:58] <arigo> and probably attach a patch just after
[14:58] <cfbolz> sorry! My computer died because out home directory server crashed.
[14:58] <cfbolz> s/out/our
[14:58] <hpk> nfs is fun
[14:59] <hpk> arigo: sounds good, you could also fix it in getpycode()
[14:59] <arigo> cfbolz: the problem was broken .pyc files again
[14:59] <arigo> hpk: is getpycode() still there in the branch?
[14:59] <cfbolz> yes, I still saw that part
[14:59] <hpk> arigo: yes, getpymodule() getpycode() are fully there, still
[14:59] <arigo> ok
[14:59] <cfbolz> hpk: Yes, we're trying to get AFS running, not much success so far
[15:00] <hpk> arigo: they should be renamed to _getpymodule() and _getpycode() at some point, and maybe there could be an option that uses them instead of the new pyimport()
[15:08] <cfbolz> hpk: Oh, I just realized that you didn't mean our home directories with your comment about nfs :-)
[15:09] <cfbolz> hpk: I was allready astonished how you guessed that we're using nfs.
[15:09] <hpk> cfbolz: oh, i actually did mean your home directories :-)
[15:09] <hpk> computer crashing / remote home server -> very likely nfs :-)
[15:09] <cfbolz> right :-)
[15:10] <hpk> although the 2.6 linux series are better in this respect
[15:10] <hpk> most problems arise if using different unices (like a solaris client, which can crash the linux 2.6. nfs server ...)
[15:10] <cfbolz> well, that's not really the problem here, since everybody is using Linux (or Windows)
[15:11] <cfbolz> (but Windows doesn't get files via nfs of course)
[15:14] <hpk> arigo: regarding KeyboardIÖnterrupt, it's probably not py.test's fault
[15:14] <hpk> arigo: but the fault of someone doing bare except:'s
[15:14] <arigo> hpk: no, I think I know:
[15:14] <arigo> it's because they get turned into OperationErrors
[15:15] <hpk> arigo: conftest.py:114 turns them back
[15:15] <hpk> pypy/conftest.py
[15:15] <arigo> ah
[15:15] <hpk> but maybe it's a different code paths that doesn'T use execute_appexecf
[15:16] <hpk> yes, i guess that running interplevel tests will not go through that code path
[15:17] <hpk> this is on my todo-list to refactor, partly done on the pypy-branch already
[15:19] <hpk> what do you think of saying that py.test reserves all lowercase short-options and applications should only pick capital letters?
[15:19] <arigo> for one-letter options? ok
[15:20] <hpk> yes, for long options the probability of clashes is small enough, i think
[15:21] <hpk> i was thinking that py.test should only use long options but that is a bit too harsh, i think
[15:21] <arigo> probably
[15:22] <hpk> with the new branch you can actually go to dist-pypy and issue "py.test" which will work through all the packages
[15:22] <hpk> this is a nice side effect of the "option = py.test.addoptions()" thingie
[15:22] <hpk> because even if commandline options of sub-packages are not initially considered at least the subtrees have to defaults to work with
[15:23] <arigo> I see
[15:24] <hpk> i consider this a major feature actually :-)
[15:25] <arigo> :-)
[15:26] <cfbolz> Hey, I just got bitten for the first time by old .pyc too.
[15:26] <cfbolz> I was nearly complaining that the fix of r_uint annotation doesn't work and stared at the annotator code for quite some time :-)
[15:27] <hpk> arigo: it would be interesting to fix getpycode() right away to see if such problems go away
[15:27] <hpk> i guess i will still take a few days to finish the branch, especially considering my dentist date tomorrow :-)
[15:28] <arigo> :-(
[15:28] <arigo> hpk: I checked the getpycode() fix already
[15:28] <arigo> (insert "in" somewhere)
[15:28] <hpk> time machine quality
[15:30] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 16 minutes ----- [15:46] <arigo> I think we must have 27 versions of a mapping between operation names and built-in Python functions that do them
[15:46] <arigo> now that I need a 28th, I'm wondering if we couldn't unify them a bit
[15:54] <pedronis> hi :)
[15:54] <arigo> hi
[15:55] <pedronis> it would be a good idea, also because people have been bitten more than once by operator.pow is not a good subtitue for __builtin__.pow for space op equivalent
[15:56] <arigo> yes
[15:56] <arigo> also, what about 'type' and 'issubtype'
[15:57] <arigo> in the flow objspace, 'type(Exception)' is faked to return 'type'
[15:58] <pedronis> well, in general we should simulate that we have only new-style classes
[15:58] <arigo> ok
----- silence for 49 minutes ----- [16:47] <arigo> good
[16:48] <arigo> now the flow objspace turns all calls to built-in functions to their corresponding space operations, if possible
[16:48] <arigo> this makes annotation/builtin.py much smaller,
[16:48] <arigo> we can handle everything in the SomeObject hierarchy only
[17:03] <arigo> Christian's new _interplevel_cache.py doesn't seem to hold all analysed pieces of code,
[17:03] <arigo> but only the last one
[17:09] <pedronis> ah
[17:10] <arigo> makes it difficult to debug something there that goes wrong because of the flow space
[17:10] <pedronis> yes
[17:13] <arigo> the problem I have now is that applevelinterp fails because I turned calls to builtins into single operations, for which we don't have enough implicit_exceptions
[17:13] <arigo> enough for R-Python, but not in general
[17:15] <pedronis> yes, geninterplevel was also special because it used builtins_can_raise_exceptions = True
[17:16] <arigo> I see
[17:16] <pedronis> I made that change because otherwise I had the same kind of problem at a different level
[17:17] <pedronis> the app helpers are RPython-ish but RPython so geninterplevel is obviously an oddball
[17:17] <pedronis> s/but/but not
[17:18] <arigo> would it make sense to raise an implicit Exception for *every* operation?
[17:18] <pedronis> well, it would make sense to have a mode that does that and activate it for geninterplevel
[17:19] <arigo> yes, that was my question
[17:19] <pedronis> with the change I fear is necessary
[17:19] <arigo> I can also simply not do my change in geninterplevel mode and keep the simple_call
[17:19] <pedronis> yes
[17:20] <arigo> hum, I can probably have the best of both worlds and raise an implicit Exception when I do my change and when in geninterp mode
[17:24] <pedronis> arigo: did you pay attention that you cannot trasform a 3 args getattr?
[17:24] <arigo> pedronis: not at all
[17:24] <arigo> :-)
[17:25] <pedronis> that also something we encountered with geninterplevel
[17:25] <pedronis> because it is also already doing that transformation by itself (builtin -> space op)
[17:25] <arigo> argh
[17:28] <pedronis> also space.pow takes exactly 3 arguments the builtin is happy just with two
[17:29] <arigo> yes but I don't know if I want to handle that case...
[17:29] <arigo> well as a special case, it's ok
[17:32] <pedronis> I'm thinking about builtin pow(2,3) -> space.pow (2,3, None)
[17:32] <arigo> yes, that's what I'm thinking too :-)
[17:36] <pedronis> btw, we thought of removing OverflowErrro as an implicit exception but ops on floats can still raise it
[17:38] <arigo> I see
[17:43] <arigo> shouldn't we use the same rules for floats, somehow?
[17:44] <cfbolz> I'm going home. See you
[17:44] <arigo> bye
[17:45] <cfbolz> bye
[17:45] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[17:48] <pedronis> arigo: well we coud use a similar idiom but that does not change the fact that on CPython the operation itself will reaise the OverflowError
[17:48] <arigo> grumble, yes
[17:56] <arigo> I also got 'int', 'long' and 'float' wrong
[17:56] <arigo> because they should not accept a string
[18:03] <arigo> argh argh argh
[18:03] <arigo> _interplevel_cache is probably a bad idea for now
[18:04] <arigo> it makes everything behave erratically
[18:04] <arigo> tests that fail once pass the next time, etc.
[18:05] <arigo> I've just spent half an hour debugging something that was solved by removing _interplevel_cache.pyc (the pyc! I removed the py regularly but forgot the pyc)
[18:08] idnar (mithrandi@idnar.user) left irc: Nick collision from services.
[18:08] idnar_ (mithrandi@idnar.user) joined #pypy.
[18:10] <pedronis> did you change GI_VERSION in geninterplevel?
[18:10] <arigo> ah, I should, right
[18:10] <arigo> it's a bit hard to change it all the time while debugging
[18:12] <pedronis> I think there should a value for it that means don't cache
[18:13] <pedronis> to set when playing with changing flowspace etc
[18:15] <arigo> ok
[18:15] <arigo> I also fixed it not to try importing the .pyc file if the .py file has been deleted
[18:24] sax_ (~sax@probio.xs4all.nl) joined #pypy.
[18:25] sax_ (~sax@probio.xs4all.nl) left irc: "Leaving"
[18:29] idnar_ (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
----- silence for 38 minutes ----- [19:07] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
[19:17] pedronis (~Samuele_P@c-0c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[19:26] idnar (mithrandi@idnar.user) joined #pypy.
[19:36] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 2 hr and 58 minutes ----- [22:34] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 1 hr and 22 minutes ----- [23:56] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
[00:00] --- Mon Apr 11 2005