Re: [9fans] Go Plan 9
The following executables are installed into $GOROOT/bin as Plan 9 a.out binaries when you run make -k install inside src/pkg: cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch. They should be directed somewhere else by setting GOBIN, there is no need to include them in your PATH, the host's native executables are already in place after you build Go. There is a temporary fix to the mmap issue with pkg syscall in my patch queue, it just moves the mmap staff over to syscall_unix.go. Pavel On Sun, Apr 10, 2011 at 8:07 AM, Lucio De Re lu...@proxima.alt.za wrote: The new build incantation is: cd $GOROOT/src/pkg make clean mkdir -p $GROOT/bin/plan9 GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install I won't try this until the mmap problem you refer to is resolved, so a question is in order: are the plan 9 tools essential to the operation of 8l with GOOS=plan9 and will they be found by default or will one need to make sure that the PATH is set to find them ahead of the Linux ones? Wait. You are talking about a.out executables, these are specifically for the Plan 9 environment, aren't they? I guess I need to look for myself :-) Alternatively, is it sufficient to specify a different GOBIN or does the PATH need to be changed? I think I know the answer to this question is that the PATH needs changing, but I am normally wrong in these matters. ++L
Re: [9fans] Go Plan 9
The following executables are installed into $GOROOT/bin as Plan 9 a.out binaries when you run make -k install inside src/pkg: cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch. They should be directed somewhere else by setting GOBIN, there is no need to include them in your PATH, the host's native executables are already in place after you build Go. OK, I think I got it. These belong on the Plan 9 platform where it is easy to bind -a .../bin/plan9 /bin to access them. Thanks for clarifying this for me: as I have nentioned more than once, getting my mind around all the permutations of toolchains, tools, platforms, architectures and targets isn't easy. ++L PS: So far I have had no joy building any of them, but that will get fixed :-)
Re: [9fans] I can't boot Plan 9 after install it with 9atom (the system is rebooted)
Ok. I have installed Plan9 in an empty hard disk and the bootloader works fine. have the bootloader got any problems if the Plan9 partition is above 1024 cylinders? Cheers. pmarin On Sat, Apr 9, 2011 at 7:18 AM, pmarin pmarin.m...@gmail.com wrote: I have a problem after installing 9atom in an old HP Optiplex GX110 (i810e/PIII) When I start the machine the screen only show PBS2...Plan 9 from Bell Labs and after a few second the machine is rebooted. Can someone tell me what I have to do now? Some info ( a few Spanglish sorry): fdisk -l Disco /dev/hda: 30.0 GB, 30060527616 bytes 255 heads, 63 sectors/track, 3654 cylinders Units = cilindros of 16065 * 512 = 8225280 bytes Disk identifier: 0x Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/hda1 1 1216 9767488+ 83 Linux /dev/hda2 1217 1338 979965 f W95 Ext'd (LBA) /dev/hda3 * 1339 3654 18603270 39 Plan 9 /dev/hda5 1217 1338 979933+ 82 Linux swap / Solaris lspci 00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory Controller Hub (rev 03) 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC) Chipset Graphics Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02) 00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 02) 01:07.0 USB Controller: NEC Corporation USB (rev 43) 01:07.1 USB Controller: NEC Corporation USB (rev 43) 01:07.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
Re: [9fans] I can't boot Plan 9 after install it with 9atom (the system is rebooted)
On Sun Apr 10 09:12:49 EDT 2011, pmarin.m...@gmail.com wrote: Ok. I have installed Plan9 in an empty hard disk and the bootloader works fine. have the bootloader got any problems if the Plan9 partition is above 1024 cylinders? i'm glad you got things working. clearly the pbs loaded something, but its calculations could have gone wrong, or it's an intel-related ide problem. it's hard to tell without the hardware in hand. - erik
[9fans] hg 1.7.5 update
the problem with commit messsages has been fixed by steve. stallion/mercurial thanks for the bug reports. - erik
[9fans] /dev/draw and c, rc, ruby, python, go
Ruby is my language of choice. It was natural to use it for Plan 9
application development which involves working with dictiories, stacks
and some metaprogramming.
I took fgb/ruby, localized changes, wrote mkfile
https://gist.github.com/912507 And it was ok until I've started
GUI part. It appears that Ruby C extensions are dynamic libraries.
So I can't access libdraw, but why not access /dev/draw directly?
libdraw is a simple wrapper around /dev/draw. It can be implemented
in any language. Unexpected problem appeard rapidly.
I can't reread /dev/draw/ctl
named-image.rb:26:in `read': Invalid argument - /dev/draw/new
(Errno::EINVAL) from named-image.rb:26
To check algorithm named imaged retrieval on several
languages was written . All attempts storred on github
https://gist.github.com/912377
C looks clear and works fine. Python and Ruby falls with exception.
Their message construction checked in rc, which works fine. Also
works when opened from rc and accessed in application through /fd/4
[4] /dev/draw/new { ruby application.rb }
Today I've implemented same on go. It also falls but it may be my
fault
error: read /dev/draw/new: unknown id for draw image
What's special about Plan 9 files? Which languages handle them?
How to fix Python and Ruby?
Any help appreciated
Re: [9fans] /dev/draw and c, rc, ruby, python, go
Hi, it's me, the repeating person (I almost said broken record but I'm not sure how many people know what that means any more :-) Suggest you run your command with ratrace ratrace - whatevercommandyouarerunning It can be very revealing. ron
Re: [9fans] /dev/draw and c, rc, ruby, python, go
Sergey Kish sergey.k...@gmail.com once said: Today I've implemented same on go. It also falls but it may be my fault error: read /dev/draw/new: unknown id for draw image You're giving bad data to devdraw. The Go code on the gist is sending long(id) 'n' long(id) byte(namelen) string(name) but that first long will cause the write to fail. Also, you should really check the errors from any system call instead of discarding them. The error from the read is a red herring in this case (but still expected because the named image allocation failed). Now for the Python and Ruby code, I really have no idea. I would check to see if their standard library requires that you flush after writes. Hope that helps. Anthony
Re: [9fans] /dev/draw and c, rc, ruby, python, go
Another thing to check would be any encoding of the data passed to a write, i.e., try opening the data file in binary mode. Anthony
