Re: [9fans] Go arm builder's image

[adr via 9fans]

Ok, thanks.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3dbd3cda56f638ee-M16e29431130bbf818b28
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Go arm builder's image

[Richard Miller]

> Last thing about your rpi image Richard, Is this the
> one used in the go arm builders? Can I asume that
> these are the only patches needed to have a working go?
>

Yes, and yes.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3dbd3cda56f638ee-M52ab001ba7b43f68f46d09be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Go arm builder's image

[adr via 9fans]

Last thing about your rpi image Richard, Is this the
one used in the go arm builders? Can I asume that
these are the only patches needed to have a working go?

Regards,
adr

Re: [9fans] go on plan9 - what doesn’t work?, ports list?

[Fazlul Shahriar]

Hi,

I believe Multicast works. There are some basic tests at
https://golang.org/src/net/udpsock_plan9_test.go. It should work on all
three architectures.

I don't know of any ports list. In general everything should work unless
it's doing something non-portable. I recently played around with go-git and
had to deal with its use of symlinks, assuming posix semantics for
os.Rename, etc. However, there are features missing in the Go port to
plan9, and other issues (see https://github.com/golang/go/labels/OS-Plan9).

- fhs

On Sat, Dec 28, 2019 at 2:55 PM Steve Simon  wrote:

> hi
> 
> i am interested to hear from in those using go under plan9.
> 
> what doesn't work? i know the build servers confirm the nightly build but
> they cannot check everything.
> 
> for example, does multicast work? if so does it work on x86, amd64, and
> arm (pi)?
> 
> secondly, is there a ports list, or a list of packages and apps
> successfully built?
> 
> i am toying with moving to plan9 as my main go development platform (for
> work). this sits on etcd, nats, and protobufs which should be
> straightforward, but also needs multicast which is a bit of a dusty corner
> in plan9.
> 
> i would also like to run a DLNA server for music and movies on plan9.
> there is a nifty ine in go (DMS) but anyone already tried porting it?
> 
> thanks for any/all help,
> 
> -Steve
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T25dc9fda4f99337a-Mb7b0c119f0952ea9f6947228
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] go on plan9 - what doesn’t work?, ports list?

[Steve Simon]

hi

i am interested to hear from in those using go under plan9.

what doesn't work? i know the build servers confirm the nightly build but they 
cannot check everything.

for example, does multicast work? if so does it work on x86, amd64, and arm 
(pi)?

secondly, is there a ports list, or a list of packages and apps successfully 
built?

i am toying with moving to plan9 as my main go development platform (for work). 
this sits on etcd, nats, and protobufs which should be straightforward, but 
also needs multicast which is a bit of a dusty corner in plan9.

i would also like to run a DLNA server for music and movies on plan9. there is 
a nifty ine in go (DMS) but anyone already tried porting it?

thanks for any/all help,

-Steve



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T25dc9fda4f99337a-Mb42f463b44f03868803a504c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

See https://www.flexense.com/usb3_vs_sata_disk_performance_comparison.html
Here local SATA3 vs USB3 comparison is done. While not directly comparable,
the only case where throughput is below what you can push through GbE is
single threaded small file copying. For every other case tested, GbE will
be the bottleneck.

