Re: [9fans] 9front sam in plan9port.

This is just a port of the 9front version of sam to p9p. As you can see, it hasn't been updated in a while. But I can do that if anybody wants it. Em 21/05/2016 4:50 PM, escreveu: #define chording 0 /* code here for reference but it causes deadlocks */ I suppose the

Re: [9fans] Namespace inheritance between processes

> What is the reason for performing namespace > inheritance by copy as opposed to namespace inheritance by reference? > Is it just to simplify the implementation? i assume by reference you mean shared between parent and child. most of the time you don't want the child process to change the

Re: [9fans] Namespace inheritance between processes

Thanks Skip and Anthony for the scripts! Okay, that makes sense. What is the reason for performing namespace inheritance by copy as opposed to namespace inheritance by reference? Is it just to simplify the implementation? It seems like it might be useful. For example, if you had a daemon that

Re: [9fans] bug in authdial()

On Sat May 21 16:05:58 PDT 2016, 9...@9netics.com wrote: > >> >> Waitmsg *exitsts = nil; > > i see; it's set but not used before it is assigned to again. > > i would expect the compiler to get the hint that it's initialization > -- especially given that the value is 0 and the assignment

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

unfortunately, sam has hardcoded B into the command channel. see /sys/src/cmd/samterm/plan9.c:/^plumbformat - erik

Re: [9fans] bug in authdial()

> Yes, exactly. And doesn't/didn't ndb have a tag that was used to indicate > whether a system or network used il? (proto=il? I don't have access to a > 9labs machine to check at the moment.) > > Determining ip6 connectivity shouldn't be that hard. If you have a route, > you connect. If

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

> I've never seen it happen, and I don't really expect to. I do maintain > that calling acme an editor is akin to calling New York a shopping > center. > > khm That deserves an entry in the fortunes file.

Re: [9fans] bug in authdial()

> On May 21, 2016, at 10:04 AM, erik quanstrom wrote: > > this problem is a little easier to fix. cs needs to do a little more work to > filter out > impossible connection types. for example, if one's internet connection is > not ip6 > capable, then cs should be

Re: [9fans] bug in authdial()

>> >> Waitmsg *exitsts = nil; i see; it's set but not used before it is assigned to again. i would expect the compiler to get the hint that it's initialization -- especially given that the value is 0 and the assignment is right with the declaration.

Re: [9fans] bug in authdial()

> also, > > 209c203 > < char exitsts[2*ERRMAX]; > --- > > Waitmsg *exitsts = nil; > > is likely to generate used-and-not-set on amd64. Wouldn't it be "set and not used" instead? -- David du Colombier

Re: [9fans] bug in authdial()

On Sat May 21 15:19:06 PDT 2016, 9...@9netics.com wrote: > > < char exitsts[2*ERRMAX]; > > --- > >>Waitmsg *exitsts = nil; > > > > is likely to generate used-and-not-set on amd64. > > > > - erik > > i'm not sure i understand how. can you explain? since the only code path that uses

Re: [9fans] bug in authdial()

> < char exitsts[2*ERRMAX]; > --- >> Waitmsg *exitsts = nil; > > is likely to generate used-and-not-set on amd64. > > - erik i'm not sure i understand how. can you explain?

Re: [9fans] bug in authdial()

> i believe this is missing a free. > > - erik good catch; thanks.

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

Thanks for the interesting comments. I've been making an effort to use Sam, in the interest of my own understanding. One of the biggest barriers I've hit is that there doesn't appear to be a good way to save complex edit commands for later. The man page suggests that it's possible to send

Re: [9fans] bug in authdial()

also, 209c203 < char exitsts[2*ERRMAX]; --- > Waitmsg *exitsts = nil; is likely to generate used-and-not-set on amd64. - erik

Re: [9fans] bug in authdial()

On Sat May 21 14:47:24 PDT 2016, 9...@9netics.com wrote: > > a better solution is to just use waitmsg (see wait(2)). the parsing rules > > and sizing are > > already implemented there. > > yes, i agree. i changed my patch. i believe this is missing a free. - erik

Re: [9fans] bug in authdial()

> a better solution is to just use waitmsg (see wait(2)). the parsing rules > and sizing are > already implemented there. yes, i agree. i changed my patch. diff /n/dump/2016/0519/sys/src/libc/9sys/dial.c /sys/src/libc/9sys/dial.c 167c167 < notedeath(Dest *dp, char *exitsts) --- >

Re: [9fans] 9front sam in plan9port.

#define chording 0 /* code here for reference but it causes deadlocks */ I suppose the bug is still messing around. I'll give it a try to the 9front version. Thanks for the info!

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

#define chording 0 /* code here for reference but it causes deadlocks */ I suppose the bug is still messing around. I'll give it a try to the 9front version. Thanks for the info!

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

On Sat, May 21, 2016 at 11:28:09AM -0700, Rob Pike wrote: > If that was meant as a dis, you obviously haven't been to New York lately. > Merely an observation that editing text is a minor subset of acme's functionality. When I dis things, you will not be confused about my intent. khm

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

On Thu, May 19, 2016 at 11:18 PM, Lee Fallat wrote: > You can copy code from Acme and "backport" it. I've done it before and > it was trivial (and it's long gone too). That's most interesting. The following had made me think it would not be easy:

Re: [9fans] 9front sam in plan9port.

On Sat, May 21, 2016 at 8:30 PM, wrote: >> The plan9port version also has chording if in its samterm/main.c you >> change #define chording 0 to #define chording 1. > > It was also marked as being buggy, which is why it remains disabled by > default. I noticed the comment in

Re: [9fans] 9front sam in plan9port.

>> > The plan9port version also has chording if in its samterm/main.c you >> > change #define chording 0 to #define chording 1. >> >> It was also marked as being buggy, which is why it remains disabled by >> default. > > i believe rsc found the reason for this later. the bug was that it caused

Re: [9fans] 9front sam in plan9port.

On Sat May 21 11:32:04 PDT 2016, s...@9front.org wrote: > > The plan9port version also has chording if in its samterm/main.c you > > change #define chording 0 to #define chording 1. > > It was also marked as being buggy, which is why it remains disabled by > default. i believe rsc found the

Re: [9fans] 9front sam in plan9port.

> The plan9port version also has chording if in its samterm/main.c you > change #define chording 0 to #define chording 1. It was also marked as being buggy, which is why it remains disabled by default. sl

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

If that was meant as a dis, you obviously haven't been to New York lately. -rob On Sat, May 21, 2016 at 11:16 AM, Kurt H Maier wrote: > On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote: > > > This is tantamount to saying acme is superior because you are better

Re: [9fans] 9front sam in plan9port.

> Ok, the wording on that site is a bit odd to me. The name plan9port is a > project Russ Cox wrote, so the wording > > A port of 9front's version of sam(1) to unix (plan9port) > > seemed to imply porting 9front's sam(1) to plan9port. That didn't make > sense to me since Russ's plan9port sam

Re: [9fans] 9front sam in plan9port.

On Sat, May 21, 2016 at 6:31 PM, wrote: >> If you mean Russ's project, as referred to on that link, yes. > > Hello James. > > No, it appears to be the 9front version (2014, with mouse chords in > samterm/main.c ), ported to plan9port. The plan9port version also has

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

On Sat, May 21, 2016 at 10:36:44AM -0700, erik quanstrom wrote: > > This is tantamount to saying acme is superior because you are better at > > acme. [...] > > c'mon man. you follow this with several paragraphs of opinion which appear > to say that acme is not better because you don't like it.

Re: [9fans] Marvell Yukon 88E8055 NIC

