[9fans] Re: finding root blocks in a venti server

[Anthony Martin]

ashley  once said:
> is it possible to find the scores for all root blocks in a venti server?

/sys/src/cmd/venti/words/dumpvacroots

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf81f9125de5510db-M349a6119ba48f492793ff3e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] troll paper

[Anthony Martin]

"Do we really have to have our own kernel? What are
the benefits?" ...

The IWP9 paper titled "centre, left and right" looks like
a complete troll. Was it generated by an LLM? I read the
whole thing and it was a waste of time. Zero stars, would
not recommend.

Institutional Academy of the Academic Institute, lol.

The vetting process needs some work, lads.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mc0042c4999171963951f5bad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: Pipes staying after sending note

[Anthony Martin]

Philip Silva via 9fans <9fans@9fans.net> once said:
> if ((cpid = fork()) != 0) {
> close(infd[1]);
> close(outfd[1]);
>
> n = write(infd[0], "test", 4);
> printf("check process: wrote %d bytes\n", n);
>
> sendnote(cpid);
> // close(infd[0]);  // <--- uncomment to make write fail
> // close(outfd[0]);
>
> n = write(infd[0], "test2", 5);
> printf("write: wrote %d bytes\n", n);
>
> n = read(outfd[0], outbuf, 20);
> printf("outbuf=%s (n=%d)\n", outbuf, n);
> wait();
> return 0;

Why aren't you waiting for the process to die
after sending it the note? It must be running
to see that is has a note pending. At the time
of your second write, the scheduler may not
have selected the child process to run.

The sequence could look like:

child: read from empty pipe, go to sleep
parent: write to pipe
parent: write kill to /proc/$cpid/note
parent: write to pipe
child: wakeup, see note, die

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3392001a02ee7ec8-Mfe03d0d140063db1ea509f2a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Adjust Thinkpad Screen Brightness

[Anthony Martin]

un...@cpan.org once said:
> I reviewed the data sheet and the scripts should
> work, but does not.

The above scripts can work for some Intel cards
but probably not for all of them.

I wrote a program fifteen years ago to adjust the
brightness on an Intel MacBook from Linux. There
was a bit of experimentation involved to determine
register values that wouldn't cause problems. I've
attached it below.

Notice how I had to use a mask of 0xfffe instead
of 0x to keep the least significant bit zero
and how I had to be strict about maintaining the
maximum backlight level field when reading and
writing the register. I remember working through a
lot of blank and flickering screens before
arriving at something that worked.

I'm not near a machine with an Intel card at the
moment so I can't give you something that works on
Plan 9 but reading this old code may give you some
hints.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4c4247ec1c0429f6-M13bf569fd6da2483ff3c4074
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
#define _XOPEN_SOURCE 500
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef unsigned short  ushort;
typedef unsigned intuint;

// A barebones representation of a PCI device.
typedef struct Pcidev Pcidev;
struct Pcidev {
ushort vid;  // PCI vendor ID.
ushort did;  // PCI device ID.
pciaddr_t  bar;  // Physical address of the first BAR.
size_t size; // Size of the first BAR.
char*  addr; // Mapped virtual address of the first BAR.
};

// Macros to read and write 32-bit PCI memory registers.
#define reg32r(p, r)(*(uint*)((p)->addr+(r)))
#define reg32w(p, r, v) (*(uint*)((p)->addr+(r)) = (v))

enum {
// The PCI vendor and device ID for the Intel 945GM graphics chipset.
Intel  = 0x8086,
I945GM = 0x27a2,

// The backlight PWM control register offset.
Bctl = 0x061254,

// The backlight duty cycle mask. The LSB must be zero.
Bmask = 0xfffe,

// The empirically observed range for valid brightness levels.
Boff = 0x,
Bmin = 0x003e,
Bmax = 0x0128,

// Without an explicit value, we increase or decrease by this
// quantum so that there are only ten brightness levels.
Bquant = (Bmax-Bmin)/(10-1),
};

// We don't expose the hardware-centric brightness levels to the user
// but instead shift the range down so it starts at one. These macros
// convert to and fro.
#define B(u)(((u) == 0) ? Boff : (u)+Bmin-1)
#define U(b)(((b) == Boff) ? 0 : (b)-Bmin+1)

// The set of operations that can be performed on the backlight.
enum {
Onop = 1<<0,
Oset = 1<<1,
Oadd = 1<<2|Oset,
Osub = 1<<3|Oset,
};

// The high sixteen bits of the opcode are only used for operations
// that require a numeric argument. These macros ease extraction.
#define OP(o)((o)&0x)
#define OPVAL(v) (((v)&0x)<<16)

char*   argv0;

voidfatal(char*, ...);
int pcimatch(Pcidev*, int, int);

int
main(int argc, char *argv[])
{
int o, fd, max, cur, new;
char *s, *end;
Pcidev p;

// Determine which operation to perform.
argv0 = argv[0];
switch(argc){
default:
fprintf(stderr, "usage: %s [+-][val]\n", argv0);
exit(EXIT_FAILURE);
case 1:
o = Onop;
break;
case 2:
s = argv[1];
if(*s == '+' || *s == '-'){
o = (*s == '+') ? Oadd : Osub;
s++;
} else
o = Oset;
if(o != Oset && *s == '\0')
o |= OPVAL(Bquant);
else {
o |= OPVAL(strtol(s, , 10));
if(errno != 0 || end == s)
fatal("invalid number");
}
break;
}

// Map the GPU device into memory so we can access the backlight 
register.
if(pcimatch(, Intel, I945GM) < 0)
fatal("pcimatch failed");
fd = open("/dev/mem", O_RDWR);
if(fd < 0)
fatal("open /dev/mem failed");
p.addr = mmap(NULL, p.size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 
p.bar);
if(p.addr == MAP_FAILED)
fatal("map failed");
close(fd);
max = reg32r(, Bctl) >> 16;
if(max != Bmax)
fatal("invalid maximum: have %d want %d", max, Bmax);

// Load the current brightness level and change it, if applicable.
cur = reg32r(, Bctl) & Bmask;
new = 0;
switch(OP(o)){
case Oset:
new = B(o>>16);
break;
case Oadd:
new = (cur == Boff) ? 

Re: [9fans] Adjust Thinkpad Screen Brightness

[Anthony Martin]

o...@eigenstate.org once said:
> not nicely integrated. Depending on your card, something like
> this may work:
>
> [...]
>
> You'll have to figure out where the backlight PWM register is
> on your model of video card if this doesn't just work out of
> the box.

Konstantinn wrote a version of your script with predetermined
register addresses for a bunch of cards:

https://shithub.us/qwx/rc/98421abf7681f7ae8d49c4e4e82ffbdc6b215ef6/bin/br/raw

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4c4247ec1c0429f6-M46e9148d59fdc4150c3f21d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Anthony Martin]

Charles Forsyth  once said:
> It's funny that usually "it wasn't me" is used when breaking things. here
> it's fixing them, but I'm fairly sure "it wasn't me" that fixed it.

It was Richard Miller in 2012.

https://9p.io/sources/patch/applied/fossil-snap-deadlock/
https://9p.io/sources/patch/applied/fossil-archive-corruption/
https://9p.io/sources/patch/applied/fossil-superblock-write/

He fixed another issue a year or two ago.

http://9legacy.org/9legacy/patch/fossil-deadlocks.diff

Noam, can you reproduce your problem with the above patch?

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-Mce8ab1dcb5e0d8d96f33af8e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] spim syscall stack adjustment

[Anthony Martin]

Does anyone know why the libc system call functions for
spim add four to the stack pointer (R29) before issuing
the SYSCALL instruction?

/sys/src/libc/9syscall/mkfile:/spim

It was introduced in the third edition but there were
never any spim kernels released so I wasn't able to
compare the libc additions to the trap code.

I was watching one of adventuresin9's videos about his
ongoing port to the MediaTek MT7688 and he mentioned
having to modify the stack offsets in the syscall trap
handler just as cherry9 had done for the loongson port.

Is there any reason not to simply get rid of that ADD $4?

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T589fa55313abbdb4-Mc96c7cb218c2b6a69a83b8e8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] non-interruptible temporary: why do we care?

[Anthony Martin]

un...@cpan.org once said:
> Quoth o...@eigenstate.org:
> > Why do we warn about non-interruptible
> > temporaries? What issues am I missing?
>
> Silence to this question means no one knows, right?

There is nothing new under the sun.

Date: Mon, 4 Apr 2005 14:10:20 -0400
From: Russ Cox 
To: Fans of the OS Plan 9 from Bell Labs <9f...@cse.psu.edu>
Subject: Re: [9fans] 'non-interruptable temporary' warning
Message-ID: 

the compiler is warning you against its own laziness.
in this case it is using a global temporary to hold the
intermediate value of (lba = f->lba) while converting
it to uchar.  if you had another thread running through
this code it would use the same temporary.

[...]

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdcfb8f84c90eb199-Ma5f11ad84f13cd81ba0c8c85
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: rc: <{command} and > mess with exit status

[Anthony Martin]

adr via 9fans <9fans@9fans.net> once said:
> ; if(grep a <{echo a} >/tmp/1) echo true
> ;
>
> Is this expected?

This was fixed a few years ago in 9front:

http://git.9front.org/plan9front/plan9front/2839760066e578e449ebc8b3d71297b9f79a8c99/commit.html

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad6cf6b7414c1847-M2ee91d7ff496d1af63633dea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: What's a mounted channel?

[Anthony Martin]

Anonymous AWK fan via 9fans <9fans@9fans.net> once said:
> The comments on the #define lines and a commented out section of
> stat(2) say (DM|QT)MOUNT indicates a mounted channel, what is this?
>
> Also, why does exportfs fork and the kernel not send write on closed
> pipe notes for mounted channels?

