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

[00:06] esteban (esteban@DWM-12-229.go.retevision.es) left #pypy.

----- silence for 1 hr and 34 minutes -----

[01:40] jamwt (jamwt@count.jamwt.com) joined #pypy.

----- silence for 1 hr and 1 minute -----

[02:41] pedronis (~Samuele_P@c-1a8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0/20041107]"

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

[03:56] _hannes (lrsylbu@i528C1451.versanet.de) left irc: Read error: 104 (Connection reset by peer)

[03:56] thingie24 (~rmt38@valhalla.ccp.cc) joined #pypy.

[03:59] _hannes (ivghtxp@i528C187A.versanet.de) joined #pypy.

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

[04:03] thingie25 (~rmt38@valhalla.ccp.cc) left irc: Read error: 60 (Operation timed out)

[04:04] nas (~nas@S0106000625c557dc.cg.shawcable.net) joined #pypy.

----- silence for 19 minutes -----

[04:23] nas (~nas@S0106000625c557dc.cg.shawcable.net) left irc: "Client exiting"

----- silence for 1 hr and 13 minutes -----

[05:36] _hannes (ivghtxp@i528C187A.versanet.de) left irc: "utz utz utz"

----- silence for 4 hr and 55 minutes -----

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

----- silence for 49 minutes -----

[11:20] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)

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

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

[12:05] thingie25 (~rmt38@213.167.138.65) joined #pypy.

[12:11] thingie24 (~rmt38@valhalla.ccp.cc) left irc: Read error: 145 (Connection timed out)

----- silence for 51 minutes -----

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

[13:15] <hpk> arigo: morning

[13:18] <arigo> hi

[13:21] <hpk> do you already have an office at HHU?

[13:21] <arigo> yes

[13:21] <arigo> I'm there now

[13:23] <hpk> i wonder who used cmdexec() instead of os.system() in the first place and why

[13:23] <arigo> I guess that's me

[13:23] <hpk> the main difference is that cmdexec() returns the output, maybe it should be renamed to py.process.getoutput()

[13:24] <hpk> or cmdoutput()

[13:25] <arigo> sorry, I've to reboot to get rid of a kernel module I can't unload any more (yes I'm hacking kernel modules this morning)...

[13:25] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: Remote closed the connection

[13:25] <hpk> have insmod fun

[13:28] arigo (~arigo@134.99.112.244) joined #pypy.

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

[13:46] cfbolz (~cfbolz@hdlb-d9b95c16.pool.mediaWays.net) joined #pypy.

[13:56] <cfbolz> hi!

[13:57] <cfbolz> I managed to write my flowgraph transformation but can't figure out where to put it.

[13:57] <hpk> hi

[13:58] <hpk> i would welcome it if backends would live in their own directories i guess

[13:58] <hpk> and common stuff in the translator base dir

[13:58] <cfbolz> Ok

[13:58] <hpk> arigo: is there a reason you didn't create a subdir for genc_*.py, btw?

[13:59] <arigo> hpk: no, it's just step-by-step additions that make it grow

[13:59] <cfbolz> I was talking not only about the physical position, though :-)

[14:00] <hpk> sure but that is easier to think about :-)

[14:00] <cfbolz> I don't know at what point in the annotation process:

[14:00] <cfbolz> If I do it before annotation it gets reversed since Annotators simplify removes empty block

[14:00] <cfbolz> If I do it after annotation the new variables are not annotated

[14:01] <hpk> this impülies more fine grained control about simplification steps IMO

[14:01] <cfbolz> hpk: a lot easier :-)

[14:01] <arigo> oups, right

[14:02] <cfbolz> remove_direct_loops has the same problem

[14:02] <arigo> genc_funcdef calls remove_direct_loops() quite late, I didn't realize it means the new vars wouldn't get typed

[14:02] <arigo> :-)

[14:02] <cfbolz> of course, since genc doesn't need the annotations

[14:03] <cfbolz> at the moment I just don't do annotator.simplify which breaks one of my tests where unneeded exceptions are not removed

[14:04] <cfbolz> but eventually this probably has to be done differently

