| Keybuk | that'll be the last thing I do :-) | 00:00 |
|---|---|---|
| sadmac | Keybuk: I haven't crashed it yet. only interesting thing I've done is create 1000 jobfiles at once | 00:23 |
| 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:24 |
| Keybuk | probably just the terminal ;) | 00:26 |
| sadmac | could be | 00:26 |
| ion_ | I really wish terminals were better with that. IMO a terminal should *never* cause an application printing text to block. | 00:29 |
| 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:30 |
| Keybuk | ion_: it only blocks the app if the app using blocking io for stdout ;) | 00:31 |
| 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:32 |
| Keybuk | isn't that what happens mostly now? | 00:33 |
| Keybuk | it doesn't really matter either way | 00:33 |
| ion_ | Well, something like that, yes, but still ruby -e '10000.times { puts "bar" }' is *much* slower than the same with >/dev/null | 00:34 |
| Keybuk | what if you set it non-blocking? | 00:35 |
| 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. | 00:42 |
| Keybuk | why not? | 01:01 |
| 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:02 |
| ion_ | No, it wouldn’t. The prompt might just come to the screen sooner. :-) | 01:11 |
| Keybuk | it'd come much later | 01:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| Keybuk | but the printf won't unblock yet | 01:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| sadmac | ah | 01:22 |
| Keybuk | which should be enough to set up any number of tests | 01:23 |
| sadmac | Keybuk: ahh | 01:24 |
| 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:26 |
| sadmac | ah | 01:27 |
| 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:30 |
| sadmac | very good | 01:31 |
| ion_ | sadmac: Alternatively, $stdout.sync = false | 01:32 |
| sadmac | ion_: wouldn't it be sync = true? | 01:34 |
| sadmac | Keybuk: is it in any way possible to create an unlimited instance job? | 02:05 |
| Keybuk | sadmac: no, can you think of a use for one? | 09:29 |
| 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:40 |
| 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 | 13:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!