==== Channel ##pypy: 03/17/05 ====

[00:05] <Fade> etrepum: yeah, it doesn't build on amd64, and the patch from the forums doesn't apply. ;)

----- silence for 26 minutes -----

[00:31] _hannes (exulzcj@i3ED6B13E.versanet.de) left irc: "utz utz utz"

----- silence for 3 hr and 55 minutes -----

[04:26] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)

----- silence for 1 hr and 47 minutes -----

[06:13] idnar (mithrandi@idnar.user) left irc: No route to host

----- silence for 52 minutes -----

[07:05] sanxiyn (tinuviel@sparcs.kaist.ac.kr) joined #pypy.

----- silence for 41 minutes -----

[07:46] idnar (mithy@idnar.user) joined #pypy.

[07:57] sanxiyn (tinuviel@sparcs.kaist.ac.kr) left irc: "Bye"

----- silence for 24 minutes -----

[08:21] adim (~adim@logilab.net2.nerim.net) joined #pypy.

----- silence for 1 hr and 24 minutes -----

[09:45] idnar (mithy@idnar.user) left irc: Client Quit

[09:57] idnar (mithy@idnar.user) joined #pypy.

[10:12] mwh (~user@pc150.maths.bris.ac.uk) joined #pypy.

----- silence for 17 minutes -----

[10:29] <mwh> anyone here alive?

[10:32] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.

[10:38] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: "Leaving"

[10:44] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.

----- silence for 1 hr and 4 minutes -----

[11:48] Continuity (kittish@host81-155-189-38.range81-155.btcentralplus.com) joined #pypy.

[11:48] Action: mwh wanders off

[11:55] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)

[11:58] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.

----- silence for 25 minutes -----

[12:23] arigo (~arigo@hp0.cs.uni-duesseldorf.de) joined #pypy.

[12:35] hpk_ (~holger_kr@mail.trillke.de) joined #pypy.

[12:36] <hpk_> arigo, hi armin

[12:37] <hpk_> so you are happiily in duesseldorf?

[12:37] <arigo> hi

[12:37] <arigo> yes :-)

[12:37] <hpk_> even online: i am impressed :-)

[12:38] <hpk_> is the paperwork going well?

[12:39] <arigo> yes

[12:40] <arigo> people around here are quite helpful.

[12:40] <arigo> I've got a room in a shared 4-rooms flat for the 3-4 weeks after PyCon

[12:41] <arigo> I cannot begin my employment today, as expected, but it'll start the week after PyCon.

[12:41] <hpk_> sounds good, would be better if you can get your travel costs reimubersed though

[12:41] <arigo> unlikely

[12:42] <arigo> the strangest thing I still have to get is the "Freizuegigheitsbescheinigung"

[12:42] <arigo> Germany cannot ask EU people for a work permit any more,

[12:42] <arigo> so German Laenders just ask them something else with a new name that is more or less the same thing

[12:43] <arigo> -- or -- the art of working around the rules :-(

[12:43] <hpk_> arg

[12:43] <arigo> however, now that I have a temporary address in Duesseldorf, it shouldn't be too hard

[12:43] <hpk_> but i think it's a simpler thing

[12:44] <hpk_> it basically means that you have to prove that you allowed to be in germany, i think

[12:44] <arigo> I hope so, yes

[12:46] <arigo> the ACCU sprint is before ACCU, isn't it?

[12:47] <hpk_> to be hnonest: i have no clue

[12:47] <hpk_> has it ever been fixed?

[12:47] <arigo> dunno

[12:48] <arigo> ah no, the home page says "trying to organize a PyPy sprint in Oxford the week after"

[12:50] <hpk_> exactgly, i was just reading that as well

[12:51] <hpk_> it seems that Oxford may actually become a sprint that i might miss

[12:52] <hpk_> but i don't know yet

[12:53] <arigo> ok

[12:54] <hpk_> it depends on a few things i can't predict at the moment

[12:54] <hpk_> something else

[12:54] <hpk_> i saw your commits to the documentation: nice

[12:55] <hpk_> reminded me to write about the release scheme which i am doing right now :.-)

[12:55] <arigo> :-)

[12:56] <arigo> I wanted to work a bit on it on the train, but didn't have an svn-updated version

[12:56] <arigo> so I worked on cleaning up genc.py instead

[12:56] <hpk_> :-)

[12:56] <arigo> reminds me to check in class charseq

[12:56] <arigo> with minor hacking around, _formatting.py can be reused successfully.

[12:57] <hpk_> hehe

[12:57] <hpk_> i guess py.test could use it for reporting basically

[12:58] <hpk_> so that it's easy to e.g. preserve information when presenting things in a pygame or hacked rxvt-window

[12:58] <arigo> yes, though we should do a few integration-in-Python efforts

[13:00] <hpk_> what specifically are you thinking of?

[13:01] <arigo> a couple of things

[13:01] <arigo> if we don't want to hack str.join and str.__mod__

[13:01] <arigo> then we need a nice and simple replacement for them

[13:02] <arigo> maybe charseq().join(lst) is short enough

[13:02] <arigo> and charseq('hello %s!') % username looks slightly strange

[13:02] <Jerub> arigo: I would be interested in help improving the netrek client, btw.

[13:04] <arigo> Jerub: just asking, it's unrelated to colored strings, right?

[13:04] <arigo> or PyPy?

[13:04] <Jerub> arigo: you were in #netrek the other day weren't you?

[13:04] <arigo> (just trying to figure out this 'btw')

[13:04] <arigo> no

[13:04] <Jerub> okay. someone using your nick.

[13:05] <Jerub> aka 'ariqs' too.

[13:05] <arigo> ah, 'ariqs' is not 'arigo' :-)

[13:05] <Jerub> he also used 'arigo'

[13:05] <arigo> ok

