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?

[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?

[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 <skip.tavakkol...@gmail.com> 
> 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 <sirnewton...@yahoo.ca> 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?

[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?

[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 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] Any demand for a supported Windows version of p9port?

[Chris McGee]

I was thinking of using Cygwin to see would be capable of compiling p9p.

Chris

> On Jul 27, 2016, at 9:08 PM, Andrew Simmons  wrote:
> 
> What the subject line says.
> 
> This is not remotely intended to disrespect Sean Quinlan’s 9pm, or the guys 
> who did pf9. I’m just asking because there are still chunks of p9p that I’d 
> like to have under Windows. Some of the chunks I want (mostly the command 
> line utilities, also sam, not so much acme) I’ve managed to build under 
> Microsoft Visual Studio (note to self - wash mouth out and learn to eschew 
> IDEs and love mk ((also, sub-note to self, don’t use syntax highlighting)))
> 
> But, and this is a large but, there are parts of p9port that seem to be 
> dependent on the Unix world - unix pipes for one, the stuff about sigjmp for 
> another.
> 
> So, what the subject line says, but also - how much of the Unix-specific 
> stuff in the current p9p is essential to a port to Windows?
> 
> Go in peace
> James V Choate XXXVI
> 
> 
> 

Re: [9fans] Linker and duplicate symbols

[Chris McGee]

Thanks Richard,

I tried outputting the echo of the ld command and it's linking all of the .5 
files together along with the few archive files to produce the raw kernel file. 
I'll go hunting to see if there is some other unbound symbol.

I think the reason why I'm confused is that I don't understand how the linker 
can possibly pick the "right" symbol here given that C doesn't allow 
overloading. There are two sleep symbols. Why does the linker generally know to 
pick the one from the .5 file and not the one from the libc.a. Is it that the 
linker prefers a symbol from a .5 file over the .a file?

Chris

On Sep 2, 2016, at 6:20 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> I have recently run into a problem when compiling the kernel where the 
>> linker complains about duplicate symbols and fails. The symbol is sleep(), 
>> which is exported in libc.a but is also exported in another file in port, 
>> but with different parameters (both number and type).
> 
> Shouldn't happen (TM).  The duplicate sleep may be a side effect of
> some other error (undefined symbol?) which is getting ld confused.
> I suggest finding the invocation of ld (or $LD) in the mkfile and
> inserting a copy of the command with "echo" prepended, to see exactly
> what's being linked; then have a good look at all the error messages
> and see if there's anything obvious you can clear up which could make
> the duplicate sleep go away too.
> 
> Otherwise you could post the ld line and error messages to get more
> eyes looking at the problem ...
> 
> 

Re: [9fans] Linker and duplicate symbols

[Chris McGee]

Thanks Cinap, Richard,

That makes sense and was probably obvious or in a man page somewhere.

Chris

> On Sep 2, 2016, at 12:12 PM, cinap_len...@felloff.net wrote:
> 
> uses the first one it finds, so the order matters. its not unusual
> for programs to override certain library function by providing ther
> own version and putting them first in the object file list. this
> works only when the function you want to replace sits alone in his
> own object file (the smallest unit of linkage).
> 
> the kernel does link in some standard libc functions, but obviously
> not the ones attempting syscalls :)
> 
> --
> cinap
> 

Re: [9fans] Linker and duplicate symbols

[Chris McGee]

Thanks Steve,

I will give these strategies a try.

Chris

> On Sep 2, 2016, at 6:34 PM, Steve Simon <st...@quintile.net> wrote:
> 
> the linker rejects later instances of symbols if it had already found an 
> instance. the important point however is that this is done on a per file 
> basis if the symbol is in a library.
> 
> the case where I have seen this is your code (the kernel code in this case) 
> references another symbol which only exists in the file that contains the 
> second instance of clock on the command line.
> 
> this means both copies of clock are forced into the linkage, one directly 
> through a call to clock, the other through the other reference.
> 
> what I have done to find these in the past (crude but effective) is to delete 
> both files which contain the clock call (for libc use "ar d") then run mk 
> again and see what complains.
> 
> my bet is there will be unresolved calls to clock, and something else that 
> shouldn't be there...
> 
> good luck,
> 
> -Steve
> 
>> On 2 Sep 2016, at 21:00, Chris McGee <sirnewton...@yahoo.ca> wrote:
>> 
>> Thanks Cinap, Richard,
>> 
>> That makes sense and was probably obvious or in a man page somewhere.
>> 
>> Chris
>> 
>>> On Sep 2, 2016, at 12:12 PM, cinap_len...@felloff.net wrote:
>>> 
>>> uses the first one it finds, so the order matters. its not unusual
>>> for programs to override certain library function by providing ther
>>> own version and putting them first in the object file list. this
>>> works only when the function you want to replace sits alone in his
>>> own object file (the smallest unit of linkage).
>>> 
>>> the kernel does link in some standard libc functions, but obviously
>>> not the ones attempting syscalls :)
>>> 
>>> --
>>> cinap
> 
> 

[9fans] Linker and duplicate symbols

[Chris McGee]

Hi All,

I have recently run into a problem when compiling the kernel where the linker 
complains about duplicate symbols and fails. The symbol is sleep(), which is 
exported in libc.a but is also exported in another file in port, but with 
different parameters (both number and type).

It's my understanding that C doesn't support overloading. So, why is it that 
the kernel links when there are two different sleep functions?

Thanks,
Chris

Re: [9fans] Is 9Fans dead or alive

[Chris McGee]

Sure,

I'm looking for plan9 user/enthusiast appropriate medium. Any suggestions?

Chris

> On Aug 30, 2016, at 6:18 PM, Eduardo Alvarez <astrochelon...@gmail.com> wrote:
> 
> Are you keeping your progess public? It would be very educational to read.
> 
>> On Tue, Aug 30, 2016 at 7:10 PM, Chris McGee <sirnewton...@yahoo.ca> wrote:
>> I am about a quarter of the way to a similar setup.
>> 
>> My goal is to have a specialty for each of the Pi's (sensors, controller,
>> terminal, router) without preventing them from doing general tasks. I'm
>> hoping to eventually connect up some Pi zeros as leaf nodes for just
>> sensor/control and plumb through 9P via UART pins.
>> 
>> Chris
>> 
>> On Aug 30, 2016, at 3:36 PM, Skip Tavakkolian <skip.tavakkol...@gmail.com>
>> wrote:
>> 
>> It is straightforward and easy:
>> 
>> https://plus.google.com/+SkipTavakkolian/posts/Fb846KhBMM6
>> 
>> On Tue, Aug 30, 2016 at 11:54 AM Eduardo Alvarez <astrochelon...@gmail.com>
>> wrote:
>>> 
>>> I mostly lurk around here, as I'm greener than green when it comes to
>>> plan 9. At some point in time, a friend and I were discussing setting
>>> up a small-sized computing cluster for small scale distributed
>>> computations. I was keen on the idea of using inexpensive hardware (we
>>> even joked about using a truckloads of Raspberry Pis), and plan 9
>>> seemed like an excellent candidate for the infrastructure. The biggest
>>> challenge was porting software to Plan 9. Sadly, the idea never took
>>> off. It would be a fun experiment.
>>> 
>>> Eduardo Alvarez
>>> 
>>> On Tue, Aug 30, 2016 at 3:41 PM, Jules Merit
>>> <jules.merit.eurocorp...@gmail.com> wrote:
>>>> Well let's hope someone does something. Mark-my-words is writing
>>>> beautiful
>>>> code that has already been done.
>>>> 
>>>> Push a little button, get .hot .chocolate.
>>>> -- Russ Cox Cable von Shane
>>>> 
>>>> 
>>>> On Aug 30, 2016 10:03 AM, "Skip Tavakkolian"
>>>> <skip.tavakkol...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> I heard that too (I think the woot was for Go on Plan 9/ARM).  I'm
>>>>> sorry I
>>>>> missed that meetup.
>>>>> 
>>>>> I've been thinking about setting up a meetup for 9fans in Seattle area.
>>>>> There seems to be renewed interest (or perhaps it's my wishful
>>>>> thinking).
>>>>> 
>>>>> 
>>>>> On Tue, Aug 30, 2016 at 9:27 AM michaelian ennis
>>>>> <michaelian.en...@gmail.com> wrote:
>>>>>> 
>>>>>> On Tue, Aug 23, 2016 at 12:26 PM, Skip Tavakkolian
>>>>>> <skip.tavakkol...@gmail.com> wrote:
>>>>>> 
>>>>>>> as a 9fan, I can say, not dead yet. In fact the population of 9fans
>>>>>>> in
>>>>>>> my neighborhood has doubled.
>>>>>> 
>>>>>> 
>>>>>> And for the county it has at least tripled.  I heard at least one
>>>>>> other
>>>>>> woot for Plan9 at Brad Fitzpatrick's talk last week.  :)
>>>>>> 
>>>>>> Ian
> 

Re: [9fans] Is 9Fans dead or alive

[Chris McGee]

I am about a quarter of the way to a similar setup.

My goal is to have a specialty for each of the Pi's (sensors, controller, 
terminal, router) without preventing them from doing general tasks. I'm hoping 
to eventually connect up some Pi zeros as leaf nodes for just sensor/control 
and plumb through 9P via UART pins.

Chris

