It's not abandoned; it's resting :)
On Sun, Feb 19, 2017 at 10:08 AM Dave MacFarlane <driu...@gmail.com> wrote:
> Sure, but I'm not the one using plan9/client: plumb.Open is. So in
> order to do it and keep supporting p9p, I still need to fork
> 9fans.net/go and vendor my changes to the plumb package, which brings
> me back to where I started: needing to maintain my own fork of a
> seemingly abandoned package.
>
> (I just tried directly opening /mnt/plumb/edit behind a build tag in
> the plumb package and returning the *os.File, and it does mostly work
> except for the same problem of *os.File not implementing
> io.ByteReader, and the fact that now the same function on different
> platforms has different signatures, because the default plumb.Open is
> defined as returning a concrete type from plan9/client, not an
> interface..)
>
> On Sun, Feb 19, 2017 at 9:43 AM, Skip Tavakkolian
> <skip.tavakkol...@gmail.com> wrote:
> > if want to run those utilities in Plan 9 you don't need to worry about
> > speaking 9P with the underlying services -- i.e. no need for
> plan9/client
> > package. the file hierarchies for plumber, acme, draw, etc. are mounted
> into
> > the process' namespace. for example, acme's namespace is mounted on
> > "/mnt/acme"; so a program that is started by acme will use normal
> > open/read/write/close to interact with acme. that's the beauty of Plan
> 9.
> >
> > the middle-layer packages (i.e. acme, plumb, draw) should use
> os.OpenFile,
> > File.Read/Write, etc.
> > for example: acme.New() can be modified like this
> >
> > // New creates a new window.
> > func New() (*Win, error) {
> > fid, err := os.OpenFile("/mnt/acme/new/ctl", os.O_RDWR)
> > if err != nil {
> > return nil, err
> > }
> > buf := make([]byte, 100)
> > n, err := fid.Read(buf)
> > if err != nil {
> > fid.Close()
> > return nil, err
> > }
> > a := strings.Fields(string(buf[0:n]))
> > if len(a) == 0 {
> > fid.Close()
> > return nil, errors.New("short read from acme/new/ctl")
> > }
> > id, err := strconv.Atoi(a[0])
> > if err != nil {
> > fid.Close()
> > return nil, errors.New("invalid window id in acme/new/ctl: " + a[0])
> > }
> > return Open(id, fid)
> > }
> >
> > etc.
> >
> >
> >
> >
> > On Sat, Feb 18, 2017 at 3:51 PM Dave MacFarlane <driu...@gmail.com>
> wrote:
> >>
> >> client doesn't implement ReadByte, and opening a plumbing port with
> >> 9fans.net/go/plumb9fans/net/go/plumb needs a ByteReader is the change
> >> that I've been vendoring for other OSes to be able to open the "edit"
> >> port of the plumber.
> >>
> >> The problem that I'm having now isn't that it doesn't build, it's that
> >> "plumb.Open("edit", plan9.OREAD)" returns an error right away on Plan
> >> 9 because DialService is assuming it's for p9p trying to emulate
> >> namespaces with Unix Domain Sockets. I'm sure it's fixable, but the
> >> repo seems to be abandoned (pull requests have been open since 2015),
> >> so I'm wondering if there's any other packages that deal with the
> >> plumbing ports (because otherwise I think my only option is to fork it
> >> and maintain it myself..)
> >>
> >>
> >> On Sat, Feb 18, 2017 at 10:57 PM, Bakul Shah <ba...@bitblocks.com>
> wrote:
> >> > On Sat, 18 Feb 2017 21:42:05 GMT Dave MacFarlane <driu...@gmail.com>
> >> > wrote:
> >> >> Are there any cross-platform alternatives to 9fans.net/go for
> >> >> interacting with the Plan9/p9p plumber?
> >> >
> >> > I think you will have to create os specific versions of
> >> > 9fans.net/go/plan9/client/dial.go:Namespace()
> >> >
> >> >> It doesn't seem to be maintained (I've had to vendor a bug fix for a
> >> >> while to use it to receive plumbing messages) and I just discovered
> >> >> while trying to use my de text editor on Plan 9 that, ironically,
> >> >> 9fans.net/go doesn't work under Plan 9, either..
> >> >
> >> > I know go/acme/Watch doesn't build. Are there others (modulo
> >> > the above issue)? There may be other ways to handle Watch....
> >>
> >>
> >>
> >> --
> >> - Dave
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to golang-nuts+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> - Dave
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
