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

[00:06] dlk (~dlk@82.96.42.156) left irc: Read error: 110 (Connection timed out)

[00:07] Nick change: idnar_ -> idnar

----- silence for 1 hr and 10 minutes -----

[01:17] arigo_ (~arigo@vicky.ecs.soton.ac.uk) left irc: "leaving"

----- silence for 32 minutes -----

[01:49] <sanxiyn_> If anyone's curious, my >400 test failures disappeared after deleting all *.pyc files...

[01:49] Action: sanxiyn_ up again, 9 am here.

----- silence for 47 minutes -----

[02:36] <sanxiyn_> py.py py.py continues far longer now...

[02:36] <sanxiyn_> faking <type 'unicode'>

[02:36] <sanxiyn_> (snip)

[02:36] <sanxiyn_> faking <pypy type 'unicode'> [!]

----- silence for 40 minutes -----

[03:16] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)

----- silence for 32 minutes -----

[03:48] <sanxiyn_> Extra, extra!

[03:48] <sanxiyn_> PyPy in StdObjSpace on top of Python 2.3.4 (startupttime: 6103.75 secs)

[03:48] <sanxiyn_> >>>>>

[03:49] Action: sanxiyn_ go commit his assorted hacks

[03:51] <sanxiyn_> It fails to print "1" though.

----- silence for 2 hr and 17 minutes -----

[06:08] sanxiyn_ (tinuviel@222.233.187.43) left #pypy ("Bye").

----- silence for 1 hr and 6 minutes -----

[07:14] lac (lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) left #pypy.

[07:15] idnar (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)

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

[07:57] sanxiyn (~tinuviel@211.104.100.115) left irc: Remote closed the connection

[07:58] sanxiyn (tinuviel@222.233.187.43) joined #pypy.

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

[08:19] dlk (~dlk@walter.ita.chalmers.se) joined #pypy.

[08:20] dlk (dlk@walter.ita.chalmers.se) left #pypy.

----- silence for 32 minutes -----

[08:52] idnar (mithy@idnar.user) joined #pypy.

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

[10:16] sanxiyn (tinuviel@222.233.187.43) left irc: "Bye"

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

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

----- silence for 1 hr and 15 minutes -----

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

----- silence for 48 minutes -----

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

----- silence for 23 minutes -----

[13:00] Fade (~fade@outrider.deepsky.com) left irc: Read error: 110 (Connection timed out)

[13:15] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: Remote closed the connection

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

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

[13:37] cfbolz_ (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.

[13:37] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: Read error: 104 (Connection reset by peer)

[13:51] Nick change: cfbolz_ -> cfbolz

----- silence for 33 minutes -----

[14:24] arigo (~arigo@134.99.112.244) joined #pypy.

----- silence for 1 hr and 22 minutes -----

[15:46] <pedronis> hpk, arigo: is subversion down?

[15:47] <hpk> yip, i have a look

[15:47] <arigo> hi

[15:49] <cfbolz> hi all!

[15:49] <hpk> pedronis: it's operative again

[15:50] <hpk> this time i made a complete copy to play around a bit

[15:51] <cfbolz> hpk: Did you see the thread on py.test on comp.lang.python?

[15:51] <hpk> cfbolz: yes, yesterday night i skimmed it

[15:52] <pedronis> hpk: thanks

[15:52] <hpk> cfbolz: reymond seems to like it :-)

[15:52] <cfbolz> yes, very much. btw: I just love it. :-)

[15:53] <hpk> also i noticed that people were remembering single sentences/promises of my talk ... scary :-)

[15:53] <cfbolz> There's a transcript on the net somewhere (though I don't now whether it contains exact quotes).

[15:54] <hpk> i should put up my PDF somewhere i guess

[15:54] <cfbolz> most talks are in some wiki page of python.org

[15:55] <cfbolz> ah, no. not a wiki. It's http://www.python.org/pycon/2005/papers/.

[15:56] <jacob22|office> Hi, I just received notification that the place in Oxford charges 45 pounds per person per day.