[14:05] pedronis (~Samuele_P@c-398b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.

[14:06] <arigo> I don't see an obvious solution

[14:06] <hpk> i think backends need to call simplify with a list of explicit transformations

[14:06] Topic changed on #pypy by arigo!arigo@134.99.112.244: PyPy, Python in Python -- http://codespeak.net/pypy/ -- chanlog available via http://nimrod.terra-link.net/pypy/

[14:06] <cfbolz> some quick-an-easy solution would be a tag for the empty blocks that marks them as "don' remove"

[14:07] <cfbolz> But that's relatively ugly

[14:07] <arigo> cfbolz: but what in a.simplify() removes empty blocks?

[14:07] <arigo> that's done in t.simplify() only, as far as I see..?

[14:08] <hpk> simplify_graph()?

[14:08] <cfbolz> right

[14:08] <hpk> that's called from buildpyxmodule

[14:08] <arigo> uh??

[14:08] <arigo> cfbolz: forget it, def simplify() in RPythonAnnotator calls eliminate_empty_blocks() again

[14:08] <arigo> for some reason I can't figure out

[14:09] <cfbolz> that's what I meant

[14:09] <arigo> hpk: buildpyxmodule.build_cfunc() isn't used any more

[14:10] <cfbolz> I think in the end some more elaborate "simplification manager" has to be used

[14:10] <arigo> indeed

[14:10] <cfbolz> especially if there are more passes that optimize the graphs

[14:10] <pedronis> hi

[14:10] <arigo> hi

[14:10] <cfbolz> hi

[14:10] <hpk> hi

[14:11] <arigo> at least transformations that create new vars should be able to tell which other vars these ones are a "copy" of,

[14:11] <arigo> so that we can propagate annotations (and the typer's types)

[14:11] <pedronis> arigo: yes

[14:11] <arigo> looks fragile, but I can't think of something better

[14:11] <cfbolz> then we could do remove_direct_links after annotation

[14:11] <cfbolz> right?

[14:12] <pedronis> when I moved remove_direct_loops

[14:12] <pedronis> I thought that we would have that problem

[14:12] <cfbolz> oops, I meant remove_direct_loops of course :-)

[14:12] <pedronis> it was done even later

[14:13] <pedronis> so the variable it introduced were not declared

[14:13] <pedronis> which broke translate_pypy -no-a

[14:13] <arigo> argh

[14:15] <cfbolz> something else: How can i find the base class of a classic class?

[14:16] <arigo> Class.__bases__

[14:16] <arigo> ?

[14:17] <cfbolz> ouch.

[14:17] <cfbolz> That was easy :-)

[14:17] <arigo> hpk: sorry, I missed this check-in of yours during the Vilnius sprint that added eliminate_empty_blocks() at the end of RPythonAnnotator.simplify()

[14:18] <arigo> all these graph transformations are indeed a bit hackish, done here and there in some random order at some random places

[14:18] <hpk> indeed

[14:18] <cfbolz> yes, but the graph transformations are not really that complex right now

[14:19] <arigo> yes, but they are a lot of them already

[14:19] <hpk> i don't really see a big problem with managing a list of transformations

[14:20] <arigo> I'm not at all sure for example that you can't simplify more by calling simplify() twice

[14:20] <cfbolz> There are now some that reverse each other's actions

[14:20] <arigo> hpk: the messy part is for transformations that create new vars, how they should propatage annotations

[14:21] <arigo> hpk: given that they might also be called _without_ annotations

[14:21] <cfbolz> (side node: LLVM has really quite a bit of machinery to manage passes)

[14:21] <hpk> the brute force way would be to force re-simplification in that case

[14:21] <arigo> hpk: not to mention typer's new types, which are still stored differently

[14:22] <hpk> cfbolz: i can imagine

[14:22] <hpk> the use of transformers will only grow with PyPy, i am sure

[14:23] <cfbolz> I think so, too

[14:24] <cfbolz> Especially if they really do some sort of optimizations (and not only more or less obvious things)

[14:24] <hpk> yes, so what keeps us from adding a level of indirection for those transformations?

[14:25] <hpk> the create-new-vars issue is somewhat ortoghonal IMO

[14:28] <arigo> on the contrary, I think we need something that helps with the create-new-vars issue