> On Aug 30, 2016, at 3:36 PM, Skip Tavakkolian  
> wrote:
> 
> It is straightforward and easy:
> 
> https://plus.google.com/+SkipTavakkolian/posts/Fb846KhBMM6
> 
>> On Tue, Aug 30, 2016 at 11:54 AM Eduardo Alvarez  
>> wrote:
>> I mostly lurk around here, as I'm greener than green when it comes to
>> plan 9. At some point in time, a friend and I were discussing setting
>> up a small-sized computing cluster for small scale distributed
>> computations. I was keen on the idea of using inexpensive hardware (we
>> even joked about using a truckloads of Raspberry Pis), and plan 9
>> seemed like an excellent candidate for the infrastructure. The biggest
>> challenge was porting software to Plan 9. Sadly, the idea never took
>> off. It would be a fun experiment.
>> 
>> Eduardo Alvarez
>> 
>> On Tue, Aug 30, 2016 at 3:41 PM, Jules Merit
>>  wrote:
>> > Well let's hope someone does something. Mark-my-words is writing beautiful
>> > code that has already been done.
>> >
>> > Push a little button, get .hot .chocolate.
>> > -- Russ Cox Cable von Shane
>> >
>> >
>> > On Aug 30, 2016 10:03 AM, "Skip Tavakkolian" 
>> > wrote:
>> >>
>> >> I heard that too (I think the woot was for Go on Plan 9/ARM).  I'm sorry I
>> >> missed that meetup.
>> >>
>> >> I've been thinking about setting up a meetup for 9fans in Seattle area.
>> >> There seems to be renewed interest (or perhaps it's my wishful thinking).
>> >>
>> >>
>> >> On Tue, Aug 30, 2016 at 9:27 AM michaelian ennis
>> >>  wrote:
>> >>>
>> >>> On Tue, Aug 23, 2016 at 12:26 PM, Skip Tavakkolian
>> >>>  wrote:
>> >>>
>>  as a 9fan, I can say, not dead yet. In fact the population of 9fans in
>>  my neighborhood has doubled.
>> >>>
>> >>>
>> >>> And for the county it has at least tripled.  I heard at least one other
>> >>> woot for Plan9 at Brad Fitzpatrick's talk last week.  :)
>> >>>
>> >>> Ian

Re: [9fans] Is 9Fans dead or alive

[Chris McGee]

I could put it up as a troff file on a 9P share but then how will people find 
it and know when it's updated?

There's got to be some medium that is palatable to both hard core and new users.

Chris

> On Aug 30, 2016, at 8:51 PM, Skip Tavakkolian <skip.tavakkol...@gmail.com> 
> wrote:
> 
> some here still prefer hammer/chisel/stone to new-fangled quill/ink/parchment
> 
>> On Tue, Aug 30, 2016 at 3:22 PM Chris McGee <sirnewton...@yahoo.ca> wrote:
>> Sure,
>> 
>> I'm looking for plan9 user/enthusiast appropriate medium. Any suggestions?
>> 
>> Chris
>> 
>> > On Aug 30, 2016, at 6:18 PM, Eduardo Alvarez <astrochelon...@gmail.com> 
>> > wrote:
>> >
>> > Are you keeping your progess public? It would be very educational to read.
>> >
>> >> On Tue, Aug 30, 2016 at 7:10 PM, Chris McGee <sirnewton...@yahoo.ca> 
>> >> wrote:
>> >> I am about a quarter of the way to a similar setup.
>> >>
>> >> My goal is to have a specialty for each of the Pi's (sensors, controller,
>> >> terminal, router) without preventing them from doing general tasks. I'm
>> >> hoping to eventually connect up some Pi zeros as leaf nodes for just
>> >> sensor/control and plumb through 9P via UART pins.
>> >>
>> >> Chris
>> >>
>> >> On Aug 30, 2016, at 3:36 PM, Skip Tavakkolian <skip.tavakkol...@gmail.com>
>> >> wrote:
>> >>
>> >> It is straightforward and easy:
>> >>
>> >> https://plus.google.com/+SkipTavakkolian/posts/Fb846KhBMM6
>> >>
>> >> On Tue, Aug 30, 2016 at 11:54 AM Eduardo Alvarez 
>> >> <astrochelon...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I mostly lurk around here, as I'm greener than green when it comes to
>> >>> plan 9. At some point in time, a friend and I were discussing setting
>> >>> up a small-sized computing cluster for small scale distributed
>> >>> computations. I was keen on the idea of using inexpensive hardware (we
>> >>> even joked about using a truckloads of Raspberry Pis), and plan 9
>> >>> seemed like an excellent candidate for the infrastructure. The biggest
>> >>> challenge was porting software to Plan 9. Sadly, the idea never took
>> >>> off. It would be a fun experiment.
>> >>>
>> >>> Eduardo Alvarez
>> >>>
>> >>> On Tue, Aug 30, 2016 at 3:41 PM, Jules Merit
>> >>> <jules.merit.eurocorp...@gmail.com> wrote:
>> >>>> Well let's hope someone does something. Mark-my-words is writing
>> >>>> beautiful
>> >>>> code that has already been done.
>> >>>>
>> >>>> Push a little button, get .hot .chocolate.
>> >>>> -- Russ Cox Cable von Shane
>> >>>>
>> >>>>
>> >>>> On Aug 30, 2016 10:03 AM, "Skip Tavakkolian"
>> >>>> <skip.tavakkol...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> I heard that too (I think the woot was for Go on Plan 9/ARM).  I'm
>> >>>>> sorry I
>> >>>>> missed that meetup.
>> >>>>>
>> >>>>> I've been thinking about setting up a meetup for 9fans in Seattle area.
>> >>>>> There seems to be renewed interest (or perhaps it's my wishful
>> >>>>> thinking).
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Aug 30, 2016 at 9:27 AM michaelian ennis
>> >>>>> <michaelian.en...@gmail.com> wrote:
>> >>>>>>
>> >>>>>> On Tue, Aug 23, 2016 at 12:26 PM, Skip Tavakkolian
>> >>>>>> <skip.tavakkol...@gmail.com> wrote:
>> >>>>>>
>> >>>>>>> as a 9fan, I can say, not dead yet. In fact the population of 9fans
>> >>>>>>> in
>> >>>>>>> my neighborhood has doubled.
>> >>>>>>
>> >>>>>>
>> >>>>>> And for the county it has at least tripled.  I heard at least one
>> >>>>>> other
>> >>>>>> woot for Plan9 at Brad Fitzpatrick's talk last week.  :)
>> >>>>>>
>> >>>>>> Ian
>> >

[9fans] 9front on raspberry pi

[Chris McGee]

Hi All,

I have an experimental (read unstable, may void the warranty) merge of Richard 
Miller's kernel for raspberry Pi into 9front. It is capable of running Go 
programs and sdk.

The code is here as a drop in replacement for existing /sys/src/9/bcm:
https://github.com/sirnewton01/rpi-9front

Also, there is a release with an sdcard image there from the last 9front 
release. Tested briefly with a Pi B+ and Pi 2 B. In theory it could work with 
other models such as zero.

If you find problems either with the code or in testing comments are welcome 
either as response to this email or github issue. Pull requests are welcome.

Cheers,
Chris

Re: [9fans] Linker and duplicate symbols

[Chris McGee]

I wanted to check if the problem was pre existing or a result of a potentially 
bad merge on my part. It sounds like reboot wasn't a big concern for the 
raspberry Pi engineers. Wow, weird.

Thanks for the suggestion. I'll try it out when/if they ever have the zero 
available in Canada for a comparable price. Do you use the pi or pi2 kernel for 
zero?

Chris