[15:56] <jacob22|office> I think that is out of our league, and that we need to cancel the sprint.

[15:56] <mwh> ouch!

[15:57] <hpk> jacob22|office: wow! per person?

[15:57] <jacob22|office> Right, and it is the cheap place.

[15:57] <cfbolz> hpk: the notes about the talk are in http://www.sauria.com/~twl/conferences/pycon2005/20050323/

[15:58] <mwh> well, that kills that then

[15:59] <hpk> cfbolz: thanks, i try to put up my PDF on the pycon wiki next time i am on my laptop

[15:59] <arigo> "cheap" place indeed

[16:00] <hpk> jacob22|office: And Andy cannot find something else for us, i guess?!

[16:01] <hpk> arigo: your lufs hack is marvellous

[16:01] <arigo> :-)

[16:01] <hpk> arigo: also it shows the way how py.path implementations should be refactored

[16:02] <jacob22|office> hpk: No, he says that free space in Oxford is not available.

[16:02] <hpk> arigo: but note that lufsmnt seems to be deprecated in favour of the "lufis" cmdline tool

[16:02] <jacob22|office> hpk: And as far as I know he doen't have contacts anywhere else.

[16:02] <hpk> arigo: but i couldn't figure out so far how to substitute it correctly

[16:03] <arigo> I don't have "lufis" installed

[16:03] <arigo> is there a more recent version of lufs than 0.9.7 ?

[16:03] <hpk> not that i know off

[16:03] <arigo> (also note that lufsmnt is not lufsmount)

[16:05] <arigo> ah, lufis is a bridge to something else, fuse

[16:05] <arigo> well I wanted something that works with minimal installation fuss

[16:06] <hpk> sure

[16:07] <hpk> it appears that on gentoo there is no lufsmnt

[16:07] <arigo> ah, I see

[16:07] <hpk> but weren't you using a gentoo installation, too?

[16:07] <arigo> not on this machine

[16:07] <arigo> it's my old laptop

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

[16:24] arigo (~arigo@134.99.112.244) left irc: Remote closed the connection

[16:32] sanxiyn (tinuviel@222.233.187.43) joined #pypy.

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

[16:43] <sanxiyn> Hello

[16:44] <arigo> hi

[16:46] <sanxiyn> Got py.py py.py running.

[16:46] <arigo> :-)

[16:48] <arigo> what was the problem you posted about?

[16:48] <sanxiyn> Eh, I still don't have solution to what I posted...

[16:50] <arigo> might be a __name__ attribute missing because it's actually not the same type of object in CPython and PyPy,

[16:50] <arigo> which is possible for built-in stuff

[16:50] <pedronis> it seems a problem with refaking the fake stuff

[16:50] <sanxiyn> Yes.

[16:51] <sanxiyn> Is it worth to disable all py.* magics when running inside PyPy?

[16:51] <sanxiyn> (It will cut down 100 min startup time significantly)

[16:52] <arigo> then I guess so

[16:52] <sanxiyn> After autopath fix py.* stuffs actually work on top of PyPy, but it's too slow.

[16:53] <pedronis> well, having py.py running on itself is nice but I would not invest too much time in it until we are more stand-alone

[16:53] <sanxiyn> I guess so.

[16:53] <pedronis> otherwise you have to do a lot of work working around stuff that is not meant to be there

[16:54] <sanxiyn> Any idea why "deleting *.pyc" apparently "fixed" my problems with py.test?

[16:55] Action: sanxiyn cannot reproduce this, but swear it happened...

[16:55] <pedronis> yes it can happen

[16:55] <arigo> boooo

[16:56] <pedronis> yes something in py.lib loading pycs without checking whether they are out-of-date?

[16:56] <pedronis> s/yes/is

[16:56] <mwh> jacob22|office: the EP meeting is in two hours, correct?

[16:56] <arigo> pedronis: there is py/path/local/local.py, but it should check the date

[16:59] <pedronis> maybe there's a bug

[16:59] <pedronis> I also had massive test failures that were fixed by removing pyc files

