Re: [9fans] Purely historical question on variadic function notation

2013-10-15 Thread fgergo
Thanks for the guess! Since I could not directly find this information, at the moment I am trying to find when ... was introduced. I hope to find a hint during this search. On Wed, Oct 16, 2013 at 6:21 AM, Joel C. Salomon wrote: > On Mon, Oct 14, 2013 at 5:40 PM, Gergő Födémesi wrote: >> Who inv

Re: [9fans] Ritchie and Plan 9

2013-10-15 Thread Skip Tavakkolian
i'm not sure if rsc's "plan 9 kernel history" includes the contributors' name in the file diffs, but it is worth a look. http://swtch.com/plan9history/ On Mon, Oct 14, 2013 at 10:27 AM, Sakis Kasampalis wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Are there any notes/facts ab

Re: [9fans] Purely historical question on variadic function notation

2013-10-15 Thread Joel C. Salomon
On Mon, Oct 14, 2013 at 5:40 PM, Gergő Födémesi wrote: > Who invented ... notation in c? > I'll appreciate any hints. I'd guess this comes from C++, along with all function prototypes. --Joel

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread Lyndon Nerenberg
On 2013-10-15, at 6:39 PM, erik quanstrom wrote: > the syntax is "flag x +". Oh gawd I have been subsumed by the Bourne Supremacy ...

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread erik quanstrom
> If the 'flag +x' worked as documented, it would be easy to tell :-p the syntax is "flag x +". - erik

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread Lyndon Nerenberg
On 2013-10-15, at 6:33 PM, erik quanstrom wrote: > 1.test -f /dev/mousectl > 2 ~ $mouseport ps2 ps2intellimouse 0 1 2 usb > 3.! ~ $"monitor '' > 4.! ~ `{cat /dev/user} none > > > could /dev/user be none, while $user = your user? If the 'flag +x' worked as documented, it would

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread erik quanstrom
> The aux/vga in termrc isn't running. The one I added to > $home/lib/profile is. (And why isn't 'flag +x' added to > /rc/bin/termrc barfing out the expected trace data? The 'echo kill > -roy' immediately below it fires off.) at least on my machine, the simplified relevant bit looks like

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread Lyndon Nerenberg
On 2013-10-15, at 1:36 PM, erik quanstrom wrote: > due to the second law of thermohorification, fixing one thing means that at > least one other thing goes broken. perhaps your mouse:parallels connection > kept the universe's hork in balance. Whatever it is, it's very bizarre. The aux/vga in

Re: [9fans] Kirara new version

2013-10-15 Thread arisawa
Hello, My first code was like > if(~ $#kirara2 0) > kirara2=/n/other/kirara2 but I rewrote > kirara2=/n/other/kirara2 > kirara=$kirara2 because the latter is safest, though a little pain. Thanks On 2013/10/14, at 14:59, BurnZeZ wrote: > kirara2=/n/other/kirara2 > kirara=$kirara2 > >

Re: [9fans] Kirara new version

2013-10-15 Thread BurnZeZ
That currently links to an uncompressed tarball. Just a heads up.

Re: [9fans] Kirara new version

2013-10-15 Thread BurnZeZ
kirara2=/n/other/kirara2 kirara=$kirara2 This is in many of the scripts, and you are required to manually correct it. if(~ $#kirara2 0) kirara2=/n/other/kirara2 Is there a reason something like this is not done instead?

Re: [9fans] reg DI left allocated

2013-10-15 Thread Charles Forsyth
On 15 October 2013 20:45, Steve Simon wrote: > I assume the answer is just > to simplify the code > Yes, to get it through, but it shouldn't happen. If you can produce a simplified test case that will be helpful. It might involve 64-bit ints or structure assignment.

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread erik quanstrom
> > does "aux/vga -l $vgasize" do what you expect? > > > No, it actually kicks the display into graphics framebuffer node. > (That's *not* what I expected.) But this turns up a new problem: no > data from the mouse. /dev/mouse is there, but it returns no data. I > can start rio at this point, bu

Re: [9fans] Parallels mysteriously loosing /dev/draw

2013-10-15 Thread Lyndon Nerenberg
On 2013-10-14, at 7:38 PM, erik quanstrom wrote: > does "aux/vga -l $vgasize" do what you expect? No, it actually kicks the display into graphics framebuffer node. (That's *not* what I expected.) But this turns up a new problem: no data from the mouse. /dev/mouse is there, but it returns n

Re: [9fans] "On a clear disk, you can seek forever"

2013-10-15 Thread erik quanstrom
> It seems that it was. Geoff appears to have un-horked the > frammis. Thanks! three cheers for the unhorkification! - erik

Re: [9fans] "On a clear disk, you can seek forever"

2013-10-15 Thread Dave Eckhardt
> It seems as if the fossil partition on the official USB > installer image is full of zeroes? It seems that it was. Geoff appears to have un-horked the frammis. Thanks! Dave Eckhardt

Re: [9fans] reg DI left allocated

2013-10-15 Thread erik quanstrom
On Tue Oct 15 15:46:57 EDT 2013, st...@quintile.net wrote: > Hi, > > Compiling open source software with 8c I see: > > "reg DI left allocated" > > I haven't unpicked the code from all its #defines to see > what is actually causing this, and I assume the answer is just > to simplify the cod

[9fans] reg DI left allocated

2013-10-15 Thread Steve Simon
Hi, Compiling open source software with 8c I see: "reg DI left allocated" I haven't unpicked the code from all its #defines to see what is actually causing this, and I assume the answer is just to simplify the code but done anyone have an explanation as to what might have happened? Than

Re: [9fans] [sources] applied patch: /n/atom/patch/applied/termrcnodhcp

2013-10-15 Thread erik quanstrom
On Tue Oct 15 09:20:16 EDT 2013, sdao...@gmail.com wrote: > erik quanstrom wrote: > |- 9fans > | > |thanks for the interest! > > no, i'm just totally brain dead. i didn't think so. seems like sleep should be fixed. but i need more information on your environment to fix it. if you're runnin

Re: [9fans] [sources] applied patch: /n/atom/patch/applied/termrcnodhcp

2013-10-15 Thread Daode
erik quanstrom wrote: |- 9fans | |thanks for the interest! no, i'm just totally brain dead.

Re: [9fans] [sources] applied patch: /n/atom/patch/applied/termrcnodhcp

2013-10-15 Thread Daode
hmm, i'm braindead. And that made it especially hard to deal with ipconfig(8): by default, ipconfig exits after trying DHCP for 15 seconds with no answer --steffen --- Begin Message --- Hello, erik quanstrom wrote: |email | quans...@quanstro.net |readme | don't dhcp by default. it look

Re: [9fans] [sources] applied patch: /n/atom/patch/applied/termrcnodhcp

2013-10-15 Thread erik quanstrom
> then each tick sleeps ~1 second (sometimes a tick needed 3 in the > tests i've done). But if i add hmm. can you explain more about the environment, and kernel you were using? i'd like to correct the kernel timing. sleep(n) must be fairly accurate. i would define that as accurate to ±1/HZ on

Re: [9fans] [sources] applied patch: /n/atom/patch/applied/termrcnodhcp

2013-10-15 Thread Daode
Hello, erik quanstrom wrote: |email | quans...@quanstro.net |readme | don't dhcp by default. it looks like a hang. [.] |+ #if(! test -e /net/ipifc/0/ctl || ~ 127.0.0.1 `{cat /net/ipifc/0/local}) |+ # ip/ipconfig >/dev/null >[2=1] [.] after looking into the ipconfig source and placing