On Sep 9, 2016, at 4:31 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics 
>> on reboot. Cold reset brings it back to normal.
> 
> Sorry, I have seen this failure too, but only on pi3.  If you run with
> *ncpu=1 the soft reboot seems to work reliably.  But my scheme for
> rebooting from multicore state is clearly not right.  Unfortunately I
> don't know of any way of forcing an arm reset after loading the new
> kernel without also resetting the gpu back to the load-from-sdcard
> point.  I'll welcome any suggestions for a way to do this.  I think
> linux on the pi supports kexec, so it might be possible to reverse
> engineer from that and find a way that works.  On the other hand, if
> you search the web for "raspbian kexec" most of the hits seem to be of
> the "doesn't work" variety, so maybe not.
> 
>> Does your latest code work on Pi zero? I don't yet have one to test it.
> 
> Yes it does.  If you boot different kernels from the same sdcard you need
> to use [pi0] as a section header for the zero. (Discovered by trial and
> error because this doesn't seem to be documented anywhere.)
> 
> 

Re: [9fans] Linker and duplicate symbols

[Chris McGee]

Thanks Richard,

I traced it down to a symbol being brought in from libc that brought in other 
symbols that collided with ones on the kernel.

Btw, with your latest changes I have merged them in with the latest 9front and 
its running on my Pi 1 and Pi 2.

Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics on 
reboot. Cold reset brings it back to normal.

Does your latest code work on Pi zero? I don't yet have one to test it.

Chris

On Sep 2, 2016, at 12:11 PM, Richard Miller <9f...@hamnavoe.com> wrote:

>> Is it that the linker prefers a symbol from a .5 file over the .a file?
> 
> I believe it's supposed to pick the first one it finds.  Object files and
> libraries are processed in the order in which they appear on the command line.
> On my system proc.5 appears before libc.a in the ld command, and 
> libc.a(sleep.5)
> doesn't contain any symbols other than sleep, so there should be no reason
> for ld to pull it in from the library.
> 
> 

[9fans] Multicast examples

[Chris McGee]

Hi All,

I'm looking at setting up a multicast dns on plan9. First, I need to be able to 
write a mdns server and client.

I see from the net manual page that there are references to multicast, namely 
addmulti and remmulti ctl messages. I'm not entirely sure how they work.

Does anyone know of multicast examples for server and client that I could look 
at?

Thanks,
Chris

Re: [9fans] Ping

[Chris McGee]

Oh, interesting.

Thanks,
Chris

> On Sep 13, 2016, at 8:58 AM, Rob Pike <robp...@gmail.com> wrote:
> 
> This might be one reason.
> 
> -rob
> 
> 
>> On Tue, Sep 13, 2016 at 10:51 PM, Chris McGee <sirnewton...@yahoo.ca> wrote:
>> Sorry for the spam. Is this mailing list getting my emails?
>> 
>> Thanks
>> Chris
> 

[9fans] Ping

[Chris McGee]

Sorry for the spam. Is this mailing list getting my emails?

Thanks
Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Thank you Alex,

I will give these a try tonight. I'm happy to hear that multicast can work and 
it's likely just some silly mistake on my end.

Chris

> On Sep 15, 2016, at 12:23 AM, Alex Musolino  wrote:
> 
> I was playing around with multicast on 9front the other week and
> managed to get something working (for some definition of working). I
> have attached 2 test programs for sending and receiving multicast
> datagrams. Unfortunately, it seems you can't send/receive messages
> from the same host. I'm not sure what's missing to get that part
> working.
> 
> Also, note that the dial in mcastrecv.c is just a hack to get the
> local address via getnetconninfo, which doesn't seem to work given the
> announce directory.
> 
> Hopefully these are of some use. Would be interested to hear how to
> fix the mentioned (and unmentioned) shortcomings.
> 
> --
> Cheers,
> Alex Musolino
> 
> 
> 

Re: [9fans] IP Multicast - Results

[Chris McGee]

Hi Alex,

I tried the mcastsend and mcastrecv on my two raspberry Pis running 9front.

Im seeing similar routes as in my own experiment without the interface 
number, tagged as 4m for IPv4 multicast. I can ping each device from the other 
using their unicast addresses.

Unfortunately, it doesnt seem to be working. Both ends are sitting idle.

Do you remember if you needed to add/remove routes to make it work? Also, did 
you use 9front or the bell labs distribution?

Thanks,
Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Yes, same here. Both are wired directly to a dumb switch using link local 
addresses. No router.

I tried 225.0.0.1 port 1234 on both ends.

I cant figure out what the contents of the buffer is. Just random bytes? 

It is weird that the ifc number gets filled in after pinging the multicast 
address.

Chris

[9fans] Cpu command and namespace

[Chris McGee]

Hi All,

I tried running a cpu server using aux/listen1 on one of my plan9 machines and 
running cpu from another to connect to it. I set auth to none for now.

When I connected I noticed that the namespace was the local namespace of the 
server, not the namespace of the client before connecting. I was under the 
impression that the namespace should come from the client.

Am I doing something wrong here or is my understanding incorrect? Maybe I need 
to get authentication set up properly?

Thanks,
Chris

Re: [9fans] Cpu command and namespace

[Chris McGee]

Thanks Skip,

That's the part I was missing. I thought that the current namespace is 
preserved after cpu command on the remote. But then I realize that it would be 
difficult to remap the bin namespaces to a different cpu architecture.

I suppose that I can always bind over what I want from /mnt/term or customize 
the profile script to do it automatically in cpu case.

Chris

On Oct 6, 2016, at 12:14 AM, Skip Tavakkolian <9...@9netics.com> wrote:

>> I was under the impression that the namespace should come from the client.
> 
> perhaps it's a confusion over cwd when you cpu to another machine?
> 
> supermic% pwd
> /usr/fst
> supermic% cpu -h rpi
> rpi% pwd
> /usr/fst
> rpi% 
> 
> since typically everything is served by fs, it is all the same
> content.  the local namespace is exported by the local cpu and the
> far-end cpu mounts it on /mnt/term.
> 
> e.g.
> 
> rpi% devsysname='/dev/sysname' for (i in `{seq 3}) {
>echo $devsysname ' = ' `{cat $devsysname}
>devsysname='/mnt/term'^$devsysname
>}
> /dev/sysname  =  rpi
> /mnt/term/dev/sysname  =  supermic
> /mnt/term/mnt/term/dev/sysname  =  dell
> rpi% 
> 
> 

Re: [9fans] "The Name Game"

[Chris McGee]

Very nice introduction.

> On Oct 7, 2016, at 7:05 PM, Skip Tavakkolian  
> wrote:
> 
> A wonderful and entertaining talk by Charles about key ideas in Plan 9 and 
> Inferno.
> 
> https://youtu.be/3d1SHOCCDn0
> 
> Thanks also to Ron for posting it.
> 

[9fans] IP Multicast - Results

[Chris McGee]

After some investigation and trial and error Im left with the sense that 
multicast is not entirely implemented on plan9. Heres what I tried.

I tried setting up a udp announce directly against /net/udp for port 564. 
Before listening I sent an addmulti message as described in the ip manual page. 
According to /net/iproute there is a new route for my multicast address but it 
is not bound to any of my interfaces despite specifying the ip of my adapter in 
the addmulti. There doesnt seem to be a way to specify the interface 
number in the iproute protocol. My process waits but when another process on 
another machine sends on that multicast address it is not received.

I tried pinging 224.0.01 from another machine and my plan 9 box doesnt 
respond to the ping like other machines with multicast enabled.

Finally, after looking at the code in /sys/src/9/ip I find that while a queue 
of multicast IPmulti structs are assembled nothing at the Ethernet/ARP layer 
seems to register the multicast with the adapter so that it can receive packets.

Something else thats puzzling is that I cant seem to have multiple 
processes on the plan9 machine listening on the same udp port. On other OSes 
there are flags that can be set to allow reuse. Im not seeing anything 
similar here.

Im hoping that theres something that Im missing. Has anyone else 
had success setting multicast servers up in any of the plan 9 variants? 
Otherwise, it would be a project to write the code for it. Perhaps ARP will 
suit my need better for detecting hosts on the same Ethernet switch.

Thanks,
Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Ooh thanks. In hg?

Chris

> On Sep 16, 2016, at 5:26 PM, cinap_len...@felloff.net wrote:
> 
> updated the code for multicast and promisc mode in nusb/ether...
> 
> --
> cinap
> 

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

> 
> > You just mount search engine, route planning tool, or even shopping site 
> > and echo commands into the ctl file. 
> 
> I hadn't thought of this - was more thinking on the user union mounting, say, 
> google.com/bin into their bin directory and running a google operation. The 
> concept of just echoing into a ctl file is really interesting from a security 
> perspective.

Right, in this case there is no remote code execution. Web users run all kinds 
of code they are unaware of today. It's a major problem.

It also helps to create a certain uniformity and expectation of how services 
should work.

Mounting a bin directory from some remote servers is a potential vector for 
malicious code and requires all services to provide binaries for all platforms 
(arm, x86, riscv,...). Instead, serving the source code and mkfile allows for 
audit ability (what did I just run?) and support for their own platform. Plan 9 
compilers were designed not just to produce optimal code but also for speed of 
compilation.

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

Wow,

That sounds cool.

Thanks,
Chris

> On Sep 22, 2016, at 6:49 PM, michaelian ennis  
> wrote:
> 
> Not exactly what you meant but Coraid did implement a something like this 
> that had 9p on it.  Sort of.  It was an ARM based PCIe card spoke 9p over 
> something like IL without the IP (bwc called it EL) using network ports on 
> the card.  
> 
> Sometimes they appear on ebay as "coraid mass storage NIC" or some such.  Not 
> the repurposed SuperMicro Cards but something that looks mor complicated with 
> a SO-DIMM socket on it. 
> 
> The ARM CPU was also used for other services running on/for the platform that 
> were performed by the card.  The card could be powered by POE so the chassis 
> could be powered down and the card could still be accessed. The firmware on 
> the card was, IIRC, not quite plan9 but constructed mostly from plan9.
> 
> Ian

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

I was thinking more along the lines of hardware implementation of 9P minus any 
OS. For example, a disk serves up a filesystem via 9P or an Ethernet device 
serving a /net with 9P.

Chris

> On Sep 20, 2016, at 2:16 AM, David Pick <d.m.p...@qmul.ac.uk> wrote:
> 
>> On 19/09/16 21:55, Chris McGee wrote:
>> 
>> 
>> 
>> Maybe 9P could be implemented in a SoC.
> 
> It already has: the Raspberry Pi is built round a SoC...
> ...all that's needed is to boot from SoC ROM instead of the SD card.
> 
> -- 
> David Pick
> Network Security Manager, IT Services
> Queen Mary University of London
> Tel: +44 (0) 20 7882 7079
> Mob: +44 (0) 7973 379 161
> E-Mail: d.m.p...@qmul.ac.uk
> 
> Normal working days are Monday to Wednesday inclusive
> 
> Worried about Cyber Security? Check out the
> Cyber Security Information and Training described at
> http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html
> 
> 

Re: [9fans] IP Multicast - Results

[Chris McGee]

Hi All,

Multicast is working fine for me with the latest patches in 9front hg on my 
raspberry Pi.

Thanks Cinap, Alex et al for pointing me in the right direction.

Current status is that I can use multicast dns to discover nodes on my local 
network using a Go library and some patches to the Go networking code to add 
multicast support. I'm going to try and see if I can get that contributed to 
the next version.

Btw, I noticed that the net manpage doesn't accurately describe the format of 
/net/ipifc/x/status files. It says there are 9 columns but mine has more than 
that and also some extra rows for assigned IP addresses. Does anyone know if 
this is a 9front specific deviation or if the man page is just way out of date?

Chris

> On Sep 17, 2016, at 7:53 AM, Chris McGee <sirnewton...@yahoo.ca> wrote:
> 
> I recompiled with the latest in hg. I'm still not having success with the 
> multicast. I'm going to start adding debugging to figure out what's going on.
> 
> Chris
> 

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

> Would this be fast enough for what we experienced back then with early 
> websites, however? What with the stats on how people close or click away from 
> a tab within N seconds if it hasn't fully loaded yet, I'd think that having 
> to compile at all could've been prohibitive to people taking this route vs. 
> web forms. Though, I'm not sure how user behaviors or expectations of speed 
> were back then for the web.

I have a couple of ideas in this area. If a more guided interface is needed 
then when you mount a service you can hook up a console to a file using "con" 
command allowing for interactive prompts such as "enter search criteria" and 
responses. Still no remote code required.

Another option is to provide a readme.txt file describing the service, relevant 
files, etc. Inside that document are examples of shell commands that you can 
run.

echo 'search cat pictures' >> ctl

Open the readme in acme, edit the examples, select and middle click on it and 
it runs the command. You learn how to use the service and again, there is no 
remote command execution other than what you selected and ran.

> 
> I was thinking what may have eventually happened would have been an 
> interpreted language would pop up that would be what web applications were 
> written in, sort of like java applets, except not embedded in the browser, 
> and hopefully in a simpler language. Early web applications were also very 
> simple 'put info in textbox and hit enter' forms, if I remember correctly, so 
> a small, expandable runtime that would be quickly started up in a sandbox 
> might have been on equal footing with html, assuming it was indeed able to 
> start up and run quickly (or maybe just fork a running one into a new 
> namespace?). Ideally, developers could then write their own libraries (in C 
> or whatever they like) that the web language would hook into that could do 
> more powerful things - and those libraries might be the time to provide 
> source and makefiles, or binaries if they wanted to keep things close to the 
> chest.

That's possible that an interpreted language would have taken off. With OS 
level sandboxing, hopefully people run these within the sandboxes, providing 
access the minimal set needed for the service.

> 
> Thinking more on the 'writing to a ctl file' idea, which I'm really getting 
> into, I was thinking users may have ended up making their own graphical 
> interfaces for web services; UIs that abstracted away the actual writing to 
> ctl files and put it in a GUI for less advanced users. It'd've been 
> interesting to see a competition in UI design among OSS interfaces for web 
> services, sort of like what we see today with apps for reddit on phones 
> (except hopefully they wouldn't all be awful). Or, maybe everyone would just 
> use the service-provider's provided interfaces.

I think that many GUI's were created to hide ugly, inconsistent and large 
layers underneath. I have a hypothesis that if you start with a small, well 
designed system with a simple interface that people can and will use it of the 
alternative is a system that is brittle, complex and allows accidental security 
breaches at the click of a button. Textual interfaces can good and usable, with 
a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or 
it truly simplifies the interface.

> Do you think there would've been fewer large databases if things had gone 
> this way? Just thinking on my banking example, it seems like it'd be easiest 
> to just have a /bank.com/users/ folder with the relevant files in 
> it that users could union-mount, since you're not forced to show things 
> through a web interface. Though, I suppose a bank could just expose that 
> folder as an interface for what's actually a DB running in the background.

The bank may expose files, but it doesn't necessarily mean you can edit them 
like simple text files. Plan 9 has some really interesting paradigms with read 
only files, updating using control file protocols, append only files, file 
descriptors that return errors for invalid writes. I've only scratched the 
surface. It could be a really interesting project to write up how different 
paradigms work for certain scenarios.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

I recompiled with the latest in hg. I'm still not having success with the 
multicast. I'm going to start adding debugging to figure out what's going on.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Thanks Alex, Cinap,

Right, the Pi uses USB for its built in nic.

I wanted to make sure that I have narrowed down where the missing functionality 
is. It sounds like I need to have a look at how multicast filtering works with 
supported PCI nic cards and apply that to nusb/ether.

Chris

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

If plan 9 had taken off I wonder if there would be peripherals with built-in 9P 
support.

For example, a network adapter that you can mount into /net/etherxyz over USB, 
PCI using a 9P connection. No driver needed, except to communicate with the bus.

Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. 
UTF-8 file names, of course.

Maybe 9P could be implemented in a SoC.

Chris

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

Hi,

I have been pondering the same kind of thing myself lately. In an alternate 
bizarro universe, what would the web look like that is modelled more around 
plan 9 concepts. Heres my fantastic take on this.

First, there is a focus on simplicity of implementation and interface over 
flashiness of UI. As a result, services are much easier to use directly rather 
than having to rely on html/js UIs. You just mount search engine, route 
planning tool, or even shopping site and echo commands into the ctl file. And 
you get back results as numbered files with simple text output. User 
doesnt accidentally run malicious software embedded in the service. 
Its all just 9P.

If a service is complex enough, due to complexity of the problem it is trying 
to solve (not invented complexity). Source code is posted on the service in C 
source code form. User runs mk, which is super fast because the compilers are 
optimized for this. They run the program in a rfork+rio sandbox. Users quickly 
learn how simple this is and do it regularly so that in trusted programs 
dont have access to what they shouldnt. The process isnt 
automatic so it doesnt happen without user knowledge. Pop ups and such are 
not possible.

User wraps the connection in tls if they dont want any snooping. Sensitive 
services such as banking dont allow unencrypted sessions.

URLs are just relative paths, navigable using acme and plumber. Absolute 
links to sites dont exist since the user can map their namespaces any way 
they choose. Instead, documents may give 9P connection information and 
locations. Cross site linking becomes very clear. To facilitate ease of 
navigation and discovery services pop up to curate documents with nice easy 
relative linking within that service.

Multimedia documents with both pictures and text are compiled into self 
contained files kind of like PDF without hyperlinks and arbitrary code 
expectation. Links between documents are relative paths as above. Users are 
accustomed to using simple text or even markup/markdown for most things. This 
rich format is for longer and more focused reading sessions: studying a topic, 
leisure reading.

Implementers of Internet services have a strong focus on simplicity of 
implementation and interface, but also in adopting common conventions. For 
example, a ctl file where you send commands and numbered directories with 
results of each invocation. Perhaps a new convention could be to include a 
readme file and maybe man page with details about how to use the service. Also, 
services are designed to be focused enough and standard enough that they can be 
easily interact with other services using pipes, redirects, etc. so that the 
user can combine them to suit their needs.

Services take advantage of the simplicity of plan 9 and 9P to easily sandbox, 
proxy and load balance their services. Also, commodity and mixed architecture 
systems are easily integrated for free or new services that are built with 
whatever hardware they can find.

Single signon is achieved using symmetric encryption. If the service recognizes 
your public key and you are able to sign a message using your private key you 
can proceed. Not sure how much overlap there is here with what is in tls and 
factotum. Something like factotum could be useful to allow you to specify 
different keys (identities) for different services. The point here is that 
authentication is in the users control and not the service. The user ever 
only needs to remember one password or store their thumbprint in one place.

Thats all I have so far.

Chris

[9fans] 9P - Meaning of iounit

[Chris McGee]

Hello All,

I am learning the 9p protocol and implementing a 9P server. After reading the 
9p manual page, the types of messages and much of the overview is clear. There 
are a number of items that are less clear.

For example, it took some time to figure out how to provide a directory 
structure on a Tread.

Lately, I’m looking at the “iounit.” Initially, I had thought of it as a way to 
give the size of a file on Topen. After some testing I realized that the 
network subsystem in plan9 is expecting the iounit to be large enough to write 
commands into a /net/tcp ctl file. With a small iounit, the network subsystem 
truncates the commands, such as “connect xyz|1234” to match the size of the 
iounit.

So, what is this mysterious iounit? Is there another man page or plan9 document 
that describes it in more detail?

Thanks,
Chris

Re: [9fans] 9P - Meaning of iounit

[Chris McGee]

Thanks Richard, James,

Chris

> On Oct 3, 2016, at 11:05 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
> term% lookman iounit
> man 2 fcall # fcall(2)
> man 2 iounit # iounit(2)
> man 3 proc # proc(3)
> man 5 0intro # 0intro(5)
> man 5 open # open(5)
> man 5 read # read(5)
> 
> 

Re: [9fans] Terminal possibliities...

[Chris McGee]

It would be interesting to hear how this works out in practice. The bandwidth 
requirement is probably so low compared to typical traffic from a hotel, 
compared even to smart phones.

> On Sep 30, 2016, at 3:49 PM, James A. Robinson  wrote:
> 
> Is anyone here using Plan 9 as a terminal to connect to remote CPU / File 
> servers over the internet to get work done?
> 
> If I set up a small Plan 9 cluster at home, I'm thinking it'd be pretty neat 
> to be able to connect to the network at home over the internet.
> 
> While I have a laptop and could put 9front on it, I also really like the 
> thought of carrying around a little Raspberry Pi and portable keyboard/mouse 
> as an alternative.  Sitting here in a cheap motel room, I realized that all 
> the hotel rooms I've been in over the past few years have a decent flat 
> screen television that takes an HDMI input and has had decent, if not 
> amazing, WiFi to the internet.
> 
> Jim
> 

[9fans] 9p - meaning of iounit

[Chris McGee]

Hello All,

I am learning the 9p protocol and implementing a 9P server. After reading the 
9p manual page, the types of messages and much of the overview is clear. There 
are a number of items that are less clear.

For example, it took some time to figure out how to provide a directory 
structure on a Tread.

Lately, I’m looking at the “iounit.” Initially, I had thought of it as a way to 
give the size of a file on Topen. After some testing I realized that the 
network subsystem in plan9 is expecting the iounit to be large enough to write 
commands into a /net/tcp ctl file. With a small iounit, the network subsystem 
truncates the commands, such as “connect xyz|1234” to match the size of the 
iounit.

So, what is this mysterious iounit? Is there another man page or plan9 document 
that describes it in more detail?

Thanks,
Chris

Re: [9fans] Terminal possibliities...

[Chris McGee]

I believe that it is documented somewhere on Russ Cox’s website or on plan9port.

Basically, you can hold down the ctrl or alt keys while clicking/dragging to 
simulate the same action with the middle or right mouse button. I think that 
chording is possible too by holding down both ctrl and alt at the same time. 
Although, I’m not sure how you would do chording with the left and middle or 
left and right. Maybe you can use shift in those cases.

I’m wondering if this kind of thing has been discussed before. Perhaps there 
are good reasons to keep the functionality out of p9bl or 9front?

Chris

> On Oct 2, 2016, at 10:28 PM, s...@9front.org wrote:
> 
> Could you explain exactly what the modifiers are and how they work?
> 
> sl
> 

Re: [9fans] Terminal possibliities...

[Chris McGee]

Is there any interest in putting these p9port style keyboard modifiers into 
p9bl or 9front?

It might be a good backup for when I don’t have a true three button mouse 
kicking around.

Chris

> 
> Since I'm on a macbook with a one-button touchpad I end up using
> the keyboard modifiers plus the patch submitted by djeannot24 to
> plan9port (see https://codereview.appspot.com/6115053 
> ) to help get
> around the lack of buttons.
> 
> Jim
> 

Re: [9fans] Terminal possibliities...

[Chris McGee]

Sure, they would work but it's one more thing to have to charge. My drill 
batteries are always charged and I already own them.

> On Oct 1, 2016, at 9:40 AM, James A. Robinson <jim.robin...@gmail.com> wrote:
> 
> Honestly I had been assuming one of those usb battery packs would work. :)
> 
> On Sat, Oct 1, 2016 at 4:59 AM Chris McGee <sirnewton...@yahoo.ca> wrote:
> I found some $4 voltage regulators that will convert 18v Lithium ion drill 
> batteries to power my Pi. Could be useful for field work.

Re: [9fans] Terminal possibliities...

[Chris McGee]

> I forgot the thinkpad also has an inbuilt battery. Good for mobility
> and against flaky power in development countries.

I found some $4 voltage regulators that will convert 18v Lithium ion drill 
batteries to power my Pi. Could be useful for field work.

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image

[Chris McGee]

Thanks David,

I will give this a try.

Chris

On Oct 28, 2016, at 2:58 AM, David du Colombier <0in...@gmail.com> wrote:

>> you have to have an n-1 version of Go to compile n
> 
> You have to bootstrap from Go >= 1.4.
> 
> If you want to build the current Go source from scratch on plan9/386,
> you can just do:
> 
> cd /tmp
> git clone -b go1.4.3 https://go.googlesource.com/go go1.4
> cd go1.4
> hget http://9legacy.org/go/patch/syscall-exec.diff | ape/patch -p1
> cd src
> make.rc
> 
> GOROOT_BOOTSTRAP=/tmp/go1.4
> cd /tmp
> git clone https://go.googlesource.com/go
> cd go/src
> make.rc
> 
> This is documented on https://github.com/golang/go/wiki/Plan9
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David,

These binaries are great as a starting point to compile newer versions of Go.

I almost fully automated the preparation of my 9front rpi sd card images. Cross 
compiling from plan9 386 to plan9 arm using the bootstrap fails with this error:

Install: './install' not found

Maybe cross compile isn't working with Go on plan9 yet?

Thanks,
Chris

> On Oct 28, 2016, at 4:14 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> As you wish:
> 
> http://www.9legacy.org/download/go/go1.7.3-plan9-386-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-amd64-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-arm6-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-arm7-bootstrap.tbz
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image

[Chris McGee]

I was thinking about this myself. I'm more in favour of a script that downloads 
the go source and compiles it since it seems to be more in the spirit of plan9.

The trouble is that Go has made it harder to do now that you have to have an 
n-1 version of Go to compile n. This started with 1.5 but 1.5 doesn't seem to 
compile or run well on plan9.

Maybe a compromise would be to have tbz binaries for 1.7 and a script that 
takes them and uses it to compile a fresh copy from sources and cleans up the 
bootstrap. Otherwise, you need to cross compile from another OS. Yuck.

Chris

> On Oct 27, 2016, at 12:26 PM, Marshall Conover  wrote:
> 
> Hi All!
> 
>I compiled a Go binary for use on Richard Miller's raspberry pi image in 
> contrib (thanks for that Richard, by the way). I threw up a link to the 
> binary in a previous email a week or two ago, but I think that email got spam 
> filtered, so I won't link it again - but, is there a good place to make this 
> available for ease-of-use? Woudl've been nice to just hget a tgz and extract 
> it when I was getting things up and running the other day, instead of getting 
> go set up on my linux box, compiling it, setting the final_goroot, etc. 
> Richard, if you're comfortable with it, I could pass it to you to throw up on 
> your contrib.
> 
> Thanks!
> 
> Marshall

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

To cross compile with make.rc do you just set GOARCH and GOOS and just run it?


> On Oct 29, 2016, at 2:46 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> > Maybe cross compile isn't working with Go on plan9 yet?
> 
> I don't know about bootstrap.sh, but cross-compiling works fine on Plan 9 
> using make.rc.
> 
> -- 
> David du Colombier

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Hi All,

I have cleaned up some of the concurrency code and USB. The new release is here:
https://github.com/sirnewton01/rpi-9front/releases/tag/nov2016-2 


Thanks,
Chris

Re: [9fans] 9front on raspberry pi

[Chris McGee]

> On Nov 7, 2016, at 6:44 AM, arisawa  wrote:
> 
> by the way I said about raspi 1
>> the display size is 1920x1200.
>> when I try to resize a window, the mouse cursor flips and it is difficult to 
>> resize.
> This phenomenon was stopped when I connected lan cable.
> I don’t know the reason.

Interesting data point. Thank you. I tend to keep mine plugged into an active 
Ethernet switch. I'll try without to see if I can narrow down the problem.

> 
> I looked the source code and I guess for raspi 1:
> Plan9BCMpin
> GPIO01711
> GPIO11812
> GPIO22713
> GPIO32215
> GPIO42316
> GPIO52418
> GPIO62518
> GPIO7 4 7
> GPIO82824
> GPIO92921
> GPIO1030?
> GPIO1131?
> SDA 2 3
> SCL 3 5
> CE1 726
> CE0 824
> MISO 921
> MOSI1019
> SCLK1123
> TxD14 8
> RxD1510
> 
> and I tried some experiments.
> 
> (a) turn led light on/off that is connected to GPIO0 pin

Cool, good to know that part is working for others.

> 
> term% echo function out GPIO0 >ctl
> term% echo 1 > GPIO0
> term% echo 0 > GPIO0
> term% 
> 
> the result is OK.
> 
> (b) read GPIO1 status
> 
> term% echo function in GPIO1 >ctl
> 
> I expected:
> term% cat GPIO1# low voltage
> 0
> term%
> 
> however I have:
> term% cat GPIO1# low voltage
> 00...
> 
> I expected:
> term% cat GPIO1# high voltage
> 1
> term%
> 
> however I have:
> term% cat GPIO1
> 11...
> 
> is this a feature or bug?
> 

This part is inherited and merged in from original 9front source code. As we 
discussed before there seems to be no manual page. I'm not sure the intended 
behaviour and I have not yet tried reading from a gpio pin myself.

So in either case on the read it just repeats forever until interrupted?

Chris

Re: [9fans] libtask

[Chris McGee]

If you're interested in Go, this 9p library has worked reasonably well for my 
servers.

https://github.com/docker/go-p9p


> On Oct 18, 2016, at 1:31 PM, Iruatã Souza  wrote:
> 
> https://github.com/iru-/lua9p
> 
>> On Thu, Oct 13, 2016 at 3:47 PM, yy  wrote:
>>> On 13 October 2016 at 18:03, Steve Simon  wrote:
>>> Anyone written or ported a small simple 9p library;
>> 
>> As part of a GSoC project I wrote
>> https://bitbucket.org/yiyus/devwsys-prev/src/tip/libninep/ (man pages
>> can be found in the same repo). There is a ninepserver but not a
>> ninepclient because the only client I wrote was to be used with p9p,
>> so I was using 9pclient(3), but it should be relatively easy to write
>> one if you need it.
>> 
>> 
>> --
>> - yiyus || JGL .
>> 
> 

