Re: [9fans] bug in authdial()

2016-05-20 Thread arisawa 
parallel dialing would be fine.
I guess both cinap and erik have examined labs code.
any problem with it?

> 2016/05/21 7:25、Charles Forsyth  のメール：
> 
> 
> On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote:
> i'm a little confused by the discussion of il + tcp on authdial
> causing the delay.  if ndb/cs returns multiple dial strings, dialmulti
> function (/sys/src/libc/9sys/dial.c) dials them all in parallel
> (rfork) and the first one that returns, wins.
> 
> 9front uses the original sequential one

Re: [9fans] /acme/edit commands?

2016-05-20 Thread sl 
> Unfortunately sam isn't available on Inferno

I don't remember where I got this, and I don't know who wrote it,
and it definitely seems pretty buggy, but:

http://plan9.stanleylieber.com/inferno/src/sam.tgz

sl

Re: [9fans] bug in authdial()

2016-05-20 Thread arisawa 
I am sorry that I didn’t give enough information but I din’t know there is so 
much difference
on the subject among 9front, 9atom and labs plan9.

> 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール：
> 
> i'm a little confused by the discussion of ...

Re: [9fans] /acme/edit commands?

2016-05-20 Thread Brian Vito 
Skip Tavakkolian <9nut  9netics.com> writes:

> all the recipes in /acme/edit/guide start with 'e' command (ee.l).  'e'
> starts by looking in /mnt/acme/index for the buffer id of "file"; it
> then operates on the corresponding buffer.  so the edit commands are
> meant to operate in /mnt/acme namespace (i.e.  inside acme). 
> 
> you can use 'sam -d' for shell scripts.
> 

Got it, thanks. Unfortunately sam isn't available on Inferno, so I'll have
to make do with using acme. When I get around to it, I'll work on
extracting the logic from acme/sam and write stand-alone versions
of the /acme/edit commands. What would people generally prefer,
separate commands for a, c, d, g, i, p and x, or one command that
collectively implements the sam language?

Re: [9fans] bug in authdial()

2016-05-20 Thread Skip Tavakkolian 
i think this fix is correct; i'm not sure why tokenize didn't have a
problem walking a buffer it expects to be null terminated.

supermic% yesterday -d dial.c
diff /n/dump/2016/0520/sys/src/libc/9sys/dial.c /sys/src/libc/9sys/dial.c
209a210
>   int n;
211c212,213
<   if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
---
>   if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts)) >= 0) {
>   exitsts[n] = 0;
supermic% 

> can you spot the problem in reap() function in /sys/src/libc/9sys/dial.c?
> hint: in notedeath() there is a tokenize(exitsts, ...)
> 
> static int
> reap(Dest *dp)
> {
>   char exitsts[2*ERRMAX];
> 
>   if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
>   notedeath(dp, exitsts);
>   return 0;
>   }
>   return -1;
> }

Re: [9fans] bug in authdial()

2016-05-20 Thread Charles Forsyth 
On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote:

> i'm a little confused by the discussion of il + tcp on authdial
> causing the delay.  if ndb/cs returns multiple dial strings, dialmulti
> function (/sys/src/libc/9sys/dial.c) dials them all in parallel
> (rfork) and the first one that returns, wins.
>

9front uses the original sequential one

Re: [9fans] bug in authdial()

2016-05-20 Thread Skip Tavakkolian 
can you spot the problem in reap() function in /sys/src/libc/9sys/dial.c?
hint: in notedeath() there is a tokenize(exitsts, ...)

static int
reap(Dest *dp)
{
char exitsts[2*ERRMAX];

if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) {
notedeath(dp, exitsts);
return 0;
}
return -1;
}

Re: [9fans] bug in authdial()

2016-05-20 Thread Skip Tavakkolian 
i'm a little confused by the discussion of il + tcp on authdial
causing the delay.  if ndb/cs returns multiple dial strings, dialmulti
function (/sys/src/libc/9sys/dial.c) dials them all in parallel
(rfork) and the first one that returns, wins.