> On Sep 21, 2019, at 5:32 AM, hiro <23h...@gmail.com> wrote:
> 
> yeah, but check small blocksize random read/write vs. AoE or 9p over
> ethernet. I'm not sure how efficient usb3 in terms of latency :)
> 
> On 9/21/19, Bakul Shah  wrote:
>> On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com>
>> wrote:
>>> 
 Another option worth exploring may
 be AOE as pi4 has a GbE (I haven't tried this yet).
>>> 
>>> My go test builders are running with "local" fossil on a slice
>>> of disk provided over AoE from an atom server.  I tried various
>>> configurations and this gave me the best performance.  This is
>>> with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.
>>> 
>>> Pi4 has proper GbE, but also has usb3 so a local ssd drive might
>>> be a practical alternative.  More experiments to do.
>> 
>> On linux/pi4 I get about 230MB/s for seq. read on a $10 USB3.1
>> Samsung flash drive. Time to get a new SSD!
>> 
>> 
> 

Re: [9fans] go under plan9 on the radpberry pi?

[hiro]

yeah, but check small blocksize random read/write vs. AoE or 9p over
ethernet. I'm not sure how efficient usb3 in terms of latency :)

On 9/21/19, Bakul Shah  wrote:
> On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com>
> wrote:
>>
>> > Another option worth exploring may
>> > be AOE as pi4 has a GbE (I haven't tried this yet).
>>
>> My go test builders are running with "local" fossil on a slice
>> of disk provided over AoE from an atom server.  I tried various
>> configurations and this gave me the best performance.  This is
>> with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.
>>
>> Pi4 has proper GbE, but also has usb3 so a local ssd drive might
>> be a practical alternative.  More experiments to do.
>
> On linux/pi4 I get about 230MB/s for seq. read on a $10 USB3.1
> Samsung flash drive. Time to get a new SSD!
>
>

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com> wrote:
>
> > Another option worth exploring may
> > be AOE as pi4 has a GbE (I haven't tried this yet).
>
> My go test builders are running with "local" fossil on a slice
> of disk provided over AoE from an atom server.  I tried various
> configurations and this gave me the best performance.  This is
> with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.
>
> Pi4 has proper GbE, but also has usb3 so a local ssd drive might
> be a practical alternative.  More experiments to do.

On linux/pi4 I get about 230MB/s for seq. read on a $10 USB3.1
Samsung flash drive. Time to get a new SSD!

Re: [9fans] go under plan9 on the radpberry pi?

[Steve Simon]

hi,

thanks richard, this is perfect

i could not have asked for more.

-Steve


On 20 Sep 2019, at 9:43 am, Richard Miller <9f...@hamnavoe.com> wrote:

>> Only lightly tested.
> 
> In a sense, plan9/arm go is tested as well as any other platform:
> under the go continuous development process, every time a change
> is made to the compiler or runtime library, a complete test suite
> is run on builder machines for every supported architecture and
> operating system.  If you look at https://build.golang.org and
> scroll wa over to the right, the plan9/arm column refers
> to a set of Raspberry Pi machines run by David du Columbier and me.
> 
> In another sense, it's probably not very well tested at all:
> I'm not aware of any production application being run on go in
> Plan 9, on any machine architecture.  I haven't used go seriously
> myself, but I find the test suite gives the OS such a brutal workout
> (especially with small physical memory) that it's a good way
> to flush out underlying Plan 9 bugs.
> 
> The tests show some intermittent hard-to-reproduce failures ("flakes")
> on all the Plan 9 builders.  Many are timing issues because the tests
> make assumptions about absolute speed of builder machines; but there
> are some "can't happen" panics during garbage collection which smell
> like a cache or memory barrier problem.  Please don't use plan9/arm
> go to run your nuclear power plant just yet ...
> 

Re: [9fans] go under plan9 on the radpberry pi?

[Richard Miller]

> If you mean the go compiler itself, hopefully the 2GB VM you
> get on 9p/pi4 is enough to compile the compiler using a
> cross-compiled bootstrap compiler.

The compiler can compile itself natively on a pi2 or pi3.
No need to activate swap space, unless you want to run the
full test suite.

> Another option worth exploring may
> be AOE as pi4 has a GbE (I haven't tried this yet).

My go test builders are running with "local" fossil on a slice
of disk provided over AoE from an atom server.  I tried various
configurations and this gave me the best performance.  This is
with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.

Pi4 has proper GbE, but also has usb3 so a local ssd drive might
be a practical alternative.  More experiments to do.

Re: [9fans] go under plan9 on the radpberry pi?

[Richard Miller]

> Only lightly tested.

In a sense, plan9/arm go is tested as well as any other platform:
under the go continuous development process, every time a change
is made to the compiler or runtime library, a complete test suite
is run on builder machines for every supported architecture and
operating system.  If you look at https://build.golang.org and
scroll wa over to the right, the plan9/arm column refers
to a set of Raspberry Pi machines run by David du Columbier and me.

In another sense, it's probably not very well tested at all:
I'm not aware of any production application being run on go in
Plan 9, on any machine architecture.  I haven't used go seriously
myself, but I find the test suite gives the OS such a brutal workout
(especially with small physical memory) that it's a good way
to flush out underlying Plan 9 bugs.

The tests show some intermittent hard-to-reproduce failures ("flakes")
on all the Plan 9 builders.  Many are timing issues because the tests
make assumptions about absolute speed of builder machines; but there
are some "can't happen" panics during garbage collection which smell
like a cache or memory barrier problem.  Please don't use plan9/arm
go to run your nuclear power plant just yet ...

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Fri, 20 Sep 2019 06:29:31 +0100 Steve Simon  wrote:
>
> my plan was to build and run/debug go on a raspberry pi 4 running plan9, not
>  to cross compile.

If you mean go programs, the compile speed is tolerable
provided you are not building very large programs.

If you mean the go compiler itself, hopefully the 2GB VM you
get on 9p/pi4 is enough to compile the compiler using a
cross-compiled bootstrap compiler.  If the build does work, it
will be slow because sdcards are slow. Root mounted from a
decent fileserver may help. Another option worth exploring may
be AOE as pi4 has a GbE (I haven't tried this yet).

Re: [9fans] go under plan9 on the radpberry pi?

[Michael Misch]

Go builds on Plan9 suffer from the post-1.9 performance regression.

> On Sep 19, 2019, at 10:29 PM, Steve Simon  wrote:
> 
> hi,
> 
> my plan was to build and run/debug go on a raspberry pi 4 running plan9, not 
> to cross compile.
> 
> i am confident in the linux cross compile environment i was just concerned 
> about the plan9 os/runtime support for the pi.
> 
> i guess it comes down to plan9 os interface for the arm.
> 
> people said it is painful, you mean the pi is slow?
> 
> thanks for the help.
> 
> -Steve
> 
>> On 20 Sep 2019, at 5:37 am, Lyndon Nerenberg  wrote:
>> 
>> Matthew Veety writes:
>> 
>>> Building anything on a raspberry pi is a bit of a chore. I highly=20
>>> recommend running go on your cpu server and/or local to your filesystem.=20
>>> The generated binaries seem to work fine.
>> 
>> Go does wonderfully when it comes to generating binaries for
>> non-native architectures.  I have a few Go-based tools I use at
>> work that I build on any number of archictures (macos, freebsd,
>> openbsd, linux / armX, i386, amd64)) that I need to run on one or
>> many of the above.  They all just work.  Makes debugging a breeze.
>> 
>> But now that they are succumbing to the shared lib/obj doctrine, I'm sure
>> I will soon go back to writing C code, since the advantage of those
>> static go binaries is about to be lost :-(
> 
> 

Re: [9fans] go under plan9 on the radpberry pi?

[Steve Simon]

hi,

my plan was to build and run/debug go on a raspberry pi 4 running plan9, not to 
cross compile.

i am confident in the linux cross compile environment i was just concerned 
about the plan9 os/runtime support for the pi.

i guess it comes down to plan9 os interface for the arm.

people said it is painful, you mean the pi is slow?

thanks for the help.

-Steve

> On 20 Sep 2019, at 5:37 am, Lyndon Nerenberg  wrote:
> 
> Matthew Veety writes:
> 
>> Building anything on a raspberry pi is a bit of a chore. I highly=20
>> recommend running go on your cpu server and/or local to your filesystem.=20
>> The generated binaries seem to work fine.
> 
> Go does wonderfully when it comes to generating binaries for
> non-native architectures.  I have a few Go-based tools I use at
> work that I build on any number of archictures (macos, freebsd,
> openbsd, linux / armX, i386, amd64)) that I need to run on one or
> many of the above.  They all just work.  Makes debugging a breeze.
> 
> But now that they are succumbing to the shared lib/obj doctrine, I'm sure
> I will soon go back to writing C code, since the advantage of those
> static go binaries is about to be lost :-(

Re: [9fans] go under plan9 on the radpberry pi?

[Lyndon Nerenberg]

Matthew Veety writes:

> Building anything on a raspberry pi is a bit of a chore. I highly=20
> recommend running go on your cpu server and/or local to your filesystem.=20
> The generated binaries seem to work fine.

Go does wonderfully when it comes to generating binaries for
non-native architectures.  I have a few Go-based tools I use at
work that I build on any number of archictures (macos, freebsd,
openbsd, linux / armX, i386, amd64)) that I need to run on one or
many of the above.  They all just work.  Makes debugging a breeze.

But now that they are succumbing to the shared lib/obj doctrine, I'm sure
I will soon go back to writing C code, since the advantage of those
static go binaries is about to be lost :-(

Re: [9fans] go under plan9 on the radpberry pi?

[Matthew Veety]

Building anything on a raspberry pi is a bit of a chore. I highly 
recommend running go on your cpu server and/or local to your filesystem. 
The generated binaries seem to work fine. I haven't found any bugs, but I 
haven't run anything serious on on my pis.


On Thu, 19 Sep 2019, Michael Misch wrote:


I’ve used it, it works fine. Building on a raspberry pi, on the other hand is a 
chore when using Go.


On Sep 19, 2019, at 3:46 PM, Bakul Shah  wrote:

On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon  wrote:


does go run under plan9 on the radpberry pi or only on x86?


I haven't tried a native build but cross-compiling with

   cd `go env GOROOT`/src
   GOOS=plan9 GOARCH=arm ./bootstrap.bash

seems to work. bunzip2 the resulting .tbz file in $home & then
bind -a $home/go-plan9-arm-bootstrap/bin /bin

Only lightly tested.

Re: [9fans] go under plan9 on the radpberry pi?

[Michael Misch]

I’ve used it, it works fine. Building on a raspberry pi, on the other hand is a 
chore when using Go.

> On Sep 19, 2019, at 3:46 PM, Bakul Shah  wrote:
> 
> On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon  wrote:
>> 
>> does go run under plan9 on the radpberry pi or only on x86?
> 
> I haven't tried a native build but cross-compiling with
> 
>cd `go env GOROOT`/src
>GOOS=plan9 GOARCH=arm ./bootstrap.bash
> 
> seems to work. bunzip2 the resulting .tbz file in $home & then
> bind -a $home/go-plan9-arm-bootstrap/bin /bin
> 
> Only lightly tested.
> 

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon  wrote:
>
> does go run under plan9 on the radpberry pi or only on x86?

I haven't tried a native build but cross-compiling with

cd `go env GOROOT`/src
GOOS=plan9 GOARCH=arm ./bootstrap.bash

seems to work. bunzip2 the resulting .tbz file in $home & then
bind -a $home/go-plan9-arm-bootstrap/bin /bin

Only lightly tested.

[9fans] go under plan9 on the radpberry pi?

[Steve Simon]

hi all,

does go run under plan9 on the radpberry pi or only on x86?

thanks,

-Steve

Re: [9fans] Go on amd64

[David du Colombier]

Some Go binary packages for plan9/386, plan9/amd64
and plan9/arm are available here:

http://9legacy.org/download.html

-- 
David du Colombier

Re: [9fans] Go on amd64

[Dave MacFarlane]

Nevermind, the problems went away after recompiling 1.9.2 from source a
second time, something must have went wrong with my initial bootstrap..

On Dec 20, 2017 19:29, "Dave MacFarlane"  wrote:

What's the latest version of Go on amd64 that anyone's used successfully?

I just reinstalled 9front after putting in a new SSD on my laptop and
I'm getting panics about errors lowering to SSA while trying to
compile dgit, but I'm not sure if something went wrong bootstrapping
go 1.9.2 or how much effort I should into trying to put into make a
minimal test case (the function it's panicing on is going to be hard
to extract and I don't have any ideas what's special about it that's
causing a panic..)

--
- Dave

Re: [9fans] Go on amd64

[as]

; go version
go version 1.7beta1 plan9/amd64

On Wed, Dec 20, 2017, 16:32 Dave MacFarlane  wrote:

> What's the latest version of Go on amd64 that anyone's used successfully?
>
> I just reinstalled 9front after putting in a new SSD on my laptop and
> I'm getting panics about errors lowering to SSA while trying to
> compile dgit, but I'm not sure if something went wrong bootstrapping
> go 1.9.2 or how much effort I should into trying to put into make a
> minimal test case (the function it's panicing on is going to be hard
> to extract and I don't have any ideas what's special about it that's
> causing a panic..)
>
> --
> - Dave
>
>

[9fans] Go on amd64

[Dave MacFarlane]

What's the latest version of Go on amd64 that anyone's used successfully?

I just reinstalled 9front after putting in a new SSD on my laptop and
I'm getting panics about errors lowering to SSA while trying to
compile dgit, but I'm not sure if something went wrong bootstrapping
go 1.9.2 or how much effort I should into trying to put into make a
minimal test case (the function it's panicing on is going to be hard
to extract and I don't have any ideas what's special about it that's
causing a panic..)

-- 
- Dave

Re: [9fans] Go 1.4.3 compilation on Raspberry Pi

[Pavel Klinkovský]

>
> There are some binaries available here if you want to use them to
> bootstrap:
>
> http://www.9legacy.org/download.html


Already done and working fine. ;)

Thank you.

Pavel

Re: [9fans] Go 1.4.3 compilation on Raspberry Pi

[Chris McGee]

There are some binaries available here if you want to use them to bootstrap:

http://www.9legacy.org/download.html

Chris

On Oct 11, 2017, at 6:13 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
>> instructions on https://github.com/golang/go/wiki/Plan9.
> 
> I believe that route to bootstrapping go from scratch on Plan 9
> will work only for 386.
> 
> On arm, you can either cross-compile go1.4 on another go platform
> (eg plan9/386, plan9port on linux/386, or linux/arm), or start with
> a pre-compiled plan9/arm package (there are several to choose from
> on http://www.9legacy.org/download.html).
> 
> Once you have that, you can run it on Plan 9 on the Raspberry Pi to
> bootstrap the current release of go.
> 
> 

Re: [9fans] Go 1.4.3 compilation on Raspberry Pi

[Pavel Klinkovský]

>
> I believe that route to bootstrapping go from scratch on Plan 9
> will work only for 386.
>

I see.


> On arm, you can either cross-compile go1.4 on another go platform
> (eg plan9/386, plan9port on linux/386, or linux/arm), or start with
> a pre-compiled plan9/arm package (there are several to choose from
> on http://www.9legacy.org/download.html).
>

Excellent.

Once you have that, you can run it on Plan 9 on the Raspberry Pi to
> bootstrap the current release of go.
>

Perfect, going to follow your recommendation.

Thank you for such a hint

Pavel

Re: [9fans] Go 1.4.3 compilation on Raspberry Pi

[Richard Miller]

> I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
> instructions on https://github.com/golang/go/wiki/Plan9.

I believe that route to bootstrapping go from scratch on Plan 9
will work only for 386.

On arm, you can either cross-compile go1.4 on another go platform
(eg plan9/386, plan9port on linux/386, or linux/arm), or start with
a pre-compiled plan9/arm package (there are several to choose from
on http://www.9legacy.org/download.html).

Once you have that, you can run it on Plan 9 on the Raspberry Pi to
bootstrap the current release of go.

[9fans] Go 1.4.3 compilation on Raspberry Pi

[Pavel Klinkovský]

Hi all,

I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
instructions on https://github.com/golang/go/wiki/Plan9.

But still having errors...

term% make.rc
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, plan9/arm.
lib9
libbio
liblink
/usr/glenda/go1.4/include/plan9/../link.h:56[/usr/glenda/go1.4/src/liblink/anames6.c:1487]
syntax error, last name: float64
/usr/glenda/go1.4/include/plan9/../link.h:56[/usr/glenda/go1.4/src/liblink/anames8.c:1487]
syntax error, last name: float64
go tool dist: FAILED: /bin/5c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/glenda/go1.4/include/plan9
-I/usr/glenda/go1.4/include/plan9/arm -I /usr/glenda/go1.4/src/liblink -o
$WORK/anames6.5 /usr/glenda/go1.4/src/liblink/anames6.c:
'/usr/glenda/go1.4/src/liblink/anames8.c' does not exist
/usr/glenda/go1.4/include/plan9/../link.h:56[/usr/glenda/go1.4/src/liblink/asm5.c:1519]
syntax error, last name: float64
go tool dist: FAILED: /bin/5c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/glenda/go1.4/include/plan9
-I/usr/glenda/go1.4/include/plan9/arm -I /usr/glenda/go1.4/src/liblink -o
$WORK/anames8.5 /usr/glenda/go1.4/src/liblink/anames8.c:
'/usr/glenda/go1.4/src/liblink/anames8.c' does not exist
/usr/glenda/go1.4/include/plan9/../link.h:56[/usr/glenda/go1.4/src/liblink/anames5.c:1487]
syntax error, last name: float64
go tool dist: FAILED: /bin/5c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/glenda/go1.4/include/plan9
-I/usr/glenda/go1.4/include/plan9/arm -I /usr/glenda/go1.4/src/liblink -o
$WORK/asm5.5 /usr/glenda/go1.4/src/liblink/asm5.c:
'/usr/glenda/go1.4/src/liblink/anames8.c' does not exist
go tool dist: FAILED: /bin/5c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/glenda/go1.4/include/plan9
-I/usr/glenda/go1.4/include/plan9/arm -I /usr/glenda/go1.4/src/liblink -o
$WORK/anames5.5 /usr/glenda/go1.4/src/liblink/anames5.c:
'/usr/glenda/go1.4/src/liblink/anames8.c' does not exist
term%

Any idea what I am doing wrong?

Thanks in advance.

Pavel

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

I use GOROOT=$home/go to keep up with tip.  after bootstrapping, rebuild
the standard packages and commands:

% GOBIN=$home/bin/386 $home/go/bin/go install -a std cmd

and

% GOARCH=arm go install -a std cmd

then in my profile:

% test -d $home/go/bin/plan9_^$cputype && bind
-a $home/go/bin/plan9_^$cputype /bin  || bind -a $home/go/bin /bin

unfortunately because the treatment of GOBIN is not symmetrical when
$GOARCH == $cputype  vs  $GOARCH != $cputype,  we can't do:

% for (GOARCH in (386 arm)) {
echo GOBIN=$home/bin/$GOARCH $home/go/bin/go install -a std cmd
}


-Skip

On Wed, Apr 13, 2016 at 12:34 AM,  wrote:
>
>
> Skip, where in the FS hierarchy do you install the go distribution?
> Also, which additional go packages are in general use on Plan 9
> platforms and where do they normally get installed?
>
> Lucio.
>
>
>

Re: [9fans] Go on Plan 9?

[Richard Miller]

> Still, how much swap are we talking about?

On a 1GB system, the default test suite swaps in only a handful of places.
It's possible to limit the concurrency enough to cut out swapping, but
then it takes longer because there's less opportunity to overlap cpu-bound
tests with file I/O and paging-in of commands.

Re: [9fans] Go on Plan 9?

[lucio]

> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file, even on a
> 1GB raspberry pi.  Trust me.

Sounds like a challenge, but I never quite wanted to know whether Plan
9 swap is or isn't broken.  Still, how much swap are we talking about?
It can't be nice on a device like the rPi.

Lucio.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> That's insane. Really.

The designer(s) of the test suite had bigger systems in mind,
so there's lots of stuff running concurrently.

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 15:42, Charles Forsyth 
wrote:

> On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:
>
>> If you want to get to the satisfying ALL TESTS PASSED message at the end
>> of the go install+test process, you will need a swap file,
>>
>
> That's insane. Really.


More helpfully, it would be useful to find the relevant tests and make them
conditional on configuration.
I'm sure it makes sense to test big memory systems, but it's somewhat
limiting to insist on an Internet of Tanks
instead of Things.

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 15:39, Richard Miller <9f...@hamnavoe.com> wrote:

> If you want to get to the satisfying ALL TESTS PASSED message at the end
> of the go install+test process, you will need a swap file,
>

That's insane. Really.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> It won't need a swap file unless the program forces all that to be
> allocated, which it shouldn't,

If you want to get to the satisfying ALL TESTS PASSED message at the end
of the go install+test process, you will need a swap file, even on a
1GB raspberry pi.  Trust me.

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

I tried that at some point. Got pi2 booting with one core, crashed with 
multiple, but then again, I'm new to having to be that intimate with assembly 
and kernel mode.

I'd suggest trying from scratch to port things, but there are a few 9front 
differences that make it much more than just a diff.

Best regards,
Kenny Levinsen

> On 13. apr. 2016, at 16.00, Chris McGee  wrote:
> 
> Ah, that makes sense. It’s virtual memory and not the physical memory.
> 
> Do you think that your changes to the bcm will make it to 9front? If not, any 
> chance I could have the diffs so that I can try merging them in there myself?
> 
> Thanks,
> Chris

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 13 April 2016 at 14:08, Chris McGee  wrote:

> I believe that my rpi only has the 512MB of RAM so I’ll add swap.


It should be enough to increase the available virtual space by changing
that #define.
It won't need a swap file unless the program forces all that to be
allocated, which it shouldn't,
and if it does, you still won't want to swap since it doesn't work well.

In fact, I've ripped the paging and swap crud out of my own systems. The
time for that was years ago,
and it certainly makes no sense at all on any small device. The code and
data get a lot simpler too.

Re: [9fans] Go on Plan 9?

[Chris McGee]

Ah, that makes sense. It’s virtual memory and not the physical memory.

Do you think that your changes to the bcm will make it to 9front? If not, any 
chance I could have the diffs so that I can try merging them in there myself?

Thanks,
Chris

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I didn’t realize that Go was so virtual memory hungry. I wonder why stats 
> didn’t show me a large peak of memory consumption before the go compiler died?

stats -m shows physical memory usage.  Every go program starts by allocating
a huge block of virtual space for its garbage-collected allocation arena.
A lot of that will normally remain unused, so no corresponding physical ram
need be allocated.

> Are these changes going to make it into the official kernel source? Any 
> reason why everyone, even non Go users, wouldn’t want the changes?

Depends what you mean by "official".  The rpi specific changes are all in
/n/sources/contrib/miller/9/bcm, and I will be sending patches for the portable
changes soon.  This is only for reference - it has been some time since any
patches were being applied on /n/sources/plan9.

> I didn’t realize that Go programs were so heavy weight. What do embedded Go 
> users have to do to make things work on other platforms like Linux?

Depends what you mean by "embedded".  The VM allocation is probably less
significant for very small platforms than the size of the runtime library.

cpu% cat smallest.go
package main
func main() {
}
cpu% go build smallest.go
cpu% ls -l smallest
--rwxr-x--x M 3990 miller miller 614356 Apr 13 14:42 smallest
cpu% size smallest
466123t + 1792d + 87712b = 555627   smallest

Re: [9fans] Go on Plan 9?

[Chris McGee]

Thanks Richard for doing the go port to plan9/arm. I was going to start on that 
myself until I found out it was already done. :-)

I didn’t realize that Go was so virtual memory hungry. I wonder why stats 
didn’t show me a large peak of memory consumption before the go compiler died? 
Perhaps it allocates a huge chunk of virtual memory on startup.

I’ll check for that kernel change in my kernel source. If it’s not there I’ll 
recompile and give it a shot. Are these changes going to make it into the 
official kernel source? Any reason why everyone, even non Go users, wouldn’t 
want the changes?

I believe that my rpi only has the 512MB of RAM so I’ll add swap. I didn’t 
realize that Go programs were so heavy weight. What do embedded Go users have 
to do to make things work on other platforms like Linux?

Cheers,
Chris

> On Apr 13, 2016, at 5:10 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
>> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
>> virtual memory allocation failed” error when I try to compile anything.
> 
> Go needs a lot of virtual memory - it won't even pass the installation test 
> suite
> if you give it less than a gigabyte.  That was the reason for the change to 
> the
> definition in /sys/src/9/bcm/mem.h mentioned earlier:
> 
> < #define USTKTOP 0x2000  /* user segment end +1 
> */
> ---
>> #define  USTKTOP 0x4000  /* user segment end +1 
>> */
> 
> Are you running a 9pi kernel built with this change?  There are newer kernel 
> binaries
> in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
> are
> using an older pi with 512MB of ram, you'll need to activate swap(8).
> 
> The plan9_arm version of go is expected to be in the 1.7 release.  It is 
> already
> self hosting: if you look at the builder dashboard in http://build.golang.org
> which tracks updates being built and tested on all platforms, the "plan9 arm"
> column at the far right is a Raspberry Pi 3 managed by David du Colombier.
> It doesn't keep up with every update because a complete build and test suite
> run takes a bit over an hour.
> 
> 

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
> virtual memory allocation failed” error when I try to compile anything.

Go needs a lot of virtual memory - it won't even pass the installation test 
suite
if you give it less than a gigabyte.  That was the reason for the change to the
definition in /sys/src/9/bcm/mem.h mentioned earlier:

< #define   USTKTOP 0x2000  /* user segment end +1 
*/
---
> #define   USTKTOP 0x4000  /* user segment end +1 
> */

Are you running a 9pi kernel built with this change?  There are newer kernel 
binaries
in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
are
using an older pi with 512MB of ram, you'll need to activate swap(8).

The plan9_arm version of go is expected to be in the 1.7 release.  It is already
self hosting: if you look at the builder dashboard in http://build.golang.org
which tracks updates being built and tested on all platforms, the "plan9 arm"
column at the far right is a Raspberry Pi 3 managed by David du Colombier.
It doesn't keep up with every update because a complete build and test suite
run takes a bit over an hour.

Re: [9fans] Go on Plan 9?

[Richard Miller]

> I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
> virtual memory allocation failed” error when I try to compile anything.

Go needs a lot of virtual memory - it won't even pass the installation test 
suite
if you give it less than a gigabyte.  That was the reason for the change to the
definition in /sys/src/9/bcm/mem.h mentioned earlier:

< #define   USTKTOP 0x2000  /* user segment end +1 
*/
---
> #define   USTKTOP 0x4000  /* user segment end +1 
> */

Are you running a 9pi kernel built with this change?  There are newer kernel 
binaries
in /n/sources/contrib/miller/9pi* with this and other tweaks applied.  If you 
are
using an older pi with 512MB of ram, you'll need to activate swap(8).

The plan9_arm version of go is expected to be in the 1.7 release.  It is already
self hosting: if you look at the builder dashboard in http://build.golang.org
which tracks updates being built and tested on all platforms, the "plan9 arm"
column near the far right is a Raspberry Pi 3 managed by David du Colombier.
It doesn't keep up with every update because a complete build and test suite
run takes a bit over an hour.

Re: [9fans] Go on Plan 9?

[lucio]

> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?

Go seems a little outside the scope of a Plan 9 release and I think it
would take a greater interest by the community to bring it in.  I seem
to recall that Quanstro's 9atom does not implement syscall 53
(nanotime), as a probable example of where the thinking diverges.

It is certainly the case that Go has distinctive philosophy that
differs in place from Plan 9 and I see no reason not to treat the two
as distinct.

Expecting the Plan 9 community to focus on Go would be unreasonable,
in my opinion.  It does not mean that the shift can't take place, but
it should not be forced.

Skip, where in the FS hierarchy do you install the go distribution?
Also, which additional go packages are in general use on Plan 9
platforms and where do they normally get installed?

Lucio.

Re: [9fans] Go on Plan 9?

[lucio]

> I tried a bootstrapped version on my RPi but it fails with a
> "fork/exec ...  virtual memory allocation failed” error when I try to
> compile anything.  According to stats I have plenty of memory left
> when it runs.  I’m not sure what to make of it.  Any idea if the port
> is complete or if there are additional commits in progress?

I'm sure Richard will respond; I think this is a known problem and has
been addressed.  I seem to recall (not having an rPI of my own) that
the cause lies outside Go.

Lucio.

PS: In passing, I have Plan 9 running - in a limited sense - on
MIPS-64 on my Yeeloong notebook and I have also experimented with
linux/mips64 on the same platform (thank you Cherry for both!).

>From there, I think the next milestones ought to be plan9/mips64 and
exp/shiny.  That would be bliss.

Re: [9fans] Go on Plan 9?

[lucio]

> Next to try on Plan 9: build a linux/s390x binary and find a machine to run
> it on :)

I have certainly done that with linux/386 under Plan 9.  It works like
a charm, even if the compilation is a lot slower than doing it
natively on the target machine (which I could eventually install Go
on).

Lucio.

Re: [9fans] Go on Plan 9?

[Chris McGee]

I see now that there is plan9/arm in tip (1.7), but not 1.6.

I tried a bootstrapped version on my RPi but it fails with a "fork/exec ... 
virtual memory allocation failed” error when I try to compile anything. 
According to stats I have plenty of memory left when it runs. I’m not sure what 
to make of it. Any idea if the port is complete or if there are additional 
commits in progress?

For linux/s390x you can run it fairly easily (if slowly) in a Hercules emulator 
on Linux/Mac. I believe that there is at least one tutorial out there that I 
have successfully followed to get it working.

Chris

> On Apr 12, 2016, at 10:50 PM, Skip Tavakkolian  
> wrote:
> 
> I think Richards' CL's were submitted to main Go repo before Go 1.6 and are 
> now in 1.7 dev branch (tip). I believe I first saw the announcement on godev 
> list. as a Go user, it is a good way of keeping up with the fast-paced 
> development; e.g. IBM's linux/s390x port went in today!
> 
> I usually keep one environment in sync with the latest sources and try out 
> the new features that affect me the most, but I don't think there's anything 
> special about that.
> 
> Next to try on Plan 9: build a linux/s390x binary and find a machine to run 
> it on :)
> 
> 
> 
> On Tue, Apr 12, 2016 at 2:44 PM, > 
> wrote:
> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?
> 
> Perhaps even news to those who regularly use go on Plan 9.
> 
> sl
> 
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

I think Richards' CL's were submitted to main Go repo before Go 1.6 and are
now in 1.7 dev branch (tip). I believe I first saw the announcement on
godev list. as a Go user, it is a good way of keeping up with the
fast-paced development; e.g. IBM's linux/s390x port went in today!

I usually keep one environment in sync with the latest sources and try out
the new features that affect me the most, but I don't think there's
anything special about that.

Next to try on Plan 9: build a linux/s390x binary and find a machine to run
it on :)



On Tue, Apr 12, 2016 at 2:44 PM,  wrote:

> Skip, isn't the point here that being able to run go binaries
> in Plan 9 on an arm machine is news to most Plan 9 users?
>
> Perhaps even news to those who regularly use go on Plan 9.
>
> sl
>
>

Re: [9fans] Go on Plan 9?

[sl]

Skip, isn't the point here that being able to run go binaries
in Plan 9 on an arm machine is news to most Plan 9 users?

Perhaps even news to those who regularly use go on Plan 9.

sl

Re: [9fans] Go on Plan 9?

[Chris McGee]

Thanks,

I'll give it a shot.

I noticed that there are some assembly files in golang for plan9/386 and no 
equivalent for plan9/arm so I assumed that it wouldn't work with that 
combination.

Chris

> On Apr 12, 2016, at 5:26 PM, Skip Tavakkolian  
> wrote:
> 
> i've not built Go under plan9/arm.  however, in practice (in a real Plan 9 
> environment) this is not an issue. the way authentication and namespaces 
> (including file server) work in a Plan 9 envrionment, it is natural to use 
> the fastest cpu available to (cross) compile apps. typical sessions are like 
> this:
> 
> supermic% ls -l
> d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
> --rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
> --rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
> --rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
> --rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
> --rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
> --rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
> --rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
> --rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
> --rwxrwxr-x M 5543 fst fst 5977542 Apr 12 13:57 tcpmeter
> supermic% rm tcpmeter
> supermic% go build
> supermic% ls -ltr
> --rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
> --rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
> --rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
> --rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
> --rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
> --rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
> --rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
> --rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
> d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
> --rwxrwxr-x M 5543 fst fst 5855281 Apr 12 14:00 tcpmeter
> supermic% file tcpmeter
> tcpmeter: 386 plan 9 executable
> supermic% ./tcpmeter -?
> flag provided but not defined: -?
> 2016/04/12 14:00:31 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h 
> [host:]port] [-l logfile]
> supermic% GOARCH=arm go build
> supermic% file tcpmeter
> tcpmeter: arm plan 9 executable
> supermic% cpu -h rpi2
> rpi2% ./tcpmeter -?
> flag provided but not defined: -?
> 2016/04/12 14:04:35 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h 
> [host:]port] [-l logfile]
> rpi2% pwd
> /usr/fst/GoApps/src/tcpmeter
> rpi2% exit
> supermic% pwd
> /usr/fst/GoApps/src/tcpmeter
> supermic% 
> 
> Similar setup could be done under Linux/MacOSX with some work. I found this 
> article very helpful:
> https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec#.635w6yhi5
> 
> btw, building Go on rpi/linux, took some time.  i have not tried rpi3 yet 
> (waiting for 64bit plan9 or linux).  building Go on odroid-c2 (linux/arm64) 
> "feels" as speedy as on atom or i3.
> 
> 
>> On Tue, Apr 12, 2016 at 12:21 PM, Chris McGee  wrote:
>> Hi Skip,
>> 
>> Have you managed to get Go running on an RPi this way?
>> 
>> Cheers,
>> Chris
>> 
>> >
>> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be 
>> > easier/faster to cross compile your app and copy it over. E.g. to compile 
>> > for 9Pi:
>> > $ GOOS=plan9 GOARCH=arm go build
>> >
>> >
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