Re: [9fans] libtask

[Chris McGee]

Yeah, I saw that and it made me chuckle, especially once I discovered the 
recursive reflection.

It's reasonably easy to program in it. I know that it can handle 16 bit 44.1 
kHz stereo pcm streaming over a network. Does that it "performing?"

Chris

> 
> Reading the description of the go-p9p, it says "A modern, performant 9P 
> library for Go.".  I'm guessing "modern" refers to being implemented in Go.  
> Any pointers on how performance was measured or what it was measured against?
> 
> 
> 
>> On Tue, Oct 18, 2016 at 11:32 AM Chris McGee <newton...@gmail.com> wrote:
>> If you're interested in Go, this 9p library has worked reasonably well for 
>> my servers.
>> 
>> https://github.com/docker/go-p9p
>> 
>> 
>>> On Oct 18, 2016, at 1:31 PM, Iruatã Souza <iru.mu...@gmail.com> wrote:
>>> 
>>> https://github.com/iru-/lua9p
>> 
>>> 
>>> 
>>>> On Thu, Oct 13, 2016 at 3:47 PM, yy <yiyu@gmail.com> wrote:
>>>>> On 13 October 2016 at 18:03, Steve Simon <st...@quintile.net> wrote:
>>>>> Anyone written or ported a small simple 9p library;
>>>> 
>>>> As part of a GSoC project I wrote
>>>> https://bitbucket.org/yiyus/devwsys-prev/src/tip/libninep/ (man pages
>>>> can be found in the same repo). There is a ninepserver but not a
>>>> ninepclient because the only client I wrote was to be used with p9p,
>>>> so I was using 9pclient(3), but it should be relatively easy to write
>>>> one if you need it.
>>>> 
>>>> 
>>>> --
>>>> - yiyus || JGL .
>>>> 
>>> 

