Conversation with #inferno at Sun Jan 16 02:53:32 2011 on powerman-asdf@irc.freenode.net (irc)
(13:15:56) bvalek2 [598516ea@gateway/web/freenode/ip.89.133.22.234] entered the room.
(18:41:32) bvalek2 left the room (quit: Quit: Page closed).
(19:49:21) Fish [~Fish@9fans.fr] entered the room.
(21:42:40) cbj [~cbj@c-98-216-73-231.hsd1.ma.comcast.net] entered the room.
(22:12:14) cbj left the room (quit: Ping timeout: 240 seconds).
(22:50:37) cbj [~cbj@c-98-216-73-231.hsd1.ma.comcast.net] entered the room.
(22:51:26) cbj: hi
(22:51:31) mjl-: howdy
(22:51:46) cbj: mjl- i think your repo is great!
(22:52:09) cbj: i've been browsing through a lot of your stuff.
(22:52:20) cbj: makes me want to get started on another inferno project again.
(22:53:00) cbj: how do you host your inferno?
(22:53:40) mjl-: i'm running it on a linux server currently
(22:53:53) mjl-: cool, about starting on another inferno project
(22:53:55) mjl-: plenty to do :)
(22:53:59) vsriniva1: not native? aww....
(22:54:03) vsriniva1: :)
(22:54:22) mjl-: hehe, not currently :(
(22:54:45) cbj: there aren't many public inferno services. so plenty of kudos for that.
(22:54:55) mjl-: i want to have another go at the intel video card for my x40 soon, but...
(22:56:12) vsriniva1: i actually have an experiment in mind, was going to try on native inferno -- i was going to add a sys-vread(fd: ref FD, pipefd: ref FD, nbytes: int): int; and vwrite(fd: ref FD, pipefd: ref FD, nbytes: int): int; pair of 'syscalls'.
(22:56:36) vsriniva1: the difference between vread and read is that vread will take a 2nd FD which points to a pipe.
(22:56:50) vsriniva1: and the reads and writes copy to/from the pipe buffer rather than a program buffer.
(22:57:22) vsriniva1: if inferno were a typical kernel, then this would avoid copy-to-user / copy-from-user for paths like http servers or w/e.
(22:57:33) vsriniva1: (its not; but this is a nice place to experiment)
(22:58:08) vsriniva1: and since its a pipe, you can prepend your own headers before the data blocks you read from someplace else.
(22:58:15) cbj: jl- do you use your native kirkwood for anything?
(22:58:46) mjl-: vsriniva1: that sounds sensible.  but how to get from the pipe to the network socket?  or is a network socket also considered a pipe?
(22:59:02) vsriniva1: another  vwrite() ! :D
(22:59:09) mjl-: cbj: not currently now.  my sheevaplugs are still in boxes at the moment even.  i'm writing other (user space) inferno code at atm
(22:59:10) vsriniva1: from the pipe FD to the net fd.
(22:59:24) mjl-: ah!
(22:59:40) mjl-: sounds like a good experiment :)
(23:00:05) mjl-: what happens if the pipefd in vread is full?
(23:00:07) mjl-: and blocks
(23:00:40) vsriniva1: hadn't decided ... i can see use for it blocking, actually. but its not generally safe if it can, i think, unless space can be 'reserved' in a pipe.
(23:00:52) vsriniva1: (for net reads, blocking is bad)
(23:01:44) mjl-: cbj: i have some vague plans for using inferno-kirkwood for a file server.  at least nfs (server code is mostly there), and cifs (server code in early stages).  but i also want a better file system (only code).  i need lots of time to do it.  inferno-kirkwood isn't finished yet either (i've read/written to my sata 1.5tb drive with it though)
(23:02:44) mjl-: vsriniva1: the read inside vread could read as much as is available in pipefd (assuming nothing else will fill it between vread's read & its write)
(23:03:27) mjl-: still vread returning 0 would normally indicate eof, while it could mean pipefd is full.  perhaps the programmer has to keep track of how much is available in pipefd anyway then.
(23:06:59) cbj left the room.
(23:40:37) caerwyn [~caerwyn@c-98-217-102-21.hsd1.ma.comcast.net] entered the room.
(00:00:47) caerwyn: mjl-: Have you run inferno hosted on sheevaplug?
(00:03:37) vsriniva1: on a 1.6ghz atom, a 2048 point DFT (DFT via correlation, not FFT) at double precision runs on a sine in 0.96 sec; java (1.6 JDK) takes 1.8 sec; limbo 2.0sec.
(00:03:49) vsriniva1: *the first was just C.
(00:04:36) caerwyn: With jit?
(00:04:39) mjl-: caerwyn: yes, on top of debian
(00:04:43) mjl-: jit didn't work
(00:04:49) mjl-: probably calling convention mismatch
(00:04:54) vsriniva1: caerwyn: yes.
(00:05:05) vsriniva1: (though that prolly wasn't to me :D)
(00:06:34) mjl-: hah, and i thought it was, but was triggered by the jit mention anyway
(00:06:48) vsriniva1: unrelated, sorry. 
(00:07:03) mjl-: "linux/arm jit problems" i send to inferno-list some time ago: http://thread.gmane.org/gmane.os.inferno.general/4949
(00:07:20) mjl-: vsriniva1: but is that the same code, the dft?
(00:07:32) mjl-: seems like a reasonable score for limbo/dis/inferno
(00:07:52) vsriniva1: yea, the core loop is terribly simple, natural in all 3 languages.
(00:09:31) vsriniva1: re[i] += x[j] * math->cos(real 2 * 3.1415 * real i * real j / (len x + 1));
(00:09:42) vsriniva1: repeat for imaginary part, use sin instead.
(00:10:06) vsriniva1: do this for every point in output, accumulate that across every point in the input.
(00:11:54) vsriniva1: limbo defines all FP math on real to be 64-bit, yea?
(00:13:59) mjl-: that's my understanding
(00:14:19) mjl-: it's what doc/dis.pdf says
(00:14:30) mjl-: well, provides
(00:14:42) vsriniva1: okay, hmm. i wonder why they have to do on less ieee 754-y platforms ....
(00:14:54) vsriniva1: also perhaps it'd have made sense to make single-precision available?
(00:15:16) caerwyn: You might not get fp at all.
(00:15:41) caerwyn: If I remember right, like the nintendo ds
(00:16:36) caerwyn: What are you writing?
(00:17:52) vsriniva1: i was actually talking to someone about android and why they had dalvik... we couldn't figure it out, as its rumored to be much slower than the sun jvm..... so we wanted to see if that was true and how much slower.... and it only took a few minutes to do the limbo one....
(00:19:33) mjl-: and how slow/fast is the android version?
(00:20:12) vsriniva1: am figuring out how to boot android-x86 now....
(00:20:54) vsriniva1: (on a 600mhz cortex a8, the C version on this data took ~25.5 sec, the java (sun jvm) version took ~24sec.... (erep!)
(00:21:09) vsriniva1: and inferno for that machine is slowly building now, will get back to you in a bit.
(00:21:19) vsriniva1: (unless any of you have an ARM/linux emu you want to share? :D
(00:21:25) mjl-: not bad for java/jvm
(00:21:31) mjl-: don't have one handy
(00:21:37) mjl-: but i hope the jit will work on it...
(00:22:04) caerwyn: There should be an arm emu on the inferno-bin project on googlecode
(00:22:11) vsriniva1: okay, will get it.
(00:22:22) vsriniva1: hmmm on x86, w/o JIT, 2.0 sec becomes 5.3sec.
(00:22:24) mjl-: btw, i think i read that the latest android native development kit (ndk) gives access to more of android.  perhaps an inferno port is now feasible
(00:22:25) caerwyn: I ve used one from ther on the chum by
(00:29:04) vsriniva1: caerwyn: thanks; copying over atm.
(00:31:05) vsriniva1: the native limbo compiler has a -O optimization option..... the limbo version doesn't?
(00:32:12) mjl-: optim.b is empty...
(00:32:17) vsriniva1: right.
(00:32:21) vsriniva1: optim.c is far from.
(00:34:16) vsriniva1: curious...
(00:34:30) caerwyn: I didn't know that
(00:35:57) caerwyn: I need to get out of my acme myopia and start using inferno again.
(00:38:31) vsriniva1: hmmm, grumbles. all of the inferno-bin arm binaries crash here...
(00:40:39) Fish left the room (quit: Quit: So Long, and Thanks for All the Fish).
(00:40:48) caerwyn: Sorry
(00:40:59) vsriniva1: it was a nice try!
(00:41:01) vsriniva1: thanks though.
(00:41:49) caerwyn: If you do build a working one it'd be nice to add to the collection
(00:41:54) vsriniva1: okay.
(00:41:57) vsriniva1: who did this, btw?
(00:41:58) vsriniva1: http://code.google.com/p/inferno-os-maemo/
(00:46:54) mjl-: the nickname doesn't ring a bell...
(00:51:08) caerwyn: That might have been a gsoc project
(00:55:52) caerwyn: I'm trying wam for the first time.
(00:56:16) caerwyn: Not warn Qwm. Damn text substitutions!
(01:19:07) mjl-: and and? :)
(01:27:02) mjl-: hmm, is a pread supposed to change the offset associated with an fd?
(01:27:12) vsriniva1: no.
(01:28:11) vsriniva1: 'offset untouched' in sys-read ;; (are you seeing it change?)
(01:31:24) mjl-: at first sight, i'm probably doing it wrong.
(01:36:00) mjl-: yeah, it still looks like it...
(01:36:09) mjl-: as if the number of bytes read is added to the offset, not the offset changed entirely
(01:39:30) mjl-: that is what the code is doing
(01:44:00) mjl-: plan 9's pread does it too.  i wonder what the idea behind that is
(01:55:04) mjl-: unix pread does change the offset
(01:57:39) mjl-: http://www.ueber.net/who/mjl/tmp/pread.b
(01:58:02) mjl-: i would expect that to print "offset is now 6", but it prints "offset is now 7" for me, the pread of 1 byte increased the offset by 1
(01:59:45) mjl-: anyway, it's late here, off for sleep o/~~
(02:16:42) vsriniva1: that's bizarre! 
(02:16:48) vsriniva1: quote from unix manpage: file offset is not changed
(02:17:28) mjl-: sorry, unix pread does _not_ change the offset...
(02:17:42) vsriniva1: quote from inferno: Pread and pwrite take an explicit file offset as a  parameter,  leaving fd's  current  offset untouched
(02:18:47) mjl-: but you could interpret that as "leaving fd's _initial_ current offset untouched".  then it says that otherwise it works as read & write, which do also advance the offset.
(02:19:07) vsriniva1: what does plan9's do?
(02:19:11) vsriniva1: oh it changes it....
(02:19:17) mjl-: same as inferno, changes it
(02:19:26) vsriniva1: that's bizarre and not terribly useful....
(02:19:32) mjl-: no...
(02:19:43) mjl-: it caused me to think i had a bug!
(02:20:02) cbj1 [~none@c-98-217-102-21.hsd1.ma.comcast.net] entered the room.
(02:20:10) vsriniva1: hey when did plan9 gain readv/writev/preadv/pwritev?
(02:21:02) mjl-: heh, the man page at bell labs says:  The implementations use malloc(2) to build a single buffer for a standard call to read or write. They are placeholders for possible future system calls.
(02:21:14) mjl-: (in readv(2)
(02:21:14) mjl-: )
(02:21:16) vsriniva1: hah okay.
(02:21:30) vsriniva1: so very unPlan9/Inferno-like
(02:22:18) cbj1 left the room (quit: Read error: Connection reset by peer).
(02:24:09) cbj1 [~none@c-98-217-102-21.hsd1.ma.comcast.net] entered the room.
(02:28:40) cbj1 left the room (quit: Read error: Connection reset by peer).
(02:51:32) The account has disconnected and you are no longer in this chat. You will be automatically rejoined in the chat when the account reconnects.