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