Re: [9fans] How to take a portion of a screenshot

[Chris McGee]

I tried to write an rc script that would make a screen video as an animated 
gif. I have something that almost works, but ran into a few 
problems/limitations.

* I can’t seem to find a way to have an incrementing loop counter in rc shell 
(best I could do is check the size of a growing list variable)
* The gif command barfs when the GIF is any larger than a few megabytes due to 
an allocation error
* I couldn’t think of a good way to name the image files so that they can be 
sorted into the correct sequence as input to togif

I’ll try banging my head on the solution again tomorrow. I’m hoping that either 
it can be a one-liner of rc shell scripting or put into a full utility script 
(e.g. recscreen) that anyone could use.

Thanks,
Chris

> On Nov 23, 2016, at 3:07 PM, Skip Tavakkolian <9...@9netics.com> wrote:
> 
>> it's one of the reasons I'm liking plan 9.
> 
> ingenious glenda.
> 

[9fans] Trouble finding current window directory in acme

[Chris McGee]

Hi All,

I’m in the process of writing an interactive tutorial for plan9/acme. I’m 
hoping to demonstrate how to execute a command on a text file that uses the 
current selection as input.

According to the acme manual page there should be a /dev/acme/acme (or 
/mnt/acme/acme) directory that represents the current window within acme. There 
should be the usual body, ctl, addr, etc. files. On a regular document window 
I’m finding that the directory is empty. However, when I run an interactive 
“win” window the files are there for that window.

How does one get the /dev/acme/acme directory to be present in a normal 
document window? Alternatively, is there a simple way to find the index of the 
current acme window so that I can use the /dev/acme/x directory?

Thanks,
Chris

Re: [9fans] Trouble finding current window directory in acme

[Chris McGee]

Thanks, that will work.

Chris

> On Nov 26, 2016, at 12:56 PM, Antons Suspans <an...@ml.lv> wrote:
> 
> On Sat, Nov 26, 2016 at 12:41:21PM -0500, Chris McGee wrote:
>> How does one get the /dev/acme/acme directory to be present in a normal 
>> document window? Alternatively, is there a simple way to find the index of 
>> the current acme window so that I can use the /dev/acme/x directory?
> 
> Use /mnt/acme/$winid for that purpose. It's described in acme(1).
> 
> Hope this helps,
> Antons
> 

Re: [9fans] How to take a portion of a screenshot

[Chris McGee]

Thanks Richard,

That is the kind of thing I was looking for. And yes, it's one of the reasons 
I'm liking plan 9. Each piece does one thing we'll.

Chris

On Nov 23, 2016, at 11:06 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> I'm working on some documentation and would like to include a portion of the 
>> screen in a particular window. What's a good way to take the shot but also 
>> snip out the piece that I'm interested in?
> 
> Making a screenshot is one of those delightful examples of
> the elegant simplicity of Plan 9:
> 
>cat /dev/screen >screenshot.pic
> 
> To select a rectangle from an image you can use crop(1)
> 
> 

Re: [9fans] Using plot(1)

[Chris McGee]

Thanks,

> not sure what you mean by pipe the output, if you want to save the graph
> you need to do that by grabbing the window, there could be things like 
> gifplot which render the plot command stream into a gif, but it doesn't (yet).

Yes, this is what I was after. I'll try fetching the window buffer and extract 
it from there. I'll see if a command line switch can be added easily to plot to 
do just that.

> i am pretty sure graph has a "don't clear the screen" option if that will do 
> for you,
> however my suspicion is that if you close and reopen the stream to plot it 
> will
> clear and redraw the screen. i thing (guess) that you would need to send all 
> your
> plot commands in a single stream.

I was thinking that if plot didn't automatically clear the window (maybe with 
an option) you could add a background to the plot. Another option could be for 
plot to have an image command that imports and draws one from a file.

>> o
>> ra -1.0 -1.0 1.0 1.0
>> e
>> co r
>> cf r
>> di 0.0 0.0 1.0
>> co k
>> li 0.0 -1.0 0.0 1.0
>> li -1.0 0.0 1.0 0.0
>> cl


I tried this same plot program on a raspberry Pi with much slower graphics and 
I noticed that the red circle is drawn for an instant and then disappears 
behind a white box that covers most of it. I tried it without the lines and 
it's the same thing. Not sure what is clipping the circle. Very strange.

Chris

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

A C compiler that supports the latest spec would be nice as long as it doesn't 
sacrifice compile times. I like how quickly the system can recompile itself. 
Maybe extend pcc to include new features?

Go works pretty well and is on its way to be a supported platform. I use it 
quite frequently on 9front.

For git, there's a wrapper script for github and others. But yes, a fuller 
featured git would be good. There are some projects trying to do that in Go. 
Maybe that'll work someday.

Mercurial is already there on 9front via python.

Chris

> On Nov 16, 2016, at 5:27 PM, Charlie Lin  wrote:
> 
> Any plans for Plan 9 5th edition?
> 
> My desires:
> ISO-compliant C compiler and preprocessor
> Port other programming languages (especially Go) to here
> Start a source code repository
> Port Git, SVN, Mercurial, et cetera to here

Re: [9fans] Hack font for plan9

[Chris McGee]

Thanks for checking it out.

I'll check the tool for sizing problems.

Chris

On Nov 16, 2016, at 9:27 AM, Steve Simon  wrote:

>> I have converted the open source font called Hack to plan 9 font format.
> 
> Thats nice, not sure if I will switch, I will try it for a week or so...
> 
> I think the sizes are wrong, the 14 point in the hack directory looks close 
> to 9 point in
> the plan9 pelm font.
> 
> -Steve
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

There's also Gogits.

https://github.com/gogits/git

I haven't tried it yet.

Chris

> On Nov 17, 2016, at 11:16 AM, Dave MacFarlane <driu...@gmail.com> wrote:
> 
>> On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> wrote:
>> For git, there's a wrapper script for github and others. But yes, a fuller
>> featured git would be good. There are some projects trying to do that in Go.
>> Maybe that'll work someday.
> 
> I know I started a really half-assed, wholly-abandoned implementation
> here: https://github.com/driusan/go-git
> when I was starting to learn Go so that I could fix a bug in some of
> my code on Plan 9 (eventually I just made
> the change, tested it, and copied the file to a supported git platform
> over drawterm, and commited it from there..)
> 
> Who else is trying to do it?
> 
> - Dave
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

It doesn't build for me anymore. Fixing the make file seemed non trivial.

Chris

> On Nov 17, 2016, at 12:50 PM, Ori Bernstein <o...@eigenstate.org> wrote:
> 
> https://bitbucket.org/oridb/libgit2
> 
> If someone wants to actually turn it into a git client, it at least builds
> (or used to).
> 
>> On Thu, 17 Nov 2016 11:16:20 -0500, Dave MacFarlane <driu...@gmail.com> 
>> wrote:
>> 
>>> On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> wrote:
>>> For git, there's a wrapper script for github and others. But yes, a fuller
>>> featured git would be good. There are some projects trying to do that in Go.
>>> Maybe that'll work someday.
>> 
>> I know I started a really half-assed, wholly-abandoned implementation
>> here: https://github.com/driusan/go-git
>> when I was starting to learn Go so that I could fix a bug in some of
>> my code on Plan 9 (eventually I just made
>> the change, tested it, and copied the file to a supported git platform
>> over drawterm, and commited it from there..)
>> 
>> Who else is trying to do it?
>> 
>> - Dave
>> 
> 
> 
> -- 
>Ori Bernstein
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David,

Will you add new Go releases there as they come out so that we can bootstrap 
from previous releases?

Also, the Git script is working quite well for me. Thanks for that too.

Chris

> On Nov 13, 2016, at 1:07 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> I've updated the Go binary packages with the fix to make.rc:
> 
> http://9legacy.org/download/go/go1.7.3-plan9-386-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-amd64-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-arm6-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-arm7-bootstrap.tbz
> 
> -- 
> David du Colombier
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