When you call mount(2), the mnt(3) driver attempts to
negotiate a conversation with the 9p server on the other
end of the supplied file descriptor. If the negotiation
is successful, the kernel sets a flag on the underlying
channel to restrict the set of operations available to
user space until the file descriptor is closed. If this
wasn't done, any reads, writes, or seeks would interfere
with the mount driver's ongoing 9p conversation.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T07cb7686febe72c8-M1734aaea903ed27f61612f56
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Foundation new releases question

[Anthony Martin]

Ethan Gardener  once said:
> the later breaking change to 9p auth

Which change was that?

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc472e4a0c0b6f084-M5a6466d3fd80eaa026b0f9dc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9P reading directories client/server behavior

[Anthony Martin]

nicolagi via 9fans <9fans@9fans.net> once said:
> The only question that still stands is the last in my original post:
> What happens and what should happen when a dir entry is larger than
> msize-24? Possibly written from a connection with a large msize, and to
> be read from a connection with a smaller msize?

In that case either the server or client lied about it's
msize and is not correctly speaking the 9p protocol.

>From version(5):

The client suggests a maximum message size, msize, that is
the maximum length, in bytes, it will ever generate or ex-
pect to receive in a single 9P message. This count includes
all 9P protocol data, starting from the size field and ex-
tending through the message, but excludes enveloping trans-
port protocols. The server responds with its own maximum,
msize, which must be less than or equal to the client's
value. Thenceforth, both sides of the connection must honor
this limit.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42be63e964005519-Mcceb79ab7dadcad157ebec8a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: 9p(2) and walk1

[Anthony Martin]

pouya+lists.9f...@nohup.io once said:
> Are these subtle differences (the two in the man page and the third in
> code) intentional?  It's my first time implementing a 9P file system
> so apologies if I'm missing something basic.

It's actually just a case of forgetting to update the man page.

In early February 2003, Russ was cleaning up lib9p and changed
the code to check that fid->qid and qid were exactly the same.
He updated the man page accordingly. However, Dan Cross noticed
that it broke some existing code. Russ then relaxed the client
requirements and had lib9p just assign qid to fid->qid. The man
page wasn't updated to reflect the change.

To: 9f...@cse.psu.edu
Subject: Re: [9fans] Okay, who's been playing with the cheese wiz?
From: "Russ Cox" 
Date: Sun, 9 Feb 2003 16:51:01 -0500
Message-ID: 

[...]

I changed lib9p to do a few more checks that the
client code is behaving, and your execnet crash
shows that lib9p thinks execnet is not behaving.
It turns out that actually lib9p is not behaving -- I was
trying to clean up this particular detail (whether a
walk function should set both fid->qid and *qid),
because it always confuses me, and I got confused.
I just put out a new srv.c that makes reasonable
demands of the clients.

[...]

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb39d71a5497bba2d-M26c5e627eb106c505ce67b9b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] patches from 9front

[Anthony Martin]

Lucio De Re  once said:
> the fact that we have different objectives needs to be addressed at a
> philosophical level. How else are we going to select from conflicting
> alternatives?

Let a hundred flowers blossom.

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc82939f1fda0e479-M2baac72ee9a9151a70895833
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: Plan 9 Foundation

[Anthony Martin]

Anthony Sorace  once said:
> Collier

Can *I* buy a vowel?
Not this one but another,
Here and on the site.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T973ff41a99053355-M99db8eabd2cbcc95399a1d53
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: cfs

[Anthony Martin]

Steve Simon  once said:
> The error occurs on the first write to /srv/boot.
>
> I can mount /srv/boot with mount(1) without problems.
>
> What have I missed?

The kernel doesn't allow you to explicitly read from
or write to a channel that the mount driver is using.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1ff0c2bf191f9858-M7fb63cb25344ad05f23cbacd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] brazil ip stack source code

[Anthony Martin]

Does anyone have a copy of the alef source code
for the user mode ip stack that was in brazil?

Maybe you could leave it hanging off the back of
your truck? Or swap it for beer?

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T441f146d3d267e35-Md5eccd8c364f7527e532a87f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Arm Thumb compiler for Cortex-M

[Anthony Martin]

While we're asking questions, how does utils/tl differ from utils/5l?

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc22ac8ae61456f10-M2563a68e7482ebdc4221b9cc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: /proc/n/status's memory field

[Anthony Martin]

Kyohei Kadota  once said:
> I'm reading proc(3). It describes the status file:
> 
> > the amount of memory used by the process, except its stack, in units of 
> > 1024 bytes
> 
> In /sys/src/9/pc/port/proc.c, it seems to me that procread sums all
> segment's size for that.
> Is the above statement correct?

The Labs kernel loops over [1,NSEG) to sum the segment sizes.
The index of the stack segment, SSEG, is zero so it is skipped.
This measurement is the total virtual address space in use by
the process minus the stack.

The 9front kernel loops over [0,NSEG) to scan the virtual page
table of each segment for used pages, summing as it goes. This
measurement is the total amount of memory in use by the process.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc2c9fe27a3a2dd4c-M9bf220c6eb9f6bf0e10d813e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Acme fonts

[Anthony Martin]

[cc -golang-nuts, +9fans]

> io/fs draft design
>  - Video: https://golang.org/s/draft-iofs-video

Russ, what did you do to that poor little Acme?! ☺

Did you take the less daunting route using

 - a combined font file with shapes for normal, italic, bold, etc. and
 - a filter to offset runes into "planes" for each font shape?

Or did you modify Acme to support some sort of rich text mark-up?

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9673b88bfb3c3d3b-M0780616af05536293a1a676c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: which programs use dynld(2)?

[Anthony Martin]

It's used to load kernel modules in Inferno.

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbca49dda768294c8-M772b5be61791472285ed70f5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: Jim McKie

[Anthony Martin]

echo farewell | uux - mcvax!rmail jim

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td73b359f9dc68c15-Ma03ae3c659754b5ea2bebdb8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Gmail vs upas

[Anthony Martin]

o...@eigenstate.org once said:
> Unrelatedly, would there be interest in adding the `$split{cmd} syntax
> from 9atom to 9legacy?  I think it's currently the only reason that
> git9 doesn't work out of the box there, and it's very nice syntax.

I'm not a fan of the `word{...} syntax. It's odd to
allow a word in the middle of a syntactic form like
that. I can't think of any other part of rc(1) that
does that. Is there any?

I used to use a pair of functions named pushifs and
popifs to easily control backquote tokenization but
over time I realized that I only used them when I
wanted no tokenization at all, with $ifs set to ''
or '\n'.

So I ported the "{...} mechanism from mash(1) to my
local copy of rc(1) and haven't looked back since.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te20476748ab5e4ba-Ma8334ad7af705f12f900f6e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Anthony Martin]

Ethan Gardener  once said:
> As for the footer, I'm sure I'll be glad to have the permalink in every
> email, and it's not in the headers.
>
> [...]
>
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-M377ada983df012733fe78595

It is in the headers:

Archived-At: 


  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-Med45876a99f665e39b83bd76
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Anthony Martin]

Anthony Martin  once said:
> This is missing the dozen or so messages from the beginning of the
> mailing list in April 1993. I have them in mbox format if you are
> interested in adding them to your archive.

Also, the following messages in the Topicbox archive are duplicates.
They are identical except for an empty "Cc" header on the first one.

https://9fans.topicbox.com/groups/9fans/Td304f708de7d8d92-M42f72ee9d5148680750dc274/9fans-attention-new-list-address
https://9fans.topicbox.com/groups/9fans/Td304f708de7d8d92-Mc7db8bc68d73a0e7bf287d33/9fans-attention-new-list-address

This was the first message after the switch from psu.edu to 9fans.net.

Just checking edge cases. ☺

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-M54add7534b3e2e76b3148e17
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Anthony Martin]

hiro <23h...@gmail.com> once said:
> there's also a plaintext version of this, adding 5 lines to every
> email. all this seems quite redundent if you ask me.

And it's all in duplicated in the headers.
Can it be turned off?

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-Mc63130c53c7ccb1eb552eb60
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Anthony Martin]

Russ Cox  once said:
> The 9fans archives  now
> hosted at Topicbox contain all the messages formerly at
> 9fans.net/archive (before that machine went down), dating all the way
> back to July 1993.

This is missing the dozen or so messages from the beginning of the
mailing list in April 1993. I have them in mbox format if you are
interested in adding them to your archive.

  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-Mfd66fd44927b59d431c422bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Anthony Martin]

Richard Miller <9f...@hamnavoe.com> once said:
> I see the above list uses .e and .j for riscv and riscv64 -
> are these just reserved or are there actual compilers somewhere?

No, it was just a suggestion on my part. If I remember correctly,
I thought it was mildly clever that 'e' is the fifth letter in the
English alphabet and 'j' is five letters after that.

I'm only aware of your riscv compiler.

  Anthony

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Anthony Martin]

Charles Forsyth  once said:
> I'd need a letter or number and thought about reusing x (xa/xc/xl) since
> the AT DSP is long gone

https://github.com/0intro/plan9-mips/tree/master/sys/src/cmd/4c
https://github.com/0intro/plan9-mips/blob/master/rc/bin/xc

I think I sent this to the list once before but here's a table that I made
a while back.

https://www.pbrane.org/comp.html

The number 3 is free.

Cheers,
  Anthony

[9fans] nCUBE, Transit, and Plan 9

[Anthony Martin]

mycrof...@sphericalharmony.com once said:
> Most recently, I have been pursing historical investigation and
> recreation of systems based on the hypercubic computers which rose to
> prominence in the late 1980s.  Most interesting (to me) are the
> systems from nCUBE, which transitioned during the 1990s to a Plan 9
> based (!) operating system called Transit which was used for streaming
> video appliance servers such as the Mediacube 4.  I am very very
> interested in the Transit OS and this history, and I can find almost
> no substantive information about the Transit variant of Plan 9,
> although information on the earlier generation of nCUBE systems is
> fairly plentiful.

I'm also interested in this. I tracked down some current email addresses
for some of the nCUBE people who posted to 9fans in the '90s.

