[02:04] <pedronis> I have merged the branch
----- silence for 17 minutes ----- [02:21] <pedronis> nite
[02:21] pedronis (~Samuele_P@c-158b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050317]"
----- silence for 18 minutes ----- [02:39] sanxiyn (~tinuviel@211.104.100.115) left irc: "Bye"
----- silence for 3 hr and 13 minutes ----- [05:52] LENOI (~io@193.231.20.8) joined #pypy.
[05:52] LENOI (io@193.231.20.8) left #pypy.
----- silence for 1 hr and 13 minutes ----- [07:05] idnar (mithrandi@idnar.user) left irc: Read error: 145 (Connection timed out)
----- silence for 1 hr and 23 minutes ----- [08:28] idnar (mithy@idnar.user) joined #pypy.
----- silence for 16 minutes ----- [08:44] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 110 (Connection timed out)
----- silence for 1 hr and 28 minutes ----- [10:12] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 43 minutes ----- [10:55] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 57 minutes ----- [11:52] arigo (~arigo@134.99.112.244) joined #pypy.
----- silence for 1 hr and 32 minutes ----- [13:24] <arigo> hpk: ping?
----- silence for 25 minutes ----- [13:49] jacob22|office (jacob@enzo.strakt.com) left irc: Connection timed out
[13:52] idnar (mithy@idnar.user) left irc: Read error: 113 (No route to host)
[13:52] idnar (mithy@idnar.user) joined #pypy.
----- silence for 21 minutes ----- [14:13] jacob22|office (jacob@enzo.strakt.com) joined #pypy.
----- silence for 35 minutes ----- [14:48] Gromit (~bear@dialin-212-144-184-010.arcor-ip.net) joined #pypy.
[14:56] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[14:57] <cfbolz> hi!
[14:57] <arigo> hi!
[14:58] <cfbolz> re your post: I don't remove flowgraph blocks
[14:58] <cfbolz> I remove blocks that exist only in LLVM
[14:58] <arigo> ah
[14:58] <cfbolz> and have no match in the flowgraph
[14:59] <cfbolz> I insert a block in LLVM along each link to be able to do the neccessary casts
[14:59] <arigo> oh, I see
[14:59] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[15:00] <cfbolz> I did them in the prevblock before but that doesn't work with exceptions
[15:00] <arigo> ah
[15:01] <arigo> sorry for the misdirected comment, then.
[15:01] <cfbolz> no problem :-)
[15:01] <cfbolz> btw: What's the exact meaning of link.exitcase if the exitswitch is last_exception?
[15:02] <cfbolz> It can't be the exact class of the exception being caught
[15:02] <arigo> no, it can be a superclass
[15:02] <pedronis> and probably Exception itself may mean anything
[15:02] <arigo> the exitcase matches if it is a superclass of the exception being caught.
[15:02] <arigo> yes
[15:03] <arigo> in practice we possibly only have either exact matches or Exception to mean "anything" right now.
[15:03] <pedronis> yes
[15:03] <cfbolz> good
[15:03] <pedronis> I think exact matches are produced by implicit exceptions
[15:03] <cfbolz> yes
[15:03] <pedronis> and some internal stuff, e.g. catching StopIteration
[15:04] <pedronis> while iterating
[15:04] <cfbolz> I was confused by the fact that in the case of excplicitly raised exceptions an explicit is_/issubtype is inserted
[15:05] <arigo> yes, it's a bit strange,
[15:05] <pedronis> yes, it is something we discussed yesterday
[15:06] <arigo> but it's because the PyPy interpreter catches any exception and then proceeds to the "except:" clause, which itself does the check
[15:06] <pedronis> a part of the catching is the links exitcase
[15:06] <pedronis> and the rest is inlined things from the interpreter
[15:06] <arigo> it's still interesting for implicit exceptions to have them caught by the link exitcase,
[15:06] <arigo> so that we know what implicit exceptions to generate at all
[15:06] <pedronis> yes
[15:07] <pedronis> but as I said we the current schema
[15:07] <pedronis> for annotating exception handling fails
[15:07] <pedronis> we may need to rework the inlining
[15:08] <pedronis> the problem is that althoug simplication prevent that, it may be possible
[15:08] <pedronis> to lose the information that a variable is related
[15:08] <cfbolz> arigo: Good. Until now I have been generating all builtin exceptions, now I can find out which one I need.
[15:08] <pedronis> to a last_exception or last_exc_value
[15:09] <arigo> pedronis: I don't follow you there
[15:09] <arigo> in a simple example, "except MyError, e:" seems to be annotated just fine
[15:09] <arigo> because the is_ and issubtype ensure that 'e' is known to have the correct class.
[15:09] <pedronis> yes, but it works because
[15:10] <pedronis> because we inseret a is_type_of releation
[15:10] <pedronis> from the things coming out of the
[15:10] <pedronis> exitcase exception link
[15:11] <pedronis> but if it weren't for simplification and other things
[15:11] <pedronis> that info may get lost
[15:11] <pedronis> so it is working but is fragile
[15:11] <arigo> I see, it doesn't work if we don't simplify
[15:12] <pedronis> for example
[15:12] <pedronis> but I'm not totally sure that something strange can still happen
[15:12] <pedronis> cannot
[15:13] <arigo> can you explain why we need these Constant flags?
[15:14] <pedronis> because of th implicit exception case
[15:14] <pedronis> there's last_exception is a constant class
[15:16] <pedronis> a possible solution would be to mark the variable in which last_exception, last_exc_value go
[15:16] <arigo> I still don't see
[15:16] <arigo> at least now, the graph of
[15:16] <arigo> try: x+1
[15:16] <arigo> except OverflowError: return -1
[15:16] <arigo> is nice and clean
[15:19] <arigo> what I am missing? naively I'd say that when there is an exception-handling link, we only have to add "is_type_of" between the binding of any (last_exception) and (last_exc_value) that are output args of that link
[15:21] <pedronis> but for explict exception the constant on the link itself is not last_exception
[15:21] <pedronis> s/expl/impl
[15:22] <arigo> well in any case you know that last_exc_value is SomeInstance(classdef(link.exitcase)), no?
[15:22] <arigo> for implicit exceptions the annotator doesn't have to be more clever, it seems, because the graph is already very short
[15:23] <pedronis> could be, but I added the SomeInstance(classdef=) only yesterday
[15:24] <arigo> ah. (where is it?)
[15:25] <arigo> bascially at least in the current model I don't see why you need to track variables and flag constants around instead of just figure out the correct annotations and let them propagate by themselves
[15:27] <pedronis> mmh, it seems that change has been reverted
[15:27] <pedronis> it was revision 10366
[15:28] <arigo> oups, I branched off 10364
[15:29] <arigo> how did you merge?
[15:30] <pedronis> I copied thinks from the branch into the trunk
[15:30] <pedronis> because I thought the branch was uptodate
[15:30] <arigo> I see that, I mean how did you know the list of files to copy
[15:30] <pedronis> I compared the head and the branch
[15:31] <arigo> ok
[15:31] <pedronis> but, yes I should have not assumed that the branch was from an up-to-date head
[15:31] <arigo> and hpk who created another branch off the trunk while our branch was still active :-(
[15:32] <pedronis> fun fun by merging
[15:32] <arigo> yes
[15:32] <arigo> we could need a "dead-end detection tool"
[15:32] <pedronis> well, I will re-checkin that change
[15:32] <arigo> ok
[15:32] <pedronis> although I don't get why the corresponding test is passing
[15:33] <arigo> a tool looking for patches that have been lost by a merge, basically
[15:33] <arigo> the test was removed as well, no?
[15:33] <pedronis> of course :(
[15:38] <pedronis> yes it is failing without the change
[15:44] <pedronis> done
[15:45] <arigo> ok
[15:49] <cfbolz> hey, apart from some the distinction between exact matching of exitcase vs. matching subclases (which should be a minor fix) exceptions now work with genllvm.
[15:49] <arigo> :-)
[15:49] <cfbolz> Although I need to find a better way to pass uncaught exceptions back to Python
[15:51] <cfbolz> for now I just have a flag that tells Python that any uncaught exception has occured.
[15:53] <cfbolz> Then I need to find something new to do: It doesn't really make sense to work on dicts right now,
[15:53] <cfbolz> since genc will need its own dict implementation at one point anyway (and I'm not really qualified to implement dicts properly), right?
[15:56] <arigo> hum
[15:58] <arigo> if you really want you might try to support all the PyObject operations
[15:58] <arigo> if you do, it would make genllvm a full concurrent to genc for annotated graphs
[15:59] <arigo> pedronis: now I see a problem with unsimplified graphs
[15:59] <arigo> it's that is_type_of doesn't handle links that duplicate a Variable
[16:00] <arigo> I think we can fix that in the handling of is_type_of over links
[16:01] <arigo> iow you forgot that link.args may contain several times the same Variable -- this bites more often that you'd expect ;-)
[16:04] <pedronis> well, me and mwh had tons of fun with that code
[16:04] <arigo> I guess so
[16:04] <arigo> however I just fixed the is_type_of propagation bit
[16:05] <arigo> and also added support for len(is_type_of) > 1 in builtin_issubclass (my fault there)
[16:05] <arigo> and removed all the flag stuff from Constant
[16:05] <arigo> now it seems to annotate properly exception handlers, with or without simplification
[16:05] <arigo> even makes the test_annrpython pass
[16:06] <cfbolz> arigo: I feared that that was coming :-)
[16:06] <pedronis> that's good, most of the issues we ever had with annotating exception handling have a test there
[16:06] <arigo> I guess it was kind of obvious how to fix that with the simpler model of the branch
[16:07] <arigo> and for someone that is outside the flagging subtleties :-)
[16:07] <cfbolz> arigo: basically what I needed to do is a conversion function for every type in LLVM to PyObject, right?
[16:07] <pedronis> but I admit I never looked that deeply into why simplication was necessary, because it was done most of the some
[16:08] <pedronis> most of the times
[16:08] <arigo> ok
[16:08] <pedronis> also I was trying to annotate all of targetpypy0
[16:08] <pedronis> and exceptions were only a part of the problems
[16:08] <arigo> cfbolz: yes, but maybe only as the needs become apparent
[16:09] <arigo> cfbolz: the first thing would be to support most operations on PyObjects themselves
[16:09] <arigo> cfbolz: e.g. add() --> PyNumber_Add()
[16:10] <cfbolz> arigo: ok. For this I have to check whether the args of an operation are SomeObjects and then use PyNumber_Add then, right?
[16:11] <arigo> yes
[16:12] <cfbolz> But if the arguments are of mixed types (SomeObject and anything else) I have to do conversions
[16:13] <arigo> yes, if you want to do the "full thing" then if the arguments are not some combination that you can handle, convert everything to PyObject and use PyNumber_Add
[16:13] <arigo> hum
[16:14] <arigo> of course the alternative idea is not to do that in genllvm,
[16:14] <arigo> but instead throw translate_pypy1 at it and see how far it goes
[16:15] <cfbolz> ?
[16:15] <cfbolz> it being genllvm, right?
[16:15] <arigo> I mean, trying not to tie genllvm too much to CPython's API might be good too
[16:15] <arigo> yes
[16:16] <cfbolz> ah, ok. what does translate_pypy1 try to translate?
[16:17] <pedronis> arigo: does targetpypy1 with genc use annotations now or should that also be enabled?
[16:17] <arigo> cfbolz: targetpypy1 is a small bit of the stdobjspace, enough to do (-6)*(-7)
[16:17] <arigo> cfbolz: targetpypy0 is the next goal, it's the interpreter of PyPy without the objspace
[16:18] <arigo> pedronis: let me see
[16:18] <cfbolz> arigo: ah. So you mean maybe targetpypy1 might be simple enough to be translated by genllvm in the near future?
[16:18] <arigo> yes
[16:19] <cfbolz> Ok. Then I'll try to do that and fix whatever problems I encounter
[16:19] <pedronis> yes. targetpypy1 is also small enough that you can look at the graphs to see what's going on
[16:20] <arigo> pedronis: so far you have to call something to use annotations in genc
[16:20] <arigo> from pypy.translator.genc.ctyper import GenCSpecializer
[16:20] <arigo> GenCSpecializer(a).specialize()
[16:20] <pedronis> I suspected that
[16:20] <arigo> maybe that should be done automatically in translator.ccompile()
[16:21] <pedronis> yes, at least that it enough to pass a flag to get that
[16:22] <arigo> hum, maybe you'd like to see the modified flow graph in pygame
[16:22] stakkars (~tismer@82.144.60.19) joined #pypy.
[16:22] <pedronis> mmh, yes
[16:22] <pedronis> we may want to extende translate_pypy.py to enable that
[16:22] <pedronis> maybe also to be able to choose a generator
[16:22] <arigo> right
[16:26] <arigo> hi
[16:31] <arigo> pedronis: ctyper is pretty much useless right now on targetpypy
[16:31] <arigo> targetpypy1 I mean
[16:32] <arigo> but it doesn't make things crash :-)
[16:32] <pedronis> I know
[16:32] <pedronis> but it's good to track progress
[16:32] <arigo> yes
[16:33] <arigo> actually, now you need ctyper to remove the pyfn_* generated functions and produce direct C-level calls
[16:33] <arigo> for targetpypy1, a majority of functions don't have their pyfn_ wrapper at all, which is good
[16:35] <arigo> I added a method a.specialize() on the annotator object, to be called together with a.simplify()
[16:36] <arigo> it defaults to GenC-specific specialization
[16:37] <cfbolz> hum, can I avoid the floats in targetpypy1 somehow?
[16:37] <arigo> and the long...?
[16:38] <cfbolz> yup, them too.
[16:38] <arigo> not sure
[16:38] <pedronis> addind SomeFloat is one the next thing to do
[16:38] <arigo> yes
[16:39] <pedronis> sorting out our integer arith confusions would also be a good thing
[16:39] <pedronis> but that's not just an annotator issue
[16:39] <arigo> for longs, we might consider rewriting longobject.py to use simpler operations, e.g. x.__add__(y) instead of x+y
[16:40] <arigo> which can be supported with only getattr and simplecall
[16:41] <arigo> ok, I'm going for SomeFloat
[16:42] <arigo> cfbolz: if you are interested in the annotator's internals we can pair-program it in a shared screen session
[16:43] <cfbolz> Oh cool! I certainly am.
[16:43] <cfbolz> What do I need?
[16:43] <arigo> ssh codespeak.net
[16:43] <arigo> screen -x arigo/arigo
[16:46] <arigo> cfbolz: restart screen when you're back (it wouldn't resize screen's window, I had to restart it)
[16:48] <cfbolz> arigo: I'm ready
[16:54] <arigo> pedronis: what about adding operations systematically to SomeInteger?
[16:55] <stakkars> interesting ongoings, here!
[16:56] <stakkars> what do I need to work on, right now?
[17:03] <arigo> it seems that people are running out of work :-)
[17:03] <stakkars> not really, I'm running into confusion :-)
[17:03] <arigo> I think appinterplevel works right now too
[17:03] <stakkars> you are doing lots of things which I don't understand, yet, so I'm trying to catch up in some way.
[17:04] <arigo> the branch was a clean-up of exception handling, which are somehow nice now
[17:04] <pedronis> arigo: yes I reactivated it before merginng
[17:05] <pedronis> stakkars: we should sort the unsigned intergers and various arith stuff for example
[17:05] <pedronis> s/sort/sort out
[17:05] <stakkars> so you are focused on some solution of certtain types for all generators?
[17:06] <stakkars> ah, unsigned with overflow things, signed with wrap around
[17:10] <pedronis> yes and all things related
[17:20] <stakkars> great, all tests still pass
[17:20] <stakkars> somehow, the last changes can't easily be inspected, because the show up as"addition" of files.
[17:20] <stakkars> s/the/they
[17:22] <pedronis> you need to look at checkins mail for the branch
[17:22] <stakkars> yeah,doing this now
[17:31] <stakkars> pedronis: the changes aren't in the log, too :(
[17:31] <arigo> stakkars: you can just follow the log for the files, they should follow the file across moving around branches
[17:32] <pedronis> yes, I did the copying exactly to preserve the logs
[17:33] <stakkars> they are not in the email, and when I use tortise on the file, I don't see it.What am I missing?
[17:35] <stakkars> now the files were deleted, and then added again.no diff available :-(
[17:41] <pedronis> stakkars: the changes are in the mails about the branch, 10369-10388
[17:52] <stakkars> gack! I see normalize_exception is now interp-level !
[17:53] <stakkars> probably fine,and releases the burden to flow this stuff early.
[17:53] <arigo> stakkars: that was the whole point of the branch, basically
[17:54] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[17:57] <pedronis> yes, although discovering the bug such that an assert in analyzed code triggered the analysis of py.test stuff was fun ;)
[17:58] <stakkars> looks very nice to me!
[17:58] <stakkars> But can we use a different aproach to do merges? I don't like the disruption of files history very much.
[17:59] <stakkars> pedronis: hehe, escaping analysers are indeed fun
[18:00] <arigo> I don't understand why you see a disruption at all
[18:01] <stakkars> when I try to get the history of geninterp, for instance, tortoise shows me that it was added, and it can't show any diff.
[18:01] <pedronis> that's a limit of tortoise
[18:01] <pedronis> because we do the copying in fact to keep the proper logs
[18:02] <pedronis> svn log interpreter/error.py
[18:02] <pedronis> for example shows also the logs from the branch
[18:04] <stakkars> yes, I can see the changes now. I just need to search below the adding operation. confusing, but works.
[18:06] <arigo> stakkars: "adding" only means that the file was put in some directory, not that it is necessarily new
[18:06] <stakkars> it looked like the old version was explicitly removed, but probably this is the way svn does it.
[18:07] Gromit (~bear@dialin-212-144-184-010.arcor-ip.net) left irc: "Client Exiting"
[18:07] <pedronis> no, you have to do that because subversion does not let you do
[18:07] <pedronis> a svm rm , svn cp into working copy
[18:08] <pedronis> without a check-in in between
[18:08] <stakkars> ok
----- silence for 20 minutes ----- [18:28] lypanov (~alex@a80-126-190-213.adsl.xs4all.nl) joined #pypy.
[18:28] <lypanov> hey all :)
[18:29] <stakkars> honk :-)
[18:29] <lypanov> hehe
[18:29] <lypanov> yoyo stakkars :)
[18:29] <lypanov> how are things?
[18:29] <lypanov> any chance of a one line status report? :P
[18:29] <lypanov> i'm trying to make sense of the svn- list but its rather difficult to see the big picture... :)
[18:30] <stakkars> indeed.One line? oooooooh
[18:30] <stakkars> lots of refactorings, changes on normalize_exception, progress in annotation/translation, where to start with...
[18:30] <arigo> hi!
[18:31] <stakkars> in fact, might do good by giving a short (one para) summary of every few day's hackery
[18:36] <lypanov> arigo! :)
[18:36] <lypanov> stakkars: that would really rock :)
[18:37] <arigo> stakkars: yes
[18:37] <lypanov> stakkars: from the outside its really hard to grok progress
[18:37] <stakkars> even from the inside, for my case
[18:37] <lypanov> yeah :)
[18:37] Action: lypanov was just typing that :)
[18:37] <lypanov> unless you can explain to outsiders, its difficult to *fully understand* from the inside even
[18:38] <lypanov> hows annotation to pure c coming along?
[18:38] <lypanov> i've seen lots on the running on python part. but not sure on the progress of translation
[18:39] <lypanov> or is llvm now the path taken?
[18:39] <lypanov> arigo: result was go without c++ stuff right?
[18:40] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: "BeOS - Because you don't eat soup with a fork!"
[18:42] <stakkars> it seems to be not c++ stuff, now. genc is still most advanced, but at the moment, cfbolz and arigo are
[18:42] <stakkars> pair programming in a screen session, so it could also be llvm :-)
[18:43] <lypanov> hehe
[18:43] <stakkars> if you want to watch flying cursors,log into codespeak and use screen -x arigo/arigo
[18:44] <lypanov> lol
[18:44] Action: lypanov not on codespeak
[18:44] <lypanov> but i'll take ur word for it :P
[18:47] <arigo> we are working about annotation completeness now
[18:47] <arigo> adding missing arithmetic operations etc.
[18:47] <arigo> genc and genllvm are indeed kind of competitors
[18:47] <arigo> genc knows about "int" types, and function pointers, but no other types
[18:47] <cfbolz> but very friendly
[18:47] <arigo> :-)
[18:48] <arigo> genllvm is impressive in its code generation but only has limited "PyObject*" support, so it depends on annotations crucially
[18:48] <cfbolz> hey, thanks. Not that impressive actually.
[18:48] <arigo> but it's true that I should take a couple of days to really kick off genc's annotation support :-)
[18:49] <arigo> well i'm impressed because genc doesn't do any of that :-)
[18:49] <cfbolz> The problem is that genc annotation support will be cleaner when it's there
[18:49] <stakkars> btw., I found a bug that probably will hit genc in some future, too.
[18:50] <stakkars> (maybe genc does it differently,already, didn'tlook)
[18:50] <cfbolz> so I probably have to adapt llvm to typer in the near future
[18:50] <lypanov> so llvm is purely static or?
[18:50] <lypanov> (with regards to annotations, no type feedback right?)
[18:51] <cfbolz> what do you mean?
[18:51] <lypanov> and this sort of code is called rpython?
[18:51] <arigo> cfbolz: I'm not sure you need to change llvm if it works nicely
[18:51] <cfbolz> arigo: we'll see
[18:51] <arigo> lypanov: both genc and genllvm start from the same code, which is the static "R-Python" definition
[18:52] <lypanov> okay
[18:52] <lypanov> but llvm can do low level optimisations at runtime right?
[18:52] <cfbolz> not implemented yet, I think
[18:53] <lypanov> are for example the code transforms also possible at runtime or is that at compile time only?
[18:53] <stakkars> arigo: here the bug
[18:53] <lypanov> cfbolz; ah
[18:53] <stakkars> in t_pyobj you define
[18:53] <stakkars> def later(self, gen):
[18:53] <stakkars> self.latercode.append((gen, self.debugstack))
[18:53] <lypanov> cfbolz: but certainly possible via the current technique?
[18:53] <lypanov> cfbolz: what sort of speeds do u see now for basic code snippets?
[18:54] <cfbolz> lypanov: for very basic things: Faster than gcc, somtimes :-)
[18:54] <lypanov> cfbolz: neat :)
[18:54] <cfbolz> but that's mostly a feature of LLVM
[18:54] <lypanov> yeah
[18:54] <stakkars> arigo: this code is used for nameof_list and nameof_dict.
[18:54] <lypanov> cfbolz: but its still python ;)
[18:55] <lypanov> any idea when bootstrapping will work on either of them?
[18:55] <stakkars> This is wrong usage, will result in things being installed too late.
[18:55] <lypanov> or rather, is there a plan / target date for that and how well is it going?
[18:55] <arigo> stakkars: you had the problem in geninterp
[18:55] <cfbolz> lypanov: I think it will take quite some time to remove the CPython dependencies entirely
[18:56] <arigo> lypanov: agreed
[18:56] <stakkars> exactly. I resolved it by inserting the object name early into the know names, and then generating stuff inplace.
[18:56] <arigo> lypanov: but we are hoping to get reasonable intermediate results in, say, 1-3 months maybe
[18:56] <stakkars> Alternatively, I guess a later that *prepends* instead of appending might do it.
[18:56] <arigo> stakkars: I see
[18:57] <arigo> stakkars: well the idea was that init-time code shouldn't depend on things being already fully built
[18:57] <arigo> stakkars: I guess it only depends on what you are doing at init-time.
[18:58] <stakkars> well, I think I was building a list, which I needed to instantiate a type orclass or something.
[18:58] <lypanov> cfbolz: by cpython deps you mean actual references in the llvm generator to the cpython classes?
[18:58] <stakkars> I know that you avoided this completely for genc, because of the problem with "the other side" not seeing it early enpough.
[18:58] <arigo> stakkars: ah, maybe the __dict__ of the class itself
[18:59] <lypanov> cfbolz: or the deps of pypy on cpython?
[18:59] <stakkars> I had it with llists, but I'm not sure if you can generally avoid this.
[18:59] <cfbolz> lypanov: Well, genllvm doesn't do that at the moment, by I will have to add something like that in the next weeks. and it will take some time to get rid of it again :-)
[19:00] <lypanov> cfbolz; ah. hehe :)
[19:01] <lypanov> arigo: i'm up to 500arith-ops/sec on rubydium btw. up from 3sec/arith-op several months back
[19:01] <lypanov> (or 8000 with a trivial loop)
[19:01] <stakkars> arigo: I guess you don't step into the prob because all initialisation is done by the interpreter???
[19:01] idnar (mithy@idnar.user) left irc: Nick collision from services.
[19:01] idnar_ (mithrandi@idnar.user) joined #pypy.
[19:02] idnar (mithy@idnar.user) joined #pypy.
[19:06] <pedronis> cfbolz: see you
[19:07] <cfbolz> see you
[19:07] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[19:07] idnar (mithy@idnar.user) left irc: Client Quit
[19:14] <stakkars> I just had an interesting request by some client who asked me why his program doesn't
[19:14] <stakkars> run certain threads any longer.
[19:15] <stakkars> He was running his main program via an import statement :-)
[19:15] <stakkars> This mademe think about the general import problem, again, and that we might show alternative
[19:16] <stakkars> implementations which don't need to block. When we have stackless-like support, we can
[19:16] <stakkars> do imports in coroutines and can finish them in any required order.
[19:16] <stakkars> Just a brain dum(b|p)
[19:18] <arigo> makes sense.
[19:19] <stakkars> of course this would not solve *his* problem. The never-ending import would at least prevend other threads from completely importing *this* module. well.
[19:20] Nick change: idnar_ -> idnar
[19:20] <stakkars> but circularities would be much simpler to solve, if there is no stack order of executionenforced.
[19:21] <stakkars> pedronis: what is the status of the property.__doc__ problem, did you have time for a look?
[19:21] <pedronis> oops, sorry I forgot about that
[19:22] <pedronis> I can try that, I can look now
[19:22] Action: pedronis bad bad spelling
[19:22] <pedronis> how can I try that?
[19:22] <stakkars> that would be nice! I'm stuck, I don't get why it works in the interpreter but not when interp'ed.
[19:22] <arigo> argh Argh ARGH
[19:22] <arigo> bad biting typo:
[19:23] <arigo> writing a long list of strings
[19:23] <arigo> and forgetting a comma
[19:23] <stakkars> makes the list shorter :-)
[19:23] <pedronis> 'a' 'b' -> 'ab'
[19:23] <stakkars> pedronis:well,if Iknew this I would have a solution, maybe
[19:24] <stakkars> I prepared geninterplevel to watch out for the code snippet and it writes /tmp/look.py for you with the source code.
[19:25] <pedronis> yes, I see there's look.py in my tmp
[19:25] <stakkars> but to enable translation, you need to modify the comment line at the top of
[19:25] <stakkars> app_descriptor.py, otherwise it won't be run though the machinery.
[19:25] <pedronis> ok
[19:26] <pedronis> then complex alone
[19:26] <pedronis> fails
[19:26] <stakkars> I wouldlike to know if it is possible to deduct the behavior from the generated "assembly".
[19:26] <stakkars> The funny thing is:
[19:26] <stakkars> __doc__ *should* be a read-only attribute.
[19:26] <lypanov> doesn't python have a %w() ? (qw(a b c) in perl)
[19:27] <stakkars> when you use regular Python and execute the app_descr thing, you get a pretty working class,
[19:27] <stakkars> but it has the read/write __doc__ for some reason !! ??
[19:27] <arigo> lypanov: what's that doing?
[19:27] <stakkars> when PyPy interprets the applevel code, everythign works fine.
[19:28] <stakkars> Only after geninterp, it becomes read-only. That makes my brain melt,slowly.
[19:28] <stakkars> better to have another melitng brain :-)
[19:28] <lypanov> arigo: qw(a b c) -> ["a", "b", "c"]
[19:29] <stakkars> so I guess something with descriptor lookups gets messy, wheee hoo
[19:29] <arigo> sorry, I don't know Perl syntax, so I don't know what you mean with qw(a b c)
[19:29] <pedronis> the python idiom
[19:29] <lypanov> arigo: quoteword(a b c) makes a list of the strings "a" "b" and "c"
[19:29] <pedronis> lst = "a b c".split()
[19:29] <lypanov> yeah...
[19:30] <lypanov> ugly :)
[19:30] <stakkars> your progress to become a Python addict is ready when you say "nice", instead.
[19:30] Action: lypanov is a syntax sugar freak tho :P
[19:30] <lypanov> stakkars: couldn't ever say that.
[19:30] <arigo> :-)
[19:31] <lypanov> stakkars: the above implies assumptions about the implementation
[19:31] <lypanov> stakkars: i kind of like my code to imply its efficiency
[19:31] <lypanov> stakkars: and that really doesn't..
[19:32] Action: stakkars wonders if arigo has his stick at hand, from yesterday
[19:32] <lypanov> lol
[19:32] Action: lypanov wonders what the stick incident was yesterday :)
[19:32] <arigo> yes I wanted to say something along the lines of "don't use Perl or Python or Ruby for a language where each operation is equally efficient"
[19:33] <stakkars> http://nimrod.terra-link.net/pypy/%23pypy.log.06Apr2005
[19:35] <lypanov> arigo: you mean, "as an example of a language where ..."
[19:35] <lypanov> arigo: or, as a language in which each operator is equal in efficiency?
[19:36] <arigo> "if you want a language where"
[19:36] <lypanov> ah :)
[19:36] <lypanov> why would u ever want that? :P
[19:36] <arigo> :-)
[19:36] <arigo> well, then "a b c".split() is nice :-)
[19:36] <lypanov> ;)
[19:36] <lypanov> i still dislike it :P
[19:37] <arigo> actually I agree that method calls on literals are slightly ugly
[19:37] <stakkars> string.split("a b c")
[19:37] <lypanov> stakkars: better. but huge
[19:37] <pedronis> stakkars: what I found out so far
[19:37] <pedronis> is that PyPy own property has a writable __doc__
[19:38] <stakkars> str.split("a b c") # this is actually better
[19:38] <arigo> indeed, all slots of class property are writable because they are slots
[19:38] Action: lypanov still likes %w(a b c) the most :P
[19:38] <pedronis> stakkars: but standard python property __doc__ is not
[19:38] <stakkars> ok, so far things are consistent (although I'm not sure if it is ok so)
[19:39] <stakkars> so what the heck is different after translation?
[19:39] <pedronis> so we have in our code or the generated code a x.__doc__
[19:39] <pedronis> stakkars: well, this seems that with translation
[19:39] <pedronis> something using CPython property
[19:39] <pedronis> instead of our own
[19:40] <pedronis> and we have code that does p.__doc__=...
[19:40] <stakkars> that was my feeling, too. ut I didn't find a way to nail that down. The error message is from PyPy
[19:40] <pedronis> and this crashes with CPython __doc__
[19:40] <stakkars> then this must be visible in some way in the generated code?
[19:40] <arigo> time to clean up the flowobjspace's handling of built-ins ?
[19:40] <stakkars> but we do a simle setattr operation.
[19:41] <arigo> what occurs is that you get a Constant(property) in the flow graph
[19:41] <arigo> with CPython's built-in "property"
[19:41] <stakkars> but I translate it bravely:-o
[19:42] <pedronis> how do you translate properties?
[19:43] <stakkars> erhmm, I have some special typemap entry, but the problem occoured even before I added it.
[19:44] <arigo> hum, I'm not sure about what I just said
[19:44] <stakkars> the generated code does not contain any real reference to a real property.
[19:44] <pedronis> arigo: not strange, we have so many moving parts that it easy to forget how
[19:44] <pedronis> something exactly works
[19:44] <arigo> :-)
[19:45] <stakkars> we need, atsome point, to write up a big picture, the "who is who in PyPy"
[19:45] <arigo> well
[19:46] <arigo> there are already some documents about the big picture
[19:46] <arigo> but it's hard to describe the "medium-sized" picture
[19:46] <stakkars> ok, I meant a big big picture of medium sizedlittle pictures
[19:46] <stakkars> and the hard thing would be to *always* keep that in sync.
[19:47] <arigo> we might think about a way to attach any amount of extra documentation to places in the code, or files, or directories
[19:47] <stakkars> yes. It should make giving the crucial information as easy as adding docstrings.
[19:48] <stakkars> then wecan extract information, and instead of browsing source code, we can browse concepts.
[19:48] <arigo> well, the source is the concepts
[19:48] <arigo> I'm more thinking about extra information that doesn't fit in the general docstrings
[19:49] <arigo> because it would be far too verbose
[19:49] <stakkars> not now. Try to get a newbie through the source. He runnsaway crying, when he sees the first __extend__ class
[19:49] <arigo> yes, that's why I want to be able to say a word about __extend__ in extra docstrings
[19:50] <arigo> I don't want to build yet another organization, but I want the source to become easier to grasp
[19:50] <arigo> with doc that can link to more information etc.
[19:50] <arigo> and to related concepts.
[19:51] <stakkars> ok, they would need to be in a special place,probably not scattered over everything,
[19:51] <stakkars> but probably some source code is the better place to add info "while you are at it".
[19:52] <arigo> yes, but we should be able to do that without actually writing it into the source -- far too much info
[19:52] <stakkars> where do you put things like "in PyPy, these are slots and therefore always writable"?
[19:53] <arigo> well I'd like to write it in-line in the source
[19:53] <arigo> but I'd also like to avoid that all this information makes the source twice or 5x as big
[19:53] <stakkars> right. But that spot is hard to find if you want to extract meta-info.
[19:54] <stakkars> not necessarily. I think, besides implementation details and other comments, there are
[19:54] <arigo> I know it's not an easy problem, just saying "it would be nice" and wondering if there are tools out there that try to do that.
[19:54] <stakkars> some small sentences necessary and sufficient to say. They could sit in something, like __metainfo__
[19:54] <arigo> I don't agree with that
[19:54] <stakkars> or __general__
[19:55] <arigo> the log messages of svn are a proof that sometimes you need to say a lot about few things
[19:55] <arigo> I definitely would like to say more than I feel like the source can reasonably contain
[19:56] <arigo> also, sometimes giving pointers to other meta-info, to e-mails, to svn log messages, etc... you don't want that crap all over the source
[19:56] <pedronis> stakkars: the difference seems related to the fact that you special case __doc__
[19:56] <stakkars> if you are exploring the source, you'd love this.
[19:57] <pedronis> stakkars: so when you construct the property class you set __doc__ in its dict to a string
[19:57] <arigo> stakkars: possibly, but once you're done exploring, it becomes a major nuisance
[19:57] <stakkars> right, I'd like to fold this away. Unfortunately not an option.
[19:57] <pedronis> stakakrs: not the docstring special class instance as it happens effectively in source code done
[19:57] <pedronis> s/done//
[19:58] <stakkars> pedronis: I'm special casing __doc_ ???
[19:58] <stakkars> pedronis: aaaarghhhh
[19:59] <pedronis> property __doc__ should be simply a string
[19:59] <pedronis> SHOULD NOT
[20:00] <stakkars> you mean this code?
[20:00] <stakkars> if cls.__doc__ is not None:
[20:00] <stakkars> sdoc = self.nameof("__doc__")
[20:00] <stakkars> andso on?
[20:00] <stakkars> self.initcode.append("space.setitem(_dic, %s, _doc)" % (
[20:00] <stakkars> self.nameof("__doc__"),))
[20:01] <pedronis> but the question is about _doc
[20:01] <pedronis> it depends how you read the original __doc__
[20:02] <pedronis> because in look.py _doc for property is just a string
[20:02] <pedronis> but it should be an instance of docstring
[20:02] <stakkars> puuuuh, I begin to understand
[20:03] <stakkars> yes, I simply take the doc and thus invoke the instance to give me the string.
[20:03] <stakkars> then I put in the string, andall magic is lost.
[20:03] <pedronis> you should if __dict__['__doc__'] is something strange
[20:03] <pedronis> should check
[20:04] <stakkars> and thenuse the nameof(that object) instead of a string result?
[20:05] <stakkars> 1024 thanks!
[20:07] <pedronis> stakkars: yes, at least this is something to try
[20:07] <pedronis> I still don't understand completely the failure itself
[20:08] <stakkars> well, I seem to kill the __doc__ magic by assigning a string to the class attribute.
[20:09] <stakkars> but, actuially, I could be biten by such things in other places, too. oh-oh
[20:10] <pedronis> stakkars: no now I see
[20:10] <pedronis> property has __slots__
[20:10] <stakkars> well, the right thingis not to use the doc attr, but the dict entry
[20:10] <pedronis> so setting an attr not among the slots fails
[20:10] <stakkars> well, and sees the __doc__ which is read-onlyclass attribute?
[20:11] <arigo> pedronis: another of your check-ins was lost by the branch merge
[20:11] <stakkars> no, which is read-only, but does not exist at all in the instance.
[20:11] <pedronis> stakkars: yep
[20:11] <arigo> pedronis: std/objspace.py: "don't pollute *_w results with the logic for wrapped object returning mms"
[20:11] <pedronis> umph
[20:11] <arigo> pedronis: should I merge it back?
[20:11] <pedronis> yep
[20:11] <pedronis> thank you
[20:12] <arigo> I've just finished a "lost check-in detection tool" :-)
[20:14] <stakkars> whow!
[20:15] <stakkars> pedronis: ok, when I find a string in the __dict__, all is fine.
[20:16] <stakkars> pedronis: but when something else is there, can i simply use it? If that is a specialmember descriptor, then I have to do something else to trigger its creation, isn't it?
[20:16] <pedronis> yes, btw this one of those, I need the object now, the name is not enough cases
[20:20] <stakkars> you mean self.later() would fail here, instead Ineed it right now.And it would apply to genc, too.
[20:26] <stakkars> whow, works now. :-)
[20:26] <stakkars> I'm removing the /tmp/look.py
[20:38] Action: pedronis is leaving the office, see you possibly later
[20:38] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[20:39] <stakkars> bye
[20:43] stakkars (~tismer@82.144.60.19) left irc: ""see"
[20:58] arigo (~arigo@134.99.112.244) left irc: Remote closed the connection
----- silence for 17 minutes ----- [21:15] pedronis (~Samuele_P@c-3c8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[21:20] adim (~adim@82.229.225.51) joined #pypy.
----- silence for 22 minutes ----- [21:42] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 24 minutes ----- [22:06] adim (adim@82.229.225.51) left #pypy.
[22:08] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "Leaving"
[22:11] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[22:13] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 131 (Connection reset by peer)
[22:14] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
[22:17] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Client Quit
[22:24] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 23 minutes ----- [22:47] lypanov (alex@a80-126-190-213.adsl.xs4all.nl) left #pypy.
[00:00] --- Fri Apr 8 2005