i've not built Go under plan9/arm.  however, in practice (in a real Plan 9
environment) this is not an issue. the way authentication and namespaces
(including file server) work in a Plan 9 envrionment, it is natural to use
the fastest cpu available to (cross) compile apps. typical sessions are
like this:

supermic% ls -l
d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
--rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
--rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
--rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
--rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
--rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
--rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
--rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
--rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
--rwxrwxr-x M 5543 fst fst 5977542 Apr 12 13:57 tcpmeter
supermic% rm tcpmeter
supermic% go build
supermic% ls -ltr
--rw-rw-r-- M 5543 fst fst6332 Feb 10  2013 client.go
--rw-rw-r-- M 5543 fst fst 450 Feb 10  2013 logger.go
--rw-rw-r-- M 5543 fst fst1071 Feb 10  2013 LICENSE
--rw-rw-r-- M 5543 fst fst1307 Feb 10  2013 main.go
--rw-rw-r-- M 5543 fst fst 206 Feb 10  2013 README
--rw-rw-r-- M 5543 fst fst   12477 Feb 10  2013 admui.go
--rw-rw-r-- M 5543 fst fst8623 Feb 10  2013 index.html
--rw-rw-r-- M 5543 fst fst4232 May 13  2013 server.go
d-rwxrwxr-x M 5543 fst fst   0 Jul 21  2015 .hg
--rwxrwxr-x M 5543 fst fst 5855281 Apr 12 14:00 tcpmeter
supermic% file tcpmeter
tcpmeter: 386 plan 9 executable
supermic% ./tcpmeter -?
flag provided but not defined: -?
2016/04/12 14:00:31 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h
[host:]port] [-l logfile]
supermic% GOARCH=arm go build
supermic% file tcpmeter
tcpmeter: arm plan 9 executable
supermic% cpu -h rpi2
rpi2% ./tcpmeter -?
flag provided but not defined: -?
2016/04/12 14:04:35 usage: ./tcpmeter (-c|-s) [-r [host:]port] [-h
[host:]port] [-l logfile]
rpi2% pwd
/usr/fst/GoApps/src/tcpmeter
rpi2% exit
supermic% pwd
/usr/fst/GoApps/src/tcpmeter
supermic%

