| 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:07 |
| ion_ | XSLT? | 10:12 |
| Keybuk | probably just Python ;) | 10:12 |
| * ion_ once made an evil m4→xslt→{makefile,graphviz} converter thing. :-P | 10:14 | |
| Keybuk | heh | 10:15 |
| Keybuk | I never really understood xslt | 10:15 |
| 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 | 10:19 |
| === thom_ is now known as thom | ||
| 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:47 |
| ion_ | Ok | 13:48 |
| 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:53 |
| ion_ | Yeah | 13:54 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:06 |
| ion_ | Yep | 14:07 |
| ion_ | How about a hash table with key and value being the pointer? | 14:09 |
| ion_ | Or is that a stupid idea? :-) | 14:09 |
| ion_ | (Or a hash-like table with only keys – say, a Hashish table.) | 14:12 |
| 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 | 14:18 |
| 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:26 |
| Keybuk | IRC is Finnish | 16:28 |
| ion_ | Yes. | 16:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!