[14:28] <cfbolz> Something is needed. This issue will grow worse with more backends that need different transformations

[14:28] <hpk> arigo: i am not saying that nothing is needed

[14:29] <pedronis> yes, we need a make a variable that can receive from this other one

[14:29] <hpk> arigo: i just don't see the deep connection to the "managing transformations makes sense" idea

[14:30] <hpk> especially if backends have different needs

[14:30] <pedronis> no, but having a clearer picture of what transformation are done before annotation, can be done after or depend on it

[14:31] <pedronis> can help

[14:31] <pedronis> in general we need to streamline when we call them

[14:31] <pedronis> tracking down the issue with remove_direct_loops called to late and so the undeclated vars was quite messy

[14:32] <arigo> hpk: the connection is that we can't just say "make a new Variable copying this Variable"

[14:32] <arigo> hpk: we have to provide the annotator object if available, and only if available

[14:32] <arigo> hpk: so it seems necessary to have some kind of transformation manager that knows if it currently has an annotator or not

[14:34] <pedronis> well Translator could have that role

[14:36] Action: hpk is currently playing with shpy + translator.view()s

[14:38] <cfbolz> I gotta go (I have only dialup at home and can't stay online all the time :-) ). Bye

[14:38] <hpk> see you

[14:38] <arigo> bye

[14:39] <arigo> pedronis: makes sense

[14:39] cfbolz (~cfbolz@hdlb-d9b95c16.pool.mediaWays.net) left irc: "Verlassend"

[14:39] <hpk> i guess so, too

[14:50] _hannes (hvvesxlp@i528C187A.versanet.de) joined #pypy.

[14:57] <arigo> ok ok

[14:57] <arigo> you are right, and a quick Translator-based hack to propagate Variable information is just what we need

[14:58] <arigo> ...now

[14:58] <arigo> because it's making half of the tests crash :-)

[15:12] Action: hpk mumbles something about piled hacks

[15:13] <pedronis> hpk: what I had in mind is that simplifications request should be routed through the translator and simplication should take a translator

[15:13] <pedronis> s/simplication/simplifications

[15:15] <hpk> so transformations would receive a (translator, graph) üpair always

[15:17] <pedronis> yes

[15:19] <arigo> i just tried that, but there is still something wrong in typer.py

[15:19] <arigo> conversion of variables across links is delicate, e.g. I forgot that link.args can contain the same Variable multiple times

[15:21] <arigo> (see e.g. the 1st block in the graph of snippet.nested_whiles)

----- silence for 29 minutes -----

[15:50] <pedronis> arigo: I don't understand from where the translator in copyvar is coming from

[15:51] <arigo> excellent point

[15:51] <arigo> none of the test_ctrans exercices that code then

[15:52] <pedronis> ah

[15:52] <pedronis> in fact of all translate_pypy -no-a

[15:52] <pedronis> only two functions were affected by the misplaced

[15:52] <pedronis> remove_direct_loops

[15:52] <arigo> which functions? (I'm looking for an example to add to the tests)

[15:53] <pedronis> one was listobject._roundupsize

[15:53] <arigo> I see

[15:54] <pedronis> yes, a test based on that would make sense

[15:58] <arigo> ok I've got a test that segfaults when remove_direct_loops is not applied

[16:02] _hannes (hvvesxlp@i528C187A.versanet.de) left irc: "utz utz utz"

[16:15] <arigo> guess it's time to move a few files in a new c/ subdirectory

[16:17] <arigo> or genc/

[16:30] <pedronis> yes

[16:32] <arigo> let's also split genc.h into reasonable pieces

[16:34] <pedronis> should also GenCSpecializer be moved out of typer?

[16:36] <arigo> yes, I'm putting it in genc/ctyper.py

[16:49] idnar (mithrandi@idnar.user) left irc: Nick collision from services.

[16:49] idnar_ (mithrandi@idnar.user) joined #pypy.

[16:49] <arigo> help! I can't figure out an import error

[16:53] <arigo> pdb-ing through import hooks... ah someone is hiding the real error, of course

----- silence for 28 minutes -----

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

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

[17:38] <cfbolz> arigo: could it be that the new remove_direct_loop breaks if there are Constants in link.args?

[17:38] <cfbolz> or does that never happen?

[17:52] <arigo> argh

[17:52] <arigo> you're right, of course

[17:54] <cfbolz> I noticed it while writing remove_double_links :-)

[17:54] <arigo> :-)

