[02:13] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Remote closed the connection
----- silence for 22 minutes ----- [02:35] yuuh (kxronqxe@dsl-62-220-8-154.berlikomm.net) left irc: "utz utz utz"
----- silence for 5 hr and 40 minutes ----- [08:15] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 1 hr and 16 minutes ----- [09:31] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) joined #pypy.
----- silence for 1 hr and 18 minutes ----- [10:49] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[10:56] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[10:57] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 18 minutes ----- [11:15] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[11:15] <cfbolz> hi!
[11:18] <arigo> hi!
[11:18] <cfbolz> I just read your ideas about improving genc
[11:19] <cfbolz> I think it's an excellent idea to be able to write all the low level stuff in Python too
[11:20] <cfbolz> In fact, I tried something similar but didn't get very far.
[11:23] <arigo> I see
[11:23] <arigo> this was indeed motivated by both your and my attempts at something like C template code
[11:23] <arigo> negatively motivated :-)
[11:24] <cfbolz> yes
[11:25] <cfbolz> in my case the string manipulations in make_runtime slowly get larger than the code itself :-)
[11:26] <cfbolz> my problem when I tried this was that I couldn't manipulate the annotator to help me
[11:27] <arigo> I see
[11:27] <arigo> you know a bit more about the annotator now, right?
[11:27] <cfbolz> a bit, yes
[11:28] <arigo> implementing the low-level types in the annotator and elsewhere and gluing it all together will probably be more code than just hacking them in GenC or GenLLVM
[11:28] <arigo> but so much more fun :-)
[11:29] <arigo> and really more flexible too.
[11:29] <cfbolz> yes
[11:30] <cfbolz> And testable without crashes
[11:30] <cfbolz> I think that's the coolest thing about it.
[11:31] <cfbolz> I think a problem could be subtle differences between the target languages
[11:31] <arigo> testing and avoiding strange segfaults is definitely nice
[11:32] <arigo> subtle differences: yes, we kept Java at the back of our head as such an example
[11:32] <arigo> we'll probably need configurable behaviors here and there
[11:32] <arigo> depending on the target language
[11:32] <arigo> and also on the GC we use in the target language, etc.
[11:33] <cfbolz> yes, that's probably a problem
[11:35] <cfbolz> did you read christian's mail?
[11:37] <arigo> Re: Just so you know? or Magic problems?
[11:37] <cfbolz> first one
[11:38] <cfbolz> I'm not interested in Magic :-)
[11:38] <arigo> :-)
[11:39] <cfbolz> I think it's a big plus of genllvm that the target language supports flow graphs directly
[11:39] <arigo> yes, indeed
[11:40] <arigo> I'm a bit surprized that the MS compiler doesn't fully optimize the overhead away,
[11:40] <cfbolz> yes, me too
[11:40] <cfbolz> on the other I hand, it's not clear that the internal flow graph of the compiler matches our own afterwards
[11:40] <arigo> but it's possible that it gets confused by whole-function local variables that are constantly copied around, when there are not enough registers free
[11:41] <cfbolz> that's another thing LLVM copes with nicely
[11:41] <cfbolz> copying around never happens, there are just a lot of phi nodes that are ignored
[11:41] <arigo> Christian's approach makes a lot of sense anyway as a compiler-like optimization,
[11:42] <arigo> but yes, it would be interesting to compare LLVM and C performance at some point :-)
[11:42] <cfbolz> I'm getting there
[11:42] <arigo> :-)
[11:42] <cfbolz> Don't have that much time at the moment, Analysis exam in two weeks
[11:42] <cfbolz> I guess the next big step would be dicts
[11:43] <cfbolz> but I'll wait for your and Samuele's ideas to converge to something useful :-)
[11:47] <arigo> :-)
----- silence for 1 hr and 12 minutes ----- [12:59] yuuh (lowhssg@dsl-62-220-8-154.berlikomm.net) joined #pypy.
----- silence for 20 minutes ----- [13:19] yuuh (lowhssg@dsl-62-220-8-154.berlikomm.net) left irc: Read error: 145 (Connection timed out)
[13:30] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
----- silence for 45 minutes ----- [14:15] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[14:15] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[14:17] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 39 minutes ----- [14:56] ludal (~ludal@lab75-1-81-57-254-81.fbx.proxad.net) joined #pypy.
[14:59] <pedronis> arigo: should we move ll under pypy? maybe we need to create a rpython dir and move rarithmetic there too
[15:00] <arigo> ok
[15:00] <arigo> for later, maybe hide pypy/annotation/ under rpython too?
[15:00] <arigo> s/hide/regroup :-)
[15:11] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[15:11] yuuh (bxpcgykx@dsl-62-220-9-38.berlikomm.net) joined #pypy.
[15:24] <cfbolz> I'm going home. See you.
[15:24] <arigo> see you
[15:25] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[15:37] <pedronis> arigo: I'm commiting ll.py as rpython/lltypes.py
[15:37] <arigo> ok
[15:37] <arigo> svn cp instead of commit?
[15:37] <pedronis> mmh, yes
[15:37] <pedronis> well I did a svn cp
[15:38] <arigo> ok.
[15:38] <pedronis> but to the local wc
[15:38] <arigo> np, I forgot that svn cp needed an svn commit afterwards in this case.
[15:43] <ludal> hi, is there conventions or guidelines on how to add a new option / configuration parameter ?
[15:45] <ludal> we'd like to make the replacement compiler optional (at least from an ENV var)
[15:45] <arigo> pypy/tool/option.py has a get_standard_options()
[15:45] <ludal> yes I've seen that
[15:46] <ludal> trouble is it goes and do stuff in various bits and places
[15:46] <arigo> yes, it's a bit hackish. try to follow what is done for --oldstyle, that's what I did to add --file.
[15:46] <pedronis> arigo: done, I have moved the tests to their own file
[15:47] <arigo> pedronis: good
[15:48] <ludal> how about using pypy.tool.Options as a global place to look for optional parameters ?
[15:48] <arigo> ludal: actually, see the --file option: it's very self-contained
[15:48] <arigo> it's defined and used only in option.py
[15:49] <arigo> I don't know exactly the design decisions behind the two Options classes (py.py vs option.py)
[15:49] <ludal> here I need : point ExecutionContext.__init__ to the Compiler class to use
[15:49] <arigo> right
[15:49] <ludal> plus eventually activate recparser as builtin module
[15:50] <ludal> I'd rather like to see compiler.py select the right class based on global parameters than having options.py actively modify stuff
[15:50] <ludal> see my point?
[15:50] <arigo> yes, something cleaner than patching space.getexecutioncontext().compiler from pypy.tool.option.objspace()
[15:50] <arigo> but global options also have drawbacks
[15:51] <ludal> sure that's mostly why I asked for guidelines; both approaches have drawbacks
[15:52] <arigo> ok. so no, I don't think we have guidelines for that
[15:52] <ludal> from my point of view having an "Options" object that every pieces of code references to get there options has the advantage to be easily grepable
[15:53] <ludal> on the other hand the options' sideeffect don't show up quite easily as if they are initiated from options.py
[15:58] <arigo> I tend to avoid code that depends on global state in general, and would much rather stick the options into a relevant object (like 'space') from option.py
[15:59] <ludal> don't you mean 'Options
[15:59] <ludal> '?
[16:00] <arigo> no, I really mean some object which is not a global in a module, but which is tied to the current context; in PyPy, the space plays pretty much that role
[16:01] <arigo> so that you could instantiate several spaces with different options without collisions
[16:02] <ludal> ok, but there's no options stored in space as of now right ?
[16:03] <arigo> right.
[16:03] <arigo> the current situation is more accidental than designed.
[16:05] <ludal> how about starting by passing an options object to the space constructor with apropriate default ?
[16:06] <ludal> derived classes can pick their own options and you can drop stuff like if name=='std' ...
[16:08] <arigo> yes, though it would be nice if somehow the derived classes could also declare which options they accept, in a way that can be used in the option parser
[16:08] <arigo> that's rather difficult with optik, as I understand it, because which class is selected depends on an -o option itself
[16:09] <ludal> right, but there's a loop here, since without parsing the options you don't know which class you'll instanciate
[16:09] <arigo> that's the problem. in theory you can say that -o <class> can be followed by class-specific options; but optik isn't happy with that idea.
[16:11] <arigo> although I didn't work on option.py I can guess that it's the kind of background motivation that led to the current solution, a quick hack that works for now and that should be redesigned more thoroughly...
[16:11] <ludal> you can always have the kind of kludge gcc uses to pass options to the linker --spaceopts=a,b=1,c
[16:12] <arigo> yes, but that's not really nice, is it? :-)
[16:12] <arigo> I'm sure that Holger has other ideas in mind -- he experimented quite a bit with option parsing in py.test.
[16:14] <mwh> arigo: i don't think you can accuse pypy's option handling of being designed
[16:14] <ludal> not really, but since at the time the options are parsed the objspace isn't even imported
[16:15] <ludal> only divination would help here
[16:15] <arigo> mwh: I don't accuse anything, indeed :-)
[16:15] <arigo> ludal: well you could import the correct object space class when you see the -o option.
[16:19] <ludal> sure,
[16:21] <ludal> and more easily you can just name objspace options meaningly like --std-oldstyle and leave it as that for now
[16:21] <ludal> especially since this is the only namespace specific options I can see now
[16:22] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc:
[16:22] <ludal> totally orthogonal question is how you pass these options (once parsed) to the objspace
[16:23] <arigo> well, I can see solutions that aren't that much orthogonal to the option specifications
[16:23] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[16:23] <ludal> ok not orthogonal, only slanted then ;)
[16:23] <arigo> :-)
[16:25] <ludal> btw, I see Options.spaces as a list and objspace() instanciating Options.spaces[-1]
[16:25] <ludal> are you planning to have several objspaces instantiated?/
[16:26] <arigo> not really
[16:26] <arigo> I don't know why it's done this way
[16:27] <pedronis> to define a chain of wrapping? possibly?
[16:28] <arigo> maaaaybe
[16:32] <pedronis> arigo: I added some tests and fixed some stuff
[16:34] adim (adim@logilab.net2.nerim.net) left #pypy.
[16:36] <arigo> pedronis: oups, a bug of mine.
[16:37] <pedronis> well, if both forgot about checking parents of parents too
[16:37] <pedronis> s/if/we
[16:37] <arigo> indeed
[16:38] <pedronis> we should probably move to annotation etc now
[16:38] <pedronis> the concrete model seems good enougn as starting point
[16:38] <mwh> Options.spaces is a list because at one point
[16:38] <mwh> python test_all.py -ST
[16:38] <mwh> would run all tests in the standard object space, then the trivial
[16:38] <mwh> outdated cruft, in other words
[16:39] <pedronis> I see
[16:53] <pedronis> arigo: I did not thought about this, but given our current rules it seems we need only SomePtr
[16:54] <pedronis> because you never really get directly to an Array or Struct
[16:57] <arigo> mmh, I see
[16:57] <arigo> not even SomeStructPtr and SomeArrayPtr?
[16:57] <pedronis> well, we can do that
[16:57] <arigo> ah no, I see, SomePtr with a TYPE is probably enough (as is class _ptr)
[16:57] <pedronis> may point was more that we don't need SomeStruct and SomeArray
[16:58] <arigo> yes.
[16:58] <arigo> cool
[16:59] <lac> anybody got some time to help me with a not-pypy problem?
[16:59] <lac> it requires running around, not thinking. :_(
[17:00] <lac> and a spare console which i do not have.
----- silence for 23 minutes ----- [17:23] <arigo> lac: finished my piece of hacking, I can help you now if you still need it
----- silence for 23 minutes ----- [17:46] <lac> yes
[17:46] <lac> thanks armin
----- silence for 33 minutes ----- [18:19] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "[x]chat"
[18:20] arigo (~arigo@c-3a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 24 minutes ----- [18:44] yuuh (bxpcgykx@dsl-62-220-9-38.berlikomm.net) left irc: "utz utz utz"
----- silence for 16 minutes ----- [19:00] <lac> i need to loging
[19:00] <mwh> ECANTPARSE
----- silence for 19 minutes ----- [19:19] arre (ac@ratthing-b3fa.strakt.com) left irc: Remote closed the connection
[19:33] Action: pedronis about to leave the office
[19:35] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
----- silence for 1 hr and 16 minutes ----- [20:51] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) joined #pypy.
----- silence for 3 hr and 2 minutes ----- [23:53] aleale (~redorlik@cpe.atm0-0-0-129140.0x3ef2fa3a.bynxx3.customer.tele.dk) left irc: "Real IRC clients know "to" is a preposition, not an adverb"
[00:00] --- Wed May 11 2005