I like the idea of focusing on the functionality, not specific software, that 
could go into a 5th edition. It seems that stepping back and rethinking popular 
industry trends led to some of the unique and interesting decisions that gave 
us plan9 in the first place.

Here is what I'd like to see
-3D graphics (something akin to /dev/draw except for graphics pipelines)
-Location capabilities (gps, map drawing, routing)
-Mobile interface (clean, simple, optimized for small and touch screens)
-2D graphics editing (edit photographs or make raster art from scratch, layers, 
antialiasing, filesystem for scripting)
-3D printing (manipulate 3D model data, output one of the standard formats for 
printers)
-Knowledge/AI system (plug in statements, make inferences)
-Notifications (deliver events, alerts and reminders to my attention in a 
consistent manner)
-Search quickly for files based on content (indices, also accessible via 9P, 
there's a paper floating around about this)
-Easily find disk space statistics (free disk space for each file system)
-Single Instruction Multiple Data (language and compiler for writing programs 
that can use these special instructions)
-Video playback and recording (support for most popular 3 codecs, including one 
of the free ones, syncing of audio stream, record from camera and/or screen)
-Clean HTML (not fully featured web browser, instead render existing HTML in a 
clean, readable way, not unlike the various reader modes in popular web 
browsers, convert to PDF/PS)

I think that each of these can be done in the plan9 way with simple, consistent 
and elegant implementations that integrate well with the rest of the system. 
The focus is to enable capability and not necessarily to just port existing 
software, repeating existing complexity and bloat.

Chris

> On Nov 19, 2016, at 3:37 PM, Charlie Lin  wrote:
> 
> Any features that should be incorporated into Plan 9?
> 
> 
>> On Nov 16, 2016 17:27, "Charlie Lin"  wrote:
>> Any plans for Plan 9 5th edition?
>> 
>> My desires:
>> ISO-compliant C compiler and preprocessor
>> Port other programming languages (especially Go) to here
>> Start a source code repository
>> Port Git, SVN, Mercurial, et cetera to here

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

This one might be adapted to work for gitlabs. It only supports read only type 
commands: clone, checkout, pull.

http://9legacy.org/9legacy/tools/git

It could be a start.

Chris

> On Nov 21, 2016, at 10:08 AM, Wes Kussmaul  wrote:
> 
> 
> 
> On 11/21/2016 03:46 AM, Sigrid Haflinadóttir wrote:
> 
> 
>>Very kind!  Where can I download your Plan 9 git client?
> 
> I'm afraid mine is something of a "stone soup" offering. Perhaps someone can 
> add value to the soup by providing a client.
> 
> 
> -- 
> Wes Kussmaul
> 
> The Authenticity Institute
> 738 Main Street
> Waltham, MA 02451
> 
> office +1 781 790 1674
> mobile +1 781 330 1881
> 
> THIS COMMUNICATION IS INTENDED ONLY FOR THE USE OF THE PERSON TO WHOM IT IS 
> ADDRESSED.
> 
> If it was addressed incorrectly there's not much I can do but ask you 
> politely to pretend you didn't see it. Any disclaimer suggesting that the 
> sender has some kind of recourse is just wishful thinking.
> 
> If I had a message from you that was digitally signed using your Osmio VRD™ 
> identity credential from the Osmio Vital Records Department 
> (http://osmio.ch), we could easily and at no cost exchange
> encrypted messages and files with each other.
> 
> 
> 

[9fans] Hack font for plan9

[Chris McGee]

Hi All,

I have converted the open source font called Hack to plan 9 font format. It's 
designed to render source code and is working well for me.

https://github.com/sirnewton01/plan9-font-hack/releases

I used the this tool to convert it.

https://github.com/sirnewton01/ttf2plan9

I hope that they are useful.

Chris

Re: [9fans] Plan9 usage but used to parallel MPI on linux..

[Chris McGee]

I would be interested in manuals or papers on this subject as well.

Plan9 is well suited to distributed computing with its per process namespaces 
and network transparent resource access. Do grid computing projects built on 
plan9 use the built-in OS facilities such as cpu and 9p or do they generally 
favour custom protocols and for what reasons?

Cheers,
Chris

> On Oct 30, 2016, at 8:33 PM, Darren Wise  wrote:
> 
> Heya folks,
> 
> Can anyone point me in the right direction of some manuals concerning the use 
> of a beowulf cluster style of computing setup, i'm so used to MPI installs 
> and limiting myself to terminals that being what it seems ooout-f-he-box this 
> already is setup with parallel computing in mind..
> 
> Also some examples would be great of common current usages of such.
> 
> 
> 
> > Kind regards,
> > Darren Wise Esq, 
> > B.Sc , HND, GNVQ, City & Guilds.
> > 
> > Managing Director (MD)
> > Art Director (AD)
> > Chief Architect/Analyst (CA/A)
> > Chief Technical Officer (CTO)
> > 
> > www.wisecorp.co.uk 
> > www.wisecorp.co.uk/babywise 
> > www.darrenwise.co.uk 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

I tried this command with both go 1.7.3 and master branches. Both fail right 
after “ Building packages and commands for host, plan9/386” with an error 
“install: ./install not found.”

It seems like the go bootstrap tool is trying to call a binary called “install” 
but there are none on my system. Is there such a command on p9bl? Maybe 9front 
doesn’t have it?

It works fine if I don’t try to cross compile to plan9/arm or even linux/386.

Chris

> On Oct 30, 2016, at 4:39 AM, David du Colombier <0in...@gmail.com> wrote:
> 
> > To cross compile with make.rc do you just set GOARCH and GOOS and just run 
> > it?
> 
> Yes and you can add the --no-rebuild flag to prevent cmd/dist to remove the 
> existing binaries.
> 
> For example:
> 
> ℅ GOOS=plan9 GOARCH=arm make.rc --no-rebuild
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David, Stanley,

I managed to get the cross compile to work using the 9legacy go binaries and 
the git script.

The workaround for the error I received before is to create a dummy rc script 
called 'install' and put it into my /bin. The go make.rc script calls it and 
continues on seemingly fine afterwards.

Chris

> On Oct 30, 2016, at 9:47 PM, Stanley Lieber <s...@9front.org> wrote:
> 
> Chris McGee <newton...@gmail.com> wrote:
> 
>> I tried this command with both go 1.7.3 and master branches. Both fail
>> right after “ Building packages and commands for host, plan9/386”
>> with an error “install: ./install not found.”
>> 
>> It seems like the go bootstrap tool is trying to call a binary called
>> “install” but there are none on my system. Is there such a command on
>> p9bl? Maybe 9front doesn’t have it?
>> 
>> It works fine if I don’t try to cross compile to plan9/arm or even
>> linux/386.
>> 
>> Chris
>> 
>>> On Oct 30, 2016, at 4:39 AM, David du Colombier <0in...@gmail.com>
>> wrote:
>>> 
>>>> To cross compile with make.rc do you just set GOARCH and GOOS and
>> just run it?
>>> 
>>> Yes and you can add the --no-rebuild flag to prevent cmd/dist to
>> remove the existing binaries.
>>> 
>>> For example:
>>> 
>>> ℅ GOOS=plan9 GOARCH=arm make.rc --no-rebuild
>>> 
>>> -- 
>>> David du Colombier
>>> 
> 
> 'install' is from BSD. It does not exist in Plan 9.
> 
> sl
> 
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Thanks for trying it out. Can you raise a github issue with any error messages 
or data that I can use to try to fix the problem?

I understand that Richard's kernel that I used should work with Pi 1, 2 and 
zero. I have tried it with a Pi 1 B+ and Pi 2 B.

Sent from my iPhone
> On Nov 2, 2016, at 3:48 AM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> 
> I’ve tried both pi1 and pi2.
> both devices successfully boot up.
> 
> my impression only in primitive usage is:
> pi2 is fine. thanks Chris!
> pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally 
> detached.
> 
> 
>> 2016/11/02 14:05、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
>> 
>> thanks, i will try.
>> 
>> is this for pi1 or pi2 or both?
>> 
>>> 2016/11/02 10:35、Chris McGee <newton...@gmail.com> のメール：
>>> 
>>> Hi All,
>>> 
>>> I have released an experimental 9front raspberry pi image that I use for my 
>>> cluster.
>>> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
>>> 
>>> Highlights:
>>> -Latest 9front release 2016-10-27
>>> -Merged in Richard Millar’s kernel from a couple of months ago
>>> -Retains 9front GPIO filesystem structure
>>> -Link local ipv4 address on boot (low likelihood of collisions)
>>> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
>>> -9fs mount other nodes on the network
>>> -Go 1.7.3
>>> -Git script (works with github and google source repos)
>>> 
>>> Cheers,
>>> Chris
>> 
>> 
> 
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

> but something weird.
> term% mount -a '#G' /dev
> mount: can’t open '#G': permission denied
> I don’t know the reason.

Maybe you want to use bind instead?

> 
> using large display is frustrating...
> my portable HDMI display of 1280x800 works fine.
> 

What's wrong with the large display?

Re: [9fans] 9front on raspberry pi

[Chris McGee]

The GPIO doesn't have a manual page as far as I know. The implementation came 
from what is in 9front mainline and is in #G. I agree that it would be good to 
have a manual page for it there.

mDNS is running as bcast9p process and is written in Go. It's based on a Go 
library and uses udp multicast support for plan 9 that is only in latest git 
master branch, slated for Go 1.8.

Go SDK in this image is 1.7.3 though. It should be reasonably stable.

Chris

> On Nov 2, 2016, at 3:57 AM, Steve Simon <st...@quintile.net> wrote:
> 
> hi,
> 
> this is interesting.
> 
> can you tell me what the gpio file system looks like (pointer to man page?). 
> also, is the mDNS client the go one discussed recently or a c implementation?
> 
> i have never go'ed and have been thinking about writing a upnp renderer for 
> plan9 for years...
> 
> -Steve
> 
> 
>> On 2 Nov 2016, at 07:48, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
>> 
>> I’ve tried both pi1 and pi2.
>> both devices successfully boot up.
>> 
>> my impression only in primitive usage is:
>> pi2 is fine. thanks Chris!
>> pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally 
>> detached.
>> 
>> 
>>> 2016/11/02 14:05、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
>>> 
>>> thanks, i will try.
>>> 
>>> is this for pi1 or pi2 or both?
>>> 
>>>> 2016/11/02 10:35、Chris McGee <newton...@gmail.com> のメール：
>>>> 
>>>> Hi All,
>>>> 
>>>> I have released an experimental 9front raspberry pi image that I use for 
>>>> my cluster.
>>>> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
>>>> 
>>>> Highlights:
>>>> -Latest 9front release 2016-10-27
>>>> -Merged in Richard Millar’s kernel from a couple of months ago
>>>> -Retains 9front GPIO filesystem structure
>>>> -Link local ipv4 address on boot (low likelihood of collisions)
>>>> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
>>>> -9fs mount other nodes on the network
>>>> -Go 1.7.3
>>>> -Git script (works with github and google source repos)
>>>> 
>>>> Cheers,
>>>> Chris
>>> 
>>> 
>> 
> 
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Apologies Richard for misspelling your last name.

Chris

> On Nov 1, 2016, at 9:35 PM, Chris McGee <newton...@gmail.com> wrote:
> 
> Hi All,
> 
> I have released an experimental 9front raspberry pi image that I use for my 
> cluster.
> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
> 
> Highlights:
> -Latest 9front release 2016-10-27
> -Merged in Richard Millar’s kernel from a couple of months ago
> -Retains 9front GPIO filesystem structure
> -Link local ipv4 address on boot (low likelihood of collisions)
> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
> -9fs mount other nodes on the network
> -Go 1.7.3
> -Git script (works with github and google source repos)
> 
> Cheers,
> Chris

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Thanks,

I'm thinking that could be related to USB problem making the mouse jump around.

Chris

> On Nov 2, 2016, at 8:05 AM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> 
> hello Chris,
> 
>> 2016/11/02 20:17、Chris McGee <newton...@gmail.com> のメール：
>> 
>> What's wrong with the large display?
> 
> the display size is 1920x1200.
> when I try to resize a window, the mouse cursor flips and it is difficult to 
> resize.
> 
> 

[9fans] 9front on raspberry pi

[Chris McGee]

Hi All,

I have released an experimental 9front raspberry pi image that I use for my 
cluster.
https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016 


Highlights:
-Latest 9front release 2016-10-27
-Merged in Richard Millar’s kernel from a couple of months ago
-Retains 9front GPIO filesystem structure
-Link local ipv4 address on boot (low likelihood of collisions)
-Discovery of other nodes using multicast DNS through the ‘find9p’ command
-9fs mount other nodes on the network
-Go 1.7.3
-Git script (works with github and google source repos)

Cheers,
Chris

[9fans] 3D graphics as a filesystem

[Chris McGee]

Hello All,

I am looking at the specs for a GPU and was thinking about something analogous 
to /dev/draw, but for 3D graphics. Kind of like OpenGL except exposed as a 
filesystem so that it is network mountable and programmed in any language (even 
rc).

Does anyone know if this kind of thing has been done before for plan 9? Any 
relevant papers or documents out there?

My first thought involves representing elements in the graphics pipeline as 
files where you can write shader language code. Also a vertex file to write or 
read floating point vertex data. Maybe something more abstract would be better 
with scene graph and camera controls would be better match for a filesystem 
implementation.

Thanks,
Chris

Re: [9fans] 3D graphics as a filesystem

[Chris McGee]

Cool. Do you have any code that you can share for that? What does the file 
protocol look like?

> On Oct 12, 2016, at 7:17 PM, Jules Merit <jules.merit.eurocorp...@gmail.com> 
> wrote:
> 
> Yeah I prototyped draw3d with 9vx driver to host GPU on Linux system. MesajGL 
> if 9p file exists it supports mode of that name to transfer to gpu. It helps 
> if you have DooM handy to try writing it in rc.
> 
> 
>> On Oct 12, 2016 4:06 PM, "Chris McGee" <newton...@gmail.com> wrote:
>> Hello All,
>> 
>> I am looking at the specs for a GPU and was thinking about something 
>> analogous to /dev/draw, but for 3D graphics. Kind of like OpenGL except 
>> exposed as a filesystem so that it is network mountable and programmed in 
>> any language (even rc).
>> 
>> Does anyone know if this kind of thing has been done before for plan 9? Any 
>> relevant papers or documents out there?
>> 
>> My first thought involves representing elements in the graphics pipeline as 
>> files where you can write shader language code. Also a vertex file to write 
>> or read floating point vertex data. Maybe something more abstract would be 
>> better with scene graph and camera controls would be better match for a 
>> filesystem implementation.
>> 
>> Thanks,
>> Chris

[9fans] Using plot(1)

[Chris McGee]

Hi All,

I’m trying graph and plot out. I have some questions.

Is there a way to pipe the output of plot or do I need to pull that out of the 
screen/window buffer? Also, is there a way to plot on top of an existing image?

I tried making a simple plot routine to draw a red unit circle with x and y 
axes. The lines are drawing fine, but the circle is completely cut off except 
for a hint of the top-most and bottom-most edges. Here’s the routine that I’m 
using. Is there something obvious that I’m doing wrong?

o
ra -1.0 -1.0 1.0 1.0
e
co r
cf r
di 0.0 0.0 1.0
co k
li 0.0 -1.0 0.0 1.0
li -1.0 0.0 1.0 0.0
cl

Thanks,
Chris

Re: [9fans] git client-ish

[Chris McGee]

Thanks for the tool.

I managed to get it working on plan9front/386 Go 1.8 beta1 with a network 
connection. I will probably try it soon on plan9/arm.

Initially, it did not compile. Here are the quick fixes that I needed to make.

1) There is no syscall.Stat_t on plan9, instead the stat.Sys() returns a 
syscall.Dir

index.go:AddFile():
I changed stat to be fstat.Sys().(*syscall.Dir)
csec = stat.Mtime (This is how APE maps ctimes)
cnano = uint64(0) (There does not seem to be any nanosecond precision on mtimes 
in plan9)
uint32(stat.Qid.Path) (Roughly equivalent to inode numbers)
uint32(0) (GID’s are strings in plan9)
uint32(0) (UID’s are strings)
I assume that you want the library to be platform neutral so these should 
probably be abstracted.

2) Compile error