[13:05] <Jerub> very strange.

[13:05] <arigo> I never had a nickname conflict, so indeed it is

[13:06] <Jerub> arigo: I was quite surprised, as he said "I would have to improve my programming skills"

[13:06] <hpk_> arigo, indeed, especially the mod operator is cumbersome to integrate nice enough

[13:06] <arigo> Jerub: :-)

[13:06] <hpk_> hehe, that kind of proves it wasn't armin :-)

[13:06] <Jerub> arigo: and not 4 hours after that conversation, I mentioned the bug with signed numbers here.

[13:06] <Jerub> and you responded.

[13:06] <arigo> well depends if he was talking about C# or Visual Basic :-)

[13:06] <Jerub> Python and C

[13:07] <Jerub> well, C

[13:07] <arigo> yes, I remember this bug

[13:07] <Jerub> btw, love the work you're doing on pypy.

[13:07] <arigo> it's a well-known little problem of Python 2.4

[13:07] <arigo> tnx

[13:07] <Jerub> arigo: I found a problem not long ago that stumped me.

[13:08] <Jerub> "%f" % 2**32

[13:08] <arigo> hpk_: maybe we just have to hack str.__mod__ along with str.join and be done with it

[13:08] <Jerub> hold on, that's working now.

[13:08] <arigo> hpk_: using an optional C extension

[13:08] <hpk_> arigo, makes sense

[13:09] <hpk_> prob a bl y

[13:09] <Jerub> oh, here.

[13:09] <Jerub> "%d" % float(2**32)

[13:09] <arigo> I see

[13:09] <arigo> using floats with %d is kind of deprecated

[13:10] <arigo> here I see that "%d" only accepts floats that fit in an 'int'

[13:10] <Jerub> well, it doesn't work for any float greater than 2**31-1

[13:10] <Jerub> imho, it should either work, or die, not throw errors on certain cases.

[13:11] <arigo> yes, it makes sense

[13:11] <Jerub> it took a small amount of effort to not get the bug striken as not being a bug on the bug tracker.

[13:11] <Jerub> at least it's now on there waiting for attention.

[13:12] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 110 (Connection timed out)

[13:16] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.

[13:19] Jerub (~gideon@CPE-203-45-251-238.qld.bigpond.net.au) left irc: "Lost terminal"

[13:23] tic (~vision@213.115.110.153) joined #pypy.

[13:26] arigo (~arigo@hp0.cs.uni-duesseldorf.de) left irc: "lunch"

----- silence for 1 hr and 38 minutes -----

[15:04] pedronis_ (pedronis@ratthing-b246.strakt.com) joined #pypy.

[15:04] jacob22 (jacob@62.119.131.75) left irc: Read error: 54 (Connection reset by peer)

[15:04] pedronis (pedronis@ratthing-b246.strakt.com) left irc: Read error: 104 (Connection reset by peer)

[15:07] jacob22 (jacob@enzo.strakt.com) joined #pypy.

[15:09] Nick change: pedronis_ -> pedronis

----- silence for 21 minutes -----

[15:30] stakkars (~tismer@82.144.60.19) joined #pypy.

[15:36] idnar (mithy@idnar.user) left irc: "kbye"

----- silence for 22 minutes -----

[15:58] _hannes (mlsdfv@i3ED6B13E.versanet.de) joined #pypy.

[16:09] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.

----- silence for 19 minutes -----

[16:28] arigo (~arigo@hp0.cs.uni-duesseldorf.de) joined #pypy.

[16:35] <arigo> hpk_: release scheme sounds good, though we'll need to discuss a bit during the sprint what exactly we want to add for release 0.6

[16:35] <hpk> arigo: yes, i agree

[16:35] <arigo> also, it may make sense to adopt CPython's release numbers

[16:35] <hpk> in which wayß

[16:35] <hpk> ?

[16:35] <arigo> have "2.3" at the beginning of the release number

[16:36] <arigo> I know we are releasing more than an interpreter

[16:36] <hpk> hum, maybe

[16:36] <arigo> but still, it would make it clear what the interpreter is supposed to be compatible with

[16:36] <arigo> otherwise, we can put "2.3" elsewhere too

[16:37] <hpk> having a table with pypy-release numbers mapping to cpython compliancy may suffice

[16:37] <hpk> having something like pypy-2.3.4-0.6 or pypy-0.6(2.3) or whatever just is messy

[16:37] <hpk> and what if we release pypy and support both python 2.3 and 2.4?

[16:38] <hpk> pypy-2.3-and-2.4-0.6 :-)

[16:38] <arigo> :-)

[16:38] <hpk> but we need to decide if we stay with 2.3 in april or go for 2.4

[16:39] <hpk> if we would directly go for 2.4 anyway, then there will not be much confusion in 2005 i guess

[16:39] <pedronis> hi

[16:39] <stakkars> hi

[16:39] Action: hpk has prepared another mail that tries to tackle the fact that we are always discussing on IRC and almost never on pypy-dev .-Ö)

[16:39] <arigo> still, I think that using 2.3 in the name somewhere would emphasis it's not a language branch or a rewrite-from-scratch based on the language spec (which is quite less precise than needed)

[16:39] <arigo> hi

[16:39] <hpk> pedronis, stakkars: hi

[16:40] <hpk> arigo: but i tend to think it's sufficient to state that and not have it encoded in the pypy release numbers

[16:40] <pedronis> I think it may be enough if it is printed at the prompt

[16:41] <pedronis> but I see the problem with putting it in the release number

[16:41] <hpk> right, also we'll be hammering the compliancy issues (to python-the-implementation) at pycon :-)

[16:41] <pedronis> OTOH

[16:42] <pedronis> we should think what to put

[16:42] <pedronis> in the various version related attrs in sys

[16:43] <hpk> yes

