[00:05] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: "Never put off till run-time what you can do at compile-time. - D. Gries"
----- silence for 16 minutes ----- [00:21] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.
[00:28] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
----- silence for 4 hr and 29 minutes ----- [04:57] yuuh (gyxqmedk@i528C13CD.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[05:03] hpk_away (~hpk@merlinux.de) left irc: Read error: 110 (Connection timed out)
----- silence for 3 hr and 7 minutes ----- [08:10] hpk_away (~hpk@merlinux.de) joined #pypy.
[08:16] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 49 minutes ----- [09:05] Gromit (~bear@A36ae.a.pppool.de) joined #pypy.
----- silence for 21 minutes ----- [09:26] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 1 hr and 7 minutes ----- [10:33] mwh2 (~user@modem-62.ar-sakalthur.dialup.pol.co.uk) joined #pypy.
----- silence for 35 minutes ----- [11:08] mwh2 (~user@modem-62.ar-sakalthur.dialup.pol.co.uk) left irc: "bye"
----- silence for 23 minutes ----- [11:31] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection
----- silence for 42 minutes ----- [12:13] Gromit (~bear@A36ae.a.pppool.de) left irc: Read error: 110 (Connection timed out)
----- silence for 18 minutes ----- [12:31] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: "Eject! Eject! Eject!"
----- silence for 20 minutes ----- [12:51] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.
----- silence for 21 minutes ----- [13:12] stakkars (~tismer@rosine27.inf.fu-berlin.de) joined #pypy.
----- silence for 48 minutes ----- [14:00] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[14:12] <pedronis> aleale: you modified a file in 2.3.4!
[14:23] Nick change: hpk_away -> hpk
[14:29] <hpk> hi samuele
[14:29] <pedronis> hi
[14:29] <hpk> forget about the disclaimer, that was an accident
[14:29] <hpk> the real question is how to represent the developers
[14:30] <hpk> i am also thinking that it makes some sense if we drop some of our names at the end of the announcement and otherwise refer to a complete view of contributors
[14:30] <hpk> stakkars: are you there?
[14:32] stakkars (~tismer@rosine27.inf.fu-berlin.de) left irc: Read error: 60 (Operation timed out)
[14:46] yuuh (~yuuhu@i528C1F8D.versanet.de) joined #pypy.
[14:56] cfbolz (~cfbolz@hdlb-d9b946d7.pool.mediaWays.net) joined #pypy.
[14:56] <cfbolz> hi!
[15:00] <pedronis> hpk: do you know what was meant with this in TODO: mark debugging variables to make our code more readable
[15:01] <hpk> i wondered too
[15:01] <hpk> cfbolz: hi carl!
[15:01] <mwh> i think we've mostly done that
[15:01] <hpk> pedronis: ah, maybe it means: prefix debugging functions/variables with debug_ or something
[15:01] <hpk> to make it more distinguishable from real variables
[15:02] <hpk> mwh: hi michael, btw
[15:02] <pedronis> I see, should we open an issue, I see the point but if that were our only understandability problem ...
[15:02] <cfbolz> LLVM 1.5 got just out, but I probably won't have time to test it before tommorrow (due to installation hassles, it just takes too long). Should the docs say anything about LLVM versions?
[15:03] <pedronis> cfbolz: that we used 1.4 for development
[15:03] <pedronis> maybe
[15:03] <hpk> pedronis: surely, it's not our only u-problem :-)
[15:04] Gromit (~bear@A3690.a.pppool.de) joined #pypy.
[15:04] <hpk> pedronis: the prefix issue is kind of touched in the tracing issue
[15:04] <hpk> pedronis: i'd say forget about it for now, it's nothing critical indeed
[15:04] <pedronis> yes, too much issues is not good either
[15:04] <pedronis> many
[15:05] <cfbolz> pedronis: Ok, I'll write that. I see no reason why 1.5 should break anything anyway.
[15:05] <pedronis> cfbolz: any idead how much it takes for deb packages to show up after a new release?
[15:06] <cfbolz> nope. I guess it will take a while since these don't come from the LLVM core team AFAIK
[15:06] <pedronis> I see. right now I have used those to install llvm 1.4
[15:07] <cfbolz> ok. I guess hoping for the best is all I can do for now.
[15:08] <pedronis> hpk: in TODO there are basically 3 things left.
[15:09] <pedronis> do we need a issue about testing framework?
[15:09] <pedronis> I can make an issue about string formatting speed issues
[15:09] <hpk> maybe
[15:09] <hpk> i guess filing one for testing is fine
[15:09] Action: hpk is out for 30 minutes
[15:13] cfbolz (~cfbolz@hdlb-d9b946d7.pool.mediaWays.net) left irc: "Verlassend"
----- silence for 19 minutes ----- [15:32] ericvrp (~a@ericvrp.demon.nl) joined #pypy.
----- silence for 25 minutes ----- [15:57] tea (~tea@cap049-090.kcn.ne.jp) joined #pypy.
[15:57] cfbolz (~cfbolz@hdlb-d9b95e9b.pool.mediaWays.net) joined #pypy.
[15:58] <cfbolz> hpk: back again?
[15:58] arigo (~arigo@ratthing-b407.strakt.com) joined #pypy.
[15:59] <cfbolz> hi!
[16:00] <arigo> hi!
[16:05] <hpk> cfbolz: yes
[16:05] <cfbolz> I think you misunderstood me re README:
[16:05] <hpk> impossible
[16:05] <cfbolz> I would like pointers to the pypy/documentation folder
[16:06] <cfbolz> in the archive
[16:06] <hpk> you mean as relative local pointers, i see
[16:06] <hpk> cfbolz: feel free to modify it the way you see fit
[16:06] <cfbolz> a pointer is not even neccessary, I would just write "see pypy/documentation"
[16:07] <cfbolz> Ok, I'm doing it.
[16:09] Action: hpk is out a bit again
[16:14] <pedronis> cfbolz: we need to skip or disable the failing llvm tests about exceptions
[16:15] Gromit (~bear@A3690.a.pppool.de) left irc: Read error: 110 (Connection timed out)
[16:17] <cfbolz> huh? I though I fixed these
[16:17] <cfbolz> Are there still failing tests for you?
[16:18] <pedronis> test_catch_instance and test_try_raise_choose are still failing, yes
[16:19] <cfbolz> strange
[16:20] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
[16:21] <cfbolz> could you send me the errors? or save it somewhere on codespeak? It seems to be working for me.
[16:24] <pedronis> cfbolz: /home/pedronis/llvm-err-out.txt
[16:25] <cfbolz> thanks. I'll look into it.
[16:25] <hpk> aleale: did you see the issue regarding codecs?
[16:26] Action: hpk sets TODO issue to resolved
[16:31] <cfbolz> pedronis: Don't know what happened -- it fails for me too, on another machine. I'm disabling the tests for now and try to fix it tonight.
[16:40] <cfbolz> I'm going again. See you.
[16:40] <hpk> see you!
[16:40] <arigo> bye
[16:40] cfbolz (~cfbolz@hdlb-d9b95e9b.pool.mediaWays.net) left irc: "Verlassend"
[16:43] <hpk> arigo: are you working on architecture and mission, btw?
[16:43] <arigo> will start soon...
[16:43] <arigo> basically just arrived on my machine, reading my mails now
[16:44] <hpk> np, i am just curious what "everyone" is doing
[16:45] Action: hpk walks out to see what the sun is doing
[16:55] arre (ac@ratthing-b3fa.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[17:00] faasse1 (~faassen@a80-127-80-154.adsl.xs4all.nl) joined #pypy.
[17:01] <faasse1> hey..svn on codespeak has a problem..I tried the recoversvn script..
[17:01] <faasse1> but this failed:
[17:01] <faasse1> + /etc/init.d/svn stop
[17:01] <faasse1> * Stopping apache2-svn ... [ ok ] * Stopping /www/trac/sysconf on port 7400 ...
[17:01] <faasse1> start-stop-daemon: warning: failed to kill 27023: No such process [ !! ] * ERROR: problems stopping dependent services.
[17:01] <faasse1> * "svn" is still up.
[17:02] Nick change: faasse1 -> faassen
[17:05] <mwh> arigo: congratulations on being so polite to tjreedy
[17:05] <arigo> mwh: :-)
[17:06] <arigo> faassen: hum
[17:06] <mwh> which reminds me, i liked this checkin message:
[17:06] <mwh> Made the __name__ of types writeable. This triggered a chain of obscure
[17:06] <mwh> and mostly funny problems leading to eventual bug fixes.
[17:06] <mwh> :)
[17:06] <arigo> :-)
[17:07] <arigo> the funny problem was that setattr__Type was calling the set descritor with arguments (self, obj, type(obj)) instead of (self, obj, value)
[17:07] <mwh> haha
[17:07] <faassen> mwh: what'd tjreedy do?
[17:07] <arigo> but it was still setting the value into the dict of the type anyway afterwards
[17:07] <mwh> copy and paste, perchance
[17:08] <arigo> so most things just worked; __name__ was the first that didn't
[17:08] <faassen> it's glad someone finds this kind of problem funny.. :)
[17:08] <faassen> I'm glad..
[17:08] <mwh> faassen: oh, responded to a bug report of arigo's in a slightly silly way
[17:08] <faassen> mwh: anyway, arigo in my experience is patience itself. :)
[17:08] <faassen> mwh: unlike myself. :)
[17:09] Action: faassen prays for the svn to repair itself..
[17:09] <faassen> oh Subcevesarch, God of Checkins and Chickens..
[17:10] <mwh> argh
[17:10] <mwh> local dns is down
[17:10] <faassen> please listen to me besiege thee, repair the svn so I can commit the Checkin that fixes bugs for your higher glory.
[17:11] <mwh> can someone tell me the ip of news.bcc.co.uk? :)
[17:11] <faassen> 212.58.226.44)
[17:11] <mwh> thanks
[17:16] Action: arigo tries to remove a stale pid file on codespeak
[17:16] Action: arigo stops messing around -- didn't work
[17:20] Action: arigo fixed it, hopefully cleanly
[17:21] <arigo> should work now. the trac-sysconf service had died -- process no longer there as far as I could tell. I had to convince the start-up script to consider it as down ("zap").
[17:21] <arigo> Hope I didn't break anything.
[17:23] <arigo> hum, the trac-sysconf service doesn't appear to have restarted. hpk: oups! should it be restarted manually? (arigo really stops messing around)
[17:25] Action: hpk is back
[17:29] <hpk> arigo: seems fine, i actually disabled trac-sysconf now, so it shouldn't show up again
----- silence for 16 minutes ----- [17:45] Action: hpk notices that test_typed fails for a longer time now
[17:46] <hpk> but apparently only on amd64 (codespeak)
[17:46] <arigo> ah
[17:54] <arigo> argh. we use 'int' in the generated C code. should be 'long'....
[17:55] <arigo> but I don't care too much at this point
[17:55] <arigo> given the proposed changes going away from genc...
[17:55] <hpk> right
[17:56] stakkars (~tismer@rosine27.inf.fu-berlin.de) joined #pypy.
[17:56] <arigo> hi!
[17:56] <hpk> hey christian
[17:56] <stakkars> hi
[17:56] <hpk> arigo: so should we just disable the tests or skip them on amd64?
[17:57] <arigo> yes
[17:57] <arigo> I'm doing it
[17:57] <hpk> fine, you can set the testing issue to testing then :-)
[17:57] <hpk> issue57
[17:58] <stakkars> phew, I had a hard time
[17:59] <hpk> pedronis: let's think a bit about finalizing the release announcement?
[17:59] <stakkars> flow space can now do everything that's flowable.
[17:59] <stakkars> there is no longer any special treatment of geninterp.
[17:59] <stakkars> the do_imports thing is gone, we always do it.
[17:59] <stakkars> import sys at topleveldoes the right thing(tm)
[18:00] <hpk> you are talking about your working copy i guess?
[18:00] <stakkars> and geninterp output is never run through flowspace, becuase it makes no sense.
[18:00] <stakkars> yes. I'm doing final tests, then you get a larger update.
[18:01] <stakkars> it was easier to correct things than to tell why they don't work :-)
[18:01] <hpk> i hope your checkin doesn't introduce problems for the release tomorrow
[18:02] <stakkars> how can it if I run test_all?
[18:02] <arigo> well, I can think of a lot of ways :-) but I'm still optimistic
[18:02] <arigo> go ahead and check in
[18:02] <arigo> I'd like to see if and what remains to be done for genc-ing print statements, or crashing nicely on them
[18:03] <stakkars> nix, nada,null.
[18:03] <stakkars> works already with targetrpystone
[18:03] <arigo> cool
[18:03] <stakkars> the trick to get sys right:
[18:03] <arigo> I'll try to put the prints back in demo/bpnn.py too
[18:03] <stakkars> I changed flow space to intercept getattr
[18:04] <stakkars> and to see if it has a constant that is not so constant.
[18:04] <stakkars> sys is the onlycandidate at the moment.
[18:04] <stakkars> if it is found, then a do_operation of a simple function is done,
[18:04] <hpk> arigo: it's generally better to skip tests only at very few places, because the different places will all be listed
[18:04] <stakkars> which always generates a SomeObject
[18:04] <arigo> hpk: I know, isn't it what I did?
[18:05] <hpk> arigo: i just saw the first lines of the diff which show redundancy
[18:05] <hpk> but it isn't crucial for M0.5 :-)
[18:05] <arigo> they show a typo that I fixed :-) I didn't add these two skips
[18:06] <arigo> stakkars: looks like the correct direction, indeed
[18:06] <hpk> right, currently we have a rather long list of skips
[18:06] <arigo> stakkars: in the long run the flow space should probably be less aggressive on constant folding
[18:07] <arigo> stakkars: i.e. be careful in the same way as you did for getattr(), for all other operations as well, probably based on inspecting what object the Constant().value is.
[18:07] <stakkars> arigo: yes, probably. certain things are a bit annoying, like 'print 5000*"hallo"'
[18:07] <arigo> :-)
[18:08] <stakkars> in case of sys, I started a tiny registry.
[18:08] <stakkars> just doing the minimum.
[18:08] <stakkars> the getattr gets folded if we ask for sys.maxint, for instance
[18:08] <stakkars> but sys.stdout will always be lazy
[18:15] <pedronis> hpk: sorry, I was reworking a bit our RPython doc to approximate reality better,
[18:15] <pedronis> hpk: yes we should think about finalizing the announcement
[18:22] <aleale> hpk: re:codec issue, Yes I saw it - I am working on it
[18:23] <aleale> It is strange because my implementation of _codecs is disabled in that revision
[18:24] <aleale> I can (after much work with conftest.py and other tests failing on windows) regenerate the failing test.
[18:28] <hpk> pedronis: the main issue is a contributors/eu-partners list i guess
[18:29] <hpk> aleale: before you resort to conftest.py hacking you can ask me or someone about the underlying problem
[18:29] <hpk> aleale: also i guess you noticed that there is now a much more detailed description about modules
[18:30] Action: arigo working on architecture.txt
[18:30] <aleale> hpk: it was the problem of WIFEXTED and friends
[18:31] <aleale> hpk: I am reading it
[18:33] <pedronis> hpk: I see, the full contributors list is quite long, so it's matter how to we want to point to it and how to sign the announcement
[18:33] <hpk> aleale: i see, you can usually run py.py test_codecs.py if you want to see things direclty
[18:33] <hpk> pedronis: exactly
[18:34] <aleale> A comment on "getting-started": On windows py.test is invoked as "pytest"
[18:35] <hpk> we are usually mentioning "python ../test_all.py" as an equivalent
[18:35] <hpk> plus it's not quite true for the recent py lib anymore if you run "setup.py install"
[18:35] <pedronis> hpk: about the partners, I presume they may like to be listed but I don't know for sure
[18:35] <hpk> it should actually put 'py.test' on your path
[18:35] <aleale> ok I see - didnt do that
[18:36] <hpk> aleale: it's quite recent
[18:37] <hpk> pedronis: if we list the partners then we should at least list a few individuals as well
[18:37] <hpk> and link to the full list contributors somewhere
[18:37] <hpk> should i just put a computed list of contributors into documentation?
[18:38] <hpk> (ordered by number of commits for now, guess who is leading by far :-)
[18:38] <hpk> i also have a version where i basically walk through the whole blame tree but i'd like to refine that after M0.5
[18:39] <pedronis> hpk: but blame and merges can interfere
[18:39] <hpk> pedronis: yes i know
[18:40] <hpk> but ordering is not really the problem for the first few problems
[18:40] <hpk> and people other than the core group tend not to branch/merge that much
[18:41] <hpk> but let's not argue if using svn's blame is 100% enough: it isn't.
[18:41] <hpk> IOW, i am talking about "good enough" approaches for now
[18:42] <pedronis> hpk: anyway having a refereceable list of contributors makes sense apart the one LINCENSE that is mixed with license text
[18:42] <pedronis> hpk: we need a criteria for how to cut the list for announcement and point to the rest
[18:43] <hpk> yes, i am doing the contributors list now (with a script in documentation/tool)
[18:43] adim (~adim@logilab.net2.nerim.net) left irc: Remote closed the connection
[18:43] <stakkars> waah,everything breaks after svn up :-(
[18:44] <hpk> we haven't been resting :-)
[18:44] <stakkars> where is py.code now?
[18:45] <hpk> pedronis: i'd put all people that have been heavily involved with the release into the release announcement
[18:45] <hpk> pedronis: and link to the rest or something
[18:45] <pedronis> makes sense
[18:45] <hpk> stakkars: py.code didn't change
[18:46] <stakkars> [D:\pypy\dist\pypy\interpreter\baseobjspace.py:393]
[18:46] <stakkars> does an import py
[18:46] <stakkars> it worked before
[18:46] <hpk> pyc files?
[18:46] <stakkars> so something with path magic must have changed
[18:46] <stakkars> maybe. I'll try
[18:46] <pedronis> stakkars: you need to remove .pyc files for sure
[18:46] <hpk> stakkars: oh, you have to remove the pyc files, armin specifically warned against it
[18:47] <pedronis> for example intepreter/py.pyc if still around is evil
[18:48] <pedronis> it masks py lib package imports
[18:48] <stakkars> I did this. It still gives problems.
[18:49] <stakkars> ok, I get different errors, now, this is probablymine.
[18:53] <stakkars> ah, sourcetools has consumed compile2. Getting closer...
[18:55] <stakkars> where have the things fromgoalgone into?
[18:55] <stakkars> goal?
[18:56] tea (~tea@cap049-090.kcn.ne.jp) left irc: "using sirc version 2.211+KSIRC/1.3.10"
[18:57] <stakkars> thanks,got it
[19:11] <hpk> stakkars: have you worked on the other M0.5 issues or are they pending?
[19:16] <hpk> i am trying to sort out where we stand with the ~20 issues for M0.5
[19:17] <stakkars> working on them
[19:18] Action: hpk suggests to bring all M0.5 issues to 'testing' tonight
[19:24] <pedronis> hpk: README can be set to testing I presume?
[19:24] <hpk> pedronis: yes, i guess so
[19:26] Action: hpk just commited release-0.6 to testing
[19:27] <stakkars> mega-checkin done
[19:30] <hpk> looks nice
[19:32] <stakkars> if we have the time,wecannow write a littletool that creates tiny compiled programs
[19:32] <stakkars> there is not much missing I think.
[19:32] <hpk> only if everything else is done :-)
[19:33] <hpk> and even then i think we should go for a M0.7 / 0.7 release at EP
[19:33] <hpk> move to Python2.4, do the tool etc.pp.
[19:33] <stakkars> sure. It is just the thing that kept me from putting this on the milestones
[19:33] <stakkars> that I didn'tknpow how difficult it is.
[19:36] yuuh (~yuuhu@i528C1F8D.versanet.de) got netsplit.
[19:36] faassen (~faassen@a80-127-80-154.adsl.xs4all.nl) got netsplit.
[19:38] <hpk> pedronis: i wonder how your name went wrong, i though i generated them, but well, what can i say
[19:39] faassen (~faassen@a80-127-80-154.adsl.xs4all.nl) returned to #pypy.
[19:39] yuuh (~yuuhu@i528C1F8D.versanet.de) returned to #pypy.
[19:43] <hpk> stakkars: i guess you are not going to work on https://codespeak.net/issue/pypy-dev/issue56 ?
[19:43] <hpk> because then i would just move it out of M0.5
[19:45] <stakkars> shift files?
[19:45] <stakkars> no, should I?
[19:45] <hpk> i asked you in the issue
[19:45] <stakkars> oops
[19:45] <hpk> np
[19:45] <hpk> i am just trying to reduce the issue list now :-)
[19:46] <stakkars> seems to be a minor thing.
[19:47] <hpk> indeed, but it's more or less just a cosmetical thing (which allows us to name the moduels 'sys' and '__builtin__'
[19:47] <stakkars> didn't getit completely,yet.
[19:48] <stakkars> you mean exceptionsinterp and classobjinterp?
[19:48] <hpk> i thought that the .py files in pypy/module give problems if we rename 'sys2' to 'sys'
[19:48] <hpk> but maybe this is not (or hasn't been?) the case
[19:49] <hpk> if something in pypy/module imports 'sys' then it would end up in pypy/module/sys instead of the cpython one
[19:50] <stakkars> ah, oh. ? in applevel?
[19:50] <hpk> no, interplevel
[19:50] <stakkars> cpython never looks for builtin modules.
[19:51] <stakkars> maybe I'm numb, today. My brain is fullf of flow graphsand SomeObjects
[19:51] <hpk> :-)
[19:51] <hpk> i thought that 'import sys' still triggers a try at a relative import first
[19:52] <stakkars> no, there isno way to trick CPython about a builtin module.
[19:52] <stakkars> well, checking again...
[19:53] <hpk> i am pretty sure that cpython tries relative imports first
[19:53] <hpk> otherwise there wouldn't be all those sys.modules shortcuts setting relative import tries to None
[19:54] <pedronis> hpk: I tried, if you have a sys.py in package Python tries it
[19:55] <pedronis> stakkars: targetpypymain end up analyzing unspecialize?
[19:56] <hpk> stakkars: i didn'T want to drag you into a discussion now, but just determine the status of the issue because it also affects documentation (already written)
[19:56] <stakkars> pedronis: that's the only that I didn't test,yet
[19:59] <stakkars> pedronis: what is the problem?
[20:01] <stakkars> hpk, pedronis: right. I'm also too tired for discussion. Will try to get my stuff done.
[20:03] <stakkars> pedronis: what doyou mean? sure, unspecialize is there, but just when sys attributes are touched.
[20:04] <stakkars> (will add its removal to simplify when there is time)
[20:04] <arigo> stakkars: I tried demo/bpnn.py with real print statements. Really works. Thanks! Excellent.
[20:05] <stakkars> well, I was not sure if that bypass trick for the gateway was the right thing to do, but it really works.
[20:05] <stakkars> I guess you could even try to use long expressions froma tiny program, Iguess you get just the code you need. Not sure
[20:10] <hpk> is pypy/cpython 4000 or 2000 times slower? (we have contradicting statements)
[20:10] <stakkars> 2000 in termy of rpystone
[20:11] <arigo> doesn't make much sense to be more precise than "2000 to 4000"
[20:11] <arigo> with our app-level helpers etc.
[20:12] <stakkars> hum. I tried to use some long operations, and it works, but seemstofall back into CPython! ???
[20:12] <hpk> arigo: then let's settle on 3000 to have a common number
[20:13] <stakkars> 2000
[20:16] <hpk> arigo: your refactoring looks very nice so far
[20:17] <arigo> 4000 :-)
[20:17] <arigo> (just kidding)
[20:17] Action: hpk is adding some minor fixes and a reference to Python (language reference)
[20:18] <stakkars> arigo: I just inserted a few statements which are using longs in RPython.
[20:18] <stakkars> I expected to get the implementationof this rendered, but these is just a single pow() call,
[20:19] <stakkars> which actually works. How comes that it calls back into CPython?
[20:19] <arigo> stakkars: not really following you
[20:20] <arigo> if you put a ** in a flow graph, you get a 'pow' operation, for sure
[20:21] <stakkars> in a way I expected tosee the implementation of pow,in this case for longs since this was annotated.
[20:21] <hpk> arigo: the 5.1 numbering is odd, there is no 5.2
[20:21] <stakkars> maybe this is not my dayof intelligence...
[20:22] <arigo> hpk: well it's a subsection of 5, so it gets 5.1
[20:22] <hpk> arigo: i understood that much :-)
[20:22] <arigo> hpk: I meant something like "what can I do about it?"
[20:23] <arigo> stakkars: the annotator doesn't know about longs, so no chance it pulls anything in
[20:24] <hpk> arigo: it's arguable if that section really belongs into architecture.txt (it is certainly a nice section, mind you)
[20:24] <stakkars> I see (thought we had already). But I'm right, if the annotator knew, it would pull?
[20:24] <arigo> hpk: I think it's good to have it here, to show concretely the difference between app- and interp-level code
[20:24] <stakkars> ok, I'll try different stuff,formatting should be great
[20:25] <arigo> stakkars: I guess so, yes
[20:25] <hpk> arigo: i think the "problem" is that we might have different audiences ...
[20:25] <hpk> those with a python background and those without
[20:25] <arigo> stakkars: well I said "yes" to "if it knew it it would pull"
[20:25] <arigo> stakkars: you won't see formatting either
[20:26] <arigo> stakkars: an interp-level % doesn't call our _formatting.py
[20:27] <arigo> stakkars: remember that there is absolutely no std objspace around, if you try to translate any small example.
[20:27] <arigo> hpk: this section is easily skipped, I guess, but useful for people which come with a practical Python experience
[20:28] <hpk> arigo: ok, but the section would otherwise be useful in the coding-guide or at leat referenced from there
[20:29] <arigo> hpk: ok, makes sense. it can be moved there and a link be added from architecture.txt
[20:29] <arigo> that would be more consistent with the rest of architecture.txt.
[20:29] <hpk> yes, probably
[20:29] <hpk> i am making a first commit with minor changes soon
[20:32] <hpk> arigo: we then also need to change the start of 6 wrapping
[20:32] <hpk> but that makes sense, anyway, i think (major sections should try to avoid depending on earlier chapters IMO)
[20:33] cfbolz (~cfbolz@hdlb-d9b95eaa.pool.mediaWays.net) joined #pypy.
[20:33] <arigo> re-hi
[20:33] <cfbolz> :-)
[20:33] <hpk> arigo: because it makes it harder to link to them
[20:33] <hpk> re-hi-hi
[20:33] <cfbolz> :-))
[20:33] <arigo> hpk: right.
[20:33] <cfbolz> It seems that genllvm works fine with LLVM 1.5, Eric just tested it (thanks!)
[20:34] faassen (~faassen@a80-127-80-154.adsl.xs4all.nl) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[20:34] <stakkars> arigo: yes :-/
[20:35] <hpk> arigo: 5 and 6 should be folded
[20:36] <hpk> if you look at the content-index they really fall out
[20:39] <arigo> hpk: the quickest fix would be s/6/5.2
[20:39] <hpk> ok, i am doing that although i still think the levels are not 100% correct
[20:39] <arigo> yes, the whole 5/5.1/5.2 is a bit long
[20:40] <arigo> and I see what you mean by levels not being 100% correct.
[20:42] <hpk> arigo: a real bonus would be to insert some pictures sparsely
[20:42] <arigo> :-)
[20:43] <hpk> i mean pictures we already have somewhere IIRC
[20:43] <hpk> and with '.. image:: ...' you are done ASFAIK
[20:43] <arigo> yes
[20:47] <arigo> I see, but I don't know exactly which images we already have and where
[20:52] <cfbolz> ok, I'm off again (more re*n hi's coming :-) )
[20:54] cfbolz (~cfbolz@hdlb-d9b95eaa.pool.mediaWays.net) left irc: "Verlassend"
[20:56] <arigo> hpk: off topic: why do execnet.inputoutput.Popen2IO.close_read and close_write use os.close(f.fileno()) instead of just f.close() ?
[20:56] <hpk> arigo: noclue
[20:57] <arigo> good :-)
[20:57] <hpk> it'S likely i didn'T just add this for fun though :-)
[20:57] <hpk> but then this particular code might have been written by Jum who comes from a lower level world :-)
[20:58] <stakkars> any objects if I also trash _exceptions.py?
[20:58] <stakkars> s/object/objections/
[21:00] <arigo> and re-generate it automatically also?
[21:00] <arigo> hum
[21:01] <arigo> it's nicely readable code...
[21:01] <stakkars> yes,depending on the state on _enum_exceptions.
[21:01] <stakkars> that makes sure that everybody has *her* platform's exceptions
[21:01] <arigo> I see.......
[21:01] <stakkars> well, I could spit its output into _cache
[21:02] <arigo> it makes sense but also means that we are forever dependent on CPython's list
[21:02] <stakkars> and them compile that
[21:02] <hpk> i thought the idea was to trash exceptionsinterp.py and not _exceptions.py or am i missing something?
[21:02] <arigo> I guess Christian wants to trash them both
[21:02] <stakkars> that was your idea, but cetero censeo carthaginem esse delendam nit not work with me :-)
[21:03] <stakkars> oops, sorry!
[21:03] <stakkars> mistaken, I thought you were afetr getting rid of the introspection stuff.
[21:03] <stakkars> yes, it would make us dependant fromCPython forever. bad idea.
[21:04] <stakkars> ok, let's forget about that.
[21:04] <arigo> of course we can add new exceptions with a hack in _enum_exceptions,
[21:04] <arigo> because we can then remove the hack if PyPy always runs on top of its own previous version :-)
[21:05] <stakkars> this is then the kind of source code like the tweak people have:
[21:05] <stakkars> some parts are gone :-)
[21:05] <arigo> "where does this exception come from?" "currently, nowhere"
[21:05] <stakkars> squeak
[21:05] <arigo> :-)
[21:06] <stakkars> well, there is a chance to loose them, but CPython will notreallygoaway.
[21:07] <arigo> I was afraid about the exceptions we might want to add later.
[21:07] <stakkars> right, at some time, there will be frozen stuff that has no source. why not.
[21:07] <stakkars> adding it is of course easy.
[21:07] <stakkars> even this way:
[21:07] <arigo> I know about one project which is 100% generated C code with no source, but able to regenerate its next version all the time.
[21:07] <stakkars> run pypy interactively,
[21:07] <stakkars> define a new exception
[21:08] <stakkars> run the generator program and whoops, you have them as a file.
[21:08] <arigo> squeakish :-)
[21:09] <stakkars> ok, do it or keep it?
[21:09] <pedronis> stakkars: I have slightly changed your code so that we don't need a special unspecialize anymore, tests pass, targepypymain annotates and bpnn.py prints
[21:09] <stakkars> pedronis: how does this work?
[21:10] <arigo> stakkars: keep it for now, I'd say, but put a big comment at the beginning of _exceptions.py
[21:10] <stakkars> ok
[21:10] <pedronis> stakkars: I just keep the constant in the getattr but put a variable as its result
[21:11] <pedronis> _classobj already triggered situations like that
[21:13] <stakkars> ahh. that was notso obvious for a flow graph hacking beginner like me :-) Let me check...
[21:14] Action: hpk would like to look at the remaining M0.5 issues not in 'testing' already
[21:15] <hpk> shall we go through them here?
[21:15] <stakkars> pedronis: no, this breaks things!
[21:15] <pedronis> what things?
[21:15] <stakkars> sys looses its laziness
[21:16] <stakkars> withmy version, the getattr(sys, stdout) is done very late.
[21:16] <stakkars> and it works in PythonWin
[21:16] <pedronis> with my version too
[21:16] <stakkars> your version is back to the days where the method of the open file is rendered.
[21:17] <stakkars> please look at the graph of targetpypymain and look into print_item_to
[21:17] <stakkars> the difference is that I gain complete SomeObjectnessfor sys.
[21:18] <stakkars> pedronis: yes it is done, but then not used!
[21:18] <stakkars> please revert, this is what I had days before.
[21:19] <pedronis> but the flowgraph is the wrong place to force SomeObjectness for sys
[21:19] <pedronis> SomeObjectness is a matter of the annotator
[21:19] <arigo> stakkars: do you mean to say that with samuele's version, the *annotator* computes the getattr result, which must be avoided?
[21:22] <stakkars> yes. wait -- I have toclear cache
[21:22] Action: hpk is walking off to issue65
[21:22] <stakkars> yes, absolutely.
[21:22] <arigo> how does that hurt?
[21:23] <stakkars> think of sys.argv
[21:23] <stakkars> I want the one of the user, not the compiler!
[21:23] <stakkars> so please keep the hack until we have something better
[21:24] <arigo> I see.
[21:24] <stakkars> and I want sys.stdout from the actual session, not the overriden one fromPythonWin, for instance
[21:24] <arigo> block.fillcolor = "red"
[21:24] <arigo> AttributeError: 'SpamBlock' object has no attribute 'fillcolor'
[21:24] <arigo> yack! slots.
[21:25] <stakkars> for that reason I made unspecialize, which cannot be tracked by the annotator.
[21:25] <arigo> another hack would be to change what the annotator thinks 'sys' is.
[21:25] <pedronis> yes
[21:26] <arigo> e.g. it can think it is just SomeObject() for now
[21:26] <stakkars> some special casing must go somewhere, sure. I don't see why you must change it now
[21:26] <stakkars> please have a look at the special treatmentof certain attributes, too.
[21:26] <arigo> well, because unspecialize is a very very strange function that even shows up in the flow graphs...
[21:26] <pedronis> yes
[21:26] <stakkars> pah
[21:27] <stakkars> the comment says that this will get simplified away, soon :-)
[21:27] <arigo> I think Samuele kept the special treatment of the attributes.
[21:27] <pedronis> yes
[21:27] <pedronis> I just need to special case sys in immutablevalue
[21:27] <arigo> yes, that's a two-liner
[21:27] <stakkars> fine with me. Although I'dlike that we specify such things in one place,some time.
[21:28] <arigo> yes, definitely right
[21:28] <pedronis> stakkars: if you had checked in a test I would have known what your goal was
[21:28] <stakkars> how could I do that, noidea howtotest this.
[21:29] <pedronis> set sys.argv
[21:29] <pedronis> compile
[21:29] <pedronis> change
[21:29] <stakkars> well,maybe you're right.
[21:29] <pedronis> sys.argv
[21:29] <pedronis> call function returning it
[21:29] <arigo> in general, the whole annotator business is a compromise between special cases in the annotator vs special cases in the source it handles (but strange code in the flow graph must be kept as low as possible, and I think the special sys per-attribute treatment could be defined outside the flow space altogether at some point.)
[21:29] <arigo> (not now, mind)
[21:29] <pedronis> see if the new state has changed
[21:30] <stakkars> checked in?
[21:30] <stakkars> arigo: yes, some registry where we tell about certain objects that need attention.
[21:30] <arigo> stakkars: there is annotation/builtin.py already, it'd be a good place I guess
[21:31] <stakkars> the way I did it in the objspace is maybe not so bad. The annotator should just specialtreat all these objects.
[21:34] <stakkars> arigo: yes
[21:40] <stakkars> pedronis: are you patching immutabevalue or do I do it?
[21:40] <pedronis> done
[21:42] <stakkars> yeah,perfect
[21:52] ericvrp (~a@ericvrp.demon.nl) left irc:
[21:55] ericvrp (~ericvrp@ericvrp.demon.nl) joined #pypy.
[21:58] <stakkars> where is the qeuvalent of py.py now?
[21:59] <hpk> pypy/bin/
[21:59] <stakkars> thx
[22:00] <hpk> ericvrp: i now guess how you are :-) hi eric
[22:00] <ericvrp> hi hpk. Yes I'm here . trying to figure out how to use Gaim's irc client
[22:00] <hpk> arigo, pedronis: can one of you add a few more "related projects" especially in the LISP area?
[22:01] <hpk> ericvrp: i am holger in case you can't use your IRc clients feature of detecting the real name :-)
[22:02] <ericvrp> hpk: figured that one out, thank you :) Now if I can just stop Gaim from poping up this conversation window. Getting there.
[22:04] <ericvrp> I've been trying to subscribe to: http://codespeak.net/mailman/listinfo/pypy-sprint without success. Is that list down at the time?
[22:06] <hpk> works for a test account of mine, just checked
[22:08] <pedronis> hpk: we may want to borrow from the list of refences in the goal section of the proposal itself
[22:08] <hpk> pedronis: yes, i guess so
[22:10] bbailey (~bbailey@adsl-146-20-126.mia.bellsouth.net) joined #pypy.
[22:13] <hpk> would anyone mind if we just forget about the left side navigation bar while on the documentation pages?
[22:13] <ericvrp> hpk: the confirmation emails went into a generic IMAP mailinglists folder of mine. Some 3000 other unread message (mostly about Qt) to keep it company. Sorry for taking your time!
[22:13] <hpk> ericvrp: np
[22:18] arigo (~arigo@ratthing-b407.strakt.com) left irc: Read error: 110 (Connection timed out)
[22:20] arigo (~arigo@ratthing-b409.strakt.com) joined #pypy.
[22:23] <arigo> oups. no idea why I timed-out.
[22:24] <arigo> ericvrp: hi!
[22:24] <ericvrp> hi
[22:25] <stakkars> exceptionsinterp is gone.
[22:26] <arigo> :-)
[22:26] <stakkars> maybe I should try todrop classobjinterp as well?
[22:26] <arigo> would be great
[22:27] <stakkars> hmm, where do wepull this out of the pocket? Maybe right after the expcetions?
[22:28] <stakkars> (I'll see where it gets imported, maybe there)
[22:28] <arigo> yes, let's generate it from where it's imported, I guess
[22:28] <arigo> std/objspace.py
[22:31] <stakkars> ahem :-)
[22:31] <ericvrp> py/execnet/testing/test_gateway.py[68] .............F is taking a very long time. I see /usr/bin/python -u -c exec input() functions running, but they take up *no* cpu time. Could there be something wrong with my system setup?
[22:35] <hpk> ericvrp: this is a 'py' lib question, py != pypy
[22:35] <ericvrp> never mind
[22:35] <arigo> hpk: we should include ChangeMaker as a partner in the release announcement
[22:36] <ericvrp> :( I just realized that :(
[22:36] <hpk> arigo: right, i forgot them because i just took the list from the copyright holders
[22:36] <hpk> arigo: do you do it?
[22:36] <arigo> ok
[22:37] <hpk> arigo: may i also ask for the mission statement?
[22:38] <arigo> hum
[22:38] <hpk> ericvrp: but to answer your question: it'S probably a bug, some teardown issues for the involved gateways are still not ironed out
[22:40] <arigo> hpk: going home now, thinking about the mission statement at home or tomorrow
[22:41] <hpk> ok, have a nice night then
[22:41] <hpk> i am going to try to resolve some issues and see what remains left
[22:43] <arigo> hpk: off-topic, I've also a change in execnet that removes the two teardown messages and uses the teardown of the low-level inputoutput as an equivalent signal
[22:43] <arigo> will work more on it after the release, though :-)
[22:43] <hpk> :-)
[22:44] <arigo> g'night
[22:44] <hpk> night
[22:44] arigo (~arigo@ratthing-b409.strakt.com) left irc: Read error: 104 (Connection reset by peer)
[22:45] Action: hpk is slightly unhappy that nobody joined in pushing for a more concerted issue discussion/resolving
[22:47] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[22:52] ericvrp (ericvrp@ericvrp.demon.nl) left #pypy.
[22:53] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: " * Blackened *"
[22:53] ericvrp_ (~chatzilla@ericvrp.demon.nl) joined #pypy.
[22:58] Nick change: ericvrp_ -> ericvrp
----- silence for 17 minutes ----- [23:15] <stakkars> classobjinterp is gone
[23:19] Nick change: hpk -> hpk_away
[23:20] <stakkars> autopath missing in test_sysmodule
[23:21] <stakkars> fixed
[23:21] <stakkars> ahh,adeadone:-)
----- silence for 16 minutes ----- [23:37] ericvrp (~chatzilla@ericvrp.demon.nl) left irc: Remote closed the connection
[23:40] ericvrp (~chatzilla@ericvrp.demon.nl) joined #pypy.
[00:00] --- Fri May 20 2005