[00:55] stakkars (upbnqz@dsl-62-220-10-104.berlikomm.net) joined #pypy.
----- silence for 1 hr and 10 minutes ----- [02:05] yuuh (apbldy@dsl-62-220-10-104.berlikomm.net) joined #pypy.
----- silence for 41 minutes ----- [02:46] stakkars (upbnqz@dsl-62-220-10-104.berlikomm.net) left irc:
----- silence for 24 minutes ----- [03:10] yuuh (apbldy@dsl-62-220-10-104.berlikomm.net) left irc: "utz utz utz"
[03:13] idnar (mithrandi@idnar.user) left irc: Read error: 145 (Connection timed out)
----- silence for 1 hr and 46 minutes ----- [04:59] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 3 hr and 36 minutes ----- [08:35] idnar (mithrandi@idnar.user) joined #pypy.
----- silence for 2 hr and 24 minutes ----- [10:59] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[11:00] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Client Quit
[11:00] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[11:03] <hpk> arigo: hi armin
[11:03] <arigo> hi!
[11:04] <hpk> do you like the new test result page?
[11:05] <hpk> (in case you have seen it already, anyway)
[11:05] <arigo> nice
[11:05] <arigo> you're using remix.py?
[11:05] <hpk> no
[11:06] <hpk> genreportdata.py and and htmlreport.py/index.cgi
[11:06] <hpk> all in the base result directory
[11:07] <arigo> ok, you're using the same trick of comparing revision numbers to get the latest
[11:08] <arigo> Samuele and me wanted to go over the list and categorize as you mention.
[11:08] <hpk> those categorizations should be in conftest.py, btw
[11:08] <arigo> yes
[11:08] <arigo> with new flags, I guess
[11:09] <hpk> i think the 'enabled' thingie looses its signifance
[11:09] <arigo> indeed.
[11:09] <hpk> one thing: we shoulid modify the default test run
[11:10] <hpk> to produce pure mime type messages
[11:10] <hpk> for htmlreport.py i simply use rfc822.Message()
[11:10] <hpk> at the same time we should not write out test results with real keyboard interrupts
[11:10] <hpk> if feasible
[11:11] <hpk> IOW, we should write the result into some temp directory and only write it to the real location if is sane
[11:11] <arigo> why?
[11:11] <hpk> you get bogus test reports otherwise
[11:12] <hpk> when i say 'py.test -D'
[11:12] <hpk> then ctrl-c
[11:12] <hpk> then 'py.test'
[11:12] <hpk> the test___all___.py will have bogus results
[11:12] <arigo> ah, sorry, I see
[11:12] <hpk> the mime format is just nice, because parser can dispatch on testreport-version
[11:13] <hpk> and the detailed test run works pretty nicely except for doctests (which are almost there, as well)
[11:13] <arigo> do you want to move the files around now?
[11:13] <hpk> makes sense
[11:14] <hpk> oh, i have to tell you what the apache problem was yesterday:
[11:14] <arigo> that's what is keeping us back for now :-)
[11:14] <arigo> yes?
[11:14] <hpk> sure, may i tell the apache thingie before?
[11:14] <arigo> yes
[11:14] <hpk> i needed to recompile apache to allow ~public_html/ cgi scrripts of users to execute SUEXEC (under their user rights)
[11:14] <hpk> so i reinstalled apache
[11:15] <hpk> reemergerd rather
[11:15] <hpk> this broke apache: it didn't have any mod_* anymore
[11:15] <hpk> now after three hours of tracking it down:
[11:15] <hpk> bash 3.0.15 or apparently introduced a new ENV variable
[11:15] <hpk> called 'CMD'
[11:15] <hpk> it is set automatically after each command executes
[11:15] <hpk> and the apache build process had this in one of its many helper scripts:
[11:16] <hpk> CMD = `construct command`
[11:16] <hpk> echo $CMD
[11:16] <hpk> $CMD || die "..."
[11:16] <hpk> which resulted in a simple no-op :-(
[11:16] <hpk> fun
[11:16] <arigo> aaargh.
[11:16] <arigo> what a nice idea of bash to override the CMD env var.
[11:16] <hpk> bash scares me that they changed something like this
[11:17] <arigo> I propose to make 'x' a keyword in Python.
[11:17] <hpk> hehe
[11:17] <hpk> don't propose just commit it :)
[11:17] <arigo> :-)
[11:17] <hpk> ok, so on to the moving fun
[11:18] <arigo> well actually they're considering making 'block' a keyword, which will break half of the flow graph and annotator
[11:18] <hpk> i hope that the no-keyword approach wins if any
[11:18] <arigo> on to the moving fun :-)
[11:18] <hpk> the construct is generic enough ASFAIU
[11:18] <hpk> -x hpk/hpk
----- silence for 37 minutes ----- [11:55] esteban (~esteban@DWM-203-228.go.retevision.es) joined #pypy.
----- silence for 1 hr and 9 minutes ----- [13:04] yuuh (nhajczt@dsl-62-220-10-104.berlikomm.net) joined #pypy.
[13:16] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[13:18] yuuh (nhajczt@dsl-62-220-10-104.berlikomm.net) left irc: Read error: 145 (Connection timed out)
[13:18] yuuh (lpxaqnks@dsl-62-220-8-204.berlikomm.net) joined #pypy.
----- silence for 22 minutes ----- [13:40] Action: hpk -> hunting for food and sun
----- silence for 45 minutes ----- [14:25] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[14:27] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 26 minutes ----- [14:53] stakkars (tqlslygx@dsl-62-220-8-204.berlikomm.net) joined #pypy.
[14:59] <stakkars> hi
[15:08] <arigo> hi!
[15:12] <stakkars> how is it in Gothenburg?
[15:12] <arigo> nice and sunny
[15:13] <stakkars> same here. I will leaveto a cafe and work from there.
[15:13] <arigo> btw if that's easy, could you please install 'screen' on tismerysoft.de?
[15:13] <arigo> great :-)
[15:13] <stakkars> no idea,letmesee if the package is in Debian
[15:13] <arigo> yes
[15:15] <stakkars> done
[15:16] <stakkars> (not tested, just installed)
[15:16] <arigo> thanks!
[15:16] <stakkars> last nite I got the first int_add_ovf generated and compiled.
[15:17] <stakkars> not checked in, yet.
[15:17] <arigo> :-)
[15:18] <stakkars> but the ovfcheck hack works nicely. Tested with add,mul and div, and it handles the dualblock problem nicely
[15:18] <stakkars> should I continue a bit, or work on the test goal stuff
[15:19] <arigo> as you like
[15:19] <arigo> if you find failures in http://codespeak.net/~hpk/pypy-testresult/ that look familiar, go ahead
[15:22] <stakkars> ouups
[15:22] <stakkars> that is a lot not working, almost 50 %
[15:23] <arigo> yes
[15:25] <stakkars> ok, I'll go to the cafe and finish the C backend (there is no internet)
[15:25] <stakkars> later I will start on the hugebug list.
[15:26] <stakkars> maybe we should have something where we say who is working on which problem?
[15:26] <stakkars> to avoid double efforts?
[15:29] <stakkars> screen seems to need some changes formultiuser support. suid root :-(
[15:31] <arigo> yes
[15:31] <arigo> "finish the C backend" ?
[15:32] <hpk> which 'screen' binary are you refering to?
[15:32] <arigo> hpk: on tismerysoft
[15:33] <stakkars> arigo: finishing and testing the C macros for ovvf checked operations, and extending the target
[15:33] <stakkars> hpk: what do I need to do with screen?
[15:33] <hpk> chmod u+s /usr/bin/screen IIRC
[15:33] <arigo> stakkars: ah, ok
[15:34] <hpk> then your /var/run/screen directory may need perm-changes ... it will tell you
[15:34] <stakkars> hpk: isn't this a security issue?
[15:34] <hpk> suid binaries are always security issues
[15:34] <stakkars> ok, let's do it before I leave
[15:35] <stakkars> chmod is done. What else?
[15:36] <hpk> it will tell you, i don't know it by heart
[15:36] <stakkars> how do I start a multi-user screen session, to test it?
[15:37] <hpk> look into e.g. my codespeak.net:~hpk/.screenrc at the end
[15:37] <hpk> you need to add the users you want to give access there
[15:37] <stakkars> ah, thanks
[15:37] <stakkars> do you have an account?
[15:37] <stakkars> on tismerysoft
[15:38] <hpk> yes, you gave it to me two days ago
[15:38] <stakkars> brain dead me
[15:39] <hpk> chmod 755 /var/run/screen
[15:39] <hpk> is what you need to do
[15:39] <stakkars> done
[15:41] <stakkars> stolen your .screenrc
[15:43] <stakkars> I looked into the test results. There are different timeouts.
[15:43] <stakkars> Is this by killing the processmanually?
[15:43] <hpk> yes
[15:46] <stakkars> some look quite strange.
[15:47] <stakkars> see you - I'll work offline in a cafe
[15:48] <hpk> see you, have fun (and write tests :-)
[15:48] <stakkars> I'll extend targetpypy which is a test
[15:55] Action: arigo and pedronis categorizing the tests as core or not core
[15:56] <hpk> arigo: how are you doing it ?
[15:57] <hpk> i'd recommend a simple list of names
[15:57] <arigo> hpk: we're adding a "core" flag in conftest
[15:59] <hpk> arigo: i am going to make our test reports mime-compliant
[15:59] <hpk> and then quickreport and htmlreport should have more common code
[15:59] <arigo> ok
[16:14] stakkars (tqlslygx@dsl-62-220-8-204.berlikomm.net) left irc: Read error: 113 (No route to host)
----- silence for 23 minutes ----- [16:37] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) got netsplit.
[16:37] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) returned to #pypy.
----- silence for 22 minutes ----- [16:59] <hpk> arigo, pedronis: that's what i mean with my comment earlier
[17:00] <hpk> it would be better to put the core specs into a plain list of names
[17:01] <arigo> well, why?
[17:02] <hpk> because it better matches the upcoming test selection/querying support
[17:03] <arigo> if we need this information even after the tests are run,
[17:03] <arigo> then IMHO it only shows that we should put it outside conftest altogether
[17:03] <arigo> but keep information (both formal flags and informal comments) in a single place for each test
[17:03] <hpk> i am talking about: http://codespeak.net/py/current/doc/test.html#selecting-tests-by-queries-full-text-search
[17:04] <hpk> so at some point i'd simply like to say 'py.test coretests'
[17:04] <hpk> and all the tests in that list would belong to that set
[17:05] <hpk> IOW, i'd like to avoid adding too many bits and pieces everywhere that will then work cleanly with selection support
[17:05] <arigo> but for now it makes sense to have all info about a test at the same place
[17:05] <hpk> yes, although i hope that we will be mainly looking at the html reports
[17:05] <hpk> which will be a lot more cross-referenced and 'life' anyway
[17:06] <arigo> yes but not tonight, right? :-)
[17:06] <hpk> no, tomorrow :-)
[17:06] <hpk> i mean the html report is already more useful than looking at conftest.testmap
[17:07] <hpk> oh, you mean the selection support? no that is not going to happen tomorrow i guess _:-)
[17:07] <arigo> I mean that we didn't want to do a concept refactoring in the same checkin as selecting the core files
[17:08] <arigo> e.g. I'd like to check in a two-liner change:
[17:08] <arigo> by default py.test should ignore 'enabled' and run 'core' tests only
[17:09] <arigo> because that's what we need now.
[17:09] <hpk> yes, enabled should just go
[17:09] <hpk> completely
[17:09] <hpk> maybe not today but in the next few days
[17:09] <arigo> ah, possibly, yes
[17:09] <hpk> (it still has this extra piece of information that someone once got this running)
[17:09] <hpk> (but that piece of info should be generated anyway)
[17:09] <arigo> yes
[17:10] <hpk> the current reporting code including quickreport is just a mess :-)
[17:10] <hpk> intentional, i might add
[17:10] <arigo> it was meant to be a quick hack, and it's useful this way for now :-)
[17:10] <pedronis> one problem is what to do about tests that can be passed but timeout
[17:11] <pedronis> like test_coercion
[17:11] <hpk> i am basically rewriting the whole reporting
[17:11] <hpk> at the end a test will not be overwritten if it timed out but the existing result did not
[17:19] <arigo> hpk: for now, do you mind if I try to change index.cgi to display core/noncore instead of nonignored/ignored?
[17:20] <hpk> sure, maybe do it directly on -x hpk/hpk
[17:20] <hpk> i have it ready ... there
[17:26] <arigo> I can do it myself if you like :-)
[17:26] <arigo> I mean I already looked around these files
[17:26] <hpk> i want to properly localize the hack
[17:26] <hpk> but ok
[17:26] <arigo> as you like
[17:26] <hpk> just give me 5 minutes
[17:34] <hpk> arigo: works
[17:34] <arigo> thanks
----- silence for 1 hr and 10 minutes ----- [18:44] esteban (~esteban@DWM-203-228.go.retevision.es) left irc:
[18:53] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
----- silence for 2 hr and 8 minutes ----- [21:01] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "[x]chat"
[21:05] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 33 minutes ----- [21:38] <hpk> arigo: hi
[21:38] <hpk> when i have the new reporting stuff ready do i need to stay compatible to the current test reports?
[21:40] <hpk> mean, i would make quickreport work as well as htmlreport but would drop all current test results as being compatible to the old format is not really worth it IMO
[21:49] <arigo> that's fine, I guess
[21:49] <hpk> the email package really has a strange API as you said
[21:50] <arigo> we'll start regenerating tests as soon as you commit, so by tomorrow morning we should have them ready again
[21:50] <hpk> if i complete it this evening, but i should (i have been away a while)
[21:51] <arigo> basically, if you're confident things work,
[21:51] <arigo> we don't have to svn-up testresult before we have the new test results checked in
[21:52] <arigo> this way we can still poke around.
[21:52] <hpk> ok, is there any information in quickreport.py that needs to preserved ... IGNORE_MODULES is obsolete now, i guess
[21:52] <arigo> yes
[21:53] <arigo> I see nothing useful to keep around
[21:54] <hpk> i just tried "python index.cgi >x.html && links -dump x.html | less"
[21:54] <hpk> works nicely :-)
[21:54] <hpk> so maybe we don't even neeed quickreport :-)
[21:54] esteban (~esteban@DWM-203-228.go.retevision.es) joined #pypy.
[21:55] <hpk> (just joking)
[21:55] <arigo> no, as you like, that makes some sense
[21:55] <arigo> quickreport.py is taking ages now on my machine, actually
[21:56] <arigo> not sure why, maybe regexp problem
[21:56] <hpk> yes, the regexes take quite some time
[21:56] <arigo> r_endout, possibly
[21:57] <arigo> r_end too
[21:57] <hpk> they are completely gone in my WC, so don't bother
[21:57] <arigo> good :-)
[21:57] <hpk> basically test results are encapsulated as mime messages
[21:57] <hpk> where the first multipart message has the current headers
[21:58] <hpk> i took care that things are mostly readable in a text editor
[21:58] <arigo> where are timeouts detected?
[21:58] <hpk> ?
[21:58] <hpk> that is like before, i didn't change it much
[21:58] <hpk> oh, you mean for fine-grained?
[21:58] <arigo> no
[21:59] <arigo> currently, timeouts need a regexp
[21:59] <arigo> you mean you only removed r_endout and r_end, and not r_timedout?
[21:59] <hpk> no, the timeout reporting is missing, i guess
[21:59] <hpk> it should come as an exit status from the alarm process i guess
[22:00] <arigo> it's a bit delicate
[22:00] <arigo> the only real hint is the presence of this =======timeout======= string
[22:01] <arigo> I can think about cases where a test would time out, give this string, and fail in various strange ways
[22:01] <arigo> unless the timeout thread calls os._exit(), but that's brutal
[22:02] <hpk> i am wondering how to do proper timeout-ing in fine-grained mode
[22:02] <hpk> because this usually runs in process
[22:02] <arigo> the same approach should work
[22:02] <hpk> probably just assert that the test runs in the main thread
[22:02] <hpk> yes, well
[22:02] <arigo> you need to catch the KeyboardInterrupt carefully
[22:03] <arigo> and yes, check that you are in the main thread, if possible
[22:03] <arigo> of course the alarm thread needs to be stopped if the test finishes in time, etc.
[22:03] <arigo> some careful locking might be needed
[22:03] <hpk> yes
[22:05] <hpk> with fine-grained the timeout thingie will be more meaningful because it is on a per-method level
[22:06] <arigo> sure
[22:10] esteban (~esteban@DWM-203-228.go.retevision.es) left irc:
[22:24] <arigo> hpk: syntaxerror on the web page :-)
[22:24] <hpk> upsy
[22:25] <hpk> fixed
[22:27] <hpk> i am close to opening a 'test' directory in lib-python :-)
[22:28] <hpk> but don't even want to start thinking how that interferes with the conftest.py ...
[22:28] <arigo> :-)
[22:30] <hpk> if you have a better design idea regarding conftest.py let me know
[22:30] <hpk> btw
----- silence for 21 minutes ----- [22:51] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 20 minutes ----- [23:11] <hpk> arigo: btw, py.path.local objects, at least, are picklable, to a bit of my suprise
[23:11] <arigo> :-)
[23:11] <arigo> they don't really point to outside data, as far as I can imagine
[23:16] ptk (~flUnf@c-24-128-26-215.hsd1.ma.comcast.net) joined #pypy.
[23:16] ptk (flUnf@c-24-128-26-215.hsd1.ma.comcast.net) left #pypy.
[23:16] <hpk> arigo: i thought you were worried about the import (not-so-anymore) magic
[23:17] <arigo> ah, right
[23:18] <arigo> I guess it fools pickle to pretend that class py.path.local is in module py.path, where it can really be re-imported from
[23:18] <hpk> yes, although i guess that py.__. - paths should work also
[23:21] [`Gu|]syR!flUnf@c-24-128-26-215.hsd1.ma.comcast.net] Come watch me on my webcam and chat /w me :-) http://c-24-128-26-215.hsd1.ma.comcast.net:3743/me.mpg
[00:00] --- Mon May 2 2005