On Wed May 4 23:51:49 PDT 2016, kokam...@hera.eonet.ne.jp wrote: > I think this is written by eric, however, it may concern to others, > and I'm now a 9front user. > > I use Panasonic CF-R7 C2D notebook(maybe around 2009) which has > Yukon 88E8055 ether chip. The etheryuk.c has no this entry.

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

> This is tantamount to saying acme is superior because you are better at > acme. [...] c'mon man. you follow this with several paragraphs of opinion which appear to say that acme is not better because you don't like it. but then again, editors don't tend to lead to logical arguments. :-) -

Re: [9fans] 9front sam in plan9port.

On Sat, May 21, 2016 at 9:33 AM wrote: > No, it appears to be the 9front version (2014, with mouse chords in > samterm/main.c ), ported to plan9port. > Ok, the wording on that site is a bit odd to me. The name plan9port is a project Russ Cox wrote, so the wording A port

Re: [9fans] bug in authdial()

On Fri May 20 15:27:56 PDT 2016, charles.fors...@gmail.com wrote: > 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

Re: [9fans] bug in authdial()

On Fri May 20 21:48:40 PDT 2016, aris...@ar.aichi-u.ac.jp wrote: > parallel dialing would be fine. > I guess both cinap and erik have examined labs code. > any problem with it? i don't use this code. i think the problem with parallel dial is that like the tricks we used to play in nsec()—it

Re: [9fans] bug in authdial()

> static int > reap(Dest *dp) > { > char exitsts[2*ERRMAX]; > + int n; > - if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) { > + if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >= > 0) { > + exitsts[n] = 0; >

Re: [9fans] 9front sam in plan9port.

> If you mean Russ's project, as referred to on that link, yes. Hello James. No, it appears to be the 9front version (2014, with mouse chords in samterm/main.c ), ported to plan9port.

Re: [9fans] 9front sam in plan9port.

If you mean Russ's project, as referred to on that link, yes. https://swtch.com/plan9port/ I am using it under Mac OS X now, mainly for acme and sam. I've tried it under Linux years ago and it seemed just as solid (I am guessing Russ initially developed it under Linux). Jim On Sat, May 21,

[9fans] 9front sam in plan9port.

Hello everyone, any experience with this? https://bitbucket.org/iru/sam9f-unix trebol.

Re: [9fans] Namespace inheritance between processes

Anthony Martin once said: > Casey Rodarmor once said: > > Also, whatever the answer is, how can I test this for myself? I was > > struggling to come up with a combination of commands, short of writing > > some C programs, which would let me have two

Re: [9fans] Namespace inheritance between processes

Casey Rodarmor once said: > > Let's say I have a process A which forks a child process B with the > > RFNAMEG so it receives a copy of A's namespace. > > > > If process A then makes a change to its namespace, will process B see > > that change? Or does B receive a distinct

Re: [9fans] Namespace inheritance between processes

lets create a couple of shell scripts like this: 1) ns_shared: #! /bin/rc cat /n/tmp/foo ramfs -m /n/tmp # start another ramfs in the child's namespace echo something > /n/tmp/foo cat /n/tmp/foo exit 2) ns_RFNAMEG #! /bin/rc rfork

Re: [9fans] Namespace inheritance between processes

On Sat, May 21, 2016 at 12:26 AM, Casey Rodarmor wrote: > Hi 9 fans, > > I'm trying to figure out how namespace inheritance between process groups > works. > > Let's say I have a process A which forks a child process B with the > RFNAMEG so it receives a copy of A's

[9fans] Namespace inheritance between processes

Hi 9 fans, I'm trying to figure out how namespace inheritance between process groups works. Let's say I have a process A which forks a child process B with the RFNAMEG so it receives a copy of A's namespace. If process A then makes a change to its namespace, will process B see that change? Or

Re: [9fans] bug in authdial()

Hello, > 2016/05/21 11:25、Skip Tavakkolian <9...@9netics.com> のメール： > > 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. I agree with skip. the man wait(2) says: The underlying system call is await, which