[00:23] _hannes (avvuvv@i528C12C8.versanet.de) left irc: "utz utz utz"
----- silence for 1 hr and 9 minutes ----- [01:32] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
----- silence for 1 hr and 9 minutes ----- [02:41] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 1 hr and 2 minutes ----- [03:43] arigo_ (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
----- silence for 19 minutes ----- [04:02] arigo_afk (~arigo@vicky.ecs.soton.ac.uk) left irc: Read error: 110 (Connection timed out)
[04:16] -dmwaters (dmwaters@dmwaters-osuosl.staff.freenode) to $*- {global notice} Hi all! We have one large split coming up so that i can fix some routing problems. This will not take long, Please sit back and enjoy your flight, and thank you for using freenode!
[04:18] unscene (~Unscene@152.97.224.238) joined #pypy.
[04:18] idnar (mithrandi@idnar.user) got netsplit.
[04:19] tic (~vision@s-213-115-110-186.sme.bredbandsbolaget.se) got netsplit.
[04:19] etrepum (bob@ayunami.redivi.com) got netsplit.
[04:20] idnar (mithrandi@idnar.user) returned to #pypy.
[04:20] tic (~vision@s-213-115-110-186.sme.bredbandsbolaget.se) returned to #pypy.
[04:20] etrepum (bob@ayunami.redivi.com) returned to #pypy.
[04:23] -dmwaters (dmwaters@dmwaters-osuosl.staff.freenode) to $*- {global notice} Hi all! All done now. Sorry for the bumpy ride there, we had a bit of unexpected routing trouble that I fixed while I was at it. Thank you for your patience, and thank you for flying freenode!
----- silence for 42 minutes ----- [05:05] unscene (~Unscene@152.97.224.238) left irc: Read error: 110 (Connection timed out)
----- silence for 2 hr and 13 minutes ----- [07:18] idnar (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
----- silence for 1 hr and 52 minutes ----- [09:10] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
[09:22] arigo_ (~arigo@vicky.ecs.soton.ac.uk) left irc: Read error: 110 (Connection timed out)
[09:24] arigo_ (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
----- silence for 1 hr and 28 minutes ----- [10:52] ludal (~ludal@lab75-1-81-57-254-81.fbx.proxad.net) joined #pypy.
----- silence for 16 minutes ----- [11:08] arigo_ (~arigo@vicky.ecs.soton.ac.uk) left irc: Remote closed the connection
[11:10] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[11:13] <hpk> arigo: hello again
[11:13] <arigo> morning
[11:17] <hpk> arigo: may i pester you with asking if you saw Michele's greenlet post on py-dev?
[11:17] <hpk> i saw you made another example
[11:17] <hpk> or was that coincendence?
[11:17] <arigo> no, he asked me to
[11:18] <arigo> but he answered his own e-mail on py-dev
[11:18] <arigo> should I write more?
[11:18] <hpk> i'd mention the new example to others
[11:19] <hpk> there are some people interested in greenlets and they probably enjoy a reminder that greenlet's exist :-)
[11:19] <arigo> ok
[11:19] Action: hpk is a bit scared of current cpython-dev discussions, btw
[11:20] <hpk> hey, i think it's actually a good idea to put all test results into a common result dir
[11:21] <hpk> because we can always write a tool that goes back in history ...
[11:21] <hpk> and distinguish platforms etc.pp.
[11:21] <arigo> indeed
[11:21] <hpk> so we should advertise that everybody is free to run tests and commit the results
[11:21] <arigo> I've got all tismerysoft.de test results,
[11:21] <arigo> should I check them in?
[11:21] <hpk> sure
[11:21] <hpk> wait
[11:21] <hpk> let's add a 'version' field
[11:22] <arigo> ?
[11:22] <hpk> result-type-version: 1.0
[11:22] <hpk> it could be useful later and doesn't hurt
[11:23] <hpk> am i making sense?
[11:25] <arigo> to distinguish various text formats produced by later versions of conftest?
[11:25] <hpk> yes
[11:25] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[11:26] <hpk> hi samuele
[11:26] <arigo> you want to add this line manually, for the already-produced results?
[11:26] <arigo> hi
[11:26] <hpk> arigo: if you don't mind, yes
[11:26] <pedronis> hi
[11:26] <pedronis> hpk: I missed the point last night, mutants defeats the timeout mechanism :(
[11:26] <hpk> yes, but only for larger timeouts
[11:27] <arigo> pedronis: yes, I had to kill it manually at one point
[11:27] <pedronis> because I had the tests running overnight on my office machine
[11:27] <pedronis> and they are stuck at mutants :(
[11:27] <hpk> where is michael, when you need him :-)
[11:28] <arigo> hpk: I'm not here today (I'm just dropping by at the office to buy a coach ticket for tomorrow)
[11:28] <arigo> maybe you or samuele can pick my test results from tismerysoft.de if you want to modify them before checking them it
[11:29] <arigo> pypysrc/lib-python-2.3.4/etc
[11:29] <hpk> arigo: just check them in
[11:29] <hpk> it's not that hard to add it later and implicitely assume the current ones ==1.0 :-)
[11:31] <hpk> and have a nice sunny day ... at least i am taking a small sun shower now ...
[11:32] <arigo> ok
[11:32] <arigo> thanks :-)
[11:38] <arigo> hum, I guess we'll need some kind of tool also,
[11:38] <arigo> to help us check in a newer version of a test_*.txt
[11:38] <arigo> only if it is for a more recent revision
[11:39] <arigo> my own check-in is for multiple revisions because I svn up'ed often during the long run
[11:46] Nick change: pedronis -> pedronis_lunch
[11:48] ludal (~ludal@lab75-1-81-57-254-81.fbx.proxad.net) left irc: Remote closed the connection
----- silence for 40 minutes ----- [12:28] <hpk> arigo: i am not sure i understand
[12:28] Nick change: pedronis_lunch -> pedronis
[12:33] <hpk> arigo: each test result cites the then-current revision of the pypy directory
[12:34] <hpk> arigo: we could by default do an 'svn up' on pypy-dist
[12:39] <hpk> pedronis: do you know off-hand if we support private __ instance names?
[12:39] <pedronis> we should, it's the compiler that does the mangling
[12:40] <hpk> yes it works
[12:47] <pedronis> hpk: my tests run is slowly about to finish
[12:47] <pedronis> from the rev number is seem more recent than Armin's one
[12:47] <pedronis> but is still before you added the printing the of oldstyle vs. new
[12:48] <pedronis> and before you fixed the bug so things run all with oldstyle
[12:48] <hpk> ok, doesn't matter
[12:48] <hpk> just check it in
[12:48] <hpk> i think we don't need to think about the order of things
[12:48] <hpk> the current version will always be kind of recent
[12:49] <pedronis> no, just to keep in my mind that stuff my be failing because of bugs in old style classes (they were not much tested)
[12:49] <pedronis> or OTOH pass because of them
[12:49] <hpk> right, we'll see
[12:50] <hpk> it probably makes sense to run the tests both with old and new style classes
[12:50] <pedronis> yes
[12:50] <pedronis> we should exclude mutants somehow btw
[12:51] <hpk> easiest one is to simply comment it in conftest with a proper comment and XXX
[12:51] <hpk> it's probably a test that we need to fix for the may goal
[12:52] <hpk> (i don't mean modifying the tests but fixing pypy)
[12:52] <hpk> (if feasible)
----- silence for 1 hr and 8 minutes ----- [14:00] <pedronis> hpk: one thing is that timeouts are machine dependent
[14:01] <hpk> in which sense?
[14:01] <hpk> you mean speed of the machines?
[14:01] <pedronis> yes
[14:01] <pedronis> test_marshal passed for me
[14:01] <pedronis> and timed out on tismerysoft
[14:02] <hpk> well, the test run could run pystone first and we set the timeout in terms of pystones :-)
[14:03] Action: hpk -> lunch
[14:03] dlk (~dlk@walter.ita.chalmers.se) joined #pypy.
[14:03] dlk (dlk@walter.ita.chalmers.se) left #pypy.
----- silence for 21 minutes ----- [14:24] idnar (mithy@idnar.user) joined #pypy.
----- silence for 31 minutes ----- [14:55] arigo (~arigo@vicky.ecs.soton.ac.uk) got netsplit.
[14:55] arigo (~arigo@vicky.ecs.soton.ac.uk) returned to #pypy.
----- silence for 16 minutes ----- [15:11] ludal (~ludal@lab75-1-81-57-254-81.fbx.proxad.net) joined #pypy.
[15:12] hpk (~hpk@merlinux.de) left irc: Read error: 110 (Connection timed out)
[15:24] _hannes (trcnnijh@dsl-62-220-11-56.berlikomm.net) joined #pypy.
----- silence for 24 minutes ----- [15:48] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection
----- silence for 1 hr and 15 minutes ----- [17:03] idnar (mithy@idnar.user) left irc: "kbye"
----- silence for 1 hr and 4 minutes ----- [18:07] hpk (~hpk@merlinux.de) joined #pypy.
[18:22] <pedronis> hpk: we have 95 tests passing, 72 failing in some way (some may be still ignorable but also some of the passing ones) and 21 timeouts (+ plus the ignored stuff)
[18:29] Action: pedronis is leaving (will not reappear until much later, mid-evening)
[18:29] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
----- silence for 32 minutes ----- [19:01] idnar (mithrandi@idnar.user) joined #pypy.
----- silence for 3 hr and 20 minutes ----- [22:21] cfbolz (~cfbolz@wrz9-d9b95ec8.pool.mediaWays.net) joined #pypy.
[22:21] <cfbolz> hi!
[22:21] <hpk> hi carl
[22:21] <cfbolz> discovered a strange bug: u"asdffa"[:-1]
[22:21] <cfbolz> raises
[22:22] <cfbolz> TypeError: an integer is required
[22:22] <cfbolz> in PyPy
[22:22] <hpk> works for me :-)
[22:22] <hpk> rev 11607
[22:23] <cfbolz> ok, mine is older
[22:23] <cfbolz> I'll try svn up
[22:28] <cfbolz> ok, I had an old revision.
[22:29] <cfbolz> ok. the test_complex should be working now
[22:29] <cfbolz> after I check in my change
[22:44] <hpk> i guess this evening is a good time to change the locations as i mentioned on pypy-dev
[22:44] <hpk> do you have an opinion about it?
[22:44] <cfbolz> sorry, didn't get that. locations?
[22:44] <hpk> my "restructuring lib-python-2.3.4" mail on pypy-dev
[22:45] <cfbolz> ah. I think it's a good idea.
[22:45] <hpk> actually i think we should just move to 2.3.5 while we are at it
[22:45] <cfbolz> yes.
[22:46] <cfbolz> should slower versions of tests be added if they take a long time for unimportant reasons (e.g. just long loops)?
[22:46] <cfbolz> s/slower/faster
[22:47] <hpk> hum, i guess so
[22:48] <cfbolz> ok. There are trivial division tests in test_complex which take very long
[22:49] pedronis (~Samuele_P@c-0f8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[22:49] <hpk> cfbolz: but make a clear note that this test was only modified for speed reasons
[22:49] <cfbolz> hpk: the note in conftest, yes?
[22:52] <hpk> if you add 'modified="speed"' to the testdeclaration then we can add a switch '--faster' which would choose the faster versions
[22:52] <cfbolz> ok.
[22:53] <cfbolz> are there any tests that are expected to be relatively easy to fix that I can try my hands on?
[22:54] <hpk> hard to tell before hand, maybe pedronis has something ready?
[22:55] <hpk> i guess i am not doing the lib-python-2.3.4 restructuring today
[22:56] <hpk> codespeak's repository doesn't have python-2.3.5 tracked right now
[22:57] <cfbolz> oh, it tracks python-2.3.4?
[22:57] <hpk> we have python releases in http://codespeak.net/svn/vendor/cpython
[22:57] <cfbolz> ah. Didn't know that.
[22:58] <hpk> it's not advertised but it's useful to have it in subversion for internal purposes :-)
[22:59] <cfbolz> :-)
[22:59] <cfbolz> know everybody can read it in the logs
[23:00] <cfbolz> s/know/now
[23:03] <pedronis> cfbolz: I don't know about low hanging fruit
[23:03] <pedronis> fruits
[23:03] <pedronis> it's all a bit messy
[23:04] <cfbolz> so should I rather do nothing or try to find something myself
[23:04] <cfbolz> ?
[23:04] <pedronis> well, test_scope seems sane
[23:05] <pedronis> but I have no idea why we die in the middle it
[23:05] <pedronis> some tests fail because our faking is not good enough
[23:05] <cfbolz> but I can't really fix that.
[23:06] <cfbolz> :-)
[23:06] <pedronis> no, that was an example of the messy stuff we are confronted with
[23:06] <cfbolz> ok
[23:06] <pedronis> for example test_iter mostly passes
[23:06] <pedronis> one failure maybe is sane but the last is about faking of files
[23:07] <cfbolz> what is a sane failure? not messy?
[23:09] <pedronis> well is not about converting exceptions around faking
[23:09] <pedronis> which seems one of the main problem we have with that
[23:10] <cfbolz> ok
[23:11] <cfbolz> thanks for the suggestions. I'll see whether I can fix something.
[23:11] <cfbolz> See you.
[23:13] <hpk> see you
[23:13] <cfbolz> g'night
[23:13] cfbolz (~cfbolz@wrz9-d9b95ec8.pool.mediaWays.net) left irc: "Verlassend"
[23:15] <hpk> pedronis: in some ways, i would like it if we had a single lib-python-2.3.4 tree
[23:15] <hpk> it would remove a lot of messyness
[23:16] <hpk> i mean a lib-python-2.3.4 tree that has modified files in it
[23:16] <hpk> it's trivial to write a tool that nicely lists all differences to the original
[23:16] <hpk> showing the log messages of the modifications
[23:17] <pedronis> it would create a lot of messyness when we are in the business of tracking an active pythonv version like 2.4
[23:17] <hpk> why?
[23:17] <hpk> i'd say with our current scheme we would create more messyness
[23:18] <hpk> what if we need to do different fixes for 2.3 and 2.4 (and 2.5) ?
[23:20] <pedronis> the problem is that you have you modified file and the new version changed on the pyhton branch but to get info about the original you have to play with revisions
[23:21] <hpk> sounds like a oneliner-merge
[23:23] <pedronis> but we stuff that may need to be completely changed
[23:23] <pedronis> vs. to CPython
[23:23] <pedronis> so there's mergeable stuff and noit
[23:24] <hpk> i am not sure i follow
[23:24] <ludal> if you (svn) move the files that are completely changed before rewriting it then svn merge should handle that no ?
[23:25] <hpk> ludal: if i understand your question right: yes
[23:27] <pedronis> hpk: we may for example need a version of inspect.py because for example our builtin look like normal functions that is not mergable anymore
[23:27] <ludal> so you can maintain different branches with original cpython versions, modified pypy versions for files that are either slightly modified and forbid merge on totally modified files by moving the root of the branch away
[23:28] <hpk> pedronis: ok, let's consider this example
[23:28] <hpk> ludal: subversion usually detects any conflicts
[23:28] <hpk> pedronis: if you just have pypy/lib/inspect.py and you switch lib-python from 2.3 to 2.4 or 2.5
[23:29] <hpk> it's unlikely that our inspect.py is still correct
[23:29] <hpk> and i'd argue you have to look at any differences anyway
[23:29] <pedronis> that's an orthogonal issue
[23:29] <pedronis> of course you have to look at the differences
[23:30] <ludal> sure but what pedronis is saying is that you will have to manually merge files that are totally modified (ie with conflict). on the other hand renaming inspect.py as inspect.py.orig and creating a new inspect.py will allow you to merge difference from cpython2.3.4->cpython2.3.4 to your branch without any conflict right ?
[23:30] <ludal> sorry that was ->cpython2.3.5
[23:30] <hpk> sorry, i am not following both of you currently :-)
[23:31] <hpk> i think there is a misunderstanding
[23:31] <pedronis> my point is that by not merging I both have the unmodified the modified version of the file around without having to play with revisions
[23:31] <hpk> well
[23:32] <hpk> if you have
[23:32] <pedronis> and on the other hand
[23:32] <hpk> lib/python-2.3.4
[23:32] <hpk> lib/python-2.4.1
[23:32] <hpk> lib/python-2.5.0
[23:32] <hpk> then if you want to merge the pypy-changes from 2.3.4 to 2.4.1
[23:33] <tic> Hrm. What is the real goal of PyPy again? Just as a "fun experiment" to write a compiler in its own language, or leaning more towards the hidden goal?
[23:33] <hpk> you do it by saying give me the diff from python-2.3.4 to its original branch point (--stop-on-branch or something)
[23:33] <hpk> tic: you have read the home page?
[23:33] <hpk> and then applying this pypy-diff to 2.4.1
[23:34] <hpk> basically
[23:34] <hpk> that is the one-liner-merge i meant
[23:35] <tic> hpk, yes, I did.
[23:35] <hpk> tic: so obviously we weren't clear enough :-)
[23:35] <tic> hpk, no, not really. Granted, you might have updated it a lot since when I read it about 5 months ago
[23:35] <ludal> hpk: yes; and the svn renaming tric will allow you to easily merge big modifications like pedronis was talking about
[23:36] <ludal> that was a trick no a tric..
[23:36] <hpk> tic: although the very first paragraph in http://codespeak.net/pypy should make it clear that is a quite a bit more than "just" a fun experiment
[23:36] <tic> hpk, well, the "secret goal" thing -- how strongly is that emphasized
[23:37] <tic> ?
[23:37] <hpk> ludal: i am not sure what you refer to with "renaming trick"
[23:37] <hpk> tic: i can't tell you, unfortunately :-)
[23:37] <hpk> tic: i would get shot, y'know
[23:37] <tic> hpk, ... uhm .... ?
[23:37] <ludal> ok; you want to merge pypy modification from python 2.3.5 to python 2.4.5 right ?
[23:37] <tic> that's basically why I'm asking you, because you're not being very clear.
[23:37] <pedronis> a secret goal should be kept secret
[23:37] <hpk> ludal: yes
[23:37] <tic> from what I can read on the web page, it's basically of academical interest.
[23:38] <ludal> but you can have files that are completely changed like inspet.py if I understood
[23:38] <tic> like, okay, we have something here that's pretty interesting, but doesn't yield any real-life value.
[23:38] <tic> sorry if I come off as a pessimistic jerk. I just want to know if I can get part of the action when it's done .:)
[23:38] <pedronis> not completely but no mergeable without getting tons of conflicts each time
[23:38] <ludal> so if in the pypy branch of 2.3.5 you rename inspect.py and create a new one; then the merge will do the same in the 2.4 orig branch and you don't have to resolve any conflict
[23:38] <tic> if the goal is to produce basically a research paper, then that's really fine with me. but if not, I want to know! :P. </spam>
[23:39] <hpk> tic: it's more than that, it's aimed to be a practically useful python implementation
[23:39] <hpk> ludal: ah, now i see what you mean, indeed
[23:39] <hpk> ludal: probably right
[23:39] <tic> hpk, couldn't you achieve the same thing with a cleaner rewrite/refactoring of CP?
[23:40] Action: tic reads more of the oscon2003 paper
[23:40] <hpk> tic: better read: http://codespeak.net/pypy/index.cgi?doc/coding-style.html#restricted-python
[23:41] <hpk> tic: which directly deals with your question
[23:41] <tic> hpk, thanks. *checking*
[23:41] <tic> maybe I'll see you guys at EP.
[23:41] <hpk> tic: sure
[23:41] <hpk> pedronis: but you didn't answer my original question:
[23:42] <hpk> how would you handle it if you needed different "pypy-fixed" things in pypy/lib?
[23:42] <hpk> for different python versions, i mean
[23:42] <pedronis> well, if you need that with more than one dir
[23:42] <pedronis> but remember that part of the reason for the separation
[23:42] <pedronis> is not to tempt people to change stuff
[23:43] <pedronis> too much
[23:43] <hpk> but it has always been messy and fragile IMO
[23:43] <hpk> and i think that we will want to change quite a few more tests
[23:44] <hpk> pedronis: are you actually implying that we will always only track one python version?
[23:45] <pedronis> it depends on the resources and what it involves
[23:45] <pedronis> but I fear yes
[23:45] <pedronis> for the project
[23:45] <pedronis> having to follow more than one version
[23:45] <pedronis> is very messy
[23:45] <pedronis> given that we have other things to achieve
[23:46] <pedronis> we probably need to switch to 2.4
[23:46] <pedronis> and stick with it
[23:46] <pedronis> after this release
[23:47] <hpk> probably right
[23:50] Action: hpk -> leaving
[23:54] <ludal> bye
[00:00] --- Fri Apr 29 2005