Similar setup could be done under Linux/MacOSX with some work. I found this
article very helpful:
https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec#.635w6yhi5

btw, building Go on rpi/linux, took some time.  i have not tried rpi3 yet
(waiting for 64bit plan9 or linux).  building Go on odroid-c2 (linux/arm64)
"feels" as speedy as on atom or i3.


On Tue, Apr 12, 2016 at 12:21 PM, Chris McGee  wrote:

> Hi Skip,
>
> Have you managed to get Go running on an RPi this way?
>
> Cheers,
> Chris
>
> >
> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will
> be easier/faster to cross compile your app and copy it over. E.g. to
> compile for 9Pi:
> > $ GOOS=plan9 GOARCH=arm go build
> >
> >
>
>
>

Re: [9fans] Go on Plan 9?

[Dave MacFarlane]

I've managed to get Go running on an RPi2 using a similar method, but:

1. You need to make sure you're using go-tip. <= 1.6 doesn't have Plan9/arm
support.
2. I had to apply this patch that Richard Miller sent me to my kernel:

term% diff /n/sources/contrib/miller/9/bcm/mem.h /sys/src/9/bcm/mem.h
55c55
< #define   USTKTOP 0x2000  /* user segment end
+1 */
---
> #define   USTKTOP 0x4000  /* user segment end
+1 */

(Then realized that the git client I was writing in Go wasn't ready enough
to use
as a daily driver for developing Go programs under Plan9, so I didn't go
much
further than that and compiling a few test programs..)

-- Dave

On Tue, Apr 12, 2016 at 3:21 PM, Chris McGee  wrote:

> Hi Skip,
>
> Have you managed to get Go running on an RPi this way?
>
> Cheers,
> Chris
>
> >
> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will
> be easier/faster to cross compile your app and copy it over. E.g. to
> compile for 9Pi:
> > $ GOOS=plan9 GOARCH=arm go build
> >
> >
>
>
>


-- 
- Dave

Re: [9fans] Go on Plan 9?

[Chris McGee]

Hi Skip,

Have you managed to get Go running on an RPi this way?

Cheers,
Chris

> 
> If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be 
> easier/faster to cross compile your app and copy it over. E.g. to compile for 
> 9Pi:
> $ GOOS=plan9 GOARCH=arm go build
> 
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

Yes, this works and is the easier of the two methods.  Using a desktop OS
and starting no Go compilers:

1. download the Go 1.6 binaries for your desktop OS and install them; set
GOROOT_BOOTSTRAP to that directory (e.g. /usr/local/go)

2. copy the Go 1.6 sources (either the tar.gz or git clone of sources) to
your desktop OS; set GOROOT to that directory (e.g. $HOME/go)

3. build the bootstrap for Plan 9 (i.e. go-plan9-386-bootstrap.tbz) on your
desktop:
$ cd $GOROOT/src
$ GOOS=plan9 GOARCH=386 ./bootstrap.bash
   if all is well, this will produce ../../go-plan9-386-bootstrap.tbz

4. untar this in your Plan 9 environment and set GOROOT_BOOTSTRAP to that
directory; e.g. drawterm from your desktop OS to Plan 9:
% cd $home
% bunzip2 -c /mnt/term/path-to-go-plan9-386-bootstrap.tbz | tar -xv
% GOROOT_BOOTSTRAP=$home/go-plan9-386-bootstrap

5. copy Go 1.6 sources to your Plan 9 fs and set GOROOT to that directory;
e.g. drawterm from your desktop OS to Plan 9:
% mkdir $home/go
% dircp /mnt/term/path-of-GOROOT-on-desktop $home/go
% GOROOT=$home/go
% cd $GOROOT/src
% ./all.rc

If you run Plan 9 in a VM, emulator or a confined device (RPi), it will be
easier/faster to cross compile your app and copy it over. E.g. to compile
for 9Pi:
$ GOOS=plan9 GOARCH=arm go build

-Skip


On Mon, Apr 11, 2016 at 5:59 PM, Chris McGee  wrote:
>
>
> It may also be possible to cross compile a bootstrap of Go from
> Linux/Mac/Windows using the bootstrap.sh script after setting GOOS=plan9,
> GOARCH=386 and GO386=387. That bootstrap can be placed into plan9 and used
> as the GOROOT_BOOTSTRAP to compile a full Go installation on the plan9
> system.
>
>
>

Re: [9fans] Go on Plan 9?

[Chris McGee]

Hi All,

A while back there was a thread about getting newer versions of Go running on 
plan9. In particular there was a panic related to a floating point error.

In case anyone is interested I have managed to get the newest version of Go 
working on plan9/386 within virtualbox despite having a similar floating point 
error as was mentioned here before in that thread.

1) Download, extract and compile Go 1.4.3 from the source tarball
New versions of Go require older versions in order to compile through a 
bootstrapping process.
This is the last version that can be compiled without bootstrapping.
Modify the include/plan9/386/u.h and remove the line that has a typedef for 
intptr (in my 9front install this is already declared elsewhere).
Run the make.rc script in the src directory (don’t run all of the tests as many 
of them appear to fail)

2) Download, extract and compile Go 1.5.3
Set GOROOT_BOOTSTRAP to the go directory for 1.4.3 compiled above
Set GO386=387 (this is important as there appears to be a problem with sse2 
floating point with Go in my environment - plan9/386/virtualbox)
https://github.com/golang/go/issues/15234
Run the make.rc script (skip the tests for now)

3) Download, extract and compile Go 1.6
Set GOROOT_BOOTSTRAP to the 1.5.3 go directory
Run the all.rc script

Step 2 may not be necessary, but it worked for me this way.

It may also be possible to cross compile a bootstrap of Go from 
Linux/Mac/Windows using the bootstrap.sh script after setting GOOS=plan9, 
GOARCH=386 and GO386=387. That bootstrap can be placed into plan9 and used as 
the GOROOT_BOOTSTRAP to compile a full Go installation on the plan9 system.

I hope that this is useful information for others who are trying to get Go 
working on plan9.

Cheers,
Chris

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

> On 23 Feb 2016, at 18:31, lu...@proxima.alt.za wrote:
> 
>> A proper duffcopy/duffzero/memmove is also an option.
> 
> The adjective "proper" is revealing.  I vote for that.
> 
> Lucio.
> 
> 

It’s a bit out of my usual area of expertise, however. I have no idea what 
benchmark they have been running, either. Any pointers?

Kenny

Re: [9fans] Go: FP in note handler

[lucio]

> A proper duffcopy/duffzero/memmove is also an option.

The adjective "proper" is revealing.  I vote for that.

Lucio.

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

A proper duffcopy/duffzero/memmove is also an option.

Best regards,
Kenny Levinsen

> On 23. feb. 2016, at 18.02, erik quanstrom  wrote:
> 
>> On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
>> A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
>> significant speedup for larger copies: 
>> https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
>> 
>> I have no clue whether this holds true or not. My intention to reenable 
>> duffcopy and continue to use duffzero is mostly to avoid differences and 
>> ensure that the note handlers are floating point free in the future. Whether 
>> the duffcopy/duffzero’s current form is an actual optimization or just a 
>> complexity, I cannot say. A test was made in #cat-v out of annoyance where 
>> the result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
>> remember the details.
> 
> that post is a speedup relative to the original asm, which might not be as 
> good as the best
> non-sse versions, and it is also for amd64.
> 
> - erik
> 

Re: [9fans] Go: FP in note handler

[erik quanstrom]

On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote:
> A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
> significant speedup for larger copies: 
> https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da
> 
> I have no clue whether this holds true or not. My intention to reenable 
> duffcopy and continue to use duffzero is mostly to avoid differences and 
> ensure that the note handlers are floating point free in the future. Whether 
> the duffcopy/duffzero’s current form is an actual optimization or just a 
> complexity, I cannot say. A test was made in #cat-v out of annoyance where 
> the result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
> remember the details.

that post is a speedup relative to the original asm, which might not be as good 
as the best
non-sse versions, and it is also for amd64.

- erik

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

A benchmark was supposedly made of the new duffcopy/duffzero which claimed 
significant speedup for larger copies: 
https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da

I have no clue whether this holds true or not. My intention to reenable 
duffcopy and continue to use duffzero is mostly to avoid differences and ensure 
that the note handlers are floating point free in the future. Whether the 
duffcopy/duffzero’s current form is an actual optimization or just a 
complexity, I cannot say. A test was made in #cat-v out of annoyance where the 
result seemed to be that it was indeed faster to use MOVUPS, but I don’t 
remember the details.

Best regards,
Kenny Levinsen

> On 23 Feb 2016, at 16:27, erik quanstrom  wrote:
> 
> On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote:
>> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
>> specific runtime.sighandler implementation and everything called by it 
>> directly. Notes that don't exit the process are queued and should run 
>> outside the actual note handler.
>> 
>> I think the "magic" code will be isolated, and might fend off accidental 
>> future additions of floating point registers. The magic-ness also only 
>> revolves around avoiding duffzero and duffcopy in some way. I also think 
>> that removing conditionals in the compiler will be a positive thing.
>> 
>> I still do not know the feasibility of my plan, whether it is possible to do 
>> cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
>> the matter could chime in and call me an idiot?
>> 
>> Avoiding duffcopy should be easy with a simple memmove implementation. If 
>> done right, we can also remove the plan9 specific runtime.memmove and only 
>> use the slow memmove in sighandler (The globlal runtime.memmove is 
>> implemented using MOVUPS just like duffcopy. Duffcopy is used for 
>> blockcopies by the compiler in some cases, although I must admit to not know 
>> all the cases yet).
>> 
>> Avoiding duffzero without compiler assistance is a bit more tricky - global 
>> variables, stack on assembly functions, something like that.
> 
> fwiw, on modern amd64 machines, using the xmm and ymm registers has a benefit 
> only in a narrow range
> of sizes (384-511 bytes) and a subset of (mis-)alignments that i've 
> forgotten.  at least for the exact test setup
> i used on 3-4 different µarches.  intel claims rep; movs is the 
> (architecturally) fastest way to go.
> 
> i am not sure any of this makes much difference, as it's hard to know what a 
> real-world memory
> access pattern looks like, and that seems to dominate all but gigantic moves, 
> for which rep; movs
> is actually no slower than even the trickiest use of ymm registers.
> 
> - erik
> 

Re: [9fans] Go: FP in note handler

[erik quanstrom]

On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote:
> Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
> specific runtime.sighandler implementation and everything called by it 
> directly. Notes that don't exit the process are queued and should run outside 
> the actual note handler.
> 
> I think the "magic" code will be isolated, and might fend off accidental 
> future additions of floating point registers. The magic-ness also only 
> revolves around avoiding duffzero and duffcopy in some way. I also think that 
> removing conditionals in the compiler will be a positive thing.
> 
> I still do not know the feasibility of my plan, whether it is possible to do 
> cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
> the matter could chime in and call me an idiot?
> 
> Avoiding duffcopy should be easy with a simple memmove implementation. If 
> done right, we can also remove the plan9 specific runtime.memmove and only 
> use the slow memmove in sighandler (The globlal runtime.memmove is 
> implemented using MOVUPS just like duffcopy. Duffcopy is used for blockcopies 
> by the compiler in some cases, although I must admit to not know all the 
> cases yet).
> 
> Avoiding duffzero without compiler assistance is a bit more tricky - global 
> variables, stack on assembly functions, something like that.

fwiw, on modern amd64 machines, using the xmm and ymm registers has a benefit 
only in a narrow range
of sizes (384-511 bytes) and a subset of (mis-)alignments that i've forgotten.  
at least for the exact test setup
i used on 3-4 different µarches.  intel claims rep; movs is the 
(architecturally) fastest way to go.