[17:02] <jacob22|office> mwh: In 1 hour.

[17:02] <arigo> pedronis: ah

[17:03] <mwh> jacob22|office: oh

[17:03] <pedronis> arigo: mmh, what time does svn use for files

[17:03] <mwh> uh

[17:03] <mwh> yes, that's what i meant :)

[17:04] <arigo> pedronis: is that related to svn?

[17:04] <arigo> pedronis: ah I see, sorry

[17:04] <pedronis> it could be

[17:05] <pedronis> depends what svn exactly does with mtime you could have a local pyc that is newer than a changed .py

[17:05] <arigo> pyc timestamps don't work like that, though

[17:05] <arigo> .the pyc file stores the timestamp of the .py file

[17:06] <arigo> if the .py timestamp changes, the .pyc is thrown away

[17:06] stakkars (tmbhvu@i528C1277.versanet.de) joined #pypy.

[17:06] <arigo> the timestamp of the pyc is not used, and there is no future-vs-past comparison, only time equality

[17:07] <pedronis> yes, I forgot about that

[17:13] <stakkars> hi all! I was quite ill for the day. Trying to catch up...

[17:13] <arigo> :-(

[17:14] <pedronis> arigo: the code in path.local is indeed doing the right thing

[17:14] <stakkars> did something change concerning space.issubtype? (well, I'll know, soon)

[17:14] <arigo> stakkars: not by myself

[17:14] <pedronis> stakkars: no

[17:15] <pedronis> arigo: the next time it happens I need to anlyze what's going on before killing the pyc files

[17:15] <arigo> yes

[17:16] <stakkars> you were discussing how to evolve this. Any decision?

[17:17] <pedronis> no, whatever we do about exception_match, the annotator and the generator may need changes

[17:17] <stakkars> ah, I see changes on the docstring problem.Let's see...

[17:18] <stakkars> but if we simply enhance space.issubtype to be compatible, would that be in the wrong direction?

[17:18] <arigo> I think it's easier than that

[17:18] <arigo> we have to see who is putting this issubtype operation there in the first place

[17:18] <stakkars> easier than the 10 lines?

[17:19] <arigo> well not "easier" but more localized:

[17:19] <arigo> fix the flow objspace to generate the right kind of graphs

[17:20] idnar (mithy@idnar.user) left irc: "kbye"

[17:20] <pedronis> well, it's not localized because a lot of places assume the broken graphs ;) right now

[17:20] <arigo> hum

[17:20] <pedronis> I mean, is the correct thing

[17:20] <pedronis> to do

[17:21] <stakkars> right. For me a nightmare, willlots of follow-up bugs, so I personally would prefer a small hack that works, before we break so much.

[17:21] <pedronis> but I aspect changes needed in some places under translator/

[17:21] <arigo> the annotator yes, but why translator/ ?

[17:22] <arigo> I have in mind an override of exception_match() that assumes a constant w_check_class

[17:23] <stakkars> for the moment, and the simpleproblem to get dir() translated, would it be ok if I simply break that exceptclause into to, with an XXX?

[17:23] <stakkars> two

[17:25] <arigo> let me see if I'm missing something obvious

[17:25] <stakkars> btw.: what is "lufs"?

[17:25] <arigo> Linux Userland Filesystem

[17:25] <sanxiyn> Linux Userland File System.

[17:26] <stakkars> ah, I remember (still booting)

[17:26] <sanxiyn> sshfs is cool.

[17:28] <sanxiyn> There's also FUSE, which seems to be a competitor to LUFS.

[17:28] <sanxiyn> Filesystem in USErspace

[17:29] <sanxiyn> (FUSE is used by cvsfs and gmailfs)

[17:30] <pedronis> arigo: no it seems the generators are doing the right thing

[17:30] <stakkars> yes. Interesting, I'm looking a little into these, because I'm planning my own remote fs pet project

[17:30] <sanxiyn> FUSE has Python binding...

[17:30] Action: arigo plugs http://codespeak.net/svn/user/arigo/hack/pylufs/

[17:31] <sanxiyn> arigo: Oh.

[17:31] <arigo> dates from this morning :-)

[17:31] <sanxiyn> arigo: Any reason to prefer LUFS over FUSE by the way?

[17:32] <stakkars> arigo: interesting. At first glance this seems to be a client. I would like to write my server in Python. Is that related?

[17:32] <arigo> no, I didn't know about FUSE, basically

[17:32] <arigo> stakkars: for what protocol?

[17:33] <stakkars> I want to write a special block device, in the first place, and to put anything on top, client-wise.

[17:34] <arigo> stakkars: for special block devices, as opposed to custom file systems, there is nbd

[17:34] <arigo> I've got a pure Python nbd server, too

[17:35] <stakkars> I just saw your localfs server. great!

[17:35] <arigo> you get read or write queries for one block at a given offset, and that's all

[17:35] <stakkars> that's exactly what I need,yay

[17:35] <arigo> that's entierely unrelated to lufs/pylufs, though.

[17:35] <stakkars> pylufs is about logicalfilesystems,only?

[17:36] <arigo> yes

[17:36] <stakkars> maybe I want it both.

[17:36] <arigo> well, the purposes are quite different

[17:37] <hpk> arigo: btw, i definitely think that py.path impls should go for the Filesystem abstraction

[17:37] <hpk> that you used in pylufs

[17:38] <arigo> hpk: it's not so different from the py.path interface, more basic and cleaned

[17:38] <stakkars> arigo: sure, and they can be stacked.

[17:38] <arigo> stackless is better ;-)