[16:44] <stakkars> maybe just our version, and sys.version tells it (pypy v.xxx on top of blah),

[16:44] <stakkars> then some extra info in sys which lists the Python versions this PyPy versions has beentested with?

[16:44] <arigo> no, I think sys.version_info should match CPython's

[16:45] <arigo> user programs might be testing for it to decide which feature to use (though it's a bad thing to do I agree)

[16:45] <stakkars> but compare what others do, PyWin for instance.

[16:45] <pedronis> arigo: I agree

[16:46] <hpk> something else: who is going to give the introduction on saturday morning

[16:46] <hpk> and how do we structure that?

[16:47] <arigo> depends on what the people here expect

[16:47] <arigo> and what they want to work on

[16:48] <arigo> unless we'd like to focus them on some preferred aspects

[16:48] <arigo> like CPython compliance and C modules

[16:48] <hpk> which was the original "main" issue

[16:48] <arigo> yes

[16:48] <hpk> we have some new people so we definitely need that track

[16:49] <hpk> and we should make sure that at least on the first and second day we have good pairings

[16:49] <dialtone> hurray for Python 2.4 :)

[16:49] <dialtone> that won the Jolt productivity award

[16:49] <hpk> dialtone: hi valentino :-)

[16:49] <dialtone> hpk: hi boy :)

[16:50] <arigo> :-)

[16:51] <hpk> stakkars: you said something that you wouldn't mind giving the introduction or some such ...

[16:53] <arigo> what about sending a mail to pypy-sprint: "last-minute overview to print and read in the plane"

[16:54] <arigo> just a few links to the doc

[16:54] <arigo> about what people should read to know how to code interp-level stuff

[16:54] stakkars (~tismer@82.144.60.19) left irc: Read error: 104 (Connection reset by peer)

[16:54] <hpk> ok, who is next? :-9

[16:54] <hpk> arigo: makes sense

[16:55] <hpk> although i guess that most of them will already have done that

[16:55] <arigo> we have no doc about *where* to put things but we have for *how* to write them

[16:55] <arigo> yes

[16:55] <hpk> indeed

[16:55] <arigo> but then it's easy to just make sure they did :-)

[16:55] <hpk> i wonder if we shouldn't start off with half a day of fixing and writing documentation :-9

[16:55] <arigo> hum