i am not sure any of this makes much difference, as it's hard to know what a 
real-world memory
access pattern looks like, and that seems to dominate all but gigantic moves, 
for which rep; movs
is actually no slower than even the trickiest use of ymm registers.

- erik

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 
specific runtime.sighandler implementation and everything called by it 
directly. Notes that don't exit the process are queued and should run outside 
the actual note handler.

I think the "magic" code will be isolated, and might fend off accidental future 
additions of floating point registers. The magic-ness also only revolves around 
avoiding duffzero and duffcopy in some way. I also think that removing 
conditionals in the compiler will be a positive thing.

I still do not know the feasibility of my plan, whether it is possible to do 
cleanly, or possible at all. Maybe someone smarter than me with knowledge on 
the matter could chime in and call me an idiot?

Avoiding duffcopy should be easy with a simple memmove implementation. If done 
right, we can also remove the plan9 specific runtime.memmove and only use the 
slow memmove in sighandler (The globlal runtime.memmove is implemented using 
MOVUPS just like duffcopy. Duffcopy is used for blockcopies by the compiler in 
some cases, although I must admit to not know all the cases yet).

Avoiding duffzero without compiler assistance is a bit more tricky - global 
variables, stack on assembly functions, something like that.

Best regards,
Kenny Levinsen

On 23. feb. 2016, at 10.05, lu...@proxima.alt.za wrote:

>> Well, avoiding XMM registers in duffcopy/duffzero is one solution, but
>> I was thinking of working around them entirely in code called from the
>> note handler, so that duffcopy/duffzero can operate as intended on
>> plan9, rather than littering the compiler with OS conditionals.
> 
> Do you think you'll be able to sell that to the Go developers?  You
> ARE talking about a system-wide adjustment and it seems to me that it
> will need constant supervision to be maintained.  Again, I may have
> misunderstood, but it does seem like a maintenance nightmare to me.
> 
> As for:
> 
>> To fix the duffzero, we'd have to fix runtime.goexitsall's buffer
>> usage, but to reenable duffcopy, we'd have to look at the much bigger
>> runtime.sighandler.
> 
> That is undeniable, but to avoid a different type of maintenance
> nightmare, may be the only option.  Although "fixing" duffcopy and
> duffzero would seem a better, if less efficient option.
> 
> Still, it's the opinion of a none-too-well-informed spectator, do not
> let me spoil it for you.  In particular, I'm sure I'm not telling you
> anything you have not already considered.
> 
> Lucio.
> 
> PS: I do think that it is our responsibility to track each and every
> aspect of Go where Plan 9 demands special treatment.  Ideally, this
> means build flags or specially named modules and a commitment from a
> few of us to keep these in sync.  Anything else becomes someone else's
> responsibility and that is risky.
> 

Re: [9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

Well, avoiding XMM registers in duffcopy/duffzero is one solution, but I was 
thinking of working around them entirely in code called from the note handler, 
so that duffcopy/duffzero can operate as intended on plan9, rather than 
littering the compiler with OS conditionals.

It puts some restrictions on the note handling code, such as no copy(), make() 
or even an on-stack var b [n]byte. Due to sighandler disabling write barriers, 
we can't currently allocate on the heap, meaning that we might need either 
locked global buffers (which can be duffzeroed) or more assembly so we can use 
on-stack buffers (which could be zeroed if we wanted to, they just can't use 
duffzero for it).

To fix the duffzero, we'd have to fix runtime.goexitsall's buffer usage, but to 
reenable duffcopy, we'd have to look at the much bigger runtime.sighandler.

Best regards,
Kenny Levinsen

On 23. feb. 2016, at 08.20, lu...@proxima.alt.za wrote:

>> Duffcopy is disabled from plan9 after the last bug report on the
>> matter, but duffzero was later optimized to use XMM registers, causing
>> goexitsall, which use an on-stack byte array to make a new note, to
>> call duffzero and trip the fp in note handler message.
> 
> I had to re-read this to understand this because you tend to put at
> the end what I would find easier to understand if it was at the
> beginning.  No offence meant, different punctuation would have perhaps
> helped my understanding.
> 
> So, we need a duffcopy and duffzero that do not use XMM registers,
> rather than stop invoking them, if I read your comment correctly?
> 
> I also have an open issue (I see David has offered to look into it
> soon) involving syscalls and their error messages, it seems these are
> all Plan 9 specific issues that could be addressed together.
> 
> I really would like to take a more active role in Go for Plan 9, but I
> can't yet give it the priority I'd like.  Still, I like hearing from
> others who take this to heart.
> 
> Lucio.
> 

[9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

For those interested in the matter, I have opened 
https://github.com/golang/go/issues/14471

I mention potentially reenabling duffcopy by writing some magic note handler 
code that avoid the regular copy and zero optimizations, but I’m not entirely 
sure if that’s a plausible path. If it is, I think it would bring benefit, both 
in the performance gained by duffcopy/duffzero, as well as the chances of this 
happening again. It is, however, slightly annoying to do, as you cannot use 
copy(), make() or even strings or byte array literals, as these will trip 
duffcopy and duffzero. Any comments to my silly idea?

Best regards,
Kenny Levinsen

> On 22 Feb 2016, at 18:16, Richard Miller  wrote:
> 
>> The trace of goexitsall still contain FP register access (XORPS and duffzero 
>> which contains MOVUPS)
> 
> Sorry, in that case I think my patch is not relevant for your issue
> (but it does prevent a deadlock on multiprocessors which you might
> also run into...)
> 

Re: [9fans] Go on Plan 9?

[Charles Forsyth]

On 27 January 2016 at 01:40, Sean Caron  wrote:

> update process running:
>
> replica/pull -v /dist/replica/network
>

Beware that the introduction of the nsec system call can cause trouble if
replica updates commands before you're running the new kernel.

Re: [9fans] Go on Plan 9?

[David du Colombier]

> Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
> so good for my current running system. It looks like it might make the most
> sense to just archive my home directory and reload a fresh VM ...
>
> Where are they keeping the most current installation ISO these days? I'm
> just not sure of what's canonical now that the old bell-labs.com domain is
> offline.

You can download the latest Plan 9 CD image here:

https://9p.io/plan9/download/plan9.iso.bz2

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[lucio]

> Where are they keeping the most current installation ISO these days? I'm
> just not sure of what's canonical now that the old bell-labs.com domain is
> offline.

David is in charge of legacy Plan 9 outside of Bell Labs. His instructions were 
pretty explicit, but if you run into trouble I'll be happy to guide you. I 
can't always remember how my Plan 9 (legacy) system is different from the 
distribution, but it runs Go (tip) more than adequately (I actually have two 
production systems).

Installing from CD isn't always successful, even from David's legacy site. I 
did have to make some allowance for the ESX 3.5i instance that is running as 
fumble.proxima.alt.za.

Lucio.

[9fans] Go on Plan 9?

[Sean Caron]

Hi all,

I've been getting interested in programming in Go recently and it's my
understanding that at some point in time, Plan 9 was a supported
environment in which one could bootstrap and use Go?

I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
the directions that I found on a blog somewhere, i.e:

tar xf go 1.4.2.tar
cd go-go1.4.2/src
./all.rc

But it fails almost immediately trying to bootstrap Go:

cpu% ./all.rc
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, plan9/386.
lib9
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
/usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:6
/usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const

I get a fair number of these errors for various header files, then some
more worrisome output:

/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:7
/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
char const
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
/usr/scaron/go-go1.4.2/src/lib9/flag.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
/usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
/usr/scaron/go-go1.4.2/include/plan9/utf.h:5
/usr/scaron/go-go1.4.2/include/plan9/libc.h:7
/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
const
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
external redeclaration of: Rune
TYPEDEF UINT
/usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
TYPEDEF USHORT
/386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:21]
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/charstod.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
-D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
-I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
/usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dofmt.8
/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:
'/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist

At that point the build fails and I drop back to the rc prompt.

While the example I cite above is for version 1.4.2, I believe the failure
mode is pretty much the same for both earlier and later versions that I've
tried to build.

Is my Plan 9 installation "too old"? I'm using pretty bog-standard Fourth
Edition on this particular instance; 9atom doesn't seem to get along with
VMware ESXi (at least, not last time I checked).

Any help greatly appreciated! I'd love to be able to use Go within Plan 9.

Thanks,

Sean

Re: [9fans] Go on Plan 9?

[sl]

>From http://fqa.9front.org/appendixl.html:

# automatically converted ca certs from mozilla.org
hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
# shell script that emulates git commands
hget http://9front.org/extra/rc/git >$home/bin/rc/git
chmod 775 $home/bin/rc/git
# fetch the repository
git clone https://go.googlesource.com/go
cd go
git checkout go1.4.2
# build go
cd src
./make.rc
# install documentation
go get golang.org/x/tools/cmd/godoc
# go!

Newer versions of go seem to have problems with Plan 9.

sl

Re: [9fans] Go on Plan 9?

[Kenny Lasse Hoff Levinsen]

Go builds just fine right now on the plan9 builders: http://build.golang.org

1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and amd64 
should both build, although amd64 fails an irrelevant unittest.

What do you see with 1.5.2/1.5.3? (You said you tried?)

Best regards,
Kenny Levinsen // joushou

> On 26 Jan 2016, at 22:52, s...@9front.org wrote:
> 
> From http://fqa.9front.org/appendixl.html:
> 
>   # automatically converted ca certs from mozilla.org
>   hget http://curl.haxx.se/ca/cacert.pem >/sys/lib/tls/ca.pem
>   # shell script that emulates git commands
>   hget http://9front.org/extra/rc/git >$home/bin/rc/git
>   chmod 775 $home/bin/rc/git
>   # fetch the repository
>   git clone https://go.googlesource.com/go
>   cd go
>   git checkout go1.4.2
>   # build go
>   cd src
>   ./make.rc
>   # install documentation
>   go get golang.org/x/tools/cmd/godoc
>   # go!
> 
> Newer versions of go seem to have problems with Plan 9.
> 
> sl
> 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

All the errors seem related to the old Rune size. I suspect you're running
an old system and it's likely to not have nsec and tsemacquire syscalls
either.

If you believe the system is up-to-date, you can cross compile a simple Go
program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
or Windows box and see if it runs on your system.  That might give you more
info.



On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:

> Hi all,
>
> I've been getting interested in programming in Go recently and it's my
> understanding that at some point in time, Plan 9 was a supported
> environment in which one could bootstrap and use Go?
>
> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
> the directions that I found on a blog somewhere, i.e:
>
> tar xf go 1.4.2.tar
> cd go-go1.4.2/src
> ./all.rc
>
> But it fails almost immediately trying to bootstrap Go:
>
> cpu% ./all.rc
> # Building C bootstrap tool.
> cmd/dist
>
> # Building compilers and Go bootstrap tool for host, plan9/386.
> lib9
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>
> I get a fair number of these errors for various header files, then some
> more worrisome output:
>
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
> char const
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
> const
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:21]
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/charstod.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:
> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dofmt.8
> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:
> 

Re: [9fans] Go on Plan 9?

[Sean Caron]

Thanks, Skip. That would follow; this system is probably straight Fourth
Edition, certainly an old ISO...

I've never been 100% clear on the process for running updates; can I bring
myself up to current from where I'm at now and not have to reload or build
a fresh system? It's a VM and I can snapshot so I'm willing to give
anything a try ...

I'm looking at the directions in a (cached copy) of
http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...

Is that still valid? What's the canonical procedure these days for updating
a system?

If that's roughly correct ... I'm running a single Plan 9 machine, combined
CPU and fileserver ... I run that command as the bootes user on the system
console?

Thanks!

Sean


On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> All the errors seem related to the old Rune size. I suspect you're running
> an old system and it's likely to not have nsec and tsemacquire syscalls
> either.
>
> If you believe the system is up-to-date, you can cross compile a simple Go
> program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
> or Windows box and see if it runs on your system.  That might give you more
> info.
>
>
>
> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>
>> Hi all,
>>
>> I've been getting interested in programming in Go recently and it's my
>> understanding that at some point in time, Plan 9 was a supported
>> environment in which one could bootstrap and use Go?
>>
>> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
>> the directions that I found on a blog somewhere, i.e:
>>
>> tar xf go 1.4.2.tar
>> cd go-go1.4.2/src
>> ./all.rc
>>
>> But it fails almost immediately trying to bootstrap Go:
>>
>> cpu% ./all.rc
>> # Building C bootstrap tool.
>> cmd/dist
>>
>> # Building compilers and Go bootstrap tool for host, plan9/386.
>> lib9
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
>> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>>
>> I get a fair number of these errors for various header files, then some
>> more worrisome output:
>>
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
>> char const
>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or char
>> const
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
>> external redeclaration of: Rune
>> TYPEDEF UINT
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:152]
>> TYPEDEF USHORT
>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:21]
>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:152]
>> external 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> All the errors seem related to the old Rune size. I suspect you're running
> an old system and it's likely to not have nsec and tsemacquire syscalls
> either.
>
> If you believe the system is up-to-date, you can cross compile a simple Go
> program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a Linux/OSX
> or Windows box and see if it runs on your system.  That might give you more
> info.