[17:39] <arigo> hpk: but you're right, it would be nice if svnfs.py directly worked for any kind of py.path.

[17:39] <hpk> arigo: yes, that is the point and it especially eases custom filesystem implementations like Matthew has done with dictfs and proxyfs

[17:43] <sanxiyn> It seems VFS is an attractive concept, but devilishly hard to get right.

[17:43] <hpk> but being able to implement and test it in pure python simplifies this

[17:44] <sanxiyn> Well, I don't think so... the problem itself is inherently difficult.

[17:44] <hpk> note that i am not saying "it makes it simple" :-)

[17:45] <stakkars> arigo: where can I look at your nbd server?

[17:45] <sanxiyn> (Tcl has VFS support in the core language since 8.4. I haven't digged much, but it looked good.)

[17:45] <stakkars> and will we get this stuff to run on Windows? I would commit myselfto do the device driver mess...

[17:46] <sanxiyn> Stacking works in tclvfs: like metakit database on zip file on http remote.

[17:46] <hpk> sanxiyn: yes, asfaik they even provide a way to intercept arbitrary c-programs by linking to a special tcl-vfs lib

[17:47] <stakkars> sanxiyn: urcks, great :)

[17:47] <sanxiyn> It is rumored that Twisted people are working on VFS too...

[17:48] <arigo> stakkars: no chance to work on Windows

[17:48] <arigo> you'd have to start from scratch again.

[17:48] <stakkars> never say "no chance". We had that already with Stackless...

[17:48] <arigo> NBD is a Linux-only kernel fs, as far as I know

[17:49] <arigo> well in this case I don't think there is much useful code in any of what I did if you want something on Windows

[17:49] <sanxiyn> stakkars: I think arigo is saying "no chance you can reuse code on Windows".

[17:49] <stakkars> well, I would probably try to emulate the underlying API?

[17:50] <stakkars> but this is not trivial of course.

[17:50] <hpk> but of course it would make sense to be able to use the same python/userlevel filesystem implementations on all platforms

[17:51] <sanxiyn> Another exceedingly unbelievable project using LUFS is Captive.

[17:51] <hpk> stakkars: if you get it to work on Windows i'll do OSX :-)

[17:51] <hpk> sanxiyn: i saw references, what is it?

[17:51] <sanxiyn> hpk: NTFS driver for Linux using Windows binary driver.

[17:52] <hpk> !

[17:52] <sanxiyn> Robust read/write.

[17:52] <stakkars> hpk: Hey! While I guess OSX has some useful similarities to Linux, while I have to fight this incredible device driver kit