sha1.go:GetTree()
Sha1FromString(commit.Tree.Id.String())

The tests seem to be passing. I will try more rigorous tests. If the github bug 
gets fixed then I can submit pull requests.

Cheers,
Chris

> On Dec 3, 2016, at 2:20 PM, Dave MacFarlane  wrote:
> 
> I mentioned in another thread that I had started working on a pure go
> git client a while ago, then abandoned it, which gave me an itch to
> pick it up again. I've finally implemented enough that it can
> bootstrap its own development, and theoretically be used on Plan 9,
> but then I realized I don't currently have any machines with all of
> Plan 9, Go, and a network connection to test it on.
> 
> Would someone who has all of the above kindly try compiling it on Plan
> 9 and let me know if there's any problems? It's at
> https://github.com/driusan/go-git.You'll need the 9legacy git rc hack
> for Go to bootstrap it..
> 
> You should be able to:
> go-git init
> go-git clone*
> go-git fetch*
> go-git add file (from the root of the working directory only)
> go-git checkout file (same)
> go-git commit -m 'message'
> go-git status
> go-git merge (fast-forward only)
> go-git push works over https to GitLab, but not GitHub (GitHub
> responds with "200 OK" and no body but doesn't update the references,
> so I opened a ticket to see if I can get more information from them
> about why it doesn't work.. you also need to run as "go-git push
> localbranchname", which isn't the standard git command line.. )
> 
> The happy paths for a few other git plumbing commands are implemented.
> 
> The code's not very well written (I didn't know much about git
> internals or Go when I started, and mostly just wanted to hack
> something together that works at first), but if anyone wants to
> contribute, you can try to email me a patch using ape/diff in some
> kind of format that I can apply under DragonFlyBSD and commit under
> your name until whatever the issue with GitHub is is resolved..
> 
> * large repositories will likely crash because the Go zlib
> implementation is greedy on the underlying io.Reader, and the hack
> that I added to rewind to the end of the last compressed block when
> reading packfiles isn't 100% accurate.
> 
> - Dave
> 

[9fans] New 9front image for raspberry pi

[Chris McGee]

Hi All,

I have published a new version of 9front image for raspberry pi. This version 
has a draft of an interactive tutorial in acme. I hope that it can help new 
people like myself to discover some of the basics of the system.

https://github.com/sirnewton01/rpi-9front/releases/tag/nov2016-4 


Cheers,
Chris

Re: [9fans] git client-ish

[Chris McGee]

Thanks for setting this up. It's going to be really helpful for my work.

Cheers,
Chris

> On Dec 5, 2016, at 12:14 PM, Dave MacFarlane <driu...@gmail.com> wrote:
> 
>> On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee <newton...@gmail.com> wrote:
>> 
>> The tests seem to be passing. I will try more rigorous tests. If the github
>> bug gets fixed then I can submit pull requests.
> 
> The bug that was preventing me from pushing to GitHub is now fixed, so
> if you update
> feel free to pull request away.
> 
> - Dave
> 

[9fans] Test, please ignore

[Chris McGee]

Test

[9fans] Backgrounding a task

[Chris McGee]

Hi All,

When I'm using Unix, there's a workflow that I use for long running commands 
that I'm hoping to find the equivalent in the Plan 9 way of doing things.

I will occasionally run a command, realize that it will take a long time to 
complete. I don't want to kill it. I'll just Ctrl-Z and bg to put it into the 
background using the shell. It's almost as if I had run it with '&' in the 
first place. I can then run other commands in the same working directory, 
environment and shell history.

Is there an equivalent to this workflow in Plan 9?

I realize that the whole job control system dates back to old single session 
terminals, which isn't a problem with Rio where you can draw new windows at 
will. Initially I thought, that you just drag that window to a corner somewhere 
and let it complete. But, if I draw a new window it won't be in the same 
working directory, have the same environment and namespace. Maybe there is a 
way to create a window that inherits these from an existing process?

Chris

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] Backgrounding a task

[Chris McGee]

Thanks for the tip! I'll give that a try.

Chris

> On Oct 7, 2017, at 12:04 AM, Skip Tavakkolian <skip.tavakkol...@gmail.com> 
> wrote:
> 
> Spitballing here: in the new window do something like
> 
> cat /proc/123/ns | rc 
> 
> Or first massage the ns then generate an output for rc.
> 
>> On Fri, Oct 6, 2017, 4:34 PM Chris McGee <newton...@gmail.com> wrote:
>> Hi All,
>> 
>> When I'm using Unix, there's a workflow that I use for long running commands 
>> that I'm hoping to find the equivalent in the Plan 9 way of doing things.
>> 
>> I will occasionally run a command, realize that it will take a long time to 
>> complete. I don't want to kill it. I'll just Ctrl-Z and bg to put it into 
>> the background using the shell. It's almost as if I had run it with '&' in 
>> the first place. I can then run other commands in the same working 
>> directory, environment and shell history.
>> 
>> Is there an equivalent to this workflow in Plan 9?
>> 
>> I realize that the whole job control system dates back to old single session 
>> terminals, which isn't a problem with Rio where you can draw new windows at 
>> will. Initially I thought, that you just drag that window to a corner 
>> somewhere and let it complete. But, if I draw a new window it won't be in 
>> the same working directory, have the same environment and namespace. Maybe 
>> there is a way to create a window that inherits these from an existing 
>> process?
>> 
>> Chris

Re: [9fans] Backgrounding a task

[Chris McGee]

The namespace join facility looks interesting. Do you have a patch somewhere 
for it?

> Of course, a lot of the isolation that per-process namespaces give you
> is suddenly undone by the introduction of this facility.  

I'm not sure if the lack of isolation is any different than what can be done 
with a child process that shares the namespace. Is there a particular case that 
you are thinking?

> At this
> point I'm not entirely convinced that it's worth the trouble.

I think that it can be depending on how much time you have spent building up a 
namespace for a process. Perhaps I have spent hours working on something slowly 
customizing the namespace mounting and binding things. If I end up running a 
long running command that blocks and I want to work in parallel with it then I 
must remember everything that I have done and repeat in a new window. It seems 
like something the computer should do for me or at least help me to do it.

Re: [9fans] Backgrounding a task

[Chris McGee]

