==== Channel ##pypy: 04/25/05 ====

[00:05] pedronis (~Samuele_P@c-108b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection

----- silence for 1 hr and 58 minutes -----

[02:03] _hannes (jycxuwt@i528C11F6.versanet.de) left irc: "utz utz utz"

----- silence for 5 hr and 11 minutes -----

[07:14] idnar (mithrandi@idnar.user) left irc: Connection timed out

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

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

----- silence for 55 minutes -----

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

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

[10:27] dannu (~hpk@mail.trillke.de) joined #pypy.

[10:28] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 145 (Connection timed out)

[10:43] hpk (~hpk@merlinux.de) left irc: Read error: 110 (Connection timed out)

[10:46] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.

[10:47] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.

----- silence for 55 minutes -----

[11:42] stakkars (~tismer@rosine41.inf.fu-berlin.de) joined #pypy.

[11:42] dannu (~hpk@mail.trillke.de) left irc: Read error: 104 (Connection reset by peer)

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

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

----- silence for 30 minutes -----

[12:53] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.

[12:53] <cfbolz> hi all!

[12:59] <stakkars> hi

----- silence for 1 hr and 8 minutes -----

[14:07] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"

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

[14:32] <stakkars> pedronis: are you there?

[14:33] <pedronis> yes

[14:34] <stakkars> after lots ofother problems, including the one form the last check-in, I'm now back where I was some days ago.

[14:34] <stakkars> targetpypy1 -no-a works, but without the -no-a

[14:34] <stakkars> I need to special specialcase certain things which otherwise are nonimplemented.

[14:34] <stakkars> Can you please hint me again,*how* I should do this, and where?

[14:35] <pedronis> we are talking about genc

[14:35] <pedronis> ?

[14:35] <stakkars> yup

[14:36] <stakkars> I need to figure out that some skipped thing is special and needs to get support code.

[14:36] <pedronis> the things that need special casing are listed in annotation/builtin.py or translator/ann_override.py

[14:36] <stakkars> I remember.

[14:37] <pedronis> another problem is that the annotator does specialisation but this is not tracked by the graphs right now

[14:37] <stakkars> I also remember that I did not understand what need to be done there.

[14:40] <pedronis> for ovfcheck things the typer or genc should recognise the pattern and emit code to detect overflows

[14:40] <pedronis> for the rest is a matter to emit calls to special functions or macros that do what the original not analysed function does

[14:40] <pedronis> but in a manner that makes sense for the code genc generates

[14:41] <stakkars> how would genc recognize ovfcheck, for instance?

[14:41] <pedronis> for specialisation, we really need to put some indirection in the graph probably such that

[14:41] <pedronis> it doesn't right now

[14:41] <pedronis> I think

[14:41] <pedronis> a lot of stuff is not there

[14:42] <stakkars> no sure, I'd like to ask how I can intercept this and tech genc.

[14:42] <stakkars> teach

[14:42] <pedronis> I think the typer should probably recognize the pattern

[14:43] <pedronis> and substitute the ovfcheck( op ) pattern with a new operation

[14:43] <stakkars> you talked about "this pattern" -- ah, so I should figure out how to do this.

[14:43] <stakkars> with a new operation that genc then knows and intercepts?

[14:43] <pedronis> well you have an operation was result is passed to ovfcheck

[14:43] <pedronis> and then there around those the exception handling

[14:44] <pedronis> this is the pattern

[14:45] <pedronis> either the typer or a transformation before it should recognise this

[14:47] <pedronis> it should look for block that terminate with a simple_call to ovfcheck and exception handling

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

[14:51] hpk (~hpk@merlinux.de) joined #pypy.

[14:52] <stakkars> I'm still unable to deduce which part of the code actually makes ovfcheck get unimplemented. :(

[14:52] <pedronis> it is not analysed

[14:52] <pedronis> because it is special cased

[14:53] <stakkars> is this signaled by being an entry in BUILTIN_ANALYZERS ?

[14:53] <pedronis> yes

[14:54] <pedronis> the special-casing happens through

[14:54] <pedronis> because the constant goes through bookeeper.immutablevalue and through the case there

[14:54] <pedronis> elif ishashable(x) and x in BUILTIN_ANALYZERS: ...

[14:55] <stakkars> woha, I see!

[14:55] <pedronis> and then in unaryop

[14:55] <pedronis> simple_call and call for SomeBuiltin are defined

[14:56] <pedronis> and will use what was put in the BUILTIN_ANALYZERS table

[14:58] <stakkars> ok,many thanks!

[14:58] Action: stakkars still wonders how to (gulp) modify this complicated machinery...

[14:58] <stakkars> will try it, again.

[14:59] <pedronis> you don't have to modify this

[14:59] <pedronis> you have to write a separate transformation

[14:59] <pedronis> it is already complicated enough without trying to do even more things at the same time

[15:00] <stakkars> ah, you mean I insert a new step that scans this and replaces operations?

[15:00] <pedronis> yes

[15:01] <pedronis> there are already a set of transformation done after annotation

[15:01] <stakkars> now I get the picture. I don't change something to handle this, I add my own filter.

[15:03] <pedronis> I think the transformation after annotation or done

[15:03] <pedronis> through RPythonAnnotator.simplify

[15:03] <pedronis> wich calls things defined in transform.py

[15:07] <stakkars> yes

----- silence for 1 hr and 13 minutes -----

[16:20] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.

[16:24] <hpk> arigo: pypy-funding is almost closing the debate :-)

[16:25] <hpk> ludal: hey, great, i've seen your commit. i guess you regret moving to subversion, eh? :-)

[16:28] <ludal> yeah a bit

[16:28] <ludal> I really like darcs' feature allowing you to select hunks to include in a record

[16:30] <hpk> there are an aweful lot of interesting versioning systems these days

