[00:59] stakkars (vjgmbn@dsl-62-220-9-123.berlikomm.net) joined #pypy.
----- silence for 4 hr and 19 minutes ----- [05:18] yuuh (uhxhae@dsl-62-220-9-123.berlikomm.net) left irc: "utz utz utz"
----- silence for 5 hr and 37 minutes ----- [10:55] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[10:57] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[10:58] hpk_ (~hpk@merlinux.de) joined #pypy.
[10:58] <hpk_> morning
[10:58] <arigo> morning
[10:59] <pedronis> morning
[11:00] <hpk_> so i guess we should come up with a plan
[11:00] <arigo> 1) finish to wake up
[11:01] <hpk_> 2) talk a bit about how we organize the next few days
[11:03] <hpk_> i think we have a number of issues to resolve, coding, website and otherwise
[11:04] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.
[11:04] <hpk_> hi anders
[11:04] <aleale> Hi sorry I am late
[11:05] <hpk_> dont worry
[11:05] <hpk_> i'd suggest to reinitialize the tracker after a round of comments from you
[11:05] <hpk_> and then start filling in issues for the release goal
[11:06] <hpk_> which i would consider 'M0.5' in milestone-terms
[11:07] <arigo> http://codespeak.net/issue/pypy-dev
[11:08] <arigo> redirects me to localhost:7502/pypy-dev??
[11:08] <hpk_> trailing slash
[11:08] <arigo> argh.
[11:08] <arigo> http://codespeak.net/issue/pypy-dev/
[11:08] <hpk_> roundup is very sensitive to this slash, and one has to insert apache rules to "fix" it
[11:13] Action: arigo playing a bit with roundup in links
[11:14] <stakkars> ooops, Hi! I set my alarm clock but forgot to activate it for Sundays
[11:15] <hpk_> hi christian
[11:15] <stakkars> hi holger
[11:15] <arigo> hi!
[11:16] <stakkars> hi. I hacked until early morning (yawn)
[11:17] <arigo> hpk_: sorry, roundup works very well in links once you're logged in
[11:17] <arigo> hpk_: it looks confusing before you log in because the fields (title etc) are displayed as plain text in this case, lost in the middle of the rest of the text
[11:18] <hpk_> arigo: yes, it doesn't look too good when not logged in
[11:19] <hpk_> should we go with my "keyword" suggestion?
[11:19] <hpk_> if you look at "keywords" you'll find all directory names at most two levels below pypy
[11:19] <stakkars> do we meet at pypy-tb at 11 (now), or did I mess up and can take a nap?
[11:20] <hpk_> we are meeting here
[11:20] <hpk_> i think we only need pypy-TB for possibly EU related internal discussions
[11:21] <hpk_> stakkars: but feel free to take a nap, anyway :-)
[11:22] <arigo> hpk_: and how do we use keywords?
[11:22] <hpk_> when creating an item (or editing it)
[11:22] <hpk_> you can assign one or more keywords
[11:23] <hpk_> it's pretty nice with a CSS/javascript browser
[11:23] <hpk_> not sure about links
[11:23] <arigo> ah, it's called "topics" there... (confusing :-)
[11:23] <hpk_> yes, i'll change that immediately
[11:24] <arigo> the keywords should be all subdirs excluding 'test' ones. e.g. translator/tool/pygame should be a keyword
[11:24] cfbolz (~cfbolz@hdlb-d9b95ef1.pool.mediaWays.net) joined #pypy.
[11:24] <cfbolz> morning all!
[11:24] <stakkars> moin
[11:24] <hpk_> hi!
[11:24] <arigo> even goal and lib-python too, so maybe start at dist/ instead of dist/pypy.
[11:24] <arigo> hi!
[11:25] <hpk_> arigo: makes for pretty long keywords
[11:25] <hpk_> arigo: we can manually modify/add keywords
[11:25] <arigo> ok
[11:25] <arigo> then e.g. genllvm would probably be better than translator/llvm
[11:26] <arigo> if we edit a keyword, does it change also on all issues that currently use it?
[11:26] <hpk_> yes
[11:26] <arigo> good :-)
[11:26] <hpk_> if we use just the plain exact directory names
[11:26] <hpk_> then it's always easy to guess what something is related to
[11:27] <hpk_> that's what i like about this more strict approach
[11:27] <hpk_> (or call it systematic)
[11:27] <arigo> fine
[11:27] <stakkars> I'm a bit confused by the 300 test issues. Where should I go?
[11:28] <hpk_> we were just talking about the general issue properties (hit 'create item' for example)
[11:28] Action: hpk_ is ready to reinitialize the tracker anytime
[11:29] <stakkars> ah, I didn't want to use "create"for just reading. but fine.
[11:30] <hpk_> we can further improve the tracker layout/properties after the release
[11:30] <hpk_> so i guess i just go ahead
[11:31] <stakkars> the keywords are basically flat and just structured by slash (directory names), right?
[11:31] <hpk_> right
[11:32] <hpk_> we can add custom keywords by time
[11:32] <hpk_> for example we could probably define '0.8' to mark issues as related to a certain release version
[11:33] <arigo> I see
[11:33] <hpk_> ok, should i reinitialize now?
[11:34] <arigo> go ahead.
[11:35] <hpk_> ok, done
[11:35] <hpk_> now is a good time to register that you want to receive any new issue item
[11:35] <hpk_> login and go to 'your details'
[11:35] <hpk_> and enter 'yes' into 'notify on new issues'
[11:37] <stakkars> can we change the server clock to GMT+1?
[11:38] <hpk_> you can set your timezone in 'your details'
[11:38] <stakkars> ah
[11:39] <stakkars> still confusing, with 1, it is still an hour off.
[11:40] <hpk_> where is it an hour off?
[11:41] <stakkars> the log of my time change. After I updated my email, it showed 9:35, after adjusting tz it showed 10:40, but still.
[11:41] <arigo> summer time, we need +2 ?
[11:41] <cfbolz> seems like it
[11:41] <stakkars> I guessed that would be done automatically, but well.
[11:45] <arigo> summer time dates vary from place to place, so the server can't guess based only on information like "+1"
[11:45] <arigo> e.g. only very recently has England decided to change at the same time as the rest of Europe ;-)
[11:46] <stakkars> I see. So roundup should provide daylight savings date entries. well...
[11:47] <arigo> well you could provide a drop-down list of timezones... but anyway
[11:47] <stakkars> let's start.
[11:47] <hpk_> did everybody who registered with "notify on new issues" just receive a mail?
[11:47] Action: stakkars needs coffee
[11:47] Action: hpk_ added an issue
[11:48] <cfbolz> I did
[11:48] <arigo> yes
[11:48] <stakkars> I don't know, too much spam...
[11:48] <stakkars> yes!
[11:49] <hpk_> note that you are not on the nosy list
[11:49] <hpk_> you just received the top-level new item
[11:49] <hpk_> if you want to follow that issue you need to
[11:49] <hpk_> either reply by mail commenting on it
[11:49] <hpk_> or you go to the web page and just add yourself
[11:50] <hpk_> the nosy list's addresses will receive mails from updates to the item
[11:50] <aleale> I got it
[11:52] <cfbolz> you can also reply to the mail and put a [nosy=+username] at the end of the subject line
[11:52] <cfbolz> (if you don't like the web interface)
[11:52] <hpk_> cfbolz: yes, although that should be redundant if i did the configuration right
[11:53] <stakkars> cfbolz: does this also work without adding a comment, just replying for the nosy entry?
[11:53] <cfbolz> stakkars: yes thats the point
[11:53] <hpk_> cfbolz: i am not sure if that doesn't show up as a new message
[11:53] <hpk_> have you tried?
[11:53] <cfbolz> i can try
[11:54] <cfbolz> yes works
[11:55] <cfbolz> empty message body does the trick
[11:56] <stakkars> so how empty? Do I need to wipe my .sig away? and syntax again [nosy=+username] is correct?
[11:56] <arigo> doesn't work for me: I get an e-mail back saying "You are not permitted to edit issue."
[11:56] <hpk_> arigo: you need to register your email address
[11:56] <hpk_> as an alternate address
[11:56] <arigo> ahh, thanks
[11:56] <hpk_> because roundup only allows registered users to mailin
[11:57] <hpk_> (well i configured it this way but otherwise you get lots of spam)
[11:58] <arigo> makes sense (works thanks)
[11:58] <pedronis> hpk: do you know of a criteria that works for consistetlly filtering (I want my e-mail program to put them in their own folder) tracker messages
[11:58] <arigo> well, now I'm confused by issue1 whose web page nosy list doesn't include arigo, but whose history says nosy: +arigo
[11:59] <hpk_> it does for me
[11:59] <cfbolz> pedronis: I think the tracker puts a signature there:
[11:59] <cfbolz> PyPy development tracker <pypy-dev-issue@codespeak.net>
[11:59] <cfbolz> <https://codespeak.net/issue/pypy-dev/issue1>>
[12:00] <arigo> hpk_: it seems reloading is not enough, I need to shut down and restart links :-( :-(
[12:00] <stakkars> arigo: it does
[12:01] <arigo> stakkars: yes, I see it too now that I restarted by browser
[12:01] <stakkars> browser issue?
[12:01] <hpk_> arigo: does links have some kind of more forceful reload?
[12:01] <arigo> I'm confused because I tried to flush all caches
[12:02] <hpk_> arigo: there are no custom caching directives on the delivered html
[12:02] <arigo> but most of all it's strange that the same web page contained the correct history and the wrong text field
[12:02] <stakkars> is links a browser?
[12:02] <arigo> stakkars: yes
[12:02] <cfbolz> maybe links tries to preserve the text in forms
[12:03] <arigo> cfbolz: ah, could be
[12:03] Action: stakkars makes coffee
[12:03] <hpk_> ok, so everybody: just file issues away or raise issues here on IRC, i'd say
[12:05] <hpk_> aleale: if you use the email-in feature for adding yourself to the nosy list it's a good idea to have a completely empty body (or use the web page if you can't do that)
[12:06] <hpk_> arigo, pedronis: for example, you could file issues for compliance test failures that should be fixed
[12:07] <hpk_> i think it's a bit of overhead to structure all work-to-do with the tracker but it should be well worth it, i think
[12:07] <aleale> I just noticed - I have deleted the bogus message
[12:11] <stakkars> I don't seehow the keywords are used. They don't show up in the issues list.
[12:12] <stakkars> I hoped they would become some grouping or tree-like thing, no?
[12:12] <hpk_> not currently
[12:12] <stakkars> (just fearing that we get a flat 500 entry list which cannot be managed)
[12:13] <hpk_> you can define a search query relating to the keyword 'translation' for example
[12:13] <cfbolz> you can even save it for future use
[12:13] <hpk_> i am pretty sure that there are lots of things that can be improved with the tracker, btw
[12:14] <hpk_> but i think we should try to focus on the actual content now
[12:14] <stakkars> focusing was my intent
[12:15] <stakkars> I think we should discuss the major things to be done here, first
[12:16] <stakkars> I mean, how the release should look like, what's missing, and such?
[12:17] <hpk_> makes sense
[12:18] <stakkars> just consider you would want to make a release, today. What would stop
[12:19] <stakkars> you from it --> say it.
[12:20] <hpk_> e.g. an announcement text, the question how we package pypy, a first download scheme
[12:20] <hpk_> seeing if we can reach the 90% compliancy goal
[12:21] <hpk_> i.e. examine each test failure
[12:21] <arigo> setup.py or no setup.py?
[12:21] <stakkars> go through all directories and see if the files are relevant or confusing.
[12:22] <hpk_> i guess that setup.py does not really make sense at the moment, or does it?
[12:22] <stakkars> (at the moment it is not clear to me if genc stuff is superseded by new files)
[12:23] <cfbolz> hpk_: not really, the release is more for playing around than for anything productive
[12:24] <stakkars> we need a toplevel README guide and an easy to use folder for py.py etc.
[12:25] <hpk_> i think it is a good idea to just file all these little issues and then we make a round of assigning the tasks :-)
[12:26] yuuh (cwengw@dsl-62-220-9-123.berlikomm.net) joined #pypy.
[12:26] <stakkars> I think we need to clarify again what exactly the release should/must provide and what not.
[12:28] <hpk_> a PyPy interpreter prompt, very compliant to CPython
[12:28] <tic> Nearing a release?
[12:28] <hpk_> the release is mainly a public signal that have crossed a certain barrier
[12:28] <stakkars> yes, we want to relase in a week
[12:28] <tic> that -you- have?
[12:29] <hpk_> tic: yes
[12:29] <arigo> hpk_: yet another roundup question: can I receive e-mails for issue entries between the 1st and the time I nosify myself?
[12:29] <hpk_> arigo: not easily, although it should be possible to hack it
[12:29] <stakkars> yes I would prefer to be auto-nosed.
[12:30] <cfbolz> me too.
[12:30] <arigo> I guess me too
[12:30] <arigo> :-)
[12:30] <tic> What's this barrier you've crossed?
[12:30] <cfbolz> we are about to pass the 90% test compliance barrier
[12:30] Action: hpk_ sees if he can satisfy the "i want to receive every message" crowd
[12:31] <cfbolz> tic: meaning CPython tests excluding those that rely on external libraries
[12:31] <stakkars> around 90% of complicance, plus some internal convincement that "we can make it" :-)
[12:31] <tic> cfbolz, sweet.
[12:31] <tic> how's speed? 0.1?
[12:32] <stakkars> 0.0005
[12:32] <cfbolz> :-(
[12:32] <tic> ouchie.
[12:32] <hpk_> not surprising if you consider that we run on top of CPython
[12:33] <cfbolz> I guess we also want the public to bang a bit on PyPy and use it in unexpected ways
[12:33] <hpk_> yes, thunk object space and traceinteractive comes to mind
[12:33] <tic> hpk_, oh, thought you ran it through the RPython core
[12:33] <cfbolz> not finished yet
[12:33] <tic> that would speed things up, I assume.
[12:33] <stakkars> it is surprizing in the first place. In terms of abstraction and complexity, we have
[12:34] <stakkars> in a sense stacked Python just twice.
[12:34] Action: hpk_ concludes that he is not going to implement the nosy-me-always feature right away
[12:35] <tic> stakkars, indeed.
[12:35] <stakkars> well, sorry, not really. But in a straight-forward, speed oriented impl, I would expect a factor of 100-200
[12:35] <tic> stakkars, so then you'll be running at ~0.1 of CPython? :)
[12:39] <stakkars> ?? No, I would expect this slowdown instead of ten more, we just have a lot of abstraction to pay for
[12:39] <tic> okay, now I don't understand.
[12:39] <tic> you said you have 0.0005 of CPython now, and by speeding up by a factor 100-200 you'd get 0.1
[12:40] <stakkars> and this happens at run-time at the moment. An object space for instance should turn itself into something
[12:40] <stakkars> else after it was choosen.
[12:41] <stakkars> tic: we need to stop this now, there are other issues. What I said was a comparison of our implementation and a virtual, less abstract one.
[12:42] <arigo> we still have no clue about the speed of the translated PyPy -- testing with pystone is not representative of anything :-)
[12:42] <tic> :)
[12:43] <cfbolz> should I mark documentation errors as "bugs"?
[12:43] <stakkars> arigo: no, I just said that after translation, we still have a huge overhead which will not vanish without extra transformations
[12:44] <stakkars> notmaking any promises here, if I sounded this way. Other way round.
[12:44] <hpk_> cfbolz: yes
[12:52] <cfbolz> hpk_: how exactly are milestone handled in the tracker? Why is current not the same as M0.5?
[12:52] <hpk_> 'current' basically means that the user didn't supply a milestone
[12:53] <hpk_> could be called differently i guess
[12:54] <cfbolz> ah, ok. I guessed that it would automatically assign it to some specific milestone
[12:54] <hpk_> often we may just have issues floating around (for the immediate future) without caring to tie them to a specific milestone
[12:55] <cfbolz> yes, of course. I was just making guesses.
[12:55] <hpk_> sure
[12:56] <hpk_> cfbolz: your test results often seem to result in a 'copy_reg' problem
[12:56] <hpk_> at one point you had 10 more tests failing than me
[12:56] <hpk_> but i couldn't figure out at the time where there was a difference (maybe it was just an intermediate commit problem)
[12:57] <cfbolz> hpk_: yes, sorry for checkin this in (At one point all my tests failed due to that).
[12:57] <cfbolz> The problems vanished when I deleted _cache and the pyc files
[12:59] <cfbolz> not sure which of them caused the problem
[12:59] <cfbolz> btw: maybe it's a good idea to point that out in the to be written README.
[12:59] <arigo> some roundup e-mails are sent with the correct headers to make them threaded in a mailbox; others are not -- no clue what the pattern is
[13:00] <hpk_> arigo: easy:
[13:00] <hpk_> when you reply by mail then you directly send the mail (not through the tracker, so they don't get special headers)
[13:00] <hpk_> when you update through the webpage then you get proper headers
[13:00] <hpk_> you really need to filter on 'pypy-dev-issue@codespeak.net' in the recipient list
[13:01] <arigo> yes I do that
[13:01] <hpk_> that should also answer pedronis earlier question
[13:01] <hpk_> arigo: oh, and it doesn't filter correctly?
[13:01] <arigo> I didn't talk about filtering
[13:01] <hpk_> ups, sorry
[13:02] <arigo> only about e-mails showing up as a single "thread"
[13:02] <hpk_> i just read 'correct headers' and stopped reading to quick :-)
[13:02] <hpk_> arigo: yes, that's a bug/missing-feature in roundup IMO
[13:02] <hpk_> it doesn't artificaally set email-headers from the web-interface that would allow email readers to thread things nicely
[13:03] <arigo> aaah, ok I see
[13:03] <hpk_> if you care, then file an issue and assign it to me, i wanted to fix this for along time
[13:03] <arigo> :-)
[13:04] <hpk_> it shouldn't be too hard and would be very convenient because then mailboxes could present a nice full view of all issues (and you don't need to use the webinterface much)
[13:05] <arigo> yes, in addition to the alwaysnosy flag you wouldn't need it much any more
[13:06] <cfbolz> hpk_: Did you send your mail re windows compatibility via the web interface?
[13:06] <hpk_> cfbolz: no, through email, i think
[13:07] <cfbolz> because 'pypy-dev-issue@codespeak.net' doesn't seem to appear in the recipient list
[13:07] <cfbolz> so my filter didn't get it
[13:08] <stakkars> so how do I reply?
[13:09] <hpk_> cfbolz: are you checking TO and CC?
[13:10] <cfbolz> yes.
[13:11] <hpk_> cfbolz: all the mails i see do have pypy-dev-issue in either of them
[13:11] <cfbolz> Arrgh! I got it. the filter was incorrect and the TO read 'Christian Tismer <pypy-dev-issue@codespeak.net>'
[13:11] <cfbolz> and I stopped reading at christian :-)
[13:12] <hpk_> yes, roundup should allow to prefix the realnames (it only allows postfixes, currently)
[13:12] <hpk_> stakkars: either by email or through the web interface or am i misunderstanding your question?
[13:12] <stakkars> how do I reply correctly, please? Concerning the reply-to, whom should I include?
[13:13] <hpk_> if you have a group-reply in your mail-reader that's safest
[13:14] <hpk_> just make sure that the pypy-dev-issue mailaddress is in TO or CC
[13:14] <hpk_> you don't need to include or exclude anyone manually
[13:15] <stakkars> that's it. If I only use that it is ok? My habit is to always use reply to all, but that will duplicate, right?
[13:15] <cfbolz> no
[13:15] <hpk_> i guess just hitting 'Reply' also works
[13:15] <cfbolz> roundup only sends mails to people that are not in the CC list
[13:15] <hpk_> exactly
[13:15] <cfbolz> so reply to all is ok
[13:16] <stakkars> thanks, *that* was the answer.
[13:17] <arigo> (of course I'm getting duplicates then, because I told roundup to use arigo+pypyissues@codespeak.net as my address, but actually I want duplicates in this case)
[13:20] stakkars_ (eehmbdhj@i528C1F21.versanet.de) joined #pypy.
[13:23] <arigo> we should decide if the focus of the release is py.py, or if we also want the translator available in a reasonable form to play with
[13:23] <hpk_> indeed
[13:23] <arigo> I guess we should not try to make translate_pypy.py official at this point
[13:24] <cfbolz> yes but it would be cool to at least be able to play around with the translator and compile some simple snippets
[13:24] <arigo> yes
[13:25] <hpk_> we could make this a june release, though
[13:26] <hpk_> (but i am fine with trying it for next week's release)
[13:28] <cfbolz> It's probably not much more work than writing a bit documentation of point to getting-started
[13:28] stakkars (vjgmbn@dsl-62-220-9-123.berlikomm.net) left irc: Read error: 60 (Operation timed out)
[13:29] <hpk_> ok, file an issue relating to the getting_started document then?
[13:29] <cfbolz> I can add it to my README issue
[13:29] <stakkars_> everything that uses flow space is a problem right now when not running just a dos shell
[13:30] <arigo> stakkars_: including the automatic geninterp ?
[13:30] <cfbolz> because of PythonWin?
[13:30] <stakkars_> cfbolz: yes
[13:31] <stakkars_> arigo: it depends on what you touch. Basically we need to enhance sys.stdin and friends handling.
[13:32] <stakkars_> probably not that big issue but necessary.
[13:35] yuuh (cwengw@dsl-62-220-9-123.berlikomm.net) left irc: Read error: 110 (Connection timed out)
[13:40] <cfbolz> ok. I'm going offline (it's getting expensive). I will be reading the IRC logs and issues. See you.
[13:40] <arigo> see you!
[13:40] <hpk_> cfbolz: see you!
[13:41] <hpk_> i guess we should start assigning issues to us
[13:42] cfbolz (~cfbolz@hdlb-d9b95ef1.pool.mediaWays.net) left irc: "Verlassend"
[13:42] Action: arigo started on issue12
[13:44] Action: stakkars_ would like to stop everybody from working onj anything but finishing the current issues and the meeting
[13:46] <stakkars_> hi all, can you please stop working on the issues?
[13:46] Action: hpk_ is not so much thinking of being in a meeting, rather than being at the start of a multi-day session
[13:47] <stakkars_> we decided to have a kick-off structuring meeting. At some time, I'd like to be able to leave the house :-)
[13:47] <hpk_> i agree
[13:47] <arigo> so is the question if we have more issues to file now?
[13:47] <hpk_> yes, any major issues at least
[13:48] <hpk_> 'writing a release announcement' comes to mind (i am filing it)
[13:50] <stakkars_> we must be missing something. In a way, the list looks quite tiny for a multi-day session.
[13:51] <stakkars_> Are there things which hide huge amounts of work under an innocent phrase?
[13:51] <arigo> there are general "clean this up" issues
[13:52] <stakkars_> what we should do is to estimate how much work this is.
[13:52] <hpk_> stakkars_: indeed, if we all work on it we could be finished on tuesday or wednesday i guess
[13:52] <hpk_> we should be able to just start working on the issues
[13:52] <hpk_> and decide while going if we postpone it to M1.0 if it's too much work
[14:00] <hpk_> arigo: if you fix test_mutants.py, try out the svn-checkin-issue-resolving feature :-)
[14:02] <stakkars_> well, there are some which hide some work, like my "every file should tell its purpose and main dependencies"
[14:02] <arigo> hpk_: ok :-)
[14:06] <hpk_> i'd like to go to a lunch break ...
[14:06] <hpk_> do we need to discuss anything major here?
[14:07] <stakkars_> no, well, how do we track issues which are not clearly defined
[14:07] <hpk_> discuss them here, i guess
[14:07] <stakkars_> I mean how do we find out if an issue like "fix documentation"
[14:08] <stakkars_> is resolved, and how do we split tasks to avoid duplicate work?
[14:08] <hpk_> yes, i think issues should try to be as specific as possible
[14:08] <stakkars_> no, you can't do that.
[14:09] <hpk_> you can't try to be as specific as possible?
[14:09] <stakkars_> if we for instance want to check that every source file has a sensible docstring at its
[14:09] <hpk_> regarding "split tasks": we should assign tasks to people
[14:09] <arigo> one person should assign it to himself for a while, and then possibly other people can discuss with him (here or in the issue itself) how to share tasks
[14:09] <stakkars_> top, you will probably not create 250 issues and assign them to people.
[14:10] <stakkars_> instead I would try to split this directory-wise and let people assign to that.
[14:10] <arigo> well just telling about it should be enough, no need to make many issues
[14:10] <arigo> as long as one person takes a temporary "coordinating" role by assign to himself
[14:11] <stakkars_> that means if I assign "add docstrings" to myself, this would ensure avoiding duplicate work? :-)
[14:11] <hpk_> sounds sensible
[14:12] <arigo> stakkars_: yes, and then push other people into specific subdirs until there's none left :-)
[14:12] <hpk_> yes, e.g. "add docstrings to interpreter/modules"
[14:13] <stakkars_> ok, this makes sense.
[14:15] Action: stakkars_ out for lunch
[14:23] Action: hpk_ -> lunchbreak
[14:25] mwh2 (~user@195.10.250.235) joined #pypy.
[14:30] <hpk_> arigo: i just tried to switch the ">" roundup-parsing magic off (now i am really off ...)
[14:31] <arigo> thanks!
----- silence for 28 minutes -----
[14:59] <arigo> check-in message for r12286 (issue7 resolved) has strange effects
[15:00] <arigo> I got an e-mail from the tracker, with status: unread -> chatting (uh?), but the web tracker doesn't seem to be updated at all and doesn't contain the message either
[15:15] mwh2 (~user@195.10.250.235) left irc: "bye"
[15:18] yuuh (rfsttxhe@i528C1F21.versanet.de) joined #pypy.
----- silence for 32 minutes -----
[15:50] <hpk_> arigo: strange, lemme check
[15:56] <arigo> hpk_: ouack
[15:56] <hpk_> yes, i noticed there is a problem.
[15:56] <hpk_> apprently the backend has a problem
[15:57] <arigo> I just received an e-mail again with my log message, this time status: resolved -> chatting
[15:57] <arigo> ('resolved' was put by hand on the web interface)
[15:58] <hpk_> arigo: yes, the svn-triggering script causes as error
[15:58] <hpk_> and probably leaves the tracker in a somewhat inconsistent state
[15:58] <hpk_> it's apparently related to the choice of backend
[15:58] <hpk_> (which is suprising, that's why i didn't think of re-testing the svn-functionality while switching backends)
[16:02] <hpk_> arigo: i am hijacking issue7 now (put you off the nosy list) in order to test it with your checkin message
[16:02] <arigo> ok
[16:10] <hpk_> i'd like to exchange the backend to see if that helps
[16:11] Action: hpk_ is doing that now
[16:13] cfbolz (~cfbolz@hdlb-d9b95ecb.pool.mediaWays.net) joined #pypy.
[16:13] <cfbolz> is anybody working on getting_started?
[16:13] <cfbolz> otherwise I would try to improve it a bit.
[16:13] <hpk_> i don't think so
[16:14] <hpk_> the tracker is down, i'll post a note when it's up again
[16:14] <cfbolz> is it ok to link to the to be written download page and remove the line "there is no release yet"?
[16:18] <cfbolz> just write an answer if neccessary, I'll read the logs.
[16:18] cfbolz (~cfbolz@hdlb-d9b95ecb.pool.mediaWays.net) left irc: "Verlassend"
[16:20] <hpk_> arigo: i changed backends (which had its own quirks, oh well) and tested, it works now: https://codespeak.net/issue/pypy-dev/issue7
[16:20] <hpk_> now correctly processes the commit message
[16:21] <hpk_> so svn-notification is really backend dependant and you are saying that the py lib is messy in parts? :-)
[16:21] <arigo> ah, now sorting by ID does an alphabetical sort, i.e. 9 > 10
[16:21] <arigo> messy :-)
[16:23] <hpk_> what's worse though, is that a failure in the script leaves the db in an inconsistent state so that when you export/import the db it fails :-(
[16:23] <hpk_> so i guess we are going with the anydbm backend (which is much slower so that will become an issue over time)
[16:24] <arigo> :-(
[16:31] <hpk_> i wrote richard jones a mail describing the problem
[16:31] <hpk_> for small numbers of issues i don't think it's a noticeable deal
[16:42] Action: stakkars_ back
----- silence for 1 hr and 2 minutes -----
[17:44] <stakkars_> somebody must have checked in some change that breaks geninterp.
[17:44] <stakkars_> somce code compiled by nicecompile that can't be literally found in its source.
[17:45] <stakkars_> this is from today. Any idea?
[17:48] <arigo> no other information?
[17:48] <arigo> you can always try to locate the precise revision number...
[17:49] <stakkars_> I thought to just save time because I don't know what I'm searching for. But ok, already at it
[17:54] <stakkars_> hum, it was a cache effect. how can that be.
[17:56] <arigo> hum.
[17:56] <arigo> did you keep the broken cache around?
[17:56] <stakkars_> no, unfortunately I just killed it, after I could not reproduce the effect.
[17:58] <stakkars_> the effect was that nicecompile could not find a pice of code in a source file.
[17:59] <stakkars_> not sure if I ran svn up during compilation. It is unlikely but possible that I changed source during that :-)
[18:04] <arigo> right, we already realized that changing sources during py.py startup -- or starting py.py twice in parallel -- could have bad effects on the cache
[18:08] <stakkars_> starting twice - what does it change?
[18:11] <arigo> the two processes write into the same file in parallel
[18:12] <arigo> hum, not exactly sure
[18:12] <arigo> I have a lot of .py files in my _cache which have no corresponding .pyc file -- any clue?
[18:14] <stakkars_> maybe you just killed al .pyc files, and only the current versions of the py files get compiled
[18:14] <stakkars_> whenever the code changes, there is a new file name
[18:16] <arigo> ah right, there is this py.cleanup tool which removes all pyc files
----- silence for 47 minutes -----
[19:03] Action: arigo and pedronis adding support for writing to __class__ and __bases__...
[19:15] Action: hpk_ hacking doctest support into text files (mostly works, except for >>>> prompts)
[19:22] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
[19:24] yuuh (rfsttxhe@i528C1F21.versanet.de) left irc: "utz utz utz"
[19:26] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 55 minutes -----
[20:21] stakkars (fgmwlnvi@i3ED6B62D.versanet.de) joined #pypy.
[20:24] <arigo> we found a way to create in CPython a class Y(X) where the metatype of Y doesn't inherit from the metatype of X
[20:24] <arigo> but I can't seem to find a way to crash CPython using that ;-)
[20:26] <stakkars> huh!
[20:29] stakkars_ (eehmbdhj@i528C1F21.versanet.de) left irc: Read error: 60 (Operation timed out)
[20:33] cfbolz (~cfbolz@hdlb-d9b95e95.pool.mediaWays.net) joined #pypy.
[20:33] <cfbolz> is the tracker working again?
[20:34] <arigo> yes
[20:38] <cfbolz> ah, the link in getting-started is wrong
[20:50] <arigo> oups
[20:50] <arigo> someone forgot to run py.test -R in the documentation directory?
[20:51] yuuh (zkzplpel@i3ED6B62D.versanet.de) joined #pypy.
[20:56] cfbolz_ (~cfbolz@hdlb-d9b95ee2.pool.mediaWays.net) joined #pypy.
[20:56] <cfbolz_> well, I should have done it, since i reworked getting_started a bit :-)
[20:56] <cfbolz_> arigo: t.ccompile() seems to fail if you run it twice (some compiler error).
[20:58] <stakkars> cfbolz: I guess this thing is not made for being run twice
[20:58] <cfbolz_> yes, I guess so, too.
[20:59] <cfbolz_> I was just wondering
[20:59] <cfbolz_> no real complaint
[20:59] <arigo> yes, I remember some strange thing like that
[20:59] <cfbolz_> (you can't even print the LLVM source and compile it with LLVMGenerator)
[21:04] cfbolz_ (~cfbolz@hdlb-d9b95ee2.pool.mediaWays.net) left irc: "Verlassend"
[21:16] cfbolz (~cfbolz@hdlb-d9b95e95.pool.mediaWays.net) left irc: Read error: 113 (No route to host)
[21:22] mwh (~user@pc150.maths.bris.ac.uk) left irc: "bye"
[21:25] <stakkars> arigo:for what reason does basetype.CType need the translator in the constructor?
[21:26] <stakkars> this stops me from pickling flowgraphs
[21:26] <arigo> CType is kind of deprecated now...
[21:26] <stakkars> but still used.
[21:26] <arigo> because it's cached on the translator instance
[21:27] <arigo> it's heavily used by some subclasses of CType, e.g. in pyobjtype.py
[21:27] <arigo> at this moment you should pickle before specializing
[21:27] <stakkars> if that object doesn't get pickled, it would notwork?!
[21:27] <arigo> and specially not after specializing with GenCSpecializer, which goes away
[21:27] <stakkars> ahh, oh. I thought -no-c was just ok
[21:28] <arigo> no, for now it's -no-t
[21:28] <stakkars> ahh, I see. no typer, *but* annotation. fine :-)
[21:28] <arigo> yes. and we're interested in pickling just before specializing because that's what we are working on, basically.
[21:29] <stakkars> then let me see. The basic things seem to work. (want to finish this, starting with the release stuff tomorrow morning)
----- silence for 33 minutes -----
[22:02] mwh (~user@s239-2.nomadic.bris.ac.uk) joined #pypy.
[22:17] <arigo> mwh: just for fun, Samuele gets assert errors in Python 2.3.0 on his Mac
[22:18] <arigo> about GC_ref untrack whatever
[22:18] <mwh> really?
[22:18] <mwh> when running the pypy tests or what?
[22:19] <arigo> absolutely no clue about this one -- it's py.test test_descr.py, but crashes after 2 seconds already
[22:19] Action: mwh is amusing himself by running nmap at hosts that seem to really want to ssh in as root
[22:20] <mwh> well, test_descr.py from 2.3.4 contains all kinds of tests for bugs fixed in earlier 2.3's
[22:20] <mwh> so this isn't surprising
[22:20] <mwh> hang on
[22:20] <mwh> let me think about this a sec :)
[22:20] <arigo> maybe, but it's running at py.py level :-)
[22:20] <mwh> yeah :)
[22:21] <arigo> unrelatedly, we found a way in CPython to build a class X(Y) whose metaclass is not a subclass of type(Y)
[22:21] <arigo> but didn't find a way to crash CPython using that...
[22:21] <mwh> uh
[22:21] <mwh> is that hard?
[22:22] <mwh> i know it takes a bit of effort...
[22:22] <arigo> not at all: change the __bases__...
[22:22] <arigo> there is no check about metaclass consistency in there.
[22:22] <arigo> in addition, I guess you can also change the __class__ of the class X itself somewhat freely among strict subclasses of 'type'.
[22:23] <arigo> yes, that works too.
[22:25] <mwh> oh good then it's not just because of me :)
[22:28] <mwh> test_descr w/2.3.0 doesn't appear to be crashing for me
[22:32] <mwh> taking a while, though :)
[22:34] <arigo> yes
----- silence for 37 minutes -----
[23:11] mwh (~user@s239-2.nomadic.bris.ac.uk) left irc: "bye"
----- silence for 28 minutes -----
[23:39] cfbolz (~cfbolz@hdlb-d9b9469b.pool.mediaWays.net) joined #pypy.
[23:40] <cfbolz> stakkars: I just checked in a fix (somewhat hackish) to make test_complex pass for me under windows 2000
[23:40] <cfbolz> Could you try whether it works for you too?
[23:45] <stakkars> yes. which folder was it?
[23:46] <cfbolz> it's an official CPython test: lib-python/2.3.4/test
[23:49] <stakkars> duuh, that takes long. There was another pypy test that broke on complex
[23:50] <cfbolz> where?
[23:50] <stakkars> that was the question :-)
[23:50] <cfbolz> maybe module/test/test_complexobject.py?
[23:51] <stakkars> yeah!
[23:51] <cfbolz> I think that's a something rather oldish
[23:52] <stakkars> wrong, anyway
[23:52] <stakkars> running your test meanwhile, it takes looong
[23:53] <stakkars> (should take complex, right?)
[23:53] <cfbolz> ah, there's a modified version of it, are you using that?
[23:54] <stakkars> not explicitly, I tried to run the original, but test_all automatically switched me.
[23:54] <cfbolz> good. should not take much more than a few minutes
[23:55] <cfbolz> test_complexobject.py fails for you?
[23:55] <stakkars> it did lat time
[23:55] <stakkars> last
[23:56] <stakkars> because of machine-specific coding of inf and such
[23:56] <cfbolz> I tried to fix that
[23:57] <cfbolz> Would you try it, too (should be fast, it does not run on PyPy but rather uses our complex module on CPython)
[23:57] <stakkars> yay, seems to work now :-)
[23:57] <cfbolz> good. My solution is probably not very portable, but I guess Linux and Windows on x86 is good enough for now
[23:58] <stakkars> hee hee, I just saw it :-)
[23:58] <cfbolz> :-)
[23:59] <stakkars> s/ :-) / :-)) /
[23:59] <cfbolz> Well, it works. It's not really clear how we want to access float details from PyPy applevel
[23:59] <stakkars> yep, everything passed.
[23:59] <cfbolz> Thanks a lot. I'm off. see you tommorrow.
[23:59] <arigo> see you!
[00:00] --- Mon May 16 2005