=== Keybuk_ is now known as Keybuk [15:34] Keybuk: have time to look at the state machine prototype today? [15:37] no, I haven't even got the url to it [15:37] did you mail it to upstart-devel? [15:39] Keybuk: I pinged it here. I'll mail it to devel if that's where you want it [15:42] sure [15:42] IRC is lossy ;) [15:45] Keybuk: just sent [15:46] thx [15:46] * Keybuk is still insanely busy [15:46] jaunty planning \o/ [15:46] so it's fun busy [15:47] This summer, Ubuntu gets Jaunty [15:47] What is it that's Jaunty? Jackalope? Jaguar? [15:53] hmm.. I have some post-lenny development plans I should write up and push to ubuntu devs too.. Shared workload and all :P [16:22] Jackalope [16:22] thought that was it [16:22] K is proving tricky on the acronym front ;) [16:22] I liked Kafkaesque :p [16:22] Kafkaesque Kangaroo [16:23] heh, Kafkaesque: our most depressing release yet! Fill your computer with existential horror today! [16:23] not having the name is actually annoying, because jaunty is a bug fix focus release, so we're targetting features to k already [16:24] Kettle-cooked [16:25] I like Kinky ;) [16:25] Kamikase Kangaroo! [18:08] Ubuntu 9.04: Kinky Keybuk? [18:09] * Keybuk gets the chains [18:11] It seems strange that I'm getting paid at a time like this [18:12] how so? [18:13] Hmm, I dunno [18:13] you mean while I'm not working on anything for you to package? [18:13] I mean while you're getting the chains [18:13] lol [18:13] it's 6pm here, I'm on my own time ;) [18:14] I have various infrastructure tasks to keep me busy whilst you're otherwise occupied [18:14] also note that right now, it's not clear how much work I'll be doing on Upstart for jaunty [18:14] we're planning over two releases [18:14] so you may end up waiting a whole year for a 1.0 [18:17] Oh I think its going to take a year, definitely [18:17] most of what I need from you is protocol and operating principle for the actual pid 1 service manager [18:18] after that I can do most of what I need here. [18:18] right, but I may not even *start* that for 6 months [18:18] that's my point [18:18] meh, all good [18:19] depends what ends up on the jaunty list [18:19] I actually might be moving positions soon [18:19] I know it's kinda a bitch for you guys, but you've done it to us *so* many times ;) [18:19] and at the end of the day, Ubuntu pay my salary not RH, so I do what they want :p [18:19] absolutely [18:20] I'm probably being a bit more pessimistic than reality right now [18:20] I suspect I'll have lots of time [18:20] and this time round I plan to make regular releases all through development, and keep it in a roughly working state [18:20] as aposed to 0.5, where so much was stripped out, it took ages to get it working again [18:21] yeah [18:21] I think it'd be beneficial to look at libnih [18:21] there's lots of things wrong with libnih [18:21] for one of my side projects I am experimenting with a new memory model that really makes C a lot easier. [18:21] oh? [18:21] yeah [18:21] oddly enough that's what I've been playing with recently [18:21] basically you have a series of "contexts" that are all referred to by name [18:21] have a prototype new nih_alloc that's based on ion_'s ideas [18:22] when you allocate you specify a context to allocate into [18:22] and when you free, you free everything in a context at once, never just one object [18:22] isn't there a name for an allocator like that? [18:23] I'm sure there's something like that in glibc [18:23] Its quasi region based [18:23] but the idea is you allocate by the time period an object is relevant for [18:24] it's a bit like obstack [18:25] so for this web server dealie: theres a context for transactions (opened on a request, closed on reply), a context for the time between receiving the start of a header and receiving the start of the entity, a context between the open and close of the connection, etc. [18:27] you get a lot of performance gains too, because the allocation operations are simpler, and the free operations are infrequent and much simpler [18:27] are you sure you've not just reinvented an alternate API to obstack? :p [18:28] obstacks are simple, for each obstack you can allocate as many items as you want [18:28] let me see... [18:28] when you free an item, all items allocated *after* that item are also freed [18:28] freeing the first item clears the obstack [18:28] they're really useful for exactly what you describe [18:28] attach an obstack to the transaction [18:28] allocate everything from there, including header stuff [18:28] each time you finish a header parse, free the item that started it (everything allocated for the header goes too) [18:29] each time you finish a transaction, free the obstack [18:29] that's good to know :) [18:29] I think most allocation should work that way. [18:30] the one thing I did different is most/all of the stacks are globally accessable. [18:30] the really nice thing about obstacks is they have a sort of memory [18:30] so if you repeatedly do the header phrase, there won't be any actual malloc() or free() calls [18:31] since you'll just continually reuse the same bit [18:31] yes. this is good :) [18:32] why are there no manpages for it? [18:32] because it's in glibc [18:32] read the info docs :p [18:33] friggin gnu freaky manpages [18:33] granted, info is superior to man in most every way... [18:34] but who has time for this shit? [22:19] Keybuk: please note the mailing list post I just made. [22:22] tl;dr [22:22] Nah, just kidding. I’ll try to read it. :-) [22:35] heh