Re: [9fans] Why Plan 9 uses $ifs instead of $IFS?

[Tiago Natel]

AFAIK, NPROC is a env variable of mk.

On Oct 17, 2017 13:08, "Giacomo Tesio"  wrote:

> Also, why NPROC has been left uppercase? :-)
>
>
> Giacomo
>
> 2017-10-17 17:45 GMT+02:00 Giacomo Tesio :
>
>> In *rc* you use quotation marks when you want a syntax character to
>>> appear in an argument, or an argument that is the empty string, and at no
>>> other time. IFS is no longer used, *except in the one case where it was
>>> indispensable*: converting command output into argument lists during
>>> command substitution.
>>
>>
>> So, I undestood: it used to use IFS in that one case.
>>
>> I got it now: the fact that IFS was named ifs was not a relevant for the
>> discourse, and thus omitted.
>>
>> Still I'm a bit surprised that such change in the conventions provides no
>> practical advantage: the taste changes with age, but costs accumulate... :-)
>>
>>
>> BTW, thanks for your answers!
>>
>>
>> Giacomo
>>
>>
>> 2017-10-17 17:18 GMT+02:00 Charles Forsyth :
>>
>>> since for example the original Rc paper still referred to $IFS.
>>>
>>>
>>> really? the only references to IFS I can find are in comparisons of $ifs
>>> to the Bourne shell's $IFS
>>>
>>> On 17 October 2017 at 16:05, Giacomo Tesio  wrote:
>>>
 Really? Just aesthetics? :-o
 I supposed it had some practical goal I was missing, since for example
 the original Rc paper still referred to $IFS.

 This would flips the question a bit: I wonder why the same designers
 chose uppercase variable names while designing Unix... :-)


 Giacomo

 2017-10-17 16:39 GMT+02:00 Dan Cross :

> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio 
> wrote:
> > Out of curiosity, do anybody know why Plan9 designers chose lowercase
> > variables over uppercase ones?
> >
> > At first, given the different conventions between rc and sh (eg
> $path is an
> > array, while $PATH is a string), I supposed Plan 9 designers wanted
> to
> > prevent conflict with unix tools relying to the older conventions.
> >
> > However, I'm not sure this was the main reason, as this also open to
> subtle
> > issues: if a unix shell modifies $IFS and then invoke an rc script,
> such
> > script will ignore the change and keep using the previous $ifs.
> >
> >
> > As far as I can see, APE does not attempt any translation between
> the two
> > conventions, so maybe I'm just missing something obvious...
> >
> >
> > Do anyone know what considerations led to such design decision?
>
> Aesthetics.
>
>

>>>
>>
>

[9fans] 9front: Man pages of atomic functions

[Tiago Natel]

Hello folks,

I'm looking for the man page of atomic functions (cas, ainc, adec, etc) of
libc, but where it is?

I found on the cat-v website, but not in 9front:
http://man.cat-v.org/plan_9/2/atom

cpu% man 2 atom
man: no manual page
cpu% man atom
man: no manual page
cpu% man 2 ainc
man: no manual page
cpu% lookman atom
man 1 hg # hg(1)
man 2 iounit # iounit(2)
man 2 lock # lock(2)
man 2 open # open(2)
man 2 read # read(2)
man 2 semacquire # semacquire(2)
man 3 pipe # pipe(3)
man 4 upasfs # upasfs(4)
man 5 open # open(5)
man 5 read # read(5)
man 8 replica # replica(8)

But they exists: /sys/src/libc/amd64/atom.s

Thanks!

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

2016-02-01 20:03 GMT-02:00 :

> > Is there a reason why lib9p doesn't have a clunk function pointer in Srv
> struct?
>
> what about Srv.destroyfid()?
>
>   Destroyfid
>When a Fid's reference count drops to zero (i.e., it
>has been clunked and there are no outstanding requests
>referring to it), destroyfid is called to allow the
>program to dispose of the fid->aux pointer.
>
>
Thanks for your help! I'd tried using destroyfid to achieve what I need but
failed. I tried today again implement with destroyfid but realized that it
will not fully support what I need.

I'm using a file server for exchange data between 9P clients. When a new
file is created, I create a plan9 channel and two threads (one for handle
reads and other for writes), a write(2) to the file is translated into a
sendp and a read(2) is translated into a recvp on the channel. The channel
could be buffered or not, and then I want to maintain data allocated (aux
related data) anyway, because the file server is a queueing system when
channel have a buffer bigger than zero.

Apart from that, I want to know how many clients have each file opened to
update my stats file. It's possible in any way without a clunk callback?

I'm trying to replace a rabbitmq server with this system, but I have a
requirement for some way of monitoring of queues size, performance of
channels, number of clients connected to each channel (file on dchan), etc,
I need this kind of information for make a comparison with the current
queue system...

Thanks!

--
> cinap
>
>

[9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

Someone here can help me?

-- Forwarded message --
From: Tiago Natel <tiago.na...@neoway.com.br>
Date: 2016-02-01 19:17 GMT-02:00
Subject: lib9p: Add clunk callback to Srv struct
To: 9fr...@9front.org


Hello folks,

Is there a reason why lib9p doesn't have a clunk function pointer in Srv
struct?

I have a file server project using Srv and I want to know when no one
client have a specific file opened.

One way that I was able to get this working was forking 9front and adding a
clunk callback to Srv structure. See the commit below:

https://bitbucket.org/tiago4orion/plan9front/commits/5e1141f0a4aa98310cb0e2382c5c78c60fe73b4f

My project usage of the clunk routine is here:
https://bitbucket.org/tiago4orion/dchan/src/60dc3e45eb28c8a8289c177680120ef7f44e0925/fs.c?fileviewer=file-view-default#fs.c-680

This makes sense? Or is there better ways to achieve this?
And if that makes sense, it can go upstream?

Thanks.

Re: [9fans] off topic - a good Git reference

[Tiago Natel]

is there someone else interested in write a git tool for plan 9 ?

[]'s

2015-09-29 13:58 GMT-03:00 Skip Tavakkolian :

> it is informative. i find it easy to read -- good flow and visually
> pleasing typesetting.
>
> http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
>
>

Re: [9fans] Has Linux jumped the shark?

[Tiago Natel]

Make a random commit and call it 4.0? Yes, I think that it jumped the shark
as well as all competitors (BSD. win, osx). But unfortunate we don't have
any other good production-ready choice at the moment.

My hope is that someone is hard working on a new better tech for the next
20 years.  But I know that this is pretty much utopia. Some company will
introduce an old shit idea, call it 'new', make a lot of money and fuck
ours next 20 years of software...

[]'s

i4k
Em 24/07/2015 02:10, Prof Brucee prof.bru...@gmail.com escreveu:

 You are not helping at all. We know that Peter has done *everything*.

 brucee

 On Fri, Jul 24, 2015 at 2:49 PM, cinap_len...@felloff.net wrote:

 http://9front.org/img/pjwshark.png

 --
 cinap