[17:52] <sanxiyn> hpk: http://www.jankratochvil.net/project/captive/Preview.html.pl

[17:52] <hpk> stakkars: :-)

[17:52] <sanxiyn> (don't miss the diagram...)

[17:53] <sanxiyn> "sandboxed ntoskrnl.exe slave" talks to syslog via CORBA. Can you believe that?

[17:53] <sanxiyn> (from Win32 DbgPrint...)

[17:53] <stakkars> again my questions from 5 pages above:

[17:53] <stakkars> for the moment, and the simpleproblem to get dir() translated, would it be ok if I simply break that exceptclause into to, with an XXX?

[17:53] <sanxiyn> I think so...

[17:54] <hpk> sanxiyn: hehe, corba is not all that bad, actually (apart from that it is a RMI system) but let's stop the off-topic disucssions a bit :-)

[17:54] <stakkars> this would get the problem out of the way, and we can see how fast it gets just by intterpleveling as much as possible.

[17:54] Action: sanxiyn will stop :-

[17:58] <arigo> stakkars: I guess the quick-n-dirty fix is in flowobjspace.exception_match

[17:58] <arigo> if the last arg is a Constant tuple then call the parent's exception_match once for each item in the tuple

[17:59] <arigo> you get the same result as the XXX you propose without changing the source.

[18:00] <stakkars> that sounds good! To bad that I did the change, already.well.

[18:00] <stakkars> ok, I'll test my approach and then change exception_match and test again.

[18:09] <cfbolz> hey! I just talked to the administrator of the institute of physics about the possibilty of doing a sprint in some room here.

[18:10] <cfbolz> He said it wouldn't be a problem as long as it is not during lectures (not problem in summer)

[18:11] <hpk> cfbolz: cool

[18:11] <cfbolz> yes, very :-)

[18:11] <cfbolz> That way we even get all the infrastructure we need, since I am administration Hiwi here.

[18:11] <hpk> cfbolz: hehe

[18:12] <hpk> sounds great

[18:16] <stakkars> arigo: you mean I repeat the line

[18:16] <stakkars> return ObjSpace.exception_match(self, w_exc_type, w_check_class)

[18:16] <stakkars> without the return for each tuple

[18:16] <cfbolz> The next step would probably to decide whether you want to go to Heidelberg and then file a more "official" request (which will not be denied).

[18:16] <stakkars> and collect all results in a way, or do I stop on the first match?

[18:17] <arigo> stakkars: well some reasonable hack

[18:17] <arigo> stakkars: the first match is probably enough

[18:17] <stakkars> I thought I need to enumerate it all, to generate the code (not exactly understanding how it works)

[18:18] <stakkars> ah, this code branch gets backtracked, too?

[18:18] <cfbolz> should I write a mail to pypy-dev?

[18:19] <arigo> it should do "the correct thing", yes

[18:19] <arigo> each parent call to exception_match will put the usual 2 branches in the flow graph.

[18:20] <arigo> cfbolz: yes, please do so

[18:20] <stakkars> ah I understand. "I" am the parent, here.

[18:20] <arigo> no I mean, each call to the super's exception_match will do that.

[18:20] <arigo> indirectly.

[18:21] <arigo> cfbolz: we should re-plan our sprints now that Oxford is dead...

[18:21] <stakkars> yes. I meant that, too, just a doubloe-twist :-)

[18:21] <arigo> :-)

[18:23] <cfbolz> arigo: ok.

[18:24] <cfbolz> I'll post tonight

[18:24] <hpk> arigo: but this is unrelated

[18:24] <hpk> cfbolz: armin is refering to May and i don't think that your you have semesterferien during May :-)

[18:24] <arigo> hpk: yes, I know, it's for this summer

[18:24] <arigo> nevertheless

[18:24] <hpk> arigo: ok, but we never had anything planned for after june, anyway :-)

[18:25] <hpk> june - goetheborg, august - Heidelberg, October - Paris was the idea a few days ago