Greetings to Stephen, Vadim, and Alberto.

Would you be willing to indulge us with some historical information on
how Plan 9 was used and modified by nCUBE and what became of the Transit
operating system?

Thanks,
  Anthony

Re: [9fans] Don't Plan 9 C compiler initialize the rest of member of a?struct?

[Anthony Martin]

Charles Forsyth  once said:
> I didn't look at the code closely enough earlier, but remembered something
> from years ago this morning. It's a bug. It isn't platform specific.
> There is an existing fix in 9front (I think it came from there) but it's
> horrible. Still, better a horrible fix than buggy code, so I'll apply it to
> the 9legacy version as well.

It's in /sys/src/cmd/cc/dcl.c:/^contig

What was horrible about the fix? 

  Anthony

Re: [9fans] How does one read a file line by line in an rc script?

[Anthony Martin]

Mack Wallace  once said:
> Another, probably more stupid question - How does one read a text file
> line by line in an rc script.

You should really read the rc(1) man page. It will answer your
questions.

Here the functions foo and bar are equivalent:

fn foo {
<$1 while(l = `{read}) echo $l
}

fn bar {
{ while(l = `{read}) echo $l } <$1
}

Think about why this one is not like the others:

fn baz {
while(l = `{read}){ echo $l } <$1
}

Cheers,
  Anthony

Re: [9fans] rc scripts, how to get spaces in array elements generated by command output?

[Anthony Martin]

Mack Wallace  once said:
> My question: Is there a way to take the string output of a command that
> contains spaces and make it a single element of an array in rc script?
>
> [...]
> 
> However, if I am receiving output from sed that contains spaces from
> the following script line
> 
> string_var = `{echo some_string | sed ’s/x/y/g’}
> 
> If the output was ‘hello world’, string_var would become a two
> element array which
> echo $some_string(1) 
> echo $some_string(2)
> 
> Would output 
> hello
> world

You need to change the input field separator, $ifs.

The default value is any whitespace character:

% x = `{echo -n hello world}
% echo $#x
2
% echo $x(1)
hello
% echo $x(2)
world

Using only newline as the separator yields:

% ifs = '
' # this is a newline character
%   y = `{echo -n hello world}
% echo $#y
1
% echo $y(1)
hello world

You might want to use a comma instead:

% ifs = ,
% z = `{echo -n hello world,good luck}
% echo $#z
2
% echo $z(1)
hello world
% echo $z(2)
good luck

Cheers,
  Anthony

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

[Anthony Martin]

Richard Miller <9f...@hamnavoe.com> once said:
> How about i for rIscv32 and j for riscv64 (one more than i)?

Or even e for riscv since it's the fifth letter in the alphabet. :)
Let me know what you decide and I'll update my table.

> I used n for nios2.  na and aux/na commands are distinct, and
> I wouldn't expect SYM53C8XX microcode and nios2 object code
> to appear in the same context.

That works but be careful running clean in /sys/src/9/pc after adding
the n letter to $OS in /sys/src/mkfile.proto. It will blow away the
sd53c8xx.n file and you'll have to get it from the dump. That file is
now named sd53c8xx.na over here.

  Anthony

Re: [9fans] Plan 9 C compiler for RISC-V by Richard Miller

[Anthony Martin]

Charles Forsyth  once said:
> I had a chart somewhere with the available non-unicode letters.

I made one a few years ago. It's at http://pbrane.org/comp.html

I just updated it with a suggestion for the RISC-V letters.

  Anthony

Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?

[Anthony Martin]

Note that variables in the Mashey shell were single letters
in lower-case. $p was similar to $PATH in the Bourne shell.

Maybe Tom just split the difference. Have you asked him? :)

  Anthony

Re: [9fans] A heartfelt thanks... :-)

[Anthony Martin]

Ciao Giacomo,

Why did you choose to create devself? Everything it does seems
better suited to devproc. If I was going that route, I'd instead
create a QTDIR file in devproc called #p/self that is just another
view into #p/$pid. Then brk and chdir would be control messages
written to #p/self/ctl. Same with seg^(attach detach free). You
could also make those be control messages written to #p/self/segment
instead.

Also, I think it's a mistake to overload the return value of the
remove system call for passing arbitrary integers out of the kernel.
I understand why you want something like that, however. Moving
system calls into reads and writes of various files increases the
number of context switches since you have to open and close the
files. Why not do exactly what you want and make a new system
called readint or something?

Oh, and where are the man pages? /doc/hacking is missing. I'm
interested in reading about your awake system call and the changes
you've made to rendezvous and the variuos locks in libc.

Cheers,
  Anthony

Re: [9fans] Namespace inheritance between processes

[Anthony Martin]

Anthony Martin <al...@pbrane.org> once said:
> Casey Rodarmor <ca...@rodarmor.com> once said:
> > Also, whatever the answer is, how can I test this for myself? I was
> > struggling to come up with a combination of commands, short of writing
> > some C programs, which would let me have two interactive rc shells
> > that inherit from one another, since rc doesn't have job control and
> > new rio windows are in a new process group.
> 
> In one rio window, do the following:
> 
>   % mkdir -p /tmp/wsys
>   % mount $wsys /tmp/wsys 'new -r 0 0 512 512 -pid '$pid
>   % { rc -i <>/tmp/wsys/cons >[1=0] >[2=0] } &
> 
> Any further changes to the namespace will be reflected in both windows.

I was playing around with this a bit more and I came
up with something a bit cleaner. The following command
will create an interactive shell in a new window that
shares the namespace of it's parent and acts like a
normal rio window (as much as possible).

Cheers,
  Anthony

#!/bin/rc

rfork e

mkdir -p /tmp/wsys
mount $wsys /tmp/wsys 'new -r 0 0 640 480 -pid -1'
{
rc -i /tmp/wsys/cons >[2=1] &
rcpid = $apid
echo set -pid $rcpid >/tmp/wsys/wctl
echo -n rc $rcpid >/tmp/wsys/label
wait $rcpid
echo delete >/tmp/wsys/wctl
} &

Re: [9fans] Namespace inheritance between processes

[Anthony Martin]

Casey Rodarmor  once said:
> > Let's say I have a process A which forks a child process B with the
> > RFNAMEG so it receives a copy of A's namespace.
> >
> > If process A then makes a change to its namespace, will process B see
> > that change? Or does B receive a distinct copy that A then can't
> > change?

The latter. B won't observe any namespace changes made by A.

> Also, whatever the answer is, how can I test this for myself? I was
> struggling to come up with a combination of commands, short of writing
> some C programs, which would let me have two interactive rc shells
> that inherit from one another, since rc doesn't have job control and
> new rio windows are in a new process group.

In one rio window, do the following:

  % mkdir -p /tmp/wsys
  % mount $wsys /tmp/wsys 'new -r 0 0 512 512 -pid '$pid
  % { rc -i <>/tmp/wsys/cons >[1=0] >[2=0] } &

Any further changes to the namespace will be reflected in both windows.

Cheers,
  Anthony

Re: [9fans] bug or feature ? --- ip/ping -6

[Anthony Martin]

erik quanstrom  once said:
> unfortunately, the simlification removes the code that solves an important
> use case.  it's important to be able to specify the protocol or network stack,
> such as in
> 
>   ip/ping /net.alt/icmp!someaddress

Most commands use an -x option and setnetmtpt(2) to arrange
an alternate network root. Is there any reason not to do the
same for ip/ping?

  Anthony

Re: [9fans] bug or feature ? --- ip/ping -6

[Anthony Martin]

arisawa  once said:
> is this a feature or a bug?

It looks like a bug to me. The code in

  /sys/src/cmd/ip/ping.c:/^isv4name

is too clever for it's own good.

  Anthony

Re: [9fans] Small Plan 9 Platforms

[Anthony Martin]

hiro 23h...@gmail.com once said:
 Also, crazy closed firmware blobs is a violation of our COC. Some
 people here develop firmware blobs and don't want to hear such
 insults.

It says more about you that you're insulted by something so innocuous.

Email me privately if you'd like some real insults.

Cheers,
  Anthony

P.S. Stop writing closed firmware blobs.

[9fans] Why does pread(2) modify the channel offset?

[Anthony Martin]

During the investigation of a failure in the Go test suite,
I was led to the following question:

  Why does pread(2) modify the channel offset?

When pread and pwrite were added to the kernel in Feb 2001,
neither of them modified the underlying channel offset for
a given file descriptor. This was also the behavior when the
4th Edition was released. Fast forward to a year later in
May 2003. The code was reorganized slightly and pread began
modifying the channel offset.

I think this change was inadvertent because pwrite remained
the same (i.e. not modifying the offset) and because it means
that you can't mix calls to read and pread on the same file
descriptor without confusion. Mixing calls is very uncommon,
though, so nobody noticed at the time. A new test was added
to the Go test suite that does this and it instantly caused
the Plan 9 builder to fail.

I've attached a small program that shows the problem. It's
output looks like this:

  % 8c -FTVw test.c  8l -o test test.c
  % ./test
  0: init   - offset = 0
  1: write 1- offset = 1
  2: pwrite 1 0 - offset = 1
  3: seek 0 - offset = 0
  4: read 1 - offset = 1
  5: pread 1 0  - offset = 2
  %

The pread in step five clearly affects the file offset.

However, the documentation gives the impression that both
pread and pwrite should update the channel offset. Note the
first sentence in the following passage from pread(2):

  Pread and Pwrite are equivalent to a seek(2) to offset fol-
  lowed by a read or write.  By combining the operations in a
  single atomic call, they more closely match the 9P protocol
  (see intro(5)) and, more important, permit multiprocess pro-
  grams to execute multiple concurrent read and write opera-
  tions on the same file descriptor without interference.

That leaves us with two options:

  1. the docs are correct and pwrite is wrong, or

  2. the docs are incorrect and pread is wrong.

I think the latter is more likely. (Note, also, that all of
the modern Unix variants have APIs that assume the offset
is unchanged after a pread or pwrite).

Thoughts?

  Anthony
#include u.h
#include libc.h

void
run(int step, int fd)
{
vlong ret, off;
char buf[1], *msg;

msg = nil;
switch(step){
case 0:
ret = 0;
msg = init;
break;
case 1:
ret = write(fd, buf, 1);
msg = write 1;
break;
case 2:
ret = pwrite(fd, buf, 1, 0);
msg = pwrite 1 0;
break;
case 3:
ret = seek(fd, 0, 0);
msg = seek 0;
break;
case 4:
ret = read(fd, buf, 1);
msg = read 1;
break;
case 5:
ret = pread(fd, buf, 1, 0);
msg = pread 1 0;
break;
}
if(ret == -1)
sysfatal(%s failed: %r, msg);
off = seek(fd, 0, 1);
if(off  0)
sysfatal(seek failed: %r);
print(%d: %-10s - offset = %lld\n, step, msg, off);
}

char *tmpfile = /tmp/foo.6e907b64;

void
main(void)
{
int fd, i;

if((fd = create(tmpfile, ORDWR, 0600))  0)
sysfatal(create failed: %r);
for(i = 0; i = 5; i++)
run(i, fd);
close(fd);
if(remove(tmpfile)  0)
sysfatal(remove failed: %r);
}

Re: [9fans] GO Programming Environment in Plan 9.

[Anthony Martin]

minux minux...@gmail.com once said:
 On Nov 30, 2014 3:10 PM, Mats Olsson plan9@gmail.com wrote:
  Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
 
  So it seems that it's supported.
 go on arm only supports Linux, Freebsd, Netbsd, nacl and Darwin
 (unofficial).
 
 plan 9 is not on the list (yet).

By my estimate, it would be a few days work. Even less
after some simplifying changes I want to make to the
runtime and syscall packages (like removing superfluous
differences between 386 and amd64, etc.).

We're all just waiting for the tree to open up again.

If someone volunteers to run a plan9/arm builder, I'll
do the port and have it in by the 1.5 release. ☺

Cheers,
  Anthony

Re: [9fans] GO Programming Environment in Plan 9.

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
  We're all just waiting for the tree to open up again.
 
 i thought that was the promise of dcs -- you don't have to wait.
 where did this whole thing fail?

Well, I really meant we're waiting for the point in the
development schedule that allows new code to be up for
review.

Of course, we can (and do) develop on personal branches.

  Anthony

Re: [9fans] Setting up Mail in Acme on the Raspberry Pi.

[Anthony Martin]

Richard Miller 9f...@hamnavoe.com once said:
 - finally, after receiving a Google Account: sign-in attempt blocked
 email from google, followed their suggestion to:
 
 change your settings at  
 https://www.google.com/settings/security/lesssecureapps so that your  
 account is no longer protected by modern security standards.
 
 I guess upas/smtp is considered a less secure app.

Embrace, extend, and ... well, you know the rest.

http://forums.mozillazine.org/viewtopic.php?f=39t=2852231

  Anthony

Re: [9fans] kernel bug

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 i don't know where a history of stuff older than sources (2002) is.

/n/sources/extra/9hist

  Anthony

Re: [9fans] kernel bug

[Anthony Martin]

Yoann Padioleau p...@fb.com once said:
 in the newseg() function there is:

 [...]

 I think it should be
 if(mapsize  (SEGMAPSIZE))
 mapsize = SEGMAPSIZE;

Yes, you're correct.

The code allows the creation of a segment VM map with more
than SEGMAPSIZE Ptes.

Personally, I'd remove the check entirely along with the
optimization of doubling the segment size, perhaps moving
it to ibrk. I think it's more likely that the segment will
grow if brk is called at least once.

  Anthony

P.S. It looks like this is a 15 year old bug:

1998/0916/sys/src/9/port/segment.c:62,67 - 
1998/0919/sys/src/9/port/segment.c:62,70
  
mapsize = ROUND(size, PTEPERTAB)/PTEPERTAB;
if(mapsize  nelem(s-ssegmap)){
+   mapsize *= 2;
+   if(mapsize  (SEGMAPSIZE*PTEPERTAB))
+   mapsize = (SEGMAPSIZE*PTEPERTAB);
s-map = smalloc(mapsize*sizeof(Pte*));
s-mapsize = mapsize;
}

Re: [9fans] Go 1.3b1 cmd/pack test takes too long

[Anthony Martin]

Skip Tavakkolian skip.tavakkol...@gmail.com once said:
 thanks; i should have checked that. running it on the fossil+venti server
 brings it down a bit. still, it's not stellar.
 
 bootes% go test
 PASS
 ok   cmd/pack 81.480s
 bootes% go test
 PASS
 ok   cmd/pack 79.719s

Here's a CL to buffer the writes in TestLargeDefs:

https://codereview.appspot.com/95040044

Cheers,
  Anthony

Re: [9fans] Go 1.3b1 cmd/pack test takes too long

[Anthony Martin]

Skip Tavakkolian skip.tavakkol...@gmail.com once said:
 is anyone else seeing similar results for cmd/pack?
 
 % go test
 PASS
 ok   cmd/pack 172.505s
 
 this is on an atom (d525 @ 1.8ghz, 4gb). same test on an arm (quad core a9
 @ 1.7ghz, 2gb, linux 3.8) takes much less time:
 
 % go test
 PASS
 ok  cmd/pack20.872s

Your numbers don't look entirely abnormal. That test issues
over a million small writes. (Although it really should be
using bufio).

How is your system set up? Are you getting your fs from
the network? The Plan 9 disk file systems are pretty slow
even when used locally.

  Anthony

Re: [9fans] imagereclaim()

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
 I also ripped out all the swap stuff. Either I'm on a machine with at last
 a Gb or two of RAM, or it's embedded
 and there's no paging disk, or both.

What do you do when you're out of memory? Panic?
Do you still have something like the kickpager in
nix?

  Anthony

Re: [9fans] 9front sleep interrupted in kproc?

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 since kprocs don't get notes (it's an error to write to the note file),
 sleep in a kproc can't get interrupted.  this code will never fire.

It looks like they can on 9front.

The following is from pc/vgavesa.c:/^vesaproc

/*
 * dont wait forever here. some BIOS get stuck
 * in i/o poll loop after blank/unblank for some
 * reason. (Thinkpad A22p)
 */
procalarm(1);

Cheers,
  Anthony

Re: [9fans] 9front sleep interrupted in kproc?

[Anthony Martin]

Anthony Martin al...@pbrane.org once said:
 erik quanstrom quans...@quanstro.net once said:
  since kprocs don't get notes (it's an error to write to the note file),
  sleep in a kproc can't get interrupted.  this code will never fire.
 
 It looks like they can on 9front.

Actually, this isn't just 9front. All of the network
medium receive kprocs (e.g., etherread4) can be sent
notes (only by the kernel, of course).

  Anthony

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Anthony Martin]

Skip Tavakkolian skip.tavakkol...@gmail.com once said:
 is this the patch set you're referring to?
 https://codereview.appspot.com/download/issue9796043_58001.diff
 
 if so, is there a diff set for go1.2?

Hi Skip,

There were a few problems with that CL that I'm just now
starting to iron out so I extracted out the memmove fix
into a separate CL.

The patch sets that you'll need to build Go 1.2 on Plan 9 are:

cmd/8g: work around 64-bit bug in 8c for Plan 9
https://codereview.appspot.com/14521056

build: do not use the host's libbio on Plan 9
https://codereview.appspot.com/14604047

runtime: do not use memmove in the Plan 9 signal handler
https://codereview.appspot.com/34640045

The Go tree is still in a code freeze but I'll have those
CLs submitted as soon as it reopens.

Also, we have three months (until the Go 1.3 code freeze) to
get the Plan 9 port passing all tests on the build dashboard
or it will have to move outside the main repository:

https://code.google.com/p/go-wiki/wiki/PortingPolicy

If you want to help with this effort, please join the go-plan9
mailing list (https://groups.google.com/d/forum/go-plan9).

Cheers,
  Anthony

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Anthony Martin]

erik quanstrom quans...@labs.coraid.com once said:
 On Mon Dec  2 10:01:48 EST 2013, lu...@proxima.alt.za wrote:
   is the threat standing?  that is, if the plan 9 port is broken again
   when 1.5 rolls around in just a few more months, does the plan 9
   port get booted then, too?
  
  The threat is real: Plan 9 is a burden for the developers and lack of
 
 perhaps we're seperated by a common language.  standing in the sense
 that for each new release does the same condition hold: if it does not
 pass all the tests, it is evicted from the main line.

Yes. The relevant statement from the new policy is:

If a builder fails for more than four weeks or is failing at the time
of a release freeze, and a new maintainer cannot be found, the port
will be removed from the tree.

Due to backwards compatibility concerns, removing a formerly working
port should be a last resort. Finding a new maintainer is always
preferable.

As of now, both Aram and I are willing to be active maintainers.
(He's just finishing up the Solaris port).

  The solution is not with open source but with rolling up one's
  sleeves and figuring out how to converge as much as possible the
 
 given that most of the time is spent bailing water out of the boat,
 and fixing things that weren't previously broken, it seems to me that
 like anything it's a two-way street.
 
 anyway, what's the argument for not just forking?

I think forking would actually *increase* the maintenance burden
for us, assuming we want to keep up with point releases.

We would still have to track the changes from upstream and we'd
no longer even be on the Go team's radar. This would naturally 
result in more Unix-based assumptions that we'd have to deal with.

For example, I've seen many examples of code that calls certain
functions in the syscall package and just assumes that, e.g.,
Getrusage is defined everywhere. This is even present in the
new Go Performance Dashboard code (written by the Go team).

  Anthony

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Anthony Martin]

Steve Simon st...@quintile.net once said:
 Whne I looked at Go - maybe 2 years ago, I could not see why
 plan9 would not adopt go's 8c/8l and libbio.
 
 obviously others disagree as they have not been back-ported,
 but why not? - I'am not trolling, genuine question.

We couldn't adopt the Go ?[acl] toolchain wholesale
because of incompatible Go-specific changes; e.g.,
disallowing variadic C functions without a #pragma
annotation, a different symtab/pclntab format, etc.

It would take a fair bit of work to make everything
(including libmach) backwards-compatible.

  Anthony

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
  2. Use of Go's libbio, rather than Plan 9's. Alternatively libbio on Plan 9
  can be changed. It's not clear to me why this would be a bad thing.
 
 i object to the macros they have been adding.  they haven't been included
 in p9p, either.  adding B(put|get)(le|be)(Biobufhdr *b, int width) might
 be an interesting convienence, but what they've got for the sake of 1% on
 micro benchmarks seems to run counter to the plan 9 culture to me.

The claim was a bit stronger than that:

https://code.google.com/p/go/source/detail?r=1ee3ab13e3b6

but I still agree with you.

  Anthony

Re: [9fans] Building Go/386

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 since even ghostscript doesn't get into this state, i'd be interested
 in the line of code (and types of the variables) that hits this fatal
 condition.

I posted a small piece of code that triggers this on golang-dev.

Here it is:

% cat x.c
unsigned long long x;

int f(int);

void
test(void)
{
int a;

a = f(a-x+a);
}
% 8c x.c
8c 98: suicide: sys: trap: fault read addr=0x0 pc=0x0003712f
%

Cheers,
  Anthony

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Anthony Martin]

cinap_len...@gmx.de once said:
 or GO could just stop using *OMG-OPTIMIZED* SSE memmove()
 in the note handler.

This is exactly what I did in my patch. This was just
a regression. Someone changed memmove a few weeks ago.

Nothing to see here.

  Anthony

Re: [9fans] 21-bit runes

[Anthony Martin]

Thank you. I very much appreciate the work that went into this.

And thanks to Erik for his previous set of patches.

  Anthony

Re: [9fans] open file in awk script?

[Anthony Martin]

dexen deVries dexen.devr...@gmail.com once said:
 trying to create a standalone awk script (#!/usr/local/plan9/bin/awk -f).
 
 how to open a file in BEGIN pattern section and set it as next input file?
 
 not helped so far: FILENAME=foo.txt
 nor ARGV[1]=foo.txt; nextfile;

ARGV[ARGC++] = foo.txt

  Anthony

Re: [9fans] going too far?

[Anthony Martin]

lu...@proxima.alt.za once said:
 I think the Go tool does cover C programs and even (somebody will
 correct me if I'm wrong, I hope) assembler ones.  It would be silly if
 it didn't, or at least hard to use for things like the runtime.  One
 of Go's weak spots is that a lot of unconventional behaviour is poorly
 documented.  But I'm sure third party documentation will come soon.

This is correct. The go tool supports files with an
extension matching (go|[chsS]|swig(cxx)?|syso).

For .go files, each file is read until the end of the
import declarations.

For everything else (except .syso), each file is read
to determine the build constraints. The rules for these
are explained here

http://golang.org/pkg/go/build/#hdr-Build_Constraints

Files with the extension .syso are not read by the
go tool. They're opaque externally-generated blobs
that are simply added to the archive before linking.

  Anthony

Re: [9fans] ASCII character conversion program in assembler

[Anthony Martin]

I have a few suggestions and corrections.

1. You have to actually allocate space for your local variables.
   This means either calculating how much space you'll need and
   annotating the TEXT pseudo-instruction or decrementing the SP
   as you go.

2. Calls into the kernel must look like normal calls. When writing
   in C, libc takes care of this for you. In assembly you have to
   do it yourself. There are two ways to do this: define a procedure
   and call it or push a fake return address onto the stack. I see
   you've chosen the latter but the former would make the code read
   nicer.

3. There's no need to but the buffer in the data section. It can
   be a local variable. See point 2.

4. The pread(2) system call takes a 64-bit offset like pwrite(2).

5. There's no need to define a procedure called main. The linker
   doesn't care as long as your code starts at _main.

6. Since you're using the address of the buffer quite frequently,
   your program will read better if you store it in a register.

7. It helps to pass informative error strings to exits(2).

I've attached a program that accomplishes the same task.

Cheers,
  Anthony
#define STDIN  0
#define STDOUT 1
#define EOF0

#define BUFSIZE4096
#define BUFOFFSET  20

#define SYS_EXITS  8
#define SYS_PREAD  50
#define SYS_PWRITE 51

TEXT _main(SB),$(BUFSIZE+BUFOFFSET)
LEALBUFOFFSET(SP), SI

read:
// read into the buffer from stdin.
MOVL$STDIN, 0(SP)
MOVLSI, 4(SP)
MOVL$BUFSIZE, 8(SP)
MOVL$-1, 12(SP)
MOVL$-1, 16(SP)
CALLpread(SB)
CMPLAX, $EOF
JLE exit

// call conv to transform lowercase ASCII to uppercase.
MOVLSI, 0(SP)
MOVLAX, 4(SP)
CALLconv(SB)

// write the potentially modified buffer to stdout.
MOVL$STDOUT, 0(SP)
MOVLSI, 4(SP)
MOVLAX, 8(SP)
MOVL$-1, 12(SP)
MOVL$-1, 16(SP)
CALLpwrite(SB)
CMPLAX, 8(SP)
JEQ read
MOVL$writefail(SB), 0(SP)
CALLexits(SB)

exit:
JEQ 3(PC)
MOVL$readfail(SB), 0(SP)
CALLexits(SB)
MOVL$0, 0(SP)
CALLexits(SB)
RET

// void conv(char *buf, int n)
TEXT conv(SB), $0
MOVLbuf+0(FP), SI
MOVLn+4(FP), AX
MOVL$0, CX
CMPLCX, AX
JGE done
loop:
MOVB(SI)(CX*1), BL
CMPBBL, $'a'
JLT 5(PC)
CMPBBL, $'z'
JGT 3(PC)
SUBB$0x20, BL
MOVBBL, (SI)(CX*1)
INCLCX
CMPLCX, AX
JLT loop
done:
RET

// void exits(char *status)
TEXT exits(SB),$0
MOVL$SYS_EXITS, AX
INT $64
RET

// int pread(int fd, char *buf, int n, vlong off)
TEXT pread(SB),$0
MOVL$SYS_PREAD, AX
INT $64
RET

// int pwrite(int fd, char *buf, int n, vlong off)
TEXT pwrite(SB),$0
MOVL$SYS_PWRITE, AX
INT $64
RET

GLOBL   readfail(SB),$13
DATAreadfail+0(SB)/8, $read fai
DATAreadfail+8(SB)/5, $lure\z

GLOBL   writefail(SB),$14
DATAwritefail+0(SB)/8, $write fa
DATAwritefail+8(SB)/6, $ilure\z

Re: [9fans] Go: CGO and Plan 9

[Anthony Martin]

Aram Hăvărneanu ara...@mgk.ro once said:
 ?c and ?g use the same calling convention, and segmented stacks are
 implemented by the linker. You don't need cgo in order to call C code
 from Go. Why do you want cgo?

This isn't true. Most of the Plan 9 compilers will pass the
first function argument in a register (not including 8c) and
return the result in a register (including 8c).

The C compilers in the Go toolchain pass everything on the
stack and return the result in a register.

The Go compilers pass everything on the stack including the
output parameters. No registers are involved in the calling
convention.

Another difference is in C is variadic functions in the face
of segmented stacks. The C compilers in the Go toolchain will
not compile a variadic function without a NOSPLIT annotation.
And even then, only if the resulting stack frame is small.

 Look at the various C files in the Go standard library, especially
 inside runtime. Those are compiled with the Plan 9 compiler and Go
 calls it just fine.

They're also careful not to validate the above assumptions
and they do not include any outside header files.

The right way to solve this problem is to modify cgo. I just
haven't had the time.

Cheers,
  Anthony

[9fans] maxround and stack frame sizes

[Anthony Martin]

I'm curious about the origins of the maxround
function in the compilers. Specifically, why is
5c different from all the others?

It seems the common implementation gives rise
to unnecessarily large stack frames.

For convenience:

/sys/src/cmd/6c/swt.c:/^maxround
/sys/src/cmd/5c/swt.c:/^maxround
/sys/src/cmd/cc/dcl.c:/^adecl

Thanks,
  Anthony

Re: [9fans] 9atom-nix

[Anthony Martin]

This is really great. Thanks for all your work, Erik.

  Anthony

[9fans] what is the frequency, kenneth?

[Anthony Martin]

What's the story behind the curious reference
to this phrase in the code for timesync(8)?

Who wrote this code? presotto?

It's rather funny.

  Anthony

Re: [9fans] 9vx and Go

[Anthony Martin]

lu...@proxima.alt.za once said:
  Yes, the tsemacquire syscall is not currently implemented in 9vx.
 
 The ticks field is also not present in the mach structure, so adding
 tsemacquire isn't trivial.  I was hoping to get away with just adding
 the field, but if the comment is correct, I need at minimum to add
 code to keep the ticks up to date and I can't seem to find model code
 in Plan 9 to do it.  I guess I'm drowning...

I have a few patches to support Go in my vx32 tree.
I've made lots of other changes so it might take me
a while to get a clean patch to David.

For tsemacquire, you can just s/m-ticks/msec()/.

There's also a few instructions (MOVQ, EMMS, etc.)
that have to be added to libvx32/emu.c since the Go
runtime and standard library use them.

Cheers,
  Anthony

Re: [9fans] why is /dev/mousein exclusive use?

[Anthony Martin]

Richard Miller 9f...@hamnavoe.com once said:
 Is there a good reason to forbid multiple processes to open
 the mousein device?  I can't think what trouble it could cause
 (writes have to be atomic anyway because the driver will only
 parse a complete input), and it makes it awkward to debug
 a new mouse driver if a usb mouse is already (or has ever been)
 connected.

IIRC, this restriction was removed in 9front.

  Anthony

Re: [9fans] 9vx and Go

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
 MOVQ isn't a 32-bit instruction.

It is if you're using MMX registers.

  Anthony

Re: [9fans] 9vx and Go

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 On Mon Dec 10 19:11:39 EST 2012, al...@pbrane.org wrote:
  Charles Forsyth charles.fors...@gmail.com once said:
   MOVQ isn't a 32-bit instruction.
  
  It is if you're using MMX registers.
 
 does 8g default to using mmx?

No. They're written using BYTE instructions where needed.

Currently 8g will only generate 387 style fp code but the
is to eventually use SSE. See http://golang.org/issue/3912.

  Anthony

Re: [9fans] 9vx and Go

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
  No. They're written using BYTE instructions where needed.
  
  Currently 8g will only generate 387 style fp code but the
  is to eventually use SSE. See http://golang.org/issue/3912.
  
 
 that's not what i read.  i read that it's going to be a compile-time
 option.  surely they're not sneaking xmm in the side door.

Sort of. The plan is to use SSE by default but use an
environment variable (and compiler flag) to disable it.

This is how it works on ARM for different ABIs.
You set GOARM=5 or whatever and the compiler and
runtime won't use anything after that revision.

  Anthony

Re: [9fans] go forth and ulong no more!

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
 On 22 November 2012 03:44, Bruce Ellis bruce.el...@gmail.com wrote:
  uintptr in all over the go packages because it is right.

 I hadn't noticed that particularly, but having grep'd the source, I
 see it's also used for variables that are counters and numbers of
 things.

Can you give an example? Nothing jumped out after a quick glance.

 Is that right too? I suspect it's more out of expediency. Some other
 type usage looks odd too. int32 where int would do. Curious.

Such as? The only one I can think of is (*os.File).Fd returning
a uintptr but that was changed from int for a reason (Windows).

Cheers,
  Anthony

Re: [9fans] go forth and ulong no more!

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
 this is just a sample, but there were other likely candidates:

Ah. I thought we were talking about Go code not C. Carry on.

  Anthony

Re: [9fans] Kernel panic when compiling Go on native Plan 9

[Anthony Martin]

Pavel Klinkovsky pavel.klinkov...@gmail.com once said:
 I made another test.
 I compared compilation of exp/locale/collate of the Go build 14738 and
 14739 (and later).
 
 Compilation of 14738 does not consume RAM a lot.
 Compilation of 14739 (and later) consume a huge amount of RAM
 (involving swap).
 
 So it seems the Plan 9 has a problem with the virtual memory
 management (when using swap), IMO.

How much memory does your system have?

Changeset 14739 grew the Unicode collation tables
in the exp/locale/collate package by a considerable
amount. The compiler's memory usage now goes above
400 MB when building that package, almost 2.5x the
amount used to compile the second heavyweight and
15x the average.

  Anthony

Re: [9fans] Kernel panic when compiling Go on native Plan 9

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 On Fri Nov  2 09:44:43 EDT 2012, pavel.klinkov...@gmail.com wrote:
   How much memory does your system have?
  
  - 512 MB RAM
  - 512 MB swap
  
   Changeset 14739 grew the Unicode collation tables
   in the exp/locale/collate package by a considerable
   amount. The compiler's memory usage now goes above
   400 MB when building that package, almost 2.5x the
   amount used to compile the second heavyweight and
   15x the average.
  
  I see.
  I can confirm when the kernel panic occured I saw (in stats):
  - full RAM
  - small portion of swap occupied

If you want to work around this for the time being,
it's safe to remove that package since it's currently
an experiment and no other package depends on it.

Just 'rm -rf' the exp/locale/collate directory and
run you should be good.

 i'd wonder though if there were some way to cut down the module
 so it doesn't take quite so much memory.  even halving it would
 mean you could ditch swap.

There's a note at the top of the generated tables.go file that says
TODO: implement more compact representation for sparse blocks.

I'm going to investigate what's causing such high memory usage
in the compiler. I imagine those huge array initializations cause
hundreds of thousands of Node allocations, at the very least.

  Anthony

Re: [9fans] 9grid?

[Anthony Martin]

John Floren j...@jfloren.net once said:
 Write a basic http server for Plan 9 (in C) and run Apache Benchmark
 against it. Somewhere around 100 concurrent connections, I tend to get
 failure. There's code in /sys/src/9/ip that has a hard limit on the #
 of concurrent connections IIRC.

What happens when it fails? /sys/src/9/ip/ip.h:/Nchans isn't that low.
Do you get the garbage collecting Convs message from the kernel?

If you have stack traces or profiles, please post them on golang-dev
or send them directly to me. I'll try to get any bugs fixed promptly.

This goes for any other bugs encountered using Go on Plan 9.

Cheers,
  Anthony

Re: [9fans] empty *

[Anthony Martin]

% sed -n 20,32p /sys/src/cmd/grep/grep.y
prog:   /* empty */
{
yyerror(empty pattern);
}
|   expr newlines
{
$$.beg = ral(Tend);
$$.end = $$.beg;
$$ = re2cat(re2star(re2or(re2char(0x00, '\n'-1), 
re2char('\n'+1, 0xff))), $$);
$$ = re2cat($1, $$);
$$ = re2cat(re2star(re2char(0x00, 0xff)), $$);
topre = $$;
}
%

The above code sets up the initial state
machine including the pattern passed on
the command line, $1.

This combined with the fact that multiple
stars are coalesced causes the weirdness
you're seeing.

  Anthony

Re: [9fans] Governance question???

[Anthony Martin]

Christoph Lohmann 2...@r-36.net once said:
 All  mentioned  words  are  part  of the eternal fight
 between DP9IK and SP9SSS. As we all know is DP9IK winning.

We mustn't fight each other! Surely we should
be united against the common enemy!

  Anthony

Re: [9fans] Potential BoF in San Francisco

[Anthony Martin]

Peter A. Cejchan tyap...@gmail.com once said:
 BTW, what is the  current status of 9Go ... I still use 60.2

I just noticed this mail. Sorry.

To build the current Go codebase you need four patches.

Two should be applied to the Plan 9 tree:

/n/sources/patch/kernel-tsemacquire
/n/sources/patch/fmt-preserve

And two more to the Go tree:

https://codereview.appspot.com/5608059
https://codereview.appspot.com/6031056

Then you can do:

% cd $GOROOT/src
% ./make.rc

Cheers,
  Anthony

[9fans] Potential BoF in San Francisco

[Anthony Martin]

The first GoSF meetup¹ will be this Wednesday,
April 18th, and I'll be there if anyone wants
to talk about the port of Go to Plan 9 (or
about Plan 9 in general).

Cheers,
  Anthony

1. http://www.meetup.com/golangsf/events/49802152/

Re: [9fans] discrepency between plan9 and ixpc

[Anthony Martin]

Eli Cohen echol...@gmail.com once said:
 % echo b115200  /dev/eiaU0/eiaUctl
 % mount -ncC /dev/eiaU0/eiaU /n/anything
 % ls /n/anything
 anything
 
 the output of ls is just whatever directory i mount it in, though accessing
 arductl and ardudata works fine despite their absence from the directory
 listing.
 
 anyone have any ideas what i might be doing wrong?
 
 the source code is at https://github.com/echoline/NinePea

Without looking at the code it sounds like
you're not getting the Rstat correct.  Does
the root qid return / for the stat name?

You can use iostats(4) to help investigate.

Cheers,
  Anthony

Re: [9fans] C compiler error?

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
I abandoned my old CL and sent another that
allows 64-bit switch expressions for all of
the Go compilers.  A patch for [5678kqv]c
will be hitting sources soon.  Stay tuned.

  Anthony

Re: [9fans] C compiler error?

[Anthony Martin]

Lucio De Re lu...@proxima.alt.za once said:
 New features in Go require a new function in the reflect.c module
 (src/cmd/gc/reflect.c).  The C compiler (8c, in this case) reports an
 error which does not seem to apply:
 
 8c -I/go/include -I/go/386/include -FTVw ../gc/reflect.c
 ../gc/reflect.c:987 switch expression must be integer
 
 This is a bit of a stumbling block.  I'm hoping there's someone on
 this mailing list that can address this problem quicker than it would
 be possible for me.  More details off line.

Yup.  8c won't allow this.  If you we're using 6c
you could have a vlong in a switch expression.

I sent out a CL for this:
https://codereview.appspot.com/5486049/

  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Lucio De Re lu...@proxima.alt.za once said:
  Have you tried?  It's a non-invasive change, and once they are set
  up it's unlikely they will need to be updated often.
 
 I think Anthony is on the right path on this point, in that I've had
 to update a couple of mkfiles in the recent past because I had
 overlooked changes to the coresponding Makefiles.  Not many, but they
 do trigger additional maintenance problems.
 
 The only alternative option I would pick is to merge the Go release
 into the Plan 9 (and nix) distribution - mkfiles and all - then use a
 mechanism analogous to mine to keep them in sync.  The unsuspecting
 public would never see the hard backroom effort.

IMO using anything other than Make to build
the Go distribution is a fool's errand and
simply too much of a maintenance burden.
We would have to carefully watch upstream
changes to any of the many Makefiles.

Using make isn't as bad as some make it out
to be and, to be clear, I'm only advocating
the use of make to build the distribution;
we can still add rules for building tools
or libraries written in Go to the standard
mkfiles in /sys/src.

  Anthony

P.S.
I plan to switch from GNU Make to APE make
once I have the time to look closely at the
Go Makefiles for any GNU specific features
and then make the necessary changes or even
modify ape/make.

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Pavel Zholkover paulz...@gmail.com once said:
 Is the builder going to be based on the native
 build or will it be cross-compiled ?

It will be native.

  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
  IMO using anything other than Make to build
  the Go distribution is a fool's errand and
  simply too much of a maintenance burden.
  We would have to carefully watch upstream
  changes to any of the many Makefiles.
  
  Using make isn't as bad as some make it out
  to be and, to be clear, I'm only advocating
  the use of make to build the distribution;
  we can still add rules for building tools
  or libraries written in Go to the standard
  mkfiles in /sys/src.
 
 the camel has his nose in the tent.

This specific camel happens to be bearing
gifts on his nose.  I trust most 9fans to
keep the rest of him out. :-)

  Anthony

[9fans] Building Go on Plan 9

[Anthony Martin]

A few people were asking about this so I
wrote up a tutorial.  I also uploaded a
copy to http://apm.sdf.org/go/NOTES for
anyone who has trouble with attachments.

Cheers,
  Anthony
# Building Go on Plan 9
# Anthony Martin
# al...@pbrane.org


# This document will guide you through the process
# of compiling the commands and packages in the Go
# source code distribution.
#
# Before we get started you should make sure you
# have GNU Make installed.  The version on contrib
# is 3.81 and is just fine for our purposes.
#
# It's also necessary to have Mercurial installed
# and I believe there is a version on contrib as
# well.
#
# After reading this document you can extract the
# commands and pipe them to the shell using:
#
# sed -n 's,^[% ] ,,p' NOTES | rc
#
# I highly recommend reading all the way through
# before running the commands.
#

# First we must fetch the archive that contains
# modified include files, a build script, and a
# patch consisting of all pending (and not yet
# submitted) CLs pertaining to Plan 9.

% cd /tmp
% hget http://apm.sdf.org/go/root.tbz root.tbz

# Next we must verify the SHA1 hash of the archive.

% want = ed25980b3b813b1c80506b56331d83c4d485a4c0
% have = `{sha1sum root.tbz | awk '{print $1}'}
% if(! ~ $have $want){
echo 'ZOMG! INVALID SHA1 CHECKSUM'
echo have: $have
echo want: $want
exit badhash
  }

# Now we're ready to fetch the source code for the
# Go repository hosted at Google Code.  I had to
# make a decision about where this would reside so
# after a bit of thinking I chose /sys/src/go to
# mirror the structure of APE.
#
# The other important directories that will be
# created when extracting the archive are:
#
#   /386/bin/go (for binaries),
#   /386/include/go (for machine dependent C headers),
#   /386/lib/go (for Go's C libraries),
#   and
#   /sys/include/go (for machine independent C headers).

% cd /sys/src
% hg clone -u 2d7711ae https://go.googlecode.com/hg/ go
requesting all changes
adding changesets
adding manifests
adding file changes
added 10641 changesets with 40432 changes to 5437 files (+4 heads)
updating to branch default
3231 files updated, 0 files merged, 0 files removed, 0 files unresolved

# After fetching the Go repository we can extract
# the archive into the file system's root.  It's
# always a good idea to check the contents of an
# archive before doing something this drastic.

% cd /
% tar xvzf /tmp/root.tbz
tar: blocking = 16
386
386/bin
386/bin/go
386/include
386/include/go
386/include/go/ureg_x86.h
386/include/go/ureg_amd64.h
386/include/go/u.h
386/include/go/ureg_arm.h
386/lib
386/lib/go
sys
sys/include
sys/include/go
sys/include/go/bootexec.h
sys/include/go/mach.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/stdio.h
sys/include/go/libc.h
sys/include/go/goenv.h
sys/src
sys/src/go
sys/src/go/9fix.patch
sys/src/go/src
sys/src/go/src/make.rc

# We're almost done.  We can now apply the patch file
# into the root of the Go tree.

% cd /sys/src/go
% ape/patch -p1  9fix.patch

# Our final step is to build the commands and packages.
# Running make.rc will produce tons of output so you
# might want to redirect it to a file.

% cd src
% ./make.rc

# Now that you have a working build of Go you
# should help me make sure all of the tests pass. :-)
# Email me if you're interested in helping out.
#
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.
#
# Also, please don't submit any of the changes in
# the patch file to the Go development list.  Most
# of the changes have corresponding CLs and the few
# others are still being pondered.
#
# That's all for now.  Have fun!

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

John Floren j...@jfloren.net once said:
 How many different Go porting efforts do we now
 have for Plan 9?  There's apparently yours, Ron's,
 Lucio's, and I think the 9front guys have/had
 something cooking too.

That's it as far as I know.
 
 Which ones can actually be updated with hg pull?

None yet.

I have CLs at the ready for every change
I've made and I'm committed to getting
them upstream.

Not to be presumptuous but I really think
the way I've done it is the best way forward.
All you need is GNU Make, Mercurial, a few 
modified library headers and the bundle of
changes that I put in 9fix.patch.

I'd like to get the library headers in Nix
and hopefully even Plan 9 proper.  Then
there's only a handful of changes that I
need to get into the Go distribution.

It will happen. :-)

Cheers,
  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
 please just post again inline because 9fans.net
 doesn't archive attachments.

Sure thing.

---
A few people were asking about this so I
wrote up a tutorial.  I also uploaded a
copy to http://apm.sdf.org/go/NOTES for
anyone who has trouble with attachments.

Cheers,
  Anthony

# Building Go on Plan 9
# Anthony Martin
# al...@pbrane.org


# This document will guide you through the process
# of compiling the commands and packages in the Go
# source code distribution.
#
# Before we get started you should make sure you
# have GNU Make installed.  The version on contrib
# is 3.81 and is just fine for our purposes.
#
# It's also necessary to have Mercurial installed
# and I believe there is a version on contrib as
# well.
#
# After reading this document you can extract the
# commands and pipe them to the shell using:
#
# sed -n 's,^[% ] ,,p' NOTES | rc
#
# I highly recommend reading all the way through
# before running the commands.
#

# First we must fetch the archive that contains
# modified include files, a build script, and a
# patch consisting of all pending (and not yet
# submitted) CLs pertaining to Plan 9.

% cd /tmp
% hget http://apm.sdf.org/go/root.tbz root.tbz

# Next we must verify the SHA1 hash of the archive.

% want = ed25980b3b813b1c80506b56331d83c4d485a4c0
% have = `{sha1sum root.tbz | awk '{print $1}'}
% if(! ~ $have $want){
echo 'ZOMG! INVALID SHA1 CHECKSUM'
echo have: $have
echo want: $want
exit badhash
  }

# Now we're ready to fetch the source code for the
# Go repository hosted at Google Code.  I had to
# make a decision about where this would reside so
# after a bit of thinking I chose /sys/src/go to
# mirror the structure of APE.
#
# The other important directories that will be
# created when extracting the archive are:
#
#   /386/bin/go (for binaries),
#   /386/include/go (for machine dependent C headers),
#   /386/lib/go (for Go's C libraries),
#   and
#   /sys/include/go (for machine independent C headers).

% cd /sys/src
% hg clone -u 2d7711ae https://go.googlecode.com/hg/ go
requesting all changes
adding changesets
adding manifests
adding file changes
added 10641 changesets with 40432 changes to 5437 files (+4 heads)
updating to branch default
3231 files updated, 0 files merged, 0 files removed, 0 files unresolved

# After fetching the Go repository we can extract
# the archive into the file system's root.  It's
# always a good idea to check the contents of an
# archive before doing something this drastic.

% cd /
% tar xvzf /tmp/root.tbz
tar: blocking = 16
386
386/bin
386/bin/go
386/include
386/include/go
386/include/go/ureg_x86.h
386/include/go/ureg_amd64.h
386/include/go/u.h
386/include/go/ureg_arm.h
386/lib
386/lib/go
sys
sys/include
sys/include/go
sys/include/go/bootexec.h
sys/include/go/mach.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/stdio.h
sys/include/go/libc.h
sys/include/go/goenv.h
sys/src
sys/src/go
sys/src/go/9fix.patch
sys/src/go/src
sys/src/go/src/make.rc

# We're almost done.  We can now apply the patch file
# into the root of the Go tree.

% cd /sys/src/go
% ape/patch -p1  9fix.patch

# Our final step is to build the commands and packages.
# Running make.rc will produce tons of output so you
# might want to redirect it to a file.

% cd src
% ./make.rc

# Now that you have a working build of Go you
# should help me make sure all of the tests pass. :-)
# Email me if you're interested in helping out.
#
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.
#
# Also, please don't submit any of the changes in
# the patch file to the Go development list.  Most
# of the changes have corresponding CLs and the few
# others are still being pondered.
#
# That's all for now.  Have fun!

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Charles Forsyth charles.fors...@gmail.com once said:
 modified library headers?

% ls (386 sys)^/include/go
386/include/go/u.h
386/include/go/ureg_amd64.h
386/include/go/ureg_arm.h
386/include/go/ureg_x86.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/bootexec.h
sys/include/go/goenv.h
sys/include/go/libc.h
sys/include/go/mach.h
sys/include/go/stdio.h

Some of these are just copies of the standard
headers and others have a few adjustments that
the Go toolchain requires.  All except mach.h
have #pragmas that point to the stock location
in /386/lib/*.a.

  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom quans...@quanstro.net once said:
  386/include/go/ureg_arm.h
  386/include/go/ureg_x86.h
 
 surely that's the wrong place.

You would think so but that's how
where the headers are expected to
be for Go's libmach.

% gg 'include.*ureg'
src/cmd/cov/main.c:14: #include ureg_x86.h
src/cmd/prof/main.c:12: #include ureg_amd64.h
src/cmd/prof/main.c:15: #include ureg_x86.h
src/libmach/5.c:35: #include ureg_arm.h
src/libmach/5db.c:32: #include ureg_arm.h
src/libmach/6.c:35: #include ureg_amd64.h
src/libmach/8.c:34: #include ureg_x86.h
src/libmach/8db.c:34: #include ureg_amd64.h
src/libmach/8db.c:37: #include ureg_x86.h
src/libmach/darwin.c:33: #include ureg_x86.h
src/libmach/darwin.c:36: #include ureg_amd64.h
src/libmach/linux.c:42: #include ureg_x86.h
src/libmach/linux.c:45: #include ureg_amd64.h

Cheers,
  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Anthony Martin al...@pbrane.org once said:
 You would think so but that's how
 where the headers are expected to
 be for Go's libmach.

how where?

I shouldn't type when tired.

  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Lyndon Nerenberg lyn...@orthanc.ca once said:
 I stopped at gmake.  What can't mk do that demands gmake?

There's nothing wrong with mk.  It's just that
I highly doubt we could get a separate set of
mkfiles included in the Go distribution.

I've tried to get things going with the smallest
set of changes to both Plan 9 and Go and I think
using GNU Make is the only way to do that.

  Anthony

Re: [9fans] 9vx instability

[Anthony Martin]

cinap_len...@gmx.de once said:
 /lib/mainkampf is part of an ongoing project to make
 venti sha-1 hashes easy to remember by translating
 them into hitler-speeches.

Well now that it's gone, how about using
excerpts from Industrial Society and its
Future?

I can send a patch to add /lib/kaczynski.

  Anthony

Re: [9fans] 9vx instability

[Anthony Martin]

Anton fluffyl...@gmail.com once said:
 However, as it won't work on my laptop natively, i'm
 forced to use 9vx (running in kvm is too slow). It has
 one magor drawback - it is freezing my entire system
 after some random time. Symptoms are - no reaction on
 input (mouse/keyboard), no changes in output (screen is
 showing me what was going on just before freeze). The
 only thing I can do is to press power button for 10 secs
 and wait until my laptop turned off.

I had this happen to me a few times but I never
took the time to track it down.  I haven't had
it happen since I upgraded my kernel to 3.1.

We seem to have very simliar setups so you might
want to try that and see if it makes a difference.

$ uname -mp
i686 Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz
$ pacman -Q linux
linux 3.1.1-1
$

 P.S.: Sorry for my English.

Seems fine to me. :-)

Cheers,
  Anthony

Re: [9fans] all you yacc experts

[Anthony Martin]

Attached is a modified version of p9p yacc that
supports the Go grammar.  I'll be sending a
version of Plan 9 yacc later today.

The following is a description of the changes.

  1. The %error-verbose directive is ignored.

  2. A description of the final grammar is
 printed before the state descriptions
 in y.output.

  3. The 'x' format for character literals is
 now used instead of prefixing with a space.

  4. The YYEMPTY define is now used to clear
 the lookahead token (instead of an explicit
 negative one).

  5. Make yychar and yystate globals so they
 can be inspected by external code.

  5. Support C++ style // comments in actions.

  6. Add a usage message.

  7. Fix a few uses of sprint and strcpy.


I've also sent out a changeset to the Go
development list which adds support for
using Plan 9 yacc to generate the special
errors.

One tiny nit is that Plan 9 uses the name
yytoknames for debugging where Bison uses
yytname.  I've just used sed for this.

Any questions?
  Anthony
diff -r 44a7194d00cf lib/yaccpar
--- a/lib/yaccpar   Sat Nov 12 11:52:10 2011 -0800
+++ b/lib/yaccpar   Tue Nov 15 13:10:13 2011 -0800
@@ -2,7 +2,7 @@
 #define YYERRORgoto yyerrlab
 #define YYACCEPT   return(0)
 #define YYABORTreturn(1)
-#defineyyclearin   yychar = -1
+#defineyyclearin   yychar = YYEMPTY
 #defineyyerrok yyerrflag = 0
 
 #ifdef yydebug
@@ -51,6 +51,8 @@
return x;
 }
 
+long yychar;
+
 static long
 #ifdef YYARG
 yylex1(struct Yyarg *yyarg)
@@ -58,7 +60,6 @@
 yylex1(void)
 #endif
 {
-   long yychar;
const long *t3p;
int c;
 
@@ -68,6 +69,7 @@
yychar = yylex();
 #endif
if(yychar = 0) {
+   yychar = 0;
c = yytok1[0];
goto out;
}
@@ -99,6 +101,8 @@
return c;
 }
 
+int yystate;
+
 int
 #ifdef YYARG
 yyparse(struct Yyarg *yyarg)
@@ -112,8 +116,8 @@
int yys;
} yys[YYMAXDEPTH], *yyp, *yypt;
const short *yyxi;
-   int yyj, yym, yystate, yyn, yyg;
-   long yychar;
+   int yyj, yym, yyn, yyg;
+   long yyc;
 #ifndef YYARG
YYSTYPE save1, save2;
int save3, save4;
@@ -125,7 +129,8 @@
 #endif
 
yystate = 0;
-   yychar = -1;
+   yychar = YYEMPTY;
+   yyc = YYEMPTY;
yynerrs = 0;
yyerrflag = 0;
yyp = yys[-1];
@@ -151,7 +156,7 @@
 yystack:
/* put a state and value onto the stack */
if(yydebug = 4)
-   fprint(2, char %s in %s, yytokname(yychar), 
yystatname(yystate));
+   fprint(2, char %s in %s, yytokname(yyc), yystatname(yystate));
 
yyp++;
if(yyp = yys[YYMAXDEPTH]) {
@@ -165,18 +170,19 @@
yyn = yypact[yystate];
if(yyn = YYFLAG)
goto yydefault; /* simple state */
-   if(yychar  0)
+   if(yyc  0)
 #ifdef YYARG
-   yychar = yylex1(yyarg);
+   yyc = yylex1(yyarg);
 #else
-   yychar = yylex1();
+   yyc = yylex1();
 #endif
-   yyn += yychar;
+   yyn += yyc;
if(yyn  0 || yyn = YYLAST)
goto yydefault;
yyn = yyact[yyn];
-   if(yychk[yyn] == yychar) { /* valid shift */
-   yychar = -1;
+   if(yychk[yyn] == yyc) { /* valid shift */
+   yyc = YYEMPTY;
+   yychar = YYEMPTY;
yyval = yylval;
yystate = yyn;
if(yyerrflag  0)
@@ -188,11 +194,11 @@
/* default state action */
yyn = yydef[yystate];
if(yyn == -2) {
-   if(yychar  0)
+   if(yyc  0)
 #ifdef YYARG
-   yychar = yylex1(yyarg);
+   yyc = yylex1(yyarg);
 #else
-   yychar = yylex1();
+   yyc = yylex1();
 #endif
 
/* look through exception table */
@@ -201,21 +207,24 @@
break;
for(yyxi += 2;; yyxi += 2) {
yyn = yyxi[0];
-   if(yyn  0 || yyn == yychar)
+   if(yyn  0 || yyn == yyc)
break;
}
yyn = yyxi[1];
-   if(yyn  0)
+   if(yyn  0) {
+   yyc = YYEMPTY;
+   yychar = YYEMPTY;
goto ret0;
+   }
}
if(yyn == 0) {
/* error ... attempt to resume parsing */
switch(yyerrflag) {
case 0:   /* brand new error */
yyerror(syntax error);
-   if(yydebug = 1) {
+   if(yydebug = 2) {
fprint(2, %s, yystatname(yystate));
-   fprint(2, saw %s\n, yytokname(yychar));
+   fprint(2, saw %s\n, yytokname(yyc));
 

Re: [9fans] nanosleep()?

[Anthony Martin]

ron minnich rminn...@gmail.com once said:
 For a first pass, you could create a nanosleep for plan 9
 that rounds to milliseconds and then use sleep()

Yup.  This is the right thing to do.  The prof command
in the Go distribution has a minimum sampling interval
of one millisecond so you don't even need nanosleep.

  Anthony

Re: [9fans] Easy stating of newer files on Plan9

[Anthony Martin]

tlaro...@polynum.com once said:
 There is one utility used by MetaPost scripts: a binary newer using
 POSIX (sys/stat.h) mainly because if on POSIX compliant systems one can
 use find(1) with -cnewer, Plan9 has not find(1).

 [...]
 
 What would be the prefered way using utilities available on Plan9 (and
 accessible for ape/sh) since the scripts are Bourne shell ones.

The Plan 9 test(1) has newer than and older than
expressions just like the Korn shell's built-in.

  Anthony

[9fans] Two bugs in ar

[Anthony Martin]

I was investigating a bug in the Go toolchain's
fork of ar(1), called gopack, and I discovered
two similar bugs in native ar.

1. With a __.SYMDEF file of size (2*n)+1 bytes,
   the size given in the header will incorrectly
   include the padding byte.

2. When writing an archive member file to disk,
   the odd-size check occurs before the write
   which will access one byte past the end of
   the buffer containing the member data.

The solution for both errors is to check for an
odd size after the write, not before.

A patch is attached.  I also modified the code
to properly insert a newline character between
archive members when necessary, in accordance
with the ar(6) man page.

  Anthony

--- /n/sources/sys/src/cmd/ar.c 2010-01-21 16:16:47.0 -0800
+++ ar.c2011-05-05 03:15:19.0 -0700
@@ -827,8 +827,6 @@
Bseek(b,seek(fd,0,1), 0);
 
len = symdefsize;
-   if(len01)
-   len++;
sprint(a.date, %-12ld, time(0));
sprint(a.uid, %-6d, 0);
sprint(a.gid, %-6d, 0);
@@ -842,6 +840,8 @@
if(HEADER_IO(Bwrite, b, a))
wrerr();
 
+   if(len01)
+   len++;
len += Boffset(b);
if (astart) {
wrsym(b, len, astart-sym);
@@ -855,7 +855,7 @@
wrsym(b, len, aend-sym);
 
if(symdefsize0x01)
-   Bputc(b, 0);
+   Bputc(b, '\n');
Bterm(b);
 }
 
@@ -1121,10 +1121,12 @@
if(HEADER_IO(write, fd, bp-hdr))
return 0;
len = bp-size;
-   if (len  01)
-   len++;
if (write(fd, bp-member, len) != len)
return 0;
+   if (len  01) {
+   if(write(fd, \n, 1) != 1)
+   return 0;
+   }
return 1;
 }