> Think about multiple processes owned by multiple users running on a
> cpu server.  Which processes should be allowed to join which
> namespaces?
> 
> Perhaps allowing only the hostowner to join namespaces for debugging
> and administration purposes would be acceptable.

Ah, right. What about only allowing a process to join another namespace if the 
user is the same?

> This seems a contrived example.  Would you really spend HOURS working
> on setting up a namespace by hand?  Surely you would instead be
> working on a script that builds the namespace for you; make the
> computer do the work.  Then when you mess up, you can modify the
> script, create a new window, and try again.

Yes, good point. That's the best way to do it. Also screen file can help add 
commands to the script post facto. The hours term isn't so much in the 
development of the environment but more to do with the amount of time you could 
be working in that shell instance. All the while not remembering all of the 
things you did to the namespace and environment in that time.

Cheers,
Chris

Re: [9fans] how to undo in Rio shell window and Acme editor?

[Chris McGee]

There’s a ‘win’ command you can executed in acme to get an interactive rc shell 
window.

> On May 9, 2018, at 11:40 AM, 刘宇宝  wrote:
> 
> Great thanks for your idea,  file oriented design is very flexible! The 
> prompt function may be used to automatically backup the output of previous 
> command,  a poor man's undo buffer :-D
> 
> I tried to execute "rc" in Acme, seems Acme always execution command with 
> /dev/null as stdin, I can't embed an interactive rc session into Acme and 
> leverage the undo buffer of Acme window.
> 
>> On May 9, 2018, at 10:14 PM, Steve Simon  wrote:
>> 
>> hi.
>> 
>> i think it is humour of a kind.
>> 
>> i cannot speak for acme but rio has no undo buffer, so what you ask for is 
>> not possible.
>> 
>> you can save a windows content (including history). e.g. /dev/wsys/11/text 
>> /tmp (assuming the window you want is number 11, cat /dev/winid to get the 
>> current windows id)
>> 
>> -Steve
>> 
>> 
>> On 9 May 2018, at 11:55, 刘宇宝  wrote:
>> 
> I miss much the *universal* shortcut Ctrl-z on Window and Command-z on 
> macOS,  does Rio and Acme have the equivalent?
> 
 
 Both the Ctrl key and the z key are fully supported on 9front Systems.
 To remove undesired characters from the screen, the Backspace key is
 also automatically provisioned, free of charge. 
>>> 
>>> Wow, is this kind of humor like the picture at the bottom of 
>>> http://fqa.9front.org/ ?
>>> 
>>> I'm not a troll,  I wrote several articles to introduce Plan 9 some days 
>>> ago, I'm seriously asking :-D
>>> 
>>> Maybe I already got the answer @_@
>>> 
>>> Thanks,
>>> Yubao Liu
>> 
>> 
> 

[9fans] Acme create new file

[Chris McGee]

Hi All,

I’ve been using acme for a while and really enjoying the capability in such a 
small (code size) tool.

I’ve been creating new files by executing New to create a new window, typing 
the full path of the new file and then Put to save it. Am I missing an easier 
way to do this, perhaps via a directory window where I want the new file?

Thanks,
Chris

Re: [9fans] Acme create new file

[Chris McGee]

Thanks all, these suggestions worked great. I don’t know how I missed it in the 
docs and tutorials.

Chris

> On May 13, 2018, at 5:49 AM, Charles Forsyth <charles.fors...@gmail.com> 
> wrote:
> 
> Type B filename in the tag of an existing frame in the directory and execute 
> it with button 2; or type B filename as a command in that directory in a win 
> frame or rio window.
> 
> 
>> On 13 May 2018 at 02:22, Chris McGee <newton...@gmail.com> wrote:
>> Hi All,
>> 
>> I’ve been using acme for a while and really enjoying the capability in such 
>> a small (code size) tool.
>> 
>> I’ve been creating new files by executing New to create a new window, typing 
>> the full path of the new file and then Put to save it. Am I missing an 
>> easier way to do this, perhaps via a directory window where I want the new 
>> file?
>> 
>> Thanks,
>> Chris
> 

Re: [9fans] There is no fork

[Chris McGee]

Thanks everyone. This thread has been a fascinating read for me.

Chris

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

> I believe that the core of the problem with the C language is that is
> based upon abstracting the PDP-11 instruction set.  CPUs, such as Intel/AMD
> x64 are vastly more complex so "optimising" C compilers are trying to make
> something simple take advantage of something far more complex.  Perhaps we
> should call them "complexifying" compilers.
>
> Generally, model-to-model transformations (which is effectively what
> compilers do under the covers) are easier to define when we transform from
> a higher level of abstraction to a lower level of abstraction.  As folks in
> the MBSE field explain it, trying to put a pig together from sausages.
>

I wonder if the hardware world suffers from some of the same complexity
problems the software world does. Is it possible to build much simpler
hardware as well or are there real physical properties that force them to
be as complex as they are now?

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

> Take a look at greenarraychips.com and how Chuck Moore tries to
> simplify the whole instead of software or hardware.
>

Thanks, that is a very interesting read on the topic of asynchronous and
highly parallel computing. I'm not sure if the designs for these are very
simple though.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

> What one wants is Plan 9 as a
> model for what may be a family of hardware APIs. It makes sense to
> promote massive parallelism, but the API to it should be sufficiently
> simple for a single individual to manage.
>

This is the what I wonder about. Is this possible at the hardware level and
still support an equally simple, understandable, yet capable, software
system on top? By extension, would Plan 9 would run on such a system or if
it would require some fundamental changes to adapt to it. For example, does
C really need to be thrown out or can it be revised.


> Most computing devices today are single-user, even those like my new
> Android phone that offer shared user capabilities. Incidentally, the
> authorisation model in this case is inadequate for my purpose (share
> with a pre-teen).
>

I am in this boat too, however I have a general aversion to cloud computing
and so I would need some household multi-user systems for data storage and
heavy processing tasks or some distributed equivalent.


> So we have layers and we need the complexity to be shoved into
> well-tested, sealed boxes that can be trusted, while the surface
> remains as simple as 9P.
>

My trouble is that I don't trust the sealed boxes anymore after Meltdown,
Spectre, Rowhammer, etc. Perhaps simple and auditable hardware might help
with this.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

Thanks Richard,

This looks like it fits the bill: open, small, simple. How was it formally 
verified?

This doesn’t seem to need any of the chisel/scala suff, which is great.

How can I help with the compiler port? Which fpga board do you recommend?

Chris

On Sep 6, 2018, at 1:48 PM, Richard Miller <9f...@hamnavoe.com> wrote:

>> It could be, but after having looked briefly at the size of the design for
>> RISC-V Rocket and especially BOOM I wonder if it's all overly complicated.
>> They even built their own high level hardware language (Chisel) that
>> generates Verilog using Scala. Yuck.
> 
> It's possible to build a simple and perfectly usable RISC-V processor
> on an FPGA in verilog.  The one I use is
> https://github.com/cliffordwolf/picorv32 , written by Clifford Wolf.
> Its small size means it can be (and has been) formally verified, and
> (for some applications at least) you can compensate for the modest
> performance by putting lots of them on one chip.
> 
>> Also, there's appears to be quite alot of compiler optimizations in gcc for
>> RISC-based chips.
> 
> Again, it's possible to build a simple and perfectly usable C compiler
> for RISC-V without going overboard with optimisation.  I've been
> working on re-targeting the Plan 9 C toolchain for RISC-V.  It's at
> the stage where it can successfully compile itself, but floating point
> support is not yet complete.  If anyone is interested, let me know.
> 

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

> Wasn't that the whole point of RISC?
>

It could be, but after having looked briefly at the size of the design for
RISC-V Rocket and especially BOOM I wonder if it's all overly complicated.
They even built their own high level hardware language (Chisel) that
generates Verilog using Scala. Yuck.

Also, there's appears to be quite alot of compiler optimizations in gcc for
RISC-based chips.

Could you get away with a much simpler, smaller hardware design and still
run Plan 9 in a reasonable way? Maybe one side of the software/hardware
divide has to take on more complexity to help simplify the other side?

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

> > Could even be that the many-eyes approach encouraged the complexity;
> > in fact, that could easily be the unintended consequence.
>
> I suppose it made complexity seem less bad, for a while, but I was
> thinking economic factors likely drove it to get more complex.  Also, I get
> the impression that some people just love complexity, but these days I'm
> not so sure.  Complexity does have some real benefits.
>

I hadn't considered this. I just assumed that complexity = job security +
sell + lock-in. It's easy to love something that is raking in the cash.

Re: [9fans] Plan 9 potential target ports (Was: PDP11 (Was: Re: what heavy negativity!))

[Chris McGee]

> I do recall, vaguely, an Olimex comment about graphics being more
> accessible, but I did not make a note, the little that stuck was that
> some hardware manufacturer had embraced a slightly better standard
> than VESA, or some such. There may be some hardware out there that
> does not have "closed" graphics.
>

I thought that aijuboard got around this with an fpga implementation of a
frame buffer and hdmi signalling, but I suppose that ramps up the price
significantly as you'd need an fpga board in there and also an hdmi capable
lcd. Otherwise, I wonder how difficult it would be to set up a framebuffer
on the A64 like what was done with Richard's rpi code.

Chris

Re: [9fans] plan 9 : any pager?

[Chris McGee]

I like how the pager (page) actually shows a page on the screen with the
text you pipe to it. There's some real truth in the name.

On Wed, Oct 3, 2018 at 12:34 AM Mayuresh Kathe  wrote:

> thanks nick.
>
> On Tue, Oct 02, 2018 at 08:23:47PM -0700, Nick Owens wrote:
> > the pager is p(1).
> > On Tue, Oct 2, 2018 at 8:22 PM Skip Tavakkolian
> >  wrote:
> > >
> > > Turn off the scroll in the rio window that the shell is running in,
> then cat the file.
> > >
> > >
> > > On Tue, Oct 2, 2018, 8:15 PM Mayuresh Kathe  wrote:
> > >>
> > >> did plan 9 have any pager? or did every text file to be read had to be
> > >> opened in acme or a similar tool?
> > >>
> > >> btw, is there any pager under plan9port? didn't know what to search
> for,
> > >> hence couldn't find any.
> > >>
> > >> thanks,
> > >>
> > >> ~mayuresh
> > >>
> > >>
> >
>
>

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Chris McGee]

Thanks everyone. This is pretty much what I expected was the case. I just 
wanted to confirm my understanding.

Plan 9 C was re-engineered with some
focus on readable code. Readability is expected to make bugs more apparent, 
making it less “dangerous.” Linux is so huge and hard to read that even simple 
things like C have become sharp edges that cut people. While the idea that many 
eyes makes bugs shallower seems to have failed in the world of complex behemoth 
software it may work here.

I’ve read some of the 9front kernel code trying to make it work on raspberry 
pi. I admit that I didn’t find any bugs at that time. The code is relatively 
easy to follow even for me. So, I suppose it’s working nicely.

Chris

> On Sep 3, 2018, at 12:07 AM, Lucio De Re  wrote:
> 
>> On 9/2/18, hiro <23h...@gmail.com> wrote:
>> "prevailing wisdom" sounds like an oxymoron.
>> 
> Yes, real wisdom is for some (evolutionary? counter-evolutionary?)
> reason unlikely to prevail.
> 
> Go figure.
> 
> Lucio.
>