[9fans] acme(4) and addr=dot

[9fans] acme(4) and addr=dot

[Micah Stetson]

I think this may apply to all versions of acme, but I'm running into
it on p9p.  First, acme(4) claims that a read on a window's addr file
returns the current address as a pair of character offsets m and n, in
'#m,#n' format or just '#m' if m and n are equal.  It looks like it
really returns m and n as two space-padded integer values.

But that's just a documentation bug.  What's really bothering me is
that I can't seem to get the value of dot.  I've tried this:

% echo -n 'addr=dot' | 9p write acme/70/ctl
% 9p read acme/70/addr
          0           0 %

Window 70's dot is somewhere on line 16.  Thinking maybe the ctl file
had to stay open, I tried this:

% {echo 'addr=dot'; 9p read acme/70/addr >[1=2]} | 9p write acme/70/ctl
          0           0 %

No help.  Am I doing something wrong?

Micah

Re: [9fans] acme(4) and addr=dot

[roger peppe]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

the address is lost as soon as the ctl file is closed
(personally, i think this is not ideal behaviour).

under p9p i use the attached code to retrieve
the current value of acme's dot for a particular
window.

i couldn't figure out a way to do it reliably
in a shell script.

[-- Attachment #2: acmedot.c --]
[-- Type: application/octet-stream, Size: 979 bytes --]

#include <u.h>
#include <libc.h>
#include <fcall.h>
#include <9pclient.h>
#include <auth.h>
#include <thread.h>

void
threadmain(int argc, char **argv)
{
	char *id;
	CFsys *fs;
	CFid *addr, *ctl;
	char buf[100];
	int n;

	id = getenv("winid");
	if(id == nil){
		sysfatal("acmedot: not run inside acme window");
	}
	fs = nsamount("acme", nil);
	if(fs == nil){
		sysfatal("acmedot: %r");
	}

	snprint(buf, sizeof(buf), "acme/%s/addr", id);
	addr = fsopen(fs, buf, OREAD);
	if(addr == nil){
		sysfatal("acmedot: cannot open %s: %r", buf);
	}

	snprint(buf, sizeof(buf), "acme/%s/ctl", id);
	ctl = fsopen(fs, buf, ORDWR);
	if(ctl == nil){
		sysfatal("acmedot: cannot open %s: %r", buf);
	}

	strcpy(buf, "addr=dot");
	if(fswrite(ctl, buf, strlen(buf)) != strlen(buf)){
		sysfatal("acmedot: cannot set addr: %r");
	}

	n = fsread(addr, buf, sizeof(buf));
	if(n < 0){
		sysfatal("acmedot: cannot read addr: %r");
	}
	fsclose(ctl);
	fsclose(addr);
	fsunmount(fs);

	write(1, buf, n);
}

Re: [9fans] acme(4) and addr=dot

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

I think you want to create some kind of redirected handle to the ctl file
first, then start a new block in rc.  I believe this is how network
programming in rc can be accomplished in Inferno as well.  Is this not
allowed in p9p?  I've honestly not used the 9p commands too often.

On Fri, Mar 5, 2010 at 7:37 PM, Micah Stetson <micah@stetsonnet.org> wrote:

> I think this may apply to all versions of acme, but I'm running into
> it on p9p.  First, acme(4) claims that a read on a window's addr file
> returns the current address as a pair of character offsets m and n, in
> '#m,#n' format or just '#m' if m and n are equal.  It looks like it
> really returns m and n as two space-padded integer values.
>
> But that's just a documentation bug.  What's really bothering me is
> that I can't seem to get the value of dot.  I've tried this:
>
> % echo -n 'addr=dot' | 9p write acme/70/ctl
> % 9p read acme/70/addr
>          0           0 %
>
> Window 70's dot is somewhere on line 16.  Thinking maybe the ctl file
> had to stay open, I tried this:
>
> % {echo 'addr=dot'; 9p read acme/70/addr >[1=2]} | 9p write acme/70/ctl
>          0           0 %
>
> No help.  Am I doing something wrong?
>
> Micah
>
>

[-- Attachment #2: Type: text/html, Size: 1615 bytes --]

Re: [9fans] acme(4) and addr=dot

[erik quanstrom]

> I think you want to create some kind of redirected handle to the ctl file
> first, then start a new block in rc.  I believe this is how network
> programming in rc can be accomplished in Inferno as well.

inferno doesn't have rc.

- erik

Re: [9fans] acme(4) and addr=dot

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Sat, Mar 6, 2010 at 7:16 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I think you want to create some kind of redirected handle to the ctl file
> > first, then start a new block in rc.  I believe this is how network
> > programming in rc can be accomplished in Inferno as well.
>
> inferno doesn't have rc.
>

Sorry I meant the shell.  I apologize to everyone that that wasn't obvious
to, and I thank you for correcting me publicly, because everyone loves when
they're corrected publicly.

Dave


>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

Re: [9fans] acme(4) and addr=dot

[erik quanstrom]

> > > I think you want to create some kind of redirected handle to the ctl file
> > > first, then start a new block in rc.  I believe this is how network
> > > programming in rc can be accomplished in Inferno as well.
> >
> > inferno doesn't have rc.
>
> Sorry I meant the shell.  I apologize to everyone that that wasn't obvious
> to, and I thank you for correcting me publicly, because everyone loves when
> they're corrected publicly.

i apoligize if you were offended.  it wasn't my intention.

a technical error salient to the topic at hand was made.
i personally think that it is easy to get confused about inferno's
shell.  therefore, i thought a correction helpful and
appropriate.

the post wasn't personal at all; i'm pretty surprised at the
reaction.  i think that to be a good and helpful community
we can't let technical differences become personal differences.

cheers.

- erik

Re: [9fans] acme(4) and addr=dot

[roger peppe]

On 6 March 2010 15:13, David Leimbach <leimy2k@gmail.com> wrote:
> I think you want to create some kind of redirected handle to the ctl file
> first, then start a new block in rc.  I believe this is how network
> programming in rc can be accomplished in Inferno as well.  Is this not
> allowed in p9p?  I've honestly not used the 9p commands too often.

the nearest you can get to it in p9p is something like:

{
  echo -n 'addr=dot'
  9p read acme/70/addr
} | 9p write acme/70/ctl

but there's no way of guaranteeing that the read
takes place after the write - well, as a hack you can
put a sleep in there, but that's not great...

Re: [9fans] acme(4) and addr=dot

[Eoghan Sherry]

> % {echo 'addr=dot'; 9p read acme/70/addr >[1=2]} | 9p write acme/70/ctl
>          0           0 %
>
> No help.  Am I doing something wrong?

Addr is reset to 0,0 once opened. So, you need to perform these
operations in order: open addr; write ctl; then read addr.

There's a nice way to do this if you can give rc access to the acme
files (try 9pfuse(4) with FUSE).

;9pfuse unix!`{namespace}^/acme mnt
;<mnt/acme/1/addr{
	echo 'addr=dot'>>mnt/1/ctl;
	cat;
}
         93         234 ;

By the way, your question motivated me to give 9pfuse a try. Also,
it lead to my realization that, in rc, you can put the redirections
in front of the command. Hooray!

Eoghan

Re: [9fans] acme(4) and addr=dot

[Micah Stetson]

> Addr is reset to 0,0 once opened. So, you need to perform these
> operations in order: open addr; write ctl; then read addr.

Thanks, all.

Micah

Re: [9fans] acme(4) and addr=dot

[ron minnich]

Since fuse is being mentioned here ....

I needed to do a fuse module recently. The standard Linux fuse library
is quite badly designed. Turns out Russ's fuse library is about as
good as you can get given the limitations of the kernel interface for
fuse. I really like it in fact. It made my library development dead
simple.

So if you're going to do anything with fuse, use the p9p version. It's
great. I did beat on Russ's code a bit to make it work without
requiring p9p libraries (long story ...). It was a trivial set of
changes which anyone can easily do.

ron

Re: [9fans] acme(4) and addr=dot

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Sat, Mar 6, 2010 at 8:48 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > > > I think you want to create some kind of redirected handle to the ctl
> file
> > > > first, then start a new block in rc.  I believe this is how network
> > > > programming in rc can be accomplished in Inferno as well.
> > >
> > > inferno doesn't have rc.
> >
> > Sorry I meant the shell.  I apologize to everyone that that wasn't
> obvious
> > to, and I thank you for correcting me publicly, because everyone loves
> when
> > they're corrected publicly.
>
> i apoligize if you were offended.  it wasn't my intention.
>
>
I was saying that sort of tongue in cheek :-)  Sorry I omitted the smiley.
 No offense taken.


> a technical error salient to the topic at hand was made.
> i personally think that it is easy to get confused about inferno's
> shell.  therefore, i thought a correction helpful and
> appropriate.
>
> the post wasn't personal at all; i'm pretty surprised at the
> reaction.  i think that to be a good and helpful community
> we can't let technical differences become personal differences.
>

Sorry, it wasn't meant to come off as true offense :-)


>
> cheers.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1931 bytes --]