Yes, Skip is right. On your system Rune is defined as ushort instead of uint.
The change from ushort to uint was done in April 2013.

While you could successfully cross-compile Go 1.5, it will probably
not work on your machine. In fact, the nsec system call will likely be
missing as well, since it was introduced in Plan 9 in May 2014.

You should update your system.

Since plan9.bell-labs.com is currently down, you could either change
your 9fs script and change it to pull from 9p.io, like this:

http://9legacy.org/9legacy/patch/9fs-9p.io.diff

Or use the latest Plan 9 CD image:

http://9p.io/plan9/download/plan9.iso.bz2

Then, you will be able to compile and execute Go 1.4, 1.5 and 1.6 successfully.

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[sl]

> Go builds just fine right now on the plan9 builders: http://build.golang.org
> 
> 1.4 and 1.5 are very different, due to 1.5 being written in Go. i386 and 
> amd64 should both build, although amd64 fails an irrelevant unittest.
> 
> What do you see with 1.5.2/1.5.3? (You said you tried?)

Note: I'm running 9front. I can build on amd64 but not 386. Last attempt
was 1.5 on 386, bootstrapped with 1.4.2:

dl; go version
go version go1.4.2 plan9/386
dl; GOROOT_BOOTSTRAP=/usr/local/go
dl; ./make.rc
# Building Go bootstrap tool.
cmd/dist

# Building Go toolchain using /usr/local/go.
bootstrap/internal/obj
bootstrap/asm/internal/flags
bootstrap/compile/internal/big
bootstrap/internal/obj/arm
bootstrap/internal/obj/arm64
bootstrap/internal/obj/ppc64
bootstrap/internal/obj/x86
bootstrap/asm/internal/lex
bootstrap/asm/internal/arch
bootstrap/internal/gcprog
bootstrap/compile/internal/gc
bootstrap/asm/internal/asm
bootstrap/asm
bootstrap/link/internal/ld
bootstrap/compile/internal/amd64
bootstrap/compile/internal/arm
bootstrap/compile/internal/arm64
bootstrap/compile/internal/ppc64
bootstrap/compile/internal/x86
bootstrap/link/internal/amd64
bootstrap/compile
bootstrap/link/internal/arm
bootstrap/link/internal/arm64
bootstrap/link/internal/ppc64
bootstrap/link/internal/x86
bootstrap/link

# Building go_bootstrap for host, plan9/386.
runtime
panic: runtime error: floating point error
[signal 0x5 code=0x18837950 addr=0x8e826 pc=0x1f3f87]