[16:32] <ludal> yes; what I'm going to do these days is try to use some of them on small projects and compare the advantages; darcs is the first I tried and although it's missing some features I think it as the best potential

[16:33] <ludal> next I'll check monotone and bazaar-ng any experience with them ?

[16:34] <hpk> not yet, i decided to only look at the VC situation late this year or next year again :-)

[16:36] <ludal> ok

[16:38] <hpk> i think we should all move to bitkeeper

[16:38] <hpk> :-)

[16:40] <stakkars> commits on single bits?

[16:41] <hpk> i am refering to the mega-debate that occured last week regarding linux-kernel

[16:41] <hpk> linus switched away from bitkeeper (a commercial VC tool)

[16:42] <hpk> and blamed Andrew Tridgell (samba/rsync) for this

[16:42] <stakkars> ;-]

[16:42] <hpk> the company 'bitmover' revoked all free licenses

[16:43] <hpk> in reaction to Andrew reverse engeneering the metadata format to get a tool to freely access the data

[16:43] <stakkars> great idea. like the company "pypy" will do at some future :-)

[16:43] <hpk> it's a pretty crazy story

[16:44] <stakkars> (for everybody who's just lurking: this was just a joke!)

[16:44] <hpk> google will find it and the rumor will spread nevertheless :-)

[16:44] <hpk> ok, i have to go ...

[16:44] Action: hpk is out

----- silence for 28 minutes -----

[17:12] stakkars_ (~tismer@rosine41.inf.fu-berlin.de) joined #pypy.

[17:12] stakkars (~tismer@rosine41.inf.fu-berlin.de) left irc: Read error: 104 (Connection reset by peer)

[17:14] Nick change: stakkars_ -> stakkars

[17:14] _hannes (fwmanyux@i528C1032.versanet.de) joined #pypy.

[17:15] stakkars (~tismer@rosine41.inf.fu-berlin.de) left irc: Client Quit

[17:16] <arigo> pedronis: are you around?

[17:16] stakkars (~tismer@rosine41.inf.fu-berlin.de) joined #pypy.

[17:16] <pedronis> arigo: yes

[17:16] <arigo> we should quickly fix the doc about integer overflows in RPython

[17:17] <pedronis> I see

[17:17] <pedronis> do we use screen on codespeak

[17:17] <arigo> ok

[17:18] <stakkars> should I help with this? I think I wrote that mess, a millenium ago or such

[17:18] <arigo> :-) you're welcome

[17:19] <arigo> screen -x arigo/arigo

[17:26] <hpk> i wonder how it works out to write documentation via screen ...

[17:27] <arigo> experiment in progress :-)

[17:28] <stakkars> will see.Right now we're discussing, should do this here:)

[17:30] <hpk> there is emacs on codespeak as well, btw

[17:35] <hpk> ludal, adim: your recparser is unrelated to module/parser basically, right=?

[17:35] <ludal> yes

[17:35] <hpk> then i definitely suggest to move it one level up

[17:35] <ludal> that what I thought

[17:35] <hpk> moreover: do you intend this as applevel code or interplevel?

[17:35] <hpk> or mixed?

[17:35] <ludal> but I don't know if we can call it "parser" too (ie in __init__.Module) ?

[17:36] <hpk> yes, the directory name is more or less unrealated to the real module name

[17:36] <ludal> I realized that, but what if two directories provide the same module name ?

[17:36] <hpk> np

[17:36] <hpk> you have to decide for one another of course

[17:36] <ludal> ok then, I'll move it up

[17:37] <hpk> at the moment, this is done in: (goes to look it up)

[17:37] <ludal> where do you pick one or the other?

[17:37] <ludal> ok...waiting

[17:37] <hpk> baseobjspace.py:89

[17:38] <hpk> the calls to setbuiltinmodule()

[17:38] <hpk> (which are disabled at the moment)

[17:38] <hpk> pypy/interpreter/baseobjspace.py to be precise

[17:39] <ludal> setbuiltinmodule( "python_name", "dir_name" ) is this it ?

[17:40] <hpk> yes, basically

[17:40] <ludal> one thing is I wanted to check if we could use the tokenizer from parser instead of the one we wrote

[17:40] <hpk> not really dir_name

[17:40] <ludal> yeah module_name right ?

[17:40] <hpk> yes

[17:40] <hpk> i think the main issue is if your code is RPython or real applevel

[17:41] <ludal> well it's probably not RPython

[17:43] <hpk> are there specific parts where it is inherently hard?

[17:43] <ludal> hard?

[17:44] <hpk> hard to write in RPython?

[17:45] <ludal> not sure, looking for doc of what's specifically allowed/disallowed in rpython ? pointers ?

[17:45] <hpk> from the main doc page 'coding-style.txt'

[17:46] <hpk> http://codespeak.net/pypy/index.cgi?doc/coding-style.html

[17:46] <hpk> to be precise

[17:47] <hpk> actually, arminm, samuele, chris are currently in a screen session improving it a bit

[17:49] <ludal> the code create a syntax tree of objects, so a var can be assigned objects of different types but from the same base class

[17:50] <ludal> the string handling (eg "" %) are only there for debugging /representation purposes

[17:51] <ludal> the core of the parsing algorithm is very small it's in grammar.py which is 280 lines of which only 1/3 does the parsing job

[17:51] <ludal> so this 1/3 can probably be checked to see if it's RPython easily

[17:52] <ludal> the lexer is a problem now (uses regexps) and that's why I wanted to use the other one in parser

[17:52] <hpk> yes, let's at leat move recparser one level up

[17:52] <hpk> (better you do it because you are likelier to have modified Working Copies)

[17:53] <ludal> the grammar itself is built at startup from the Grammar file from python source

[17:53] <hpk> nice

[17:53] <ludal> we actually have 2 copies (slightly modified) : Grammar2.3 and Grammar2.4

