cleahcim / go9p Goto Github PK

Shouldn't IOHDRSZ be 23 not 24?!?!

What steps will reproduce the problem?
1. Implement FOpenOp.Open for a file, always return an error
2. Add said file to a server
3. Read said file with "9p read <path-to-file>"

Attaching an example file server (fstest.go)

What is the expected output? What do you see instead?

I expect the read to fail, instead it succeeds.

Please provide any additional information below.

Adding a return instruction in p/srv/file.go:373 after the RespondError call 
fixes the problem.

I'm starting to use go9p for a project, but i will need authenticated (and 
preferrably encrypted) access, so it would be nice to have an authenticated 
example of any of the srv/examples.

I'll try to hack one up, but i'm not sure what I need to do...

I terminated a network connection to my 9p server mid-read (i.e. after the 
request, prior to the response) and the code in Conn.recv() called FidDestroy() 
on the fid that was involved in the read!  Very inconvenient.  I didn't even 
get a clunk.

I'm not sure if the solution here is to wait for the ref-cnt to hit 0, or Clunk 
the fid.  I don't think a Clunk will do much good as it will be handled by a 
separate goroutine than the Read, which would require that I implement the 
synchronization that go9p probably should here.

Thoughts?

Recently, I had been looking for a decent 9P2000 server implementation 
(preferably in Go). Not surprising, I have found go9p project.

Unfortunately, the complete lack of the unit tests, made it impossible to use 
this code in our production.

Filing this issue are a feature request. Feel free to close it, as it's too 
broad in scope and cannot be easily addressed.

Read from a dir at Offset = 0 twice and you will get Ebadoffset instead of 
rewinding the directory read.

diff -r 06555e13d0bc p/srv/fcall.go
--- a/p/srv/fcall.go    Thu Nov 11 13:37:20 2010 -0700
+++ b/p/srv/fcall.go    Mon Nov 15 10:44:55 2010 -0800
@@ -326,9 +326,13 @@
        return
    }

-   if (fid.Type&p.QTDIR) != 0 && tc.Offset > 0 && tc.Offset != fid.Diroffset {
-       req.RespondError(Ebadoffset)
-       return
+   if (fid.Type&p.QTDIR) != 0 {
+       if tc.Offset == 0 {
+           fid.Diroffset = 0
+       } else if tc.Offset != fid.Diroffset {
+           req.RespondError(Ebadoffset)
+           return
+       }
    }

    (req.Conn.Srv.ops).(ReqOps).Read(req)

What steps will reproduce the problem?

# clonefs -addr :564 &        # p/srv/examples/clonefs
# mkdir /mnt/clonefs
# mount -t 9p 127.0.0.1 /mnt/clonefs
# cd /mnt/clonefs
# cat clone
1#
# echo text >>1
# echo text >1
bash: 1: Operation not permitted
# 

What is the expected output? What do you see instead?

Expected "echo text >1" to succeed.

What version of the product are you using? On what operating system?

$ hg tip
changeset:   106:2de9ef38f3b6
tag:         tip
user:        Andrey Mirtchovski <[email protected]>
date:        Mon Apr 02 13:44:29 2012 -0600
summary:     Hardcoded certificates have expired. Allow "insecure" connections 
by skipping the verify step until

$ uname -a
Linux hostname 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC 
2011 i686 i686 i386 GNU/Linux
$ 

Please provide any additional information below.

I recently wrote a trivial fs following the example code in timefs and clonefs 
and 
noticed the above error.  Perhaps it is not by design?

http://9fans.net/archive/?q=%279pserve+question%27&go=Grep
seems to be related (strace and clonefs -d output attached);
applying the below patch fixes the issue.

$ hg diff .
diff -r 2de9ef38f3b6 p/srv/examples/clonefs/clonefs.go
--- a/p/srv/examples/clonefs/clonefs.go Mon Apr 02 13:44:29 2012 -0600
+++ b/p/srv/examples/clonefs/clonefs.go Mon Apr 30 18:45:45 2012 +0530
@@ -73,6 +73,10 @@
    return len(data), nil
 }

