Conversation with #inferno at Thu Nov  6 11:06:46 2008 on powerman-asdf@irc.freenode.net (irc)
(11:06:46) #inferno: The topic for #inferno is: Inferno and Limbo | Website: http://www.vitanuova.com/inferno/index.html | Documentation: http://www.vitanuova.com/inferno/docs.html | Wiki: http://canto.hopto.org/wiki/1/index.html | Tutorial: http://www.resc.rdg.ac.uk/twiki/bin/view/Resc/InfernoTutorial | Mailing list archives: http://dir.gmane.org/gmane.os.inferno.general
(12:55:47) sqweek [n=none@203-206-123-128.dyn.iinet.net.au] entered the room.
(14:03:57) rog left the room (quit: ).
(14:29:05) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(15:03:52) newmanbe [n=btdn@138.74.131.25] entered the room.
(16:29:19) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(17:18:51) npe [n=npe@32.97.110.64] entered the room.
(17:27:23) npe left the room (quit: Connection reset by peer).
(17:28:03) npe [n=npe@32.97.110.64] entered the room.
(17:28:03) npe left the room (quit: Connection reset by peer).
(17:37:15) npe [n=npe@32.97.110.64] entered the room.
(17:37:15) npe left the room (quit: Success).
(17:44:03) uriel__ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room.
(17:46:27) npe [n=npe@32.97.110.64] entered the room.
(17:49:58) uriel_ left the room (quit: Read error: 110 (Connection timed out)).
(17:55:42) npe_ [n=npe@32.97.110.64] entered the room.
(18:00:28) npe_ left the room (quit: Operation timed out).
(18:01:08) npe_ [n=npe@32.97.110.64] entered the room.
(18:01:08) npe_ left the room (quit: Connection reset by peer).
(18:03:47) npe left the room (quit: Connection timed out).
(18:04:42) powerman: uriel: uriel__: just noticed your yesterday's 'hey'. :)
(18:06:25) powerman: I'm not really good. These bugs forced me to pause development in Inferno and return to Perl for a while. I'm really unhappy with this, but I've work to be done.
(18:07:31) powerman: The good news is Charles fixed one of these nasty bugs after my email to list. If he fix other two soon, or at least last one, I'll immediately return to Inferno and continue developing.
(18:10:11) powerman: Of course I can continue using and researching Inferno with these bugs. For fun. And as a toy. And this way I can't spend much enough time for it. :( Only way to really use Inferno for me - use it for real work, on real servers under high load. And I hope that's possible!!
(18:10:20) npe [n=npe@32.97.110.64] entered the room.
(18:11:17) powerman: uriel: uriel__: btw, how is iwp9? still sucks, or you changed your mind? :)
(18:13:07) newmanbe left the room (quit: Read error: 110 (Connection timed out)).
(18:18:52) npe left the room (quit: Connection reset by peer).
(18:19:32) npe [n=npe@32.97.110.64] entered the room.
(18:28:48) npe_ [n=npe@32.97.110.64] entered the room.
(18:37:21) npe left the room (quit: Connection timed out).
(18:38:00) npe [n=npe@32.97.110.64] entered the room.
(18:42:39) npe left the room (quit: Read error: 60 (Operation timed out)).
(18:46:38) npe_ left the room (quit: Connection timed out).
(18:47:12) npe [n=npe@32.97.110.64] entered the room.
(18:56:27) npe_ [n=npe@32.97.110.64] entered the room.
(18:57:50) newmanbe [n=btdn@138.74.131.25] entered the room.
(19:04:53) npe left the room (quit: Connection timed out).
(19:04:59) npe_ left the room (quit: Connection reset by peer).
(19:05:39) npe [n=npe@32.97.110.64] entered the room.
(19:05:39) npe left the room (quit: Connection reset by peer).
(19:14:51) npe [n=npe@32.97.110.64] entered the room.
(19:24:03) npe_ [n=npe@32.97.110.64] entered the room.
(19:30:43) uriel: 16:08 < powerman-asdf> Of course I can continue using and researching Inferno with these bugs. For fun. And as a toy. And this way I can't spend much enough time for it. :( Only way to really use Inferno for me - use it for real work, on real servers under high load. And I hope that's possible!!
(19:30:53) uriel: I agree that the best use is use to get real stuff done...
(19:31:00) uriel: lets hope this is possible...
(19:31:04) npe left the room (quit: Connection timed out).
(19:31:16) powerman: if charles will fix bugs - it's surely possible
(19:31:45) uriel: well, I'm the first one to admit inferno has flaws, but some times the issue is one of style and usage paterns
(19:31:51) powerman: actually it's much more important for me to be sure he _will_ fix them in some adequate time, than have ready fix immediately 
(19:32:08) uriel: some parts of inferno work well because they are exercised by those that use it every day to get work done
(19:32:37) uriel: but that doesn't cover the whole system, and those users tend to follow a certain style/philosophy that exercises some parts more than others
(19:33:16) npe [n=npe@32.97.110.64] entered the room.
(19:33:17) uriel: (in their defense, that style/philosphy is mostly the way inferno is supposed to do, but that doesn't mean other usages shouldn't work, even if not recomended)
(19:33:37) powerman: I'm really happy to do have my work done in different style/philosophy. But sometimes it's just bugs.
(19:34:12) powerman: If killgrp doesn't kill all processes in group - this has nothing with style or philosophy.
(19:34:28) uriel: re., bug fixing, in my experience, (and this doesn't apply only to inferno, but to all software), the only way to know for sure bugs will be fixed is to fix them yourself...
(19:34:51) uriel: otherwise, you might get lucky, but you also might be disapointed
(19:37:12) uriel: well, maybe most users don't have so much use for killgrp, at least on plan9 signals (ie., notes) and killing is not recommended for normal usage
(19:37:59) uriel: in inferno, I suspect the preferred style is, have every proc alt on a channel, and when something comes down that channel quit
(19:38:10) powerman: killing not recommended? wow. I'll be happy to hear about other way to timeout network connection.
(19:38:25) uriel: then have a proc that controls all other, and tells them to quit
(19:38:55) uriel: timeouts can be nicely implemented with channels
(19:39:00) powerman: proc doing _blocking_ read/write to network. I've to timeout it and free resources used by this proc if it network connection freezed
(19:39:18) ***uriel ponders
(19:39:25) powerman: I can't both alt on channel and do blocking read/write...
(19:39:45) uriel: yes, but you usually use 'worther procs' for blocking read/write
(19:39:55) uriel: er worker
(19:40:05) powerman: yes... and what?
(19:40:08) uriel: (sorry, I'm on a tiny laptop and over a shitty network connection)
(19:40:13) powerman: there 1000s of such workers
(19:40:24) uriel: that for every worker, you will have somebody that controls it
(19:40:32) powerman: and main proc which doing alt 
(19:40:44) powerman: that main proc decide to kill workers on timeout
(19:41:00) uriel: the worker takes some data from the network, pushes it down the channel, the proc controling the worker can be managed by a control channel and it alts on the data and the ctl channels
(19:41:13) powerman: yeah, it work exactly in this way
(19:41:15) npe_ left the room (quit: Connection timed out).
(19:41:31) uriel: but then why did you need killgrp?
(19:41:48) npe left the room (quit: Connection reset by peer).
(19:41:58) uriel: (sorry if I'm being annoying, specially given that you probably know more than me about all this, I'm just trying to understand the stylistic issues involved)
(19:42:01) powerman: ah, I got it. there two bugs. you speak about first, I about last
(19:42:12) powerman: killgrp is first. wait is last.
(19:42:28) npe [n=npe@32.97.110.64] entered the room.
(19:42:32) powerman: about killgrp... let me remember where I used it...
(19:42:48) uriel: ah, I was only thinking about the bug you mentioned here :)
(19:42:58) powerman: ok, I got it
(19:43:23) powerman: killgrp bug was found while experimenting with prime number finder app from ipwl book
(19:43:50) powerman: chain of procs which give probably-prime-number to next proc to filter it
(19:44:09) uriel: ah, I see..
(19:44:46) uriel: I'm reading your other bug repport, and I agree the monitor() issue seems more serious
(19:44:49) powerman: so, procs are spawning all of time, and when I decide to stop this app some proc survive killgrp and continue spawning
(19:45:36) powerman: nothing serious, except it's nasty to find race condition :)
(19:45:37) uriel: although, again, i think this is the wrong style, you usually would not monitor() on hundreds or thousands of procs
(19:46:00) powerman: so, let's forget about killgrp and return to wait bug
(19:46:19) uriel: if I understand this correctly, and I think charles pointed out, you are trying to use inferno somewhat the way one would unix
(19:46:34) powerman: see, I've incoming connections. network. many of them - I can have up to, say, 3000 simult connections
(19:46:36) uriel: but in inferno you would use channels to communicate when a process is done 
(19:46:46) uriel: that should be no problem
(19:47:17) npe left the room (quit: Read error: 60 (Operation timed out)).
(19:47:28) uriel: for each connection you can have a worker proc that sipmly sits on a tight loop reading from network and passing data down a channel (and maybe alt on yet another to exit gracefully)
(19:47:52) powerman: to handle these connections I've to spawn workers. which doing blocking read/write. if I'm happy with communication protocol it will be enough to spawn one worker per connection (because I know order of read/write). if I'm unhappy and read/write can be async - I've to spawn 2 threads per connection.
(19:47:57) npe [n=npe@32.97.110.64] entered the room.
(19:47:57) npe left the room (quit: Connection reset by peer).
(19:48:18) powerman: then there main proc, which communicate with workers using channels
(19:48:33) uriel: and a controller thread that alts between its own ctl chan and the data chan, and passes down the worker's ctl chan when wanted to kill gracefully ( or kill it the hard way if it is blocked)
(19:49:13) powerman: now, remember I'm not in relaxed inferno local network. it's evil world. I've to protect. protect against DoS. against freezed connections. etc.
(19:49:36) uriel: yes, I understand
(19:49:42) powerman: (or kill it the hard way if it is blocked) - EXACTLY
(19:49:44) uriel: but I don't understand how using monitor() helps...
(19:50:05) powerman: monitor? it's simple:
(19:50:44) powerman: worker thread can exit because of different reasons. normal exit. raise. killed by main proc because of timeout. bug.
(19:51:20) uriel: bug seems the only relevant to monitor I would think, no?
(19:51:29) powerman: main proc should have _reliable_ way to find out fact about thread exit and related details - like exception text
(19:51:42) uriel: if the main proc kills it, it already knows, if normal exit, it can tell via channel
(19:51:53) powerman: no
(19:51:55) powerman: there race
(19:52:04) uriel: ?
(19:52:12) powerman: thread can exit normally while main proc prepare list of thread to kill because of timeout
(19:52:42) uriel: hmmmm...
(19:53:07) uriel: is it all that important? the proces dies either way gracefully
(19:54:17) uriel: does it matter if it quits or if it was killed? and if it does, shouldn't the individial controller for that worker be able to synchronize?
(19:54:22) powerman: again, if we remember about KISS - it's simpler to kill timed out workers and don't bother about them at _that_ place of code. and have other channel which collect information about exited threads and decide how to handle their exit (also in single place of code)
(19:54:31) uriel: (after all, it will alt on both msgs from worker and main controller)
(19:55:03) uriel: yes, but I'm not sure I quite understand what you are trying to do
(19:56:23) uriel: maybe if you explain why you need to know how did each proc exit, and I'm not sure your approach of an accountant and a killer is necesarily simpler..
(19:56:31) uriel: (could be, just not sure)
(19:57:05) powerman: maybe it will be ease to understand having code in hand: http://powerman.name/tmp/parsers.b.txt
(19:57:09) npe [n=npe@32.97.110.64] entered the room.
(19:57:09) npe left the room (quit: Connection reset by peer).
(20:05:26) powerman: uriel: I'm sorry to giving code as excuse for inability to explain problem in words - I'm just too sleepy now and switched my mind to completely another tasks in last few days. :(
(20:06:21) npe [n=npe@32.97.110.64] entered the room.
(20:06:27) uriel: powerman-asdf: no, no, code is great
(20:06:41) uriel: sorry, this really is not the best time for me to look into it :(
(20:07:04) uriel: (I'm in istanbul in a hostel with a laptop that has a cracked screen... and have to run get some food soon)
(20:07:17) uriel: not to mention I'm probably the least qualified person to comment :)
(20:07:22) uriel: maybe post code to inferno-list?
(20:09:28) powerman: I think code is ok. And I can develop one or two workarounds which should be safe enough. Actually Inferno with increased queue (my patch in issue tracker) handle 3500 exited threads in wait file, which is enough for me.
(20:10:10) powerman: The problem isn't in some critical bugs. Problem is in finding new nasty bug each time I try to use Inferno under high load.
(20:10:32) powerman: If it isn't designed for such task - I wish to hear this and relax.
(20:11:17) powerman: If it should work with such tasks - I wish to know there workarounds for bugs or Charles will fix them in some adequate time (not years).
(20:11:51) powerman: Actually I doesn't want something unique - usual requirements for tool which should be used for real work.
(20:12:15) uriel: it is designed, but I already told you that inferno is full of bugs because nobody uses it
(20:12:40) uriel: (other than the developers, and the codepaths the devs use are 'safe', the just cover a small part of the whole system)
(20:12:42) powerman: designed - good. full of bugs - not a problem in case there workarounds and fixes.
(20:13:14) uriel: well, if there were fixes, there wouldn't be bugs :)
(20:13:23) powerman: so, the questions now - is there workarounds? yes, for now. is there fixes? hmm. some. 
(20:13:36) uriel: (well, sadly in some cases the fixes exist but haven't been released because 'are not ready' or simply because nobody has copmlained
(20:14:15) uriel: and again, in any system, the only certain fixes (like the only certain features) are those you write yourself... :/
(20:14:17) powerman: actually I really understand charles about 'not ready' or 'don't like to fix it in this way'
(20:14:24) powerman: I do same on my projects for years.
(20:14:46) powerman: And my users probably suffer in same way and I because of Charles. :)
(20:14:51) powerman: and I -> as I
(20:15:29) uriel: :)
(20:15:35) uriel: understanding is good :)
(20:15:54) powerman: yeah. but now I'm on other side... and that's changes everything :D
(20:16:11) uriel: hehehe
(20:16:51) npe_ [n=npe@32.97.110.64] entered the room.
(20:18:05) powerman: Anyway. Inferno enlighten me a lot. I'm now rewriting my 3-years old perl module which doing event-based optimized I/O (using epoll/linux). And chances are, I'll do it in much simpler way nowadays.
(20:18:24) powerman: Probably I'll use it to develop Styx in Perl.
(20:19:00) uriel: ah! that would be wonderful
(20:19:08) uriel: I think perl is one of the few languages that has no 9p yet..
(20:19:19) powerman: yeah. and that's very strange.
(20:20:00) uriel: there are like three python implementation, two ruby ones, two java...
(20:20:14) uriel: (probably more, can't remember them all, and probably some more are not prublic)
(20:21:00) powerman: it's not a problem to do some reference implementation 'just to have one'. but that's not what I like to do. my implementation should not just work, but work reliable under really high load.
(20:21:37) uriel: even better ;)
(20:21:57) uriel: now I have to go, hope to be back home and be of more help some time next week
(20:22:06) uriel: good luck and keep up the great work!
(20:22:29) powerman: it may be surprising, but perl is really good for doing such tasks. if used in right way it's performance is similar to C (slower, but not *times slower)
(20:22:42) powerman: thanks :)
(20:23:48) powerman: from other side, because of such perl performance I completely forgot C - not used it for more than 10 years. so fixing Inferno C sources myself is a real problem. :(
(20:24:00) npe left the room (quit: Connection timed out).
(20:25:23) npe_ left the room (quit: Connection reset by peer).
(20:26:03) npe [n=npe@32.97.110.64] entered the room.
(20:26:03) npe left the room (quit: Read error: 131 (Connection reset by peer)).
(20:35:15) npe [n=npe@32.97.110.64] entered the room.
(20:39:35) npe left the room (quit: Operation timed out).
(20:40:15) npe [n=npe@32.97.110.64] entered the room.
(20:42:19) npe left the room (quit: Read error: 60 (Operation timed out)).
(20:49:30) npe [n=npe@32.97.110.64] entered the room.
(20:58:02) npe left the room (quit: Connection reset by peer).
(20:58:42) npe [n=npe@32.97.110.64] entered the room.
(20:58:42) npe left the room (quit: Read error: 131 (Connection reset by peer)).
(21:07:54) npe [n=npe@32.97.110.64] entered the room.
(21:07:55) npe left the room (quit: Success).
(21:17:06) npe [n=npe@32.97.110.64] entered the room.
(21:17:06) npe left the room (quit: Read error: 104 (Connection reset by peer)).
(21:27:32) npe [n=npe@32.97.110.64] entered the room.
(21:36:04) npe left the room (quit: Connection reset by peer).
(21:36:44) npe [n=npe@32.97.110.64] entered the room.
(21:40:08) KillerX left the room (quit: ).
(21:40:22) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(21:45:56) npe_ [n=npe@32.97.110.64] entered the room.
(21:53:32) npe left the room (quit: Connection timed out).
(21:55:08) npe [n=npe@32.97.110.64] entered the room.
(21:55:08) npe left the room (quit: Connection reset by peer).
(22:03:09) npe_ left the room (quit: Connection timed out).
(22:04:20) npe [n=npe@32.97.110.64] entered the room.
(22:04:20) npe left the room (quit: Read error: 131 (Connection reset by peer)).
(22:05:35) KillerX left the room (quit: ).
(22:13:32) npe [n=npe@32.97.110.64] entered the room.
(22:19:18) npe left the room (quit: Read error: 60 (Operation timed out)).
(22:22:44) npe [n=npe@32.97.110.64] entered the room.
(22:26:49) npe left the room (quit: Operation timed out).
(22:27:29) npe [n=npe@32.97.110.64] entered the room.
(22:35:26) newmanbe left the room (quit: Read error: 110 (Connection timed out)).
(22:37:56) npe_ [n=npe@32.97.110.64] entered the room.
(22:45:04) npe left the room (quit: Connection timed out).
(22:46:28) npe_ left the room (quit: Connection reset by peer).
(22:47:08) npe [n=npe@32.97.110.64] entered the room.
(22:55:40) npe left the room (quit: Connection reset by peer).
(22:56:20) npe [n=npe@32.97.110.64] entered the room.
(23:03:53) newmanbe [n=btdn@138.74.131.25] entered the room.
(23:04:52) npe left the room (quit: Connection reset by peer).
(23:05:32) npe [n=npe@32.97.110.64] entered the room.
(23:05:33) npe left the room (quit: Connection reset by peer).
(00:00:04) C-Keen left the room (quit: Remote closed the connection).
(00:08:25) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room.
(00:10:00) uriel__ left the room (quit: Read error: 60 (Operation timed out)).
(00:51:33) newmanbe left the room (quit: "Leaving").
(01:03:24) anothy left the room (quit: Read error: 110 (Connection timed out)).
(01:05:32) anothy [n=a@c-98-221-84-216.hsd1.nj.comcast.net] entered the room.
(01:57:02) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(01:58:18) anothy [n=a@c-98-221-84-216.hsd1.nj.comcast.net] entered the room.
(02:20:47) newmanbe [n=btdn@138.74.131.25] entered the room.
(02:50:05) uriel__ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room.
(03:07:37) uriel_ left the room (quit: Read error: 110 (Connection timed out)).
(04:01:13) npe [n=npe@66.112.249.148] entered the room.
(06:00:33) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(06:01:58) anothy [n=a@c-98-221-84-216.hsd1.nj.comcast.net] entered the room.
(06:38:30) underspecified left the room (quit: Read error: 104 (Connection reset by peer)).
(06:39:10) npe left the room (quit: ).
(06:39:35) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(06:44:22) anothy [n=a@c-98-221-84-216.hsd1.nj.comcast.net] entered the room.
(07:30:51) underspecified [n=eric@clair12.naist.jp] entered the room.
(08:32:14) newmanbe left the room (quit: "Leaving").
(08:33:17) underspecified left the room (quit: ).
(08:36:09) underspecified [n=eric@clair12.naist.jp] entered the room.
(09:23:53) mjl-: morning
(09:30:42) anothy: and here i am, about to go to bed. ;-)
(09:34:19) mjl-: happens ;)
(09:34:23) mjl-: sweet dreams
(09:53:11) sqweek: howdy
(09:53:39) sqweek: mjl-: do you think anything will misbehave if i change wm/irc's font to non-fixed-width?
(09:54:18) mjl-: yo sqweekmeister
(09:54:26) mjl-: i can't think of anything that will misbehave
(09:54:31) mjl-: but be my lack of imagination...
(09:55:18) mjl-: i'm not sure in how many places you need to configure the font
(09:55:35) mjl-: i suppose binding the font you want over the font that wm/irc might be easiest
(09:55:41) sqweek: i guess all the buttons and stuff are using default fonts
(10:04:21) mjl-: yes, i just don't know if tk has an option to change the default font for an app
(10:04:23) mjl-: probably does
(10:04:26) mjl-: let me know how it works
(10:04:55) mjl-: oh, one thing i can think of:  the listbox on the left will probably look a bit strange
(10:05:10) mjl-: -+= will probably have different widths
(10:05:32) mjl-: same holds for lines, which have a time, not all digits will have same widths
(10:06:12) rog [n=rog@78.148.16.148] entered the room.
(10:06:20) sqweek: depends on the font
(10:06:45) sqweek: the digits in /font/lucidasans/unicode.7.font are equal width
(10:08:47) rog_ [n=rog@78.148.16.148] entered the room.
(10:08:47) rog left the room (quit: Read error: 104 (Connection reset by peer)).
(10:09:35) sqweek: it works, but as i kind of expected it didn't affect all fonts (i only changed the two -font occurences)
(10:10:04) mjl-: myeah, those are there to make something work (i think)
(10:10:30) mjl-: sqweek: i would try binding a font file on the default font file
(10:13:38) C-Keen [i=ckeen@pestilenz.org] entered the room.
(10:19:40) sqweek: well the font changed, but not quite how i would expect...
(10:22:00) mjl-: screenshot!!!111
(10:23:36) uriel_ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room.
(10:23:39) sqweek: the smaller text is the explicitly requested font
(10:24:46) sqweek: http://sqweek.dnsdojo.org/tmp/ircfs-bind-font.png
(10:25:23) uriel__ left the room (quit: Read error: 60 (Operation timed out)).
(10:26:32) mjl-: sqweek: the text in the main textarea looks good.  but strange that the other text changes as well?
(10:26:46) sqweek: the other text changed because of the bind
(10:27:14) sqweek: but i bound the same font i used for the main textarea, so i don't know why it looks different...
(10:27:28) sqweek: i added a bunch more -font crap around and now everything is consistent
(10:29:50) mjl-: perhaps the fonts you bounded are in a different directory?  the .font files contain references to other paths.  so perhaps a bind of the entire dir helps as well
(10:29:57) mjl-: but if it's consistent now, that good
(10:30:14) mjl-: the activity stuff on the left is not off by too much?
(10:30:46) sqweek: right, the different directory would explain it
(10:32:21) sqweek: things get misaligned a bit because -/+ is wider than space
(10:32:28) sqweek: but not a big deal
(12:16:06) underspecified left the room (quit: ).
(13:15:43) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room.
(13:42:30) underspecified left the room (quit: ).
(13:43:49) underspecified [n=eric@softbank220043052011.bbtec.net] entered the room.
(17:01:08) npe [n=npe@32.97.110.64] entered the room.
(17:01:08) npe left the room (quit: Connection reset by peer).
(17:20:23) npe [n=npe@32.97.110.63] entered the room.
(17:29:35) npe_ [n=npe@32.97.110.63] entered the room.
(17:37:41) npe left the room (quit: Connection timed out).
(17:38:06) npe_ left the room (quit: Connection reset by peer).
(17:38:46) npe [n=npe@32.97.110.63] entered the room.
(17:38:46) npe left the room (quit: Success).
(17:39:22) npe [n=npe@32.97.110.63] entered the room.
(17:48:33) npe_ [n=npe@32.97.110.63] entered the room.
(17:57:12) npe left the room (quit: Connection timed out).
(17:57:44) npe [n=npe@32.97.110.63] entered the room.
(18:06:03) npe_ left the room (quit: Connection timed out).
(18:06:55) npe_ [n=npe@32.97.110.63] entered the room.
(18:13:21) anothy left the room (quit: "Leaving.").
(18:13:59) npe left the room (quit: Connection timed out).
(18:16:07) npe [n=npe@32.97.110.63] entered the room.
(18:23:16) npe_ left the room (quit: Success).
(18:25:18) npe_ [n=npe@32.97.110.63] entered the room.
(18:32:32) npe left the room (quit: Connection timed out).
(18:33:49) npe_ left the room (quit: Connection reset by peer).
(18:34:29) npe [n=npe@32.97.110.63] entered the room.
(18:34:29) npe left the room (quit: Connection reset by peer).
(18:43:40) npe [n=npe@32.97.110.63] entered the room.
(18:54:06) npe_ [n=npe@32.97.110.63] entered the room.
(18:55:08) newmanbe [n=btdn@138.74.131.25] entered the room.
(18:59:58) npe left the room (quit: Connection timed out).
(19:04:33) npe [n=npe@32.97.110.63] entered the room.
(19:10:27) npe_ left the room (quit: Connection timed out).
(19:13:45) npe_ [n=npe@32.97.110.63] entered the room.
(19:18:39) npe_: test
(19:20:44) mjl-: it works!!1
(19:20:54) npe left the room (quit: Connection timed out).
(00:33:58) npe_ left the room (quit: Read error: 60 (Operation timed out)).
(00:52:31) rog_ left the room (quit: ).
(00:52:43) mennis left the room (quit: ).
(00:57:17) rog [n=rog@78.148.16.148] entered the room.
(01:02:55) rog left the room (quit: ).
(01:19:09) newmanbe left the room (quit: "Leaving").
(02:56:42) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(03:00:32) KillerX left the room (quit: Client Quit).
(03:36:37) uriel__ [n=uriel@84-216-52-47.sprayadsl.telenor.se] entered the room.
(03:47:57) uriel_ left the room (quit: Read error: 110 (Connection timed out)).
(06:14:53) trojatra [n=trojatra@c-75-72-133-174.hsd1.mn.comcast.net] entered the room.
(06:15:11) trojatra: Can you install Inferno from a CD (without using P9, Linux, BSD, etc.)?
(06:30:10) sqweek: inferno can run native, so i guess so
(06:35:07) trojatra: Are there instructions for doing this somewhere? I can't find any :\
(06:39:59) sqweek: not sure
(06:42:31) trojatra left the room ("Ex-Chat").
(08:59:46) anothy [n=a@c-98-221-104-176.hsd1.nj.comcast.net] entered the room.
(17:59:36) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(18:11:35) mjl-: anyone here with experience with rsa (crypto) stuff in inferno?
(18:34:43) KillerX left the room (quit: ).
(18:35:06) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(18:40:30) KillerX left the room (quit: ).
(18:48:05) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(19:37:01) newmanbe [n=btdn@138.74.131.25] entered the room.
(19:38:57) KillerX left the room (quit: ).
(19:39:11) KillerX [n=anant@gentoo/developer/KillerX] entered the room.
(21:10:52) jas_: pip had some instructions on native inferno somewhere...
(21:25:31) mjl-: blstuart has some recent instructions
(21:26:31) mjl-: https://umdrive.memphis.edu/blstuart/htdocs/inf_nat_inst.html
(21:26:45) mjl-: the page has an iso
(21:26:53) mjl-: oh, trojatra left a long time ago...
(21:47:26) npe [n=npe@66.112.249.148] entered the room.
(21:54:10) trojatra [n=trojatra@c-75-72-133-174.hsd1.mn.comcast.net] entered the room.
(21:55:30) trojatra: mjl-, I believe I am having the same issues I was having with the Plan 9 install CD, stuck at boot from:
(01:43:36) mjl-: trojatra: that makes sense.  i think they use the same 9load (which is the thing that loads a kernel from someplace)
(02:13:50) KillerX_ [n=anant@145-116-231-243.uilenstede.casema.nl] entered the room.
(02:14:21) KillerX left the room (quit: Remote closed the connection).
(02:57:57) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(02:57:57) trojatra left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:03:01) trojatra [n=trojatra@c-75-72-133-174.hsd1.mn.comcast.net] entered the room.
(03:03:01) anothy [n=a@c-98-221-104-176.hsd1.nj.comcast.net] entered the room.
(03:58:29) trojatra left the room ("Ex-Chat").
(03:58:59) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(04:00:58) newmanbe [n=btdn@138.74.131.25] entered the room.
(04:03:31) newmanbe left the room (quit: Success).
(04:05:02) newmanbe [n=btdn@138.74.131.25] entered the room.
(04:08:41) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(04:09:21) anothy [n=a@c-98-221-104-176.hsd1.nj.comcast.net] entered the room.
(04:52:01) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(04:55:48) anothy [n=a@c-98-221-104-176.hsd1.nj.comcast.net] entered the room.
(05:27:28) anothy left the room (quit: Read error: 110 (Connection timed out)).
(05:28:38) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(05:30:11) newmanbe [n=btdn@138.74.131.25] entered the room.
(05:30:20) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(05:31:30) newmanbe [n=btdn@138.74.131.25] entered the room.
(05:38:44) KillerX_ left the room (quit: Client Quit).
(06:54:52) npe left the room (quit: ).
(08:52:02) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(08:57:07) newmanbe [n=btdn@138.74.131.25] entered the room.
(09:10:00) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(09:14:24) newmanbe [n=btdn@138.74.131.25] entered the room.
(09:14:43) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(09:24:59) newmanbe [n=btdn@138.74.131.25] entered the room.
(09:25:19) newmanbe left the room (quit: Read error: 104 (Connection reset by peer)).
(09:27:05) newmanbe [n=btdn@138.74.131.25] entered the room.
(09:54:33) newmanbe left the room (quit: Connection reset by peer).
(15:14:58) mjl-: good day all
(15:21:39) sqweek: hi mjl
(15:42:00) uriel__ left the room (quit: Read error: 60 (Operation timed out)).
(16:30:34) mjl-: yo sqweek
(16:30:38) mjl-: any limbo programming lately? :)
(16:30:40) mjl-: like on n
(16:34:47) sqweek: nah
(16:34:53) sqweek: tried to reproduce the ircfs disconnect bug
(16:35:14) mjl-: ah, and?
(16:35:22) sqweek: i failed
(16:35:49) sqweek: but i got a bit more familiar with the debugging tools
(16:37:24) mjl-: you used wm/deb?
(16:37:34) mjl-: it's quite good i think.  stack -v is helpful too
(16:37:38) mjl-: for quick things
(16:38:02) sqweek: indeed
(16:38:29) sqweek: hopefully i can work out what is going on next time it actually happens
(16:39:37) sqweek: abuses my poor 500MHz geode having an ircfs proc spinning so fast :S
(16:39:39) mjl-: what are the symptoms again?
(16:39:42) mjl-: :D
(16:39:52) mjl-: ah, yes, the spinning thing
(16:44:48) mjl-: btw, i did do some changes wrt disconnects some time ago.  might be triggered less often now? 
(16:45:23) sqweek: ah, maybe it is even fixed
(16:45:43) sqweek: unfortunately i think i restarted ircfs before i pulled
(16:46:32) sqweek: although i should restart again because inferno's west australian timezone file is out of date
(16:49:24) mjl-: had the same problem... i didn't restart ircfs though, a month later the time was correct again :P
(16:49:38) sqweek: heh
(16:49:46) mjl-: the timezone is fixed now?  charles did put in a few more timezone changes then
(16:49:55) sqweek: dunno
(16:50:13) sqweek: man, the blinking cursor in ircfs fools me every time
(16:50:18) sqweek: always think it has focus when it doesn't
(16:50:46) sqweek: well, it's inferno that doesn't have focus
(16:51:56) mjl-: ☺
(16:52:13) mjl-: the blinking cursor is a bit weird, dunno
(16:52:43) mjl-: i like acme's cursor just as much, and that doesn't requiring drawing all the time
(16:52:44) olegfink: does having some x -> wm hook for notifying when an emu windows is out of focus make sense?
(16:53:01) olegfink: s/(window)s/\1/
(16:53:08) mjl-: i suggest removing the blinking alltogether, and making the cursor look a bit more obvious
(16:53:20) mjl-: i'm guessing the reason for blinking is that you can find it more easily
(16:56:47) mjl-: hah, i'm writing an ssh client
(16:56:53) mjl-: doesn't look hard
(16:57:00) mjl-: i can already login and execute a command
(17:02:43) sqweek: awesome
(17:03:11) sqweek: i thought you might be, with the rsa question and looking through russ's ssh2 code
(17:06:19) mjl-: the rsa-thing is still an open question
(17:06:30) mjl-: for now i don't verify the rsa signature the server sends after a key exchange
(17:07:37) mjl-: it seems the rsa code is not documented.  it isn't hard luckily.  it's just a matter of figuring out what's in the rsa signature the server sends, and which part of it i need to feed to rsa's verify()
(17:10:51) KillerX [n=anant@gentoo/developer/KillerX] entered the room.