[18:26] <arigo> would it make sense to try to insert something before june?

[18:26] <hpk> makes some sense i guess

[18:26] <cfbolz> august is not a requirement for Heidelberg as long as it is in Semesterferien - which are quite long

[18:26] <cfbolz> July to oktober I think

[18:27] <hpk> let's do a sprint from July to October :-)

[18:27] <cfbolz> That would be cool. You can all live in my apartment :-)

[18:27] <cfbolz> (just kidding)

[18:27] <hpk> (damn)

[18:28] <hpk> For that period of time we could just rent a flat or two

[18:28] <hpk> well, ok, i guess trying something in May makes sense

[18:28] <cfbolz> right. and we can use the room in the institute here that long :-)

[18:29] <hpk> arigo: do you have any specific idea?

[18:30] <hpk> i am not too enthused about making sprints on short notice, that's why i try to think about june-october rather than in four weeks or so

[18:30] <arigo> sure

[18:30] <arigo> no, no specific idea

[18:31] <hpk> we had someone from Spain but i doubt that this works on short notice (and it would be at a university, probalby with similar "semsterferien" restrictions)

[18:31] <stakkars> arigo: flowspace doesn't have w_tuple, which I'd like to check against. How do I do this?

[18:31] <hpk> or we think about Paris in May?

[18:32] <arigo> stakkars: as a first hack, look directly at unwrap(w_check_class)

[18:32] <stakkars> at some time I'd like to ask CCPgames whether we may do asprint in Iceland

[18:33] <stakkars> thanks

[18:33] <arigo> CCPgames: :-)

[18:41] <sanxiyn> gaga = "ssertion" in printable_name

[18:41] <sanxiyn> if gaga:

[18:41] <sanxiyn> print cls

[18:41] <sanxiyn> print cls.__module__

[18:41] <sanxiyn> print type(cls)

[18:41] <sanxiyn> 1/0

[18:41] <sanxiyn> Above code from geninterplevel.py... what is this?

[18:43] <stakkars> oops, sorry, that is debug code

[18:43] <stakkars> aeh, which module?

[18:44] <sanxiyn> pypy.translator.geninterplevel.GenRpy.nameof_classobj

[18:44] <stakkars> ohyou mean it is in geninterplevel? That's ok, just debugging.

[18:44] <sanxiyn> thanks

[18:46] <arigo> see you

[18:46] <cfbolz> bye

[18:46] <sanxiyn> bye

[18:46] <stakkars> bye

[18:46] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: "dinner time"

[18:46] <cfbolz> I'm going home too. See you later.

[18:46] <sanxiyn> see you

[18:47] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "going home"

[19:00] <mwh> is mike salib working for divmod now?

[19:00] <pedronis> mwh: yes

[19:01] <mwh> interesting

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

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

[19:24] stakkars_ (pixsnsr@i528C1277.versanet.de) joined #pypy.

[19:24] stakkars (tmbhvu@i528C1277.versanet.de) left irc: Read error: 104 (Connection reset by peer)

[19:27] <stakkars_> pedronis: I still can't figure out why app_descriptor.py doesn't work after translation.

[19:28] <stakkars_> I checked the code of the mnodule, it works fine in CPython, too,

[19:28] <stakkars_> but after translation, it thinks __doc__ is read-only.

[19:36] <pedronis> I need to look at it, you mean if you geninterp app_decriptor

----- silence for 16 minutes -----

[19:52] <pedronis> stakkars: are you about to checkin the exception_match thing?

[19:56] <stakkars_> yes, and yes.

[19:57] <stakkars_> will do some more cleanup, first.

[19:57] <stakkars_> geninterp is now checking for "class property" and create /tmp/look.py for this case.

[19:58] <stakkars_> I disable app_descriptor for the moment by a NOT_RPYTHON comment line.

[19:58] <pedronis> Ok, because I think it may be worth to try a more radical idea

[19:59] <pedronis> wich may make the annotator code for exception also a bit more robust

[19:59] <stakkars_> after all tests pass, I'll check in. You can provoke the error by