+func (cl *ClFile) Wstat(fid *srv.FFid, dir *p.Dir) error {
+   return nil
+}
+
 func (cl *ClFile) Remove(fid *srv.FFid) error {
    log.Println("Remove")
    return nil
$ 

Thanks for go9p and the nice examples!
Arvindh

What steps will reproduce the problem?
1. compile examples under go9p/p/clnt/examples and 
go9p/p/srv/examples
2. start go9p/p/srv/examples/timefs
3. start go9p/p/clnt/examples/cl
4. from "cl" prompt enter "cd"

What is the expected output? nothing, or change to default/root of the 
attached filesystem

What do you see instead?

PC=0x20fb index 0<0>0
throw: string bounds



What version of the product are you using?

6g version 5099 release.2010-03-22 release

On what operating system?

Darwin dhcp-64-100-95-181.cisco.com 10.2.0 Darwin Kernel Version 
10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-
1486.2.11~1/RELEASE_I386 i386


Please provide any additional information below.

diff -r 620e384be698 p/fmt.go
--- a/p/fmt.go  Tue Nov 16 11:13:34 2010 -0700
+++ b/p/fmt.go  Thu Nov 18 15:06:10 2010 -0800
@@ -124,7 +124,7 @@
    case Ropen:
        ret = fmt.Sprintf("Ropen tag %d qid %v iounit %d", fc.Tag, &fc.Qid, fc.Iounit)
    case Rcreate:
-       ret = fmt.Sprintf("Rcreate tag %d qid %v iounit %d", fc.Tag, fc.Qid, 
fc.Iounit)
+       ret = fmt.Sprintf("Rcreate tag %d qid %v iounit %d", fc.Tag, &fc.Qid, 
fc.Iounit)
    case Tcreate:
        ret = fmt.Sprintf("Tcreate tag %d fid %d name '%s' perm ", fc.Tag, fc.Fid, fc.Name)
        ret += permToString(fc.Perm)

To fix, replace "os.Dir" with "os.FileInfo" and add a cast at line 144 ;D

Seriously, it would be nice to have the examples compiled by default, so 
annoying bugs like these get noticed by anyone typing "make"

marko@ributtalo $ ./ls -addr="127.0.0.1:5645" /                                 


2011/06/06 18:19:22 Error

(I use ufs.go as 9p server, and it works fine with 9mount on linux)


"ReadDir(0)" returns the error, and the error has an empty string message.

Hi, nice job.

I think that it wouuld be nice if the clnt api would implement the io.Reader 
interface for File.

In particular I want to be able to use: ioutil.ReadAll(file)


The first thing I noticed is:

noce.go:36: cannot use file (type *clnt.File) as type io.Reader in function 
argument:
    *clnt.File does not implement io.Reader (wrong type for Read method)
        have Read(buf []uint8) (int, *p.Error)
        want Read(p []uint8) (n int, err os.Error)


I tried to fix the signatures:


-func (clnt *Clnt) Read(fid *Fid, offset uint64, count uint32) ([]byte, 
*p.Error) {
+func (clnt *Clnt) Read(fid *Fid, offset uint64, count uint32) ([]byte, 
os.Error) {
....

and it built fine. However at runtime the ioutil.ReadAll(file) didn't return.

I suspect that the is some difference w.r.t the io.Reader interface in way EOF 
is signaled.

if the iounit of the auth fid is not set, Tread messages will get packed with a 
0 read count, resulting in auth always failing on the first read of the auth 
fid.

patch follows.
==============

diff -r 630c71178faf p/clnt/mount.go
--- a/p/clnt/mount.go   Wed May 14 13:19:14 2014 -0600
+++ b/p/clnt/mount.go   Sat Aug 30 06:26:39 2014 +0000
@@ -24,6 +24,7 @@
                return nil, err
        }

+       fid.Iounit = clnt.Msize - p.IOHDRSZ
        fid.User = user
        fid.walked = true
        return fid, nil

Before revision 102:49cad2d4591a (2 days ago) some source files,
p/clnt/stats_http.go and p/srv/stats_http.go, would not be
built on default, as Makefiles contained lines like:

    STATS=
    #STATS=stats_http.go

    GOFILES=\
        ...\
        $(STATS)\

As a result, net/http package, which is used in stats_http.go,
would have been linked into a go9p program only if STATS was
set to the non-default value.

Makefiles vanished as a part of the transition to the Go build
tool; now all go files within p/clnt and p/srv will be built
on default, i.e. also stats_http.go. I suggest to add a line to
the top of each of the stats_http.go files:

 // +build ignore

which would exclude them from being built on default.
This would restore the old behavior and avoid net/http being
linked into each program using go9p. Users that want to use
the statistics could remove these lines temporarily.


Unrelated to the issue above, though related to stats_http.go,
i.e. the use of http.Handle() in statsUnregister() functions:

It seems that unregistering a Handle by specifying
a nil pointer is no longer possible since Go revision
11785:d739d7e8b0e6: "net/http: panic on duplicate
registrations". Now net/http will panic in such a case.
(I don't know if there is a way to unregister a http.Handle at all
...)

Michael

examples not working after implementing io.Reader/io.Writer in rev 467f16f300db

marko@ributtalo ~/Build/go9p/p/clnt/examples $ ./read -addr="127.0.0.1:5645" 
/myfile ()
this is my file2011/06/06 16:02:19 Error EOF

1. Start a server (I tried with examples ufs.go)

2. Start client which reads a (big) file, like

    file, err := c.FOpen(name, p.OREAD)
  if err != nil {
        return nil, os.NewError(err.String())
  }
    defer file.Close()

    buf := make([]byte, 8192)
  for {
        fmt.Printf("reading chunk\n")
    n, err := file.Read(buf)
    if err != nil {
            return nil, os.NewError(err.String())
    }

    if n == 0 {
        break
    }

        dest.Write(buf[0:n])
  }

3. Kill the server in the middle of the write


The reader will be stuck during read and never resume.

Good evening,

I've been playing around with go9p and libixp (http://repo.cat-v.org/libixp/) 
and I think I spotted a bug when they interact.

To reproduce,
1. launch any of srv/examples on localhost:5640
2. run "ixpc -a 'tcp!127.0.0.1!5640' ls"
3. ixpc fails with "unknown user: 22"

cl and ls in clnt/examples are fine. With -d=1 on the server, I can see that 
they send Tattach messages looking like
Tattach tag 0 fid 0 afid 4294967295 uname '' nuname 1001 aname ''
whereas ixpc does
Tattach tag 0 fid 1 afid 4294967295 uname 'louis' nuname 4294967295 aname ''

I understand that the go9p programs put the nil value in uname and rely on 
nuname and that ixpc does the exact opposite.

I figured out 22 means EINVAL, the invalid user seems to be the 0xFFFFFFFF id. 
As far as I know, this report could also be considered an issue with libixp.

I haven't tried connecting a go9p client and a libixp server over tcp.

Louis

# What steps will reproduce the problem?

Trying to create two different clients with mount causes a panic, due to a 
double registration in the http package.

I've attached a test program that exhibits the problem, along with it's output 
to stderr (nothing comes out on stdout). The original code that caused me to 
notice the issue is here:

github.com/zenhack/cow9p

commit 78f0796f8e4f (which is current at the time of writing) causes the 
problem.

# What is the expected output? What do you see instead?

Should successfully mount both filesystems, and exit normally without producing 
any output. Instead, the http package causes a panic due to double registration 
(see stderr.log)

What version of the product are you using? On what operating system?

hg revison 120, gc compiler (go9p was built with go get) on linux amd64.

# Please provide any additional information below.

It seems like the http package shouldn't even need to be pulled in unless 
explicity asked for; I was a bit confused when I got a panic from a package I 
didn't think I was using. Could the http stuff go in a sub-package?

The code which unregisters the http handler:

func (srv *Srv) statsRegister() {
        http.Handle("/go9p/srv/"+srv.Id, srv)
}

func (srv *Srv) statsUnregister() {
        http.Handle("/go9p/srv/"+srv.Id, nil)
}


Breaks with weekly 2012-03-22:



panic: http: nil handler

goroutine 6 [running]:
net/http.(*ServeMux).Handle(0xf840059900, 0xf8400ac090, 0x22, 0x0, 0x0, ...)
    /usr/lib/go/src/pkg/net/http/server.go:937 +0x101
net/http.Handle(0xf8400ac090, 0x100000022, 0x0, 0x0, 0x73667500000003, ...)
    /usr/lib/go/src/pkg/net/http/server.go:962 +0x52
code.google.com/p/go9p/p/srv.(*Conn).statsUnregister(0xf8400c0000, 0x5c0798)
    /home/marko/gocode/src/code.google.com/p/go9p/p/srv/stats_http.go:40 +0x89
code.google.com/p/go9p/p/srv.(*Conn).recv(0xf8400c0000, 0x0)
    /home/marko/gocode/src/code.google.com/p/go9p/p/srv/conn.go:155 +0x4ce
created by code.google.com/p/go9p/p/srv.(*Srv).NewConn
    /home/marko/gocode/src/code.google.com/p/go9p/p/srv/conn.go:42 +0x28f

clnt.File should implement io.Seeker to keep up the 'file' illusion.

This diff enables ufs to correctly report setuid and setgid files.
fixes todo in source: /* TODO: setuid and setgid */

I noticed Rob and Russ have been playing around with a 9p API for Go that seems 
to overlap with go9p. Perhaps a merger is in order?   

if you get a Fid from say, clnt.Auth, it is practically useless. i would like 
to pass the auth fid to factotum, but my factotum library needs a io.ReadWriter 
to speak to the server. you can't simply construct a File from a Fid, which 
would meet the io.ReadWriter interface.

srv/fcall.go

func (srv *Srv) read(req *Req) 

if tc.Count+p.IOHDRSZ > req.Conn.Msize {
                req.RespondError(Etoolarge)
        }

There probably should be a return here.

file, _ = c.FOpen(flag.Arg(0), p.OREAD)
dst, _ := os.OpenFile("/tmp/test", os.O_RDWR | os.O_CREATE, 0666)
_, ioerr := io.Copy(dst, file)
if ioerr != nil {
  fmt.Printf("Error %s\n", ioerr)
}

Outputs:

Error i/o count too large


I'm not sure, but I think the Msize limit should be handled transparently in 
the client.

A recent change to Go compilers, "gc: diagnose unused labels" 
(http://code.google.com/p/go/source/detail?r=570c3ce8), makes compilation of 
srv/srv.go fail:

srv.go:323: label unknown defined and not used

After that label definition is removed, the package compiles again:


--- a/p/srv/srv.go
+++ b/p/srv/srv.go
@@ -320,7 +320,6 @@

    switch req.Tc.Type {
    default:
-   unknown:
        req.RespondError(&p.Error{"unknown message type", syscall.ENOSYS})

    case p.Tversion:

What steps will reproduce the problem?
1. Compile and start a 9p server listening on e. g. socket /tmp/xxx
2. mount -t 9p /tmp/xxx /mnt/ -o trans=unix,version=9p2000.u,uname=<any valid 
user name>

What is the expected output? What do you see instead?

Mount does not succeed: 
mount: wrong fs type, bad option, bad superblock on /tmp/xxx,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Mount does succeed with protocol version 9p2000 (without .u)

What version of the product are you using? On what operating system?

Current repo of go9p, Linux 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux, go version go1.3.1 linux/amd64

Please provide any additional information below.

After fixing the issue 30 (p/osusers.go) [1], the following code in 
p/srv/fcall.go stopped working (line 118, attach function):

        if tc.Unamenum != p.NOUID || conn.Dotu {
                user = srv.Upool.Uid2User(int(tc.Unamenum))
        } else if tc.Uname != "" {
                user = srv.Upool.Uname2User(tc.Uname)
        }

and there also is identical code in the auth function.

When mounting a 9p server, Linux sends Tattach with valid username, but numeric 
user ID is -1. The code above calls Uid2User with such username when dotu mode 
is active, however the lookup will certainly fail. In non-dotu mode the "else 
if" branch is followed, so user lookup is successful.

The proposed patch replaces this code with

        if tc.Unamenum != p.NOUID || (conn.Dotu && tc.Unamenum != p.NOUID) {
                user = srv.Upool.Uid2User(int(tc.Unamenum))
        } else if tc.Uname != "" || (conn.Dotu && tc.Uname != "") {
                user = srv.Upool.Uname2User(tc.Uname)
        }

that is, if numeric UID is -1, lookup by name only will be attempted.

Thanks.

[1] 
https://code.google.com/p/go9p/source/detail?r=30ef0eabe4137d115fcb3d9b9d84bc2e7
6a40c25

Thanks for go9p! I used it to rewrite a 9p server I had written in C, and 
srv.File made it super-easy.

Unless I've missed something though, there's no way to tell the server to stop 
listening and close the socket. I can understand why as many servers will be 
happy to let the OS clean up the tcp socket after it exits.

However when using unix domain sockets, the OS doesn't clean up the socket file 
and the server fails next time it runs ("address already in use").

It looks like the "go way" here is for the server to call Close() on the unix 
socket once it is done. Go's net library will then take care of removing the 
socket file.

My intention is to add a Stop() call to srv.Srv to facilitate this use case. Is 
there anything I should keep in mind when working on the patch to improve it's 
chance of being accepted?

Thanks,
-sqweek

What steps will reproduce the problem?
1. goinstall go9p.googlecode.com/hg/p && goinstall go9p.googlecode.com/hg/p/srv 
&& goinstall go9p.googlecode.com/hg/p/clnt
2. cd $GOROOT/src/pkg/go9p.googlecode.com/hg/p/srv/examples
3. make

What is the expected output? What do you see instead?
expected: compilation succeeds
actual result:
$ make
8g -o ufs.8 ufs.go
8l -o ufs ufs.8
8l: conflicting definitions for "http".URL
ufs.8:  type "http".URL struct { Raw string; Scheme string; RawAuthority 
string; RawUserinfo string; Host string; RawPath string; Path string; 
OpaquePath bool; RawQuery string; Fragment string }
        func (url *"http".URL) IsAbs () bool
        func (base *"http".URL) ParseURL (ref string) (? *"http".URL, ? "os".Error)
        func (base *"http".URL) ResolveReference (ref *"http".URL) *"http".URL
        func (url *"http".URL) String () string
/home/johnny/dev/golang/pkg/linux_386/go9p.googlecode.com/hg/p/srv.a(_go_.8):   
type "http".URL struct { Raw string; Scheme string; RawAuthority string; 
RawUserinfo string; Host string; RawPath string; Path string; OpaquePath bool; 
RawQuery string; Fragment string }
        func (url *"http".URL) String () string
make: *** [ufs] Segmentation fault
make: *** Deleting file `ufs'

What version of the product are you using? On what operating system?
latest hg tip:
$ hg identify
99d3f81dd91e tip


Please provide any additional information below.
I noticed this when my project wouldn't compile: 
http://github.com/soul9/go-ircfs , in this case I know it's the linker that 
segfaults

hello,

go9p is unsupported on Plan 9, as there is no sycall.Errno defined on Plan 9. 
as a short term solution, i changed the definition to a uint, but it makes for 
poor error messages and compatability.

is there any good way to have errors work on plan 9, where errors are strings, 
and unix systems, where errors are generally numbers that are translated to 
strings?

it is used here: https://code.google.com/p/go9p/source/browse/p/p9.go#118

i think it would be very nice if this worked out of the box on plan 9.

i'm using go version devel +d881cb1ffc14 Wed Aug 07 13:36:41 2013 +1000 
plan9/386 on 9front.

from 9p(2):

Because implementing the full walk message is intricate
               and prone to error, the helper routine walkandclone
               will handle the request given pointers to two functions
               walk1 and (optionally) clone . Clone, if non-nil, is
               called to signal the creation of newfid from oldfid.
               Typically a clone routine will copy or increment a ref-
               erence count in oldfid's aux element.  Walk1 should
               walk fid to name, initializing fid->qid to the new
               path's qid.  Both should return nil on success or an
               error message on error.  Walkandclone will call respond
               after handling the request.

dirread9p is very useful for Read calls on directories. an example in go is 
below, as i have used in my fileserver. it could just be called srv.Dirread.

type Dirgen func(uint64, interface{}) *p.Dir

func Dirread9p(req *srv.Req, gen Dirgen, i interface{}) {
    var start uint64
    var count uint32

    p.InitRread(req.Rc, req.Tc.Count)

    if req.Tc.Offset == 0 {
        start = 0
    } else {
        start = req.Fid.Diroffset
    }

    b := req.Rc.Data

    for len(b) > 0 {
        d := gen(start, i)
        if d == nil {
            break
        }
        sz := p.PackDir(d, b, req.Conn.Dotu)
        if sz == 0 {
            break
        }

        b = b[sz:]
        count += uint32(sz)
        start++
    }

    req.Fid.Diroffset = start

    p.SetRreadCount(req.Rc, uint32(count))
    req.Respond()
}

Srv.attach uses Unamenum to determine if user lookup should be done by uid. if 
left uninitialized in non-dotu mode, a user lookup will be done by uid for uid 
0 in Srv.attach, when the lookup should be done by username.

the fix i believe would be to initialize fc.Unamenum to p.NOUID unconditionally.

diff -r fbcdb68b9c01 p/unpack.go
--- a/p/unpack.go       Fri Aug 23 06:37:54 2013 -0600
+++ b/p/unpack.go       Wed May 14 11:57:09 2014 -0700
@@ -106,12 +106,9 @@
                        goto szerror
                }

-               if dotu {
-                       if len(p) > 0 {
-                               fc.Unamenum, p = gint32(p)
-                       } else {
-                               fc.Unamenum = NOUID
-                       }
+               fc.Unamenum = NOUID
+               if dotu && len(p) > 0 {
+                       fc.Unamenum, p = gint32(p)
                }

        case Rerror:

What steps will reproduce the problem?
1. goinstall go9p.googlecode.com/hg/p/ #works fine
   goinstall go9p.googlecode.com/hg/p/clnt


2. error:
goinstall: === cd 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt; gomake -f- 
install
8g -o _go_.8 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/clnt.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/close.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/write.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stat.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/walk.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/open.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/read.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/remove.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/mount.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/pool.go 
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:3: 
statsRegister redeclared in this block
    previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:10
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:6: 
*Clnt·statsRegister redeclared in this block
    previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:29
/home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_none.go:9: 
*Clnt·statsUnregister redeclared in this block
    previous declaration at /home/johnny/dev/golang/src/pkg/go9p.googlecode.com/hg/p/clnt/stats_http.go:33
make: *** [_go_.8] Error 1
--- exit status 2
goinstall: installing go9p.googlecode.com/hg/p/clnt: running gomake: exit 
status 2


3. same thing for p/srv

What is the expected output? What do you see instead?
Expected p/clnt and p/srv to install properly

What version of the product are you using? On what operating system?
latest mercurial revision of both golang and go9p