[17:54] <arigo> also, link.args can contain several times the same Variable

[17:55] <arigo> but I think that it doesn't break remove_direct_loops...

[17:55] <cfbolz> *Could* it break anything?

[17:56] <arigo> well, yes

[17:56] <arigo> in typer.py, the code that converted variables copied over links was broken in this way

[17:57] <cfbolz> ok

[17:59] <cfbolz> can you change copyvar (which should be called differently, then) to copy the annotation of Constants, too?

[17:59] <arigo> I guess so

[17:59] <arigo> but here, copyvar() should really return a var

[17:59] <arigo> for remove_direct_loops

[18:00] <arigo> for genc, it's ok to return a Variable which has the same 'type_cls' attribute as the Constant

[18:00] <cfbolz> of course. But it should have the annotation of the Constant.

[18:00] <arigo> right

[18:00] <arigo> we can copy the annotation too.

[18:01] <cfbolz> I don't know if we can: My knowledge of the annotators internals are still rather small :-)

[18:02] <arigo> yes, that's possible

[18:02] <arigo> but I'm thinking that the "correct" way to insert an empty block is slightly different

[18:02] <arigo> it probably doesn't matter here

[18:02] <arigo> but we could only copy the variables that appear in link.args into the new block,

[18:03] <arigo> and then reinsert the constants during the 2nd link

[18:03] <cfbolz> and remove them from the first

[18:03] <arigo> yes

[18:04] <arigo> and also only keep one copy of each variable in the 1st link, if there are several ones

[18:04] <arigo> this is what typer.py has to do for other reasons.

[18:05] <cfbolz> so copyvar doesn't have to be changed after all

[18:06] <cfbolz> maybe we should write a function that correctly inserts an empty block along a link

[18:06] <arigo> makes sense

[18:08] <cfbolz> do you want to do it or should I try?

[18:09] <arigo> I'm working on it,

[18:09] <arigo> I'm copying bits of typer.py and I'd like to see if it can use this new insert_empty_block() to become simpler

[18:10] <cfbolz> thanks

[18:19] <arigo> ok...

[18:19] <arigo> hopefully remove_direct_loops() will eventually be correct :-)

[18:24] <cfbolz> :-)

[18:29] <arigo> yes, typer.py gets a bit simpler

[18:29] <cfbolz> good. and remove_double_links is now very simple too

[18:29] <arigo> nice

[18:29] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.

[18:30] <arigo> so now if we want to insert operations like conversions along a link, we can just call insert_empty_block() and redo the conversion-inserting code in this new block instead.

[18:30] <arigo> hi lac!

[18:32] <cfbolz> arigo: That's good. It'll make genllvm simpler too, then.

[18:32] <arigo> argh

[18:33] <arigo> I'm trying this example function:

[18:33] <arigo> def fn(n):

[18:33] <arigo> while n > 0:

[18:33] <arigo> n = n-1

[18:33] <arigo> if n == 5:

[18:33] <arigo> n = 3.1416

[18:33] <arigo> return n

[18:33] <arigo> to see a int -> general object conversion

[18:33] <arigo> but all I get is

[18:33] <arigo> return -0.8584

[18:33] <arigo> in the "n==5" case

[18:33] <arigo> :-)

[18:34] <cfbolz> well...

[18:35] <cfbolz> That's a bit like the benchmarks that got optimized awy by the compilers :-)

[18:35] <arigo> yes :-)

[18:35] <arigo> with a "n += 3.1416" however the optimization disappears

[18:36] <arigo> and it seems to work

[18:36] <cfbolz> good

[18:36] <cfbolz> There is no SomeFloat, right?

[18:37] <arigo> no

[18:37] <cfbolz> because it's trivial to add or because nobody needs it?

[18:37] <arigo> ah, no I managed to get a segfault (always test test and test! :-)

