Re: [9fans] VCS on Plan9

[Giacomo Tesio]

Hi 9fans

Il 18 Aprile 2024 22:41:50 CEST, Dan Cross  ha scritto:
> 
> Git and Jujitsu are, frankly, superior

out of curiosity, to your knowedge, did anyone ever tried to port fossil scm
to Plan9 or 9front (even through ape)?



Also (tangential) did anybody tried to port Tiny-CC?


Giacomo

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M85b3f817edeaf49c1634b730
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

[Giacomo Tesio]

Hi hiro.

History is full of counter examples that contraddict your thesis.

At least since neolithic, human organization has been determinated by 
technology.
The most recent (and most directly related to informatics) were Gutemberg's 
movable-type
printing press, Meucci's telephone, the general purpose CPU and obviously 
the Internet.

But ancient sailing tech, the steam engine, the car, the H bomb, are few among 
thousands of examples of technological innovation that enabled new (and
always more complex) kind of human organizations.

Actually one could argue that technology is the most powerful political force 
in human society.

On January 27, 2022 9:02:29 PM UTC, hiro <23h...@gmail.com> wrote:
> the majority of "hackers" have already failed to be political, when
> they sold their souls to the big corps like google and amazon.

You are confusing hackers with engineers.

Most hackers ARE politically aware.
They pursuit knowledge instead of power, money or prestige, but they are aware 
of
the consequences of their hack.

Yet they might align with power anyway.
Some are blind enough or careless enough or individualistic enough to only care 
about 
their own fun hacks.


Take Pike or Thompson: they were pioneers, invented C, Plan9 and all the stuff 
we love
but now they work in Google (afaik).

Were they hacker?

I can't say if they were or they were just great engineers, but for sure they 
now align 
with Google interests and approve its business model based on surveillance 
capitalism.


On the other hand, RMS, Terry A. Davis or Phineas Fisher, Ola Bini are all very 
politically aware hackers, each in his own way.


Sure, since ever, Power system try to get control of hackers.
Sometime they manage to jail us. Sometime we escape. [1]


Giacomo

[1] http://www.tesio.it/2020/09/03/not_all_hackers_are_americans.html

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-M2da0005ff460750189129b1e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

[Giacomo Tesio]

Hi raingloom, mycroftiv and 9fans,

As you might know I'm pretty heretic in Plan 9 (as much that my for is called 
Jehanne) 
and I'm also very sympathetic with SJW victims, mostly because SJW basically
try to impose worldwide a US-workplace ethos that is compatible with US-styled 
corporate management.

More often than not, they are in good faith.
But ultimately they become tools of US colonialism, spreading their cultural 
hegemony.
The trick is basically: convince everybody that they have your problems 
(eg, systemic racism, lgtqmi+ phobics, gender bias and so on) so that they
will accept your corporate-friendly solutions (eg CoCs...)

In Europe being inclusive doesn't mean to be hypocrital, and that's why I'd 
really like 
to know what "sin" Nemo did to cause all this debate.

More often than not, SJW raise their swords after fictional issues that amount 
to nothing
and could be basically settled with a honest conversation between openminded 
adults.

More often than not, what a SJW consider outragous and evil, is said
in a completely different cultural context and environment, so much that they
simply can't (or don't care to) interpret it as intended and understood in that 
context.

Finally, more often than not, SJW inclusiveness stops before weird people,
(like hackers often are) that do NOT belong to the demographic groups that
populate US's remorse, like blacks, women and so on.

Not to mention that often they are plain blind with the harm their corporations 
cause worldwide (think of the Facebook's SJW that obtained the removal of RMS 
from GCC Steering Committee).

On January 27, 2022 4:35:16 AM UTC, raingloom  wrote:
> 
> Side note: technology is political. Deal with it. Software that helps
> no one is of no use and who you choose to help with software and count
> as a stakeholder (which includes but is not limited to users) is an
> inherently political question. Ignoring that just means that you prefer
> the status quo.

I totally agree with this. [1]

Since neolithic, technology is a prosecution of politics by other means.

I agree so much that all my free software projects include a POLITICS.txt that 
explicitly declares the political goals they have.


However, thanks God, not all politics is based on cancel culture, yet.
Hackers do not cancel, we create.

If you feel the need to cancel Nemo's great influence over Plan 9, I'm not 
interested.

If you want to update his great books, eg to describe 9front, I'd really like 
to help.
But I'd love to work WITH Nemo, not against him.

I might disagree with Nemo's view on general politics (I really do not know his 
takes 
on anything) but I think I might well work with him on a well defined political 
goal
(say "document 9front internals so that anybody can more easily hack it").

Or maybe he doesn't like 9front and prefer to stick to plan9foundation's code, 
in 
which case I would't partecipate because I can't trust several of the founders 
[2].


Sure, as you say, deciding who your project serves and how is a political 
choice.
But it has nothing to do with who you cancel.


Technology is Politics.

But Politics, to me, is to build bridges, not walls.
Cancelling Nemo is not a political achievement.

Building on the great work he donated to this community, is.


My 2 cents.



Giacomo

[1] http://www.tesio.it/2019/06/03/what-is-informatics.html

[2] 
http://www.tesio.it/2018/02/14/what-i-wish-i-knew-before-contributing-to-open-source.html

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-Mfc760e8816936706c934d544
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9f licensing question (u9fs)

[Giacomo Tesio]

Thanks David,

On Sun, 11 Apr 2021 20:55:33 +0200 David du Colombier wrote:

> > browsing the 9p.io's sources of plan9 I have noticed that u9fs have
> > a specific LICENSE file that is not MIT, while the page header says
> > "Distributed under the MIT License".
> > 
> > What's the actual license under which u9fs is distributed by the
> > Plan 9 Foundation?  
> 
> I suppose you are referring to this:
> 
> https://9p.io/sources/plan9/sys/src/cmd/unix/u9fs/LICENSE

Yes I am.
Sorry, I should have liked the page. 

> This is an old license that was used by Lucent to share software
> such as AWK, sam, u9fs, etc. as part of the Netlib collection.
> 
> This license was quite permissive and similar to the MIT license.

It looks so, but the wording is wierd (to my untrained eye):

```
Permission to use, copy, modify, and distribute this software for any
purpose without fee is hereby granted, ...
```

the fact is that "without fee" comes before "is hereby granted", not
after, so that it looks as a condition to the distribution grant.

Indeed the canonical MIT license does not mention fees and the "free of
charges" is clearly referred to the permission:
https://opensource.org/licenses/MIT

> You can ignore this file and consider u9fs is distributed under MIT.

Thanks!

But I think that to avoid future issues, the Plan 9 Foundation should
either remove the file or complement it with an explicit statement
about the new MIT licensing.


Giacomo

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7af5000e9aa9f587-Mf9e3729b6ba12e43297e212b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] p9f licensing question (u9fs)

[Giacomo Tesio]

Hello 9fans,

browsing the 9p.io's sources of plan9 I have noticed that u9fs have a
specific LICENSE file that is not MIT, while the page header says
"Distributed under the MIT License".

What's the actual license under which u9fs is distributed by the
Plan 9 Foundation?


Giacomo

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7af5000e9aa9f587-Meb06d9ef91c0fe95cd859e9f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 64-bit?

[Giacomo Tesio]

Not sure if anybody cares, but Jehanne's kernel derives from a version
of Charles https://bitbucket.org/forsyth/plan9-9k cherry picked from
2015.


Giacomo

Re: [9fans] A heartfelt thanks... :-)

[Giacomo Tesio]

Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener
 ha scritto:
> Please forgive my laziness in not reading the code, but how do you actually 
> implement sleep?  Does the process read a file guaranteed to block forever, 
> or what?

No problem. Actually sleep is very short:
https://github.com/JehanneOS/jehanne/blob/master/sys/src/lib/c/9sys/sleep.c#L23

The blocking system call used in sleep is rendezvous that, in Jehanne,
can never occur at tag ((void*)~0).


Giacomo

Re: [9fans] A heartfelt thanks... :-)

[Giacomo Tesio]

Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin
 ha scritto:
> I'm interested in reading about your awake system call and the changes
> you've made to rendezvous and the variuos locks in libc.

Hi Anthony, sorry for the 2 years delay, but I've finally wrote about awake.
http://jehanne.io/2018/11/15/simplicity-awakes.html

Feel free to ask any question!


Giacomo

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Giacomo Tesio]

Il giorno dom 14 ott 2018 alle ore 19:39 Ole-Hjalmar Kristensen
 ha scritto:
>
> OK, that makes sense. So it would not stop a client from for example first 
> read an index block in a B-tree, wait for the result, and then issue read 
> operations for all the data blocks in parallel.

If the client is the kernel that's true.
If the client is directly speaking 9P that's true again.

But if the client is a userspace program using pread/pwrite that
wouldn't work unless it fork a new process per each read as the
syscalls blocks.
Which is what fcp does, actually:
https://github.com/brho/plan9/blob/master/sys/src/cmd/fcp.c


Giacomo

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Giacomo Tesio]

Il giorno mar 9 ott 2018 alle ore 05:33 Lucio De Re
 ha scritto:
>
> On 10/9/18, Bakul Shah  wrote:
> >
> > One thing I have mused about is recasting plan9 as a
> > microkernel and pushing out a lot of its kernel code into user
> > mode code.  It is already half way there -- it is basically a
> > mux for 9p calls, low level device drivers,
> >
> There are religious reasons not to go there

Indeed, as an heretic, one of the first things I did with Jehanne was
to move the console filesystem out of kernel.
Then I moved several syscalls into userspace. Or turned them to files
or to operation on existing files.
More syscall/kernel services will move to user space as I'll have time
to hack it again.

You know... heretics ruin everything!

I'm not going to turn Jehanne to a microkernel, but I'm looking for
the simplest possible set of kernel abstractions that can support a
distributed operating system able to replace the mainstream Web+OS
mess.
You know... heretics are crazy, too!


Giacomo

Re: [9fans] 9n

[Giacomo Tesio]

2018-05-02 19:24 GMT+02:00 Fran. J Ballesteros <n...@lsub.org>:

> I just learned to love absolute paths.
>

Actually they kind of emerge from my design by themselves.


> IIRC, there was no deadlock caused that you should be aware of.
> I'ts been a long time and quite a few protocols since then, I can look for
> the source; there must be also some docs in the web.
>

Well, actually I'm pretty curious about the implementation.
I'd like to see how you did isolated the changes, since to me they seem
rather huge (but my protocol diverge more from 9P2000 than 9P2000.ix).

Also, I welcome any suggestion for further documents to read about the
topic.


> Also, I'm more in favor of prefix mount tables, that they are very
> different from what 9 does and they would lead to a very different system.
>

Can you elaborate? What differences this approach would produce?
I can foresee some (eg bind semantics) but maybe I'm missing some of them.


> Good luck and have fun.
>

Thanks! :-)


Giacomo


>
> > On 2 May 2018, at 19:14, Giacomo Tesio <giac...@tesio.it> wrote:
> >
> > 2013-06-17 21:06 GMT+02:00 Nemo <nemo.m...@gmail.com>:
> > You should ask if anyone else did that before doing it, instead of saying
> > they are un-spined life forms.
> >
> > Here I am, finally! :-)
> >
> > I'm designing yet another file protocol for my toy/research os (whose
> kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a
> look at your prior art.
> >
> > Some of my design decisions lead to a management of mount tables that is
> pretty similar to what you describe in your paper about the integration of
> 9P2000.ix.
> >
> > Given you already walked this path, I'd like to know what you have
> learnt and if you faced issues I should be aware.
> > For example, the slight difference in bind semantics seems to reduce the
> risk of accidental loops in the namespace, but I would expect it would
> break related userspace assumptions.
> > Also, resolving the dot of each process in the Pgrp each time a mount is
> done, seems pretty complex and prone to deadlocks.
> >
> >
> > Don't you have a tricorder?
> >
> > No... but usually I can get away with my sonic screwdriver... :-)
> >
> >
> > Giacomo
> >
>
>

Re: [9fans] 9n

[Giacomo Tesio]

2013-06-17 21:06 GMT+02:00 Nemo :

> You should ask if anyone else did that before doing it, instead of saying
> they are un-spined life forms.
>

Here I am, finally! :-)

I'm designing yet another file protocol for my toy/research os (whose
kernel is derived from Charles Forsyth's Plan9-9k), and I'd like to give a
look at your prior art.

Some of my design decisions lead to a management of mount tables that is
pretty similar to what you describe in your paper about the integration of
9P2000.ix.

Given you already walked this path, I'd like to know what you have learnt
and if you faced issues I should be aware.
For example, the slight difference in bind semantics seems to reduce the
risk of accidental loops in the namespace, but I would expect it would
break related userspace assumptions.
Also, resolving the dot of each process in the Pgrp each time a mount is
done, seems pretty complex and prone to deadlocks.



> Don't you have a tricorder?
>

No... but usually I can get away with my sonic screwdriver... :-)


Giacomo

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 17:13 GMT+01:00  :
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
>> That's the marketing blurb, I've heard it a thousand times before. [...]
>> So, for the last 10-12 years, maybe more, mountains of software have been 
>> produced on the assumption that it will be easy to find and install all 
>> their dependencies. That's only true for users of big 'distributions' which 
>> have lots of people, a large professional team or many contributors, to 
>> create and maintain the package tree.
>
> From a different point of view, the problem is also that the developers,
> using some developing tools (for example the GNU automake and autoconf),
> don't really know what they are using, or, since "GNU is not Unix",
> don't verify that their code is POSIX compliant (and to what level etc.;
> when I began using Unix by discovering Linux, I remember reading a book
> explaining that for C programming, when linking, you will add always
> the Glib library because "there are probably things you will need in
> it!"...).

