[00:00] <stakkars> I don't see why I shouldn't use it for stuff like _formatting, too.
[00:00] <arigo> because the annotator is simply not meant for app-level code
[00:00] <arigo> at the moment, honestly, I don't want even more strange code in there
[00:01] <arigo> it's already full of the stuff
[00:02] <arigo> the problem is that you can do nice things as a first step with little efforts -- ints and strings, say
[00:02] <stakkars> I'm not talking of changes to the annotator.
[00:02] <arigo> but it will lead to other steps
[00:02] <arigo> ...not yet
[00:02] <arigo> you don't need to change it at first
[00:02] <arigo> for simple cases like int and str
[00:02] <stakkars> you mean I would get greedy after first successes?
[00:03] <arigo> e.g. you'll want ints to produce longs when they overflow
[00:03] <arigo> you're very quickly going to need changes in the annotator
[00:03] <stakkars> absolutely not
[00:03] <stakkars> our applevel code is RPythonic. That was the concept
[00:04] <arigo> _formatting isn't doing long arithmetic?
[00:04] <stakkars> I don't remember. But it is definately rpythonic.
[00:05] <arigo> not if it uses long arithmetic
[00:05] <stakkars> if something uses long, then it must be like r_unit.
[00:05] <arigo> the point is that you can't use the unmodified annotator, then
[00:06] <arigo> you can't use the simple rules about int arithmetic
[00:07] <arigo> _formatting has classes with __iter__()
[00:07] <arigo> it is mixing types, e.g. floats and ints and longs
[00:08] <stakkars> yes, I justskimmedthough it.
[00:08] <arigo> the point is that the annotator cannot do anything correct on that
[00:09] <stakkars> you mean the code is not explicit about types
[00:09] <stakkars> and iterators are a no-no?
[00:09] <arigo> these were examples of things that are currently no-no's.
[00:10] <arigo> it's of course *possible* to do _formatting, but not with the current annotator at all
[00:10] <stakkars> ortoclean-up _formatting,maybe. Ok. it might work with md5
[00:11] <stakkars> you convinced me that I cannot simply switch it on for geninterp.
[00:12] <arigo> no:
[00:12] <stakkars> yes, you did
[00:12] <arigo> I mean, no about MD5
[00:12] <stakkars> because of the long masks?
[00:12] <arigo> because there are better solutions for MD5 for the moment
[00:13] <arigo> most of md5.py is "plain RPython code"
[00:13] <arigo> so what we can do easily is:
[00:13] <arigo> extract the bits that are really arithmetic code
[00:13] <arigo> drop explicit r_uints in there
[00:13] <arigo> move it to a lazymodule, i.e. pypy/module/md5/core.py
[00:13] <arigo> write an interface in pypy/module/md5/__init__.py
[00:13] <stakkars> sure, and we don't need the double layering at all
[00:14] <arigo> the point is that if we compare the two approaches,
[00:14] <arigo> geninterp has clear long-term advantages
[00:14] <arigo> but the lazymodule has clear short-term advantages
[00:14] <arigo> including, I may say, freeing you for work that I feel is more needed right now
[00:14] <stakkars> yes, I thought that already. If something stands the annotator, then it is probably too primitive for geninterp
[00:15] <arigo> and *right* now making a decision about md5 is premature. we still even have no clue how fast PyPy can be after translation.
[00:17] <stakkars> ok, I was mislead by the assumption that the annotator should annotate all flow space output.
[00:18] <pedronis> no, flow space does not care about types so whether something can be analyze by it does not mean much about its use of types
[00:19] <pedronis> the flow space knows only constants and variables what passes through variables is mostly ignored
[00:19] <stakkars> it doescareabout builtin types
[00:19] <arigo> ?
[00:19] <stakkars> confuzius, sorry
[00:21] <stakkars> pedronis: I was talking about the annotator. It does a great job to primitive types.
[00:22] <pedronis> yes, but app-level and interp-level are different
[00:22] <stakkars> beggining to unerstand this
[00:22] <pedronis> conceptually you need different type system and rules
[00:22] <pedronis> to annotate those
[00:22] <pedronis> and some things would still be a bit out of reach
[00:23] <pedronis> so you would need to start from scratch
[00:23] <stakkars> I'm still talking of rpython
[00:23] <pedronis> app-level code that looks mostly like rpython is not rpython
[00:23] <stakkars> not the same exception rules?
[00:23] <pedronis> for example
[00:24] <pedronis> app-level getattrs can fail
[00:24] <pedronis> not the case for rpython
[00:25] <stakkars> yes, builtins_can_raise stuff. Not the real problem I guess
[00:25] <arigo> the annotator makes simplifying assumptions on the types
[00:26] <arigo> int-to-long automatic conversion cannot happen
[00:26] <arigo> for example
[00:26] <pedronis> ints don't wrap around but becomes long
[00:26] <arigo> but there are a lot of obscure examples all over the place
[00:26] <stakkars> ah,no!
[00:26] <stakkars> we should have talked about that earlier.
[00:26] <stakkars> I *always* assumed that these rules apply. my fault
[00:27] <arigo> (may I remind everybody to keep in mind that the long-term goal is not static compilation of anything)
[00:27] <stakkars> then the simple examples of main programs are wrong?
[00:27] <arigo> ?
[00:27] <pedronis> ?
[00:27] <stakkars> if getattr does not raise, and we use print???
[00:28] <pedronis> well it involves some objects but for general targets is very hackish to inline the helpers at interp-level
[00:29] <pedronis> SomeObjects I mean
[00:29] <pedronis> that means the print fix as long as you have support for SomeObject as Python objects around
[00:30] <pedronis> s/fix as/fix work as/
[00:30] <stakkars> yes, it is limited
[00:31] <stakkars> arigo: ad geninterp, you said is had long-term advantages.
[00:32] <arigo> stakkars: yes, definitely. for now I am stressing the "long-term" in the sentence
[00:32] <stakkars> but right now I think if we don't go further, it has only a little effect, like giving precompiled
[00:32] <stakkars> stuff when we are bootstrapping.
[00:32] <arigo> yes
[00:33] <stakkars> All the other cases are not helping anything, because we don't gather much
[00:33] <stakkars> speed, and we have ugly caches.
[00:33] <stakkars> That was why I thought to make more sense out of it.
[00:33] <stakkars> everything it does now can easily be don by flowing on-the-fly. No need to have generated source
[00:34] <arigo> never needs to generate source for annotation...?
[00:34] <arigo> the caches are fine because PyPy starts in 5 sec instead of 30 on my machine
[00:34] <stakkars> yes,but in the long term, geninterpo will vanish
[00:35] <stakkars> and when my pickling is ready, you don't need source code, but just load a flowgraph and use a graph interpreter, maybe
[00:36] <stakkars> ok, maybe we need the bytecode.
[00:37] <arigo> stakkars: we need to talk more about your plans at EuroPython
[00:37] <arigo> at the moment I'm not really making much sense
[00:38] <pedronis> stakkars: you cannot directly embed app-level flowgraph into the set of interp-level ones
[00:38] <stakkars> pedronis: no, I cannot.
[00:39] <stakkars> but there is just no point in generating the source code.
[00:45] <stakkars> just a last word to reduce confusion (and I'm not doing this now)
[00:46] <stakkars> instead of generating source code and leaving it in python source form in _cache,
[00:46] <stakkars> we could avoid this completely and instead
[00:47] <stakkars> store the compiled functions which are living in the caches as pickle files.
[00:48] <stakkars> the interface to the magically created stuff consists of functions in interpreter/gateway.
[00:49] <stakkars> after compilation is done, everything lives in internal caches.
[00:49] <stakkars> instead of saving source and re-importing, we could reload these caches from a big pickle and that's it.
[00:49] <stakkars> end of story - night :-)
[00:54] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 44 minutes ----- [01:38] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "good night"
----- silence for 38 minutes ----- [02:16] <Rhamphoryncus> I don't suppose anybody in here would be able to give me some feedback/help with a PEP for a concurrency extension for python I'm developing? Nothing to do with PyPy actually, but the people in #Python are quickly scared off by any discussion of threading for some reason ;)
----- silence for 50 minutes ----- [03:06] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
----- silence for 24 minutes ----- [03:30] -deedra (dmwaters@dmwaters-osuosl.staff.freenode) to $*- {global notice} Hi all! in 5.5 hours, I'm going to begin the maintenence on the network. This will affect about half the network. For more information, please see 'http://www.freenode.net/news.shtml' Thank you for your patience, and thank you for using freenode!
----- silence for 23 minutes ----- [03:53] <Rhamphoryncus> Yeah, that's what they say too
[03:55] <stakkars> Rhamphoryncus: maybe you should wait for daylight. Most of this group is in Europe
[03:56] <Rhamphoryncus> ahh good point
[03:57] <stakkars> they will help, for sure. (I'm hacking late now and almost asleep :-)
[03:57] <Rhamphoryncus> heh okay
[03:57] <Rhamphoryncus> Trying to design something in a vacuum sucks. I really need the feedback :/
[03:58] <stakkars> there is only avacuum of you have no use-case I guess.
[03:58] <stakkars> s/of/if/
[03:59] <Rhamphoryncus> eh, writing a httpd from scratch is a lot of work :)
[04:00] <stakkars> is that the need for concurrency?
[04:00] <Rhamphoryncus> Anything that wants or needs to do things concurrently :)
[04:01] <Rhamphoryncus> I've experimented with a httpd, a gui toolkit, an irc bot..
[04:01] <stakkars> does not need threads at all for concurrency.
[04:01] <Rhamphoryncus> It's *easier* with threads
[04:01] stakkars (sjsjoubq@i528C13E8.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[04:02] stakkars (bjbnobj@i528C13E8.versanet.de) joined #pypy.
[04:02] <stakkars> hum, irc crash
[04:02] <Rhamphoryncus> heh wb
[04:03] <Rhamphoryncus> The existing options are either a state machine (callbacks) or preemptive threads
[04:03] <stakkars> I just tried to say: I see no point in that a httpd needs threads at all.
[04:03] <stakkars> no state machine, no preemptive threads.forget about that crap.
[04:04] <Rhamphoryncus> Do you want to have more than one connection at once? :)
[04:04] <stakkars> sure :-)
[04:04] <Rhamphoryncus> Then you need a state machine or preemptive threads. Or my cooperative threads :)
[04:04] <stakkars> nope :-)
[04:04] <Rhamphoryncus> You have another option?
[04:05] <stakkars> guess why I invented Stackless Python?
[04:05] <Rhamphoryncus> You invented stackless?
[04:05] <stakkars> yes.
[04:05] <Rhamphoryncus> heh
[04:06] <Rhamphoryncus> My attitude is that stackless would allow experimenting with a better language. My concurrency extensions are the better language you'd experiment with :)
[04:06] <stakkars> well, if you can do it without threads, I'm interested.
[04:08] <Rhamphoryncus> You can use whatever cheap threads you want. Internally you could do it very similarly to generators
[04:08] <Rhamphoryncus> Does *not* need kernel threads
[04:08] <stakkars> use tasklets. They give you all of generators and much more.
[04:08] <Rhamphoryncus> Not in debian :/
[04:09] <stakkars> Actually, the *build* the state machines that you need.
[04:09] <stakkars> sorry, there is confusion about tasklets.
[04:09] <stakkars> I'm not sure if I invented the name or Linux. I mean Stackless tasklets.
[04:10] <Rhamphoryncus> yeah I understand
[04:10] <stakkars> internally, you use polling, or select, or whatever, see the techniques in asyncore.py
[04:11] <Rhamphoryncus> I use poll :)
[04:11] <Rhamphoryncus> I was actually gonna try porting to stackless
[04:11] <stakkars> for the user interface, you use tasklets. They give the user the idea that it completely blocks.
[04:11] <stakkars> but the truth is that you don'tblock,but run the next tasklet available. Kindof moving the OS into the app.
[04:11] <Rhamphoryncus> I'm sure it'd improve the performance for my proof-of-concept implementation dramatically over kernel threads
[04:12] <Rhamphoryncus> yes I understand, that's what I do :)
[04:12] <stakkars> so we are from the same breed
[04:12] <Rhamphoryncus> Yeah
[04:12] <Rhamphoryncus> lots of overlap
[04:12] <Rhamphoryncus> Biggest difference would be mine is deliberately limited
[04:12] <stakkars> wot?
[04:13] <stakkars> this reminds me that I *urgently* need to port Stackless to 2.4
[04:13] <stakkars> PyPy is blocking me completely.
[04:15] <Rhamphoryncus> Several things. Scheduling is automatic, normal programs don't have control over it. Threads are "prejoined", so any exceptions from them are injected to just about the function that spawned them. And there's a different between normal functions and "concurrent" functions that can trigger the scheduler (and in fact do so automatically when called)
[04:16] <stakkars> doable, yes.
[04:16] <stakkars> While I'm not sure about automatic scheduling. None of my customers wants it
[04:17] <Rhamphoryncus> Different perspective :)
[04:17] <stakkars> what is a "concurrent" func?
[04:17] <Rhamphoryncus> http://members.shaw.ca/rhamph/asyn/examples/echoserver.py
[04:17] <Rhamphoryncus> One that uses the "blocking" I/O calls
[04:18] <stakkars> dooh, decorators
[04:19] <stakkars> and import * tss tss
[04:19] <Rhamphoryncus> Two reasons for it. First, it allows you to trivially guarantee atomicity (non-concurrent functions can't trigger the scheduler)
[04:19] <Rhamphoryncus> Second, you can limit it to explicitely-supported functions, so there's no issue with combining it with the C stack
[04:20] <stakkars> sounds good
[04:20] <Rhamphoryncus> decorators make it *much* simpler :(
[04:20] <stakkars> scheduling only occours on @sthread?
[04:20] <Rhamphoryncus> yup
[04:21] <Rhamphoryncus> (the name of which is a historical artifact. I'm pondering renaming it to @concurrent)
[04:21] <stakkars> so you are probably always in a context where you don't need to worrxy about C stack
[04:21] <stakkars> might be extremely efficient with STackless.
[04:21] <Rhamphoryncus> yeah
[04:23] <Rhamphoryncus> Even stackless might be overkill.. but far better than kernel threads ;)
[04:23] Action: stakkars is heading for bed and nice dreams about @concurrent
[04:23] <Rhamphoryncus> hehe
[04:23] <Rhamphoryncus> okay, I'll put #pypy on my autojoin list ;)
[04:23] <stakkars> you mean it would be doable with generators?
[04:23] <stakkars> if so then do it!
[04:24] <Rhamphoryncus> Behaviorally, yes, syntactically, no
[04:24] <stakkars> tasklets are twice as slow as generators
[04:24] <Rhamphoryncus> Generators are statements (no return values or exceptions), no try/finally allowed
[04:24] <stakkars> and a bit bigger. No big deal.
[04:24] Action: Rhamphoryncus nods
[04:25] <stakkars> but if you can produce something nice without touching weird things like Stackless, I would recommend :-))
[04:25] <Rhamphoryncus> heh
[04:25] <Rhamphoryncus> Need to hack CPython directly to do it right :/
[04:26] <stakkars> you get shifted into the "we don't support that" edge
[04:26] <Rhamphoryncus> yeah
[04:26] <stakkars> well, hacking CPython is probably worse.
[04:26] <Rhamphoryncus> kernel threads work for behavior. They just ruin the performance. But if I can demonstrate the behavior is GOOD...
[04:27] <stakkars> I'm the one who gets bashed for adding non-standard magic, why should you, too if it works
[04:27] <Rhamphoryncus> yeah
[04:27] <Rhamphoryncus> I think the real problem with all that stuff is it's primary use is to impliment things that should be provided by the language to begin with
[04:28] <stakkars> (late nite) do I understand you right that you mean this is a missing feature of Python?
[04:29] <Rhamphoryncus> No, the complete opposite
[04:29] Action: stakkars hopes for enlightment
[04:29] <Rhamphoryncus> It's better to add the feature to the language directly, without need for stuff like continuations or stackless or whatever
[04:30] <Rhamphoryncus> But PyPy.. Well it can benefit from those things because it *IS* implimenting the language
[04:31] <stakkars> but what you want is concurrency, to implement your stuff. Isn't this automatically pulling in kindof cheap multitasking?
[04:31] <stakkars> and this is what I do, nothing else.
[04:31] <Rhamphoryncus> You could see it that way. Or you could see it as *providing* cheap multitasking
[04:32] <stakkars> I'm too blinded to see the difference :-)
[04:32] <Rhamphoryncus> The joy of computers. So many things are equivelent ;)
[04:33] <stakkars> did you have a look at the PyPy release? I think it's great.
[04:34] <stakkars> still limited, but compliant to a large degree, good documentation
[04:34] <Rhamphoryncus> I read a bunch of stuff on the website. Kinda glazed over the details ;)
[04:34] <stakkars> and can produce efficient mini-programs already
[04:35] Action: Rhamphoryncus nods
[04:35] <Rhamphoryncus> I'm eager to see where PyPy goes :)
[04:35] <stakkars> I'm lying on the python list. My personal goal is to compete, and to really blow CPython away. (ahem)
[04:36] <Rhamphoryncus> I bet it would be easier to add my concurrency stuff to PyPy than to CPython
[04:36] <Rhamphoryncus> I'd love to see that :)
[04:36] <stakkars> absolutely! You can do that!
[04:36] <stakkars> please talk to the group, before.
[04:37] <stakkars> btw., Stackless will be folded into this, too. Not as a must, but as an option at least.
[04:37] <Rhamphoryncus> Heh, I'll wait until the peformance is up to par. That's the only reason to leave my current approach after all :)
[04:37] Action: Rhamphoryncus nods
[04:37] <stakkars> you can help!
[04:38] <stakkars> there is just this tiny factor of 2000
[04:38] <Rhamphoryncus> hehe
[04:38] <stakkars> willget to 100 after C compilation. Then, we must do tricky things.
[04:39] <Rhamphoryncus> Ever pondered hooking into gcc?
[04:39] <stakkars> considered, but machine code generation is actually not the problem
[04:39] Action: Rhamphoryncus is good at dreaming up wacky schemes. Not so good at making them work ;)
[04:40] <Rhamphoryncus> What is? Sufficient analasis to figure out what can be done cheaply and what has to be done expensively?
[04:40] <stakkars> a simple primitive object to C translation is under the works.
[04:41] <stakkars> The problem is, that we not only rewrote Python in Python,
[04:41] <stakkars> bt also that we used a much higher layer of abstraction.
[04:41] Action: Rhamphoryncus nods
[04:42] <stakkars> Without that, simple translation after type inference should just generate CPython.
[04:42] Action: Rhamphoryncus nods
[04:42] <stakkars> but there is the other factor of 100, which can only meltdown if we do more agressiveanalysis on
[04:43] Action: Rhamphoryncus nods
[04:43] <stakkars> a higher level, and fold all the abstraction away. I believe it is possible, tho.
[04:44] Action: Rhamphoryncus nods
[04:44] <stakkars> finally, if the "space" argument becomes really handled as a constant and everything gets spliced in directly,
[04:44] <stakkars> the problem will vanish (hope jhope)
[04:44] Action: Rhamphoryncus nods
[04:45] <Rhamphoryncus> I have a feeling I'm hearing all your internal ponderings ;)
[04:45] <stakkars> you hear my stomach grumbling. When I started, I was heading for something simple.
[04:45] <Rhamphoryncus> heh
[04:45] <Rhamphoryncus> I'll let you go then :)
[04:46] <stakkars> It happened to become the most abstract and evolved project I ever have seen. But well -- good nite
[04:46] <Rhamphoryncus> hehe g'night
[04:46] <stakkars> see you, hopefully. Where do you come from?
[04:48] <Rhamphoryncus> Canada? :)
[04:48] <stakkars> ah
[04:49] <stakkars> time zone?
[04:49] <Rhamphoryncus> umm.. Mountain? -0700 I think
[04:49] <Rhamphoryncus> But I pay no attention to it ;)
[04:51] <stakkars> ok, 8 or 9 hours, then. Late nite is then most probaly when you show up.
----- silence for 17 minutes ----- [05:08] Rhamphoryncus (~rhamph@rhamphoryncus.user) left irc: ""What do you mean, how many hit points do I have?" || Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html";
----- silence for 2 hr and 32 minutes ----- [07:40] -deedra (~dmwaters@dmwaters-osuosl.staff.freenode) to $*- {global notice} Hi all! in about an hour and 15 minutes, I'm going to start in on upgrades to the network. This will be a major upgrade that affects about half the network. Please see 'http://www.freenode.net/news.shtml' for more info. Thank you for your patience, and thank you for using freenode!
----- silence for 18 minutes ----- [07:58] stakkars (bjbnobj@i528C13E8.versanet.de) left irc: Read error: 113 (No route to host)
----- silence for 29 minutes ----- [08:27] -deedra (dmwaters@dmwaters-osuosl.staff.freenode) to $*- {global notice} Hi all! in half an hour I'm going to be rebooting several boxes for upgrades. This will affect about half the network. Please see 'http://www.freenode.net/news.shtml' for more information. Any further announcements are going to be given in wallops, '/mode your_nick +w' if you would like to watch what's going on. I will announce what happens as I take boxes down for reboot.
----- silence for 35 minutes ----- [09:02] hpk (~hpk@merlinux.de) got netsplit.
[09:02] hpk (~hpk@merlinux.de) returned to #pypy.
[09:07] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.
[09:07] mwh (~user@pc150.maths.bris.ac.uk) returned to #pypy.
[09:08] ericvrp (~chatzilla@ericvrp.demon.nl) joined #pypy.
[09:09] dialtone (~user@host111-56.pool80117.interbusiness.it) got netsplit.
[09:10] dialtone (~user@host111-56.pool80117.interbusiness.it) returned to #pypy.
[09:20] pyb0t joined #pypy.
[09:23] idnar (mithrandi@idnar.user) joined #pypy.
[09:28] tic (~vision@static-213-115-110-186.sme.bredbandsbolaget.se) joined #pypy.
[09:30] bbailey (~bbailey@adsl-146-20-126.mia.bellsouth.net) joined #pypy.
[09:30] hpk (~hpk@merlinux.de) joined #pypy.
[09:45] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] Hi all. We're stable again. Thanks to dmwaters for her excellent work on this upgrade!
----- silence for 1 hr and 1 minute ----- [10:46] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] Hi all. Last bit of wrap-up. If you were in #gentoo or #debian before the maintenance, you'll probably want to rejoin. You might have to try a few times. Thanks again for your patience and understanding, and thank you for using freenode! :)
----- silence for 53 minutes ----- [11:39] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[11:46] dialtone (~user@host111-56.pool80117.interbusiness.it) left irc: Remote closed the connection
[11:57] dialtone (~user@host111-56.pool80117.interbusiness.it) joined #pypy.
[12:02] ericvrp_ (~chatzilla@ericvrp.demon.nl) joined #pypy.
[12:15] <ericvrp_> I have added a reference to PyPy on http://en.wikipedia.org/wiki/Python_programming_language#Miscellaneous
[12:29] ericvrp__ (~chatzilla@ericvrp.demon.nl) joined #pypy.
[12:29] ericvrp__ (~chatzilla@ericvrp.demon.nl) left irc: Client Quit
[12:29] ericvrp_ (~chatzilla@ericvrp.demon.nl) left irc: "Chatzilla 0.9.68.3 [Firefox 1.0.4/20050511]"
----- silence for 24 minutes ----- [12:53] yuuh (zjuyzi@i528C13E8.versanet.de) joined #pypy.
[12:56] dialtone (~user@host111-56.pool80117.interbusiness.it) left irc: Remote closed the connection
[12:57] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[13:11] ericvrp_ (~chatzilla@ericvrp.demon.nl) joined #pypy.
[13:16] ericvrp (~chatzilla@ericvrp.demon.nl) left irc: "Chatzilla 0.9.68.3 [Firefox 1.0.4/20050511]"
[13:16] Nick change: ericvrp_ -> ericvrp
----- silence for 37 minutes ----- [13:53] yuuh (zjuyzi@i528C13E8.versanet.de) left irc: Connection timed out
----- silence for 23 minutes ----- [14:16] Rhamphoryncus (~rhamph@rhamphoryncus.user) joined #pypy.
----- silence for 42 minutes ----- [14:58] <hpk> ericvrp: cool
[14:58] <hpk> ericvrp: i have also been reading the excellent wikipedia pages about compilers
[14:58] <hpk> whe should try to cross-reference our documentation with it
[15:00] Action: arigo did some reading too
[15:00] <arigo> our graphs are really in SSI form (static single information)
[15:00] <hpk> ah
[15:00] <arigo> converting them to SSA isn't difficult
[15:00] <hpk> ericvrp: i can'T find the PyPy link on the page you mentioned
[15:01] <hpk> arigo: yip
[15:01] <arigo> hpk: i can find the link
[15:01] <hpk> please do
[15:02] <arigo> I mean I *do* find the link when I follow ericvrp's
[15:02] <hpk> a now i do too
[15:02] <hpk> strange
[15:03] <hpk> SSI also on wikipedia
[15:03] <hpk> or where did you come to the conclusion?
[15:12] <arigo> from the short mention on http://en.wikipedia.org/wiki/Static_single_assignment_form, Samuele did some more extensive researches outside
[15:13] <arigo> SSI seems not used that often; we'll probably want to get back to SSA when we think about low-level compiler optimizations
[15:13] <arigo> e.g. people tried to do register allocation on SSI but it works better on SSA
[15:13] <hpk> with phi?
[15:14] <arigo> not necessarily "phi" explicitely
[15:14] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[15:14] <arigo> http://codespeak.net/svn/user/arigo/hack/pypy-hack/valueset.py
[15:14] Action: hpk would enjoy very much if samuele recoreded some of the interesting links into a "further reading" in translation.txt
[15:14] <hpk> arigo: i have seen that :-)
[15:14] <arigo> it's a flow-graph "simplify.py-like" transformation from SSI to SSA
[15:15] <arigo> the result is SSA in the sense that variables are usually not renamed all the time
[15:16] <hpk> could flowspace actually produce SSA (using phi's parametrized over the links) from the beginning?
[15:17] <arigo> probably not easily, and also all the transformations we're doing on the flow graph are simpler in SSI
[15:17] <hpk> for example?
[15:18] <arigo> well, we assume in a lot of places that we don't have the same variable in different blocks
[15:18] <arigo> it would be a large change in the model, basically
[15:19] <arigo> note also that SSI implies SSA -- i.e. our graphs are also SSA anyway
[15:19] <arigo> SSI imposes more restrictions than SSA.
[15:19] <hpk> sure, i am not proposing
[15:20] <hpk> just asking
[15:20] <arigo> ok
[15:20] <hpk> you may have to consider that your and samuele'S background is certainly more compiler-oriented than mine
[15:20] <arigo> not really
[15:21] <hpk> well, writing psyco and jython certainly tells _something_
[15:21] <hpk> you are a lot more used to thinking/coding at compiler-level
[15:21] <hpk> there really is no point in disputing that :-)
[15:22] <arigo> ok :-)
[15:22] <hpk> but back on topic: where is the damn SSI link :-)
[15:23] <pedronis> www.cl.cam.ac.uk/~jds31
[15:23] <hpk> i am thinking of joining a bit of Carl's LLVM efforts, btw
[15:23] <hpk> if you don't think that's the wrong direction :-)
[15:24] <arigo> no, that's fine,
[15:24] <arigo> especially given that the next LLVM efforts have a lot in common with the next C efforts
[15:24] <pedronis> a survey on repr forms as register renaming is: http://www.cl.cam.ac.uk/~jds31/research/renaming.pdf
[15:25] <hpk> pedronis: did you see my earlier suggestion of recording intesting links, btw?
[15:28] <hpk> arigo: i read somewhere starting wikipedia, i think,
[15:29] <hpk> about a graph-transformation that gets rid of exception blocks by letting
[15:29] <hpk> each operation return a tuple
[15:29] <hpk> a "throw" operation than simply returns null, exc
[15:30] <arigo> yes, that's an "exception monad" in Haskell terms :-)
[15:30] <arigo> it depends what kind of code we want to generate
[15:30] <hpk> yes
[15:31] <arigo> we can generate very CPython-ish code with "if (something_when_wrong) goto cleanup;"
[15:31] <hpk> basically if we have some reusable exception mechanism on the target
[15:31] <hpk> but considering that we want to go dynamic at some point anyway
[15:31] <hpk> we can as well work on the assumption that the target usually has no exc-mechanism
[15:31] <hpk> ... i am guessing
[15:32] <arigo> well, it's the other way around, I am guessing
[15:32] <arigo> to generate portable C code we have difficulties with exceptions
[15:32] <arigo> but dynamic compilation is much more non-portable and we control more precisely the code that we generate
[15:33] <hpk> makes sense i am guessing
[15:33] <hpk> OTOH, it looks to me that writing a backend for a "flattended low-level CFG" is a lot easier
[15:33] <hpk> than having to deal with implementing an exception mechanism for each backend
[15:34] <arigo> yes, sure
[15:34] <hpk> add "non-polymorphic" to that
[15:34] <hpk> :-)
[15:34] <arigo> note that even returning multiple values is messy in most languages :-/
[15:35] yuuh (~yuuhu@82.140.29.233) joined #pypy.
[15:35] <hpk> you don't have to map it directly like this, do you?
[15:35] <arigo> weeeell, but then the simplifying interest is lost
[15:36] <hpk> not neccesarily
[15:36] <hpk> you still gain that you have exact markers where exceptions can occur
[15:37] <arigo> for now we're assuming that every function can raise an exception
[15:37] <arigo> every user-defined one, I mean
[15:37] <arigo> if you want something more precise you need more work
[15:38] <hpk> i guess so
[15:38] <arigo> then the resulting work is useful independently on how you actually implement the exceptions in the back-end
[15:38] <hpk> but it seems feasible from my current perspective
[15:39] <arigo> yes, it's "just" a subtle extension to the annotator
[15:39] <hpk> yes, it's just that our CFGs appear nicely simple to me except fro exceptions
[15:39] <hpk> which introduce some implicitness or irregularily, at least it currently seems so to me
[15:39] <arigo> yes, but
[15:39] <arigo> I agree absolutely but
[15:40] <arigo> exceptions are a messy subject that need back-end support for a good implementation
[15:40] <arigo> not to mention that returning two values everywhere -- or simulating that somehow -- would make the graph extremely more cluttered
[15:41] <arigo> (but more regular, I agree)
[15:41] <hpk> not that much more cluttered, would it?
[15:41] <hpk> everytime you have "last_exception" somewhere
[15:41] <hpk> that would actually come from e.g.:
[15:41] <arigo> plus every simple_call()
[15:42] <hpk> you mean cluttered in the flowviewer represenation or internally?
[15:42] <arigo> well both
[15:42] <hpk> i am not seeing the flowviewer issue but can imagine an internal one
[15:42] <arigo> anyway my point here is that we really shouldn't do that *now*
[15:42] <arigo> because we don't need it now
[15:43] <hpk> again, i didn't suggest anything
[15:43] <arigo> we're desperately trying to generate code based on the current annotator's results (which Samuele fine-tuned for months)
[15:43] <hpk> such questions/answerings really just help me to understand
[15:44] <arigo> ok
[15:44] <hpk> calm down :-)
[15:46] <ericvrp> Hi all, glad you liked my small change in the wikipedia page. I would like to note that I am reading the pypy docs (again) and the llvm language reference. My current feeling is that I would like to work on the LLVM backend during the translation-sprint.
[15:47] <hpk> ericvrp: fine, me too :-)
[15:48] <hpk> ericvrp: mail me your account data some time
[15:50] <ericvrp> How hard would it be to create llvm output in the c-backend. I know we are then trying to force C upon the llvm paradigm, but maybe the llvm compiler can do a great job with the code. Or converting the C-code to llvm with the llvm c frontend. I do like the idea of using llvm instead of c to achive faster the C execution speed but the consensus seems to be that the C backend should be done first.
[15:50] <ericvrp> hpk: what do you mean with account data?
[15:52] <hpk> ericvrp: codespeak username + ssh key
[15:53] <hpk> ericvrp: so that you can commit yourself
[15:54] <ericvrp> username: ericvrp , with ssh key. Do you mean the public key generated by something like ssh-keygen -t rsa -P ""
[15:54] <hpk> yip
[16:01] <ericvrp> hpk: me stupid , eh. mailed to the issues database :(
[16:01] <ericvrp> hpk: will mail you another one
[16:02] <hpk> you can remove the message from the issue db
[16:05] <ericvrp> done
[16:05] <ericvrp> away noe
[16:05] <ericvrp> now
[16:06] <hpk> see you
[16:07] <arigo> bye
----- silence for 42 minutes ----- [16:49] Rhamphoryncus (~rhamph@rhamphoryncus.user) left irc: ""What do you mean, how many hit points do I have?" || Support ISO 8601! http://www.cl.cam.ac.uk/~mgk25/iso-time.html";
[16:52] Rhamphoryncus (~rhamph@rhamphoryncus.user) joined #pypy.
----- silence for 55 minutes ----- [17:47] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Read error: 60 (Operation timed out)
[18:01] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.68a [Firefox 1.0.2/20050317]"
----- silence for 2 hr and 14 minutes ----- [20:15] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[20:15] pedronis (~Samuele_P@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 41 minutes ----- [20:56] ericvrp (~chatzilla@ericvrp.demon.nl) left irc: "Chatzilla 0.9.68.3 [Firefox 1.0.4/20050511]"
[21:02] ericvrp (~chatzilla@ericvrp.demon.nl) joined #pypy.
----- silence for 41 minutes ----- [21:43] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.
----- silence for 1 hr and 35 minutes ----- [23:18] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "[x]chat"
----- silence for 22 minutes ----- [23:40] stakkars (itwukm@82.140.29.233) joined #pypy.
[00:00] --- Mon May 23 2005