[18:37] <arigo> cfbolz: a bit both, so far, but we'll need it eventually

[18:38] <cfbolz> who would have thought that someone likes segfaults?

[18:38] <cfbolz> :-)

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

[18:44] <cfbolz> I checked in remove_double_links. Hah, my first checkin not in the llvm dir :-)

[18:44] <arigo> :-)

[18:45] <arigo> ah, but what about the most general case:

[18:45] <arigo> several exits, but two of them to the same block?

[18:46] <arigo> :-)

[18:46] <cfbolz> ok, ok. When do those happen?

[18:46] <arigo> no idea

[18:46] <cfbolz> exceptions, maybe

[18:46] <arigo> yes, unless I'm mistaken you can have more than 2 exits

[18:47] <pedronis> yes, exceptions

[18:47] <cfbolz> I have not seem something like that

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

[18:48] <cfbolz> but I think some transformation removes this case

[18:48] <pedronis> it's implicit exceptions but most of them are removed

[18:49] <cfbolz> Do you have an easy example to test it?

[18:50] <arigo> def fn(lst, n):

[18:50] <arigo> try:

[18:50] <arigo> lst[n]

[18:50] <arigo> except IndexError:

[18:50] <arigo> return 2

[18:50] <arigo> except KeyError:

[18:50] <arigo> return 3

[18:50] <arigo> return 4

[18:51] <arigo> it's not really common code but well :-)

[18:51] <cfbolz> that doesn't count as an excuse for not fixing it :-)

[18:52] <arigo> if we replace lst[n] with a function call, the flow graph becomes more complicated, but we can imagine that it could some day be simplified to the same 3-exits graph

[18:56] <arigo> if we want to go further with typer.py,

[18:56] <arigo> we have to figure out what we want genc to generate

[18:56] <arigo> specially with respect to memory management

[18:57] <arigo> btw what does genllvm do so far?

[18:57] <cfbolz> what do you mean?

[18:58] <cfbolz> basically nothing is ever free'ed at the moment

[18:58] <arigo> ok

[18:58] <cfbolz> We really have to figure out, what sort of GC we want

[19:00] <cfbolz> I think we could do some really cool things, since our code generators can give the GC all the support it needs

[19:01] <arigo> yes

[19:03] <arigo> one thing to try is to generate the functions that walk the heap, one function per type

[19:04] <arigo> I've been told there is paper about it, reporting no great success

[19:04] <arigo> but we'll be able to really compare both approach on a larger scale

[19:04] <cfbolz> I don't get it. You walk the heap and what?

[19:05] <arigo> well, in a mark-and-sweep collector, you need to follow all pointers

[19:05] <cfbolz> right

[19:05] <arigo> there are basically 3 ways to do it

[19:05] <arigo> you have memory structures where each word is tagged (all integers are 31-bits only)

[19:06] <arigo> so that the gc knows which fields are pointers and which are not, just by the "tag" bit

[19:06] <arigo> alternatively, you give the gc description data that tells it where the pointer fields are, for each type of structure

[19:07] <arigo> or 3rd solution, there is one "mark" function per type, and calling this function will recursively call the mark function of all pointer fields of that type

[19:07] <cfbolz> ah

[19:07] <cfbolz> got it

[19:08] <arigo> in CPython, there is one mark function per built-in object type, hand-written

[19:08] <arigo> of course we could generate it instead; or generate the description data for the gc; or just try a tagging scheme.

[19:09] <arigo> or do all three and compare :-)

[19:09] <cfbolz> :-)

[19:09] <cfbolz> with tagging you can't allow an int to "overflow" so that the tag bit gets set, right?

[19:10] <arigo> yes

[19:10] <arigo> actually, for this reason the tab bit is usually the lower bit

[19:10] <arigo> so the value 'n' is stored as the machine word '2n+1' :-)

[19:11] <cfbolz> ok

[19:11] <arigo> it has a small overhead for the computations, though

[19:11] <cfbolz> but isn't as complicated to implement

[19:11] <arigo> e.g. to add two integers we have to add their machine words and then subtract 1

[19:11] <arigo> yes, it has various advantages

[19:12] <cfbolz> why isn't n stored as just 2n?