[17:54] <hpk> i saw that

[17:54] <ludal> hpk: yes I have some files modified ; I'll do it

[17:54] <adim> well, a *slightly* modified version of the Python grammar, but this should be fixed soon

[17:54] <hpk> it's not strictly necessary to keep to the unmodified Grammer IMO

[17:54] <ludal> I'm actually trying to remove the need to *slightly* modify the grammar ;)

[17:55] <hpk> the main advantage of having the parser run at interp-level mostly is

[17:55] <hpk> that we could probably routinely use it

[17:55] <ludal> hpk: actually the grammar is unmodified in it's meaning, it's just that the way it's written make the grammar parser generate infinite recursions

[17:55] <hpk> whereas if it runs as applevel (like e.G. the file implementation) then it tends to be disabled for speed reasons alone

[17:56] <hpk> ludal: ok, ist your parser also not forward looking like CPython's btw?

[17:56] <ludal> so the only modifications are that we exchange rules in alternatives like S-> A | B | C becomes S->A | C | B

[17:57] <ludal> no but that's how I want to improve it; it's not really difficult

[17:57] <hpk> i see

[17:58] <ludal> the thing is, I'm not sure at this point that forward looking would eliminate all recursions

[17:59] <ludal> what does eliminate (IMO) recursions in CPython is NDFA -> DFA translation eg removing null/epsilon transitions

[18:00] Action: hpk needs to look at the dragon book again

[18:01] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.

[18:01] <ludal> this is just a guess btw... NDFA is non deterministic finite automata and when you translate directly the grammar file to an automata this is what you get

[18:02] <hpk> what was the exact difference between N and not NDFA again?

[18:02] <ludal> mostly because you have rules like S->A* which can do a null transition ie complete S without any token

[18:03] <ludal> so if you have S involve in a recursion it can loop forever, but usually the automata tries to eat the largest chain of tokens so it's ok

[18:04] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection

[18:04] <hpk> i see

[18:04] <ludal> (this is reaching the extent of my knowledge on automata so I'm afraid I'm not very precise nor totally correct)

[18:06] <hpk> thanks

[18:06] <hpk> i guess i am going to read up again a bit on it, my memories of the CS courses are dusty

[18:07] <ludal> back to forward looking : once the grammar is parsed it should be easy to create the set of 'first tokens' that can be visible on a rule but rules like A* have the 'null' token in the set and so should be tried last in alternatives

[18:08] <hpk> right, but for PyPy it's probably more interesting to resolve the interp/applevel issue

[18:09] <ludal> yes, would it be ok if grammar parsing code runs at bootstrap time (ie generating the parser ) ?

[18:09] <hpk> i would say so, yes

[18:09] <hpk> how long does it take?

[18:10] <ludal> with regular python, nothing

[18:10] <hpk> ok, great

[18:10] <ludal> bootstrap is CPython right ?

[18:10] <hpk> right

[18:10] <hpk> full power of it

[18:11] <hpk> so you can generate all kinds of static structure before-hand

[18:11] <ludal> so this steps creates a tree of grammarelement representing CPython's grammar

[18:11] <ludal> yes

[18:11] <hpk> e.g. i see your method dispatching ("visit") uses a computed getattr

[18:11] <ludal> once done this tree is static

[18:11] <hpk> that is not RPython but it should not be hard to precompute a constant dictionary i guess

[18:12] <hpk> ludal: sounds good

[18:12] <ludal> yep but that's just lazyness

[18:12] <hpk> sure

[18:12] <hpk> i am just trying to give a bit of feedback :-)

[18:13] <ludal> just need to overload visit on derived class

[18:13] idnar (mithy@idnar.user) left irc: "kbye"

[18:13] <ludal> thanks, it's welcome; I was just meaning that with work it can be removed ;)

[18:14] <hpk> yes, there are usually solutions like this

[18:15] <hpk> however, if it is isn't fully RPython yet, it still makes sense to integrate it soon

[18:15] <hpk> so that problems/bugs can be discovered

[18:15] <hpk> we can always switch it out for translation if it isn't RPythonic enough yet

[18:16] <hpk> (in which case we reuse CPython's parser module)

[18:16] <ludal> actually, looking at it further, this part is not called on the path : parsing -> syntaxtree -> totuple

[18:17] <hpk> ludal: btw, you/we should investigate what the new AST branch of CPython is heading at

[18:17] <ludal> this is what I intended to use to create the abstract syntax tree; before Armin pointed out the fact that this part existed in python (so applevel) in the compiler module

[18:18] <ludal> yes

[18:18] <hpk> i see

[18:18] <ludal> in the end it would probably be nice to have source_text -> AST fully in RPython, but it may be difficult to achieve

[18:19] <hpk> didn't arigo have some alternative ST-AST transformation hack somewhere?

[18:19] <arigo> http://codespeak.net/svn/user/arigo/hack/compiler/

[18:20] <ludal> right, actually you already told me about it

[18:21] <ludal> is it strictly rpython ?

[18:21] <arigo> I don't know, actually

[18:22] <hpk> skimming the source doesn't pop up something obvious un-rpythonic to me

[18:22] <hpk> arigo: i guess it would be a good example for a try to convert the code into a c-extension module :-)

[18:22] <arigo> the driver function sttuple2ast() was a bit hand-optimized and isn't rpythonic any more, but that's easily fixed

[18:25] <hpk> arigo: you should make *function calls* into `function calls`_ :-)

[18:25] Action: hpk is following the documentation screen -x arigo/arigo session on codespeak

[18:25] Action: stakkars knew we have a spy :-)

[18:26] <cfbolz> now you have two :-)

[18:27] <stakkars> gack :-D

[18:28] <hpk> stakkars, cfbolz: it would be great to get a rough overview over llvm and geninterp into pypy/documentation/translation.txt

