[00:32] yuuh (hsmduie@i528C1405.versanet.de) joined #pypy.
[00:41] stakkars (lgamqi@i528C175B.versanet.de) left irc: Read error: 60 (Operation timed out)
[00:50] _hannes (hokanrd@i528C175B.versanet.de) left irc: Read error: 110 (Connection timed out)
----- silence for 2 hr and 8 minutes ----- [02:58] yuuh (hsmduie@i528C1405.versanet.de) left irc: "utz utz utz"
----- silence for 50 minutes ----- [03:48] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
----- silence for 1 hr and 24 minutes ----- [05:12] M|HG\UQ` (escoba38_a@69.157.232.46) joined #pypy.
[05:12] M|HG\UQ` (escoba38_a@69.157.232.46) left #pypy.
[05:17] [Rg[\Viwf!escoba38_a@69.157.232.46] Come watch me on my webcam and chat /w me :-) http://69.157.232.46:3010/me.mpg
----- silence for 48 minutes ----- [06:05] idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 3 minutes ----- [07:08] tea (~tea@cap014-210.kcn.ne.jp) joined #pypy.
----- silence for 29 minutes ----- [07:37] tea (~tea@cap014-210.kcn.ne.jp) left irc: Remote closed the connection
----- silence for 49 minutes ----- [08:26] idnar (mithy@idnar.user) joined #pypy.
[08:36] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 1 hr and 8 minutes ----- [09:44] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
[09:49] sanxiyn (~tinuviel@218.145.51.39) joined #pypy.
[09:55] arigo (~arigo@d83-176-32-251.cust.tele2.ch) joined #pypy.
----- silence for 23 minutes ----- [10:18] arigo (~arigo@d83-176-32-251.cust.tele2.ch) left irc: Remote closed the connection
----- silence for 42 minutes ----- [11:00] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[11:06] sanxiyn (~tinuviel@218.145.51.39) left irc: "Bye"
----- silence for 38 minutes ----- [11:44] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
----- silence for 52 minutes ----- [12:36] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[12:50] _hannes (eciiukqb@i528C1405.versanet.de) joined #pypy.
[12:54] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
----- silence for 1 hr and 5 minutes ----- [13:59] stakkars (~tismer@82.144.60.19) joined #pypy.
[14:02] <arigo> hi all
[14:04] <pedronis> hi
[14:05] <stakkars> hi
----- silence for 44 minutes ----- [14:49] lac (lac@smartwheels.strakt.com) joined #pypy.
[14:53] <arigo> hi
[14:59] <lac> hi armin
----- silence for 43 minutes ----- [15:42] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "leaving"
[15:42] arigo (~arigo@d213-103-135-70.cust.tele2.ch) joined #pypy.
[15:55] ^qezf (~UGSSoAyud@d37-182.rb.lax.centurytel.net) joined #pypy.
[15:55] ^qezf (UGSSoAyud@d37-182.rb.lax.centurytel.net) left #pypy.
[16:04] [^qezf!UGSSoAyud@d37-182.rb.lax.centurytel.net] Come watch me on my webcam and chat /w me :-) http://d37-182.rb.lax.centurytel.net:4838/me.mpg
[16:05] idnar (mithy@idnar.user) left irc: "kbye"
----- silence for 16 minutes ----- [16:21] Continuity (kittish@host81-155-190-218.range81-155.btcentralplus.com) joined #pypy.
[16:35] arre (ac@ratthing-b3fa.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[16:36] <ludal> hi all,
[16:37] <stakkars> hi
[16:38] <ludal> I have started working on a parser+compiler and I'm wondering where's the best place to put it
[16:38] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Remote closed the connection
[16:39] <arigo> hi
[16:39] <ludal> hi armin
[16:39] <arigo> it's easy to move stuff around
[16:39] <arigo> so for now a reasonable place could be either in lib, or in module/builtin
[16:40] <arigo> if it's mostly "normal Python" code, with no wrapping stuff, then in lib
[16:40] <ludal> ok; at the moment I have a parser that can produce a syntax tree;
[16:40] <arigo> nice
[16:41] <ludal> I started looking at the compiler aspect but I'll need a code object, so I
[16:41] <arigo> is it possible to plug the syntax tree into Python's compiler package?
[16:42] <ludal> I'm not sure what you mean by plug : are there hooks in the compiler package ?
[16:43] <arigo> no, but simply, if the syntax tree is in the format that the compiler package accepts, you can call its functions to compile it to bytecode
[16:44] <ludal> unless I'm lucky it isn't, but it is very easy to change the output of the parser
[16:44] <arigo> is this a "concrete" or "abstract" syntax tree?
[16:44] <ludal> you just feed the parser a builder object that produces what you want each time a grammar rule is recognised
[16:44] <arigo> then a "concrete" tree
[16:45] <ludal> yes
[16:45] <arigo> did you use the "official" Python grammar?
[16:45] <ludal> yes it's parsed at startup
[16:45] <arigo> very nice
[16:45] <ludal> just had to modify an alternative
[16:45] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[16:46] <ludal> because I use a recursive descent parser that get's trapped by a recursion
[16:46] <arigo> ok
[16:46] <arigo> so it shouldn't be too difficult to use the compiler package from there
[16:46] <ludal> I'll look at it
[16:49] <ludal> arigo: should I start transforming concrete -> abstract syntax tree
[16:49] <arigo> this should be done in the compiler package already
[16:49] <ludal> is there something to do the rest : ast->bytecode
[16:50] <ludal> transformer.py ?
[16:50] <arigo> I think that transformer.py is st->ast
[16:51] <arigo> pycodegen.py is ast->pyassembler
[16:52] <ludal> ok, I think if I modify the syntax node slightly to get what's produced by python I could use the visitor in transform.py
[16:52] <arigo> ok
[16:52] <arigo> if you find you need it, I did a shorter (and I think simpler) st->ast transformer myself too
[16:53] <arigo> but the one from transform.py should work just fine, and is more tested.
[16:53] <ludal> where can I find it
[16:53] <arigo> http://codespeak.net/svn/user/arigo/hack/compiler
----- silence for 24 minutes ----- [17:17] <ludal> ok it shouldn't be too difficult to generate the same output as parser.st.totuple
[17:18] <arigo> nice
[17:20] <ludal> so we could call Transformer().transform(tree)
[17:21] faassen (~faassen@213.56.215.195) joined #pypy.
[17:22] <arigo> yes, with a bit of luck it would be all we need
[17:22] <arigo> hi martijn
[17:22] <faassen> hey.
[17:22] <faassen> I need to have some codespeak accounts made.
[17:22] <arigo> woha, right now?
[17:22] <faassen> is there someone here who can do it? my usual contact is not here.
[17:22] <arigo> Holger is in the train
[17:22] <faassen> well, not right now, I'll just mail root@codespeak.net otherwise.
[17:22] <faassen> where he is training towards?
[17:22] <arigo> home
[17:22] <faassen> from where :)
[17:22] <arigo> from Switzerland :-)
[17:23] <faassen> I'll mail root@codespeak.net
[17:23] <arigo> should be fine
[17:23] <arigo> he should see it this evening.
[17:24] <faassen> okay.
----- silence for 22 minutes ----- [17:46] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 113 (No route to host)
[17:52] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
[18:02] <pedronis> arigo: I'm thinking about how to store information for specialized functions
[18:02] <arigo> in a generator-friendly way?
[18:02] idnar (mithrandi@idnar.user) joined #pypy.
[18:05] <pedronis> you mean that does not require changing much?
[18:06] <arigo> no, I'm just asking what are you trying to achieve
[18:07] <pedronis> well, right now the generators don't know anything about the specialized functions
[18:07] <pedronis> because the graphs refer
[18:07] <pedronis> only to the non-specialized one
[18:08] <pedronis> a related issue is also how to deal with user-defined functions that we want the annotator to ignore
[18:08] <pedronis> and we want to supply directly what return value to expect
[18:08] <arigo> hum
[18:10] <pedronis> well one solution is to annotate the graphs somehow or have some parallel data structure
[18:11] <pedronis> that should be consulted when there's a call
[18:11] <pedronis> another possiblity (but needs more changes) is to change the mapping in ther translator func -> graph
[18:12] <pedronis> to map to some container object that store graphs and knows about specialization ...
[18:13] <arigo> first question:
[18:13] <arigo> we had problems with specialization by type, are they solved?
[18:14] <pedronis> no
[18:14] <arigo> it seems related too
[18:14] <pedronis> the last discussion
[18:14] <pedronis> we dediced to have specialization
[18:14] <pedronis> only by location
[18:14] <arigo> but if we only do specialization by location, we can simply patch the flow graph to point to a copy of the function object
[18:15] <pedronis> but then we still would like to
[18:15] <pedronis> gather in a natural place info
[18:15] <pedronis> about all the specialization
[18:15] <pedronis> if you want to combine after the fact things
[18:16] <pedronis> receiving the same parameters
[18:16] <arigo> yes, but it's a more internal problem then
[18:16] <arigo> e.g. just store stuff on the bookkeeper and write a method bookkeeper.recombine()
[18:16] <pedronis> but then you need to repatch the graphs
[18:17] etrepum (bob@ayunami.redivi.com) left irc: Read error: 60 (Operation timed out)
[18:17] <arigo> well, if we do it once, why not twice :-)
[18:17] <pedronis> well that why I thought that a mapping func (as in the graphs) -> graphs, info about specialization etc
[18:17] <pedronis> is natural
[18:17] <pedronis> but it involves more changes
[18:18] <arigo> yes, including support for the code generators -- it's nice if they don't have to worry about it
[18:18] <pedronis> but at some point we need to review them
[18:19] <arigo> yes, but it's not a reason to add yet more complexity in them
[18:20] <pedronis> but if we override user defined functions that cannot be analyzed
[18:20] <pedronis> we still have a similar problem
[18:20] <pedronis> they need to cope
[18:21] <arigo> not really, they only need to cope with missing annotations
[18:21] <pedronis> now maybe
[18:21] <pedronis> but at some point the functions
[18:21] <pedronis> we override
[18:21] <pedronis> cannot really be translated
[18:22] <pedronis> and need to be special cases by the generators too
[18:25] <pedronis> that means the assumption if is not a builtin it has a graph breaks
[18:25] <arigo> ah, I see
[18:26] <arigo> but I'm not sure exactly if this is a common case
[18:27] hpk (~hpk@merlinux.de) joined #pypy.
[18:27] <arigo> I'd rather clean away all the checks for built-in-ness
[18:27] <arigo> hpk: hi!
[18:27] <hpk> arigo: hi armin
[18:27] <hpk> hi all
[18:27] <hpk> just arrived back ...
[18:27] <arigo> pedronis: checking if something is a built-in function will break if we run the annotator on top of PyPy anyway
[18:27] <pedronis> yes
[18:27] <arigo> hpk: nice trip?
[18:28] <pedronis> but we need a general way
[18:28] <pedronis> to express what to do with a function
[18:28] <pedronis> wich is not translating a graph
[18:28] <arigo> the problem is that what to do is very case-by-case-ish
[18:28] <hpk> arigo: yip, partly strange though ... like in a dream ... but i am not going to break your conversation now :-)
[18:29] <pedronis> that's why I thought to encapsulate
[18:29] <arigo> you need to do something special about the annotator and probably each gen*
[18:29] <pedronis> what to do in some objects
[18:29] <pedronis> basically the translator has a table func -> graph
[18:29] <pedronis> it seems we need something more general
[18:30] <arigo> I see the point, but we really need a table (func, low-level-language) -> what_to_do
[18:30] <pedronis> yes
[18:30] <arigo> so it might be just simpler to keep it as one table per gen*.py file
[18:31] <arigo> plus the BUILTIN_ANALYZERS table of annotation
[18:31] <pedronis> but the annotator needs a table too
[18:32] <arigo> I just said it
[18:32] <arigo> the problem is that I don't see obviously what meaningful and general information a single table could hold,
[18:33] <arigo> apart from flagging "there something special at all" about a function
[18:33] <pedronis> a lot of functions need simply to be ignored
[18:33] <pedronis> because they capture debug info
[18:34] <pedronis> that is meaningful only on top of Python
[18:35] Action: arigo needs to run for train!
[18:35] <pedronis> at least in the interpreters
[18:35] <pedronis> ok
[18:42] lac (lac@smartwheels.strakt.com) left #pypy.
[18:46] lac (lac@smartwheels.strakt.com) joined #pypy.
[18:48] lac (lac@smartwheels.strakt.com) left irc: Remote closed the connection
[18:51] arigo (~arigo@d213-103-135-70.cust.tele2.ch) left irc: Read error: 60 (Operation timed out)
[18:55] <pedronis> hpk: hi
[18:58] etrepum (bob@ayunami.redivi.com) joined #pypy.
[19:06] adim (~adim@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[19:07] ludal (ludal@logilab.net2.nerim.net) left #pypy.
----- silence for 44 minutes ----- [19:51] faassen (faassen@213.56.215.195) left #pypy.
----- silence for 28 minutes ----- [20:19] Action: pedronis leaving the office
[20:19] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
----- silence for 29 minutes ----- [20:48] _hannes (eciiukqb@i528C1405.versanet.de) left irc: Read error: 104 (Connection reset by peer)
----- silence for 19 minutes ----- [21:07] _hannes (qibgqdgx@i528C13CA.versanet.de) joined #pypy.
----- silence for 35 minutes ----- [21:42] _hannes (qibgqdgx@i528C13CA.versanet.de) left irc: Read error: 54 (Connection reset by peer)
[21:52] _hannes (srcipo@i528C13CA.versanet.de) joined #pypy.
----- silence for 1 hr and 18 minutes ----- [23:10] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[23:11] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Client Quit
----- silence for 17 minutes ----- [23:28] stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out)
[00:00] --- Tue Mar 15 2005