[19:12] <arigo> probably so that you can store pointers directly

[19:13] <pedronis> yes, without misalignment penalty

[19:13] <arigo> with the idea that pointers are always multiples of 4

[19:13] <cfbolz> ah

[19:13] <arigo> but I guess the details of what's faster depend on the machien

[19:14] <arigo> on 386 I doubt it makes any difference

[19:14] <cfbolz> don't ask me :-)

[19:14] <arigo> if all pointers 'p' are stored as 'p+1' you can always load the word at address 'p-1', 'p+3', 'p+7', etc

[19:14] <arigo> :-)

[19:15] <cfbolz> :-)

[19:15] <cfbolz> are we even sure we want mark-and-sweep?

[19:16] <arigo> no

[19:16] <arigo> there are just too many options :-)

[19:16] <arigo> but we should probably at some point implement CPython's strategy,

[19:17] <arigo> because it doesn't immediately look worse than the others

[19:17] <arigo> (whatever GC specialists think :-)

[19:17] <pedronis> the Jikes RVM comes with whole set of differents GC impls for example

[19:17] <cfbolz> more ChoicesOverflowError

[19:17] <arigo> :-)

[19:17] <arigo> pedronis: ah, oh

[19:17] <pedronis> written in java

[19:19] <pedronis> it's probably something worth to look at that at some point

[19:19] <pedronis> also in terms of what primitives they use to make things pluggable

[19:20] <arigo> makes sense

[19:20] <pedronis> for as plugging is easier

[19:20] <pedronis> s/as/us

[19:21] <pedronis> but still what kind of low-level functionality and how packaged

[19:21] <pedronis> is needed, is still a relevant issue for us too

[19:22] <cfbolz> The most immediate question is: Do we have to solve these issues now and how do we go on if we don't

[19:25] idnar_ (mithrandi@idnar.user) left irc: Connection timed out

[19:25] <arigo> we could ignore the issue now,

[19:25] <arigo> and present at the next conference a PyPy that doesn't run 4000 times slower but consumes 4000 times more memory :-)

[19:26] <arigo> or we could write or find a very basic GC, and use that

[19:26] <arigo> (now I think that it's not a problem to use a GC heap and CPython's refcounters in parallel)

[19:26] <cfbolz> :-)

[19:27] <cfbolz> No, it's probably not, as long as inc-/decrefs are inserted for SomeObjects

[19:27] <pedronis> yes

[19:27] <arigo> or else, we keep close to CPython and put all heap objects in PyObject structures with a refcounter, a (generated) CPython type, and tp_visit..?

[19:27] <arigo> or we do simple refcounting, and ignore cycles

[19:27] <pedronis> well, the real question is what kind of thread support we want

[19:27] <arigo> argh

[19:28] <pedronis> as long as we keep a GIL or ignore thread

[19:28] <pedronis> rolling a GC is not that hard

[19:28] <pedronis> I mean we want short term, and in august

[19:29] <arigo> it's probably safe to ignore threads (or use a GIL) for the short term

[19:30] <arigo> doesn't mean that we must go for the simple GC solution, but at least it's a possibility

[19:32] <cfbolz> we have to start somewhere

[19:32] <arigo> indeed

[19:32] <arigo> looks like another choice to post on pypy-dev

[19:33] <cfbolz> maybe we could use some kind of memory access hooks that can be adapted for different GCs?

[19:33] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)

[19:33] <arigo> yes, though designing hooks is not really important, as all code is generated anyway

[19:34] <cfbolz> yes, but then you have to track done all places in the generators

[19:34] <cfbolz> if you want to add GC later

[19:35] <arigo> maybe

[19:35] <arigo> what kind of GC hooks does LLVM have?

[19:36] <pedronis> they are documented

[19:36] <pedronis> let find the link

[19:37] <pedronis> http://llvm.cs.uiuc.edu/docs/GarbageCollection.html

[19:37] <cfbolz> http://llvm.cs.uiuc.edu/docs/LangRef.html#int_gc

[19:37] <cfbolz> pedronis: don't read that.

[19:37] <cfbolz> It's about things that are not yet implemented

[19:43] <hpk> still not uninteresting