[18:28] <cfbolz> hpk: I feared that that would be coming :-)

[18:28] <hpk> i am really talking about a few paragraphs to get a start :-)

[18:28] <cfbolz> of course. I think I'll have time for it tomorrow

[18:29] <cfbolz> I guess I will have to write some more detailed docs soon anyway.

[18:29] <hpk> i will try to come up with a nice way to reference functions/classes/methods in our source code from ReST soonish

[18:29] <cfbolz> cool

[18:29] <hpk> at the moment you have to reference the files in the repository

[18:29] <hpk> and note that with 'py.test -R' in pypy/documentation all references are checked

[18:30] <hpk> the local and the remote ones

[18:30] <cfbolz> ok.

[18:31] <hpk> and regarding ReST format i recommend just looking at how the other doc is done

[18:31] <cfbolz> Oh, ReST won't be the problem :-)

[18:31] <hpk> ok, great, i am also saying this to other possible documentation writers (hint hint :-)

[18:32] <cfbolz> sorry

[18:32] <hpk> for what?

[18:33] <hpk> well, anyway i think we are getting closer to a pretty good state of the documentation ...

[18:33] <cfbolz> wrong window :-)

[18:33] <cfbolz> the sorry, I mean.

[18:34] <hpk> sorry :-)

[18:34] <cfbolz> :-)

[18:34] <cfbolz> Yes, I think after the recent changes the docs became very understandable and well structured.

[18:35] <cfbolz> Definitively a huge imporvement

[18:35] <hpk> nice to hear!

[18:36] <cfbolz> I wish it had been in that state half a year ago when I tried to understand PyPy - just kidding.

[18:36] <hpk> ludal: can you do the move the dirlevel up?

[18:37] <hpk> ludal: i want to do something about the tests not passing :-)

[18:38] <ludal> yep, in a couple minutes

[18:39] <hpk> if you put an __init__.py in your 'recparser' rootpackage then you should import things from/as pypy.module.recparser

[18:39] <ludal> ok

[18:39] Action: hpk notes that we need some documentation on our module system (which is probably my task)

[18:42] <ludal> any advice about solving a svn mv problem ...

[18:42] <ludal> I did : svn mv recparser ..

[18:42] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.

[18:43] <ludal> at the same time adim checked in smthg in recparser

[18:43] <ludal> when i svn ci to register the move svn failed 'recparser not up to date'

[18:43] <hpk> do an 'svn up' then first

[18:43] <ludal> that's done

[18:44] <ludal> but now I have to dirs : module/recparser and module/parser/recparser ...

[18:44] <ludal> that where I need advice ;)

[18:44] <hpk> what does 'svn st' at pypy/module level say?