goroutine 1 [running]:
bootstrap/compile/internal/big.nat.string(0x10b52000, 0x10, 0x16, 
0x3511a8, 0xa, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:265 +0x117
bootstrap/compile/internal/big.nat.decimalString(0x10b52000, 0x10, 
0x16, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:241 +0x6c
bootstrap/compile/internal/big.(*Float).fmtB(0x10b769c0, 0x154f35a0, 
0x0, 0xa, 0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:258 
+0x136
bootstrap/compile/internal/big.(*Float).Append(0x10b769c0, 0x154f35a0, 
0x0, 0xa, 0x62, 0x0, 0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:73 
+0x249
bootstrap/compile/internal/big.(*Float).Text(0x10b769c0, 0x154f3562, 
0x0, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:46 
+0x98
bootstrap/compile/internal/gc.Fconv(0x10b769c0, 0x0, 0x0, 0x0)

/usr/local/386/go1.5/src/cmd/compile/internal/gc/mparith3.go:208 +0x6b
bootstrap/compile/internal/gc.Vconv(0x2f0360, 0x10b769c0, 0x8, 0x0, 0x0)
/usr/local/386/go1.5/src/cmd/compile/internal/gc/fmt.go:327 
+0x544
bootstrap/compile/internal/gc.dumpasmhdr()
/usr/local/386/go1.5/src/cmd/compile/internal/gc/export.go:544 
+0x748
bootstrap/compile/internal/gc.Main()
/usr/local/386/go1.5/src/cmd/compile/internal/gc/lex.go:495 
+0x19c0
bootstrap/compile/internal/x86.Main()
/usr/local/386/go1.5/src/cmd/compile/internal/x86/galign.go:108 
+0x5ff
main.main()
/usr/local/386/go1.5/src/cmd/compile/main.go:24 +0x9a
go tool dist: FAILED: /usr/local/386/go1.5/pkg/tool/plan9_386/compile 
-pack -o /tmp/go-tool-dist-289352163/_go_.a -p runtime -+ -asmhdr 
/tmp/go-tool-dist-289352163/go_asm.h /usr/local/386/go1.5/src/runtime/alg.go 
/usr/local/386/go1.5/src/runtime/arch1_386.go 
/usr/local/386/go1.5/src/runtime/arch_386.go 
/usr/local/386/go1.5/src/runtime/atomic_386.go 
/usr/local/386/go1.5/src/runtime/atomic_pointer.go 
/usr/local/386/go1.5/src/runtime/cgo.go 
/usr/local/386/go1.5/src/runtime/cgocall.go 
/usr/local/386/go1.5/src/runtime/cgocallback.go 
/usr/local/386/go1.5/src/runtime/chan.go 
/usr/local/386/go1.5/src/runtime/compiler.go 
/usr/local/386/go1.5/src/runtime/complex.go 
/usr/local/386/go1.5/src/runtime/cpuprof.go 
/usr/local/386/go1.5/src/runtime/cputicks.go 
/usr/local/386/go1.5/src/runtime/debug.go 
/usr/local/386/go1.5/src/runtime/defs_plan9_386.go 
/usr/local/386/go1.5/src/runtime/env_plan9.go 
/usr/local/386/go1.5/src/runtime/error.go 
/usr/local/386/go1.5/src/runtime/extern.go /usr/local/386/go1.5
 /src/runtime/hash32.go /usr/local/386/go1.5/src/runtime/hashmap.go 
/usr/local/386/go1.5/src/runtime/hashmap_fast.go 
/usr/local/386/go1.5/src/runtime/heapdump.go 
/usr/local/386/go1.5/src/runtime/iface.go 
/usr/local/386/go1.5/src/runtime/lfstack.go 
/usr/local/386/go1.5/src/runtime/lfstack_32bit.go 
/usr/local/386/go1.5/src/runtime/lock_sema.go 
/usr/local/386/go1.5/src/runtime/malloc.go 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> I'm looking at the directions in a (cached copy) of
> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>
> Is that still valid? What's the canonical procedure these days for updating
> a system?
>
> If that's roughly correct ... I'm running a single Plan 9 machine, combined
> CPU and fileserver ... I run that command as the bootes user on the system
> console?

This is a bit more complicated because of two reasons:

1. The plan9.bell-labs.com server is currently down.
2. Your system is too old, and running the new binaries will require
   a new kernel with the nsec syscall.

I think the easiest for you would be to apply this patch:

% hget http://9legacy.org/9legacy/patch/9fs-9p.io.diff | ape/patch -p0

Then, install the new kernel binaries to get the new nsec syscall:

% 9fs sources
% 9fat:
% cp /n/sources/plan9/386/9pcf /n/9fat
% cp /n/sources/plan9/386/9pccpu /n/9fat
% hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat
% unmount /n/9fat

Then, reboot your machine to run the new kernel.

Finally, update your system:

% /usr/glenda/bin/rc/pull

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[David du Colombier]

> Note: I'm running 9front. I can build on amd64 but not 386. Last attempt
> was 1.5 on 386, bootstrapped with 1.4.2:
>
> dl; go version
> go version go1.4.2 plan9/386
> dl; GOROOT_BOOTSTRAP=/usr/local/go
> dl; ./make.rc
> # Building Go bootstrap tool.
> cmd/dist
>
> # Building Go toolchain using /usr/local/go.
> bootstrap/internal/obj
> bootstrap/asm/internal/flags
> bootstrap/compile/internal/big
> bootstrap/internal/obj/arm
> bootstrap/internal/obj/arm64
> bootstrap/internal/obj/ppc64
> bootstrap/internal/obj/x86
> bootstrap/asm/internal/lex
> bootstrap/asm/internal/arch
> bootstrap/internal/gcprog
> bootstrap/compile/internal/gc
> bootstrap/asm/internal/asm
> bootstrap/asm
> bootstrap/link/internal/ld
> bootstrap/compile/internal/amd64
> bootstrap/compile/internal/arm
> bootstrap/compile/internal/arm64
> bootstrap/compile/internal/ppc64
> bootstrap/compile/internal/x86
> bootstrap/link/internal/amd64
> bootstrap/compile
> bootstrap/link/internal/arm
> bootstrap/link/internal/arm64
> bootstrap/link/internal/ppc64
> bootstrap/link/internal/x86
> bootstrap/link
>
> # Building go_bootstrap for host, plan9/386.
> runtime
> panic: runtime error: floating point error
> [signal 0x5 code=0x18837950 addr=0x8e826 pc=0x1f3f87]
>
> goroutine 1 [running]:
> bootstrap/compile/internal/big.nat.string(0x10b52000, 0x10, 0x16, 
> 0x3511a8, 0xa, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:265 +0x117
> bootstrap/compile/internal/big.nat.decimalString(0x10b52000, 0x10, 
> 0x16, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/big/natconv.go:241 +0x6c
> bootstrap/compile/internal/big.(*Float).fmtB(0x10b769c0, 0x154f35a0, 
> 0x0, 0xa, 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:258 
> +0x136
> bootstrap/compile/internal/big.(*Float).Append(0x10b769c0, 
> 0x154f35a0, 0x0, 0xa, 0x62, 0x0, 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:73 
> +0x249
> bootstrap/compile/internal/big.(*Float).Text(0x10b769c0, 0x154f3562, 
> 0x0, 0x0, 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/big/ftoa.go:46 
> +0x98
> bootstrap/compile/internal/gc.Fconv(0x10b769c0, 0x0, 0x0, 0x0)
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/mparith3.go:208 +0x6b
> bootstrap/compile/internal/gc.Vconv(0x2f0360, 0x10b769c0, 0x8, 0x0, 
> 0x0)
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/fmt.go:327 
> +0x544
> bootstrap/compile/internal/gc.dumpasmhdr()
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/export.go:544 +0x748
> bootstrap/compile/internal/gc.Main()
> /usr/local/386/go1.5/src/cmd/compile/internal/gc/lex.go:495 
> +0x19c0
> bootstrap/compile/internal/x86.Main()
> 
> /usr/local/386/go1.5/src/cmd/compile/internal/x86/galign.go:108 +0x5ff
> main.main()
> /usr/local/386/go1.5/src/cmd/compile/main.go:24 +0x9a
> go tool dist: FAILED: /usr/local/386/go1.5/pkg/tool/plan9_386/compile 
> -pack -o /tmp/go-tool-dist-289352163/_go_.a -p runtime -+ -asmhdr 
> /tmp/go-tool-dist-289352163/go_asm.h /usr/local/386/go1.5/src/runtime/alg.go 
> /usr/local/386/go1.5/src/runtime/arch1_386.go 
> /usr/local/386/go1.5/src/runtime/arch_386.go 
> /usr/local/386/go1.5/src/runtime/atomic_386.go 
> /usr/local/386/go1.5/src/runtime/atomic_pointer.go 
> /usr/local/386/go1.5/src/runtime/cgo.go 
> /usr/local/386/go1.5/src/runtime/cgocall.go 
> /usr/local/386/go1.5/src/runtime/cgocallback.go 
> /usr/local/386/go1.5/src/runtime/chan.go 
> /usr/local/386/go1.5/src/runtime/compiler.go 
> /usr/local/386/go1.5/src/runtime/complex.go 
> /usr/local/386/go1.5/src/runtime/cpuprof.go 
> /usr/local/386/go1.5/src/runtime/cputicks.go 
> /usr/local/386/go1.5/src/runtime/debug.go 
> /usr/local/386/go1.5/src/runtime/defs_plan9_386.go 
> /usr/local/386/go1.5/src/runtime/env_plan9.go 
> /usr/local/386/go1.5/src/runtime/error.go 
> /usr/local/386/go1.5/src/runtime/extern.go /usr/local/386/go1.5
>  /src/runtime/hash32.go /usr/local/386/go1.5/src/runtime/hashmap.go 
> /usr/local/386/go1.5/src/runtime/hashmap_fast.go 
> /usr/local/386/go1.5/src/runtime/heapdump.go 
> /usr/local/386/go1.5/src/runtime/iface.go 
> /usr/local/386/go1.5/src/runtime/lfstack.go 
> /usr/local/386/go1.5/src/runtime/lfstack_32bit.go 
> /usr/local/386/go1.5/src/runtime/lock_sema.go 
> /usr/local/386/go1.5/src/runtime/malloc.go 
> /usr/local/386/go1.5/src/runtime/mbarrier.go 
> /usr/local/386/go1.5/src/runtime/mbitmap.go 
> 

Re: [9fans] Go on Plan 9?

[David du Colombier]

> % 9fs sources
> % 9fat:
> % cp /n/sources/plan9/386/9pcf /n/9fat
> % cp /n/sources/plan9/386/9pccpu /n/9fat
> % hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat

Of course, I mean:

hget http://www.9legacy.org/download/kernel/9pccpuf >/n/9fat/9pccpuf

-- 
David du Colombier

Re: [9fans] Go on Plan 9?

[Matthew Veety]

Also the ports tree[1] version of golang should install fine. I haven't
tried it in a while, but also haven't changed it so it should work. That
will grab the ca certs and install (I think) 1.3.

--
Veety

Re: [9fans] Go on Plan 9?

[Sean Caron]

Answering my own silly question, on my fossil-based system, running the
following command on the console as the bootes user seems to get the update
process running:

replica/pull -v /dist/replica/network

I'll wait for this to complete and then give building Go another shot.
Thanks for answering my shot in the dark!

Thanks,

Sean


On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:

> Thanks, Skip. That would follow; this system is probably straight Fourth
> Edition, certainly an old ISO...
>
> I've never been 100% clear on the process for running updates; can I bring
> myself up to current from where I'm at now and not have to reload or build
> a fresh system? It's a VM and I can snapshot so I'm willing to give
> anything a try ...
>
> I'm looking at the directions in a (cached copy) of
> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>
> Is that still valid? What's the canonical procedure these days for
> updating a system?
>
> If that's roughly correct ... I'm running a single Plan 9 machine,
> combined CPU and fileserver ... I run that command as the bootes user on
> the system console?
>
> Thanks!
>
> Sean
>
>
> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
> skip.tavakkol...@gmail.com> wrote:
>
>> All the errors seem related to the old Rune size. I suspect you're
>> running an old system and it's likely to not have nsec and tsemacquire
>> syscalls either.
>>
>> If you believe the system is up-to-date, you can cross compile a simple
>> Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
>> Linux/OSX or Windows box and see if it runs on your system.  That might
>> give you more info.
>>
>>
>>
>> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>>
>>> Hi all,
>>>
>>> I've been getting interested in programming in Go recently and it's my
>>> understanding that at some point in time, Plan 9 was a supported
>>> environment in which one could bootstrap and use Go?
>>>
>>> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just following
>>> the directions that I found on a blog somewhere, i.e:
>>>
>>> tar xf go 1.4.2.tar
>>> cd go-go1.4.2/src
>>> ./all.rc
>>>
>>> But it fails almost immediately trying to bootstrap Go:
>>>
>>> cpu% ./all.rc
>>> # Building C bootstrap tool.
>>> cmd/dist
>>>
>>> # Building compilers and Go bootstrap tool for host, plan9/386.
>>> lib9
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
>>> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
>>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>>>
>>> I get a fair number of these errors for various header files, then some
>>> more worrisome output:
>>>
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>>> external redeclaration of: Rune
>>> TYPEDEF UINT
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
>>> TYPEDEF USHORT
>>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>>> external redeclaration of: Rune
>>> TYPEDEF UINT
>>> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
>>> TYPEDEF USHORT
>>> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
>>> char const
>>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
>>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>>> go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
>>> -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
>>> -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
>>> /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/flag.8
>>> /usr/scaron/go-go1.4.2/src/lib9/flag.c:
>>> '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
>>> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
>>> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
>>> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
>>> /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
>>> /usr/scaron/go-go1.4.2/src/lib9/fmt/dofmt.c:20 Unterminated string or 

Re: [9fans] Go on Plan 9?

[Skip Tavakkolian]

Sean,

David's (0intro) instructions are the right way to do it.  If I recall
correctly, if you want to update by rebuilding from updated sources,
there's a careful dance that needs to happen for the transition from old
Rune size to the new.  Geoff sent out a note to 9fans outlining the steps
at that time; you might be able to find it on 9fans archive (which
unfortunately is not what it used to be).

-Skip


On Tue, Jan 26, 2016 at 5:40 PM Sean Caron  wrote:

> Answering my own silly question, on my fossil-based system, running the
> following command on the console as the bootes user seems to get the update
> process running:
>
> replica/pull -v /dist/replica/network
>
> I'll wait for this to complete and then give building Go another shot.
> Thanks for answering my shot in the dark!
>
> Thanks,
>
> Sean
>
>
> On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:
>
>> Thanks, Skip. That would follow; this system is probably straight Fourth
>> Edition, certainly an old ISO...
>>
>> I've never been 100% clear on the process for running updates; can I
>> bring myself up to current from where I'm at now and not have to reload or
>> build a fresh system? It's a VM and I can snapshot so I'm willing to give
>> anything a try ...
>>
>> I'm looking at the directions in a (cached copy) of
>> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>>
>> Is that still valid? What's the canonical procedure these days for
>> updating a system?
>>
>> If that's roughly correct ... I'm running a single Plan 9 machine,
>> combined CPU and fileserver ... I run that command as the bootes user on
>> the system console?
>>
>> Thanks!
>>
>> Sean
>>
>>
>> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
>> skip.tavakkol...@gmail.com> wrote:
>>
>>> All the errors seem related to the old Rune size. I suspect you're
>>> running an old system and it's likely to not have nsec and tsemacquire
>>> syscalls either.
>>>
>>> If you believe the system is up-to-date, you can cross compile a simple
>>> Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
>>> Linux/OSX or Windows box and see if it runs on your system.  That might
>>> give you more info.
>>>
>>>
>>>
>>> On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:
>>>
 Hi all,

 I've been getting interested in programming in Go recently and it's my
 understanding that at some point in time, Plan 9 was a supported
 environment in which one could bootstrap and use Go?

 I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just
 following the directions that I found on a blog somewhere, i.e:

 tar xf go 1.4.2.tar
 cd go-go1.4.2/src
 ./all.rc

 But it fails almost immediately trying to bootstrap Go:

 cpu% ./all.rc
 # Building C bootstrap tool.
 cmd/dist

 # Building compilers and Go bootstrap tool for host, plan9/386.
 lib9
 cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
 /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
 /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
 /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
 /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
 /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
 /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const

 I get a fair number of these errors for various header files, then some
 more worrisome output:

 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
 external redeclaration of: Rune
 TYPEDEF UINT
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
 TYPEDEF USHORT
 /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
 external redeclaration of: Rune
 TYPEDEF UINT
 /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
 TYPEDEF USHORT
 /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
 cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
 /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
 /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
 /usr/scaron/go-go1.4.2/include/plan9/libc.h:7
 /usr/scaron/go-go1.4.2/src/lib9/fmt/charstod.c:20 Unterminated string or
 char const
 go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 -D__STDC__=1
 -D__SIZE_TYPE__=ulong -I/usr/scaron/go-go1.4.2/include/plan9
 -I/usr/scaron/go-go1.4.2/include/plan9/386 -DPLAN9PORT -I
 /usr/scaron/go-go1.4.2/src/lib9 -o $WORK/dorfmt.8
 /usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:
 '/usr/scaron/go-go1.4.2/pkg/obj/plan9_386/lib9.a' does not exist
 go tool dist: FAILED: /bin/8c -FTVwp -DPLAN9 

Re: [9fans] Go on Plan 9?

[Sean Caron]

Yeah, thank goodness for snapshots :O Running replica/pull didn't turn out
so good for my current running system. It looks like it might make the most
sense to just archive my home directory and reload a fresh VM ...

Where are they keeping the most current installation ISO these days? I'm
just not sure of what's canonical now that the old bell-labs.com domain is
offline.

Thanks!

Sean


On Tue, Jan 26, 2016 at 8:52 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> Sean,
>
> David's (0intro) instructions are the right way to do it.  If I recall
> correctly, if you want to update by rebuilding from updated sources,
> there's a careful dance that needs to happen for the transition from old
> Rune size to the new.  Geoff sent out a note to 9fans outlining the steps
> at that time; you might be able to find it on 9fans archive (which
> unfortunately is not what it used to be).
>
> -Skip
>
>
> On Tue, Jan 26, 2016 at 5:40 PM Sean Caron  wrote:
>
>> Answering my own silly question, on my fossil-based system, running the
>> following command on the console as the bootes user seems to get the update
>> process running:
>>
>> replica/pull -v /dist/replica/network
>>
>> I'll wait for this to complete and then give building Go another shot.
>> Thanks for answering my shot in the dark!
>>
>> Thanks,
>>
>> Sean
>>
>>
>> On Tue, Jan 26, 2016 at 5:16 PM, Sean Caron  wrote:
>>
>>> Thanks, Skip. That would follow; this system is probably straight Fourth
>>> Edition, certainly an old ISO...
>>>
>>> I've never been 100% clear on the process for running updates; can I
>>> bring myself up to current from where I'm at now and not have to reload or
>>> build a fresh system? It's a VM and I can snapshot so I'm willing to give
>>> anything a try ...
>>>
>>> I'm looking at the directions in a (cached copy) of
>>> http://plan9.bell-labs.com/wiki/plan9/Staying_up_to_date/index.html...
>>>
>>> Is that still valid? What's the canonical procedure these days for
>>> updating a system?
>>>
>>> If that's roughly correct ... I'm running a single Plan 9 machine,
>>> combined CPU and fileserver ... I run that command as the bootes user on
>>> the system console?
>>>
>>> Thanks!
>>>
>>> Sean
>>>
>>>
>>> On Tue, Jan 26, 2016 at 5:05 PM, Skip Tavakkolian <
>>> skip.tavakkol...@gmail.com> wrote:
>>>
 All the errors seem related to the old Rune size. I suspect you're
 running an old system and it's likely to not have nsec and tsemacquire
 syscalls either.

 If you believe the system is up-to-date, you can cross compile a simple
 Go program using 1.5 or later targeting GOOS=plan9 GOARCH=386 from a
 Linux/OSX or Windows box and see if it runs on your system.  That might
 give you more info.



 On Tue, Jan 26, 2016 at 1:44 PM Sean Caron  wrote:

> Hi all,
>
> I've been getting interested in programming in Go recently and it's my
> understanding that at some point in time, Plan 9 was a supported
> environment in which one could bootstrap and use Go?
>
> I've tried a few different versions; 1.2.2, 1.4.2, 1.5.2, just
> following the directions that I found on a blog somewhere, i.e:
>
> tar xf go 1.4.2.tar
> cd go-go1.4.2/src
> ./all.rc
>
> But it fails almost immediately trying to bootstrap Go:
>
> cpu% ./all.rc
> # Building C bootstrap tool.
> cmd/dist
>
> # Building compilers and Go bootstrap tool for host, plan9/386.
> lib9
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:226
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> /usr/scaron/go-go1.4.2/include/plan9/utf.h:5
> /usr/scaron/go-go1.4.2/include/plan9/../fmt.h:21
> /usr/scaron/go-go1.4.2/include/plan9/fmt.h:5
> /usr/scaron/go-go1.4.2/include/plan9/libc.h:6
> /usr/scaron/go-go1.4.2/src/lib9/flag.c:6 Unterminated string or char const
>
> I get a fair number of these errors for various header files, then
> some more worrisome output:
>
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:152]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/fmt/dorfmt.c:21]
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> external redeclaration of: Rune
> TYPEDEF UINT
> /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:19[/usr/scaron/go-go1.4.2/src/lib9/flag.c:153]
> TYPEDEF USHORT
> /386/include/u.h:11[/usr/scaron/go-go1.4.2/src/lib9/flag.c:22]
> cpp: /usr/scaron/go-go1.4.2/include/plan9/../../src/lib9/utf/utf.h:227
> /usr/scaron/go-go1.4.2/include/plan9/../utf.h:1
> 

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

[Skip Tavakkolian]

 i can try it on rpi's, plugs and BBBs

On Sun, Nov 30, 2014 at 12:37 PM, Anthony Martin al...@pbrane.org wrote:

 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.

[lucio]

  i can try it on rpi's, plugs and BBBs

My Sheevaplug has died on me and the Olimex Olinuxino is a bit
underpowered.  I'm not sure if either will ever be viable.

Olimex have some exciting new hardware coming up, but a builder is a
bit of a tall order on ARM.

Ideally, I should use my Galaxy S5, that's where the power really lies
:-(

Lucio.

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

[Aram Hăvărneanu]

I am not sure I understand the question. Programming in Go on Plan 9
is almost the same as programming in Go in Unix. The setup is the
same.

-- 
Aram Hăvărneanu

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

[Ryan]

I *think* the commands would go something like this (untested):

hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz  go.tgz
tar xf go.tgz
cd go/src
all.rc

Mats Olsson plan9@gmail.com wrote:
Hi guys!

Does anyone use Plan 9 as platform for Go programming? If so, How is
your setup (remember that I'm a noob to Plan 9 so in layman terms
please)? Any information would be greatly appreciated.

Kind Regards,
Mats

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Check out my website: http://kirbyfan64.github.io/

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

[Mats Olsson]

Hi guys!

The thing is that I've been fooling around with Plan 9 for like 7
weeks (a real noob then) and then I read about programming in Go and
found that interesting and worth trying out. So the crude fact is that
I haven't any knowledge about programming in Go more than what I've
just read (at the golang site etc.) but since the Go language seems to
be very apt for the Plan 9 OS I thought that maybe some Plan 9 fans
already have some experience and could give me a headstart in such a
project. Hope this explanation makes sense. Thanks for your input and
we'll see what happens.

Kind Regards,
Mats

2014-11-30 15:16 GMT, Ryan rym...@gmail.com:
 I *think* the commands would go something like this (untested):

 hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz  go.tgz
 tar xf go.tgz
 cd go/src
 all.rc

 Mats Olsson plan9@gmail.com wrote:
Hi guys!

Does anyone use Plan 9 as platform for Go programming? If so, How is
your setup (remember that I'm a noob to Plan 9 so in layman terms
please)? Any information would be greatly appreciated.

Kind Regards,
Mats

 --
 Sent from my Android phone with K-9 Mail. Please excuse my brevity.
 Check out my website: http://kirbyfan64.github.io/

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

[Skip Tavakkolian]

are you using 9pi? if so, i don't think Go is available on plan9/arm yet.


On Sun, Nov 30, 2014 at 10:13 AM, Mats Olsson plan9@gmail.com wrote:

 Hi guys!

 The thing is that I've been fooling around with Plan 9 for like 7
 weeks (a real noob then) and then I read about programming in Go and
 found that interesting and worth trying out. So the crude fact is that
 I haven't any knowledge about programming in Go more than what I've
 just read (at the golang site etc.) but since the Go language seems to
 be very apt for the Plan 9 OS I thought that maybe some Plan 9 fans
 already have some experience and could give me a headstart in such a
 project. Hope this explanation makes sense. Thanks for your input and
 we'll see what happens.

 Kind Regards,
 Mats

 2014-11-30 15:16 GMT, Ryan rym...@gmail.com:
  I *think* the commands would go something like this (untested):
 
  hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz  go.tgz
  tar xf go.tgz
  cd go/src
  all.rc
 
  Mats Olsson plan9@gmail.com wrote:
 Hi guys!
 
 Does anyone use Plan 9 as platform for Go programming? If so, How is
 your setup (remember that I'm a noob to Plan 9 so in layman terms
 please)? Any information would be greatly appreciated.
 
 Kind Regards,
 Mats
 
  --
  Sent from my Android phone with K-9 Mail. Please excuse my brevity.
  Check out my website: http://kirbyfan64.github.io/

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

[Mats Olsson]

Yes, I'm using 9pi. OK. Thanks!

2014-11-30 18:31 GMT, Skip Tavakkolian skip.tavakkol...@gmail.com:
 are you using 9pi? if so, i don't think Go is available on plan9/arm yet.


 On Sun, Nov 30, 2014 at 10:13 AM, Mats Olsson plan9@gmail.com wrote:

 Hi guys!

 The thing is that I've been fooling around with Plan 9 for like 7
 weeks (a real noob then) and then I read about programming in Go and
 found that interesting and worth trying out. So the crude fact is that
 I haven't any knowledge about programming in Go more than what I've
 just read (at the golang site etc.) but since the Go language seems to
 be very apt for the Plan 9 OS I thought that maybe some Plan 9 fans
 already have some experience and could give me a headstart in such a
 project. Hope this explanation makes sense. Thanks for your input and
 we'll see what happens.

 Kind Regards,
 Mats

 2014-11-30 15:16 GMT, Ryan rym...@gmail.com:
  I *think* the commands would go something like this (untested):
 
  hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz  go.tgz
  tar xf go.tgz
  cd go/src
  all.rc
 
  Mats Olsson plan9@gmail.com wrote:
 Hi guys!
 
 Does anyone use Plan 9 as platform for Go programming? If so, How is
 your setup (remember that I'm a noob to Plan 9 so in layman terms
 please)? Any information would be greatly appreciated.
 
 Kind Regards,
 Mats
 
  --
  Sent from my Android phone with K-9 Mail. Please excuse my brevity.
  Check out my website: http://kirbyfan64.github.io/

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

[Mats Olsson]

Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm

So it seems that it's supported.

2014-11-30 20:06 GMT, Mats Olsson plan9@gmail.com:
 Yes, I'm using 9pi. OK. Thanks!

 2014-11-30 18:31 GMT, Skip Tavakkolian skip.tavakkol...@gmail.com:
 are you using 9pi? if so, i don't think Go is available on plan9/arm yet.


 On Sun, Nov 30, 2014 at 10:13 AM, Mats Olsson plan9@gmail.com
 wrote:

 Hi guys!

 The thing is that I've been fooling around with Plan 9 for like 7
 weeks (a real noob then) and then I read about programming in Go and
 found that interesting and worth trying out. So the crude fact is that
 I haven't any knowledge about programming in Go more than what I've
 just read (at the golang site etc.) but since the Go language seems to
 be very apt for the Plan 9 OS I thought that maybe some Plan 9 fans
 already have some experience and could give me a headstart in such a
 project. Hope this explanation makes sense. Thanks for your input and
 we'll see what happens.

 Kind Regards,
 Mats

 2014-11-30 15:16 GMT, Ryan rym...@gmail.com:
  I *think* the commands would go something like this (untested):
 
  hget https://storage.googleapis.com/golang/go1.3.3.src.tar.gz  go.tgz
  tar xf go.tgz
  cd go/src
  all.rc
 
  Mats Olsson plan9@gmail.com wrote:
 Hi guys!
 
 Does anyone use Plan 9 as platform for Go programming? If so, How is
 your setup (remember that I'm a noob to Plan 9 so in layman terms
 please)? Any information would be greatly appreciated.
 
 Kind Regards,
 Mats
 
  --
  Sent from my Android phone with K-9 Mail. Please excuse my brevity.
  Check out my website: http://kirbyfan64.github.io/

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

[erik quanstrom]

On Sun Nov 30 12:06:43 PST 2014, plan9@gmail.com wrote:
 Just googled and found: https://code.google.com/p/go-wiki/wiki/GoArm
 
 So it seems that it's supported.
 

read the supported operating systems section:

Go supports ARM on Linux. You must be running a EABI kernel.

so not even all linux.

- erik

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

[minux]

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).

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.

[erik quanstrom]

 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?

- erik

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

[David du Colombier]

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

I think I can run an plan9/arm builder. What board do you want?

-- 
David du Colombier

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

[Mats Olsson]

The following quote from GoArm makes me believe it can be done on a RPi:

Supported operating systems

Go supports ARM on Linux. You must be running a EABI kernel. These are
generally known as armel for softfloat (compatible with ARMv5) or
armhf for hardware floating point (ARMv6 and above).

2014-11-30 20:49 GMT, David du Colombier 0in...@gmail.com:
 If someone volunteers to run a plan9/arm builder, I'll
 do the port and have it in by the 1.5 release. ☺

 I think I can run an plan9/arm builder. What board do you want?

 --
 David du Colombier

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

[David du Colombier]

 The following quote from GoArm makes me believe it can be done on a
 RPi

Yes. ARMv5, ARMv6 and ARMv7 are supported. But maybe something
faster than a Raspberry Pi would be better.

-- 
David du Colombier

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] GO Programming Environment in Plan 9.

[Mats Olsson]

Hi David!

I have several Raspberry Pi's and I'm kind of doing a research of what
can be done on this platform when it comes to programming etc.
Preferable in Plan 9 OS. I'm certain that there are lots of other
options but I'm focusing on the use of the Raspberry Pi as a hardware
platform.

Kind Regards,
Mats

2014-11-30 22:10 GMT, Anthony Martin al...@pbrane.org:
 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] [go-nuts] Re: 9p protocol go implementation

[Skip Tavakkolian]

where would PostMountSrv reside? it isn't a syscall.

it is not difficult to do by hand; this version of go9p's timefs example
posts itself to /srv (plus some code to fake a few unix'isms on Plan
9). there is no authentication; permissions on the /srv file determine if a
user can mount it:

https://github.com/9nut/plan9/tree/master/go9p_timefs

a package that wraps the factotum-to-app rpc protocol (like libauth) would
be useful.

-Skip

On Mon, Nov 3, 2014 at 7:04 PM, newton...@gmail.com wrote:

 Thanks, I think I'll have to do a bit more reading to understand this.
 I'll check out ramfs and 9pcon.

 Is this simpler if written in C using postmountsrv with a mount point?
 I'm assuming that it doesn't require a tcp port and explicit authentication
 handling using libauth on both ends.

 If so, then I wonder why postmountsrv is not exposed via the Go 9P
 libraries?

 Chris

 On Monday, November 3, 2014 4:29:10 AM UTC-5, Skip wrote:

 short version: you need libauth in Go (or start the go9p client/server by
 C programs that do the auth).

 9P facilitates authentication (but doesn't define or dictate the method).
 intro(5), auth(2) and factotum(4) will be helpful. basically Tauth is used
 to request a fid to negotiate authentication (a.k.a. afid).
 Tread's/Twrite's to afid are proxy-delivered to the factotums
 (authentication agents) of the sever and of the client by each side. once
 server's factotum is convinced, the server is granted the system privilege
 to change its process id to the authenticated user.  the client attaches
 (Tattach) to the server's namespace by providing the afid in addition to
 other parameters. tools like 'ramfs  -D' and aux/9pcon are very handy for
 watching 9P in action.

 i'm copying to 9fans; it might be a better place to continue.


 On Sun, Nov 2, 2014 at 6:27 PM, newt...@gmail.com wrote:

 I see that go9p supports authentication. Assuming the client and server
 are both plan9 (even the same system), how does one hook up the OS's
 authentication?

 Chris


 On Monday, March 21, 2011 10:16:16 PM UTC-4, peterGo wrote:

 Mauricio,

 go9p - Package to write 9P clients and servers in Go
 http://code.google.com/p/go9p/

 Peter

 On Mar 21, 9:57 pm, Maurício CA mauricio.antu...@gmail.com wrote:
  Hi, all,
 
  I see at page below that there exists go9p, A 9P library in the Go
  programming language, by Andrey Mirtchovski and Latchesar
  Ionkov. Now part of the official Go distribution.
 
 http://9p.cat-v.org/implementations
 
  I can't find any implementation of 9p at this page, though, which, I
  believe, is the official list of current standard go packages:
 
 http://golang.org/pkg
 
  Is there really a 9p implementation in the official go distribution?
 
  Thanks,
 
  Maurício

  --
 You received this message because you are subscribed to the Google
 Groups golang-nuts group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 You received this message because you are subscribed to the Google Groups
 golang-nuts group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to golang-nuts+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Re: [9fans] [go-nuts] Re: 9p protocol go implementation

[Skip Tavakkolian]

short version: you need libauth in Go (or start the go9p client/server by C
programs that do the auth).

9P facilitates authentication (but doesn't define or dictate the method).
intro(5), auth(2) and factotum(4) will be helpful. basically Tauth is used
to request a fid to negotiate authentication (a.k.a. afid).
Tread's/Twrite's to afid are proxy-delivered to the factotums
(authentication agents) of the sever and of the client by each side. once
server's factotum is convinced, the server is granted the system privilege
to change its process id to the authenticated user.  the client attaches
(Tattach) to the server's namespace by providing the afid in addition to
other parameters. tools like 'ramfs  -D' and aux/9pcon are very handy for
watching 9P in action.

i'm copying to 9fans; it might be a better place to continue.


On Sun, Nov 2, 2014 at 6:27 PM, newton...@gmail.com wrote:

 I see that go9p supports authentication. Assuming the client and server
 are both plan9 (even the same system), how does one hook up the OS's
 authentication?

 Chris


 On Monday, March 21, 2011 10:16:16 PM UTC-4, peterGo wrote:

 Mauricio,

 go9p - Package to write 9P clients and servers in Go
 http://code.google.com/p/go9p/

 Peter

 On Mar 21, 9:57 pm, Maurício CA mauricio.antu...@gmail.com wrote:
  Hi, all,
 
  I see at page below that there exists go9p, A 9P library in the Go
  programming language, by Andrey Mirtchovski and Latchesar
  Ionkov. Now part of the official Go distribution.
 
 http://9p.cat-v.org/implementations
 
  I can't find any implementation of 9p at this page, though, which, I
  believe, is the official list of current standard go packages:
 
 http://golang.org/pkg
 
  Is there really a 9p implementation in the official go distribution?
 
  Thanks,
 
  Maurício

  --
 You received this message because you are subscribed to the Google Groups
 golang-nuts group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to golang-nuts+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

[Skip Tavakkolian]

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



On Sun, May 4, 2014 at 7:51 PM, Anthony Martin al...@pbrane.org wrote:

 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