[19:59] <stakkars_> dropping the comment

[19:59] <pedronis> ok

[20:00] <stakkars_> type complex at the prompt, and you get the exception.

[20:00] <pedronis> I will try my idea and refactor thing if it works after you commit your stuff

[20:00] <pedronis> about exceptions I mean

[20:00] <stakkars_> what I did was just this:

[20:00] <stakkars_> def exception_match(self, w_exc_type, w_check_class):

[20:00] <stakkars_> self.executioncontext.recorder.crnt_block.exc_handler = True

[20:00] <stakkars_> if not isinstance(self.unwrap(w_check_class), tuple):

[20:00] <stakkars_> # the simple case

[20:00] <stakkars_> return ObjSpace.exception_match(self, w_exc_type, w_check_class)

[20:00] <stakkars_> # checking a tuple of classes

[20:00] <stakkars_> for w_klass in self.unpacktuple(w_check_class):

[20:00] <stakkars_> if ObjSpace.exception_match(self, w_exc_type, w_klass):

[20:00] <stakkars_> return True

[20:01] <stakkars_> return False

[20:01] <pedronis> yup

[20:01] <stakkars_> ok, I can check this one in, alone. Or should I forget it?

[20:02] <pedronis> no. check it in. I should try my idea and it needs more changes

[20:04] <pedronis> stakkars: I think you should catch Unwrap exceptions although in our code w_check_class is always constant

[20:04] <stakkars_> ok, done

[20:04] <stakkars_> actually, I wanted to check whether we have a tuple instance. Armin suggested to unwrap,

[20:04] <stakkars_> because we don't have w_tuple on flow space (why?)

[20:05] <pedronis> it's not needed we have only constants and variables we know nothing about in the flow space

[20:05] <stakkars_> done == checkin, not the change :-)

[20:06] <pedronis> doing unwrap is just a shortcut for if isintance(., Constant) etc

[20:06] <stakkars_> aha! I see.

[20:07] <stakkars_> In this case we know it is a constant. Would an extra check for unwrap exception generate different code?

[20:07] <stakkars_> I guess not, it would be evaluated at "compile" time

[20:07] <pedronis> well, the question is whether we want to support code like this:

[20:07] <pedronis> def f(f,exc):

[20:07] <pedronis> try:

[20:07] <pedronis> return f()

[20:07] <pedronis> except exc, e:

[20:07] <pedronis> return e

[20:08] <pedronis> exc is here is variable

[20:08] <stakkars_> erhhm this is correct code? (*blush*)

[20:08] <pedronis> sorry f arg should be g

[20:09] <stakkars_> sure, if it makes sense. Not sure if we want to allow this in RPython, but even then we would need to check!

[20:09] <pedronis> no, I don't think we want

[20:09] <stakkars_> same thing with generators: When a yield occours, we simply create wrong translations, instead of a

[20:10] <pedronis> and even in our app helpers we don't have code like that

[20:10] <stakkars_> raise NoRPythonError, "you damned bastard cannot use that"

[20:11] <stakkars_> so I agree that we should check and bite

[20:11] <pedronis> yes

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

[20:18] hpk (~hpk@merlinux.de) joined #pypy.

----- silence for 48 minutes -----

[21:06] bbiow (bbiow@82.145.232.218) joined #pypy.

[21:13] <sanxiyn> bye

[21:13] sanxiyn (tinuviel@222.233.187.43) left #pypy ("Bye").

[21:14] bbiow (bbiow@82.145.232.218) left irc:

----- silence for 16 minutes -----

[21:30] <stakkars_> pedronis:how are things going?

[21:30] <stakkars_> I'm almost finished making applevelinterp the default.

[21:30] <stakkars_> There are now just two classes and one function applevel(), which looks

[21:31] <stakkars_> into the source if there is a comment with NOT_RPYTHON.

[21:31] <stakkars_> and creates the right class instance.

[21:34] <pedronis> I tried my idea, I think it could made to work, basically to generate something like empty blocks with a exception exitcase for exception_match