[18:44] <ludal> A + recparser and a lot of D parser/recparser/*

[18:45] <hpk> and what if you 'svn rm parser/recparser'?

[18:46] <ludal> don't know; but I tried svn ci and the log message looks right, I'm going to try that

[18:46] <hpk> just try 'svn ci' anyway

[18:46] <ludal> looks right == A module/recparser/* and D module/parser/recparser

[18:46] <hpk> yes

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

[18:47] <ludal> looks like it worked

[18:48] <hpk> it did

[18:48] <ludal> svn was just unhappy with the outdated file even though it (looks like) didn't need it

[18:49] <hpk> yes, if you have mods in files where there are updates on the servers it forces you to do an 'svn up' first

[18:50] <hpk> ludal: actually relative imports within recparser should be ok

[18:51] <ludal> the thing is it considers the directory 1 level above the modified file as not being up to date when a subdirs contains a modified file... or so it seems.

[18:51] <ludal> hpk: ok

[18:51] <hpk> but you need to import from 'pypy.module.recparser ...' for the entry points (from the tests, e.g.)

[18:51] <ludal> I know the imports sucks in the module this in one mess we've been trying to improve before checkin in the module

[18:52] <hpk> sure, i can also help with it ...

[18:53] <ludal> does the module breaks anything as it is now ?

[18:53] <hpk> yes, the tests, that's why i am eager to repair it :-)

[18:53] <hpk> basically all test_*.py files are collected if you do 'python test_all.py' or 'py.test' in pypy/

[18:54] <ludal> is there an easy way to disable them?

[18:54] <hpk> yes, there are some brute force ways :-)

[18:55] <hpk> did the tests run for you, btw?

[18:55] <ludal> involving svn mv ? ;)

[18:55] <hpk> not involving svn mv

[18:55] <hpk> it can be done by putting a 'blocker' conftest.py e.g. in recparser/

[18:55] <hpk> with the content:

[18:55] <ludal> well the way I run the tests now is setting python path to recparser/.

[18:55] <hpk> class Directory(py.test.collect.Directory):

[18:55] <hpk> def run(self): return []

[18:55] <stakkars> arigo: you just checked in something about genc. Do we plan for extra docs for genllvm,geninterp as well, or all-in-one?

[18:56] <hpk> all in translation.txt for now

[18:56] <hpk> but in different chapters

[18:56] <cfbolz> why could also mix it all :-)

[18:56] <hpk> ludal: yes, if you use 'pypy.module.recparser' then it will just work

[18:57] <stakkars> cfbolz: we could, if we used a consistent scheme. But partially, it is different.

[18:57] <hpk> ludal: 'py.test' adds the root directory to sys.path

[18:57] <hpk> ludal: by traversing upwards until there is no '__init__.py' anymore

[18:58] <ludal> I'll change that; the thing is I really need to go soon (ie 30 minutes ago) so I'd like to quickfix it asap

[18:58] <cfbolz> stakkars: it was a joke, really

[18:58] <arigo> stakkars: moreover what I checked in doesn't describe genc per se, but what I'd like the C typer to do (so for now it is a completely genc-specific text)

[18:58] <hpk> ludal: sure, like i said, i can help or we can just put a blocker 'conftest.py' into recparser

[18:58] <ludal> running the tests now with conftest.py if it skip ok I'll check that

[18:58] <ludal> I wrote:

[18:59] <stakkars> I asked because I need to write about geninterp, a little, also about its interaction with gateway and caching.

[18:59] <ludal> conftest.py

[18:59] <ludal> import py.test.collect

[18:59] <ludal> class Directory(py.test.collect.Directory):

[18:59] <ludal> def run(self):

[18:59] <ludal> return []

[19:00] <stakkars> import py is a bit broken, today.

[19:00] <arigo> stakkars: ok. this goes in a new chapter in translator.txt I guess.

[19:00] <hpk> ludal: looks right although "import py" is enough

[19:00] <hpk> stakkars: what do you mean?

[19:00] <cfbolz> arigo: same for genllvm?

[19:00] <stakkars> arigo: translation.txt ?

[19:00] <arigo> cfbolz: yes

[19:00] idnar (mithrandi@idnar.user) joined #pypy.

[19:01] <arigo> stakkars: well yes, same file as where I just checked in about genc

[19:01] <arigo> pypy/documentation/translation.txt

[19:01] <stakkars> hpk: Imeant we need to use

[19:01] <stakkars> from pypy.tool.getpy import py # XXX from interpreter/ we get py.py

[19:02] <hpk> indeed

[19:02] <stakkars> because the other one sometimes fetches the wrongmodule.

[19:03] <hpk> yes, that's confusing

[19:03] <stakkars> (which I really don't get why it finds interpreter/py)

[19:03] <hpk> maybe pypy/interpreter/py.py should move somewhere else anyway

[19:03] <hpk> i'd fancy:

[19:03] <hpk> pypy/bin/py.py

[19:03] <hpk> pypy/bin/translator.py

[19:04] <stakkars> is pypy/interpreter a toplevel path? Or how does it happen?

[19:04] <ludal> ok guys really need to go; looks like pypy/module tests passed without including recparser

[19:04] <ludal> I'll fix that tomorrow

[19:04] <hpk> ludal: yes, have a nice evening!

[19:04] <hpk> stakkars: it shouldn't be a toplevel apth

[19:04] <hpk> path even

[19:04] Action: hpk needs to buy a new keyboard

[19:05] <ludal> thanks, bye

[19:05] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";

[19:05] <stakkars> hpk: then I don't understand why it is seen at all.

[19:06] Action: stakkars to, but how do I replacemySamsung notebook keyboard when I need it?

[19:06] <hpk> relative paths are tried before global lookups

[19:06] <hpk> so if

[19:07] <stakkars> I have the problem when running under test_all.py . Does it mean test_all chdirs into interpreter?

[19:07] <hpk> no

[19:07] <hpk> what exactly was the problem, btw?

[19:08] <hpk> that you got interpreter/py but wanted 'py' or the other way round?

[19:08] <stakkars> sitting on toplevel pypy, testing something in subfolders which does "from py.path import local",

[19:09] <stakkars> then I get the complaint that"py" hasno atrribute "path".

[19:09] <stakkars> This is, because interpreter/py is found as that module.

[19:09] <hpk> but from a module not in interpreter/ ?

[19:09] <stakkars> Ahh, ok, the code I was testing was sitting in gateway.py :-))

[19:10] <stakkars> bingo. Grumpff

[19:10] <hpk> with a dedicated directory for our script-entry points we probably wouldn't have this problem

[19:10] <arigo> +1

[19:11] <stakkars> a better name for either of the "py"s would do it, too. I'd prefer to not use any name as a module and a script name.

[19:11] <arigo> (though I think writing something like "+1" is a bit short and longer opinions are often called for :-)

[19:11] <stakkars> +1

[19:12] <hpk> only talking in '+1' or '-1' would make our communication more efficient

[19:12] <arigo> -1

[19:12] <stakkars> you sum over the whole IRClogand do whats needed to be done :-)

[19:12] Action: hpk wonders how to express irony in numbers

[19:13] <arigo> NaN

[19:13] <stakkars> ok, so how about just moving py.py one level up? This is where I use test_all as well.

[19:13] <hpk> i think 'py.py' and for the self-contained compiled version 'pypy' is very nice

[19:13] <stakkars> 0+1J # like yes well but theres something else

[19:14] <hpk> hum, i'd prefer its own directory, we have a growing number of '.py' files already at top level

[19:15] <stakkars> at least,py.py should refuce to be imported (or even more screwed,do what's expected: import the pypackage [duck])

[19:15] <arigo> actually, putting py.py directly in pypy/ makes sense to me

[19:15] <arigo> stakkars: :-) :-)

[19:15] <cfbolz> hpk: <0.5 wink> of course

[19:16] <stakkars> arigo: "tit for tat": what py did to py, vice versa :-)

[19:16] <stakkars> move'em up I'dsay.

[19:16] <arigo> tool/ is also very messy

[19:16] <hpk> actually horribly messy

[19:17] <pedronis> yes

[19:17] <hpk> we should avoid using the name 'tool', it's much too tempting

[19:17] <stakkars> arigo: about tool: I actuallythink that some stuff in tool needs to be anywhere elsebut in tool.

[19:17] <arigo> :-)

[19:17] <pedronis> well, some stuff could go in a util directory

[19:17] <hpk> you are joking right?

[19:18] <pedronis> no

[19:18] <pedronis> we have command line tools in tools

[19:18] <hpk> oh, to me 'tool' and 'util' is largely equivalent

[19:18] <pedronis> and library stuff

[19:18] <stakkars> neither tool nor util is the right place for essential core stufflike "rarithmetic"

[19:18] <pedronis> I see different philosphy

[19:18] <pedronis> for me tool is mostly never a library

[19:18] Action: hpk suggests forking the codebase

[19:18] <stakkars> a language should still work if you remove tools

[19:18] <arigo> better bin/ and coreutil/ or whatever

[19:19] <stakkars> but notlib or sys or whatsoever reallyclaimsto be necessary :-)

[19:19] <hpk> pedronis: i see your point

[19:19] <stakkars> 1+1j

[19:19] <arigo> m

[19:19] <hpk> pedronis: but i have very often seen util==tool directories

[19:20] <arigo> bin, devtool, misclib ?

[19:20] <hpk> pedronis: for many programmers such directories just indicate a place to dump stuff ...

[19:20] <stakkars> how about "helpers"

[19:20] <arigo> "helper" you mean

[19:21] <hpk> i think we need to review the tool content and (re)move it as appropriate

[19:21] <stakkars> I don't mind. Something that says "this must be there or I'm dead"

[19:21] <arigo> "common" ?

[19:22] <pedronis> yes, that's a possibility

[19:22] <stakkars> well,if you are expressing that it is in common, becuase it is not obj spacespecific, yes

[19:22] <pedronis> although a very javaish one

[19:22] <stakkars> but then, baseobjectspace should move, there,too?

[19:22] <arigo> which is nice because it says "don't put here unless you know it will be useful for several places" :-)

[19:22] <hpk> arigo: sorry, what exactly are you suggesting a name for?

[19:22] <pedronis> for the library stuff in tool

[19:22] <stakkars> building blocks with no specific place where they are needed, but which are needed

[19:23] <arigo> rarithmetic.py, uid.py, etc.

[19:23] <stakkars> where is the difference between these and,for instance, error.py?

[19:23] <pedronis> hack.py (wich needs a better name)

[19:24] <arigo> error.py and baseobjspace.py are more specific to PyPy, that could be a difference

[19:24] <hpk> arigo: i think, for example, that rathmetic could be put into interpreter/

[19:24] <arigo> whereas rarithmetic is just general and shouldn't be put in interpreter/ :-)

[19:24] <stakkars> especially because the interpreter couldlive without it

[19:24] <pedronis> it is not only for pypy, is for general rpython code in theory

[19:25] <hpk> even if they can be used standalone

[19:25] <stakkars> is RPython meant for anything else but PyPY ???

[19:25] <arigo> pedronis: very good point

[19:25] <stakkars> ahaaa, so we need something like a core RPython folder.

[19:25] <hpk> well, doesn't "general rpython code" not need to 'from pypy.interpreter.error ...' and so on?

[19:25] <arigo> hpk: no

[19:26] <pedronis> no

[19:26] <stakkars> you sound negative...

[19:26] <arigo> general RPython code doesn't need to import anything, with the possible exception of r_uint and similar helpers to control precise details of their translation

[19:26] <hpk> then i agree with stakkars that it should go to 'pypy/rpython'

[19:27] <arigo> stakkars: the last PyPy talks I gave (based on the PyCon one), people were really interested in being able to compile their own RPython code

[19:27] <arigo> ok but it doesn't solve the whole problem

[19:27] <hpk> arigo: sure enough

[19:27] <arigo> e.g. uid.py?

[19:28] <arigo> it's just a completely general and independent small helper

[19:28] <stakkars> arigo: hohoo, there seems to be no final limit on being crazy - yet another dumb assembly target:-)

[19:28] <stakkars> s/final/finite/

[19:29] <arigo> ah, wrong example: indeed, uid.uid() might need RPython special-casing

[19:29] <arigo> then what about ansi_print.py ?

[19:29] <pedronis> arigo: yes, in fact we discussed that we may need r_huint or indeed to special case uid

[19:30] <pedronis> there are also sourcetools.py and hack.py

[19:30] <stakkars> ansi_print.py - a nice little RPython thing written in Applevel.

[19:31] <stakkars> so what does RPython mean: Things which are needed to implement it, or things which are compliant???

[19:31] <arigo> RPython is a language spec, basically

[19:31] <stakkars> sourcetools: I'llhappily move it to geninterp or something else in translator, where it is related to.

[19:33] Action: hpk is away for a while

[19:38] <stakkars> ok, and ansi_print is used both from interpreter/error.py and annotation/bookkeeper and translator/annrpython

[19:38] <stakkars> hey, should that really be a tool? :-)

[19:41] <cfbolz> I want to use it too

[19:41] <stakkars> arigo: that about RPy was just a joke - freezing into something like an intermediate language target is quite fine

[19:41] <cfbolz> so it should go to translator/llvm :-)

[19:43] <stakkars> hmm... what I said before about tools and necessity..... that would mean PyPy should work without Py

[19:43] <stakkars> which is not true. Well, consistent arguments is a hard thing.

[19:51] Action: stakkars got into funny ideas about an RPython only interpreter

[19:51] Action: pedronis leaving the office; see you

[19:51] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"

[19:51] <stakkars> bye

[19:51] <cfbolz> the cool thing about RPython only is that you would be able to compile it, no?

[19:52] <stakkars> definately

[19:53] <cfbolz> although at the moment it would be difficult to do anything usefull:

[19:53] <cfbolz> it's not possible to interface with the rest of the world with RPython only.

[19:53] <stakkars> no?

[19:54] <stakkars> But PyPy is a full Python interpreter, implemented by RPython.

[19:54] <cfbolz> yes, but you can't compile it right now.

[19:55] <stakkars> yes.Some of my thoughts went into that direction: Would things have been easier if we went for RPython, in the first place?

[19:56] Action: arigo lost -- what are you talking about?

[19:56] <cfbolz> just idle thoughts (at least on my part)

[19:56] <arigo> I don't understand, you can compile PyPy right now, and PyPy is RPython

[19:57] <cfbolz> ok, ok. I think I might be a bit to LLVM focused :-)

[19:57] <arigo> :-)

[19:57] <stakkars> random thoughts about RPython as a stand-alone interpreter and compiler, not thinking about

[19:57] <arigo> stakkars: ah, oh, I see.

[19:58] <stakkars> all the complicance and completeness things in the first place, as we did. Just musings.

[19:58] <stakkars> We might be carrying less stuff around before we getto a self-contained sthig. (Unreflected thoughts alert!)

[20:00] <stakkars> you triggered that with your reporton the PyPy talk

[20:01] <arigo> yes, there is a point about the idea that we could have done an RPython interpreter and translator faster if we didn't care for PyPY

[20:01] <cfbolz> yes but didn't rpython get defined in such a way that PyPy becomes possible?

[20:02] <cfbolz> How would you have arrived at the RPython definition without PyPy?

[20:02] <arigo> yes, it was defined by successive approximations for what is needed in a large project like PyPy

[20:02] <stakkars> there is some truth in it. Well, although most of RPython was settled after the first fewsprints.

[20:03] <arigo> yes, but then a number of subtle details changed, though.

[20:03] <stakkars> we could have saved time if we had a few people concentrating on a self-contained RPython quite early,

[20:04] <stakkars> just because all these turn-around issues would have been solved, earlier. Well, the amount ofwork is the same I guess.

[20:04] <cfbolz> but the translator relies on PyPy infrastructure, right?

[20:04] <arigo> stakkars: possibly, but that might miss the whole point, which is that we can plug an interpreter for say Javascript and have RJavascript for free :-)

[20:07] <stakkars> didn't get that, after the third reading.

[20:08] <arigo> the point of not writing an RPython interpreter or RPython-to-flow-graph by hand

[20:08] <arigo> is that you can have everything dependent on one interpreter for your language

[20:09] <arigo> in other words, we don't have to write an interpreter for RPython and one for Python in PyPy

[20:09] <stakkars> yes, but I don't get the Javascript argument.

[20:10] <stakkars> by "plug",you mean I write a fullJavascript interpreter and get RJavascript for free? Many thanks :-D

[20:10] <arigo> yes :-)

[20:10] <cfbolz> you mean a translator for RJacascript, right?

[20:11] <stakkars> I can turn that upside down and say "well I can start when I just have the RJavascript" level, and leave further work to others.

[20:11] <arigo> yes

[20:11] <cfbolz> I never looked at it that way. cool!

[20:11] <arigo> stakkars: keep in sight that the next step in PyPy is Psyco-ish JIT

[20:12] <stakkars> don't worry, at the moment, everything just feel a bit huge for me.

[20:12] <arigo> if you write RPython or RJavascript by hand, you don't get Psyco or JSyco for free :-)

[20:12] <cfbolz> and the real question is: how do you pronounce JSyco?

[20:13] <stakkars> arigo: You think to get Psyco for free?

[20:13] <cfbolz> ok. I have to go. see you.

[20:13] <arigo> cfbolz: see you :-) right, hard question.

[20:13] <cfbolz> :-)

[20:13] <arigo> stakkars: sure

[20:13] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"

[20:13] <stakkars> you needtowrite it once, I guess, in a reusableway.

[20:13] <arigo> yes.

[20:13] <arigo> "for free" means here in a mostly Python-independent way.

[20:14] <stakkars> which you do in plain Python-or-whatsoever.

[20:14] <stakkars> s/whatsoever/anything-but-plain-C/

[20:15] <arigo> yes, I'm not exactly sure at this point which pieces will have to be written in what langauge

[20:15] <stakkars> do you want to run Psyco on the user-code, or let it re-optimize all the lower interplevel stuff, too?

[20:16] <arigo> I don't know, for now I'm thinking about Psyco on the user code

[20:16] <arigo> for that, there is a large part that can be automatically generated from the flow graph of PyPy's interpreter.

[20:17] <stakkars> Yes. The major thing psyco can add is time. AS we say in the docs, annotation doesn't use time.

[20:18] <hpk> arigo: regarding ansi_print, it should go to a 'debug' directory which we need anyway (IMO)

[20:18] <arigo> makes sense

[20:18] <hpk> arigo: because we also need some general tracing mechanism (written in rpython style)

[20:19] <arigo> I still think there is bound to be some general-purpose utilities that we need

[20:19] <hpk> arigo: yes, but i'd like to move things out of tool to meaningful places

[20:19] <arigo> sure

[20:19] <stakkars> arigo:me too.

[20:19] <hpk> before resorting to 'common', 'tool', 'util' or any other cross-purpose thingie

[20:19] <arigo> it's a question of how many subdirs we want to have, we shouldn't have too many of them either.

[20:20] <hpk> arigo: sure enough

[20:20] <stakkars> it is a matter of categories: Most folders are by category, but tool is the category "wherethehackshouldIputthat"

[20:21] <stakkars> s/hack/heck

[20:21] <hpk> maybe just reducing tool from time to time is just fine (also because it rhymes)

[20:22] <hpk> does anyone know if the lightning talks are supposed to be in parallel with others?

[20:22] <hpk> it sounds like it from Jacob's EuroPython talk submission reminder

[20:22] <stakkars> the way it is used, ansi_print seems to really be a tool.

[20:23] <stakkars> I think it needs some placelike right now, but a place that makes clear that this is an internal library

[20:23] <stakkars> module, and certain things would break without it.

[20:24] <stakkars> See CPython: tools is not needed for the system to run, and also no other "external" module/package.

[20:25] <stakkars> The py package, as nice as it is, has become a contradiction to that: PyPy won't work without it.

[20:27] <stakkars> maybe we should just walk the whole folder, tomorrow and see what the puposes are.

[20:27] <stakkars> bye, see you

[20:28] <stakkars> before I go, there's another random idea :-[]

[20:29] <stakkars> arigo: on annotation and re-flowing. There is right now this type annotating

[20:30] <stakkars> and re-analysis to find out what the minimal, most exact types necessary are.

[20:30] <arigo> yes

[20:31] <stakkars> Now assume that this process is modified not to re-flow things [unreflected thoughts, again],

[20:31] <stakkars> but to create alternative implementations.

[20:32] <stakkars> just a feeling: If you don't do static analysis, but allow things to change over time,

[20:32] <stakkars> wouldn't that be quite close to what Psyco does?

[20:32] <arigo> yes, absolutely

[20:33] <stakkars> then the only reason why we need to annotate statically is toproduce a static binary?

[20:33] <arigo> only partially; the static part in the current annotation process also avoids a drawback of Psyco: it's very hard to control how much versions you actually write

[20:34] <stakkars> so we are conservative on this first part, trying to prune the tree as much as possible.

[20:34] <arigo> yes

[20:34] <stakkars> Taming Psyco is something that we want to do when we have made this lower stage.

[20:34] <arigo> yes.

[20:34] <arigo> for now, we have more computations to do in advance, but then a nice fixpoint that we can check and control.

[20:35] <stakkars> but it is not *that* different, and I guess flow graphs might be players in Psyco as well?

[20:35] <arigo> yes, that's likely

[20:36] <arigo> instead of doing the extremely low-level approach of CPsyco (:-) we should probably handle flow graphs at run-time

[20:37] <stakkars> that is, the engine is always running in the background, improving run-time constraints

[20:37] <hpk> stakkars: what exactly are you refering to when you say that pypy depends on the py lib?

[20:38] <stakkars> hpk: maybe I'm wrong, but I think that certain modules are using stuff from the py package

[20:39] <stakkars> and these things belong to the PyPy bootstrap. gateway,for instance.

[20:39] <hpk> stakkars: they shouldn't other tahn for testing and maybe intermediate tool purposes

[20:39] <stakkars> yes, but I'm using it for things which happen at runtime.

[20:40] <stakkars> I started to do this after I saw that this happens, anyway. Now I'm not sure if this is ok.

[20:40] <hpk> i see, gateway originally used it only for bootstrap time IIRC

[20:41] <stakkars> it is still only for bootstrap time.

[20:41] <hpk> then it should be quite ok

[20:42] <hpk> it would be good to have a way to find out any wrong runtime-usages without running full translation/anotation

[20:42] <stakkars> So you are saying that when PyPy is completely instantiated, there should not be any py reference left?

[20:42] <hpk> not sure, it at least should not be reachable

[20:42] <stakkars> Ok, that is already so. ALso the way I use it is ok (since today, ahem)

[20:43] <stakkars> ahh, you consider py a bootstrapping tool, as CPython is essentially, too, and this will vanish?

[20:44] <hpk> yes, originally it wasn't used at pypy bootstrap time, but it sneaked in here and there

[20:44] <stakkars> but the way PyPy is bootstrapped right now enforces these extra tools.

[20:44] <hpk> it should definitely not sneak into runtime

[20:44] <stakkars> In a way, the appearance of these nice tools in the dist collection suggested to use them.

[20:45] <stakkars> but PyPy shgould try to stay a self-contained distribution. That would mean to incorporate the really

[20:45] <stakkars> useful tools injto PyPy ???

[20:45] <stakkars> (no, they are all useful, but some are *very* handy)

[20:46] Action: stakkars is now really leaving

[20:47] <hpk> stakkars: have a nice evening

[20:47] stakkars (~tismer@rosine41.inf.fu-berlin.de) left irc: "tomorrow"

[20:53] pedronis (~Samuele_P@c-2e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

[20:53] <arigo> re-hi

[20:53] <pedronis> re-hi

[20:54] <arigo> working on this implicit exception mess

[20:54] <arigo> should we officially allow blocks with exitswitch: last_exception but a single None exit?

[20:55] <pedronis> when they show up?

[20:56] <arigo> after creating and then removing the implicit exception branches

[20:58] <arigo> I guess I should just work harder and fix the exitswitch

[20:58] <pedronis> are they a real problem? apart being a special case for the generators

[20:58] <arigo> geninterp isn't happy right now, it produces SyntaxErrors

[20:59] <arigo> but I think they might prevent some optimization here and there, or create subtle problems by prevents other stuff

[21:03] <pedronis> I see

[21:07] <arigo> for example, transform.transform_dead_code() will create such things

[21:09] <pedronis> well, given that transformation are shared and it seems at geninterp would need special casing

[21:09] <pedronis> it seems that indeed it makes sense to sanitize the graphs

[21:10] <arigo> ok, I added the condition to checkgraph() and see where such graphs come from

[21:11] <arigo> I think that transform_dead_code() and my new remove_assertion_errors() were the only places

[21:20] <arigo> hum, now would be a good time to check if I broke translate_pypy

[21:20] <arigo> but my stomac is not of this opinion

[21:20] <pedronis> I can try that

[21:23] <arigo> ok, then see you tomorrow, latest 3pm

[21:23] <pedronis> ok

[21:23] <hpk> see you (i am out too probably)

[21:23] <arigo> (2pm in the uk... almost forgot)

[21:23] _hannes (fwmanyux@i528C1032.versanet.de) left irc: "utz utz utz"

[21:23] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "good night"

[21:29] aleale (~root@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.

----- silence for 42 minutes -----

[22:11] pedronis (~Samuele_P@c-2e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"

----- silence for 38 minutes -----

[22:49] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: "BeOS - Because you don't eat soup with a fork!"

[23:04] tic (~vision@c-ba6e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.

[23:17] aleale (~root@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: "Eject! Eject! Eject!"

[23:31] fredrikj (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.

[00:00] --- Tue Apr 26 2005