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
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
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
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 ...
> If the 'flag +x' worked as documented, it would be easy to tell :-p
the syntax is "flag x +".
- erik
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
> 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
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
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
>
>
That currently links to an uncompressed tarball.
Just a heads up.
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?
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.
> > 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
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
> It seems that it was. Geoff appears to have un-horked the
> frammis. Thanks!
three cheers for the unhorkification!
- erik
> 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
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
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
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
erik quanstrom wrote:
|- 9fans
|
|thanks for the interest!
no, i'm just totally brain dead.
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
> 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
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
23 matches
Mail list logo