I might be proven wrong, but I doubt that developers not understanding
their tools can build useful software.

Or, if the software they build is useful, it may get enough traction
to be rewritten after learning from mistakes.

I cannot fix people linking glib just because it exists. Just like I
cannot fix people writing a new JS framework/library/wtf. In general I
cannot fix people.
But, whenever I have to hack on something that depends on cmake,
instead of autotools, I know it will take twice as much to get the
task done.

>
> The amount of dependencies of some packages is simply appaling. (One
> example is TeXlive, because using some macros involve using an amount
> not necessarily kwown of "other" macros, for a lot of people it is
> simpler to "take it all" just in order not to "fail"; and this is
> when you need only a part of it that you discover that this "all"
> depends on things that you do not have on your system---a C++
> compiler and so on).

My bet is that, when Jehanne will be the one true OS everybody will
hate, people will not install macro packages, but mount a remote file
server through a  caching file server, including the C++ compiler.
Now before going crazy about security, consider that the shell running
TeXlive will only see a limited namespace, containing only the file it
has to work with and nothing else.

But this is not going to happen soon... People do not hate Javascript
enough, yet... :-D


Giacomo

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>:
> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eeke...@fastmail.fm>:
>>> linux-style package managers and bsd-style port trees facilitate and enable 
>>> coupling.
>>
>> What a package manager really facilitate is version management.
>> That is when you want to use/update a software at version X that depends on 
>> libraries at version Y and Z.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been 
> produced on the assumption that it will be easy to find and install all their 
> dependencies. That's only true for users of big 'distributions' which have 
> lots of people, a large professional team or many contributors, to create and 
> maintain the package tree.

True, but part of cost here is the complexity of the package manager.

>
>> The use of dynamic linking make this complex and cumbersome. Also a single 
>> filesystem hierarchy does not help
>
> Dynamic linking is probably the largest, most visible part of the problem, 
> but your saying this makes me think you haven't tried to compile very much 
> software -- certainly not on anything other than Debian or a similarly large 
> distro where, these days, you can get all the dependencies by pasting a line 
> the package author provided.

Well, I use Debian from Potato, but I've got my headaches with
pinning, backports, conflicts and broken upgrades.

Also, I think I've compiled my amount of software.
As a rather recent example, automating the compilation of the gcc
cross-compiler for Jehanne took its time since I had to compile and
install locally specific versions of autotools and binutils, without
forcing users to install texinfo.

I think I have an idea of what I'm doing, but I'm pretty open to
suggestions and criticisms: the best time for them is now, since I did
no real work on the matter.

> The painful ones particularly included dependencies for otherwise nice 
> programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos!
> [...]
> Thinking about this stuff makes me bitter, so I ought to stop now. It's 
> possible the things you want won't intersect with the things which caused me 
> trouble, but I think I have considerable reason for pessimism.

Well, obviously I'm naive enough to try to do something better! :-D

I think the problem is really tied to the nature of software
development... just because bugs are.

To my money you have an alternative:
- to be mostly self contained (as Plan 9/9front does), which is the
optimal solution to the problem
- to leverage outside softwares which evolve outside your control

Both solution have to cope with bugs:
- in Plan 9/9front you fix them
- in other systems you can still fix them but if you contribute back
the fix things turn "complex"...

Versioning, dependency trees (or sometime even graphs) and all these
monsters comes from this problem.

The self-contained approach is way more efficient... and simpler. Thus
it's very attractive to me.

But, my insight is that these monsters need to be faced, and defeated. :-)
Since you can't stop (or control) the evolution of software you do not
code yourself, there's no way to avoid versioning and using that
software.

But again my insight is that using static linking and namespaces,
packages can be way easier to maintain.


Still, I'd really like to know details about your concerns and your
painful experiences, since they could put me on the right track.



> I'd like to think there are enough people who don't want to be tied up in all 
> this pain to create some semblance of a software ecosystem outside it, but 
> when you consider that few people want to start from the ground up, and how 
> poettering and fd.o have their tentacles in crucial parts of the 
> posix-related ecosystem, it looks impossible.

Well, actually there are several hobby OSes that do not support posix
and package management.
(and some have interesting ideas too...)

But the problem with your approach is not just posix compliance.


For example, in Jehanne most tools you are used in Plan 9 are not part
of the core system.

For example, porting Plan 9/9front games to Jehanne is trivial (could
even be automated), but their changes should not cause the core system
to "evolve".

So the solution, again, is installing them as packages, with their own
versions. And this is the reason why there are no games in Jehanne:
they are waiting for a package manager.


The problem, as always, is to get the axes right.


An OS core system should evolve as a whole.
But since its usefulness depend on the amount of things people can do
with it, it should also be able to run exogenous software.

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :

> linux-style package managers and bsd-style port trees facilitate and
> enable coupling.
>
>
What a package manager really facilitate is version management.

That is when you want to use/update a software at version X that depends on
libraries at version Y and Z.
The use of dynamic linking make this complex and cumbersome. Also a single
filesystem hierarchy does not help

Plan 9 does not suffer of this problems because of several reasons:
- it does not support dynamic linking
- it is developed as a whole "batteries included"
- few external packages have being ported to it, and people who use them
know their stuff very well


Plan 9 (and 9atom/9front) is developed and distributed as "a whole system":
there is conceptually only one version for all the software and libraries
included.


Technically it's the simplest and optimal solution to the versioning
problem.

Indeed 9front uses a single mercurial repository (which is a versioning
system) to manage both development and system updates.


I carefully considered this approach for Jehanne too, but decided to try an
alternative design.

Obviously no dynamic linking will ever land in Jehanne, but I want to
enable more external softwares to run on it.
This way I reduce the responsibilities of the project and size it to the
stable workforce (that is: I, me and myself).

It might seem counter intuitive to say that using gcc instead of ken-c
simplify the system.
It's true that it increase the complexity of the system during compilation,
but it reduce the scope of Jehanne itself.


So Jehanne's core system can follow the whole system development approach
of Plan 9, but it's a minimal system and an included package manager will
allow the installation of other useful software.


The problem is that the perfect package manager does not yet exists for the
Jehanne design.
Probably the nearest thing is BSD's pkgsrc, but it doesn't get advantage of
namespaces.

And which language should I use to code an alternative?
Probably C. But I wonder if a more high level language could make the job
easier without increasing too much the project scope.
So far candidates alternatives (that I still need time to evaluate deeply)
are Wirth's Oberon-07 and Obi's Myrddin.


Giacomo

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 0:48 GMT+01:00 Benjamin Huntsman :
> Or, if one wants NIX but to stay a little closer to the original
> distribution, are there options, or is Harvey the only way?

Out of curiosity, what's your use case for the NIX kernel?


@Lyndon: https://bitbucket.org/forsyth/plan9-9k

@Rui: Jehanne diverged a lot from Plan 9, in a pursuit for my vision
of simplicity.
While it's in no way a Unix, many won't even consider it a Plan 9
system. Still for anyone interested: http://jehanne.io


Giacomo

Re: [9fans] There is no fork

[Giacomo Tesio]

To my knowledge this is the set of active projects based on Plan 9:

9atom and 9front are both actively maintained.
Both stick strongly to the original Plan 9 from Bell Labs design.
AFAIK, 9front introduce more innovations, both in kernel and in user
space, but what make it unique is the #cat-v community.