[19:44] <cfbolz> If it only worked :-)

[19:47] <hpk> i often think that LLVM should be implemented in python rather than in C++

[19:47] <cfbolz> yes, I thought that, too.

[19:47] <cfbolz> :-)

[19:48] <pedronis> what exactly is implemented and not

[19:48] <pedronis> the second link refer to the first

[19:48] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) left irc: Read error: 110 (Connection timed out)

[19:49] <cfbolz> The actual collector is not implemented. There are some pieces but it is not finished.

[19:50] <cfbolz> I mean, the SemiSpace collector the page talks about.

[19:50] <arigo> so even the SemiSpace collector described at the end is not there

[19:50] <arigo> ok

[19:51] <cfbolz> you can look at what's there in http://illuvium.com/cgi-bin/cvsweb.cgi/llvm/runtime/GC/SemiSpace/semispace.c

[19:54] <pedronis> yes, I found that

[19:57] <cfbolz> someone tried to finish implement SemiSpace as a college project of some sort but they didn't post to LLVM-dev again.

[19:57] <cfbolz> Maybe I should asked them whether they got anything done

[20:00] <pedronis> I see, what is missing is code to update the pointers inside the objects

[20:02] <cfbolz> llvm_gc_collect() is basically empty

[20:10] <pedronis> well but given that the meta data is to supplied externally

[20:10] <pedronis> I don't see how it could be written

[20:11] <pedronis> unless they standardize what goes in meta

[20:11] <arigo> each gc has to decide what goes in the meta-data, no?

[20:12] <arigo> you can't even know the size of the objects you're moving around, otherwise, can you?

[20:13] <pedronis> that's a possibility but you may want to specialize things still

[20:13] <cfbolz> arigo: yes

[20:14] <cfbolz> and the meta data is supposed to be code generator dependent, too

[20:14] <arigo> apparently they think the gc should be very much code generator dependent, too

[20:15] <pedronis> that was my point: for a generic GC that GC and the code generator need to agree somehow

[20:15] <cfbolz> and since there doesn't exist a code generator for a GCed language there is no implementation of GC at all

[20:16] <cfbolz> (I don't know how far their Java front end is)

[20:17] <arigo> I see

[20:19] <pedronis> notice also that moving objects in memory is fairly language specifc

[20:19] <pedronis> for example you may need to that care of things related to hashing or identity

[20:20] <cfbolz> ouch. No id in RPython then :-)

[20:20] <pedronis> for example some java vm, use the adress for the hash and a flag

[20:20] <pedronis> when the object is moved a field is added to store the original hash

[20:21] <pedronis> if it was requested at least once from the program

[20:22] <arigo> I see

[20:22] <arigo> you can't safely do that for id(), though

[20:23] <pedronis> no, but they are hash is not guaranted to be unique

[20:23] <pedronis> s/they are/their

[20:23] <arigo> sure

[20:24] <pedronis> for id you need thread-safe table

[20:24] <pedronis> if you have a moving GC

[20:24] <arigo> cfbolz: remove_double_links():

[20:25] <pedronis> that's why Java and .NET (also for 64-bit reasons) abandoned the unique id idea

[20:25] <arigo> I'd swap "seen[link.target] = True" and "if link.target in seen" if I were you :-)

[20:25] <cfbolz> arigo: Ouch!!

[20:26] <cfbolz> I tested it only with functions that had double links.

[20:31] <cfbolz> It's still wrong. I really should test more before I check in :-(

[20:37] <cfbolz> Should be working now

[20:38] <arigo> looks ok :-)

[20:39] <cfbolz> Well, I thought that the other times, too :-)

[20:49] Action: arigo -> dinner, see you later

[20:49] arigo (~arigo@134.99.112.244) left irc: "[x]chat"

----- silence for 28 minutes -----

[21:17] <cfbolz> I'm going home, see you.

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

----- silence for 51 minutes -----

[22:09] esteban (~esteban@DWM-193-230.go.retevision.es) joined #pypy.

----- silence for 25 minutes -----

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

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

[23:14] esteban (~esteban@DWM-193-230.go.retevision.es) left irc:

[00:00] --- Sun Apr 3 2005