[00:00] <Keybuk> that'll be the last thing I do :-)
[00:23] <sadmac> Keybuk: I haven't crashed it yet. only interesting thing I've done is create 1000 jobfiles at once
[00:24] <Keybuk> did it work and load them all?
[00:24] <sadmac> Keybuk: they all got loaded. Seemed to take a second to state such in the terminal
[00:26] <Keybuk> probably just the terminal ;)
[00:26] <sadmac> could be
[00:29] <ion_> I really wish terminals were better with that. IMO a terminal should *never* cause an application printing text to block.
[00:30] <ion_> And a terminal should skip stuff when needed.
[00:30] <sadmac> ion_: eew.
[00:30] <sadmac> I don't want information going missing unexpectedly
[00:31] <Keybuk> ion_: it only blocks the app if the app using blocking io for stdout ;)
[00:32] <ion_> Sorry, i wasn’t clear. Text going to the buffer and the buffer being rendered should be two separate things, where the the rendering part could just pause for a short while when it’s too slow.
[00:33] <Keybuk> isn't that what happens mostly now?
[00:33] <Keybuk> it doesn't really matter either way
[00:34] <ion_> Well, something like that, yes, but still ruby -e '10000.times { puts "bar" }' is *much* slower than the same with >/dev/null
[00:35] <Keybuk> what if you set it non-blocking?
[00:42] <ion_> Then the write calls seem to fail with EAGAIN. I was unclear again: a terminal can cause the write to block as long as it takes to update the *buffer* (should be fast), but the *rendering* of the buffer to the screen should not cause it to block.
[01:01] <Keybuk> why not?
[01:02] <Keybuk> what if it was rendering a prompt which the user needed to respond to within a few seconds?
[01:02] <Keybuk> printf ("Press ^C within three seconds\n");
[01:02] <Keybuk> sleep (3);
[01:02] <Keybuk> your suggestion would break that ;)
[01:11] <ion_> No, it wouldn’t. The prompt might just come to the screen sooner. :-)
[01:11] <Keybuk> it'd come much later
[01:12] <ion_> The render code would attempt to always show the newest possible state of the buffer, lowering the update rate a bit if the rendering was lagging.
[01:12] <Keybuk> how can you show the newest state without rendering the previous state?
[01:12] <Keybuk> terminal codes and all that
[01:12] <ion_> All that would be handled within the buffer, which is a non-rendered representation of the state.
[01:13] <Keybuk> it seems like a needless optimisation
[01:13] <ion_> The slow part seems to be rendering vector fonts with pretty antialiasing.
[01:13] <Keybuk> terminals like vte already only render the current buffer state
[01:13] <Keybuk> and they still noticeably slow it down
[01:14] <ion_> Well, it still happens that you may have to wait ages for an application to receive a ^C if it’s printing a lot of stuff quickly.
[01:15] <Keybuk> but the printf won't unblock yet
[01:17] <sadmac> I've seen ruby display some interesting buffer properties lately
[01:17] <sadmac> I had an app that I wanted to print a . at every iteration of a loop
[01:18] <sadmac> I got no output until the app terminated, then I got all the .s at once
[01:18] <Keybuk> that's just line buffered output
[01:18] <sadmac> oh. Didn't know that line buffering applied to output. I thought that was input only
[01:18] <sadmac> guess it makes sense though
[01:18] <Keybuk> can apply to any fd
[01:19] <Keybuk> stdout is line buffered by default
[01:19] <Keybuk> as is stdin
[01:19] <Keybuk> but stderr isn't
[01:19] <sadmac> $stdout.flush would have taken care of it I'm guessing.
[01:21] <sadmac> Keybuk: is there a way to manually trigger events in trunk? or do we just have to wait for initctl?
[01:21] <Keybuk> you get a debug event when it starts
[01:21] <Keybuk> and events for each job that you start as a result
[01:22] <sadmac> ah
[01:23] <Keybuk> which should be enough to set up any number of tests
[01:24] <sadmac> Keybuk: ahh
[01:26] <sadmac> Keybuk: so was there still a wire protocol for backup when the dbus service is unavailable, or was it that you use peer-to-peer dbus for this situation?
[01:26] <Keybuk> peer-to-peer dbus
[01:27] <sadmac> ah
[01:30] <Keybuk> connect to unix:abstract=/com/ubuntu/upstart
[01:30] <Keybuk> same objects as if you sent over the system bus to com.ubuntu.Upstart
[01:31] <sadmac> very good
[01:32] <ion_> sadmac: Alternatively, $stdout.sync = false
[01:34] <sadmac> ion_: wouldn't it be sync = true?
[02:05] <sadmac> Keybuk: is it in any way possible to create an unlimited instance job?
[09:29] <Keybuk> sadmac: no, can you think of a use for one?
[13:40] <sadmac2> Keybuk: I was trying to create an unlimited instance job so I could create a job that started on its own starting event and trigger itself an infinite number of times (with horrible results) :)
[13:40] <Keybuk> well, yes
[13:40] <Keybuk> that's kinda _why_ you can't do that ;)
[13:41] <Keybuk> the closest you can come is by having a job instanced on a UUID
[13:41] <Keybuk> and passing that UUID in the start message or event