[10:07] <Keybuk> I think that the right way to approach this is autogenerated code
[10:07] <Keybuk> have something that turns an xml file into either proxy functions or marshal functions
[10:12] <ion_> XSLT?
[10:12] <Keybuk> probably just Python ;)
[10:14]  * ion_ once made an evil m4→xslt→{makefile,graphviz} converter thing. :-P
[10:15] <Keybuk> heh
[10:15] <Keybuk> I never really understood xslt
[10:19] <ion_> http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline.m4;hb=HEAD is converted to XML by http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline/to-xml.m4;hb=HEAD which is converted to a makefile by http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline/to-mk.xsl;hb=HEAD (and it also spouts this graph, http://heh.fi/heroes/heroes-scrape/pipeline.html). :-P
[13:47] <Keybuk> ion_: that's intense!
[13:47] <Keybuk> talking of which
[13:47] <Keybuk> I was thinking about nih_ref and nih_unref again last night
[13:47] <Keybuk> there's some thorny bits of code in Upstart that are basically compensating for the lack of it
[13:48] <ion_> Ok
[13:53] <Keybuk> so I was thinking
[13:53] <Keybuk> in general principle, nih_ref and nih_unref should just work
[13:53] <Keybuk> if you pass NULL as the context, the default 1 reference is yours
[13:53] <Keybuk> if you pass non-NULL, the reference is not yours
[13:54] <ion_> Yeah
[13:58] <Keybuk> the problem is that you have to remember you ref'd and unref in destroy()
[13:58] <Keybuk> so for the case I'm thinking
[13:58] <Keybuk> event_new "steals" the env array you pass it
[13:59] <Keybuk> with the ref/unref model, it would have to ref it, at which point it'd have to unref it again
[13:59] <Keybuk> losing the niceness of the hierarchical bit
[13:59] <Keybuk> so it'd certainly work
[13:59] <Keybuk> but I'm wondering if instead, we don't want each allocation to have multiple parent contexts?
[13:59] <Keybuk> you pass one when you create it
[13:59] <Keybuk> and any other parent can adopt it
[14:00] <Keybuk> when a parent is freed, it orphans its children
[14:00] <Keybuk> if they have other parents, then they're fine
[14:00] <Keybuk> if they are truly orphaned, then they're freed
[14:00] <ion_> Yeah, many-to-many relationships would be nice.
[14:01] <Keybuk> doing those O(1) might be hard though
[14:01] <ion_> Would we need anything else than a list of parents for each child and list of children for each parent?
[14:06] <Keybuk> no
[14:06] <Keybuk> but for each parent/child relationship, we'd need n pointers
[14:06] <Keybuk> so the context would grow for each relationship you add
[14:07] <ion_> Yep
[14:09] <ion_> How about a hash table with key and value being the pointer?
[14:09] <ion_> Or is that a stupid idea? :-)
[14:12] <ion_> (Or a hash-like table with only keys – say, a Hashish table.)
[14:18] <Keybuk> I was thinking something like that
[14:18] <Keybuk> instead of putting the context at the beginning of the block, just have a lookup table
[14:18] <Keybuk> that'd mean nih_alloc could adopt blocks allocated elsewhere
[16:26] <ion_> A Finnish ISP defines IRC as “Inter Relay Chat – Internet’s dating service”. http://sanasto.elisa.fi/showWord.cfm?id=1079&languageId=1
[16:28] <Keybuk> IRC is Finnish
[16:29] <ion_> Yes.