[16:56] <arigo> we need a fast typer to record the spoken presentation into documentation/*.txt :-)

[16:56] <hpk> ok ok, maybe a bit dry

[16:56] <hpk> well, maybe we just start easy and basically copy the introduction from Leysin

[16:56] <hpk> someone doing the pygame thingie

[16:57] <hpk> and another someone doing the source-code walk through

[16:57] <arigo> ok for the code walk through, the pygame one depends on the goal

[16:57] <hpk> the pygame one is just a nice start, i'd say

[16:57] <hpk> and it surely helps to understand the basic workings, no?

[16:58] <arigo> yes, it might help in guessing where the limit is between app- and interp-level

[16:58] <arigo> though that is always very fuzzy

[16:58] <arigo> it's a nice show, though.

[17:01] <hpk> ok, i could do either the pygame one or the code walk through, i guess, but not both :-)

[17:02] stakkars (~tismer@82.144.60.19) joined #pypy.

[17:02] <stakkars> hpk: did I? Oh dear.

[17:03] <hpk> stakkars: you mentioned something along the lines "next sprint i can imagine caring for the newbies for one or two days" or so

[17:03] <stakkars> Ah, I remember. It was meant as how I would like to see all of us acting.

[17:04] Nick change: dialtone -> dial|hAWAYii

[17:04] <stakkars> But if you want me to sing and dance, I will do.

[17:04] <stakkars> do you know about the sprint location? One room or two?

[17:05] <hpk> nothing exactly, i asked that on pypy-sprint as well and jacob gave some information

[17:05] <hpk> but it

[17:05] <hpk> but it's not all that concrete regarding room numebrs and all

[17:06] <hpk> we will have a beamer though and armin and me discussed to do a two-element introduction:

[17:06] <stakkars> yes I saw it.

[17:06] <hpk> ah ok

[17:06] <hpk> the pygame show and a code walk through and then some pairing

[17:06] <stakkars> about two-element intro: I missed that, I was dropped from irc

[17:07] <hpk> much like in leysin: one person giving the pygame demo and verbosely explaioning things

[17:07] <hpk> and another who dives into the directories (slow and verbose enough so people can follow) and discusses various places in the code

[17:08] <hpk> arigo: did you realize that the pypy talk is on the first pycon day?

[17:08] <hpk> and the py.test/lib talk is on the very first morning, ugh

[17:12] <arigo> :-)

[17:13] <arigo> I'm of course OK for doing one of the two intro shows

[17:14] <stakkars> me too

[17:14] <stakkars> but tell me if I need to prepare something on the flight.

[17:16] <arigo> I don't think we should talk for more than 2x15 minutes or so

[17:16] <hpk> i think we talked a bit longer in Leysin and that was ok

[17:17] <hpk> but at most 30 minutes i agree

[17:17] <arigo> ok

[17:17] <hpk> (i meant 2 x 30, although the pygame talk probably only lasts 15 minutes indeed)

[17:18] <hpk> hum, what do you all expect regarding working on translation?

[17:18] <arigo> it looks like it's better to work on it off-sprint now

[17:19] <arigo> I'd rather have us stay around answering interpreter & module questions than digging deep inside the translator for 4 days

[17:20] <hpk> agreed. also i think we might want to go for a real and extended translation/annotation/self-contained pypy around EuroPython

[17:20] <hpk> (which nicely fits the release schedule :-)

[17:20] <arigo> :-)

[17:21] <pedronis> but I think we need to push for results ahead of the releases

[17:21] <arigo> the point here is that what's left for translation/annotation is quite obscure and should be worked on as soon as possible but by "core members" preferrably

[17:22] <arigo> though I agree that the Lithuanian sprint was great, including Marcus

[17:22] <hpk> i guess so as well

[17:23] <arigo> I agree to push for results after PyCon :-)

[17:23] <pedronis> I agree that a 4 day sprint is not the right context

[17:23] <arigo> we all agree, great :-)

[17:23] <pedronis> but I think we need to schedule some discussion time (maybe even during the con, not the sprint)

[17:24] <pedronis> to see what we want to do next

[17:24] <hpk> indeed

[17:24] <arigo> ok

[17:29] <hpk> stakkars: ok, so you do the pygame presentation?

[17:35] <hpk> hum, we still have 10am- on the main pycon sprint page

[17:35] <hpk> i'd rather have 8 or 9 am (arigo, relax, you'll be up at 4am because of the jet lag anyway :-)

[17:37] <arigo> others coming from the other direction might prefer 10am :-)

[17:37] <hpk> ah

[17:38] Nick change: dial|hAWAYii -> dialtone

[17:44] houcj (~houcj@hougpat-8.netiq.com) joined #pypy.

[17:45] <houcj> is there a faq or readme why pypy is a good thing ?

[17:45] <houcj> telling

[17:45] <houcj> why

[17:45] <houcj> was it made just for fun ?

[17:46] <arigo> :-)

[17:46] <arigo> there is a "goals" document

[17:47] <arigo> hum, this "goals" document isn't what I thought

[17:48] <stakkars> basically, the real goal *is* fun (but don't tell the EU), with hopefully the side effect of creating something really useful.

[17:50] <arigo> we almost all have own goals, actually, which PyPy should independently help with

[17:50] <arigo> one of my goals is to reimplement Psyco in PyPy

[17:50] <arigo> a better Psyco.

[17:50] <houcj> ok jython implements python in java , you write python and execute in java interpreter. in cpython you write in python and execute in c. in pypy you write in python and execute in cpython.

[17:52] <arigo> we run in CPython but mainly for debugging and testing

[17:52] <arigo> we then translate the code to another lower-level architecture

[17:52] <houcj> i am reading http://www.python.org/pycon/dc2004/papers/27/

[17:53] <arigo> which is unspecified in advance -- could be C, could be Java, could be .net

[17:53] hpk_ (~holger_kr@mail.trillke.de) left irc: Read error: 113 (No route to host)

[17:53] <houcj> ok so you could write an executer in any langeauge ?

[17:54] <arigo> yes -- a "translator", or "simple compiler", that turns our Python source into whatever other language/run-time-system combination we want to target

[17:55] <arigo> (btw the paper at the above link is quite informative and still up-to-date)

[17:56] <houcj> It would be nice if a version of this was on the pypy home page.

[17:56] <arigo> yes, indeed

[17:56] <houcj> i think i will email some one

[17:56] <arigo> actually, it is there

[17:56] <houcj> oh

[17:57] <arigo> it's the "architecture" document, which contains a few updates

[17:57] <houcj> ok

[17:57] <stakkars> houcj: one of my major goals is to get rid of Stackless Python, by integrating it into PyPy as an option at least.

[17:58] <hpk> i guess Armin's and Christian's goals are the most conrete ones in some sense

[17:58] <hpk> which is why they are mentioned on the very home page :-)

[17:59] idnar (mithrandi@idnar.user) joined #pypy.

[17:59] <dialtone> houcj: if they really finish within 2005 it's likely Pypy will become Python 3000 :)

[17:59] <stakkars> well, those are easy to spell, something touchable. I cannot always try to convince everybody that I think PyPy will be the next real Python.

[18:00] <hpk> well, we could use a versioning scheme like:

[18:00] <hpk> pypy-2800, 2801, ... :-)

[18:00] <arigo> to increase confusion we could start numbering at 3.0 :-)

[18:01] <pedronis> :)

[18:01] <hpk> yes, something liek this

[18:01] <hpk> i thought 2800 is a bit more humble, y'know

[18:01] <houcj> ok the first paragraph of the url above , is not included in the architecture page. It is really helpful.

[18:02] <houcj> maybe it will become too dated to have on the architecture page

[18:02] <arigo> houcj: it makes sense, I'll try to update it and paste it into the architecture page

[18:03] <houcj> thanks for the help , guys,

[18:03] <houcj> this sounds like an exciteing project

[18:04] <hpk> hey! is laura not coming?

[18:05] <stakkars> on numbering: how about backwards? PyPy is getting Python back to the roots. We start with version 42, and when we are at 1.0, we are done.

[18:05] <arigo> :-)

[18:05] <hpk> i wouldn't actually mind _some_ sillyness with the version numbering

[18:06] <stakkars> all primenumbers,or everMIRP

[18:06] <arigo> laura's not coming? we didn't hear news about her silly passport issues

[18:06] <stakkars> mirp = primepalindrome :)

[18:06] <hpk> i haven't heard from laura anything lately

[18:06] <hpk> pedronis: do you know anything?

[18:06] <stakkars> that's why I assumed the would come.And she called me last Friday, no word about not coming.

[18:07] <hpk> hum

[18:07] <hpk> i came to this conclusion reading the pypysprint web page

[18:07] <hpk> where i am sure she was on at some point

[18:07] <pedronis> hpk: not explicitly

[18:08] ludal (ludal@logilab.net2.nerim.net) left #pypy.

[18:09] <hpk> stakkars: did you ever say yes to making the pygame-show?

[18:12] <arigo> hum, the interpreter module and objspace/std directories used to be 15000 lines of code + 7000 of tests

[18:12] <arigo> now they are 29000 lines of code + 7000 of tests

[18:12] <arigo> I guess we started using CPython's tests lately

[18:13] <stakkars> hpk: I said yes to give some introduction. For the pygame thing, I would need to learn to use that, tomorrow (possible)

[18:13] <hpk> it's mostly a matter of pressing the space-bar IIRC

[18:13] <stakkars> hpk: PROPFIND request failed on '/svn/pypy/dist' appears when I try to update. Something wrong with codespeak?

[18:13] <stakkars> hpk: ok, then I will exercise that a bit:-)

[18:14] Action: hpk recovers svn on codespeak, (argl!)

[18:14] Action: hpk finished

[18:14] Action: stakkars wonders if there are hardware problems?

[18:14] <hpk> nono

[18:14] <hpk> i can't fix hardware problems remotely in like 20 seconds, y'know

[18:15] <hpk> there are more people using svn+ssh urls and there seems to be some concurrency issues

[18:15] <hpk> (actually these days there are http/https and svn+ssh urls in use)

[18:16] <arigo> (sorry, number error: only 22000 lines of code without tests)

[18:16] <hpk> arigo: ?

[18:18] <hpk> does anyone know if you need a real power transformer or if a simple adapter is enough for US/EU power conversion?

[18:19] <etrepum> hpk: depends on the device

[18:19] <hpk> powerbook

[18:19] <etrepum> hpk: simple adapter

[18:19] <arigo> hpk: re ?: that was a follow-up to my previous babbling

[18:20] <hpk> arigo: ups, i completly missed that somehow

[18:23] <stakkars> hpk: most newer notebooks have mixed supply. I'm not sure with Armin's notebook, it's a bit aged.

[18:24] <arigo> stakkars: it's fine with 110V, thanks :-)

[18:25] <stakkars> arigo: I saw your genc reworking. What is the intent? Do you think the genc part is the one to be generalized, or not at all?

[18:26] <arigo> stakkars: I don't really know, it was a needed clean-up

[18:26] <stakkars> Imean, do we still want to extract a general framework, which looks quite hard. I did a couple of attempts but thrashed them.

[18:26] <arigo> I imagine

[18:27] <arigo> we could try a few more attempts

[18:27] <arigo> e.g. genc.py is now mainly a ton of nameof_xxx() definitions

[18:27] <stakkars> what I'm trying is to find a way to express certain things without spelling them in C.

[18:28] <stakkars> yes, it might be possible to generalize that. So you don't see advantage in ripping the C part into configuarable pieces? Probably much effort and not much gain.

[18:29] <arigo> the C FunctionDef class could be made to subclass a general FunctionDef

[18:30] <arigo> which would use the "nameof()" interface provided by a generator, and provide "expr()" and some functionality from cfunction_body()

[18:30] <stakkars> at themoment, it is sort of housekeeping code wrapped around C snippets.

[18:30] <hpk> arigo: it's mostly the module directory that is turning the ratio very bad

[18:31] <arigo> hpk: oh

[18:31] <hpk> arigo: objspace and interpreter are mostly 2:1 regarding code:tests

[18:32] <stakkars> it is by no means declarative, but all actions. If we parameterize that, we get unreadable, hard to configure code.

[18:32] <arigo> stakkars: yes, and in addition the problem is that various code gens need different bookkeeping details

[18:33] <stakkars> that's the problem,and that's why none of my attempt was really worth to replace the direct code.

[18:33] <stakkars> The question is if we can move to some template system, where the code layout can be specified in

[18:33] <arigo> it might be worth to provide just a few helpers

[18:33] <stakkars> a readable (more readableasnow) way,and then there are rules how tomake it a program.

[18:34] <hpk> arigo: i committed a "py.countloc" script which we can refine to have a common trackaable measuring ...

[18:34] <stakkars> yes, makes sense.

[18:34] <arigo> the nameof() nonsense is still larger than genc_funcdef.py

[18:35] <arigo> some idea based on Repr classes as in genllvm might be good

[18:35] <stakkars> yes, I looked at that. I just hesitated todo a whole re-write.

[18:36] <pedronis> arigo: yes

[18:36] <stakkars> but maybe it is faster to do so than morphing the old stuff again and again?

[18:36] <arigo> we could at least move it somewhere else; then the remaining genc.py would be mostly language-neutral

[18:36] <pedronis> one issue is that sometimes what to emit may change by context

[18:37] <pedronis> there's some cases of that in geninterp

[18:37] <stakkars> the nameof stuff is not identical for the genc and geninterp case, unfortunately.

[18:37] <stakkars> so eve there I got stuck.

[18:39] <pedronis> well, we should also try to use annotator results when generating code

[18:39] adim (adim@logilab.net2.nerim.net) left #pypy.

[18:39] <pedronis> this open another set of problems

[18:40] <arigo> "another can of works" would be more appropriate

[18:40] <arigo> "another can of worms" even

[18:40] <pedronis> I was about to write that

[18:40] <pedronis> but restrained myself ;)

[18:41] <pedronis> but code generation is the open front right now

[18:41] <arigo> indeed

[18:42] <pedronis> the annotator is doing at least a decent job

[18:42] <pedronis> and further serious problem can probably only be discovered

[18:42] <pedronis> by trying to generate code based on the results

[18:43] <arigo> makes sense

[18:43] <arigo> actually (don't hit) I thought about C++ code generation again

[18:43] <arigo> at least to generate suboptimal code

[18:44] <arigo> (i.e. with suboptimal memory layouts or overdoing reference counting)

[18:44] <pedronis> yes, also trying java using the annotation might make sense

[18:44] <arigo> possibly even more sense, given the GC

[18:44] <pedronis> yes

[18:44] <arigo> but C++ is easier for a CPython extension module

[18:44] <pedronis> yes

[18:44] <pedronis> although there's GCJ as possible path

[18:45] <arigo> yes

[18:45] <pedronis> but indeed discussing what targets make more sense

[18:45] <arigo> we could first tell genc.py to put assert statements everywhere to check the annotations at run-time :-)

[18:45] <pedronis> but we should really try to get some translated baseline

[18:46] <pedronis> to get an idead of how much work is there

[18:46] <pedronis> especially at some point performance wise

[18:46] <arigo> makes sense

[18:47] <stakkars> on the C++ idea: I thought of this, too,especially because it would hide all the refcounting mess andproduce shorter code,probably. Not using fancy C++ stuff, just the good things,like name spaces...

[18:47] <arigo> makes sense

[18:48] <arigo> though possibly not performance-wise

[18:48] <stakkars> with the right constructors/destructors, it would do the same with obects as the genc c code does, explicitly.

[18:49] <arigo> no, I thought of this, and there is a problem:

[18:49] <arigo> passing values around a link from one variable to another

[18:49] <arigo> in genc.py there is no dummy INCREF/DECREF pair at this point

[18:49] <stakkars> and on performance, I'm not so sure. If you look at the machine code,all the refcount macros create a huge pile of junk code, while we could adopt asmall dealloc routine with an array of indices into an array of local vars to deallocate.

[18:50] <arigo> yes, I also considered this

[18:50] <stakkars> oh, you are right.

[18:50] <arigo> an array of locals kills all gcc optimisations

[18:50] <arigo> again mainly because of variables being passed around in links

[18:50] <stakkars> well, what I thought to do about genc --- wait

[18:51] <stakkars> yes, it kills them, and this is just fine. There is no need to have gcc optimizations, unless it is able to foldall the many block variables.

[18:52] <arigo> well, it is able to do so

[18:52] <stakkars> But I think, through our decref in every error case, exactly this possibility vanishes, because the locals are arguments to the internal decref func call.

[18:53] <arigo> I don't think it matters

[18:53] <stakkars> well, I can live without optimizations of true Python objects.

[18:53] <stakkars> What we want is good code for the annotated stuf, right?

[18:53] <arigo> if you say "b=a; c=b; d=c; Py_DECREF(d);" it's easily optimised to Py_DECREF(a)

[18:53] <arigo> stakkars: that's an excellent point

[18:54] <pedronis> yes

[18:54] <arigo> for refcounters though, we'll probably have to do it anyway for almost anything apart from ints

[18:54] <stakkars> yes, I say that the general PyObject things are anyway slow, why waste so much code, and even packthis some more. Then let's optimize the real meat.

[18:55] <stakkars> ok, I agree. But finally, I think we can soon get rid of most extra variables, because I'm going to do nested blocks.

[18:55] <arigo> I don't know if it's useful

[18:55] <arigo> as you said, it's a limited problem -- only for the error Py_DECREFs

[18:57] <stakkars> ok! Then, if we initialize all variables, then we can shrink the error label stuff very much and always do a deallocof the whole locals block, not the battery of single error PyDecrefs, and this would be a tiny loop with PyXDECREF.

[18:59] <arigo> yes, but wouldn't the non-error case be slower then?

[18:59] <arigo> I mean, to do it all correctly, we need some kind of a graph coloring algorithm

[19:00] <arigo> otherwise, we really have tons of variables being copied around

[19:00] <arigo> which are not a problem for gcc to optimise away currently

[19:01] <stakkars> ah, now I got it. Didn't see that in the first place. Shure, you are decreffing objects via alias variables. hum hum.

[19:04] <stakkars> no, where is the problem to replace the error decref by one decref? I didn't mean to do a global thing, but just to have the many error cases perblock folded into one per block

[19:05] <arigo> the problem is to know how far we arrived, i.e. how many vars we must release

[19:05] <stakkars> right now there is a case for every variable, ordered by code location, and then exactly the right deallocs are done.

[19:05] <stakkars> Yes, but by initilializing them all to NULL, we can do a loop of PyXDecrefs.

[19:05] <arigo> argh

[19:06] <arigo> that's bad performance-wise, and you can't loop over them all unless they are in an array -> kills the optimisation again

[19:06] <arigo> if I think in term of machine code, the most compact solution I figure out would be:

[19:07] <arigo> err2_4: table[4] = v1498;

[19:07] <arigo> err2_3: table[3] = v1428;

[19:07] <arigo> err2_2: table[2] = v1512;

[19:07] <arigo> err2_1: table[1] = v1340;

[19:07] <arigo> err2_0: table[0] = v1341;

[19:07] <arigo> return release_table();

[19:07] <stakkars> ok, fine with me. And it ends - yes

[19:07] <stakkars> still huge code, but much better.

[19:08] <arigo> where 'table' is initialized with zeroes, and maybe a global var

[19:08] houcj (~houcj@hougpat-8.netiq.com) left irc: "Chatzilla 0.9.64d [Mozilla rv:1.7/20040614]"

[19:08] <arigo> but accessing a global variable is bad in PIC code

[19:09] <arigo> well but now I think that it's not that important, given that a lot of uniformly PyObject* variables should become uncommon with annotations

[19:09] <stakkars> no, it's fine to have it as a local variable. It could even be local to the block, and we could wrap the block with {} for that.

[19:10] <arigo> it can't be local unless we completely fill it with zeroes all the time, can it?

[19:10] <arigo> ah, we could do "p = global_table;" at the beginning of the function,

[19:10] <stakkars> must be zeroed,of course. But as said, I'm not after speed on theseobjects, I'm after size.

[19:10] <arigo> and then

[19:11] <arigo> err1_4: p[4] = v1148; etc.

[19:11] <stakkars> it is a very cheap repz stosd to initialize the table.

[19:12] <arigo> I fear lots of sp adjustements...

[19:12] <arigo> but maybe I'm wrong

[19:12] <stakkars> What I want to optimize at the moment is compile time, binary size, all of that, until we have code that is really worth optimizing.

[19:12] <arigo> ok ok

[19:12] <arigo> makes sense :-)

[19:13] <pedronis> yes

[19:13] <arigo> I think genc_funcdef.py almost cut the number of functions in half

[19:13] <arigo> which is not so bad either :-)

[19:16] <arigo> pedronis: how did translate_pypy0.py ever work without nameof(NotImplemented) to initialize the w_NotImplemented attribute of the space?

[19:17] <pedronis> I think I never tried it without annotations

[19:17] <stakkars> yes,a good thing, that.

[19:18] <arigo> pedronis: oh

[19:18] <stakkars> I thought even further, considering the produced code not even worth to be compiled into C directly, but

[19:18] <stakkars> to build a tiny bytecode engine, again, or maybe a small register engine, which can operate the

[19:19] <stakkars> operations of a code block. And a code block would be a series of opcodes with some args, ahem,like a frame.

[19:19] <arigo> would be easier to just use CPython bytecodes, for dispatches to PyNumber_Xxx&friends

[19:19] <stakkars> Being rendered into C code isn't worth it, that's why the Python interpreter makes sense.

[19:20] <stakkars> if we can map all our operations to that, why not! It would shring the code output by a factor of ten at least, and speed would degrade by not more than 1.5

[19:20] <stakkars> maybe.

[19:21] <hpk> do the translate_pypy*'s work for anybody at the moment?

[19:21] <arigo> genpybytecode.py would be rather easy to write in an "in-memory-only" approach, making nameof() trivial

[19:21] <stakkars> this makes even more sense for compatibility issues,like doing periodic things.

[19:22] <arigo> hpk: not translate_pypy0.py

[19:22] <pedronis> but it never worked

[19:22] <arigo> ah ok

[19:23] <pedronis> that means I used to play with the annotator

[19:23] <hpk> i thought that translate_pypy1.py used to work

[19:23] <pedronis> used it

[19:23] <pedronis> translate_pypy1 should work

[19:24] <hpk> i get an assertion error, translator.py, line 77

[19:25] <pedronis> then that's a problem introduced recently

[19:25] Action: arigo blames arigo

[19:31] <arigo> yes it's the revision splitting genc.py in two that breaks it

[19:32] <arigo> ah, it's because there are simple_call operations to a skipped (not-rpython) function

[19:34] Action: pedronis going home to eat and pack

[19:34] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"

[19:43] <arigo> hpk: works again now

[19:47] <hpk> indeed

[19:47] Action: hpk follows pedronis example

----- silence for 20 minutes -----

[20:07] <stakkars> arigo: About creating a half-compiled thingy with Python opcodes:

[20:09] <stakkars> turning every code block into a sequence of address-sized elements, opcodes followed by variable addresses

[20:09] <stakkars> and some do_block() operation that computes the block, including error decref etc?

[20:10] <arigo> genforth.py :-)

[20:10] <stakkars> as we refine things through annotation (yes sure forth), we split this into smaller pieces, intermixed with realmachine code.

[20:10] <arigo> not sure it makes sense if we go for annotations

[20:11] <arigo> because they seem to be doing a rather good job already

[20:11] <stakkars> well, I probably make the mistake to think of integers and chars all the time when we talk annotations.

[20:11] <stakkars> you mean annotations would get us rid of 90% of PyObjects?

[20:11] <arigo> or I did this mistake now

[20:12] <arigo> yes

[20:12] <arigo> but maybe not 90% of all the place where we'd still fall back to PyObjects in genc.py

[20:12] <arigo> so if annotations are only used for ints and chars then the rest is still large

[20:12] <arigo> nevertheless, I'm not sure it's worth the hassle

[20:13] <arigo> specially the part about mixing interpreted and machine code

[20:13] <arigo> well it would be rather fun, I agree :-)

[20:15] <stakkars> only if it makes sense. Kindof optimum between space and time.

[20:16] <arigo> looking for bytecodehacks,

[20:16] <arigo> is the sourceforge version the latest ?

[20:16] <stakkars> if I checked it in, yes.

[20:17] pedronis (~Samuele_P@c-108b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

[20:17] <arigo> did you ? :-)

[20:17] <stakkars> made it work with 2.3 when we were playing with Psyco.

[20:17] <stakkars> erhmm I hope

[20:19] <arigo> I see your name next to "Python 2.3.3" in the logs, should be at least partially in

[20:20] <stakkars> at least I have it under cvs tismerysoft.de:/home cvs bch

[20:22] <stakkars> anyway, this "simple" first approach turns out to be way more effort than we expected,

[20:22] <stakkars> and I think we need to have a round discussion on where we are and where to go.

[20:23] <arigo> you mean, about bytecodehacks and Psyco ?

[20:23] <stakkars> ah, no,about PyPy translation and all the approaches etc. I think we need to do new estimates.

[20:24] <arigo> ah, yes

[20:24] <arigo> I guess so

[20:24] <arigo> also, maybe it makes more sense to try to go CPython-independent

[20:24] <stakkars> I lost track, in a way I feel the problem is bigger than we thought, and we needmore strategy.

[20:25] <stakkars> that was another thing I was thinking of:

[20:25] <stakkars> We wrap the existingpython stuff that we still need into something and interface to that, using much simpler

[20:25] <stakkars> objects, maybe.

[20:26] <stakkars> Because, we want to compile RPython simple things, and only from time to time we need

[20:26] <stakkars> stuff that isn't trnasformed, yet. But we borrow from full-fletched Python.

[20:26] <arigo> the problem is the fake types, which we wanted to pass through genc.py

[20:27] <arigo> it makes genc.py's nameof_xxx() far more messy than needed

[20:27] <stakkars> yes, I think of some wrapper layer which encapsulates that.

[20:28] <arigo> ah ha

[20:28] <stakkars> maybe I'm completely into a dead end, again.

[20:28] <arigo> well ultimately we need to replace the fake types with something real

[20:29] <arigo> which might be provided by a layer using some interface

[20:29] <stakkars> I think of our generated engine, which is seolf-contained upto the point where it needs some fake.

[20:29] <arigo> so it might be a good starting point to build such a layer that actually defers back to CPython

[20:29] <stakkars> Yes, but not dealing with CPython objects visiblefrom the generated Ccode, but something simpler.

[20:30] <arigo> probably makes sense

[20:30] <arigo> we should consider it in the bigger picture, too

[20:30] <stakkars> it is like if you attach to a forth engine, a much simpler engine than Python, and it can do your long operations, too.

[20:30] <arigo> e.g. have an example of "no-longer-faked" thing, i.e. external operations

[20:31] <stakkars> for instance, a still-faked but not really faked thing would be to have a wrapper,

[20:31] <stakkars> that takes an internal representation for a long object, turns it into a real

[20:32] <stakkars> long, does the operation with Python, and then re-transforms. That would be no longer a fake, interface-wise.

[20:32] <arigo> yes

[20:32] <arigo> this would just be using CPython's longs API internally to do the operation.

[20:32] <stakkars> and that would really let us get rid of the Python dependency.

[20:32] <arigo> makes sense, I guess

[20:32] <stakkars> for instance, even so.

[20:33] <stakkars> we could either use the internal stuff,or a huge other way to wrap/unwrap, but this is no fake.

[20:33] <stakkars> Instead, we have a real C object, some representation whch is native for genc's generated code.

[20:34] <stakkars> because it is *our* objects which we want to build. Not related to theobjects Python forces us to use.

[20:35] <arigo> yessish

[20:35] <stakkars> this does not contradict the wish to build PyPy as an extension module, but this would then involve lots of transformations.

[20:36] <arigo> we'll have to talk more about this, and preferrably starting from the "where we want to go" point of view

[20:36] <stakkars> I don't know if I make sense at all. I just feel that we want to get rid of the restrictions of mother CPython.

[20:36] <stakkars> ok, let's do that in DC.

[20:37] <arigo> ok

[20:37] <arigo> I've got bytecodehacks to play with during the plane trip...

[20:37] <stakkars> which one?

[20:37] <arigo> tismerysoft's

[20:37] <stakkars> ah :)

[20:37] <arigo> :-)

[20:37] <arigo> now I can safely go off-line and wish you a pleasant journey :-)

[20:38] <stakkars> same for you. When do you arrive?

[20:38] <arigo> around 6pm at the airport

[20:38] <stakkars> we are there at 18:55

[20:38] <arigo> which airport?

[20:38] <stakkars> IAD whatever that means

[20:39] <arigo> me too

[20:39] <arigo> 18:10 -- I guess I will wait for you

[20:39] <arigo> arriving from where?

[20:39] <stakkars> from Paris. Delta

[20:39] <stakkars> with Lutz

[20:40] <stakkars> Delta 8296

[20:40] <arigo> ok, I'm from London, British Airways 293

[20:40] <stakkars> ok. See youthere, then we can together wonder how to find the place ;-)

[20:41] <arigo> :-)

[20:43] hpk_ (~holger_kr@mail.trillke.de) joined #pypy.

[20:43] <hpk_> arigo, still there?

[20:43] <hpk_> arigo, i am wondering if i left my mobile-power-charging thingie/cable in leysin

[20:44] <arigo> argh

[20:44] <hpk_> could you please bring it? ... just kidding

[20:44] <arigo> :-)

[20:45] <arigo> I'll ask my mother then

[20:45] <hpk_> yah, well, bad luck i guess, i don't like mobiles anyway

[20:45] <arigo> ...sure

[20:51] <arigo> when and where are you landing, btw?

[20:51] <hpk_> 18:55 washington dc

[20:52] <hpk_> IAD is the airport sign

[20:52] <hpk_> and you?

[20:52] <arigo> ah from Paris with Christian?

[20:52] <hpk_> well possible, from paris indeed

[20:52] <arigo> then with Christian :-)

[20:53] <arigo> I'm landing at 18:10 at IAD from London, I'll wait for you both

[20:53] <hpk_> cool, then we can take some form of taxi i guess

[20:53] <arigo> probably, yes

[20:54] <arigo> I mean, makes sense, yes :-)

[20:54] <hpk_> i am wondering how early i need to be at the airport

[20:55] <hpk_> as this is only the flight from hannover to paris (i.e. within europe) i guess not much more than an hour before

[20:55] <arigo> yes, I'd count 1h but not less

[20:56] Action: hpk_ is out for a while again

[20:57] <arigo> see you tomorrow then

[20:58] <arigo> see you all

[20:58] arigo (~arigo@hp0.cs.uni-duesseldorf.de) left irc: "[x]chat"

[20:59] <stakkars> hpk: see you tomorrow in Paris, with Lutz

[21:07] <hpk_> stakkars, see you

[21:08] <stakkars> bye

[21:10] _hannes (mlsdfv@i3ED6B13E.versanet.de) left irc: Read error: 54 (Connection reset by peer)

----- silence for 2 hr and 1 minute -----

[23:11] pedronis (~Samuele_P@c-108b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"

[23:19] stakkars (~tismer@82.144.60.19) left irc: Read error: 60 (Operation timed out)

[23:33] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: No route to host

[23:39] hpk (~hpk@merlinux.de) left irc: Remote closed the connection

----- silence for 18 minutes -----

[23:57] hpk_ (~holger_kr@mail.trillke.de) left irc: Read error: 113 (No route to host)

[23:59] lac (~lac@lac.silver.supporter.pdpc) joined #pypy.

[23:59] <lac> hi all

[00:00] --- Fri Mar 18 2005