btw, i found a bug in dial.c (i'll send it in another message); fixing
it didn't seem to have any effect but i believe it's a bug anyway.

i instrumented the near side of cpu; the setup (including setting up
notes forwarding) looks to be less than 2 seconds.  the rest can only
be attributed to local exportfs startup and remote rc startup.  here
are three runs:

supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c 
pwd
dial took: 165268068 ns
negotiate auth took: 159047373 ns
factotum autenticate took: 699255914 ns
lclnoteproc time: 702945750 ns
far end setup time: 157257845 ns
/usr/fst
0.00u 0.00s 7.58r./cpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...
supermic%  time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c 
pwd
dial took: 158312233 ns
negotiate auth took: 155598573 ns
factotum autenticate took: 681558002 ns
lclnoteproc time: 684863443 ns
far end setup time: 151972579 ns
/usr/fst
0.00u 0.01s 7.22r./cpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...
supermic%  time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c 
pwd
dial took: 176752321 ns
negotiate auth took: 175402567 ns
factotum autenticate took: 746787405 ns
lclnoteproc time: 749881615 ns
far end setup time: 172600395 ns
/usr/fst
0.00u 0.03s 8.17r./cpu -h grid.nyx.link -k 
dom=outside.plan9.bell-labs.com ...
supermic%

Re: [9fans] problem with acme on 9front

2016-05-20 Thread Steve Simon 

I started with Sam a sit ran on all the different unixes I used an vi an emacs 
just felt clunky.

I never got into help and when acme replaced that I just never made the 
transition.

I love Sam, though it is because I know it so well.

btw, anyone written scripts to allow the plan9 wiki to be edited from Sam? 
maybe the wiki is outmoded these days?

-Steve

Re: [9fans] /acme/edit commands?

2016-05-20 Thread Skip Tavakkolian 
> I had thought the /acme/edit commands (Limbo versions are included with the
> latest Inferno distribution, which also has an Acme with Edit) allow for the
> editing of files at the command line using the Sam command language
> (without having to run Acme itself), while using Edit requires loading the 
> files
> into Acme before operating on them. Am I wrong about either of these beliefs?
> If I am correct, I like the idea of being able to use the /acme/edit commands
> in shell scripts, just as I would use sed or other commands (rather than 
> having
> to use Acme itself, which is more complicated), and I would be interested in
> having the /acme/edit commands available on Plan 9 / plan9port for use there
> as well.

all the recipes in /acme/edit/guide start with 'e' command (ee.l).  'e'
starts by looking in /mnt/acme/index for the buffer id of "file"; it
then operates on the corresponding buffer.  so the edit commands are
meant to operate in /mnt/acme namespace (i.e.  inside acme). 

you can use 'sam -d' for shell scripts.

Re: [9fans] problem with acme on 9front

2016-05-20 Thread Wes Kussmaul 



On 05/20/2016 08:07 AM, Mark van Atten wrote:

This one I like, and it is not difficult to find:

http://www.amazon.com/HP-Optical-Button-Mouse-accessory/dp/B0002Y5LZ8/ref=sr_1_1?ie=UTF8=1463745997=8-1=dy651a+mouse


Sorry folks, it's not my habit to take the last cookie but in this case 
I bought the last one.


--
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.

Re: [9fans] problem with acme on 9front

2016-05-20 Thread Brantley Coile 
I purchased about a hundred of the IBM mice on Ebay, so I’m good for a while. 

HP has a nice three button mouse currently, seemingly from the European part of 
the company. I’m using one now.

http://www.laserjet.co.uk/hp-usb-optical-3-button-mouse-dy651a

Acme, of course, is based on the Oberon System by Niklaus Wirth, modified to be 
imported into the Plan 9 system, so it does have a different feel from Sam. If 
you haven’t studied Oberon, I would recommend you do. It was an amazing 
tour-de-force by Professor Wirth. 

The use of Sam vs Acme was always pretty evenly distributed. Rob uses Acme and 
Ken uses Sam still.

At SouthSuite, one of the few places still based on Plan 9, use Acme uniformly.

  Brantley Coile

> On May 20, 2016, at 7:58 AM, hiro <23h...@gmail.com> wrote:
> 
> I have bought 5 IBM mice with a real middle finger button. If someone
> needs one tell me.
> http://www.ibmfiles.com/ibmfiles/peripherals/scrollpoint_ice_blue.jpg
> location: Berlin
>

Re: [9fans] problem with acme on 9front

2016-05-20 Thread Mark van Atten 
This one I like, and it is not difficult to find:

http://www.amazon.com/HP-Optical-Button-Mouse-accessory/dp/B0002Y5LZ8/ref=sr_1_1?ie=UTF8=1463745997=8-1=dy651a+mouse

Mark.

Re: [9fans] problem with acme on 9front

2016-05-20 Thread hiro 
I have bought 5 IBM mice with a real middle finger button. If someone
needs one tell me.
http://www.ibmfiles.com/ibmfiles/peripherals/scrollpoint_ice_blue.jpg
location: Berlin