[21:35] <pedronis> it would simplify the annotator work with exceptions and make it more sane, but this needs to be discussed because some details need fixing

[21:35] <stakkars_> would it generate shorter code?

[21:36] <pedronis> well, if there's was a simplification that remove the blocks and attach new cases to the original block exiting with exception, yes

[21:37] <pedronis> but details need to be fixed also because for example with the change geninterp does not work as it is

[21:37] <pedronis> because it really generates a try except

[21:38] <pedronis> also for the empty blocks, it would need to know to check for the original last exception

[21:38] <pedronis> or the graph would have to simplified along the lines I described

[21:38] <stakkars_> yes, I was sure this would hurt other places.

[21:39] <stakkars_> another thing: There are lots of pieces I cannot translate, because there is a yield.

[21:39] hpk (~hpk@merlinux.de) left irc: Read error: 104 (Connection reset by peer)

[21:39] <stakkars_> First of all, I'm thinking how to handle this: trnaslate all the functions which don't have yield.

[21:40] <stakkars_> The other thing is: can we raise an exception in flow space if we encounter a yield?

[21:40] <stakkars_> also, do I guess right that the reason why we can't yield in flow space is that we would need a frame?

[21:40] <stakkars_> I would love to support generates, really!

[21:40] <stakkars_> generators

[21:41] <pedronis> I don't know exactly what is going on with generators and the flow space

[21:42] <stakkars_> we are loosing lots of translatable code, there.

[21:42] <stakkars_> ok, I will check my stuff in, if you are so kind to look into app_descriptor

[21:43] <pedronis> I'm about to go home

[21:43] <stakkars_> yup, see you tomorrow

[21:46] <pedronis> well, the flow space sees the first yield as just a return

[21:47] <pedronis> we would need special code to do the right thing

[21:47] <pedronis> the option is to convert the generators to something else

[21:47] <pedronis> also because they are not RPython

[21:48] <pedronis> so we cannot map a generator to a interp level generator

[21:48] <stakkars_> yes. special translation. I did that once at the bytecode level, but never finished totally

[21:48] <stakkars_> the problem is the same as with Psyco.

[21:48] <stakkars_> my solution is to rewrite the bytecode to use some function instead.

[21:48] <stakkars_> Have to recall what exactlymy plan was, but it worked, theoretically.

[21:48] <pedronis> yes, something like that

[21:49] <pedronis> see you

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

[21:54] bbiow (bbiow@82.145.232.218) joined #pypy.

[21:54] bbiow (bbiow@82.145.232.218) left irc: Client Quit

[21:56] hpk (~hpk@merlinux.de) joined #pypy.

[22:03] <stakkars_> XXX

[22:03] <stakkars_> somebody checked somethoing in that breaks

[22:04] <stakkars_> justtomakesure it is not due to my changes:TestFlowObjSpace.test_specialcases

[22:05] <stakkars_> breaks with my changes disabledaswell.

[22:15] <hpk> stakkars_: there is a strange failure after your recent checkins

[22:16] <hpk> ends like this:

[22:16] <hpk> File "/home/hpk/projects/dist-pypy/pypy/translator/geninterplevel.py", line 712, in nameof_type

[22:16] <hpk> assert cls.__module__ != '__builtin__', (

[22:16] <hpk> AssertionError: built-in class <type 'property'> not found in typename_mapping while compiling _read_only_attribute

[22:17] <hpk> occurs while invoking "python pypy/documentation/revreport/revreport.py"

----- silence for 54 minutes -----

[23:11] pedronis (~Samuele_P@c-368b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

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

[23:31] cfbolz (~cfbolz@hdlb-3e34207c.pool.mediaWays.net) joined #pypy.

[23:31] <cfbolz> hi!

[23:35] <cfbolz> ha. while trying to formulate my question that I was about to ask, it became totally clear to me :-)

[23:39] <cfbolz> see you.

[23:39] cfbolz (~cfbolz@hdlb-3e34207c.pool.mediaWays.net) left irc: "Verlassend"

[00:00] --- Wed Apr 6 2005