9legacy is not a really fork, but an organized collection of patches,
and is still actively maintained.
Another non-fork active project is Plan 9-ANTS
(http://www.9gridchan.org/ ) which also provides a 9front-based amd64
iso and a free 9P grid online.

Harvey's kernel is based on NIX, and AFAIK, it's the only project
where NIX development is active.

Forsyth's Plan-9k had some development in mid 2017.
It's 2015 version was the starting point of Jehanne's kernel, which is
my own research operating system (that also includes several of
9front's improvements).
Jehanne is the project that diverged most from the original Plan9
design, with its own set of crazy decisions, but currently it's an
unstable toy.


Giacomo

2018-02-10 3:48 GMT+01:00 Benjamin Huntsman :
> Just curious as to the state of the union.  Is 9front pretty much the de
> facto "official" Plan 9 these days, or does anyone still use or maintain any
> of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>

Re: [9fans] Talk by Charles Forsyth on Feb 1st at Imperial College London, 13:00 -14:00

[Giacomo Tesio]

Please share a link here, when ready!


Giacomo

2018-01-29 11:36 GMT+01:00 Hugues Evrard :

> Yes it should be recorded, and made available online later on (I needed
> confirmation before answering here).
> Thanks,
> Hugues
>
>
> On 24/01/18 09:32, Fran. J Ballesteros wrote:
>
> will it be avail online, somehow?
> thanks.
>
> El 24 ene 2018, a las 10:16, Hugues Evrard 
> escribió:
>
> Hi all,
>
> On Thursday Feb. 1st (next week), Charles Forsyth will kindly give an
> introduction talk to plan9 and inferno at Imperial College in London. If
> you are in the London area, don't hesitate to join and to relay this
> announce!
>
> Here is the abstract:
> Plan 9 and Inferno are two operating systems (originally developed by the
> Bell Labs centre that produced Unix decades earlier). Both were designed
> to allow systems to be composed from smaller cooperating systems performing
> specific tasks. They provide structural support for distribution, at the
> operating system level. Their defining novelty is the representation of
> all distributable resources as hierarchical name spaces. There are
> conventional names for certain resources, but no global name space.
> Instead, the kernel provides operations that compose name spaces of local
> and remote resources, at per-process granularity, to build a unique space
> to suit a given application. That can aid design, development, testing
> and integration. I'll give brief summaries of the two operating systems,
> and present examples of their use, with an emphasis on naming.
>
> The talk is at 13:00-14:00 in amphitheatre 311 of the Huxley building,
> whose entrance is at 180 Queen’s Gate, London SW7 2AZ. It is part of the
> iPr0gram talk series ( https://www.doc.ic.ac.uk/~rbc/iPr0gram/ ), where
> people external to Imperial College are warmly welcome, please just get in
> touch with Robert ( https://www.doc.ic.ac.uk/~rbc/ ) beforehand if you
> plan to join.
>
> As most of you already know, Charles has made numerous contributions to
> plan9 and inferno, and was instrumental in open-sourcing inferno. For more
> info, check out his homepage: http://www.terzarima.net/
> Please get in touch with me if you would like to have a chat with Charles
> in the afternoon, I can arrange a meeting room.
> Thanks,
> Hugues
>
>
>

Re: [9fans] Spectre and Meltdown

[Giacomo Tesio]

2018-01-10 17:59 GMT+01:00  :
> wait and see if all these scrambled together mitigations actually work.

Sorry if this is a dumb question, but the descriptions I read of the
mitigations taken in Linux for Meltdown (in particular kernel
page-table isolation) sound really familiar to my poor understanding
of how plan 9 and 9front already manage user memory.

As far as I can remember plan9 flush tables very often and clearly
separate kernel memory pages and user space memory.


So my dumb question is: are plan9/9front and friends actually
vulnerable to Meltdown?


Giacomo

[9fans] truly hidden files!

[Giacomo Tesio]

Hi, while debugging a 9P2000 file server I realized that it's very
easy to hide file or folders in Plan 9: just don't include them in the
Rreads of the parent directory.

Given the protocol, I know I'm stating the obvious, but the effect
still surprises me.

Such files/folder would be accessible to programs knowing their exact
names but not visible to the poor user who ignore them.


I wonder if this can be turned to a security issue.
Eg an invisible pipe named "null" and bound before to /dev could
receive top secret data you wanted to destroy.


Giacomo
PS: knowing a program that use these hidden files, /proc/n/fd would
still reveal their path, but the path could still appear legitimate
like the case of /dev/null.

Re: [9fans] Backgrounding a task

[Giacomo Tesio]

Here it is: 
https://github.com/JehanneOS/jehanne/commit/320e6e6f35bfbc2e37dbd079c8d6a9124bd9ac6c

The simple test attached confirms that it works as expected:
https://github.com/JehanneOS/jehanne/blob/master/qa/kern/nsclone.c

Now it's just matter of modifying the plumber to use this facility and
add a ns/clone command that take a pid and a command to run so that

ns/clone 256 rc

would start a new rc in a copy of the name space of the process with pid 256.


Giacomo


2017-10-24 21:18 GMT+02:00 Giacomo Tesio <giac...@tesio.it>:
> 2017-10-24 16:21 GMT+02:00 Alex Musolino <a...@musolino.id.au>:
>> Creating a child process is something that a process explicitly
>> controls and the RFNOTEG flag of rfork(2) allows a process to control
>> whether or not it shares its namespace with its children.  Allowing
>> other, unrelated processes to fiddle with your namespace is quite
>> different.
>>
>> Think about multiple processes owned by multiple users running on a
>> cpu server.  Which processes should be allowed to join which
>> namespaces?
>>
>> Perhaps allowing only the hostowner to join namespaces for debugging
>> and administration purposes would be acceptable.
>
> I like this idea a lot. I will give it a try in Jehanne.
>
> However I'm going to use a slightly different design: writing "clone"
> to /proc/$pid/ns will cause the current process to replace its own
> name space with a *copy* of that of $pid.
> If the owner of $pid is different from that of the current process or
> if $pid is not running on the same machine as the current process, the
> write will fail with an error.
>
> However any change to the name space after the clone does not impact
> the original process.
>
> As for the plumber, I will add a message that make the plumber clone
> the name space of a target process.
>
> This should address both use-cases without issues for the processes
> running in the original name space.
>
>
> Giacomo

Re: [9fans] Backgrounding a task

[Giacomo Tesio]

2017-10-24 16:21 GMT+02:00 Alex Musolino :
> Creating a child process is something that a process explicitly
> controls and the RFNOTEG flag of rfork(2) allows a process to control
> whether or not it shares its namespace with its children.  Allowing
> other, unrelated processes to fiddle with your namespace is quite
> different.
>
> Think about multiple processes owned by multiple users running on a
> cpu server.  Which processes should be allowed to join which
> namespaces?
>
> Perhaps allowing only the hostowner to join namespaces for debugging
> and administration purposes would be acceptable.

I like this idea a lot. I will give it a try in Jehanne.

However I'm going to use a slightly different design: writing "clone"
to /proc/$pid/ns will cause the current process to replace its own
name space with a *copy* of that of $pid.
If the owner of $pid is different from that of the current process or
if $pid is not running on the same machine as the current process, the
write will fail with an error.

However any change to the name space after the clone does not impact
the original process.

As for the plumber, I will add a message that make the plumber clone
the name space of a target process.

This should address both use-cases without issues for the processes
running in the original name space.


Giacomo

Re: [9fans] rc: $* != '/env/*'

[Giacomo Tesio]

2017-10-19 6:48 GMT+02:00 Skip Tavakkolian :
> i think 'rfork e' in lc will fix this; i'm not sure if it breaks anything
> else.

Actually 'rfork e' in lc fixes this.
I did not even tried because I assumed that /env/* was written at rc
startup, before reading the input script.
I was wrong, actually, but now I wonder when it's written... probably
just before the first exec.

> i can't tell if this was an oversight or done on purpose. lc itself doesn't
> seem all that useful or necessary.

As for lc, I use it pretty often :-)

But actually I asked about the "dirty" /env/* because I thought it
could have had a purpose I was missing.


Giacomo

Re: [9fans] rc: $* != '/env/*'

[Giacomo Tesio]

Pretty clear, thanks! :-)

So, to "fix" this rc would need an option to know to rfork(RFENVG)
before doing anything else.
Something like:

   -f [nNeEsfFm]   Start as a new process group using rfork(flags)

This way lc would produce not surprises by simply adding "-f e" to the
first line.

It shouldn't be an hard fix, but I wonder if it's actually worth the effort.


Also, probably -f is not the best flag here as it usually mean "file"...
-r would be a better choice, but it's taken for debugging output.
I might use -d for debugging output since -d is a no-op (why?) and -r
for this early rfork, but I have no idea of what it would broke.



Giacomo


2017-10-18 19:25 GMT+02:00 Skip Tavakkolian <skip.tavakkol...@gmail.com>:
> yes. lc -- an rc script -- shares the environment with the rc that starts
> it; so env is updated with arglist of lc. $* is the arglist that parent
> (interactive) rc was started with. rc(1) says:
>
> $*   Set to rc's argument list during initialization.
>Whenever a . command or a function is executed, the
>current value is saved and $* receives the new
>argument list.  The saved value is restored on com-
>pletion of the . or function.
>
> if lc was a function, there would be no surprises:
>
> % cat /bin/lc
> #!/bin/rc
> ls -p $* | mc
> % fn LC { ls -p $* | mc }
> % echo $*
>
> % cat '/env/*'
> % LC >/dev/null
> % echo $*
>
> % cat '/env/*'
> %
>
> On Wed, Oct 18, 2017 at 9:02 AM Antons Suspans <an...@ml.lv> wrote:
>>
>> On Wed, Oct 18, 2017 at 05:31:28PM +0200, Giacomo Tesio wrote:
>> > I have been a bit surprised to see that $* does not always contains
>> > the same as '/env/*':
>> >
>> > % echo $*
>> >
>> > % cat '/env/*'
>> > % lc
>> > bin/ lib/ tmp/
>> > % echo $*
>> >
>> > % cat '/env/*'
>> > /bin/lc%
>> >
>> > Not really an issue, but why this happens?
>>
>> I guess...
>>
>> When starting a command from rc, execforkexec() does fork(), which
>> is an equivalent of rfork(RFFDG|RFREND|RFPROC) and does not imply RFENVG.
>>
>> As lc(1) is a shell script, its shell instance sets /env/'*'.
>>
>> Hope this helps.
>>
>> --
>> Antons
>>
>

[9fans] rc: $* != '/env/*'

[Giacomo Tesio]

I have been a bit surprised to see that $* does not always contains
the same as '/env/*':

% echo $*

% cat '/env/*'
% lc
bin/ lib/ tmp/
% echo $*

% cat '/env/*'
/bin/lc%

Not really an issue, but why this happens?


Giacomo

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

[Giacomo Tesio]

2017-10-17 18:00 GMT+02:00 Skip Tavakkolian <skip.tavakkol...@gmail.com>:

> On Tue, Oct 17, 2017, 8:05 AM Giacomo Tesio <giac...@tesio.it> wrote:
>
>> Really? Just aesthetics? :-o
>>
>
>
>> This would flips the question a bit: I wonder why the same designers
>> chose uppercase variable names while designing Unix... :-)
>>
>
> Programs can evolve, why not names? There was no expectation that sh
> scripts would work in rc.
>


They can! For sure! But usually they evolve towards a goal... and I'm a
curious person.. :-)

Also this is not about sh scripts run by rc, but sh script run by an sh
shell started by rc.
Or, rc scripts run by an rc shell invoked by an sh.

Just to explain, for example, you could have an sh script that changes
$USER and then invoke psu that would keep using the previous $user.


Giacomo

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

[Giacomo Tesio]

Also, why NPROC has been left uppercase? :-)


Giacomo

2017-10-17 17:45 GMT+02:00 Giacomo Tesio <giac...@tesio.it>:

> 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 <charles.fors...@gmail.com>:
>
>> 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 <giac...@tesio.it> 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 <cro...@gmail.com>:
>>>
>>>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it>
>>>> 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.
>>>>
>>>>
>>>
>>
>

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

[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 <charles.fors...@gmail.com>:

> 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 <giac...@tesio.it> 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 <cro...@gmail.com>:
>>
>>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it>
>>> 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.
>>>
>>>
>>
>

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

[Giacomo Tesio]

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 <cro...@gmail.com>:

> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it> 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] Why Plan 9 uses $ifs instead of $IFS?

[Giacomo Tesio]

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?


Giacomo

Re: [9fans] The Case for Bind

[Giacomo Tesio]

2017-09-14 16:58 GMT+02:00 Marshall Conover :

> ...but enthusiasm for the concept seems lukewarm, and I'm coming to the
> point where I feel I'm going to need to make a strong argument for...
>

2017-09-15 2:53 GMT+02:00 Marshall Conover :

> It is detrimental to not have this feature, and not having it, in sum,
> will waste millions of man-hours for the people who use this operating
> system, the same way it's wasted lifetimes not being in Mac or Windows.
>

IMHO, there is a wise suggestion hidden in khm jokes.

It's pretty naive to think that contributing to open source projects leaded
by a large company (even just informally, by its employees) you can pursue
these kind of values.

Your contributions might be welcomed for a while, if they align with their
current objectives.
But you are not your contributions, and since you freely agreed to donate
your time for free, they don't owe you anything.

As long as they lead the project, the choice of open source license is just
marketing: there's neither openness nor freedom there.


Think about this for a while: if Google (or Microsoft, or...) would care
about wasted man-hours (or wasted gigawatts) do you think they would have
turned HTML browsers to what they are now?


If you want to contribute to Fuchsia (or any similarly leaded project),
start by writing tests, reviewing code, fixing small bugs, implementing the
interfaces they designed and so on... they will thanks you a lot for your
free and (really) useful work.
And as long as you align with their purposes they will threat you as a peer.

It's not that those developers are evil but there's a large amount of
politics inside these companies they have to cope with.
And ultimately, the companies that pay them are not pursuing values, just
long term profits.


Giacomo

[9fans] double lock in proc.c

[Giacomo Tesio]

In /sys/src/9/port/proc.c a comment state:

/*
* Expects that only one process can call wakeup for any given Rendez.
* We hold both locks to ensure that r->p and p->r remain consistent.
* Richard Miller has a better solution that doesn't require both to
* be held simultaneously, but I'm a paranoid - presotto.
*/

(see
https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887)

I'd like to know a bit more about Miller's solution as I'd like to simplify
postnote.
Any hint or source code?


Giacomo

Re: [9fans] Blocking on write

[Giacomo Tesio]

In Jehanne, I decided to test both: if the queue is not closed there's no
need to check up->errstr.

Thanks for your help!


Giacomo

2017-05-15 18:12 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>:

>
> On 15 May 2017 at 16:46, Giacomo Tesio <giac...@tesio.it> wrote:
>
>> Shouldn't the waserror code check that the queue has been actually closed?
>
>
> Either that or check errstr against Ehungup, since that's the exact error
> it incurred.
> The latter has the advantage of not obscuring a different error if the
> pipe is closed
> between the write and waserror, but with pipes there's not much except
> interrupt, I suppose,
> so it seems a minor race and perhaps the qclosed check is adequate.
>

Re: [9fans] equality sign in Rc

[Giacomo Tesio]

Tonight I've tried this little hack, but I do not have a comprehensive test
suite (does any exists?)

https://github.com/JehanneOS/jehanne/commit/003141901af25f0bb3556be40b7ff963f57ced32

I thought that there's no reason to mimic sh for this since if you need sh
to run a script rc won't work anyway.
So this is just a little syntactic sugar, that for the joy of sl is not
compatible with sh, but imho it can also increases the readability of
scripts. Indeed I agree with sl that expliitness is an advantage of the
current quotation rules.

The idea is to use a single $ to mark the end of variable declarations, so
that what's left can't do assignments, and equality is always quoted.

Here some examples:

% a=1 echo b=$a
rc: #d/0: token '=': syntax error
% a=1 $ echo b=$a
b=1
% $ eval prefix=$home/foo && echo $prefix
/usr/glenda/foo
% $ eval prefix=$home/foo; echo ./configure --prefix=$prefix
rc: #d/0: token '=': syntax error
% $ eval prefix=$home/foo; $ echo ./configure --prefix=$prefix
./configure --prefix=/usr/glenda/foo
% inf=/dev/random out=/dev/null $ echo dd if=$inf of=$out
dd if=/dev/random of=/dev/null


The mini-syntax should extend till the end of a single command: ; & && and
|| should stop it.

Note that it's the first time I use yacc, so probably there is a better way
to code this and there are probably bugs.
For example I was unable to make this works:

% $ echo ./configure --prefix=`{cat /env/prefix}


Giacomo



2017-05-16 17:59 GMT+02:00 Erik Quanstrom :

> by doing it in the grammar, the redirection issue is avoided.
>
> - erik
>
>
> On May 16, 2017 2:24 AM, Charles Forsyth 
> wrote:
>
>
> On 15 May 2017 at 17:44, trebol  wrote:
>
> > = is part of rc syntax, like {} and (), and it interprets it, not the
>
>
> i'd forgotten about the = in >[2=1], so you'd need another exception ...
> rc would interpret that, but then in [a-b=] it presumably wouldn't again...
>
>
>

Re: [9fans] equality sign in Rc

[Giacomo Tesio]

Ok, sorry... :-)

However what about disallowing '-'  as variable's name starting character?

It would be a breaking change, but probably more in theory than in practice.
However options like -Da=1 and --foo=bar could then work unquoted.

To my untrained eye, the gain seems larger than the loss.
Am I missing an obvious use case? Or maybe the changes to rc's code would
be too complex?


Giacomo

Il 15/Mag/2017 18:39, "Charles Forsyth" <charles.fors...@gmail.com> ha
scritto:

>
> On 15 May 2017 at 17:30, Giacomo Tesio <giac...@tesio.it> wrote:
>
>> % echo "$--fu"
>> rc: null list in concatenation
>>
>
> wrong quotes. try echo $'--fu'
>
> h% --x=hello
> h% echo $'--x'
> hello
>
>

Re: [9fans] equality sign in Rc

[Giacomo Tesio]

Actually a --fu variable is not that useful in Plan 9:

% --fu=bar
% echo $--fu
rc: null list in concatenation
% echo "$--fu"
rc: null list in concatenation
% ls /env
'/env/*'
/env/--fu
...

So rc can create a variable starting with more than one '-', but can't use
it.

So I wonder if there is a definition of "the right thing" that can fix this
incongruence and also allow the UNIX usage.


Giacomoec


2017-05-15 17:59 GMT+02:00 Charles Forsyth :

>
> On 15 May 2017 at 16:54, Erik Quanstrom  wrote:
>
>> if we implement the right thing, then arguments like --fu=bar will be
>> 'eaten silently' from the perspective of the (human) operator.  sure gigo,
>> but this seems extra hard o get right in a Unix environment.
>
>
> It would be better then to leave things as they are.
> = is part of rc syntax, like {} and (), and it interprets it, not the
> commands, unless quoted.
>

Re: [9fans] Blocking on write

[Giacomo Tesio]

I've just noticed a strange behaviour in devpipe that occurs on both
9front and Plan 9.

When the write blocks, if a note interrupt the process, the waserror
in pipewrite and pipebwrite will post another note that says "sys:
write on a closed pipe ..."

However the pipe is actually open, and still works, as you can see in
the attached test.

Shouldn't the waserror code check that the queue has been actually closed?


Giacomo

2017-05-15 15:36 GMT+02:00 Giacomo Tesio <giac...@tesio.it>:
> Thanks Charles!
>
>
> Giacomo
>
> 2017-05-15 12:32 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>:
>>
>> On 15 May 2017 at 11:05, Giacomo Tesio <giac...@tesio.it> wrote:
>>>
>>> Is there any fs/device in Plan9 that can easily provide such behaviour?
>>
>>
>> Bind #| to a name and fill up one of the data files (blocks at 256k on my
>> system, might be 32k on small ones).
#include 
#include 

int
writeTillBlock(int fd)
{
	int i = 0;
	char buf[1024];
	memset(buf, 1, sizeof(buf));
	while(i < 300){
		if(write(fd, buf, sizeof(buf)) < 0)
			break;
		print("%d\n",i);
		++i;
	}
	return i;
}

int
continueOnAlarm(void *v, char *s)
{
	if(strncmp(s, "alarm", 5) == 0)
		return 1;
	if(strncmp(s, "sys: write on closed pipe", 25) == 0)
		return 1;
	return 0;
}

void
main(void)
{
	int fds[2], res;
	char buf[1024];

	pipe(fds);

	atnotify(continueOnAlarm, 1);

	alarm(1);
	res = writeTillBlock(fds[0]);

	if(res < 256){
		while(res > 1){
			read(fds[1], buf, sizeof(buf));
			--res;
		}
		if(write(fds[0], buf, sizeof(buf)) < 0){
			print("FAIL: can't write after reads: %r\n");
			exits("FAIL");
		}
		print("PASS\n");
		exits(nil);
	}else{
		print("FAIL: written %d kb\n", res);
		exits("FAIL");
	}
	
}

Re: [9fans] Blocking on write

[Giacomo Tesio]

Thanks Charles!


Giacomo

2017-05-15 12:32 GMT+02:00 Charles Forsyth <charles.fors...@gmail.com>:
>
> On 15 May 2017 at 11:05, Giacomo Tesio <giac...@tesio.it> wrote:
>>
>> Is there any fs/device in Plan9 that can easily provide such behaviour?
>
>
> Bind #| to a name and fill up one of the data files (blocks at 256k on my
> system, might be 32k on small ones).

[9fans] Blocking on write

[Giacomo Tesio]

Hi, to write a test I'm looking for an easy way to have a write()
blocking forever.

Is there any fs/device in Plan9 that can easily provide such behaviour?


Giacomo

Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

[Giacomo Tesio]

Il 06/Mag/2017 10:22, "Francisco J Ballesteros"  ha scritto:

considering as the HW all the machines I use, including their OS as the new
“HW”.


I'm afraid it's what they are trying to achieve with webassebly.

And in a way Inferno was doing the same, wasn't it.

I agree that in a network, several different os should be able to work
together seemlessy.

But despite my efforts in Jehanne I don't think the key to achieve this is
a os, nor a language. IMHO the key is a better general purpose protocol, as
simple as 9p but able to replace http.


Giacomo

Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

[Giacomo Tesio]

You might find https://lsub.org/ls/clive.html interesting.


Giacomo

2017-05-05 15:25 GMT+02:00 Dave MacFarlane :
> On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber  wrote:
>>
>> Plan 9 has not yet been re-implemented in Go.
>>
>> sl
>>
>
> I started trying to do that at one point, but never got my kernel much
> farther than booting just enough to run "Hello, world!" compiled with
> 6c on a FAT filesystem in ring 0 and then crashing the system before
> deciding I don't have the time to finish it or get it somewhere
> useable. If anyone who has the time is interested in picking it up,
> contact me off-list and I'll send you a link to my (horribly written
> and designed) code.
>
> I'm more of a userspace kinda guy anyways..
>
> - Dave

[9fans] NSAVE/NRSTR use case in libap

[Giacomo Tesio]

Reading notify(2) I've noticed that I do not understand POSIX signals
enough to grasp the problem NSAVE/NRSTR are designed to solve.

Initially I supposed they where supposed to allow nested signals, so
that a note occurred during the execution of a signal handler wont
need to wait for NCONT.

Thus I suppose that I'm missing something: I can't imagine a (non
real-time) program requiring to handle a signal while handling a
signal.

So my questions are:

- why Plan 9 needs NSAVE/NRSTR? Which ANSI/POSIX semantics are they
designed to help with?
- can you point me to an application actually using such semantics
(either ported to Plan9 or not).


Giacomo

Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

[Giacomo Tesio]

Yes that would be a plausible explanation but actually rc does not use
getenv: it reads /env/ files directly.

I've tried to remove the loop and I can't see any issue.


Giacomo


2017-01-18 21:13 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>:
> Yes, it's the lists. Nothing will cope with \0 in a C string, so it's a good
> choice as list of string element separator.
>
> On 18 January 2017 at 19:21, Fran. J Ballesteros <n...@lsub.org> wrote:
>>
>> rc lists?
>>
>> > El 18 ene 2017, a las 17:45, Giacomo Tesio <giac...@tesio.it> escribió:
>> >
>> > Hi, last night I noticed this strange post processing in 4th edition's
>> > getenv:
>> > https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41
>> >
>> >seek(f, 0, 0);
>> >r = read(f, ans, s);
>> >if(r >= 0) {
>> >ep = ans + s - 1;
>> >for(p = ans; p < ep; p++)
>> >if(*p == '\0')
>> >*p = ' ';
>> >ans[s] = '\0';
>> >}
>> >
>> > Anybody know why this replacement is done?
>> > It does not seem a good fix to read/write or read/truncate races, but
>> > I can't find a better explanation.
>> >
>> >
>> > Giacomo
>> >
>>
>>
>

[9fans] Why getenv replaces \0 with spaces in the returned value?

[Giacomo Tesio]

Hi, last night I noticed this strange post processing in 4th edition's
getenv: 
https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41

seek(f, 0, 0);
r = read(f, ans, s);
if(r >= 0) {
ep = ans + s - 1;
for(p = ans; p < ep; p++)
if(*p == '\0')
*p = ' ';
ans[s] = '\0';
}

Anybody know why this replacement is done?
It does not seem a good fix to read/write or read/truncate races, but
I can't find a better explanation.


Giacomo

Re: [9fans] memory leaks in libmp

[Giacomo Tesio]

Oh, well, I'm sorry, I should have clarified the context a bit more. Here
it is.

The link I provided here are Jehanne issues, not Plan 9 or 9front bug
reports.
After fixing a few of them I realized that, an year from now, I won't be
able to remember why I did the change. Also, coverity could shut down and I
would have no hint.

So I started coping the coverity scan comments, as a sort of note to a
future self wondering "Why the hell I changed this code?".

The coverity comments in the Jehanne issues are NOT a proof of anything,
they are just quick reminders for Jehanne's developers.

Given that, I thought: why not share these with 9fans and 9front since they
use that code too but cannot access coverity?

Now, for Jehanne these issues were already marked as "worth considering"
(and in this case "worth fixing").
And I'm fine if you consider them false positive or even use a different
fix, since that force me to challenge my assumptions, to review the code
more and even learn from better programmers than me.
Indeed I really like your feedbacks, because you are very deep in the code
base and it usually take you seconds to understand issues that require me
days to figure out.


But these are still **Jehanne's issues**, they are shared in the hope they
helps but with no warranty! ;-)


As you note, I could do it test-driven, providing a failing test and then
fixing the test. You are right, it would be much more useful to Jehanne and
maybe to the Plan 9 ecosystem too.
But, unfortunately, I'm working alone and I do not have the energy to do
this every single time. And I'm one of those few weird people thinking that
you should not care about code coverage if you don't want to pay for a full
one.

Thus I cannot share patches that you can blindly apply, sorry.


As for the issue in question, I think it's a actually a bug. mp(2) states
that
>
> Mptobe and mptole convert an mpint to a byte array.  The
> former creates a big endian representation, the latter a
> little endian one.  If the destination buf is not nil, it
> specifies the buffer of length blen for the result.  If the
> representation is less than blen bytes, the rest of the
> buffer is zero filled.  If buf is nil, then a buffer is
> allocated and a pointer to it is deposited in the location
> pointed to by bufp. Sign is ignored in these conversions,
> i.e., the byte array version is always positive.

To my eye it should only consider bufp if buf is nil. And bufp should be
not nil in that case.

Thus the fix was simply to add an assert to make if fail fast instead of
leaking memory.

The simple reasoning I did during triage was: consider a pointer to a
struct holding both buf and its length:

 mptole(num, s->buf, s->len, nil)

it will cause the leak if the struct was just zeroed.

In this case I prefer the assert fail to the leak, so that I, as a dumb
guy, would notice the issue more rapidly.


Giacomo



2017-01-18 3:31 GMT+01:00 :

> > Still a lot of coverity defects are actually false positives.
> > I try to signal here only the actual bugs but I might be wrong, thus let
> me
> > know if you find these report useless and I will stop to annoy the list.
>
> i cannot predict the future nor tell you how to spend your time. i'm *not*
> claiming that using static code analysis to find bugs is "useless" per se.
>
> but consider the context in which problems would occur, maybe even describe
> how a bug would manifest itself in some code (thats what takes the time or
> wastes our time when you do not do this), and not just blindly present the
> coverty output as a proof.
>
> --
> cinap
>
>

[9fans] memory leaks in libmp

[Giacomo Tesio]

Hi, these other two defects identified from Coverity scan that you might
find interesting:

https://github.com/JehanneOS/jehanne/issues/5
https://github.com/JehanneOS/jehanne/issues/6

NOTE: 9front's guys consider these a false positive, since both

mptole(n, nil, 0, nil);

and

mptobe(n, nil, 0, nil);

are stupid bugs in the caller.

Since, I do stupid errors often, I prefer to fix the leak.

Still a lot of coverity defects are actually false positives.
I try to signal here only the actual bugs but I might be wrong, thus let me
know if you find these report useless and I will stop to annoy the list.


Giacomo

[9fans] out of bound access in libsec

[Giacomo Tesio]

Hi, running coverity scan on libsec it reported two defects that do not
seem false positives:

1. an out of bound access to aesXCBCmac (see
https://github.com/JehanneOS/jehanne/issues/3 )
2. an out of bound access in msgRecv, tlshand.c:1809 (see
https://github.com/JehanneOS/jehanne/issues/4 )

I verified that the code is more or less the same on 9front.
I "fixed" the first with an assert, but I'm not sure wherther passing
sizeof(m->u.finished.verify) to memset in the second is the correct
solution.

Am I missing something?


Giacomo

Re: [9fans] Porting Idris to 9front

[Giacomo Tesio]

2017-01-13 15:05 GMT+01:00 Joe M :

> >
> > Don't you need GHC to compile Idris?
>
> http://docs.idris-lang.org/en/latest/faq/faq.html#when-will-
> idris-be-self-hosting
>
> I have the posix version of the rts working on 9front. The default C
> backend generated code compiled and runs on 9front. I generated the c
> code on linux though.
>

Can you detail the process?

I'd like to give it a try on Jehanne (which is built with gcc).


Giacomo

Re: [9fans] A heartfelt thanks... :-)

[Giacomo Tesio]

2017-01-06 10:34 GMT+01:00 Anthony Martin :

> Ciao Giacomo,
>

Ciao Anthony, ottime domande! :-)

Let's start from the easy ones:


> Oh, and where are the man pages? /doc/hacking is missing.


Man pages in Jehanne will be readable in source form. Cat should be enough
to render them.
This means that I have to port them from troff to something like markdown
or commonmark (or something even  better if possible). Whatever will be the
format, it must be readable in source form.

/doc/hacking/ is just waiting to be filled. I know it's important, but so
far I gave priority to hacking itself, instead of documentation. The state
of the web site is a sad effect of this choice. I will try to scratch
something in the next week.


> I'm interested in reading about your awake system call and the changes
> you've made to rendezvous and the variuos locks in libc.
>

Well awake is the complement of sleep: instead of blocking for a number of
ms, it wakes up a process blocked on a syscall after a number of ms.
Actually right now the only syscall that can be awaken is rendezvous, but I
will add support for it to all others blocking syscalls.

As for it's impact on libc I will write something asap.

Why did you choose to create devself? Everything it does seems
> better suited to devproc. If I was going that route, I'd instead
> create a QTDIR file in devproc called #p/self that is just another
> view into #p/$pid. Then brk and chdir would be control messages
> written to #p/self/ctl. Same with seg^(attach detach free). You
> could also make those be control messages written to #p/self/segment
> instead.
>

I evaluated that option and actually devself and devproc are related, but
different:

- in Jehanne you cannot access #p after an rfork(RFNOMNT), but you can
still access #0/segment
- in Jehanne you cannot access #c after an rfork(RFNOMNT), but you can
access #0/null or #0/pid
- wdir is present in both #p and #0 so that chdir first try to open
/proc/$pid/wdir and only on failure try with #0/wdir. This allows a process
to intercept changes to the working directory of another (that want to
cooperate). Guess what's the first use case for this (still to be
implemented, actually)?

Note that both devices are still work in progress! For example this state
of things poses some security concern, but it's part of an overall design
that will include a new flag to rfork to limit the process visible in #p to
children and other security related changes to its working.


>
> Also, I think it's a mistake to overload the return value of the
> remove system call for passing arbitrary integers out of the kernel.
> I understand why you want something like that, however. Moving
> system calls into reads and writes of various files increases the
> number of context switches since you have to open and close the
> files. Why not do exactly what you want and make a new system
> called readint or something?
>


No, well... actually it's not a just matter of performance.

Remove is not the only "overloaded" system call in Jehanne, it's just the
easy to catch! :-D

Again this is a rather large topic strictly linked to the file protocol
that I'm designing.

Devices and file servers will allowed to assign custom semantics to values
that are not used by the operating system. For remove and close this just
means all the possible return values except ~0 that is used for errors. For
open, pread and pwrite it means all negative values of long arguments and
return values (again except ~0).


Giacomo

[9fans] A heartfelt thanks... :-)

[Giacomo Tesio]

Hi, I've just published a summary of my last year of experiments with
Jehanne  with a thanks to these communities and to their members:

  http://jehanne.io/2017/01/06/a-year-with-jehanne.html

It's worthless to say that I couldn't have done anything without your code
and your help.


Thanks.


Giacomo

Re: [9fans] create/create race

[Giacomo Tesio]

Thanks Charles! This is exactly the kind of info I was looking for.


Giacomo

2016-11-30 22:53 GMT+01:00 Charles Forsyth :

>
> On 30 November 2016 at 21:51, Charles Forsyth 
> wrote:
>
>> that the whole path name is re-evaluated 3 times
>
>
> That doesn't happen with the current implementation, because it walks to
> the parent directory, does the create/open etc at that point with a
> reference held.
>

Re: [9fans] create/create race

[Giacomo Tesio]

2016-11-30 16:08 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>:

>
> On 30 November 2016 at 15:02, Giacomo Tesio <giac...@tesio.it> wrote:
>
>>
>> But reading that thread I can't actually see why the OEXCL path has been
>> taken instead of eliminating the race mapping the syscall to the 9p message.
>> I mean except backward compatibility.
>>
>
> I suppose you'll find out, but I'd expect that all but a handful of
> instances want the existing effect and are untroubled by any potential race.
> Given that OEXCL then seems to handle the handful, it seems a reasonable
> approach.
> The ocreate would just put the race in a different place, wouldn't it?
>

Well not exactly: I will use the new create syscall (without OEXCL support)
when I need such level of control and use ocreate with OEXCL when I do not
care about the race and want a "create or truncate" default behaviour.

But actually, I cannot see a use case where the create(2) default behaviour
can be *wanted*.
I just see many use case where it can be tollerated: the create can fail
anyway for other reasons so it does not add much complexity to the client...
But I'm probably missing something obvious: can you provide an example
where not having the truncate fallback in the syscall actually break the
program or introduce a bug. It's exactly what I'm looking for.


Giacomo

Re: [9fans] create/create race

[Giacomo Tesio]

David it seem you walked my road already... :-)

I'm actually on a research project, so I do not care too much about the
issues on existing programs. I'm going to change/break them anyway.
Also, as far as I can foresee, it should be viable to fix such programs in
a partially automated way (eg via sed and a new "ocreate" library function
that mimic the current behaviour).

But reading that thread I can't actually see why the OEXCL path has been
taken instead of eliminating the race mapping the syscall to the 9p message.
I mean except backward compatibility.

Maybe it was found a performance issue in some more common use case?
Or a worse race prevented by the current semantic?


For example I've found pretty cryptic this message from David:
http://marc.info/?l=9fans=111558704718797=2

I'm surprised I haven't yet seen "What about union directories?"
>
> If create(2) is changed then it could succeed even though a
> file with that name exists in the union.  Then the above:
>
> if ((fd = create(file, mode, perm)) < 0) {
>   error...
> }
>
> Would need to become:
>
> if ((fd = open(file, mode|OTRUNC)) < 0 ||
> (fd = create(file, mode, perm)) < 0 ||
> (fd = open(file, mode|OTRUNC)) < 0 ||
>   error...
> }
>
> This is precisely the current create(2) call and the nasty
> race is clear.
>
>
Why the initial open() would be needed if create(2) always send a Tcreate?


Giacomo


2016-11-30 14:53 GMT+01:00 Charles Forsyth :

>
> On 30 November 2016 at 13:32,  wrote:
>
>> interesting, the thread starts here:
>>
>> http://marc.info/?l=9fans=111558704718788=2
>>
>
>
> I suspect the discussion predated 9P2000 and the introduction of the OEXCL
> option.
>

Re: [9fans] create/create race

[Giacomo Tesio]

Hi guys, I know this is a noob question, but I'd really like to understand
this aspect of the kernel design.

I'm planning to experiment on the topic, modifying chan.c so that the
semantics of create(2) match those of create(5) about existing files. I
guess that the number of callers to fix is manageable.

But since I can't see any good reason for the race being there in the first
place (except maybe backward compatibility with unix, but that was not a
problem for Plan 9 designers), I'm pretty sure I'm missing something
obvious.


So, please, do you know why the create syscall does not simply return an
error if the file already exists?
You might save me a few headache...


Thanks for your help!


Giacomo



2016-05-24 23:25 GMT+02:00 Giacomo Tesio <giac...@tesio.it>:

> I'm pretty curious about the create(2)/create(5) race described in a
> comment in namec (see https://github.com/brho/plan9/
> blob/master/sys/src/9/port/chan.c#L1564-L1603)
>
> Does anyone know or remember the reasoning behind this design?
>
> What was wrong about using the create(5) semantics for the create(2)
> syscall?
>
>
> Giacomo
>

Re: [9fans] devsegment usage examples

[Giacomo Tesio]

Neat, thanks!
I wonder if a similar approach could be used to move some device drivers
out of kernel...

Btw, I did read the sample in segment(3) but I was looking for a real world
example.
What I'm trying to understand is not *how* to use devsegment, but *when* to
use it.
Which problems is it designed to solve?

Moreover, Zinq's graphics use a very smart approach, but it's specific to
9front evolution of the device with the "fixed" type.
I'm also looking for the general use case, when segments are not used for
DMA, as designed in the original Plan9.


Giacomo

2016-08-31 12:40 GMT+02:00 :

> > Hi, I'm looking for an usage example of devsegment.
> >
> > I cannot find anything neither in bhro's plan9 nor in 9front.
> >
> > Can anybody share a real usage world example?
> >
> >
> > Giacomo
>
> its just creating named segments of some shared memory.
>
> segment(3) has an example. read it.
>
> on 9front, you can also allocate physically continuous segments *and*
> get the physical base address for it :)
>
> one application for it is on the zynq. the displayport graphics is
> implemented using the fpga and userspace uses devsegment
> to allocate 5MB of physically continous memory for the framebuffer:
>
> #!/bin/rc
> rfork en
> bind -c '#g' /mnt/segment
> if(! test -d /mnt/segment/fb){
> mkdir /mnt/segment/fb
> echo 'va 0x0050 0x0050 fixed' > /mnt/segment/fb/ctl
> }
>
> bind -b '#P' /dev
> audio/pcmconv -i 'c1u32r1' -o 'c1U32r1' < ./build/out.bin > /dev/pl
>
> then some c code programs the graphics register and hands the
> loaded core the physical address for DMA.
>
> --
> cinap
>
>

[9fans] devsegment usage examples

[Giacomo Tesio]

Hi, I'm looking for an usage example of devsegment.

I cannot find anything neither in bhro's plan9 nor in 9front.

Can anybody share a real usage world example?


Giacomo

Re: [9fans] The Plan 9/"right" way to do Facebook

[Giacomo Tesio]

2016-04-03 6:42 GMT+02:00 :

> > We are already trained to be suspicious about the truth even when it's
> > clearly evident, now we can even start to ignore the information from the
> > physical world, while accepting the virtual information that someone else
> > feed us.
>
> For an Italian inheriting the legacy of Galileo Galilei, you sure
> approach Science from an odd angle.  "suspicious about the truth" is
> good, scientific behaviour.  "clearly evident" is not.
>

Theoretically, this is a very good point! :-D

But what is good for scientific research will work very badly for social
behavior and politics.

As an Italian, I also inherit the legacy of Macchiavelli and believe me:
uncertainty, indifference and divisions (and fear) are among the most
powerful tool to gain and preserve power.

I'm not afraid of people challenging mainstream opinions (this is Plan9,
isn't it? :-D), I'm afraid of people doubting about evident facts or simply
ignoring them: climatic changes? unsustainable distribution of wealth?
parents negating their kids misbehavior? inadequate legal systems for the
current world? and so on...


Giacomo
entirely off topic, sorry

Re: [9fans] The Plan 9/"right" way to do Facebook

[Giacomo Tesio]

While funny in it's visionary shape, I'm seriously scared about this matter.

Take for example Google's material design: any software that successfully
mimic the physical world (paper layers in particular) is going to bland our
perception of its "virtuality". Our mind is going to accept it as a
physical tool. Now, we "know that a programmable computer is no more and no
less than an extremely handy device for realizing any conceivable mechanism
without changing a single wire", but are we sure we really want to remove
the awareness of the wires?

Google glasses scare me even more: we are going to look the world through
some one else eyes. In the long run, our brain will start to accept the
virtual baloons like the other physical entities that really exists.

We are already trained to be suspicious about the truth even when it's
clearly evident, now we can even start to ignore the information from the
physical world, while accepting the virtual information that someone else
feed us.



Giacomo



2016-04-01 22:00 GMT+02:00 :

> lu...@proxima.alt.za writes:
>
> > I don't even remember the name of the feature, but I used a tool way
> > back in the very early days of a public Internet (it was called a MOO,
>
> > Given a browser-style interface with 3D capabilities, it would address
> > social networking considerably better than Facebook (with which I have
>
> > For that is what social media provide: a world-wide stage on which you
> > perform selections from your real life and any fantasy life you choose
>
> Very interesting.  I was envisioning a system which would (at least on
> its GUI side) present information in the form of a Web page, like
> Facebook, LinkedIn, etc.  I hadn't thought of abandoning the Web page,
> altogether, for some other kind of "social space" browser.  I wonder
> what that might be like.
>
> [Disclaimer: This is NOT a formal or serious proposal for a new Plan 9
> file system.  (Not yet, at least.)  It's just an exploration of some
> potentially possible possibilities.]
>
> For a social network to be useful, it must provide some intuitive
> mapping between information in the virtual world and its real-life
> referents.  (In contemporary social networks, these take the form of
> person/place names, mugshots, and interactive maps with balloon icons.)
> The space which humans are most familiar with navigating, of course, is
> meatspace - the physical, brick-and-mortar world.  It makes sense, then,
> that the most intuitive interface would offer some kind of three-
> dimensional virtual reality.  The simplest, most intuitive mapping
> between virtual space and meatspace would probably be to visually
> "overlay" information from the virtual space onto meatspace.  Technology
> (mostly in the form of various head-mounted glasses or goggles) already
> exists which allows a person to see what's around them, while projecting
> information ontop of what they see.  A device such as this has generally
> been called an "eye tap".  But it has a problem: when you turn your
> head, the display turns with it.  In order for the UI to be as intuitive
> as the physical world, it would have to maintain orientation with its
> physical environment.  Tracking motion of the user's head could be done
> using accellerometers, a la Oculus Rift.  Imagine a Rift with two video
> cameras on its front (to provide a binocular view on the physical world)
> that overlays a digital world ontop of the real world you see.  Virtual
> arrows could guide you where you need to go without needing directions.
> When you get near your favorite Chinese restaurant, a balloon could
> appear in your view, giving you access to information about it.  When
> GPS magic detects that a friend of yours is nearby, an friendly-looking
> arrow appears, indicating the general direction and approximate distance
> to him or her.
>
> In order for a virtual world to be useful, however, simply mimicking the
> physical world won't do; its physics must differ from the physics of the
> real world in some useful way.  If your favorite restaurant is two miles
> from your present location, for example, you won't want to walk two
> miles to find its virtual balloon.  :) Navigating the virtual space
> would require some way to stretch/pan space and time, allowing the user
> to "fly" about and move forward/backward in time within the virtual
> world, before restoring the overlay to match normal space/time.  You
> would, for example, be able to hike the trail I hiked yesterday, even
> after I got back from hiking it.  If I recorded GPS waypoints and/or
> stereoscopic video along the way, you could hike right along with me,
> having a conversation with my avatar about your favorite edible plants.
> Then, I could "rewind" time and watch your hike & conversation as well
> (assuming that you decided to share it with me).
>
> An ability to stretch/shrink distances in virtual space enables use of
> non-Euclidean volumes, as well.  

Re: [9fans] Libc locks documentation

[Giacomo Tesio]

Thanks Charles!

Giacomo

2016-03-25 17:38 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>:

> If you look for "condition variables" for event notification,
> you'll find relevant material, such as this paper
> https://www.cs.berkeley.edu/~brewer/cs262/Mesa.pdf
> which has a few references in it too. There's a little evolutionary
> history of them somewhere.
>
> On 24 March 2016 at 19:56, Giacomo Tesio <giac...@tesio.it> wrote:
>
>> Hi, I'm a bit ignorant but I cannot recognise the algorithms in qlock.c.
>>
>> Where I can find more documentation about them? Any paper I can read?
>>
>> For example the rsleep/rwakeup always look a bit magic in its coupling
>> with qlocks. I'd really like to know more about these algorithms, but given
>> their use of rendezvous I can't find anything related.
>>
>> Can you provide me some references?
>>
>> Giacomo
>>
>
>

[9fans] Libc locks documentation

[Giacomo Tesio]

Hi, I'm a bit ignorant but I cannot recognise the algorithms in qlock.c.

Where I can find more documentation about them? Any paper I can read?

For example the rsleep/rwakeup always look a bit magic in its coupling with
qlocks. I'd really like to know more about these algorithms, but given
their use of rendezvous I can't find anything related.

Can you provide me some references?

Giacomo

[9fans] startboot signature

[Giacomo Tesio]

Out of curiosity, why the startboot function in port/initcode.c is `void
startboot(char *argv0, char **argv)` given the argv0 is ignored?

I see that this simplify various main() in init9.s but I wonder why not
simply use `void startboot(char **argv)`


Giacomo

[9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler
programming, so sorry if my question is too dumb...

I cannot understand the FP pseudo register usage.
The cpuid function, for example, is implemented as

/*
 * The CPUID instruction is always supported on the amd64.
 */
TEXT cpuid(SB), $-4
MOVLRARG, AX/* function in AX */
CPUID

MOVQinfo+8(FP), BP
MOVLAX, 0(BP)
MOVLBX, 4(BP)
MOVLCX, 8(BP)
MOVLDX, 12(BP)
RET

What I miss is where "info" comes from. I cannot

Apparently the GAS equivalent is:

.align 4
.globl cpuid
cpuid:
mov%ebp,%eax
cpuid
mov0x10(%rsp),%rbp
mov%eax,0x0(%rbp)
mov%ebx,0x4(%rbp)
mov%ecx,0x8(%rbp)
mov%edx,0xc(%rbp)
retq

Thus apparently info+8(FP) becomes 0x10(%rsp)
Why? I know that FP is a pseudo register, but shouldn't it be different
from SP?

And why info's value is 8? Is it the pointer size?

Another example:

TEXT insb(SB), 1, $-4
MOVLRARG, DX/* MOVLport+0(FP), DX */
MOVQaddress+8(FP), DI
MOVLcount+16(FP), CX
CLD
REP;INSB
RET

should be equivalent to

.align 4
.globl insb
insb:
mov%ebp,%edx
mov0x10(%rsp),%rdi
mov0x18(%rsp),%ecx
cld
rep insb
retq

Again I cannot find a definition of address and count, but both seem to be
be valued as 8, why?


Giacomo

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

Thanks for the explainations!

I did read in the Pike's paper about the syntax name+offset(FP), but I did
understood that name had to be a symbol already defined, and I was looking
for it in the c code. Sorry for the noise!

This led me to another question, however: I've read before that the plan9
compilers use the stack for va_list, but here the assembler is using it
also for explicit parameters, right?

Is it correct to say that this means that the Plan9 compiler suite *never*
follows the sysV calling convention documented at section 3.2.3 of AMD64
ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
parameters to the stack?


Giacomo



2016-02-01 23:48 GMT+01:00 :

> FP is a translated to a varying offset to SP depending on where in the
> program
> you are. arguments on the stack are padded to 8 bytes on amd64, the first
> argument
> is not passed on the stack on function entry, but passed in BP register
> (RARG is an
> alias for that), however the slot on the stack for first arg is still
> reserved
> so we have a save place to splill it. so 0(FP) is first function argument
> on the
> stack, 8(FP) second argument 16(FP) third ect...
>
> --
> cinap
>
>

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

I kinda agree, but I'm too incompetent in the matter. :-)

However, I was simply asking if, on amd64, kencc uses the 6 registers that
the abi deserves to the parameters.
As far as I've understood only BP is used (for the first argument, if
integer).

Can you confirm?



Giacomo

2016-02-02 1:36 GMT+01:00 Charles Forsyth <charles.fors...@gmail.com>:

>
> On 1 February 2016 at 23:34, Giacomo Tesio <giac...@tesio.it> wrote:
>
>>
>> Is it correct to say that this means that the Plan9 compiler suite
>> *never* follows the sysV calling convention documented at section 3.2.3 of
>> AMD64 ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
>> parameters to the stack?
>
>
> On amd64, the first parameter, if an integer, is passed in RARG, which is
> actually BP.
> The RISC machines generally pass the first parameter, if an integer, in a
> register.
>
> In general, the compiler suite never follows conventions prescribed by
> apparent maniacs.
> In particular, varargs/stdargs should (in 2000, let alone 2016) be really
> easy: lay down the ... parameters on the stack as an array in memory.
> Done. Instead ABIs give pages of filth that try to work out where things
> are for the va_x macro calls,
> because the ABI insists on following the same calling convention
> for vararg/stdarg functions as might be used for other functions with
> fixed parameters: parameter passing in registers, special rules for
> structs, special rules for structs that fit in the parameter registers,
> special rules for floating-point values. Absurd.
>

[9fans] segbrk(2) vs friends

[Giacomo Tesio]

I'm trying to understand the reason behind the introduction of segbrk(2).

I cannot find a use case in the codebase.

The manual page states that:

The segbrk system call may go away or
be re-implemented to give more general segment control, sub-
suming the functions of brk(2) ,
segflush(2)  and segfree
insegattach(2) .


But given the manpage itself is pretty cryptic, I wonder if it's outdated.
Or if it is actually deprecated.


Do you know any paper that can explain its design and intent?


Giacomo

Re: [9fans] Compiling ken-cc on Linux

[Giacomo Tesio]

2015-11-27 13:42 GMT+01:00 <tlaro...@polynum.com>:

> On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote:
> >
> > I know nothing about compilers, but actually gcc and clang dimension and
> > complexity is astonishing.
>
> It's not astonishing: it's research. They want to prove that a black
> hole does exist.
>

Funny, but actually I was wondering if there is any subtle issue in the
standards of the C language that makes it somehow hard to implement.
For example I've met a few times weird implementations of libraries and
frameworks dictated by broken standards: once they are in, they can never
be removed due to backward compatibility. I thought that Charles (that also
implemented the Limbo compiler) might have referenced these kind of issues
in his pun.


Giacomo

Re: [9fans] Compiling ken-cc on Linux

[Giacomo Tesio]

2015-11-27 0:21 GMT+01:00 Charles Forsyth :

>
> On 26 November 2015 at 23:08, Ryan Gonzalez  wrote:
>
>> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't
>> think it used that much. I only have 6 GB right now!
>
>
> You have to remember that a C compiler is one of the largest, most complex
> software components that human beings have ever had to produce.
> The original C reference manual made it look deceptively easy, but really
> there's a ton of stuff going on in there, as you can see.
> How they ever got it going on a system with 64Kbytes of address space,
> I'll never know.
>

I'd love to read more about this, Charles. :-)

I know nothing about compilers, but actually gcc and clang dimension and
complexity is astonishing.
I've always thought that this is due to their desire to compile many
different language optimized for many different OS and architectures on
many different OS and architecture.

Alternative compilers, like tcc, only build C on very few architectures /
os with almost no optimization: they are much smaller, but still not
standard compliant.


How can it be?


Giacomo

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

[Giacomo Tesio]

2015-10-12 19:00 GMT+02:00 Charles Forsyth :

>
> On 12 October 2015 at 17:49, Álvaro Jurado  wrote:
>
>> what ensures sha key is in fs.
>
>
> The reason many of us are a little sceptical about it being fsync as such
> preventing the data appearing
> is that if the git function that writes the key does a write or pwrite,
> the key will be in the file system on Plan 9: there's no need for an fsync
> just to get it there.
> In fact, in Linux there's no need for an fsync just to get it there: it
> only matters in the case of a crash.
>
> If the file system fails or you reset the machine, the intention of the
> fsync will be frustrated, but
> it shouldn't affect normal operation where no file server crash occurs.
>
> As it happens, a wstat that changes nothing can be interpreted by a file
> server to have a similar effect as fsync (see stat(5)).
>

Thus Plan9 HAS fsync! :-o
And it also has server-defined semantics! Very impressive!


Giacomo

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

[Giacomo Tesio]

2015-09-05 20:47 GMT+02:00 erik quanstrom :

> > May be my problem is that p is global in my case?
>
> global variables are in the bss, and thus shared. p will have
> the same value in each thread, but *p should point into the
> stack, and thus the same virtual address will be mapped to
> different physical pages of memory.
>
> however, if *p is assigned to a non-zero value before the process
> is created, the new page allocated for the new process' stack will
> have a copy of the old value, and thus not be 0.
>
> - erik
>
>
That's exactly what happened.
I misread privalloc(2), and assumed that privalloc()ed addresses were
somehow reset on rfork.
This is probably something to explicitly state the man page.

Thanks you all!


Giacomo

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

[Giacomo Tesio]

... and given getpid(2) implementation, a pid based table could be quite
expensive, since MyStruct is accessed very very often.

2015-09-05 16:03 GMT+02:00 Giacomo Tesio <giac...@tesio.it>:

> 2011-05-20 3:30 GMT+02:00 erik quanstrom <quans...@quanstro.net>:
>
>> one note is that while i'm aware of privalloc(2), i didn't use it.  the
>> implementation doesn't appear correct for shared-memory procs.
>> i think there are two issues
>> - locking is unnecessary.  the only preemptable unit of execution is
>> a process and each process is guarenteed to have its own instance
>> of _privates and _nprivates.
>> - for shared-memory procs, we will run out of privates because
>> the static privinit will be falsely shared.  privinit should be replaced
>> by using a private entry.
>>
>
> In a set of processes that share memory, I need a single per-process
> location to store the address of structure (which is in turn allocated in
> the global memory space).
>
> Privalloc(2) seemed what I need, but seem that I can't use it properly.
>
> In the parent process I do:
>
> 1) initialialize a global variable p = (MyStruct **)privalloc();
> 2) allocate a MyStruct for every process I'm going to spawn
> 3) spawn processes with rfork(RFMEM|RFPROC)
>
> The spawn() function that call rfork takes a MyStruct* as argument and
> assign it to *p in the new process.
> For extra safety I added an assert(*p == nil) just after rfork, and after
> a few (apparently?) successful spawns, the assert fails.
>
> What I need is a sort of thread-local storage for the MyStruct*, so that
> each child process can find it's own dedicated MyStruct.
> I know that could get this with an hashtable based on the pid, but I'd
> prefer to avoid the book keeping if possible.
>
>
> Giacomo
>

[9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

[Giacomo Tesio]

2011-05-20 3:30 GMT+02:00 erik quanstrom :

> one note is that while i'm aware of privalloc(2), i didn't use it.  the
> implementation doesn't appear correct for shared-memory procs.
> i think there are two issues
> - locking is unnecessary.  the only preemptable unit of execution is
> a process and each process is guarenteed to have its own instance
> of _privates and _nprivates.
> - for shared-memory procs, we will run out of privates because
> the static privinit will be falsely shared.  privinit should be replaced
> by using a private entry.
>

In a set of processes that share memory, I need a single per-process
location to store the address of structure (which is in turn allocated in
the global memory space).

Privalloc(2) seemed what I need, but seem that I can't use it properly.

In the parent process I do:

1) initialialize a global variable p = (MyStruct **)privalloc();
2) allocate a MyStruct for every process I'm going to spawn
3) spawn processes with rfork(RFMEM|RFPROC)

The spawn() function that call rfork takes a MyStruct* as argument and
assign it to *p in the new process.
For extra safety I added an assert(*p == nil) just after rfork, and after a
few (apparently?) successful spawns, the assert fails.

What I need is a sort of thread-local storage for the MyStruct*, so that
each child process can find it's own dedicated MyStruct.
I know that could get this with an hashtable based on the pid, but I'd
prefer to avoid the book keeping if possible.


Giacomo

Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs)

[Giacomo Tesio]

Nice example thanks.

May be my problem is that p is global in my case?

Giacomo
Il 05/Set/2015 18:50, "erik quanstrom"  ha scritto:

> by the way, the following program runs without asserting for me
> with or without the waits.
>
> - erik
>
> ---
>
> #include 
> #include 
>
> void
> task(void **p)
> {
> assert(*p == nil);
> *p = (void*)(uintptr)getpid();
> }
>
> void
> spawn(void (*t)(void**), void **p)
> {
> int pid;
>
> switch(pid = rfork(RFMEM|RFPROC)){
> case -1:
> sysfatal("spawn: rfork: %r");
> case 0:
> t(p);
> exits("");
> default:
> USED(pid);
> return;
> }
> }
>
> void
> main(void)
> {
> int i, k;
> void **p;
> Waitmsg *w;
>
> p = privalloc();
> k = 0;
> for(i = 0; i < 1024; i++){
> spawn(task, p);
> for(k++; k > 16; k--){
> if((w = wait()) == nil)
> break;
> free(w);
> }
> }
> exits("");
> }
>
>

Re: [9fans] u9fs sources

[Giacomo Tesio]

2015-09-02 6:38 GMT+02:00 :

> > I don't think it is currently maintained, but Plan 9 ships with a copy
> > of it under /sys/src/cmd/unix. I used that as the basis of the OpenBSD
> > port.
>
> I have it on my list of urgent tasks to fix u9fs.  The more recent
> copy (details need investigating) fails on NetBSD when encountering
> group IDs that don't have a matching value in /etc/group as well as
> under more mysterious circumstances.  The older copy works adequately
> (very similar platform, not identical), but it seems to care much less
> about group IDs and it seems a waste that somebody would have done a
> lot of work in vain.
>

Nice! Actually, I'm going to need the NetBSD port up and running in the
relatively near future.

A very useful thing to do is to list the known issues.
Even more useful would be to setup a set of failing shell scripts that
reproduces the issues, so that we can use them as tests.


>
> I can find out more about each, but if someone else is willing to
> help, I'd also like to apply similar expertise to add ownership and
> permission settings to NetBSD's variation of v9fs which I presume is
> an analogous problem?
>

I did not know of a v9fs version for NetBSD... Any link?

Actually, I don't care about neither 9p2000.U nor 9p2000.L.

So, feel free to nudge me, if you can add to my rather limited skills,
> the hardware can be made available for development and testing.
>
> Lucio.
>

I shouldn't need any hardware (a Xen domU should be enough), but in case
I'll write you when I'm ready to work on this.

Can you share links to the most updated sources for NetBSD?


Giacomo

Re: [9fans] pthreads

[Giacomo Tesio]

2008-12-16 23:16 GMT+01:00 Steve Simon :

> I have a distant memory that somone implemented some of POSIX pthreads
> on plan9, i.e. I want to compile programs that use pthreads under APE.
>
> anyone got any pointers?
>

Hi Steve, did you find anything (even incomplete) back then?


Giacomo

[9fans] u9fs sources

[Giacomo Tesio]

Hi, anybody knows where the u9fs sources are currently maintained?

I have just found https://bitbucket.org/plan9-from-bell-labs/u9fs but it's
only linked by an old googlecode repo: I was unable to find any official
link in the bell labs pages.


Giacomo

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

2015-08-12 9:25 GMT+02:00 David du Colombier 0in...@gmail.com:

 This comment is indeed pretty old. It was already present
 in the Second Edition.


So that check is based on pre 9p2000 code? If so, Charles have probably
explained it:

2015-08-10 17:40 GMT+02:00 Charles Forsyth charles.fors...@gmail.com:

 As a further historical note, originally 9P required a stream that
 preseved record boundaries, and the reliable datagram protocol IL/IP and
 pipes did that.


So, seem that ignoring zeros is simply wrong. A residual from the past...


Giacomo

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

2015-08-11 17:48 GMT+02:00 Charles Forsyth charles.fors...@gmail.com:


 On 10 August 2015 at 15:11, Giacomo Tesio giac...@tesio.it wrote:

 /*
  * reading from a pipe or a network device
  * will give an error after a few eof reads.
  * however, we cannot tell the difference
  * between a zero-length read and an interrupt
  * on the processes writing to us,
  * so we wait for the error.
  */


 it's doubly odd, because there's no reason for an interrupted writer to go
 to the lengths of writing an empty record as a consequence of being
 interrupted. it will waserror out in the writer, so why should an empty
 Block end up on the underlying Queue?


Ah, if only git existed when that comment was written! :-D

When I read that comment I though of a remote user space writer, whose
kernel (an old plan9 version?) on process interrupt gracefully send EOFs to
all chan open for write.

However I wasn't able to find anything concrete prove of this behavior in
the codebase (but maybe I looked at the wrong places)


 In fact, an interrupted writer in devmnt will start the flush(5) protocol,
 so it will be writing Tflush, not empty records.


This is interesting too: I thought that Tflush were for requests that had
not yet been completed. But the interrupted writer could be just waiting. I
mean the chan is open, but its last Twrite has already been replied with a
Rwrite.

In this case, sending a EOF on behalf of a process could have sense... or
not? Probably depends on the interrupt.


Giacomo

Re: [9fans] read9pmsg usage

[Giacomo Tesio]

2015-08-10 16:54 GMT+02:00 Charles Forsyth charles.fors...@gmail.com:

 Zero conventionally means end-of-file, but record boundaries are preserved
 on capable streams, so if a writer writes zero, the reader reads zero.


However this two requirements do not seem reconcilable.

Zero can either mean EOF or I'm alive but boring.

I can't see how a reliable communication (a cpu connection for example) can
survive this mismatch.
I'm probably missing something.


Giacomo

[9fans] read9pmsg usage

[Giacomo Tesio]

Hi, I've a probably naive question that I can't figure out.
I've just noticed that fcall(2) states

 Read9pmsg calls read(2) multiple times, if necessary, to
 read an entire 9P message into buf.  The return value is 0
 for end of file, or -1 for error; it does not return partial
 messages.


but I've noticed that a few client does not interpret a 0 return value as a
EOF, eg

https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/lib/fs.c#L604-L606
https://github.com/brho/plan9/blob/master/sys/src/cmd/usb/audio/audiofs.c#L889-L891
https://github.com/brho/plan9/blob/master/sys/src/cmd/aux/searchfs.c#L613-L615
https://github.com/brho/plan9/blob/master/sys/src/cmd/lnfs.c#L547-L551
https://github.com/brho/plan9/blob/master/sys/src/cmd/telco/telco.c#L935-L937

The comment there states that

/*
 * reading from a pipe or a network device
 * will give an error after a few eof reads.
 * however, we cannot tell the difference
 * between a zero-length read and an interrupt
 * on the processes writing to us,
 * so we wait for the error.
 */

However many other fs just handle errors and eof together, for example here:
https://github.com/brho/plan9/blob/master/sys/src/cmd/ip/ftpfs/ftpfs.c#L273-L279

I'm a bit confused about this. What's the proper use of the 0 return value?


Giacomo

Re: [9fans] Harvey OS: A new OS inspired heavily by Plan 9

[Giacomo Tesio]

Il 27/Lug/2015 23:47, Skip Tavakkolian 9...@9netics.com ha scritto:

  you are aware of the 9fans' fetish for movies

 and rabbits

...and feticists. ;-)

Re: [9fans] small VFD display

[Giacomo Tesio]

2015-06-09 20:34 GMT+02:00 Ethan Grammatikidis eeke...@fastmail.fm:

 search the web for EWD898. it's a good read; fascinating how little
 has really changed.


I know it's off-topic, but it's funny to compare that Dijkstra's paper with
this video https://www.youtube.com/watch?v=qlRTbl_IB-s (and this site
http://2045.com/ !)

I've just found it, and suddenly I realized that all the crazy ideas I've
got in the past were quite realistic, after all. :-D


Giacomo

Re: [9fans] using git

[Giacomo Tesio]

Ah, a small addendum: obviously we also use tags a lot to give a specific
commit (and related history) a name.
This is done automatically by build servers for the official tags, and
manually by developers whenever they want in their own repository (often
with tags like, workedhere, shittorefactortomorrow and so on).


Giacomo

2015-03-30 11:48 GMT+02:00 Giacomo Tesio giac...@tesio.it:

 As I use both git and hg, I really miss the feature-branching in hg
 (obviously, you can, if you try hard enough, use feature branching with hg
 too, but git makes it so easy that it became my default process whenever I
 can use git for development, even on solo projects):

 Suppose you have a team of 3 or more people and a central git server
 that can be used for facility of share (company server, github, bitbucket,
 gitorious...): each person start working on a issue (let it be a bug to fix
 or a new feature to implement) by doing on his working copy

 git checkout -b feature-nickname


 than it change anything that he consider relevant, committing whenever he
 decides that a change can be described in a sensible way:

 git commit -am 'OptimizingVisitor applies DeMorgan laws'

 ... a few work after...
 git commit -am 'OptimizingVisitor detects constants predicates'


 At any time, each developer can push the changes to the central server, to
 share his progresses and without the pain to merge them until the full
 issue has been addressed.

 The next day, a different developer could continue his work if it's really
 required (rarely, but it happened).

 When the feature has been fully implemented, the dev can merge it into the
 shared branch (master, or development when a human-driven test process is
 required before the production deployment).

 We do not use rebase: we want to keep track of which code the dev was
 seeing while writing his changes.

 At any time, we can see what features have been released, looking at which
 branches have been merged in the shared branch.


 On medium to large projects (5 to 20 people) this process allows a fast,
 painless collaboration.

 Still, whenever I can use git, I use it for my solo projects too, and I
 find it quite good to keep track of the progress of the project.


 My two cents.


 Giacomo


 2015-03-28 15:00 GMT+01:00 Paul Lalonde paul.a.lalo...@gmail.com:

 I'd like to hear it too - much to learn from others' process.
 Paul

 On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth 
 charles.fors...@gmail.com wrote:


 On 19 March 2015 at 18:26, arn...@skeeve.com wrote:

 Charles Forsyth charles.fors...@gmail.com wrote:

  On 19 March 2015 at 16:09, arn...@skeeve.com wrote:
 
   There is definitely some
   learning curve and mindset change
 
  Just what I want from a little servant that's supposed to help me
 manage
  some file changes.

 Git is intended for something completely different than RCS.

 I really, REALLY, don't want to start a flame war, although this being
 9fans, it's probably not possible. More's the pity.

 And again, I AM NOT trying to proselytize.  But, if you are curious as
 to what value I personally found in git for gawk development, I will be
 happy to discuss it in personal email.


 Unfortunately, switching between different devices I missed this reply.
 I wasn't really comparing it to RCS although I can see that was a
 reasonable conclusion from my wording.


 It might be worthwhile sending a brief description of what you use and
 what you find valuable to the list.
 There isn't much traffic at the moment.

Re: [9fans] using git

[Giacomo Tesio]

As I use both git and hg, I really miss the feature-branching in hg
(obviously, you can, if you try hard enough, use feature branching with hg
too, but git makes it so easy that it became my default process whenever I
can use git for development, even on solo projects):

Suppose you have a team of 3 or more people and a central git server that
can be used for facility of share (company server, github, bitbucket,
gitorious...): each person start working on a issue (let it be a bug to fix
or a new feature to implement) by doing on his working copy

git checkout -b feature-nickname


than it change anything that he consider relevant, committing whenever he
decides that a change can be described in a sensible way:

git commit -am 'OptimizingVisitor applies DeMorgan laws'

... a few work after...
git commit -am 'OptimizingVisitor detects constants predicates'


At any time, each developer can push the changes to the central server, to
share his progresses and without the pain to merge them until the full
issue has been addressed.

The next day, a different developer could continue his work if it's really
required (rarely, but it happened).

When the feature has been fully implemented, the dev can merge it into the
shared branch (master, or development when a human-driven test process is
required before the production deployment).

We do not use rebase: we want to keep track of which code the dev was
seeing while writing his changes.

At any time, we can see what features have been released, looking at which
branches have been merged in the shared branch.


On medium to large projects (5 to 20 people) this process allows a fast,
painless collaboration.

Still, whenever I can use git, I use it for my solo projects too, and I
find it quite good to keep track of the progress of the project.


My two cents.


Giacomo


2015-03-28 15:00 GMT+01:00 Paul Lalonde paul.a.lalo...@gmail.com:

 I'd like to hear it too - much to learn from others' process.
 Paul

 On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth charles.fors...@gmail.com
 wrote:


 On 19 March 2015 at 18:26, arn...@skeeve.com wrote:

 Charles Forsyth charles.fors...@gmail.com wrote:

  On 19 March 2015 at 16:09, arn...@skeeve.com wrote:
 
   There is definitely some
   learning curve and mindset change
 
  Just what I want from a little servant that's supposed to help me
 manage
  some file changes.

 Git is intended for something completely different than RCS.

 I really, REALLY, don't want to start a flame war, although this being
 9fans, it's probably not possible. More's the pity.

 And again, I AM NOT trying to proselytize.  But, if you are curious as
 to what value I personally found in git for gawk development, I will be
 happy to discuss it in personal email.


 Unfortunately, switching between different devices I missed this reply.
 I wasn't really comparing it to RCS although I can see that was a
 reasonable conclusion from my wording.


 It might be worthwhile sending a brief description of what you use and
 what you find valuable to the list.
 There isn't much traffic at the moment.

Re: [9fans] using git

[Giacomo Tesio]

Actually, Jeff I appreciate a lot your work on mercurial. I know I could
use the bookmarks extension to achieve a similar process with hg (never
tried darcs and bzr seriously, sorry). but I still prefer git to mercurial,
since it has been designed around the features that I like (when working
alone) or need (when working in large team over years long projects).

But this is personal taste, and I'm not a git evangelist. I just replied to
Charles asking for the features we use in git.

Btw, ever heard of http://libgit2.org ?
Plain c89. No external dependencies.

In theory, one could implement a native gitfs over that, in C, using the
network fs available in Plan9.

Compared to hgfs, a bit more design of the fs structure would probably be
needed to capture the concept of branch in a hierarchical filesystem.

How much you would estimate such development?


Giacomo



2015-03-30 18:16 GMT+02:00 Jeff Sickel j...@corpus-callosum.com:


  On Mar 30, 2015, at 4:55 AM, Giacomo Tesio giac...@tesio.it wrote:
 
  Ah, a small addendum: obviously we also use tags a lot to give a
 specific commit (and related history) a name.
  This is done automatically by build servers for the official tags, and
 manually by developers whenever they want in their own repository (often
 with tags like, workedhere, shittorefactortomorrow and so on).

 All of those features are available in hg, darcs, and other dscm tools.

 But to get back on topic, unless I’ve overlooked a contrib package
 somewhere, how about we begin with the requirements to get a fully working
 git installed on Plan 9.  For example,

 ## the dependencies required for git on a bare-bones FreeBSD install:
 # pkg install git
 Updating FreeBSD repository catalogue...
 FreeBSD repository is up-to-date.
 All repositories are up-to-date.
 The following 18 packages will be affected (of 0 checked):

 New packages to be INSTALLED:
 git: 2.3.4
 expat: 2.1.0_2
 p5-Authen-SASL: 2.16_1
 p5-GSSAPI: 0.28_1
 perl5: 5.18.4_11
 p5-Digest-HMAC: 1.03_1
 p5-Net-SMTP-SSL: 1.01_3
 p5-IO-Socket-SSL: 2.012
 p5-Mozilla-CA: 20141217
 p5-Net-SSLeay: 1.68
 p5-Socket: 2.018
 p5-IO-Socket-IP: 0.37
 python27: 2.7.9
 libffi: 3.2.1
 p5-Error: 0.17023
 curl: 7.41.0
 ca_root_nss: 3.18
 cvsps: 2.1_1



 I’m not sure what cvsps is for, that seems to have cropped up on the fbsd
 pkg sometime between git versions 2.3.1 and 2.3.4.  It’s been
 years^wdecades since I’ve tinkered with perl, and I’m fairly certain the
 perl 5.8 version available on Plan 9 won’t support the modules included in
 the above list.  So Plan 9 needs a modern perl to run git effectively with
 specific attention to the additional modules.  Expat is the “eXpat XML
 parser library”.  Libffi is something maintained on sources.redhat.com.
 Many of those modules depend on OpenSSL, so add that to the list.  It’s
 also possible a recent port of bash will also be required as the git
 support scripts may not work with our ape/sh or ape/psh.  We’ve got python
 2.7.8 [.9 soon] covered.

 Piece of cake, all that should fit on a coaster.

 -jas

Re: [9fans] jas' cpython

[Giacomo Tesio]

Thanks David!

2015-03-25 12:12 GMT+01:00 David du Colombier 0in...@gmail.com:

  How should I extract files from an .arch archive?

 disk/mkext -d /  cpython-src.arch

 --
 David du Colombier

[9fans] jas' cpython

[Giacomo Tesio]

I feel a bit dumb, but I can't grasp how to extracts file from

http://plan9.bell-labs.com/sources/contrib/jas/cpython-src.arch.bz2

and

http://plan9.bell-labs.com/sources/contrib/jas/hg-src.arch.bz2


tar(1), gzip(1) and ar(1) did not helped.

How should I extract files from an .arch archive?


Giacomo

Re: [9fans] Very old bug in db(1)

[Giacomo Tesio]

I could be wrong, but looks like nobody cares about such small fixes.

A few days ago, I've found some very old small errors (one in the 2c(1) man
page and one in col(1) that affects man pages' visualization in variable
width fonts) but had no feedback.
I guess that the most effective way to cope with such old and small bugs,
is to report them on 9fans (and other related mailing lists), possibly with
a patch.
This way, any other user that hit the bug (and find your email) can apply
the patch and fix them in his $home/bin (or somewhere else) and then bind
-b it to /bin.


Giacomo

2015-03-19 7:41 GMT+01:00 Roberto E. Vargas Caballero k...@shike2.com:

 I was doing some experiments with db(1), when I tried something like:

 main:b *argv/X

 and it gave me an error. I debugged it and I found that is a bug in the
 code due to a mix between char* and Rune*. I have created a patch
 in sources with the name unicode-db.

 The funny thing is this error must be at least 20 years old,
 because clearly its origin is the unicode translation of old unix tools.
 I have checked  labs, 9front and plan9port and all of them have
 the error (in some moment someone realized about a warning
 of the compiler about different pointer types and simply put a
 cast, that is not present in the code of plan9port).

 I send this mail here, first because I think is the error is funy,
 second because is my first patch send to plan9 and I'm not sure about
 the process, and third because it affects to all the versions of plan9
 and I'm not sure if all of them take this bug fixes from sources.

 Regards,

Re: [9fans] Very old bug in db(1)

[Giacomo Tesio]

Oh, I completely missed patch(1). And actually it was just when one should
look up for at first... man pages. Sorry.

Thanks for the tip!

It's a fragmented small community and that is just sad.  It is not
 likely that things will get better in the foreseeable future, so pick
 your side :-)


To pick a side, one should knows the contenders enough. :-)
It's very hard to find clear statements about the differences between the
various plan9 flavours, or clear descriptions of the vision driving the
development of each fork (at least I wasn't able to find them).
This is particularly true for plan9 forks that bet on Plan9 evolution
outside bell labs (9atom and 9front), while it's easy to get the
differences between 9legacy, Inferno, Nix-os etc...

More than 15 years ago, when I started using linux, it was easy to see how
Debian was different from RedHat or Suse.
In the Plan9 ecosystem, while looks that some are quite upsets about such
differences, it's hard to grasp them from the outside.


Giacomo

Re: [9fans] 2c(2) error

[Giacomo Tesio]

Ehm... obviously I was talking about 2c(1)...

Too much coffe, today... :-D

2015-03-10 16:53 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 2c(2) states:

 Array initializers can specify the indices of the array in
   square brackets, as
   int a[] = { [3] 1, [10] 5 };
   which initializes the third and tenth elements of the
   eleven-element array a.


 This is somewhat confusing: the third and the tenth element should have
 index 2 and 9. Moreover if the tenth element is actually referred by index
 10, why the array should hold eleven elements?

 A simple check shows that actually the array has 11 elements and the one
 initialized are the forth and the eleventh.


 Giacomo

[9fans] 2c(2) error

[Giacomo Tesio]

2c(2) states:

Array initializers can specify the indices of the array in
   square brackets, as
   int a[] = { [3] 1, [10] 5 };
   which initializes the third and tenth elements of the
   eleven-element array a.


This is somewhat confusing: the third and the tenth element should have
index 2 and 9. Moreover if the tenth element is actually referred by index
10, why the array should hold eleven elements?

A simple check shows that actually the array has 11 elements and the one
initialized are the forth and the eleventh.


Giacomo
diff -r 51285ae4f545 sys/man/1/2c
--- a/sys/man/1/2c  Thu Mar 05 10:17:23 2015 +0100
+++ b/sys/man/1/2c  Tue Mar 10 16:52:03 2015 +0100
@@ -250,7 +250,7 @@
 .EX
 int a[] = { [3] 1, [10] 5 };
 .EE
-which initializes the third and tenth elements of the eleven-element array
+which initializes the forth and eleventh elements of the eleven-element array
 .BR a .
 .TP
 \-

[9fans] col.c: one line fix for variable-width font

[Giacomo Tesio]

I gave a look at col.c and found a better fix for the tabs issue.

We simply need that col check for the previous char being a space, before
adding any tab. That is, at /sys/src/cmd/col.c:251 replace

if ((++ncp  7) == 0  !xflag) {

with

if ((++ncp  7) == 0  !xflag  *(p-2) == ' ') {

This is a better fix that redefining col in /rc/bin/man since this way col
correctly replace spaces with tabs when appropriate. It just stops to
replace single spaces at positions multiple of 8 with tabs.


Giacomo
PS: col.c ignores $tabstop. This could be something to add in the man page.
Or to fix in col.c (a really trivial fix, btw)

Re: [9fans] col.c: one line fix for variable-width font

[Giacomo Tesio]

Actually I'm using drawterm, as a sort of remote desktop connection. But I
can't see the problem you are talking about.
The clients (either windows or linux) don't have the font installed, but
still it seem working pretty well (except for the spacing issues in man
pages). I don't have a real monitor attached to the xen server, so I can't
try it without drawterm.

col.c just ignores $tabstop in it's source code. It use a Tabstop = 8
constant instead (and a 7 value to check for position).
Changing the code to use $tabstop is trivial, and I even tried it, but it
neither fixed the initial problem nor decreased the man output size enough
to justify it's proposal.

I'm going to write a sed script to remove the leading margin (but not every
space or tab at the beginning of each line) from nroff output so that (with
my font and my 14inches monitor) I can use a 3 column acme to browse
/sys/src/  read the code  browse man pages.
This should also reduce the man output size more than col.


Giacomo

2015-03-06 17:33 GMT+01:00 erik quanstrom quans...@quanstro.net:

 On Fri Mar  6 04:57:18 PST 2015, giac...@tesio.it wrote:

  if ((++ncp  7) == 0  !xflag) {
 
  with
 
  if ((++ncp  7) == 0  !xflag  *(p-2) == ' ') {

 that solves it.  you have a problem with $tabstop.  if you've cpu'd
 or ssh'd somewhere, make sure the $tabstop is set properly, and that
 the font you are using is available on the remote host, and $font
 is pointing to it.

 - erik

Re: [9fans] col.c: one line fix for variable-width font

[Giacomo Tesio]

ehm... well... actually I could try with vnc... :-)


Giacomo

2015-03-06 18:22 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 Actually I'm using drawterm, as a sort of remote desktop connection. But I
 can't see the problem you are talking about.
 The clients (either windows or linux) don't have the font installed, but
 still it seem working pretty well (except for the spacing issues in man
 pages). I don't have a real monitor attached to the xen server, so I can't
 try it without drawterm.

 col.c just ignores $tabstop in it's source code. It use a Tabstop = 8
 constant instead (and a 7 value to check for position).
 Changing the code to use $tabstop is trivial, and I even tried it, but it
 neither fixed the initial problem nor decreased the man output size enough
 to justify it's proposal.

 I'm going to write a sed script to remove the leading margin (but not
 every space or tab at the beginning of each line) from nroff output so that
 (with my font and my 14inches monitor) I can use a 3 column acme to browse
 /sys/src/  read the code  browse man pages.
 This should also reduce the man output size more than col.


 Giacomo

 2015-03-06 17:33 GMT+01:00 erik quanstrom quans...@quanstro.net:

 On Fri Mar  6 04:57:18 PST 2015, giac...@tesio.it wrote:

  if ((++ncp  7) == 0  !xflag) {
 
  with
 
  if ((++ncp  7) == 0  !xflag  *(p-2) == ' ') {

 that solves it.  you have a problem with $tabstop.  if you've cpu'd
 or ssh'd somewhere, make sure the $tabstop is set properly, and that
 the font you are using is available on the remote host, and $font
 is pointing to it.

 - erik

Re: [9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

Which font are you using?
With all mono-spaced (fixed-width) fonts everything works fine. The problem
occurs just with  variable spaced fonts.

Btw I noted that the fix is not perfect: the table at the end of man(1) is
misaligned, with or without the fix. Even without calling col at all.

This could be due to troff assuming fixed with font and inserting spaces
instead of tabs. And its a pity, because  probably libframe would align
tabs properly.

But this is just a guess, I had no time to check the troff code for this
second issue.

Giacomo
Il 05/Mar/2015 15:23 erik quanstrom quans...@quanstro.net ha scritto:

  Interestingly enough the problem disappears with a mono font.
 
  I suspect that troff is inserting such tabs instead of spaces when it
  thinks they are the same. Indeed libframe (as far I could understand from
  the manual and the sources) properly handles such variable width fonts.
 
  Looks like I've to inform troff about the glyphs sizes... but how?

 i don't use a mono font so i don't like your col -x solution, and this
 works for me regardless.

 if $font is set correctly, i believe all this should work out.  make sure
 that $tabstop=acme tabstop as well.  the default for acme is 4, but
 it is imported by $tabstop, and overridden with Tab.

 cpu'ing can screw with your $font.

 - erik

[9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

Hi, I've just installed a compact sans font (from
http://input.fontbureau.com/ ) and manual pages started to look broken.

As you can see in the screenshot (man 2 control), there are white spaces
that looks like tabs in the middle of the text with apparently no reason.
Even in the troff source (why the hell we still use troff for manual pages?
:-D) I can see no command that explain this behaviour.

Any tip to fix them?


Giacomo

[image: Immagine in linea 1]

Re: [9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

Interestingly enough the problem disappears with a mono font.

I suspect that troff is inserting such tabs instead of spaces when it
thinks they are the same. Indeed libframe (as far I could understand from
the manual and the sources) properly handles such variable width fonts.

Looks like I've to inform troff about the glyphs sizes... but how?


Giacomo

2015-03-04 17:13 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 Hi, I've just installed a compact sans font (from
 http://input.fontbureau.com/ ) and manual pages started to look broken.

 As you can see in the screenshot (man 2 control), there are white spaces
 that looks like tabs in the middle of the text with apparently no reason.
 Even in the troff source (why the hell we still use troff for manual
 pages? :-D) I can see no command that explain this behaviour.

 Any tip to fix them?


 Giacomo

 [image: Immagine in linea 1]

Re: [9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

Well... docx, obviously! :-D

Seriously, a markdown/asciidoc like language would be far easier to
write and update.
We could even compile it to troff, we we had to print it.

However, this is not a rant specific to plan9. Linux is not better
from this point of view.


Giacomo

2015-03-04 22:31 GMT+01:00 Aram Hăvărneanu ara...@mgk.ro:
 On Wed, Mar 4, 2015 at 5:13 PM, Giacomo Tesio giac...@tesio.it wrote:

 why the hell we still use troff for manual pages?

 What do you propose we use instead?

 --
 Aram Hăvărneanu

Re: [9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

2015-03-05 0:56 GMT+01:00 s...@9front.org:

  And btw, programs don't write man pages... yet.

 Are you familiar with the conventions that power godoc?


No, but I know quite well it's predecessors (Docstrings, Javadoc etc...).

They are great for API, but IMHO not every unix man page can be generated
from code. They are a specialized kind of prose.

What I can't undestand I why we still need troff for them.

It's almost like using a teletype to chat! :-)


Giacomo

Re: [9fans] unexpected tabs in man pages after font change

[Giacomo Tesio]

Well, while a bit offtopic... what do you mean by programmatically.

And btw, programs don't write man pages... yet.


Giacomo

2015-03-04 23:39 GMT+01:00 Stanley Lieber s...@9front.org:
 troff is great. easy to maintain programmatically.

 sl

Re: [9fans] drawterm sources

[Giacomo Tesio]

Thanks a lot! :-D


Giacomo

2015-03-02 11:55 GMT+01:00 yy yiyu@gmail.com:
 On 2 March 2015 at 11:06, Giacomo Tesio giac...@tesio.it wrote:
 - where I can find the most updated sources of drawterm? (links from
 http://swtch.com/drawterm/ seem to be broken)

 https://bitbucket.org/rsc/drawterm

 - Is there any simpler solution? Buying a three-button mouse is quite
 hard in Italy, and above all its usage is not viable on my couch...
 :-)

 I like to use the wheel for chording (patched acme in contrib). This
 works well with the trackpad in my laptop too. YMMV.


 --
 - yiyus || JGL .