[9fans] gcc on plan9

[9fans] gcc on plan9

[Corey]

Two questions - quite likely naive, so please be kind!

#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?

#2 - I've been daydreaming about seeing whether I
could get GNUstep ported to plan9, but I'm still curently
way too unfamiliar w/ plan 9 to assess how realistic/possible
that would be - someone else in another thread recently asked:

"If you have gcc on plan 9, will simply compiling the unix code work?"

I'm basically wondering the same thing.


Thanks for the help!

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey wrote:
> 
> Two questions - quite likely naive, so please be kind!
> 
> #1 - How difficult approximately would it be to port a
> more current release of gcc to plan9, say 4.1?

  The gcc source code is pretty messy. But let me ask you
  a different question -- what exactly do you want to
  achieve with gcc ?

> "If you have gcc on plan 9, will simply compiling the unix code work?"

  It might, but IMHO it'll defeat the purpose.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:
> On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey wrote:
> 
>>Two questions - quite likely naive, so please be kind!
>>
>>#1 - How difficult approximately would it be to port a
>>more current release of gcc to plan9, say 4.1?
> 
> 
>   The gcc source code is pretty messy. But let me ask you
>   a different question -- what exactly do you want to
>   achieve with gcc ?
> 

Let me raise my hand.

I want to run MPQC, which can not ever be compiled with 8c. Or one of 
about 1,000 other apps that need gcc. Port one app, solve it once. Port 
gcc, solve it 1,000 times.


> 
>>"If you have gcc on plan 9, will simply compiling the unix code work?"
> 
> 
>   It might, but IMHO it'll defeat the purpose.

no, I don't completely agree. We need gcc for general use, period. 
Unless we like living in a cardboard box in an alley forever.

ron

Re: [9fans] gcc on plan9

[William Josephson]

On Wed, Jun 07, 2006 at 12:50:28PM -0600, Ronald G Minnich wrote:
> no, I don't completely agree. We need gcc for general use, period. 
> Unless we like living in a cardboard box in an alley forever.

Are you mostly concerned about support for gcc language extensions
or about support for things like C++?

Re: [9fans] gcc on plan9

[Ronald G Minnich]

William Josephson wrote:
> On Wed, Jun 07, 2006 at 12:50:28PM -0600, Ronald G Minnich wrote:
> 
>>no, I don't completely agree. We need gcc for general use, period. 
>>Unless we like living in a cardboard box in an alley forever.
> 
> 
> Are you mostly concerned about support for gcc language extensions
> or about support for things like C++?

I hate to say it, but in the scientific computing world, you either do 
gcc compatibility, 100%, or you run gcc, or you don't get used. That's 
it. Many companies we deal with had to do extensive work to their 
compilers to get apps to run, i.e. they had to make them gcc-compatible. 
It's sad, I don't like it, but that's the way it is.

I'm really tired of telling people how nice plan 9 is, then having them 
ask me how to compile xyz, and having to tell them they have to do a 
port. That's pretty much where their interest ends.

But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the 
out-of-kernel picture is not great, since we lack gcc or gcc-compatible 
compilers.


ron

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 02:12:27PM -0600, Ronald G Minnich wrote:
> William Josephson wrote:
> >On Wed, Jun 07, 2006 at 12:50:28PM -0600, Ronald G Minnich wrote:
> >
> >>no, I don't completely agree. We need gcc for general use, period. 
> >>Unless we like living in a cardboard box in an alley forever.
> >
> >
> >Are you mostly concerned about support for gcc language extensions
> >or about support for things like C++?
> 
> I hate to say it, but in the scientific computing world, you either do 
> gcc compatibility, 100%, or you run gcc, or you don't get used. That's 
> it. Many companies we deal with had to do extensive work to their 
> compilers to get apps to run, i.e. they had to make them gcc-compatible. 
> It's sad, I don't like it, but that's the way it is.

  I truly share your sentiment because that's exactly what I hear from
  my customers as well. Now, what's interesting is -- are you talking about
  Fortran scientific apps or something else ? Because if fortran is anywhere
  to be found than surely these guys must use something else rather than
  gcc at least occasionally. After all, up until 2004 fortran support in
  gcc used to be a total joke.

> I'm really tired of telling people how nice plan 9 is, then having them 
> ask me how to compile xyz, and having to tell them they have to do a 
> port. That's pretty much where their interest ends.

  Could you give examples of such apps, or are they internal ?

> But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the 
> out-of-kernel picture is not great, since we lack gcc or gcc-compatible 
> compilers.

  I'm curious. Tell me more. See my earlier question to Latchesar.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:

>   I truly share your sentiment because that's exactly what I hear from
>   my customers as well. Now, what's interesting is -- are you talking about
>   Fortran scientific apps or something else ? Because if fortran is anywhere
>   to be found than surely these guys must use something else rather than
>   gcc at least occasionally. After all, up until 2004 fortran support in
>   gcc used to be a total joke.

It's just that I can't think of a single scientific app that runs on 
Plan 9. Oh, maybe that one Andrey ported. But stuff like nwchem, mpqc, 
NAS PB, the HPCS benchmarks, ... it's a long list.

>   Could you give examples of such apps, or are they internal ?\

some internal. Actually, just go find about any C++ app, or get the R 
framework, and see all the stuff it does ... eek.

ron

Re: [9fans] gcc on plan9

[William Josephson]

On Wed, Jun 07, 2006 at 02:12:27PM -0600, Ronald G Minnich wrote:
> But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the 
> out-of-kernel picture is not great, since we lack gcc or gcc-compatible 
> compilers.

The gcc C extensions are much more tractable than C++,
hence the question.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

William Josephson wrote:
> On Wed, Jun 07, 2006 at 02:12:27PM -0600, Ronald G Minnich wrote:
> 
>>But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the 
>>out-of-kernel picture is not great, since we lack gcc or gcc-compatible 
>>compilers.
> 
> 
> The gcc C extensions are much more tractable than C++,
> hence the question.

good point.

There is some requirement for C++, I have to go back and figure out all 
the places. People use G++ or python or even perl ...

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 12:50:28PM -0600, Ronald G Minnich wrote:
> Roman Shaposhnick wrote:
> >On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey wrote:
> >
> >>Two questions - quite likely naive, so please be kind!
> >>
> >>#1 - How difficult approximately would it be to port a
> >>more current release of gcc to plan9, say 4.1?
> >
> >
> >  The gcc source code is pretty messy. But let me ask you
> >  a different question -- what exactly do you want to
> >  achieve with gcc ?
> >
> 
> Let me raise my hand.

  By all means :-)
 
> I want to run MPQC, which can not ever be compiled with 8c. 

  So, is it mostly a backend or a frontend problem ?

> Or one of about 1,000 other apps that need gcc. 

  Could you, please, elaborate on what exactly these apps
  need from gcc ?

> Port one app, solve it once. Port gcc, solve it 1,000 times.

  I don't really think that with a difference in evironment
  between Linux and Plan9 the later holds true.

> >  It might, but IMHO it'll defeat the purpose.
> 
> no, I don't completely agree. We need gcc for general use, period. 

  Sorry, I just fail to see how porting gcc would help. Hence
  to make this discussion a bit more concrete could you, please,
  be more specific about what exact gcc functionality do you think
  would be beneficial to native Plan9 ?

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:

>   So, is it mostly a backend or a frontend problem ?
all of the above. Just get MPQC (google it) and then try to build it.


>   Could you, please, elaborate on what exactly these apps
>   need from gcc ?

no. There's too long a list for email.


>   I don't really think that with a difference in evironment
>   between Linux and Plan9 the later holds true.

have you looked at the apps?


>   Sorry, I just fail to see how porting gcc would help. Hence
>   to make this discussion a bit more concrete could you, please,
>   be more specific about what exact gcc functionality do you think
>   would be beneficial to native Plan9 ?
gcc compatibility.

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 02:13:48PM -0600, Ronald G Minnich wrote:
> Roman Shaposhnick wrote:
> 
> >  So, is it mostly a backend or a frontend problem ?
> all of the above. Just get MPQC (google it) and then try to build it.

  I'm doing it right now. It looks like a C++ application which means
  that your task of porting it to plan9 will be even more difficult
  than I previously though. It also looks like the sort of C++ they
  use is not strictly speaking ISO STD complaint. But I need more
  time to dig into this.

> >  Could you, please, elaborate on what exactly these apps
> >  need from gcc ?
> 
> no. There's too long a list for email.

  But do you have this list ?

> >  I don't really think that with a difference in evironment
> >  between Linux and Plan9 the later holds true.
> 
> have you looked at the apps?

  If by the apps you mean MPQC -- I'm looking at it right now.
  If by the apps you mean other OpenSource apps, there's a list
  of about 500+ of them I'm looking at on a weekly basis. Most
  of them have a pretty long list of non-trivial dependencies 
  on Linux environment. 
 
> >  Sorry, I just fail to see how porting gcc would help. Hence
> >  to make this discussion a bit more concrete could you, please,
> >  be more specific about what exact gcc functionality do you think
> >  would be beneficial to native Plan9 ?
> gcc compatibility.

  Well, all I can say is -- its a pity that even more resources will
  be spent on proliferating gcc's bad influence on application developers.
  
  I understand that most likely you're doing it as part of your job which
  means that you don't really have a choice.

Thanks,
Roman.

P.S. Is it that even HPC community is so commercialized and time-to-market
oriented these days that there's no light at the end of the tunnel ? Looks
like as far as Plan9 community is concerned, the only place where the 
decisions are not dictated by the mighty VOC is Nemo's research lab. 
Europe vs. USA kinda thing... I don't know...

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:

>   If by the apps you mean MPQC -- I'm looking at it right now.
>   If by the apps you mean other OpenSource apps, there's a list
>   of about 500+ of them I'm looking at on a weekly basis. Most
>   of them have a pretty long list of non-trivial dependencies 
>   on Linux environment. 

IMHO, you know more than I do at this point!

So, what's our problem :-) Is all hope lost?

Is this mess fixable? If so, how?



>   Well, all I can say is -- its a pity that even more resources will
>   be spent on proliferating gcc's bad influence on application developers.

The world  sucks. I could not agree more. Propagating all this gnu stuff 
is depressing, makes me wish I did something else for a living 
sometimes. I sort of watch with amazement as people work on the segment 
layout of their ELF files, and discuss what to inline. arg!

thanks, I think you've educated me (I'm dead serious).

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnik]

Ronald G Minnich wrote:
> IMHO, you know more than I do at this point!
Relatively speaking ;-) I once tried to do the same thing I do with 
these 500+ apps with everything that's
available through the Gentoo portage system. To say that I was surprised 
would be a gross
understatement. :-(

> So, what's our problem :-) Is all hope lost?
> Is this mess fixable? If so, how?
Now that I understand your goal (which is to provide a way for running a 
preselected
set of  HPC apps on a Plan9 system) and I can stop confusing it with 
inventing a magic
G-wand  I'd say that your biggest challenge will be to carefully 
retarget the apps in
question from (L)POSIX/C++ environment. I don't believe its a lost 
cause, but it all
depends on how messy the apss will turn out to be.

I don't know much about the apps, but here's a list of issues I 
personally confronted
while porting Sun Studio C/C++ compiler from Solaris to Linux:

It doesn't matter whether its C, C++ or Fortran --  nowadays its all 
about autotools/libtool
recognizing your system, and let me tell you these guys are *wild*. Case 
in point: when we
first ported our seed C compiler autoconf was convinced that it was a 
PGI compiler running
on an Open?BSD system  -- go figure. Once you get past configuring the 
apps,  every C/C++
compiler gets confronted with two essential interfaces: glibc and 
linker/ELF. For a C compiler
dependency  on ELF is less  of an issues, but for a C++ one its a pretty 
big deal. In fact
we had seriously considered porting Solaris ld to Linux just so that we 
don't have to depend
on GNU ld messing up object files (we ended up fixing GNU ld, but its a 
different story).
Next comes the glibc, which in turn, depends on Linux kernel headers and 
wants to get into
compiler business all the time by providing "kosher"  crt*.o and 
demanding a certain way
of tickling its internals for things like IEEE floating point support to 
work properly.

The biggest problem with all of this is that the way C99 (and portions 
of the C++) standard
are structured makes it impossible to have a properly functioning 
application unless
you have glibc support in certain areas. One of the  reasons GCC can't 
claim
C99 compliance is because glibc sucks (you can find more on that right here:
http://gcc.gnu.org/gcc-4.1/c99status.html).

Now, you say that you're going to use APE and there I have serious 
doubts that things
like FP exception handling and C99 complex will work for you. These two 
proved
to be quite essential for the set of HPC apps I have internally from 
*our* customers.

Now, suppose that you've overcome all of that. What's next ? C++ of course!

C++ with things like templates instantiations in ELF COMDAT sections and 
exception
handling support places lots of additional requirements on how flexible 
linker should
be in handling ELF files. Speaking of which -- do you intend to port ELF 
to Plan9 as well ?

Once you get past codegeneration the glibc will rear its ugly head once 
again. This time
around it'll be about supporting C++ header files which are just there 
to wrap around
standard C headers in the latest and greatest std:: namespace. Of 
course, I'm talking
about things like <cstring> and <cstdlib>. There again you will start 
battling how
gcc configures itself on different systems and how it all can be hooked 
up to APE.
       
Oh, and there's also a question of what to do about MT apps. I'd be very 
curious to
know how would you go about solving it on Plan9 as far as PTHREADS are 
concerned.
Or may be your apps don't use any (which I find hard to believe for an 
HPC market).

That's about it when it comes to the biggies. The sort of things I 
distinctly remember
suffering through on a personal level.

On the application level you still have to tame dependencies on things 
which go beyond
the scope of C99 or ISO C++ standards, but that's a story for another day.
>>   Well, all I can say is -- its a pity that even more resources will
>>   be spent on proliferating gcc's bad influence on application 
>> developers.
>
> The world  sucks. I could not agree more. Propagating all this gnu 
> stuff is depressing, makes me wish I did something else for a living 
> sometimes. I sort of watch with amazement as people work on the 
> segment layout of their ELF files, and discuss what to inline. arg!
>
> thanks, I think you've educated me (I'm dead serious).
    Well, I'm glad my emails weren't in vain. I'm very curious to see 
how far you can go with the approach
you've chosen, and I'd be glad to share more of the porting experience. 
Feel free to drop me emails
on this subject. I've been there and there's a chance I might be able to 
help you guys.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Iruatã Souza (muzgo)]

> (...). Speaking of which -- do you intend to port ELF
> to Plan9 as well ?
>

Static ELF is already ported by Russ.
Dynamic is coming soon.

Iruatã Souza (muzgo)

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 11:24, Roman Shaposhnick wrote:
> On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey wrote:
> > 
> > Two questions - quite likely naive, so please be kind!
> > 
> > #1 - How difficult approximately would it be to port a
> > more current release of gcc to plan9, say 4.1?
> 
>   The gcc source code is pretty messy. But let me ask you
>   a different question -- what exactly do you want to
>   achieve with gcc ?
>

Strictly speaking, gcc's just a means to an end ( for a hypothetical
project which is currently no more than an idle pipe-dream... so
take everything I say with a grain of salt or two ):  I'm really  just 
looking for objective-c support on plan 9; doesn't matter to me 
via which compiler this was provided, but I figure porting gcc to
plan 9 would be easier than somehow talking someone into 
extending 9c with objective-c support.

Why do I want objective-c on plan 9?

I think that plan 9 would make an interesting and appealing base for a
desktop operating system; objective-c and GNUstep is also a  very
interesting and appealing development environment - hey, why not
experiment? Combine the two, and it seems (to me) that a very 
persuasive, light-weight/fast, general purpose desktop and
development environment/platform could potentially be built.


> > "If you have gcc on plan 9, will simply compiling the unix code work?"
> 
>   It might, but IMHO it'll defeat the purpose.
> 

I completely understand, which is why I was hesitent to even open my
mouth on the subject; especially as I'm a mere hobbyist.

I really appreciate plan 9's focus, and agree that it should be maintained.
The whole point of this idea I'm toying with is to ditch the cruft and
luggage of today's linux-based os's.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Corey wrote:

> I really appreciate plan 9's focus, and agree that it should be maintained.
> The whole point of this idea I'm toying with is to ditch the cruft and
> luggage of today's linux-based os's.
> 
> 

Me, I want more Plan 9 users. It's a great kernel, but it's going to 
continue to fall behind if we don't get more people on it.

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 02:16:14PM -0600, Ronald G Minnich wrote:
> Corey wrote:
> 
> >I really appreciate plan 9's focus, and agree that it should be maintained.
> >The whole point of this idea I'm toying with is to ditch the cruft and
> >luggage of today's linux-based os's.
> >
> >
> 
> Me, I want more Plan 9 users. It's a great kernel, but it's going to 
> continue to fall behind if we don't get more people on it.

  Once again: I hope I was able to make my point clear that I'm not
  against the idea in general, but rather I'm very cautios about
  the way it can go.

  That said, however, I feel pretty strong about one thing -- if by
  "getting more people on it" we are going to end up with a Linux-looking
  GNU-based beast that takes a mental asylum patient to support and maintain
  then I urge you to reconsider. If they want Linux they know where to
  find it.

Thanks,
Roman.

P.S. Unfortunately, that's exactly what is going on with Linux desktop
these days. People are hungry for Windows/MacOS but without a license fee.
That in turn twists core UNIX technology so much that you can't recognize
it anymore. Which is a shame... :-(

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:

>   That said, however, I feel pretty strong about one thing -- if by
>   "getting more people on it" we are going to end up with a Linux-looking
>   GNU-based beast that takes a mental asylum patient to support and maintain
>   then I urge you to reconsider. If they want Linux they know where to
>   find it.

point taken.

It's a tough thing to do. And, I agree, Linux seems to all about 
emulating windows nowadays. Gross.

ron

Re: [9fans] gcc on plan9

[lucio]

> It's a tough thing to do. And, I agree, Linux seems to all about 
> emulating windows nowadays. Gross.

A quick philosophical point.  Microsoft/Windows is a religion, in the
sense of an organised hierarchy of authority with a deity (real or
imaginary) on top and the worshippers at the bottom.  The accolytes
are privvy to secrets they use to keep the masses from questioning the
religious dogma that keeps the system going.  Microsoft more or less
stumbled in this position the way Christianity did and adjusted to
suit.

The Red-Hat did the same.  Etc.

Should Plan 9 do the same, wittingly?  I vote against, but
intellectually, not with Darwinian survival of the fittest in mind.

Also, I don't think one can do this rationally, too much depends on
grasping and fulfilling the needs of the underlying community without
compromising authority.

++L

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

Just my view, but I think the same happen to me time ago. At the
risk of opening a flame war, this is what I mean.

After first installing and using Plan 9, I quickly tried to get unix stuff
ported to Plan 9. Then, I came across the "getting started with plan 9"
paper from dmr (don´t remember the title exactly, sorry). In few words, it
was a warning that: Plan 9 is not UNIX.

Then I forced myself to use the native tools for a few days and I saw that
most of the stuff from unix I wanted to use had more appropriate replacements
in the system. Plan9 is spartan and lean, and also very effective.
very much like UNIX was.

I agree that we don´t have too many applications, however, I think that
porting GNUstep could perhaps be an overkill.

For example, GNUstep depends not just on the compiler, but also on many
services you find today on Linux and similar UNIXes. Trying to pull that into
Plan 9 would force you to pull many other stuff as well.

hth

On 6/7/06, Corey <corey_s@qwest.net> wrote:
>
> Two questions - quite likely naive, so please be kind!
>
> #1 - How difficult approximately would it be to port a
> more current release of gcc to plan9, say 4.1?
>
> #2 - I've been daydreaming about seeing whether I
> could get GNUstep ported to plan9, but I'm still curently
> way too unfamiliar w/ plan 9 to assess how realistic/possible
> that would be - someone else in another thread recently asked:
>
> "If you have gcc on plan 9, will simply compiling the unix code work?"
>
> I'm basically wondering the same thing.
>
>
> Thanks for the help!
>
>
>

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 11:57, Francisco J Ballesteros wrote:
> In few words, it
> was a warning that: Plan 9 is not UNIX.
> 

Definitely - and this is what makes Plan 9 so appealing.


> Plan9 is spartan and lean, and also very effective.
> very much like UNIX was.
> 

I like that about plan 9, and I'm very much an advocate of spartan and lean,
as well as focused and well-integrated/holistic.

Objective-C and the base GNUstep library/framework very much themselves 
contain those same attributes: light, efficient, lean.  Conceptually, I think 
obj-c/gnustep running on plan 9 would be pretty enticing.


> For example, GNUstep depends not just on the compiler, but also on many
> services you find today on Linux and similar UNIXes. Trying to pull that into
> Plan 9 would force you to pull many other stuff as well.
> 

Yes, I've considered that - and I agree that it would be difficult and unsavory.

But it would also be temporary, a boot-strap sort of a process. The alien cruft
could be deprecated and replaced over time with natively-built components.

Also, when I talk about considering porting GNUstep, I'm just talking the base/core
framework libraries and whatever could be ported or rewritten easily.

Re: [9fans] gcc on plan9

[rog]

> I like that about plan 9, and I'm very much an advocate of spartan and lean,
> as well as focused and well-integrated/holistic.
> 
> Objective-C and the base GNUstep library/framework very much themselves 
> contain those same attributes: light, efficient, lean.  Conceptually, I think 
> obj-c/gnustep running on plan 9 would be pretty enticing.

i used objective C and nextstep, then openstep quite extensively
for some years. i would never have described either the foundation
kit or the app kit (on which, i presume, gnustep is modelled)
as "light", "efficient" or "lean".
plan 9 was a breath of fresh air after that straitjacket.

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 13:46, rog@vitanuova.com wrote:
> i used objective C and nextstep, then openstep quite extensively
> for some years. i would never have described either the foundation
> kit or the app kit (on which, i presume, gnustep is modelled)
> as "light", "efficient" or "lean".
> plan 9 was a breath of fresh air after that straitjacket.
>

Sure, and think of what Obj-C/FoundationKit is like after using GTK 
or QT or, gasp, MFC. "breath of fresh air" seems appropriate. Guess
it is, of course, all just a matter of perspective.

_If_  one was interested in experimenting in developing an integrated 
graphical desktop environment on plan 9, one would use what - pure C?  
With what higher-level libraries would one use? Or would one write it all 
from scratch? 


 

Re: [9fans] gcc on plan9

[Christoph Lohmann]

Good evening.

Am Wed, 7 Jun 2006 14:07:14 -0700 schrieb "Corey" <corey_s@qwest.net>:

> _If_  one was interested in experimenting in developing an integrated 
> graphical desktop environment on plan 9, one would use what - pure C?  
> With what higher-level libraries would one use? Or would one write it
> all from scratch? 

There is a "integrated graphical desktop environment" on Plan 9, even if
you do not call it like that.

So if you really have the moral and the power to even write a line of
code for a new "integrated graphical desktop environment" on Plan 9, then
it would be done with underlying file servers, where you write "low level"
libraries, for the graphical applications, that in the end do only a
simple write() on some file - nothing else.

Sincerely,

Christoph

Re: [9fans] gcc on plan9

[Rodolfo (kix)]

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

God save us from QT and GTK ;)

2006/6/7, Christoph Lohmann <20h@r-36.net>:
>
> Good evening.
>
> Am Wed, 7 Jun 2006 14:07:14 -0700 schrieb "Corey" <corey_s@qwest.net>:
>
> > _If_  one was interested in experimenting in developing an integrated
> > graphical desktop environment on plan 9, one would use what - pure C?
> > With what higher-level libraries would one use? Or would one write it
> > all from scratch?
>
> There is a "integrated graphical desktop environment" on Plan 9, even if
> you do not call it like that.
>
> So if you really have the moral and the power to even write a line of
> code for a new "integrated graphical desktop environment" on Plan 9, then
> it would be done with underlying file servers, where you write "low level"
> libraries, for the graphical applications, that in the end do only a
> simple write() on some file - nothing else.
>
> Sincerely,
>
> Christoph
>



-- 
Rodolfo García "kix"

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

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 14:25, Rodolfo (kix) wrote:
> God save us from QT and GTK ;)
> 

Will god likewise save us from Rio and Acme?

Is there truly no reasonable middle-ground somewhere?

So either Plan 9 stays totally, strictly, pure, and never leaves
the server rooms and some science labs - or it "apes" 
gnu/linux, and becomes a total mess?

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, Corey <corey_s@qwest.net> wrote:
> On Wednesday 07 June 2006 14:25, Rodolfo (kix) wrote:
> > God save us from QT and GTK ;)
> >
>
> Will god likewise save us from Rio and Acme?
>
> Is there truly no reasonable middle-ground somewhere?
>
> So either Plan 9 stays totally, strictly, pure, and never leaves
> the server rooms and some science labs - or it "apes"
> gnu/linux, and becomes a total mess?
>

The only reason it would never leave server rooms and labs is because
no one who would otherwise use it can find an application on Plan 9
they feel like they couldn't live without.

I get by fine day to day without Plan 9 personally.  I just use it
because it's interesting.

Dave

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Corey wrote:

> So either Plan 9 stays totally, strictly, pure, and never leaves
> the server rooms and some science labs - or it "apes" 
> gnu/linux, and becomes a total mess?
> 
> 

"welcome to hell, kid" -- Wally

ron

Re: [9fans] gcc on plan9

[Lluís Batlle i Rossell]

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

Corey wrote:
> On Wednesday 07 June 2006 14:25, Rodolfo (kix) wrote:
> 
>>God save us from QT and GTK ;)
>>
> 
> 
> Will god likewise save us from Rio and Acme?
In fact I use rio in Linux at my job. And by now I don't use Acme 
because I have to deal with veryawfulcode (lots of very bad indentations 
fruit of many tab/spaces/tab/spaces at code changes, functions more than 
1500 lines long, an unworkable hierarchy of header files...). I agree 
that acme is really pleasant for well-written code. As an example, I 
like surfing plan9's with it. Also my code looks better if it's written 
with acme, but this part is too subjective. :)

Let's wonder why there is plan9port but there is no gcc in plan9.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3311 bytes --]

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, Lluís Batlle i Rossell <viriketo@gmail.com> wrote:
> Corey wrote:
> > On Wednesday 07 June 2006 14:25, Rodolfo (kix) wrote:
> >
> >>God save us from QT and GTK ;)
> >>
> >
> >
> > Will god likewise save us from Rio and Acme?
> In fact I use rio in Linux at my job. And by now I don't use Acme
> because I have to deal with veryawfulcode (lots of very bad indentations
> fruit of many tab/spaces/tab/spaces at code changes, functions more than
> 1500 lines long, an unworkable hierarchy of header files...). I agree
> that acme is really pleasant for well-written code. As an example, I
> like surfing plan9's with it. Also my code looks better if it's written
> with acme, but this part is too subjective. :)
>
> Let's wonder why there is plan9port but there is no gcc in plan9.
>

I think a part of the problem is the momentum that linux got, and
people have been fighting with the pains of migrating from windows
(those that try to use linux as a desktop OS).  Many people got
frustrated with Linux and went to Mac OS X.

I don't see Plan 9 as a desktop OS for sure, but thanks to
virtualization technology (which certainly isn't new), I can run Plan
9 on my desktop in it's own VM and use the bits of Plan 9 that I want
or feel that I need.  P9P also helps here.

I'm not sure if we've got any killer apps to bring people to Plan 9 though.

Mac OS X has the "Ooooh Shiny" effect on people.
Linux had uhm... Apache I guess that helped it get off the ground as a
viable alternative to expensive servers.

So the question is really, what does plan 9 do better that people
actually care about?

I usually don't have a good answer for this question.  I'm not sure
saying "support gcc and all our problems are solved" is a good
approach though.

There's gotta be something we can do the Plan 9 way to WOW people
enough to give it a first or even second look.

As for me... I like operating systems, sometimes I wonder why, but I do.

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

> So the question is really, what does plan 9 do better that people
> actually care about?

I know! I know! :-)

Venti. I just sold Plan 9 services to our local set of linux users. Our
dept. server (a linux box) crashed. I know, they know, but there were
no complete backup for the system. It´s just so simple to manage distributed
resources with Plan 9, that this is just the type of thing to sell.

But anyway, going back to this thread of gcc/etc.etc. Isn´t p9p what
you are seeking for?

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Francisco J Ballesteros wrote:

> Venti. I just sold Plan 9 services to our local set of linux users. Our
> dept. server (a linux box) crashed. I know, they know, but there were
> no complete backup for the system. It´s just so simple to manage 
> distributed
> resources with Plan 9, that this is just the type of thing to sell.

yeah, fossil/venti does get people excited.

> 
> But anyway, going back to this thread of gcc/etc.etc. Isn´t p9p what
> you are seeking for?

no, I want plan 9, not linux tarted up to look like Plan 9. Although p9p 
is sure good stuff.

ron

Re: [9fans] gcc on plan9

[Victor Nazarov]

Ronald G Minnich wrote:

> Francisco J Ballesteros wrote:
>
>> Venti. I just sold Plan 9 services to our local set of linux users. Our
>> dept. server (a linux box) crashed. I know, they know, but there were
>> no complete backup for the system. It´s just so simple to manage 
>> distributed
>> resources with Plan 9, that this is just the type of thing to sell.
>
>
> yeah, fossil/venti does get people excited.
>
>>
>> But anyway, going back to this thread of gcc/etc.etc. Isn´t p9p what
>> you are seeking for?
>
>
> no, I want plan 9, not linux tarted up to look like Plan 9. Although 
> p9p is sure good stuff.
>
> ron
>
What about incorporating Plan9 kernel into Linux kernel? ;) Some steps 
have been already done, I think.
--
Victor

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 03:16:13PM -0700, David Leimbach wrote:
> On 6/7/06, LluМs Batlle i Rossell <viriketo@gmail.com> wrote:
> >Corey wrote:
> >> On Wednesday 07 June 2006 14:25, Rodolfo (kix) wrote:
> >>
> >>>God save us from QT and GTK ;)
> >>>
> >>
> >>
> >> Will god likewise save us from Rio and Acme?
> >In fact I use rio in Linux at my job. And by now I don't use Acme
> >because I have to deal with veryawfulcode (lots of very bad indentations
> >fruit of many tab/spaces/tab/spaces at code changes, functions more than
> >1500 lines long, an unworkable hierarchy of header files...). I agree
> >that acme is really pleasant for well-written code. As an example, I
> >like surfing plan9's with it. Also my code looks better if it's written
> >with acme, but this part is too subjective. :)
> >
> >Let's wonder why there is plan9port but there is no gcc in plan9.
> >
> 
> I think a part of the problem is the momentum that linux got, and
> people have been fighting with the pains of migrating from windows
> (those that try to use linux as a desktop OS).  Many people got
> frustrated with Linux and went to Mac OS X.
> 
> I don't see Plan 9 as a desktop OS for sure,

  Why ? Or better yet -- define "desktop OS". My point is just that
  it seems the Xwindows and WinAPIs are really showing its age when
  it comes to something like true desktop OS of today. And if on Linux
  there's an effort of trying to ditch X altogether and move onto
  something more in line with what we know about desktop today, I see
  no reason for not trying to reinvent Plan OS desktop side in the
  same manner. Granted, I'm not proposing porting anything, but rather
  careful reevaluation of what could be missing.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[quanstro]

On Wed Jun  7 17:07:21 CDT 2006, viriketo@gmail.com wrote:

acme and previously sam has done me well with all manner of badly formatted
and ill-concieved  c, c++, perl, pre-f77 fortran, etc.

perhaps i don't get it, but there's nothing i've seen in other editors that helped
with bad code.  bad code is just as bad in colour -- and harder on the eyes.

> Corey wrote:
> > Will god likewise save us from Rio and Acme?
> In fact I use rio in Linux at my job. And by now I don't use Acme 
> because I have to deal with veryawfulcode (lots of very bad indentations 
> fruit of many tab/spaces/tab/spaces at code changes, functions more than 
> 1500 lines long, an unworkable hierarchy of header files...). I agree 
> that acme is really pleasant for well-written code. As an example, I 
> like surfing plan9's with it. Also my code looks better if it's written 
> with acme, but this part is too subjective. :)

Re: [9fans] gcc on plan9

[Lluís Batlle]

2006/6/8, quanstro@quanstro.net <quanstro@quanstro.net>:
> On Wed Jun  7 17:07:21 CDT 2006, viriketo@gmail.com wrote:
>
> acme and previously sam has done me well with all manner of badly formatted
> and ill-concieved  c, c++, perl, pre-f77 fortran, etc.
Well, mostly I have strict rules about "your fixes must give MINIMAL
changes". So I'm not allowed changing any line (spacing, etc.) if I
the final code doesn't change. According to this rule, through the
years the code became a big mess.
So, I use gvim because I can control quite fine the spacing changes
with Undo/Redo, etc.
I don't think 'acme' would be better than gvim for me in this
situation, but I'm not an "accostumed" user of acme.
>
> perhaps i don't get it, but there's nothing i've seen in other editors that helped
> with bad code.  bad code is just as bad in colour -- and harder on the eyes.
I agree.

Re: [9fans] gcc on plan9

[quanstro]

On Fri Jun  9 08:13:18 CDT 2006, viriketo@gmail.com wrote:
> 2006/6/8, quanstro@quanstro.net <quanstro@quanstro.net>:
> > On Wed Jun  7 17:07:21 CDT 2006, viriketo@gmail.com wrote:
> >
> > acme and previously sam has done me well with all manner of badly formatted
> > and ill-concieved  c, c++, perl, pre-f77 fortran, etc.
> Well, mostly I have strict rules about "your fixes must give MINIMAL
> changes". So I'm not allowed changing any line (spacing, etc.) if I
> the final code doesn't change. According to this rule, through the
> years the code became a big mess.
> So, I use gvim because I can control quite fine the spacing changes
> with Undo/Redo, etc.
> I don't think 'acme' would be better than gvim for me in this
> situation, but I'm not an "accostumed" user of acme.

acme has full undo/redo.  but more to the point, why don't you write a script to 
strip whitespace and then diff your ws-stripped file against the ws-stripped baseline 
file.  then apply the diff script to the original files?

- erik

Re: [9fans] gcc on plan9

[Lluís Batlle]

2006/6/9, quanstro@quanstro.net <quanstro@quanstro.net>:
> On Fri Jun  9 08:13:18 CDT 2006, viriketo@gmail.com wrote:
>
> acme has full undo/redo.  but more to the point, why don't you write a script to
> strip whitespace and then diff your ws-stripped file against the ws-stripped baseline
> file.  then apply the diff script to the original files?
That's what I do if I finally break the whitespaces. But I'll think
about it being my normal-way-of-working.

By now today I've started forcing me to use acme. In a few days I'll
decide what's better. :)
We'll see.

Thanks!

Re: [9fans] gcc on plan9

[geoff]

I use f2c when I need to compile Fortran (or, more likely, Ratfor).
Have GNU extended Fortran too?  Or do you need to compile programs
that make use of features added to Fortran by later standards (though
I'm not sure that GNU Fortran will help here)?

I guess I don't see what's so offensive about rio and acme.  A hazard
is that once one starts adding things to attract novice users (e.g.,
shiney things) or people who are used to some particular (l)unix
configuration (e.g., windows managers, graphical toolkits, the GNU
world), the resulting system will be bigger, slower and clumsier.  If
you use gcc routinely, you lose the speed of 8c.  As an example of the
cumulative effect of such accretion, a friend reported compiling a Red
Hat kernel from scratch recently and it only took about an hour (vs.
the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
seconds to compile 9pc on oldish PC hardware today).

It may not be feasible, for example due to gcc's asm constructs, but
it would seem more satisfying to write a gcc-to-c preprocessor.  Of
course that doesn't help with C++; if only we had a Cfront for current
C++.

Re: [9fans] gcc on plan9

[Steve Simon]

>  ... if only we had a Cfront for current
> C++.

Many people have told me that cfront is just not up to the job,
but can somone take the time to elaborate? What is it about
modern C++ that makes cfront unusable? I can believe it has
been left behind but could it not be given some help to catch up?

I am not trolling, I am a C programmer and not a C++ one so its
not obvious to me.

-Steve

Re: [9fans] gcc on plan9

[Bakul Shah]

> >  ... if only we had a Cfront for current
> > C++.
> 
> Many people have told me that cfront is just not up to the job,
> but can somone take the time to elaborate? What is it about
> modern C++ that makes cfront unusable? I can believe it has
> been left behind but could it not be given some help to catch up?

Templates are the biggest change but the C++ standard defines
a much larger language than what cfront implements.  Starting
from scratch may be cleaner and faster but who'd do it.

Re: [9fans] gcc on plan9

[geoff]

The last paragraph of the Wikipedia entry for Cfront has a plausible
explanation.  In short, exceptions were the straw that broke the
camel's back.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Steve Simon wrote:

> Many people have told me that cfront is just not up to the job,

it was never that satisfying an experience. We were all pretty happy 
when the native C++ compilers showed up -- er, well, as happy as you can 
be with C++, that is.

ron

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Steve Simon wrote:
>
> > Many people have told me that cfront is just not up to the job,
>
> it was never that satisfying an experience. We were all pretty happy
> when the native C++ compilers showed up -- er, well, as happy as you can
> be with C++, that is.
>
> ron
>

it's somewhat funny that now the best C++ compilers in existence are
pretty much CFront-like again then isn't it? :-)

Re: [9fans] gcc on plan9

[Ronald G Minnich]

David Leimbach wrote:

> it's somewhat funny that now the best C++ compilers in existence are
> pretty much CFront-like again then isn't it? :-)

yes, maybe the approach worked, but cfront sucked. I don't know.

ron

Re: [9fans] gcc on plan9

[andrey mirtchovski]

> it would seem more satisfying to write a gcc-to-c preprocessor.

even that doesn't always help. observe the following result from such
preprocessing (which caused 8c to choke, having set the maximum length
of a line of C code to be no greater than 32K characters):

http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/ffmpeg.gif

Re: [9fans] gcc on plan9

[geoff]

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

That is grotesque, but I suspect that ken's compilers could be made to
handle arbitrarily-long input lines without too much effort, based on
related work I've done in the past.

[-- Attachment #2: Type: message/rfc822, Size: 3427 bytes --]

From: "andrey mirtchovski" <mirtchovski@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] gcc on plan9
Date: Wed, 7 Jun 2006 17:15:32 -0600
Message-ID: <14ec7b180606071615m7791cda6m6374347c3b5f797e@mail.gmail.com>

> it would seem more satisfying to write a gcc-to-c preprocessor.

even that doesn't always help. observe the following result from such
preprocessing (which caused 8c to choke, having set the maximum length
of a line of C code to be no greater than 32K characters):

http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/ffmpeg.gif

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 05:15:32PM -0600, andrey mirtchovski wrote:
> >it would seem more satisfying to write a gcc-to-c preprocessor.
> 
> even that doesn't always help. observe the following result from such
> preprocessing (which caused 8c to choke, having set the maximum length
> of a line of C code to be no greater than 32K characters):
> 
> http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/ffmpeg.gif

  FFmpeg! My other recreational project ;-) But I thought somebody
  did port it already... am I mistaken?

Thanks,
Roman.

Re: [9fans] gcc on plan9

[andrey mirtchovski]

i got it to compile but did not write a driver to display anything on
rio. it was done as part of an attempt to get mplayer on plan9, but i
was told i had more important things to do and by the time i was done
doing them i had become too old and didn't have the strength to work
on that pile of crap anymore.

thanks to venti i still have the sources taking space in my home directory :)

Re: [9fans] gcc on plan9

[andrey mirtchovski]

umm, that's in reply to Roman's ffmpeg message.

On 6/9/06, andrey mirtchovski <mirtchovski@gmail.com> wrote:
> i got it to compile but did not write a driver to display anything on
> rio. it was done as part of an attempt to get mplayer on plan9, but i
> was told i had more important things to do and by the time i was done
> doing them i had become too old and didn't have the strength to work
> on that pile of crap anymore.
>
> thanks to venti i still have the sources taking space in my home directory :)
>

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 03:26:39PM -0600, andrey mirtchovski wrote:
> i got it to compile but did not write a driver to display anything on
> rio. it was done as part of an attempt to get mplayer on plan9, but i
> was told i had more important things to do and by the time i was done
> doing them i had become too old and didn't have the strength to work
> on that pile of crap anymore.

  MPlayer would be the wrong way to go -- its too big and bloated for
  my taste. Now, ffmpeg, on the other hand is promising. I'd start with
  ffplay and go from there.

> thanks to venti i still have the sources taking space in my home directory 
> :)

  Would it be possible to send me a diff ?
 
Thanks,
Roman.

Re: [9fans] gcc on plan9

[andrey mirtchovski]

> Would it be possible to send me a diff ?

i'll send you a tarball privately. everything up to libavcodec
compiles, and i have a skeleton 9play.c which should implement the
player...

Re: [9fans] gcc on plan9

[andrey mirtchovski]

> everything up to libavcodec
> compiles

i meant up to and including.

Re: [9fans] gcc on plan9

["Nils O. Selåsdal"]

Roman Shaposhnick wrote:
> On Fri, Jun 09, 2006 at 03:26:39PM -0600, andrey mirtchovski wrote:
>> i got it to compile but did not write a driver to display anything on
>> rio. it was done as part of an attempt to get mplayer on plan9, but i
>> was told i had more important things to do and by the time i was done
>> doing them i had become too old and didn't have the strength to work
>> on that pile of crap anymore.
> 
>   MPlayer would be the wrong way to go -- its too big and bloated for
>   my taste. Now, ffmpeg, on the other hand is promising. I'd start with
>   ffplay and go from there.

Or even lighter ?
http://cm.bell-labs.com/sources/contrib/fgb/mpg.tgz

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

I don't understand why is all that fuss about the gcc port. If you don't
like it, don't use it. Few of the current Plan9 users are going to use it.
But if the gcc port brings more developers to Plan9, I don't see how that
can be bad. 

Thanks,
	Lucho

On Wed, Jun 07, 2006 at 04:04:27PM -0700, geoff@collyer.net said:
> I use f2c when I need to compile Fortran (or, more likely, Ratfor).
> Have GNU extended Fortran too?  Or do you need to compile programs
> that make use of features added to Fortran by later standards (though
> I'm not sure that GNU Fortran will help here)?
> 
> I guess I don't see what's so offensive about rio and acme.  A hazard
> is that once one starts adding things to attract novice users (e.g.,
> shiney things) or people who are used to some particular (l)unix
> configuration (e.g., windows managers, graphical toolkits, the GNU
> world), the resulting system will be bigger, slower and clumsier.  If
> you use gcc routinely, you lose the speed of 8c.  As an example of the
> cumulative effect of such accretion, a friend reported compiling a Red
> Hat kernel from scratch recently and it only took about an hour (vs.
> the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
> seconds to compile 9pc on oldish PC hardware today).
> 
> It may not be feasible, for example due to gcc's asm constructs, but
> it would seem more satisfying to write a gcc-to-c preprocessor.  Of
> course that doesn't help with C++; if only we had a Cfront for current
> C++.

Re: [9fans] gcc on plan9

[geoff]

The argument `if you don't like it, don't use it', is how PL/I, C++,
gcc and Linux got to be huge.  The fallacy in the argument is that
adding complexity and bulk to anything makes it harder to comprehend
and slower to use (not to mention less elegant).  Manuals get thicker,
it's harder to find what you want and sometimes you have to learn
about things just to avoid them successfully.  There get to be
unintended interactions between the parts.  In software, layers (thus
slowness and bulk) tend to accrete.  Then there are hacks (e.g.,
shared libraries) to try to ameliorate the bloat.

Is Linux really any better for having Gnome *and* KDE, both layered on
top of X libraries, and a raft of duelling applications written for
each?  It reminds me of the Unix Window System Wars of the 1980's,
when people thought (or pretended to) that it *really mattered* if
your windows had drop shadows or 3D effects on the corners.

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

We have to choose between having clean system that is used by handful  
of people, or slightly dirtier one (but still better than Linux for  
example) that can attract more users.

I don't think the Plan9 community has the resources (both in numbers  
and quality) to continue the development. We need fresh blood.

Thanks,
	Lucho

On Jun 7, 2006, at 6:53 PM, geoff@collyer.net wrote:

> The argument `if you don't like it, don't use it', is how PL/I, C++,
> gcc and Linux got to be huge.  The fallacy in the argument is that
> adding complexity and bulk to anything makes it harder to comprehend
> and slower to use (not to mention less elegant).  Manuals get thicker,
> it's harder to find what you want and sometimes you have to learn
> about things just to avoid them successfully.  There get to be
> unintended interactions between the parts.  In software, layers (thus
> slowness and bulk) tend to accrete.  Then there are hacks (e.g.,
> shared libraries) to try to ameliorate the bloat.
>
> Is Linux really any better for having Gnome *and* KDE, both layered on
> top of X libraries, and a raft of duelling applications written for
> each?  It reminds me of the Unix Window System Wars of the 1980's,
> when people thought (or pretended to) that it *really mattered* if
> your windows had drop shadows or 3D effects on the corners.
>

Re: [9fans] gcc on plan9

[quanstro]

On Wed Jun  7 20:08:54 CDT 2006, lionkov@lanl.gov wrote:
> We have to choose between having clean system that is used by handful  
> of people, or slightly dirtier one (but still better than Linux for  
> example) that can attract more users.
> 
> I don't think the Plan9 community has the resources (both in numbers  
> and quality) to continue the development. We need fresh blood.

thanks for insulting everyone here.  i simply don't agree that the quality
of programmers working on plan 9 is lacking.  from what i've seen it's top
shelf.

- erik

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> On Wed Jun  7 20:08:54 CDT 2006, lionkov@lanl.gov wrote:
> > We have to choose between having clean system that is used by handful
> > of people, or slightly dirtier one (but still better than Linux for
> > example) that can attract more users.
> >
> > I don't think the Plan9 community has the resources (both in numbers
> > and quality) to continue the development. We need fresh blood.
>
> thanks for insulting everyone here.  i simply don't agree that the quality
> of programmers working on plan 9 is lacking.  from what i've seen it's top
> shelf.
>
> - erik
>
I think you may have zoomed in on the wrong interpretation of his
parenthesis.  I took it as  "there are good programmers in terms of
quality in the plan 9 community, but not enough."

Dave

Re: [9fans] gcc on plan9

[quanstro]

 think you're right.

i am a charter member of the "shoot, ready, aim" school of email reading.

☺ erik

On Thu Jun  8 10:03:29 CDT 2006, leimy2k@gmail.com wrote:
> On 6/7/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > On Wed Jun  7 20:08:54 CDT 2006, lionkov@lanl.gov wrote:
> > > We have to choose between having clean system that is used by handful
> > > of people, or slightly dirtier one (but still better than Linux for
> > > example) that can attract more users.
> > >
> > > I don't think the Plan9 community has the resources (both in numbers
> > > and quality) to continue the development. We need fresh blood.
> >
> > thanks for insulting everyone here.  i simply don't agree that the quality
> > of programmers working on plan 9 is lacking.  from what i've seen it's top
> > shelf.
> >
> > - erik
> >
> I think you may have zoomed in on the wrong interpretation of his
> parenthesis.  I took it as  "there are good programmers in terms of
> quality in the plan 9 community, but not enough."
> 
> Dave

Re: [9fans] gcc on plan9

[geoff]

That's the tricky bit: values of `slightly' in `slightly dirtier' vary
widely.  My value might be epsilon or zero; others obviously have huge
tolerance for rubbish.  I'm not convinced that the system has to be
made dirtier at all to attract users.  Perhaps changes are necessary,
but I don't see virtue in dirt.

> We need fresh blood.

I'm willing to try sacrificing goats but it hasn't work very well in
the past.  ☺

I'm not sure what the answer is, but I think it's got more to do with
educating people and getting them to write more-portable code, at
least in the long term.  Why are numerical programs dependent on
obscure gcc extensions?

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

Who is going to make the changes then? Do you think the system is  
perfect and there is nothing that can be made better?

	Lucho

On Jun 7, 2006, at 7:22 PM, geoff@collyer.net wrote:

> That's the tricky bit: values of `slightly' in `slightly dirtier' vary
> widely.  My value might be epsilon or zero; others obviously have huge
> tolerance for rubbish.  I'm not convinced that the system has to be
> made dirtier at all to attract users.  Perhaps changes are necessary,
> but I don't see virtue in dirt.
>
>> We need fresh blood.
>
> I'm willing to try sacrificing goats but it hasn't work very well in
> the past.  ☺
>
> I'm not sure what the answer is, but I think it's got more to do with
> educating people and getting them to write more-portable code, at
> least in the long term.  Why are numerical programs dependent on
> obscure gcc extensions?
>

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 07:25:17PM -0600, Latchesar Ionkov wrote:
> Do you think the system is  
> perfect and there is nothing that can be made better?

  No. But porting and/or imitating even less perfect systems
  should be frowned upon, not cheered.

  In your particular case, not that I understand the reasons 
  for what you're doing I'm with you, but not because it is
  going to add elegance to an already elegant system, but
  because it might be a first step in demonstrating that investing
  in it and retargeting applications to run on it natively
  could have high benefits for users themselves. As of now, they
  probably do not have any convincing arguments to consider Plan9 
  as a platform. Once they do, my hope is they will invest time
  and energy in educating themselves in how this system is structured
  instead of blindly using the gcc crutch.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 02:21:39PM -0700, Roman Shaposhnick wrote:
> On Wed, Jun 07, 2006 at 07:25:17PM -0600, Latchesar Ionkov wrote:
> > Do you think the system is  
> > perfect and there is nothing that can be made better?
> 
>   No. But porting and/or imitating even less perfect systems
>   should be frowned upon, not cheered.
> 
>   In your particular case, not that I understand the reasons 
                               ^ 
			        \ this, of course, was supposed
				  to be "now".

Thanks,
Roman.

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, geoff@collyer.net <geoff@collyer.net> wrote:
> That's the tricky bit: values of `slightly' in `slightly dirtier' vary
> widely.  My value might be epsilon or zero; others obviously have huge
> tolerance for rubbish.  I'm not convinced that the system has to be
> made dirtier at all to attract users.  Perhaps changes are necessary,
> but I don't see virtue in dirt.

I'm a firm believer in applications that keep newbies away from the
scary, more advanced bits.  Mac OS X has been successful in keeping
grandma away from the prompt, but it's still a unix underneath.
People who want the unix bits can get at them, and do reasonable
things with it.

>
> > We need fresh blood.
>
> I'm willing to try sacrificing goats but it hasn't work very well in
> the past.  ☺

I guess I'll put my "tools" away then...

>
> I'm not sure what the answer is, but I think it's got more to do with
> educating people and getting them to write more-portable code, at
> least in the long term.  Why are numerical programs dependent on
> obscure gcc extensions?
>
>

Honestly, I don't know that Plan 9 can easily absorb a lot of the
programs that are already out there.  I also don't think that's really
so bad.  We're different...  it probably always makes sense to port
some programs from unix that are useful, but it probably doesn't make
any sense to port them all, especially when they don't take advantage
of the nice system we've got.

Dave

Re: [9fans] gcc on plan9

[quanstro]

On Thu Jun  8 10:01:01 CDT 2006, leimy2k@gmail.com wrote:
> >
> > > We need fresh blood.
> >
> > I'm willing to try sacrificing goats but it hasn't work very well in
> > the past.  ☺
> 
> I guess I'll put my "tools" away then...

not so fast.  it's chickens.  chickens and old PDPs.

- erik

[9fans] quantity vs. quality

[Lyndon Nerenberg]

On Jun 7, 2006, at 6:07 PM, Latchesar Ionkov wrote:

> I don't think the Plan9 community has the resources (both in  
> numbers and quality) to continue the development. We need fresh blood.

No, we need fresh ideas.  An infinite number of monkeys turning Plan  
9 into Linux is not progress.

The latest copy of login (the Usenix newsletter) has an editorial  
lamenting how UNIX just doesn't fit the current one-user-one-machine  
paradigm we see today, and how we need to re-think how things are  
done in this regard.  Yet Plan 9 has already been doing this for over  
a decade.

Plan 9's "future" is in guiding the UNIX community forward, not in  
regressing back to what spawned it in the first place.  And I  
sincerely hope that doesn't happen by having Plan 9 be adopted  
wholesale by the masses, for that would (sooner or later) see the end  
of research and innovation for the sake of not breaking all the  
currently running apps, which is what caused UNIX to start growing  
mold.  I would much rather see Plan 9 stay small and mostly ignored,  
since that's how it will remain agile and pliable.  It's the *ideas*  
from Plan 9 (e.g. the servers, namespaces) that will help the masses  
morph their current environment into something suitable for the 21st  
century.

--lyndon

Re: [9fans] quantity vs. quality

[Dan Cross]

On Wed, Jun 07, 2006 at 06:39:42PM -0700, Lyndon Nerenberg wrote:
> Plan 9's "future" is in guiding the UNIX community forward, not in  
> regressing back to what spawned it in the first place.  And I  
> sincerely hope that doesn't happen by having Plan 9 be adopted  
> wholesale by the masses, for that would (sooner or later) see the end  
> of research and innovation for the sake of not breaking all the  
> currently running apps, which is what caused UNIX to start growing  
> mold.  I would much rather see Plan 9 stay small and mostly ignored,  
> since that's how it will remain agile and pliable.  It's the *ideas*  
> from Plan 9 (e.g. the servers, namespaces) that will help the masses  
> morph their current environment into something suitable for the 21st  
> century.

I concur.  One has to ask the question, *why* does one want to attract
new users to Plan 9?  It would take many man-centuries of effort to get
an environment as rich (for the end-user) as that provided by the
mainstream Unices right now.  And what would be the point?  As many
have noted, it would lead to increased complexity, bloat, and decreased
quality on what is otherwise a pretty clean and high quality system.
Plan 9 would, at that point, cease to be Plan 9 and turn into something
else.  I don't particularly want that, just as I don't really want to
add a lot of new ``features'' to C: if I want C++, Java, C#, or Ruby, I
know where to get them.  Similarly, if I want Unix, I know where to get
it.

Instead, I'd like to go back to basics and use Plan 9 as a clean,
conceptually pure prototype for a new Unix-like system.  Let's take the
good ideas from Plan 9, and a current BSD kernel (probably the FreeBSD
one), a current Unix user-land, an axe, and go to town like Charles did
with SunOS 4 back in the day.  For that matter, throw in some of the
good ideas from VSTa (now FMI/OS?  They seem to be regressing: from
their Wiki's page on `Current Work': ``working on getting switching to
posix style error numbers instead of strings. done''  Great...), EMAS,
TOPS-20, VMS, Multics, QNX, etc.  (Yes! VMS had some good ideas!  Like
a standardized calling convention that made it possible to call modules
from any number of languages!  20 years ago!  Stick THAT in your ELF
and smoke it!)  But in general, you know, look back at history and add
in some of those things that were good ideas and got lost in the sands
of time but which will get reinvented two years from now, badly,
because no one thinks to do any research before starting on their work
anymore.  At least, not in computer science....

Of course, that will never happen, and Geoff is right: it's mostly an
issue with education and defeating incorrect or outdated perceptions (I
get physically ill when I hear about ``efficiency'' these days.  Yeah,
like your GCC extension to pack struct's is *so* much more efficient on
a 3 GHz machine than code to pack it or unpack it from a bytestream.
You spend more time porting it to a new platform than you ever did
writing and debugging once, and running an arbitrary number of times,
the byte packing code).  Too bad the example a beginning programmer
sees now is the cess pool of open source cruft instead of well-written
code.


	- Dan C.

Re: [9fans] quantity vs. quality

[Joel Salomon]

On 6/7/06, Dan Cross <cross@math.psu.edu> wrote:
> if I want C++, Java, C#, or Ruby, I know where to get them.

You know where to find a standards-compliant C++ compiler?  ☺

--Joel

Re: [9fans] quantity vs. quality

[Roman Shaposhnik]

Joel Salomon wrote:
> On 6/7/06, Dan Cross <cross@math.psu.edu> wrote:
>> if I want C++, Java, C#, or Ruby, I know where to get them.
>
> You know where to find a standards-compliant C++ compiler?  ☺
Which standard ? After all, 2008(9) one is downright scary :-(

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 11:05:12PM -0400, Dan Cross wrote:
> Too bad the example a beginning programmer
> sees now is the cess pool of open source cruft instead of well-written
> code.

  And that would be the second most useful thing about Plan 9 -- its 
  source code as a literature for educating oneself how the code is 
  supposed to be written.

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[David Leimbach]

On 6/9/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Wed, Jun 07, 2006 at 11:05:12PM -0400, Dan Cross wrote:
> > Too bad the example a beginning programmer
> > sees now is the cess pool of open source cruft instead of well-written
> > code.
>
>   And that would be the second most useful thing about Plan 9 -- its
>   source code as a literature for educating oneself how the code is
>   supposed to be written.
>
> Thanks,
> Roman.

Except /sys/src/9/pc/pci.c that says it badly needs to be rewritten.
Maybe a slightly less Kool-Aid drinking way to approach this would be
to say "code that needs help is better marked, and there's less of
that?"

Then again.  I've not personally audited the whole system, and it's
not clear that I have the qualifications to say that Plan 9's source
is better than other systems.

There's a lot of "belief" here that I think is "fundamentally"
dangerous... as with anything.

I say this partially tongue-in-cheek.  I think sometimes people don't
question a thing because they don't want to seem unpopular to the
group they're speaking to :-).  I think that's wrong.

Then again maybe I'm just paranoid.

Re: [9fans] quantity vs. quality

[quanstro]

On Fri Jun  9 17:45:21 CDT 2006, leimy2k@gmail.com wrote:

> Except /sys/src/9/pc/pci.c that says it badly needs to be rewritten.
> Maybe a slightly less Kool-Aid drinking way to approach this would be
> to say "code that needs help is better marked, and there's less of
> that?"

i've never worked on or looked at the source code of any significant
program or kernel that didn't have some functions that either claim 
to need or actually need "massive rewrites".  

> Then again.  I've not personally audited the whole system, and it's
> not clear that I have the qualifications to say that Plan 9's source
> is better than other systems.

going only on the theory that deleted code is debugged code, plan 9
is likely has fewer problems and unintended consequences than unix
clones.

a fundamental mistake of linux-think is that anytime a function is
known to have limitations, fixing those limitations is a priori considered
better than not.  many times, i think this boils down to local optimizations
that result in global pessimization.

> 
> There's a lot of "belief" here that I think is "fundamentally"
> dangerous... as with anything.

belief is important.  where would the catholic church be without it? ☺
if we do not believe that plan 9 is good, we'll all use something else.

- erik

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

Another example is using emalloc in libraries. I agree that it is  
much simpler to just give up when there is not enough memory (which  
is also not very likely case), but is that how the code is supposed  
to be written if you are not doing research?

Thanks,
	Lucho

On Jun 9, 2006, at 4:44 PM, David Leimbach wrote:

> On 6/9/06, Roman Shaposhnick <rvs@sun.com> wrote:
>> On Wed, Jun 07, 2006 at 11:05:12PM -0400, Dan Cross wrote:
>> > Too bad the example a beginning programmer
>> > sees now is the cess pool of open source cruft instead of well- 
>> written
>> > code.
>>
>>   And that would be the second most useful thing about Plan 9 -- its
>>   source code as a literature for educating oneself how the code is
>>   supposed to be written.
>>
>> Thanks,
>> Roman.
>
> Except /sys/src/9/pc/pci.c that says it badly needs to be rewritten.
> Maybe a slightly less Kool-Aid drinking way to approach this would be
> to say "code that needs help is better marked, and there's less of
> that?"
>
> Then again.  I've not personally audited the whole system, and it's
> not clear that I have the qualifications to say that Plan 9's source
> is better than other systems.
>
> There's a lot of "belief" here that I think is "fundamentally"
> dangerous... as with anything.
>
> I say this partially tongue-in-cheek.  I think sometimes people don't
> question a thing because they don't want to seem unpopular to the
> group they're speaking to :-).  I think that's wrong.
>
> Then again maybe I'm just paranoid.

Re: [9fans] quantity vs. quality

[quanstro]

've written many production systems this way.  i never once had a malloc
failure that was not a result of a catastrophic bug or h/w failure.

except in the case where you know you might be requesting an unreasonable
amount of memory, i have always thought that it makes more sense to limit
the number of failure states by just quitting when malloc fails.  i want my
programs to be as deterministic as possible. i would much rather have them
die than get into some untested failure state. (does any project that tries
to recover from malloc failure actually test failure at each recovery point?)

the current fad is c++ exceptions.  the idea seems okay, but the programs
i know that make use of c++ this way (mozilla comes to mind) do not
seem to be very stable or reliable.

- erik

On Fri Jun  9 17:53:03 CDT 2006, lionkov@lanl.gov wrote:
> Another example is using emalloc in libraries. I agree that it is  
> much simpler to just give up when there is not enough memory (which  
> is also not very likely case), but is that how the code is supposed  
> to be written if you are not doing research?
> 
> Thanks,
> 	Lucho

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

There are cases when you want to leave the output of the program in  
consistent state before you die (and you don't need extra memory to  
achieve that consistency). Or even if the program cannot continue its  
work, it would rather lurk around and wait for somebody to rescue it  
instead of just dying. And in cases like that you just cannot use  
libraries that call sysfatal.

Thanks,
	Lucho

On Jun 9, 2006, at 4:55 PM, quanstro@quanstro.net wrote:

> 've written many production systems this way.  i never once had a  
> malloc
> failure that was not a result of a catastrophic bug or h/w failure.
>
> except in the case where you know you might be requesting an  
> unreasonable
> amount of memory, i have always thought that it makes more sense to  
> limit
> the number of failure states by just quitting when malloc fails.  i  
> want my
> programs to be as deterministic as possible. i would much rather  
> have them
> die than get into some untested failure state. (does any project  
> that tries
> to recover from malloc failure actually test failure at each  
> recovery point?)
>
> the current fad is c++ exceptions.  the idea seems okay, but the  
> programs
> i know that make use of c++ this way (mozilla comes to mind) do not
> seem to be very stable or reliable.
>
> - erik
>
> On Fri Jun  9 17:53:03 CDT 2006, lionkov@lanl.gov wrote:
>> Another example is using emalloc in libraries. I agree that it is
>> much simpler to just give up when there is not enough memory (which
>> is also not very likely case), but is that how the code is supposed
>> to be written if you are not doing research?
>>
>> Thanks,
>> 	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

if you take that view, then you can't use paging because the
kernel might kill your process off on overcommit.

i'm not sure i understand how malloc failure can be a common
enough event that it needs to be handled.

i have never seen malloc failure on a production system where
recovery was possible; i have seen some memory corruption that
led to malloc failure, but there's no recovering from that.

what is the senerio you're thinking of where malloc could fail
and you can recover?

- erik

On Fri Jun  9 18:23:09 CDT 2006, lionkov@lanl.gov wrote:
> There are cases when you want to leave the output of the program in  
> consistent state before you die (and you don't need extra memory to  
> achieve that consistency). Or even if the program cannot continue its  
> work, it would rather lurk around and wait for somebody to rescue it  
> instead of just dying. And in cases like that you just cannot use  
> libraries that call sysfatal.
> 
> Thanks,
> 	Lucho

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

On Fri, Jun 09, 2006 at 06:29:37PM -0500, quanstro@quanstro.net said:
> if you take that view, then you can't use paging because the
> kernel might kill your process off on overcommit.

Or you should disable the overcommit (if possible).

> i'm not sure i understand how malloc failure can be a common
> enough event that it needs to be handled.

It is not only malloc failure, grep the plan9 libraries for sysfatal.

> i have never seen malloc failure on a production system where
> recovery was possible; i have seen some memory corruption that
> led to malloc failure, but there's no recovering from that.
> 
> what is the senerio you're thinking of where malloc could fail
> and you can recover?


Let's say you have a fossil like file server and you cannot malloc memory to
process new requests. Do you want to flush the data buffers back to the disk
before you die, you you want to die in some library without any flushing.

Or you have a file server that keeps some non-file server related state in
memory. The unability to serve any more requests is fine as long as it can
start serving them at some point later when there is more memory. The dying
is not acceptible because the data kept in the memory is important.

Thanks,
	Lucho

> 
> - erik
> 
> On Fri Jun  9 18:23:09 CDT 2006, lionkov@lanl.gov wrote:
> > There are cases when you want to leave the output of the program in  
> > consistent state before you die (and you don't need extra memory to  
> > achieve that consistency). Or even if the program cannot continue its  
> > work, it would rather lurk around and wait for somebody to rescue it  
> > instead of just dying. And in cases like that you just cannot use  
> > libraries that call sysfatal.
> > 
> > Thanks,
> > 	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

On Fri Jun  9 18:48:44 CDT 2006, lucho@gmx.net wrote:
> > 
> > what is the senerio you're thinking of where malloc could fail
> > and you can recover?
> 
> 
> Let's say you have a fossil like file server and you cannot malloc memory to
> process new requests. Do you want to flush the data buffers back to the disk
> before you die, you you want to die in some library without any flushing.

have you had a problem with fossil failing in this way?

i'm not saying you allocate memory like crazy and don't worry about running
out of memory.  i'm sure that fossil is very careful about allocating memory
for requests.
> 
> Or you have a file server that keeps some non-file server related state in
> memory. The unability to serve any more requests is fine as long as it can
> start serving them at some point later when there is more memory. The dying
> is not acceptible because the data kept in the memory is important.
 
i'm skeptical that this is a real-world problem.  i've not run out of memory
without hosing the system to the point where it needed to be rebooted.

worse, all these failure modes need to be tested if this is production code.

how many times have you seen the comment
	// client isn't going to check the return code, anyway
	sysfatal("out of memory");
or similar?  i'm pretty sure these comments are written be folks who've been
bitten by untested or inconsistant error recovery code.

- erik

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net wrote:
> > Or you have a file server that keeps some non-file server related state in
> > memory. The unability to serve any more requests is fine as long as it can
> > start serving them at some point later when there is more memory. The dying
> > is not acceptible because the data kept in the memory is important.
>  
> i'm skeptical that this is a real-world problem.  i've not run out of memory
> without hosing the system to the point where it needed to be rebooted.
> 
> worse, all these failure modes need to be tested if this is production code.

  I believe it is to be a crucial issue here. True, what Latchesar is after
  is a fine goal, its just that I'm yet to see a production system where
  it can save you from a bigger trouble. May be I've been exceptionally
  unlucky, but that's a reality -- if you truly run out of memory you're
  screwed. Your escape strategies don't work, worse yet they are *very*
  likely to fail in the manner that you don't except in the layer that
  you have no knowledge about. 

  Consider this -- what's worse: a fossil server that died and lost some
  of the requests or a server that tried to recover and committed random
  junk ?

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

You are concentrating too much on the particular example I gave (emalloc)
and not on the issue of exiting from a library. I don't think it is a
library job to decide whether the application should die or not.

On Fri, Jun 09, 2006 at 05:10:24PM -0700, Roman Shaposhnick said:
> On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net wrote:
> > > Or you have a file server that keeps some non-file server related state in
> > > memory. The unability to serve any more requests is fine as long as it can
> > > start serving them at some point later when there is more memory. The dying
> > > is not acceptible because the data kept in the memory is important.
> >  
> > i'm skeptical that this is a real-world problem.  i've not run out of memory
> > without hosing the system to the point where it needed to be rebooted.
> > 
> > worse, all these failure modes need to be tested if this is production code.
> 
>   I believe it is to be a crucial issue here. True, what Latchesar is after
>   is a fine goal, its just that I'm yet to see a production system where
>   it can save you from a bigger trouble. May be I've been exceptionally
>   unlucky, but that's a reality -- if you truly run out of memory you're
>   screwed. Your escape strategies don't work, worse yet they are *very*
>   likely to fail in the manner that you don't except in the layer that
>   you have no knowledge about. 
> 
>   Consider this -- what's worse: a fossil server that died and lost some
>   of the requests or a server that tried to recover and committed random
>   junk ?

How is definitely losing data better than the possibility of writing random
junk?

Thanks,
	Lucho

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 08:31:16PM -0600, Latchesar Ionkov wrote:
> You are concentrating too much on the particular example I gave (emalloc)
> and not on the issue of exiting from a library. I don't think it is a
> library job to decide whether the application should die or not.

  You're right. But this particular example illustrates an important 
  point which, I believe, is crucial to the spirit of Plan9. I clumsily
  formulate it as: its important to know when to stop solving the
  general problem. I believe that's the principle that helps Plan9
  kernel stay away from becoming a true micro-kernel (Mach OS) or 
  drive the abstraction ad absurdum (Spring OS) etc.

  It is my true belief that sometimes its better to admit that we don't
  know how to solve the general problem yet, than to pretend that we do.
  C++ and Java were supposed to relieve me from ever worrying about error
  handling. But did they really ? Somehow I don't see a huge stream
  of exceptions I get from my JVM quite regularly as a superior strategy.
  We don't know how to solve the general problem.

  Now, don't get me wrong -- sometimes you have to make an extra effort
  to at least pretend that it is solvable. Especially when you are in a
  business of building commercial software. I can appreciate it. But lets
  move our discussion to a practical level -- could you explain what 
  sort of "alternative" control flow you're after when something bad
  happens inside the library. What kind of an ideal world solution
  would you like to see as an application developer ?
 
> >   Consider this -- what's worse: a fossil server that died and lost some
> >   of the requests or a server that tried to recover and committed random
> >   junk ?
> 
> How is definitely losing data better than the possibility of writing random
> junk?

  Because it is very easy to tell when you lost something on which you can
  build a comprehensive recovery strategy. Case in point: I remember a couple
  (5-10, actually) years ago there was an MS DOS virus detected at Stanford
  which, to my recollection, was the one and only one they truly feared. 
  What the virus did was it scanned your HDD for TeX documents and carefully
  permuted certain characters as to keep the document a valid TeX document
  but alter its meaning slightly. 

  The vote on this one was unanimous: "we'd be all better off if it just
  deleted them".

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

On Fri, Jun 09, 2006 at 05:45:29PM -0700, Roman Shaposhnick said:
>   Now, don't get me wrong -- sometimes you have to make an extra effort
>   to at least pretend that it is solvable. Especially when you are in a
>   business of building commercial software. I can appreciate it. But lets
>   move our discussion to a practical level -- could you explain what 
>   sort of "alternative" control flow you're after when something bad
>   happens inside the library. What kind of an ideal world solution
>   would you like to see as an application developer ?

Umm, like returning an error? :)

Thanks,
	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

i think you're optimising for the corner case.  do you expect every program
in /sys/src/cmd to want or need to recover from a malloc error or a sysfatal?

btw.  why would you return an error for these cases:

lib9p/srv.c:		sysfatal("no walk function, no file trees");
ibString/s_grow.c:		sysfatal("s_grow of constant string");
libString/s_putc.c:		sysfatal("can't s_putc a shared string");
libString/s_read.c:		sysfatal("can't s_read a shared string");
libString/s_read_line.c:		sysfatal("can't s_read_line a shared string");
libString/s_terminate.c:		sysfatal("can't s_terminate a shared string");
[etc.]

what could you do about this one:
libthread/note.c:		sysfatal("libthread: too many delayed notes");

- erik

On Fri Jun  9 19:51:55 CDT 2006, lucho@gmx.net wrote:
> On Fri, Jun 09, 2006 at 05:45:29PM -0700, Roman Shaposhnick said:
> >   Now, don't get me wrong -- sometimes you have to make an extra effort
> >   to at least pretend that it is solvable. Especially when you are in a
> >   business of building commercial software. I can appreciate it. But lets
> >   move our discussion to a practical level -- could you explain what 
> >   sort of "alternative" control flow you're after when something bad
> >   happens inside the library. What kind of an ideal world solution
> >   would you like to see as an application developer ?
> 
> Umm, like returning an error? :)

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 09:01:23PM -0600, Latchesar Ionkov wrote:
> On Fri, Jun 09, 2006 at 05:45:29PM -0700, Roman Shaposhnick said:
> >   Now, don't get me wrong -- sometimes you have to make an extra effort
> >   to at least pretend that it is solvable. Especially when you are in a
> >   business of building commercial software. I can appreciate it. But lets
> >   move our discussion to a practical level -- could you explain what 
> >   sort of "alternative" control flow you're after when something bad
> >   happens inside the library. What kind of an ideal world solution
> >   would you like to see as an application developer ?
> 
> Umm, like returning an error? :)

  If its about 
    $ echo "I can't remember the syntax" > /dev/complicated/device

  sure thing -- I'm with you and I'd be the first one to argue for 
  fixing places where it reboots your system instead.

  What I'm after, however, is a: we are deep in a library, and 
  a really bad thing(tm) happens, how do we recover if we can't guarantee
  that we would be able to even get to the application layer from
  where we are. I'm seriously curious -- do you know of a good strategy ?

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

A fork fails.

Which would you rather have the kernel do: panic? Lock up (as in the old 
days)? Or handle it gracefully.

Your fossil fills up completely. Which would you rather have it do: blow 
up on boot, so you can no longer boot your system (current behavior); or 
manage disk space so that, even in the worst of all cases, you can still 
get booted enough to try to clean up (most unix file systems since 1980 
or so).

Nobody's arguing for "best enemy of good". All we're trying to say is, 
that there are times a library should not make the decision to 
sysfatal() on you. And, there are many real world examples of resource 
exhaustion where continuing to run is better than dying. It's not always 
better to run, and it may not be better to run in most cases, but 
sometimes it is really better not to have the library pre-emptively 
decide to exit; in fact, you want a reasonable return value.

I do believe that the shell can handle the case of some types of 
resource exhaustion:

	switch(forkid = fork()){
	case -1:
		Xerror("try again");
		break;


would you want rc to exit in this case?

ron

Re: [9fans] quantity vs. quality

[quanstro]

On Sat Jun 10 18:16:52 CDT 2006, rminnich@lanl.gov wrote:
> A fork fails.
> 
> Which would you rather have the kernel do: panic? Lock up (as in the old 
> days)? Or handle it gracefully.

i was talking about applications.  and usually applications can deal with fork
failure.  maybe counterproductively.

> Your fossil fills up completely. Which would you rather have it do: blow 
> up on boot, so you can no longer boot your system (current behavior); or 
> manage disk space so that, even in the worst of all cases, you can still 
> get booted enough to try to clean up (most unix file systems since 1980 
> or so).

i don't know.  it's hard to say without looking at it.  it's hard for me to just say
"ya, it should do that" because linux is an example of how that can go.  
you should be able to boot from cd, though?  

would this work:  lets say i have everything i need to boot on a fossilfs main
and stuff i can boot without (and could much more easily fill) on fossilfs 
otherstuff.  will fossil continue with the main fs and ignore the full one?

> 
> Nobody's arguing for "best enemy of good". All we're trying to say is, 
> that there are times a library should not make the decision to 
> sysfatal() on you.  And, there are many real world examples of resource 
> exhaustion where continuing to run is better than dying. 

agreed.

> It's not always 
> better to run, and it may not be better to run in most cases, but 
> sometimes it is really better not to have the library pre-emptively 
> decide to exit; in fact, you want a reasonable return value.

mostly agreed.  i'd go for it's /often/ better to quit.  and the downside
of the library not quitting is now you get to add a bunch of error
code to /sys/src/cmd.  

> 
> I do believe that the shell can handle the case of some types of 
> resource exhaustion:
> 
> 	switch(forkid = fork()){
> 	case -1:
> 		Xerror("try again");
> 		break;
> 
> 
> would you want rc to exit in this case?

would it really matter?  if everybody tried their hardest to continue
in the face of errors, you'd never be able to fork a process and fix anything.

damned if you do, damned if you don't.

- erik

Re: [9fans] quantity vs. quality

[lucio]

> mostly agreed.  i'd go for it's /often/ better to quit.  and the downside
> of the library not quitting is now you get to add a bunch of error
> code to /sys/src/cmd.  

Well, you _could_ modify /sys/src/cmd so that it checks all library
return codes and _sysfatal()s as and when required, as a preliminary.
It would be a small (relatively speaking) alteration that can be
improved later.

Lucho's right in that the library should _never_ terminate on error,
he is wrong in that this can only apply in an ideal world where all
returns from library functions are checked.  But we may be compounding
his error by not auditing /sys/src and adding error checking where it
ought to be present and removing Plan 9's contribution to this state
of affairs.  Then Plan 9 gets to hold a bigger chunk of the high moral
ground and also stops encouraging this approach.

Is it even conceivable (haven't had my coffee yet) that we could have
a library that reports all instances where user code _does_ not check
for error returns?

++L

Re: [9fans] quantity vs. quality

[quanstro]

never?  what if malloc's datastructures are corrupt?

- erik

On Sun Jun 11 00:24:44 CDT 2006, lucio@proxima.alt.za wrote:
> Lucho's right in that the library should _never_ terminate on error,
> he is wrong in that this can only apply in an ideal world where all
> returns from library functions are checked.  But we may be compounding
> his error by not auditing /sys/src and adding error checking where it
> ought to be present and removing Plan 9's contribution to this state
> of affairs.  Then Plan 9 gets to hold a bigger chunk of the high moral
> ground and also stops encouraging this approach.

Re: [9fans] quantity vs. quality

[lucio]

> never?  what if malloc's datastructures are corrupt?

As long as the stack isn't corrupt, it _can_ still return to the
caller.  The argument is really whether the caller can be trusted to
take the correct (non)recovery action.  But you can't take away
Lucho's options because another 99 callers are too lazy.  Your view,
if I read you correctly, is that Lucho also can't be trusted, because
he won't test his recovery code, but that is not an acceptable
assumption.

Yes, we do need a middle ground and redefining _sysfatal() is one
option, but encouraging good programming practice, by example as well
as by instruction, would be preferable to unpredictable behaviour
under error conditions.

To me, the greatest loss in this age of complexity, is the determinism
of early day computing.  Anything that increases determinism at the
application level is to be encouraged, not discouraged.

++L

PS: What is true is that the Plan 9 developers did not have the
resources to do everything perfectly and picked sensible places where
this shortcoming would affect the result in the least destructive
fashion.  What is also true is that as a community we ought to be able
to improve on this, rather than concentrate on wild goose chases.
Which brings us back, full circle, to the desirability of GCC/G++ for
Plan 9.  Thanks, Latchesar :-)

Re: [9fans] quantity vs. quality

[quanstro]

On Sun Jun 11 07:24:25 CDT 2006, lucio@proxima.alt.za wrote:
> > never?  what if malloc's datastructures are corrupt?
> 
> As long as the stack isn't corrupt, it _can_ still return to the
> caller.  The argument is really whether the caller can be trusted to
> take the correct (non)recovery action.  

i don't think this is about "trusting" somebody do do the right thing
for recovery.

if malloc's datastructures are corrupt, then you can assume that memory
is corrupt.  somebody's fandangoed on core.  since you don't have any
valid data, what can you accomplish except call sysfatal. (which might not
work.)

the most incidious bit about trying to recover when you're really and 
truly hosed is that you just make debugging harder.

btw.  glibc will abort if you corrupt the heap or double-free.

> But you can't take away
> Lucho's options because another 99 callers are too lazy.  Your view,
> if I read you correctly, is that Lucho also can't be trusted, because
> he won't test his recovery code, but that is not an acceptable
> assumption.

i think you're reading me wrong.  it's not about trust.  it's about how
software really gets written.  i'm as guilty as the next guy in writing
fancy recovery code that i never try out.

i've been bitten in production at least twice by botched recovery.

> 
> Yes, we do need a middle ground and redefining _sysfatal() is one
> option, but encouraging good programming practice, by example as well
> as by instruction, would be preferable to unpredictable behaviour
> under error conditions.

yes.

> To me, the greatest loss in this age of complexity, is the determinism
> of early day computing.  Anything that increases determinism at the
> application level is to be encouraged, not discouraged.

this is exactly why i think that sysfatal can be good if you really can't continue
or continuing is very likely to mask an error.

if you fail to get 20 bytes from malloc, for instance, it's likely you have an
huge leak in your program that needs to be fixed.

- erik

Re: [9fans] quantity vs. quality

[geoff]

I think the argument behind erik's argument is that some error
scenarios are difficult to simulate, and fairly improbable.  Even
given conscientious programmers who code carefully and test reasonably
thoroughly, will testing simulate a failure of every possible attempt
to allocate memory to see what happens?  How about simulating I/O
errors on every possible read or write?  More generally, will it
simulate an error return from every possible library and system call?
all possible error returns from every possible call?

To pick a real example of recovery, in C News, we made sure that
incoming messages would not be dropped even if a filesystem filled at
an awkward time.  The code might exit prematurely (since there's no
point in banging one's [disk] head against a full filesystem usually),
but that would just result in the batch in-process being preserved and
input processing being stalled until the file system got some free
space.  Eventually we started checking free space before processing a
batch too.

On the other hand, resource exhaustion nowadays can generally be
prevented at little cost: add a few gigabytes of RAM, add a few 500GB
disks for swap or file storage.  woot.com was selling 250GB disks
(admittedly from Western Digital, which I'm not a fan of) for $50 each
the other night.  malloc failure was a genuine possibility on the
PDP-11, with a 16-bit address space, and full file systems happened,
when 300MB disks and drives cost thousands of dollars (I no longer
remember prices; they were costly enough that the 11/70 I ran had two
300MB disks and that seemed like an enormous amount of space [it still
seems like a lot to me]).  These days I would imagine that primarily
embedded systems (including games) and supercomputer-like applications
have problems in practice with resource exhaustion.

Re: [9fans] quantity vs. quality

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 11-Jun-06, at 4:26 PM, geoff@collyer.net wrote:
>
> On the other hand, resource exhaustion nowadays can generally be
> prevented at little cost: add a few gigabytes of RAM, add a few 500GB
> disks for swap or file storage.

Generally, but not in many cases.  I do entertainment software.   
Sony, Microsoft, or Nintendo set the machine spec, and that's what  
you have to work with.  When working on the new breed of highly  
dynamic environments it's becoming difficult to fall back to the  
traditional solution of a fixed-size asset base.  Memory shortages in  
particular are acute and need to be dealt with on an excessively  
regular basis, and usually in ways that affect the fundamental  
architecture of the product.  Sadly, methodologies for exception  
condition handling are just poor and obscenely difficult to test.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEjONfpJeHo/Fbu1wRAnq2AKDNodI//nqxZ9xfCorLk2HAc/OnhgCgmKHP
D6XjGQnPzrjdbph+ki1LXu0=
=Xi4D
-----END PGP SIGNATURE-----

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

actually, to repeat my serious question: waserror() and friends in user 
mode. Crazy, doable, or just plain bad idea?

thanks

ron

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Mon, Jun 12, 2006 at 02:16:10PM -0600, Ronald G Minnich wrote:
> actually, to repeat my serious question: waserror() and friends in user 
> mode. Crazy, doable, or just plain bad idea?

  Doable. But that'll give you a tool quite similar to the C++ exceptions
  (although without the bonus of auto-destruction). What's your plan
  for using this tool in libraries ?

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

Roman Shaposhnick wrote:
> On Mon, Jun 12, 2006 at 02:16:10PM -0600, Ronald G Minnich wrote:
> 
>>actually, to repeat my serious question: waserror() and friends in user 
>>mode. Crazy, doable, or just plain bad idea?
> 
> 
>   Doable. But that'll give you a tool quite similar to the C++ exceptions
>   (although without the bonus of auto-destruction). What's your plan
>   for using this tool in libraries ?

I have no plans :-)

Just wondering.

auto-destruction: does it involve plastique or just gunpowder?

ron

Re: [9fans] quantity vs. quality

[Victor Nazarov]

Ronald G Minnich wrote:

> Roman Shaposhnick wrote:
>
>> On Mon, Jun 12, 2006 at 02:16:10PM -0600, Ronald G Minnich wrote:
>>
>>> actually, to repeat my serious question: waserror() and friends in 
>>> user mode. Crazy, doable, or just plain bad idea?
>>
>>
>>
>>   Doable. But that'll give you a tool quite similar to the C++ 
>> exceptions
>>   (although without the bonus of auto-destruction). What's your plan
>>   for using this tool in libraries ?
>
>
> I have no plans :-)
>
> Just wondering.
>
> auto-destruction: does it involve plastique or just gunpowder?
>
> ron
>
auto-destruction seems to be deprecated everywhere. Garbage Collection 
needs to be
implemented in libraries. It's seems to be possible without KenC 
language modification, but
I think it's too expensive and needs massive rewrites and refactoring.
--
Victor

Re: [9fans] quantity vs. quality

[Roman Shaposhnik]

On Mon, 2006-06-12 at 14:56 -0600, Ronald G Minnich wrote:
> Roman Shaposhnick wrote:
> > On Mon, Jun 12, 2006 at 02:16:10PM -0600, Ronald G Minnich wrote:
> > 
> >>actually, to repeat my serious question: waserror() and friends in user 
> >>mode. Crazy, doable, or just plain bad idea?
> > 
> > 
> >   Doable. But that'll give you a tool quite similar to the C++ exceptions
> >   (although without the bonus of auto-destruction). What's your plan
> >   for using this tool in libraries ?
> 
> I have no plans :-)
> 
> Just wondering.
> 
> auto-destruction: does it involve plastique or just gunpowder?
  
   I'm talking language of mass destruction here ;-)

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Francisco J Ballesteros]

in /n/sources/nemo/sys/src/liberror

there is such beast, we made it for Plan B.
I found it useful when error handling required a lot
of nesting and checking, because simply calling error sufficed.

However, at the end, I still had the problem of what to do with the error.
In may times, btw, it was just clean up to avoid messing things up, and then
sysfatal().


On 6/12/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> actually, to repeat my serious question: waserror() and friends in user
> mode. Crazy, doable, or just plain bad idea?
>
> thanks
>
> ron
>
>

Re: [9fans] quantity vs. quality

[rog]

i think this has been mentioned on the list before (otherwise i wouldn't
have known to look for it) but when considering error recovery tactics, it's
worth looking at http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
("Making reliable software systems in the presence of errors")

he summarises their approach to error recovery as follows:

- if you can't do what you want to do, die.
- let it crash.
- do not program defensively.

they built a telecoms switching system with a reported measured reliability of 99.9999999%
following this philosophy.

see section 4.3 (page 101) for details.

the key is that another process gets notified of the error.

he makes this useful distinction between "error" and "exception":

- exceptions occur when the run-time system does not know what to do.
- errors occur when the programmer does not know what to do.

i would suggest that most out-of-memory conditions are best
classed as errors, not exceptions.

Re: [9fans] quantity vs. quality

[Skip Tavakkolian]

excellent points; i believe this.  there's no sense in masking errors
with pseudo recovery.  good test coverage should expose programmer
misunderstanding.

if the system can't afford memory allocation errors, then
preallocating (static or dynamic) and capping a maximum that the
system should ever need will help simulate exhaustion in testing and
make the memory usage and response times bounded.  watchdog processes
and memory checksums are possible additional measures.

> i think this has been mentioned on the list before (otherwise i wouldn't
> have known to look for it) but when considering error recovery tactics, it's
> worth looking at http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
> ("Making reliable software systems in the presence of errors")
> 
> he summarises their approach to error recovery as follows:
> 
> - if you can't do what you want to do, die.
> - let it crash.
> - do not program defensively.
> 
> they built a telecoms switching system with a reported measured reliability of 99.9999999%
> following this philosophy.
> 
> see section 4.3 (page 101) for details.
> 
> the key is that another process gets notified of the error.
> 
> he makes this useful distinction between "error" and "exception":
> 
> - exceptions occur when the run-time system does not know what to do.
> - errors occur when the programmer does not know what to do.
> 
> i would suggest that most out-of-memory conditions are best
> classed as errors, not exceptions.

Re: [9fans] quantity vs. quality

["Nils O. Selåsdal"]

Skip Tavakkolian wrote:
> excellent points; i believe this.  there's no sense in masking errors
> with pseudo recovery.  good test coverage should expose programmer
> misunderstanding.
> 
> if the system can't afford memory allocation errors, then
> preallocating (static or dynamic) and capping a maximum that the
> system should ever need will help simulate exhaustion in testing and
> make the memory usage and response times bounded.  watchdog processes
> and memory checksums are possible additional measures.

Memory shortage can often be temporary. Sleeping malloc has saved me
a few times.

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Tue, Jun 13, 2006 at 01:08:22PM +0100, rog@vitanuova.com wrote:
> i think this has been mentioned on the list before (otherwise i wouldn't
> have known to look for it) but when considering error recovery tactics, it's
> worth looking at http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
> ("Making reliable software systems in the presence of errors")

  Thanks for the pointer. I find some of the ideas mentioned in this paper 
  to be quite interesting. Especially the ones on how true error recovery is
  supposed to be structured based on the hierarchy of supervisors and WBFs.
  
  Their job, however, seems to be made easier by the sort of language they
  use. For the cave-man like me, who still thinks that C is all I need,
  here's a mechanism I would very much like to use in order to make my
  code more fault tolerant, but easier to maintain: the "reverse" propagation
  of corrections. Here's what I mean by it.

  Suppose we're deep down in a call stack which looks somewhat like this:
     
     main 
       ...
         foo
	   ...
	      bar()

  now, there's a fixable exception that occurs in bar(), lets say a call
  to malloc that return NULL. Also suppose that I do have a strategy
  for dealing with OOM conditions, but I don't want it to clutter my
  bar() code. In fact, I don't even want it to be local to the process
  but rather implemented as a policy on a standalone server. All of that
  means that I can't just simply write:
      
         try {
	    malloc();
	 } catch(...) {
	    <fix it>
	 }
   
  but I have to transfer the control to the higher authority. I expect
  the codition which lead to OOM be fixed at that level, and all I want
  to have at the level of bar() is to see my malloc() call be restared.
  Automatically. Alternatively the authority could decide that malloc()
  has to be terminated at which point my control flow will resume past
  the 'malloc();'. 

  Now, we have a mechanism for the exception to be propagated upwards
  (I can even do it in C with things like waserror()), but there's no
  mechanism for the "fix" to be "propagated" downwards and have
  my call to malloc be automatically restarted. 

  On one hand it shouldn't be too hard to make such a thing part of the
  language, but I haven't seen anything like it yet. So are there any
  better solutions to the problem I've just described or am I talking
  nonsense here ? ;-)
  	     
Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Victor Nazarov]

Roman Shaposhnick wrote:

>  Suppose we're deep down in a call stack which looks somewhat like this:
>     
>     main 
>       ...
>         foo
>	   ...
>	      bar()
>
>  now, there's a fixable exception that occurs in bar(), lets say a call
>  to malloc that return NULL. Also suppose that I do have a strategy
>  for dealing with OOM conditions, but I don't want it to clutter my
>  bar() code. In fact, I don't even want it to be local to the process
>  but rather implemented as a policy on a standalone server. All of that
>  means that I can't just simply write:
>      
>         try {
>	    malloc();
>	 } catch(...) {
>	    <fix it>
>	 }
>   
>  but I have to transfer the control to the higher authority. I expect
>  the codition which lead to OOM be fixed at that level, and all I want
>  to have at the level of bar() is to see my malloc() call be restared.
>  Automatically. Alternatively the authority could decide that malloc()
>  has to be terminated at which point my control flow will resume past
>  the 'malloc();'. 
>
>  Now, we have a mechanism for the exception to be propagated upwards
>  (I can even do it in C with things like waserror()), but there's no
>  mechanism for the "fix" to be "propagated" downwards and have
>  my call to malloc be automatically restarted. 
>
>  On one hand it shouldn't be too hard to make such a thing part of the
>  language, but I haven't seen anything like it yet. So are there any
>  better solutions to the problem I've just described or am I talking
>  nonsense here ? ;)
>  
>
What about creating a Plan9-thread for the error recovery mecanism. This 
thread
would wait for the message on the channel. When we encounter malloc error we
send message on the error chanel. Error recovery process error and send 
message
back to us. Getting message we restart malloc...
All this require carefull coding, so I didn't try to write an example by 
myself, but
I think it's possible.
--
Victor

Re: [9fans] quantity vs. quality

[Russ Cox]

When I ported dns I was very impressed that
it correctly handled rfork failing (because p9p
doesn't do shared-memory rfork).  You can argue
about cutting corners all you want, but it's a 
slippery slope.  

You end up with more robust software when you
think about what to do in the error cases instead
of just assuming they won't happen.

Russ

Re: [9fans] quantity vs. quality

[quanstro]

On Sat Jun 10 23:41:04 CDT 2006, rsc@swtch.com wrote:
> When I ported dns I was very impressed that
> it correctly handled rfork failing (because p9p
> doesn't do shared-memory rfork).  

you've got to admit this was a fortuitous accident.  and
dns doesn't need rfork do do one request -- it needs rfork
to handle a second request concurrently.  dns didn't really
work that well with the broken rfork.

> You can argue
> about cutting corners all you want, but it's a 
> slippery slope.

i don't think it's about cutting corners. 

what do you do when
- a library can't allocate 10 bytes? or 20?
- malloc detects a double-free or somebody has stepped
on it's datastructures.

isn't this much different than
- a library can allocate 64k or 1m

trying to recover from some errors is worse than dying.
dying gives you the oppertunity to fix the problem.
not dying can cover real bugs.

> 
> You end up with more robust software when you
> think about what to do in the error cases instead
> of just assuming they won't happen.

if you're going to put that code in, it needs to be tested.
in commercial software, my worst experiences have been
with recovery code that didn't work.

- erik

Re: [9fans] quantity vs. quality

[Roman Shaposhnik]

On Sat, 2006-06-10 at 17:13 -0600, Ronald G Minnich wrote:
> A fork fails.
> 
> Which would you rather have the kernel do: panic? Lock up (as in the old 
> days)? Or handle it gracefully.

I think that the original point (which was to demonstrate that
error handling in libraries is not just a gross oversight that
obviously conflicts with a claim of Plan9 code being clean and
otherwise superior to the average source code out there) has
been clearly demonstrated by the sheer length of the discussion
that followed. That was my goal in this discussion.

Now, I think that personally I somewhat overstated my case. Clearly,
the real question is not to chose between the death and recovery,
but rather how to develop a comprehensive strategy based on these
two. 

Being a compiler guy the most common case of error handling I see
is, of course, an invalid input given to the translator. Something
that clearly requires a recovery strategy. Yet, I'm always frustrated
at an endless stream of induced error messages when I see one. Something
that makes the code for dealing with correct recovery in C++ grow longer
every day. Longer and untested :-(

Exceptions/return values/waserror() these are all just mechanisms for
controlling the flow of your application -- they can get you to a
particular place in your code, but deciding what to do once you're
there is when it gets complicated.  

Thanks,
Roman.

P.S. It is also interesting to note that a chapter on error and
resource handling in "Practice of Programming" is the least prescriptive
of them all, basically stating that authors don't have a clear
answer.

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

Latchesar Ionkov wrote:
> You are concentrating too much on the particular example I gave (emalloc)
> and not on the issue of exiting from a library. I don't think it is a
> library job to decide whether the application should die or not.

that is a very key point.

ron

Re: [9fans] quantity vs. quality

[quanstro]

the converse is that every dumb little app now has to handle
a lot of error conditions.  this is also not robust.

- erik

On Sat Jun 10 18:06:50 CDT 2006, rminnich@lanl.gov wrote:
> Latchesar Ionkov wrote:
> > You are concentrating too much on the particular example I gave (emalloc)
> > and not on the issue of exiting from a library. I don't think it is a
> > library job to decide whether the application should die or not.
> 
> that is a very key point.
> 
> ron

Re: [9fans] quantity vs. quality

[andrey mirtchovski]

> i'm skeptical that this is a real-world problem.  i've not run out of memory
> without hosing the system to the point where it needed to be rebooted.

the problem we face is that we can't isolate our programs on dedicated
hardware the way you isolate venti for example. if you ran a
standalone venti server and ran out of memory you could argue that the
crap has hit the fan irrevocably.

some of our code looks a lot like a meta-kernel: we provide the
capabilities for running other programs on many machines concurrently.
in more cases than anyone will admit, those programs misbehave badly
but we can't afford to throw the towel every time.

to illustrate from experience, just in the space of one month this
year, we ran out of memory, out of processes to run, out of time and
out of file descriptors in trivial cases. we simply must keep going or
at least sit quietly and wait for the storm to pass...

i'm sorry if i'm not explaining the situation too well.

Re: [9fans] quantity vs. quality

[quanstro]

no.  you explain the situtation well.

i realize that this is exactly the situation.  and the problem is that once you
run out of memory, all kinds of stuff will start failing.  fork will fail.  unless
there is a single identifiably offender that the kernel kills and isn't automatically
restarted, your chances of fixing the system are small.

running a production system on non-dedicated h/w is a bug in itself.  you
need to have some idea of what's going to be running on your box.

i've run into all those cases.  (except for legitamately running out of memory
with a completely sane system.)  

running out of fds on unix is a bug.  you can query the system for the number
of fds you are allowed to use, and you need to respect this number.

running out of processes could be lots of things.  i always boiled it down to
either a configuration error or a lack of resource control. e.g. something like

	if(nrq > cfg.rqmax){
		werrstr("too many requests");
		return -1;
	}
	nrq++;

look, i like to start out with each "difficult" error (like running out of memory)
and handling the real cases that kill my program.  generally this is a small
fraction of the total number of ways the application could fail.

naturally this is more work, but if you do it you have confidence that the situation
you specifically saw and handled will be handled correctly.

this is a bit of religion.  hopefully i'm not too dogmatic. ;-)

- erik

On Fri Jun  9 19:25:35 CDT 2006, mirtchovski@gmail.com wrote:
> > i'm skeptical that this is a real-world problem.  i've not run out of memory
> > without hosing the system to the point where it needed to be rebooted.
> 
> the problem we face is that we can't isolate our programs on dedicated
> hardware the way you isolate venti for example. if you ran a
> standalone venti server and ran out of memory you could argue that the
> crap has hit the fan irrevocably.
> 
> some of our code looks a lot like a meta-kernel: we provide the
> capabilities for running other programs on many machines concurrently.
> in more cases than anyone will admit, those programs misbehave badly
> but we can't afford to throw the towel every time.
> 
> to illustrate from experience, just in the space of one month this
> year, we ran out of memory, out of processes to run, out of time and
> out of file descriptors in trivial cases. we simply must keep going or
> at least sit quietly and wait for the storm to pass...
> 
> i'm sorry if i'm not explaining the situation too well.
> 

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net said:
> On Fri Jun  9 18:48:44 CDT 2006, lucho@gmx.net wrote:
> > > 
> > > what is the senerio you're thinking of where malloc could fail
> > > and you can recover?
> > 
> > 
> > Let's say you have a fossil like file server and you cannot malloc memory to
> > process new requests. Do you want to flush the data buffers back to the disk
> > before you die, you you want to die in some library without any flushing.
> 
> have you had a problem with fossil failing in this way?

IIRC fossil is not using libraries that call sysfatal. I said fossil like
file server, not fossil. Let's say that I want to write a fossil-like file
server. I cannot use lib9p, because it will call sysfatal and not give me
chance to flush the buffers to the disk.

> i'm not saying you allocate memory like crazy and don't worry about running
> out of memory.  i'm sure that fossil is very careful about allocating memory
> for requests.
> > 
> > Or you have a file server that keeps some non-file server related state in
> > memory. The unability to serve any more requests is fine as long as it can
> > start serving them at some point later when there is more memory. The dying
> > is not acceptible because the data kept in the memory is important.
>  
> i'm skeptical that this is a real-world problem.  i've not run out of memory
> without hosing the system to the point where it needed to be rebooted.

This is a real-world problem that we are currently having. 

Thanks,
	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

On Fri Jun  9 19:18:09 CDT 2006, lucho@gmx.net wrote:
> On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net said:
> > On Fri Jun  9 18:48:44 CDT 2006, lucho@gmx.net wrote:
> > > > 
> > > > what is the senerio you're thinking of where malloc could fail
> > > > and you can recover?
> > > 
> > > 
> > > Let's say you have a fossil like file server and you cannot malloc memory to
> > > process new requests. Do you want to flush the data buffers back to the disk
> > > before you die, you you want to die in some library without any flushing.
> > 
> > have you had a problem with fossil failing in this way?
> 
> IIRC fossil is not using libraries that call sysfatal. I said fossil like
> file server, not fossil. Let's say that I want to write a fossil-like file
> server. I cannot use lib9p, because it will call sysfatal and not give me
> chance to flush the buffers to the disk.
> 

sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
fancy cleanup routine and you're golden.

but i think you're letting better be the enemy of good.  start off just letting
sysfatal run its course.  if you find real examples of recoverable failure, then
handle and test each one.

when i've taken this approach, i have never needed to recover from the 
error, but i have found some corefiles with interesting requests.  like malloc(-1).
that is another overlooked benefit of not recovering from every error at
the outset.

- erik

Re: [9fans] quantity vs. quality

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9-Jun-06, at 5:23 PM, quanstro@quanstro.net wrote:
>
> sure you can.  sysfatal calls _sysfatal to do the deed.  redefine  
> that to call your
> fancy cleanup routine and you're golden.

But it's one step worse than this.  Sometimes your fancy cleanup  
routine can't dig itself out of your current callstack; it's better  
to find a way to "succeed" and handle the failure higher up, thus  
maintaining integrity.  When I have critical (well, as critical as it  
gets when doing entertainment software) resources whose allocation  
failure will cause grief, I try to pre-allocate before doing  
something irreversible.  The the rest of the work is working out what  
you're going to use to propagate that exception condition up the  
stack, at the same time as your routine "succeeds".
  A longump or function call doesn't let you clean up/repair your  
state well enough precisely because calling it threw away an  
important part of your state.  This is what all those people on about  
C++ exceptions are mumbling about, although their implementation  
means catching every such case in what seems like every codepath -  
ugly fast.

Paul


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEihUqpJeHo/Fbu1wRAh0KAJwPCzxloDdoK8R61nHASUBvYahb/wCgtetN
9AaBLhds/5qTrx4hAdoicc4=
=BXDh
-----END PGP SIGNATURE-----

Re: [9fans] quantity vs. quality

[quanstro]

sure.  if you have a known place where a known sane input will
cause allocation failure (like an image that's too big), then by all
means, handle that case.  everything you say is valid.

however, i have yet to see a small allocation fail without the
system being pretty broken.  and my conclusion is that preemtive
strikes against failures that should not happen on a sane system
may cause more harm than good.

your bit about exceptions is is right on.  sometimes just droping
core makes problem resolution much easier.

- erik

On Fri Jun  9 19:44:19 CDT 2006, plalonde@telus.net wrote:
> On 9-Jun-06, at 5:23 PM, quanstro@quanstro.net wrote:
> >
> > sure you can.  sysfatal calls _sysfatal to do the deed.  redefine  
> > that to call your
> > fancy cleanup routine and you're golden.
> 
> But it's one step worse than this.  Sometimes your fancy cleanup  
> routine can't dig itself out of your current callstack; it's better  
> to find a way to "succeed" and handle the failure higher up, thus  
> maintaining integrity.  When I have critical (well, as critical as it  
> gets when doing entertainment software) resources whose allocation  
> failure will cause grief, I try to pre-allocate before doing  
> something irreversible.  The the rest of the work is working out what  
> you're going to use to propagate that exception condition up the  
> stack, at the same time as your routine "succeeds".
>   A longump or function call doesn't let you clean up/repair your  
> state well enough precisely because calling it threw away an  
> important part of your state.  This is what all those people on about  
> C++ exceptions are mumbling about, although their implementation  
> means catching every such case in what seems like every codepath -  
> ugly fast.
> 
> Paul

Re: [9fans] quantity vs. quality

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9-Jun-06, at 5:59 PM, quanstro@quanstro.net wrote:
>
> however, i have yet to see a small allocation fail without the
> system being pretty broken.  and my conclusion is that preemtive
> strikes against failures that should not happen on a sane system
> may cause more harm than good.

I have seen allocations that are *supposed* to be small fail - some  
of the most precious results are in the middle of runs of code that's  
far from what you or I would call production-ready.  There's plenty  
of cases of relatively fragile software doing smart things with  
partial results when a programmer error occurs; when partial runs  
have value you save the result...

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEih08pJeHo/Fbu1wRAkBsAJ9Mj7i0aJnrnMDhJWI/mtII0ScPRgCgoDM+
mLfgd72HPUb5NbMb6LH59m8=
=6RkZ
-----END PGP SIGNATURE-----

Re: [9fans] quantity vs. quality

[Bruce Ellis]

i think there is at least 20 years of lit on "how to cope
with memory exhaustion".  in limbo almost any chunk
of code can exhaust the heap, throws an exception and
the errant dudes get cleaned up.  i've only seen it in
torture tests but no crashes ... just culprits.

brucee

On 6/10/06, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 9-Jun-06, at 5:59 PM, quanstro@quanstro.net wrote:
> >
> > however, i have yet to see a small allocation fail without the
> > system being pretty broken.  and my conclusion is that preemtive
> > strikes against failures that should not happen on a sane system
> > may cause more harm than good.
>
> I have seen allocations that are *supposed* to be small fail - some
> of the most precious results are in the middle of runs of code that's
> far from what you or I would call production-ready.  There's plenty
> of cases of relatively fragile software doing smart things with
> partial results when a programmer error occurs; when partial runs
> have value you save the result...
>
> Paul
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEih08pJeHo/Fbu1wRAkBsAJ9Mj7i0aJnrnMDhJWI/mtII0ScPRgCgoDM+
> mLfgd72HPUb5NbMb6LH59m8=
> =6RkZ
> -----END PGP SIGNATURE-----
>

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

On Fri, Jun 09, 2006 at 07:23:11PM -0500, quanstro@quanstro.net said:
> On Fri Jun  9 19:18:09 CDT 2006, lucho@gmx.net wrote:
> > On Fri, Jun 09, 2006 at 06:51:00PM -0500, quanstro@quanstro.net said:
> > > On Fri Jun  9 18:48:44 CDT 2006, lucho@gmx.net wrote:
> > > > > 
> > > > > what is the senerio you're thinking of where malloc could fail
> > > > > and you can recover?
> > > > 
> > > > 
> > > > Let's say you have a fossil like file server and you cannot malloc memory to
> > > > process new requests. Do you want to flush the data buffers back to the disk
> > > > before you die, you you want to die in some library without any flushing.
> > > 
> > > have you had a problem with fossil failing in this way?
> > 
> > IIRC fossil is not using libraries that call sysfatal. I said fossil like
> > file server, not fossil. Let's say that I want to write a fossil-like file
> > server. I cannot use lib9p, because it will call sysfatal and not give me
> > chance to flush the buffers to the disk.
> > 
> 
> sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
> fancy cleanup routine and you're golden.

And you think that's an example of writing good code? I thought we are
talking about a system with clean design that you don't need to use kludges in :)

	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

i don't know if it's good code or bad code in general. i was pointing out that it is possible to
catch a call to sysfatal and do something else, since you seemed to indicate that was
not possible.

it may be a good strategy if you really feel that sysfatal needs to be caught for your 
particular application.  the advantage is that other, simplier applications need not 
be complicated by handling things like malloc failures.

- erik

On Fri Jun  9 19:46:28 CDT 2006, lucho@gmx.net wrote:
> > sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
> > fancy cleanup routine and you're golden.
> 
> And you think that's an example of writing good code? I thought we are
> talking about a system with clean design that you don't need to use kludges in :)
> 
> 	Lucho

Re: [9fans] quantity vs. quality

[Latchesar Ionkov]

On Fri, Jun 09, 2006 at 07:45:40PM -0500, quanstro@quanstro.net said:
> i don't know if it's good code or bad code in general. i was pointing out that it is possible to
> catch a call to sysfatal and do something else, since you seemed to indicate that was
> not possible.

How can you find from _sysfatal what exactly caused the sysfatal and if you
in recoverable state or not?

	Lucho

Re: [9fans] quantity vs. quality

[quanstro]

by the error string.

On Fri Jun  9 20:03:37 CDT 2006, lucho@gmx.net wrote:
> On Fri, Jun 09, 2006 at 07:45:40PM -0500, quanstro@quanstro.net said:
> > i don't know if it's good code or bad code in general. i was pointing out that it is possible to
> > catch a call to sysfatal and do something else, since you seemed to indicate that was
> > not possible.
> 
> How can you find from _sysfatal what exactly caused the sysfatal and if you
> in recoverable state or not?
> 
> 	Lucho
> 

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

quanstro@quanstro.net wrote:

> sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
> fancy cleanup routine and you're golden.

wrong approach. _sysfatal has no idea what's going on. The code that 
called the library call has every idea what's going on.



ron

Re: [9fans] quantity vs. quality

[geoff]

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

I think the suggestion is to have the caller assign the address of an
alternate function to _sysfatal, and that function can know what the
caller knows.

[-- Attachment #2: Type: message/rfc822, Size: 3135 bytes --]

From: Ronald G Minnich <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] quantity vs. quality
Date: Sat, 10 Jun 2006 17:06:52 -0600
Message-ID: <448B508C.1@lanl.gov>

quanstro@quanstro.net wrote:

> sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
> fancy cleanup routine and you're golden.

wrong approach. _sysfatal has no idea what's going on. The code that 
called the library call has every idea what's going on.



ron

Re: [9fans] quantity vs. quality

[jmk]

there's nothing inviolate about fixing the library
to do what you want. for example, in this case, the default
sysfatal behaviour could stay the same, but it would
return the value returned by _sysfatal, say a string.
then we look at all the places it's used and see if
it needs any tweaking.

or something like that. if you can agree on some better
implementation that satisfies everyone then that's what
we do. routines like sysfatal end up in the library as
someone thought they were common idioms in a bunch of
existing programmes. sometimes the idiom needs refinement
after it's been seen in place.

--jim

On Sat Jun 10 19:07:50 EDT 2006, rminnich@lanl.gov wrote:
> quanstro@quanstro.net wrote:
> 
> > sure you can.  sysfatal calls _sysfatal to do the deed.  redefine that to call your
> > fancy cleanup routine and you're golden.
> 
> wrong approach. _sysfatal has no idea what's going on. The code that 
> called the library call has every idea what's going on.
> 
> 
> 
> ron

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

quanstro@quanstro.net wrote:

> i'm skeptical that this is a real-world problem.  i've not run out of memory
> without hosing the system to the point where it needed to be rebooted.

we've definitely had different experiences :-)

ron

Re: [9fans] quantity vs. quality

[quanstro]

you must have been running better software than i!  usually something
gets corrupted when a resource runs out.  and often, when you come
close to running out of memory on unix, performance sucks so bad you
wish the machine would just fall over.

- erik

On Sat Jun 10 18:06:01 CDT 2006, rminnich@lanl.gov wrote:
> quanstro@quanstro.net wrote:
> 
> > i'm skeptical that this is a real-world problem.  i've not run out of memory
> > without hosing the system to the point where it needed to be rebooted.
> 
> we've definitely had different experiences :-)
> 
> ron

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

quanstro@quanstro.net wrote:

> i have never seen malloc failure on a production system where
> recovery was possible; i have seen some memory corruption that
> led to malloc failure, but there's no recovering from that.

we've seen different things, then.

ron

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

Latchesar Ionkov wrote:
> Another example is using emalloc in libraries. I agree that it is  much 
> simpler to just give up when there is not enough memory (which  is also 
> not very likely case), but is that how the code is supposed  to be 
> written if you are not doing research?

yes, that is a problem with a lot of code. "Just bail on first error" -- 
we've had to stop using emalloc here because that is very unrealistic 
for production support.

ron

Re: [9fans] quantity vs. quality

[David Leimbach]

On 6/9/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Latchesar Ionkov wrote:
> > Another example is using emalloc in libraries. I agree that it is  much
> > simpler to just give up when there is not enough memory (which  is also
> > not very likely case), but is that how the code is supposed  to be
> > written if you are not doing research?
>
> yes, that is a problem with a lot of code. "Just bail on first error" --
> we've had to stop using emalloc here because that is very unrealistic
> for production support.
>
> ron
>

Well I wonder what people typically do when they can't malloc anymore
memory but need more... A reasonable thing to do is to die I'd think.

In fact if you use Perl "die" is even a part of the lang.

my $a = 5 or die;
print "hello, world\n" or die;

^^ Valid, "draconian" perl?

Re: [9fans] quantity vs. quality

[andrey mirtchovski]

> Well I wonder what people typically do when they can't malloc anymore
> memory but need more... A reasonable thing to do is to die I'd think.

a reasonable thing to do is send Rerror and let the client sort it out
(usually that means retry at some other time). it has happened here
when we run linux systems out of the number of allowed processes :)

Re: [9fans] quantity vs. quality

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Isn't the traditional solution to pre-allocate an emergency pad, and  
when malloc fails the emergency "I need more memory" handler gets to  
use that pad, and then propagates the condition upwards until some  
caller can handle the case?

Or should I run out and file a patent?

Paul

On 9-Jun-06, at 4:38 PM, David Leimbach wrote:

> On 6/9/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>> Latchesar Ionkov wrote:
>> > Another example is using emalloc in libraries. I agree that it  
>> is  much
>> > simpler to just give up when there is not enough memory (which   
>> is also
>> > not very likely case), but is that how the code is supposed  to be
>> > written if you are not doing research?
>>
>> yes, that is a problem with a lot of code. "Just bail on first  
>> error" --
>> we've had to stop using emalloc here because that is very unrealistic
>> for production support.
>>
>> ron
>>
>
> Well I wonder what people typically do when they can't malloc anymore
> memory but need more... A reasonable thing to do is to die I'd think.
>
> In fact if you use Perl "die" is even a part of the lang.
>
> my $a = 5 or die;
> print "hello, world\n" or die;
>
> ^^ Valid, "draconian" perl?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEighzpJeHo/Fbu1wRAtb8AJ45qe4fxgEIiZrpugkheL+V14GHDgCfRd7b
GkIT818+hgPefaxcI25OvaA=
=KZnc
-----END PGP SIGNATURE-----

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

Paul Lalonde wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Isn't the traditional solution to pre-allocate an emergency pad, and  
> when malloc fails the emergency "I need more memory" handler gets to  
> use that pad, and then propagates the condition upwards until some  
> caller can handle the case?

it's very common, and you can probably patent it anyway.

ron

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

David Leimbach wrote:
> On 6/9/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> 
>> Latchesar Ionkov wrote:
>> > Another example is using emalloc in libraries. I agree that it is  much
>> > simpler to just give up when there is not enough memory (which  is also
>> > not very likely case), but is that how the code is supposed  to be
>> > written if you are not doing research?
>>
>> yes, that is a problem with a lot of code. "Just bail on first error" --
>> we've had to stop using emalloc here because that is very unrealistic
>> for production support.
>>
>> ron
>>
> 
> Well I wonder what people typically do when they can't malloc anymore
> memory but need more... A reasonable thing to do is to die I'd think.

example.

xcpu server is running a couple hundred processes for testing. It is 
asked to do one more. It can't allocate something.

Just dying at that point is really a bad idea, and we did find that some 
of the libraries we were using would in fact do that, without coming 
back to xcpu server main code with an error. That's not good behaviour 
for xcpu server. It should gracefully return 'no more room' and keep 
managing things; in some few cases, the library did not give us that 
option.

There are lots of cases like this, many of them in the kernel even; 
would we want the kernel to just toss chunks at these times?

I agree -- sometimes, death is the only option. But not always.

ron

Re: [9fans] quantity vs. quality

[quanstro]

i think we mostly agree.  i'm a little sick of trying to read code with
gobs of recovery goo that may or may not ever get executed.
who knows?

on the other hand, you're right.  if there's a way to kill the kernel by 
running it out of memory, then that should be fixed, if possible.
no questions. 

it would be better for xcpu to start lining up processes for the 
firing squad until sufficient memory is available.

- erik

On Sat Jun 10 18:04:07 CDT 2006, rminnich@lanl.gov wrote:
> 
> xcpu server is running a couple hundred processes for testing. It is 
> asked to do one more. It can't allocate something.
> 
> Just dying at that point is really a bad idea, and we did find that some 
> of the libraries we were using would in fact do that, without coming 
> back to xcpu server main code with an error. That's not good behaviour 
> for xcpu server. It should gracefully return 'no more room' and keep 
> managing things; in some few cases, the library did not give us that 
> option.
> 
> There are lots of cases like this, many of them in the kernel even; 
> would we want the kernel to just toss chunks at these times?
> 
> I agree -- sometimes, death is the only option. But not always.
> 
> ron

Re: [9fans] quantity vs. quality

[Ronald G Minnich]

quanstro@quanstro.net wrote:
> i think we mostly agree.  i'm a little sick of trying to read code with
> gobs of recovery goo that may or may not ever get executed.
> who knows?
> 


Maybe we just need waserror() in user mode.

Then, you want to recover, you at least get the chance.

Or is waserror() there in the library and I never noticed?

ron

Re: [9fans] quantity vs. quality

[David Leimbach]

On 6/10/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> David Leimbach wrote:
> > On 6/9/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> >
> >> Latchesar Ionkov wrote:
> >> > Another example is using emalloc in libraries. I agree that it is  much
> >> > simpler to just give up when there is not enough memory (which  is also
> >> > not very likely case), but is that how the code is supposed  to be
> >> > written if you are not doing research?
> >>
> >> yes, that is a problem with a lot of code. "Just bail on first error" --
> >> we've had to stop using emalloc here because that is very unrealistic
> >> for production support.
> >>
> >> ron
> >>
> >
> > Well I wonder what people typically do when they can't malloc anymore
> > memory but need more... A reasonable thing to do is to die I'd think.
>
> example.
>
> xcpu server is running a couple hundred processes for testing. It is
> asked to do one more. It can't allocate something.
>
> Just dying at that point is really a bad idea, and we did find that some
> of the libraries we were using would in fact do that, without coming
> back to xcpu server main code with an error. That's not good behaviour
> for xcpu server. It should gracefully return 'no more room' and keep
> managing things; in some few cases, the library did not give us that
> option.

I agree with you wholeheartedly.  However there are times when you
*need* to malloc more memory but can't, based on how the program in
question is supposed to operate.

Having implemented parts of MPI's Dynamic Process Management
specification before, I totally understand where you're going.

I do find that, however, when I need to malloc more memory, not
getting what I ask for from malloc is not an acceptable run of the
program.  This happens to me more often than the recoverable cases in
fact, so I often call "abort" when malloc comes back NULL (in testing
anyway... core dumps are handy).

>
> There are lots of cases like this, many of them in the kernel even;
> would we want the kernel to just toss chunks at these times?

Well in the kernel I agree it's a totally different ball game.  There
are blocking and nonblocking memory allocators (in linux anyway).

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 03:44:22PM -0700, David Leimbach wrote:
> On 6/9/06, Roman Shaposhnick <rvs@sun.com> wrote:
> >On Wed, Jun 07, 2006 at 11:05:12PM -0400, Dan Cross wrote:
> >> Too bad the example a beginning programmer
> >> sees now is the cess pool of open source cruft instead of well-written
> >> code.
> >
> >  And that would be the second most useful thing about Plan 9 -- its
> >  source code as a literature for educating oneself how the code is
> >  supposed to be written.
> >
> >Thanks,
> >Roman.
> 
> Except /sys/src/9/pc/pci.c that says it badly needs to be rewritten.
> Maybe a slightly less Kool-Aid drinking way to approach this would be
> to say "code that needs help is better marked, and there's less of
> that?"
  
  May be. I guess I feel passionate about it because Plan9 is the only
  source code that I can read and understand what's going on almost
  always without using a debugger. Maybe it is a cognitive limitation 
  on my part, and may be you guys are lucky enough to have more developed 
  perceptual capabilities but something like this: 
     http://svn.mplayerhq.hu/mplayer/trunk/mplayer.c?view=markup&rev=18407
  or this:
     http://cvs.openssl.org/dir?d=openssl/crypto

  leaves me no chance of *learning* from it. Its all write-only code.

> There's a lot of "belief" here that I think is "fundamentally"
> dangerous... as with anything.

  Its not so much a belief but rather my personal experience. I do lots 
  of self-educating these days by trying to understand the limitations
  of a particular chunk of technology. Just the other day I was
  exploring the "graphics" (i.e. /dev/draw) approach to building a 
  desktop OS (expect more questions on this one from me a bit later ;-))
  And of course, the natural places to start were: libdraw, NeWS,
  Java2D and a bit of Quartz. libdraw wasn't the ideal one. True. But it
  was the only one where I can more or less understand what's going on
  by just reading the source. This principle holds true 99% of the time
  when I compare anything with Plan9. Does it say something about the
  quality of the code ? I don't know. About me ? Not sure. But that's the
  way it feels to me -- as subjective as it may be...

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 06:39:42PM -0700, Lyndon Nerenberg wrote:
> Plan 9's "future" is in guiding the UNIX community forward, not in  
> regressing back to what spawned it in the first place.  And I  
> sincerely hope that doesn't happen by having Plan 9 be adopted  
> wholesale by the masses, for that would (sooner or later) see the end  
> of research and innovation for the sake of not breaking all the  
> currently running apps, which is what caused UNIX to start growing  
> mold.

  Bingo! Personally it is so much easier for me to try out new
  ideas on Plan9 than it is on Linux or anywhere else. The size
  of the system and the fact that I can reasonably comprehend
  its bits and pieces without getting mad makes it an ideal
  platform for all sorts of innovation. I hope it will remain
  that way.

Thanks,
Roman.

Re: [9fans] quantity vs. quality

[andrey mirtchovski]

>   Personally it is so much easier for me to try out new
>   ideas on Plan9 than it is on Linux or anywhere else.

same here, with the small addition that p9p relieves a lot of the
prototyping burdain on Linux too. we got a small system written in p9p
(so it runs on Plan 9 too), got it to be reasonably stable, evaluated
(even by end users) it and now it's off to be rewritten in Linux'
native tongue.

way less painful than it could otherwise have been.

Re: [9fans] gcc on plan9

[Ignacio Torres Masdeu]

El 08/06/2006, a las 3:58, Latchesar Ionkov escribió:

> I don't understand why is all that fuss about the gcc port. If you  
> don't
> like it, don't use it. Few of the current Plan9 users are going to  
> use it.
> But if the gcc port brings more developers to Plan9, I don't see  
> how that
> can be bad.

I am not a developer and I cannot compare gcc with 8c, but from  
seeing Plan9's architecture and comparing it with other OSs I would  
trust the people that said that gcc makes you a lazy developer.

And about bringing new developers, let me make a parable here:
If I move to another country with a different language and customs, I  
will learn their language and their tradition. Adopting GCC to  
attract open source developers is like making french an official  
language in Spain to attract french women. I rejoice on the idea but  
don't think it would work.

Or maybe a better example: it would be like allowing driving on the  
left lane in USA to attract UK visitors. Not using the left lane  
wouldn't be an option, for there would be lots of british using MY  
lane to overtake. And dislexic drivers getting their licenses now for  
they couldn't before.

Best regards,
Ignacio

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/7/06, geoff@collyer.net <geoff@collyer.net> wrote:
> I use f2c when I need to compile Fortran (or, more likely, Ratfor).
> Have GNU extended Fortran too?  Or do you need to compile programs
> that make use of features added to Fortran by later standards (though
> I'm not sure that GNU Fortran will help here)?

GNU Fortran is actually fairly well caught up with F95 at least.  I've
seen traffic on the apple scitech list saying that f2c is completely
inadequate for modern fortran codes.

>
> I guess I don't see what's so offensive about rio and acme.  A hazard
> is that once one starts adding things to attract novice users (e.g.,
> shiney things) or people who are used to some particular (l)unix
> configuration (e.g., windows managers, graphical toolkits, the GNU
> world), the resulting system will be bigger, slower and clumsier.  If
> you use gcc routinely, you lose the speed of 8c.  As an example of the
> cumulative effect of such accretion, a friend reported compiling a Red
> Hat kernel from scratch recently and it only took about an hour (vs.
> the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
> seconds to compile 9pc on oldish PC hardware today).

tcc compiles the links web browser is 1/10th the time of gcc.  This
isn't terribly surprising.  This compiler appears to be x86 only
though, and does it's own assembly and linking too, it can also serve
as a C interpretter.

gcc is not, therefore, always the only choice on linux either.

>
> It may not be feasible, for example due to gcc's asm constructs, but
> it would seem more satisfying to write a gcc-to-c preprocessor.  Of
> course that doesn't help with C++; if only we had a Cfront for current
> C++.
>
>

Sounds like Comeau C++.  A commercial C++ compiler that aims for full
C++ compliance and compiles to other C compiler back ends, gcc is one
of them.

I believe EDG's C++ front end is actually known to be the best C++
front end in the world, and is also a CFront like compiler.  EDG's C++
compiler front end is written in C. :-)

Re: [9fans] gcc on plan9

[quanstro]

On Thu Jun  8 09:11:58 CDT 2006, leimy2k@gmail.com wrote:
> GNU Fortran is actually fairly well caught up with F95 at least.  I've
> seen traffic on the apple scitech list saying that f2c is completely
> inadequate for modern fortran codes.

modern fortran.  two words that should never share the space between
the double-space and the period.

- erik

Re: [9fans] gcc on plan9

[David Leimbach]

On 6/8/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> On Thu Jun  8 09:11:58 CDT 2006, leimy2k@gmail.com wrote:
> > GNU Fortran is actually fairly well caught up with F95 at least.  I've
> > seen traffic on the apple scitech list saying that f2c is completely
> > inadequate for modern fortran codes.
>
> modern fortran.  two words that should never share the space between
> the double-space and the period.
>
> - erik
>

*shrug* there's a lot of new (ish) fortran out there to support for
HPC.  I don't have much of a choice in my job :-).

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 14:16, Christoph Lohmann wrote:
> Good evening.
> 

Hey!


> Am Wed, 7 Jun 2006 14:07:14 -0700 schrieb "Corey" <corey_s@qwest.net>:
> 
> > _If_  one was interested in experimenting in developing an integrated 
> > graphical desktop environment on plan 9, one would use what - pure C?  
> > With what higher-level libraries would one use? Or would one write it
> > all from scratch? 
> 
> There is a "integrated graphical desktop environment" on Plan 9, even if
> you do not call it like that.
> 

Do you use Plan 9 for your general-purpose, everyday, recreational computing
environment?


> So if you really have the moral and the power to even write a line of
> code for a new "integrated graphical desktop environment" on Plan 9
> 

Well, that's sort of what I've been trying to say, (c8=

I have neither the morale nor the power to write even a single line of code
for this new  "integrated graphical desktop environment" on Plan 9 -- I
merely intend to assemble the work that others are doing; I'm like a child
clumsily playing with lego bricks. The best that I can do is help write
the gluework to get it working together nicely.

As I just now read in a different post:

On Wednesday 07 June 2006 15:33, Ronald G Minnich wrote:
"I want plan 9, not linux tarted up to look like Plan 9."

It's like this:

_Were_ there a choice between running a general-purpose/consumer-oriented
Plan 9 "distribution" of sorts, and running yet another linux distro - I would opt
for the Plan 9 "distro" ( or whatever it would be called ); this hypothetical
operating system would of course only be interesting so long as it were
designed complementary to the very cool underlying Plan 9 concepts.

But there currently is no such incarnation/form of Plan 9, and so I sometimes
find myself idly speculating on what sort of task it would be to create one, and
what this conceptual operating system might look like were it embarked upon.


> then it would be done with underlying file servers, where you write "low level"
> libraries, for the graphical applications, that in the end do only a
> simple write() on some file - nothing else.
> 

You give the impression that the only way of writing 9p fileservers and 
consumer-oriented applications on Plan 9 is with pure C, and that this will 
always be the only  way, and that it should always be the only way. 

You  also make it sound as though higher-level libraries and/or object-oriented 
programming on Plan 9 are a complete waste in all circumstances.

I honestly don't understand, but I'm also very ignorant - which is why I was
hoping for friendly explanations on how and why my assumptions don't meet 
the reality. I think the primary rift is that the idea of a general-purpose,
user-grade version of Plan 9 is distastefull and/or useless.

Anyhow, I'm probably just becoming line-noise at this point.  (c8=


Cheers!

Corey

Re: [9fans] gcc on plan9

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 7-Jun-06, at 3:39 PM, Corey wrote:
>
> You  also make it sound as though higher-level libraries and/or  
> object-oriented
> programming on Plan 9 are a complete waste in all circumstances.

Plan 9 is object-oriented.  The objects have a file-like abstraction  
and interactions with the objects are mediated by a network protocol  
that abstracts all the network messiness away.

C++ on Plan 9 is a whole other issue.  It's bad enough that it has  
invaded my work life, having it invade my hobby computing environment  
would just make me sad.  And most C++ is at best what I'd call  
naively object oriented.  C-with-classes is a better name, and,  
frankly, more palatable than what's it has grown into.

I can easily imagine a nice smalltalk implementation for Plan 9 that  
plays well with the 9P servers.  That would be sexy.   But C-double- 
cross is not compatible with Plan 9's "do it cleanly" aesthetic.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEh1fppJeHo/Fbu1wRAsVIAJ469IFwZuhl1KIk0LrPDtPfQxovhACcDlzW
bFdDAwIeg5QbUZswMFokhzo=
=EObv
-----END PGP SIGNATURE-----

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 15:49, Paul Lalonde wrote:
> On 7-Jun-06, at 3:39 PM, Corey wrote:
> >
> > You  also make it sound as though higher-level libraries and/or
> > object-oriented
> > programming on Plan 9 are a complete waste in all circumstances.
> 
> Plan 9 is object-oriented.  The objects have a file-like abstraction
> and interactions with the objects are mediated by a network protocol
> that abstracts all the network messiness away.
>

I've more or less dimly grokked the not-immediately-obvious-but-very-elegant
Plan9-as-object-oriented-via-9p concept; but Plan 9 is not a programming 
language.

To which I'll probably get the response from someone: "OOP is pointless -
you can do every thing OOP can do, using 9p and modular programming in
C."

Which is certainly a valid point, unless for whatever reasons, you are unable
to write a whole framework or whatever from scratch, and would thus selfishly 
prefer to use an existing one.


> C++ on Plan 9 is a whole other issue.  It's bad enough that it has
> invaded my work life, having it invade my hobby computing environment
> would just make me sad. 
>

I don't like C++ either;  I'm merely asking about Objective-C, which I find 
enjoyable and mostly sound.


> I can easily imagine a nice smalltalk implementation for Plan 9 that
> plays well with the 9P servers.  

Yes, that would be cool. 

But when I mention:  "I can easily imagine a nice <insert programming language> 
implementation for Plan 9 that plays well with the 9P servers", I somehow quickly 
make an annoyance of myself.  <grin>  It's weird.


Cheers,

Corey

Re: [9fans] gcc on plan9

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 7-Jun-06, at 4:17 PM, Corey wrote:
>
> I've more or less dimly grokked the not-immediately-obvious-but- 
> very-elegant
> Plan9-as-object-oriented-via-9p concept; but Plan 9 is not a  
> programming
> language.

Agreed - It's more like the CORBA part rather than the language part,  
although much nicer/more uniform.
That said, language bindings to services should be simple to write,  
not the hideous mess we see in the CORBA and COM world.  Sadly, C++  
makes for a hideous mess of these models.
File abstractions wind up being pretty easy and relatively clean.

>
> To which I'll probably get the response from someone: "OOP is  
> pointless -
> you can do every thing OOP can do, using 9p and modular programming in
> C."

OOP isn't pointless - but most supposed OOP code is just a poor  
excuse not to understand your flow control.  My annoyance is that the  
cult of re-use that is associated with most OOP proselytization makes  
the code bloat hugely - I'm as guilty of that as the next guy.   
Compare the STL hash implementation with the the elf hash table  
implementation - the latter works in 20 lines of code, the former  
requires 769 lines of near-opaque code.  Sure, it extends to any  
object you have, but the development cost was huge.  It's good to  
have it, but then people mimic that style with substantially less re- 
usable constructs that aren't nearly as functionally stable as  
hash_map and hash_set.

>
> Which is certainly a valid point, unless for whatever reasons, you  
> are unable
> to write a whole framework or whatever from scratch, and would thus  
> selfishly
> prefer to use an existing one.

Now that's a separate issue, although still touching on re-use.  For  
that one I question the viability of *any* open source "desktop"  
environment and most closed ones too.  The cruftiness that is so- 
called required to satisfy naive users is dead in the way of  
usability for advanced users.  It's sad we've all decided that  
computers have to be easy-to-use, by which is usually meant "require  
little or no training".  Sadly, a little training can go a long way  
to make usability happen for expert users, which is a level most  
users wind up a in a few years: for evidence, see how many windows  
users are willing to muck deep in their menus to change interface  
options.  Perhaps not for their early exposure, but soon enough after  
everyone seems to.  Yuck.

>
> I don't like C++ either;  I'm merely asking about Objective-C,  
> which I find
> enjoyable and mostly sound.

I like it much better than C++, that's for sure.  I'm still not so  
sure about bastard hybrids though :-)

>
>> I can easily imagine a nice smalltalk implementation for Plan 9 that
>> plays well with the 9P servers.
>
> Yes, that would be cool.
>
> But when I mention:  "I can easily imagine a nice <insert  
> programming language>
> implementation for Plan 9 that plays well with the 9P servers", I  
> somehow quickly
> make an annoyance of myself.  <grin>  It's weird.

:-)  I think the key part is that people don't want to see the layers  
and layers of cruft that seem to be involved in any port from the  
linux (GCC) world these days.  Even python is so corrupted by that  
environment I want to scream (I had to port it to PS3 recently, and  
at least the dev kit uses GCC, but even then the platform  
dependencies are hellish to work with).

But mostly I've been finding that rc + awk + sed does most of my 9p  
coding, with surprisingly good results.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEh2MrpJeHo/Fbu1wRAueTAJ9xxU7k91Wzqjn+R6cqEUcQcGmFaACg0Zzi
uDnAaKoJND4amuuJTCBXstE=
=PyZO
-----END PGP SIGNATURE-----

Re: [9fans] gcc on plan9

[quanstro]

On Wed Jun  7 18:38:21 CDT 2006, plalonde@telus.net wrote:
> >
> > To which I'll probably get the response from someone: "OOP is  
> > pointless -
> > you can do every thing OOP can do, using 9p and modular programming in
> > C."
> 
> OOP isn't pointless - but most supposed OOP code is just a poor  
> excuse not to understand your flow control.  My annoyance is that the  
> cult of re-use that is associated with most OOP proselytization makes  
> the code bloat hugely - I'm as guilty of that as the next guy.   
> Compare the STL hash implementation with the the elf hash table  
> implementation - the latter works in 20 lines of code, the former  
> requires 769 lines of near-opaque code.  Sure, it extends to any  
> object you have, but the development cost was huge.  It's good to  
> have it, but then people mimic that style with substantially less re- 
> usable constructs that aren't nearly as functionally stable as  
> hash_map and hash_set.

you're really on to something here.

768/20  ~= 40.  that may be a good proof that hash tables can't be abstracted from
the stuff hashed.

i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.

interfaces like those provided by plan 9 fileservers are much more compelling.
/dev/draw seems to me much more object-oriented than anything i've seen in
c++ or java.  it's ironic that the oop crowd seems to be the biggest poo-pooers
of plan 9.

- erik

Re: [9fans] gcc on plan9

[John Barham]

> i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.

Neither was Stepanov, the creator of the STL:

"STL is not object oriented. I think that object orientedness is
almost as much of a hoax as Artificial Intelligence. I have yet to see
an interesting piece of code that comes from these OO people."

See http://www.stlport.org/resources/StepanovUSA.html.

Re: [9fans] gcc on plan9

[David Leimbach]

> >
> > OOP isn't pointless - but most supposed OOP code is just a poor
> > excuse not to understand your flow control.  My annoyance is that the
> > cult of re-use that is associated with most OOP proselytization makes
> > the code bloat hugely - I'm as guilty of that as the next guy.
> > Compare the STL hash implementation with the the elf hash table
> > implementation - the latter works in 20 lines of code, the former
> > requires 769 lines of near-opaque code.  Sure, it extends to any
> > object you have, but the development cost was huge.  It's good to
> > have it, but then people mimic that style with substantially less re-
> > usable constructs that aren't nearly as functionally stable as
> > hash_map and hash_set.
>
> you're really on to something here.
>
> 768/20  ~= 40.  that may be a good proof that hash tables can't be abstracted from
> the stuff hashed.
>
> i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.

I don't understand why people say OOP and STL in the same sentence.
Just because code is encapsulated and isolated to a class, does not
make that code OO.

In fact, currently, none of the STL classes are even safe to derive
new classes from, based on the fact that none of them have virtual
destructors.

I'd call STL containers and algorithms an attempt at parametric
polymorphism which has been handled better in almost any Functional
Programming language I've ever seen than in C++.

>
> interfaces like those provided by plan 9 fileservers are much more compelling.
> /dev/draw seems to me much more object-oriented than anything i've seen in
> c++ or java.  it's ironic that the oop crowd seems to be the biggest poo-pooers
> of plan 9.
>

I know people who think files should be for files, and that's it.
That abstracting the filesystem to mean anything else is almost as bad
as overloading operators in C++.

I can kind of understand the complaint.

in C++ for example you've got things like

C = A + B;

If A and B are objects of classes, this could mean a lot of different
things as you must define operator + for that class.  A and B don't
even have to be of the same classes, and the same goes for C.  Without
knowing about the data types, it's not really possible to know all the
possible side effects, exceptions, allocations (needless copies that
might be immediately thrown out and how different compilers might
interpret those) etc for a single expression.  In fact there are a lot
of different function calls and code paths that could imply.

The same might be said (though I think with less confusion) when someone says:

echo eject > /dev/<blah>

could be confusing because the file interface and syntax by which we
operate on it is also overloaded.

Now think about Mac OS X again.  Sure it's unix underneath, but does
grandma even know or care about that?  Probably not.  One of my best
friends is a graphic artist who uses it every day.  He asked me about
Terminal.app one day (which would get him a shell and expose him to a
whole other world of functionality).  I told him to ignore it, that
for him, it'd be opening up the wrong can of worms.

For some, ignorance really is bliss.  And never needing to touch the
shell and still be productive is actually a dream come true.

Dave

> - erik
>

Re: [9fans] gcc on plan9

[ems]

Snakes on Plan 9 is starting this summer.
http://www.debian.org/vote/2006/platforms/ari

Re: [9fans] gcc on plan9

[quanstro]

i think the difference is that c++ operator overloading changes the
operator.  instead of emiting an ADD-type instruction, anything could
happen.  using a file as a device doesn't change the file protocol between
client and server;  the same 9p messages apply, regardless of the server
implementing the file.

trying to be parsimonious about semantics leads to strange places.  to be
silly about it, should we reserve "int" for purely abstract integers with
no constraints.  what about intgers on Zn?  or scaled integers? intgers
between a min and max? integers that are used a power of two?

should we have different types of files for spreadsheets than wordprocessors
at the file protocol/namespace level?  

unix said no.  we have One True Namespace™.  or in v7 everything was a file, mostly.

plan 9 said "s:Namespace:& Type:" and btw, if you want the usual things to work,
there are some conventions that need to be followed.

- erik

On Thu Jun  8 09:53:13 CDT 2006, leimy2k@gmail.com wrote:
> >
> > interfaces like those provided by plan 9 fileservers are much more compelling.
> > /dev/draw seems to me much more object-oriented than anything i've seen in
> > c++ or java.  it's ironic that the oop crowd seems to be the biggest poo-pooers
> > of plan 9.
> >
> 
> I know people who think files should be for files, and that's it.
> That abstracting the filesystem to mean anything else is almost as bad
> as overloading operators in C++.
> 
> I can kind of understand the complaint.
> 
> in C++ for example you've got things like
> 
> C = A + B;
> 
> If A and B are objects of classes, this could mean a lot of different
> things as you must define operator + for that class.  A and B don't
> even have to be of the same classes, and the same goes for C.  Without
> knowing about the data types, it's not really possible to know all the
> possible side effects, exceptions, allocations (needless copies that
> might be immediately thrown out and how different compilers might
> interpret those) etc for a single expression.  In fact there are a lot
> of different function calls and code paths that could imply.
> 
> The same might be said (though I think with less confusion) when someone says:
> 
> echo eject > /dev/<blah>
> 
> could be confusing because the file interface and syntax by which we
> operate on it is also overloaded.

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Thu, Jun 08, 2006 at 07:51:32AM -0700, David Leimbach wrote:
> I know people who think files should be for files, and that's it.
> That abstracting the filesystem to mean anything else is almost as bad
> as overloading operators in C++.
 
  I disagree strongly! In fact when I was in Madrid we had a very nice
  conversation with Nemo during which he managed to put in words things
  I've long felt but was never able to pinpoint. Mainly, why such
  thing as abstracting everything as file makes *lots* of sense. 

  Its rather simple, really, as an application developer my ideal world
  would be the one where I can reuse useful components/services literally
  in a manner of LEGO bricks. The world where a component that gives
  me a "binary editor" capability would be equally easily accessible
  from my debugger, my editor, the application I use to edit fonts, etc.
  Ideally I shouldn't even care about where component resides or what
  language/infrastructure it is implemented in. A SOA of sorts. 
  
  Do we live in an ideal world ? Not really, but a before I state why
  Plan 9 comes as close to it as one would hope to get, lets look at
  some of the "proposed" solutions to this universal reusability
  problem. 

  Java comes to mind right away. Its widespread and it abstracts you
  sufficiently enough from the outside world, so that you don't have
  to care how to create threads or windows -- its all part of the
  grandure API. It also provides the level of reusability I've mentioned 
  via [Net]Beans and such. However, the unbelievably high price
  you have to pay for this is that you absolutely have to remain in
  Java's world. Both from an VM and from an API standpoint. Suppose
  I even have that binary editor module coded as a [Net]Bean and
  it works fine in that framework, but can I get to it from my favorite
  editor ? From my favorite debugger ? From a command line prompt ?
  No! I have to use Java and Java alone to "glue" this piece of
  functionality to the rest of my working environment.

  It is sort of like having LEGO bricks which not only do not stick
  to each other if you put 'em together, but require a particular brand 
  of glue to form any sort of complex structure. The glue called Java
  in my previous example, or the glue called C language, or what not...

  Now, the question becomes is it even possible to have anything at all
  which would let my LEGO bricks just stick together ? 

            My answer is -- yes and it is called files! 

  Files are my true universal glue, the lowest common denominator
  of sorts, the one and only API present in absolutely *all* common
  programming languages and systems. 

  It takes a bit of time to realize just how far the lack of files 
  as a universal glues pushed various developers. Do you know 
  that when you do "getline a < /inet/tcp/lport/rhost/rport" in (g)awk
  the right thing happens ? Do you realize how much extra code was
  duplicated and how many bugs were reintroduced ? Same question
  about all these jolly Java APIs -- sure its fun to reinvent the
  wheel, but you should at least start from wood, not from carbon
  molecules...
 
> For some, ignorance really is bliss.  And never needing to touch the
> shell and still be productive is actually a dream come true.
  
  In a world where vendors actually listen to their customers that would
  be a true statement, but I'm yet to see a system where I don't have
  to tweak things so that they feel right.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Bakul Shah]

Roman Shaposhnick <rvs@sun.com> wrote:
> 
>   Its rather simple, really, as an application developer my ideal world
>   would be the one where I can reuse useful components/services literally
>   in a manner of LEGO bricks. The world where a component that gives
>   me a "binary editor" capability would be equally easily accessible
>   from my debugger, my editor, the application I use to edit fonts, etc.
>   Ideally I shouldn't even care about where component resides or what
>   language/infrastructure it is implemented in. A SOA of sorts. 
>   
>   Do we live in an ideal world ? Not really, but a before I state why
>   Plan 9 comes as close to it as one would hope to get, lets look at
>   some of the "proposed" solutions to this universal reusability
>   problem. 

Lisp machines/environments did this 25+ years ago.
Everything is an s-expression is even more fun than
everything is a file!

Files are really like persistent global variables.  Plan9
"files" are sort of like variables with getter/setter
functions.  But you still need lambdas (procedures) as glue.

For a while I have wanted to graft Scheme as a system
programming language on top of Plan9 (like system) but not
badly enough.

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

>
> Lisp machines/environments did this 25+ years ago.
> Everything is an s-expression is even more fun than
> everything is a file!

I don´t agree. The problem with lisp is that you don´t have
protection. Didn´t you manage to bring down the whole emacs
by, say, implementing your CD player in elisp?. Now, in
Plan 9 processes are really isolated. If one of them crashes, the other
ones stay alive (Probably).

I mean, you have "red lines" that protect you. I wouldn´t throw away
my MMU, just for protection.

Re: [9fans] gcc on plan9

[quanstro]

which is to say that plan 9/unix don't take files to that extent.  
processes are not files, for example, /proc notwithstanding.

- erik

On Fri Jun  9 16:34:08 CDT 2006, nemo@lsub.org wrote:
> >
> > Lisp machines/environments did this 25+ years ago.
> > Everything is an s-expression is even more fun than
> > everything is a file!
> 
> I don´t agree. The problem with lisp is that you don´t have
> protection. Didn´t you manage to bring down the whole emacs
> by, say, implementing your CD player in elisp?. Now, in
> Plan 9 processes are really isolated. If one of them crashes, the other
> ones stay alive (Probably).

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

Well, in Plan B we made an experimental /cmd, where processes
were files in the sense that mkdir created one process, cp was used
to supply the binary and the like. It did work, but it seemed more
convenient to use the distributed plumbing to deliver cmd execution
requests, and then, ox, the shell underlying omero, is in charge of
executing the commands. Now we are back into /proc.

On 6/9/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> which is to say that plan 9/unix don't take files to that extent.
> processes are not files, for example, /proc notwithstanding.
>
> - erik
>
> On Fri Jun  9 16:34:08 CDT 2006, nemo@lsub.org wrote:
> > >
> > > Lisp machines/environments did this 25+ years ago.
> > > Everything is an s-expression is even more fun than
> > > everything is a file!
> >
> > I don´t agree. The problem with lisp is that you don´t have
> > protection. Didn´t you manage to bring down the whole emacs
> > by, say, implementing your CD player in elisp?. Now, in
> > Plan 9 processes are really isolated. If one of them crashes, the other
> > ones stay alive (Probably).
>
>

Re: [9fans] gcc on plan9

[quanstro]

it is interesting that plan 9 could be rearranged as a classic µkernel, using
9p for message passing.  a process server could do just that.
before you kill me, note the difference between "interesting" and "better." ☺

how much slower is an exec over /cmd than via fork(2)/exec(2)?

- erik

On Fri Jun  9 16:59:40 CDT 2006, nemo@lsub.org wrote:
> Well, in Plan B we made an experimental /cmd, where processes
> were files in the sense that mkdir created one process, cp was used
> to supply the binary and the like. It did work, but it seemed more
> convenient to use the distributed plumbing to deliver cmd execution
> requests, and then, ox, the shell underlying omero, is in charge of
> executing the commands. Now we are back into /proc.

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

Without caching, a lot. When you cache the file nearby /cmd, and
you avoid copying if you can do so, it´s not so slow (don´t have numbers
right now, sorry).

On 6/10/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> it is interesting that plan 9 could be rearranged as a classic µkernel, using
> 9p for message passing.  a process server could do just that.
> before you kill me, note the difference between "interesting" and "better." ☺
>
> how much slower is an exec over /cmd than via fork(2)/exec(2)?
>
> - erik
>
> On Fri Jun  9 16:59:40 CDT 2006, nemo@lsub.org wrote:
> > Well, in Plan B we made an experimental /cmd, where processes
> > were files in the sense that mkdir created one process, cp was used
> > to supply the binary and the like. It did work, but it seemed more
> > convenient to use the distributed plumbing to deliver cmd execution
> > requests, and then, ox, the shell underlying omero, is in charge of
> > executing the commands. Now we are back into /proc.
>
>

Re: [9fans] gcc on plan9

[quanstro]

is this also true for everything running on the same machine?
i'd be interested in what the performance difference is in that case.

does the kernel or a userlevel fs serve /cmd?

- erik

On Fri Jun  9 17:18:40 CDT 2006, nemo@lsub.org wrote:
> Without caching, a lot. When you cache the file nearby /cmd, and
> you avoid copying if you can do so, it´s not so slow (don´t have numbers
> right now, sorry).
> 
> On 6/10/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > it is interesting that plan 9 could be rearranged as a classic µkernel, using
> > 9p for message passing.  a process server could do just that.
> > before you kill me, note the difference between "interesting" and "better." ☺
> >
> > how much slower is an exec over /cmd than via fork(2)/exec(2)?
> >
> > - erik
> >
> > On Fri Jun  9 16:59:40 CDT 2006, nemo@lsub.org wrote:
> > > Well, in Plan B we made an experimental /cmd, where processes
> > > were files in the sense that mkdir created one process, cp was used
> > > to supply the binary and the like. It did work, but it seemed more
> > > convenient to use the distributed plumbing to deliver cmd execution
> > > requests, and then, ox, the shell underlying omero, is in charge of
> > > executing the commands. Now we are back into /proc.

Re: [9fans] gcc on plan9

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

> > Lisp machines/environments did this 25+ years ago.
> > Everything is an s-expression is even more fun than
> > everything is a file!
> 
> I don´t agree. The problem with lisp is that you don´t have
> protection. Didn´t you manage to bring down the whole emacs
> by, say, implementing your CD player in elisp?. Now, in
> Plan 9 processes are really isolated. If one of them crashes, the other
> ones stay alive (Probably).

Isolation by MMU is a separate issue.  If you wish you can
think of a Lisp machine as analogous to Inferno, with Lisp as
its virtual machine language!  Also Lisp machine != emacs.
In any case even you admit (with your parenthetical
"Probably") that while at process level there is isolation
you can still run into trouble as there may be higher level
dependencies.

> I mean, you have "red lines" that protect you. I wouldn´t throw away
> my MMU, just for protection.

I understand that well.  My point was only that what Roman
wanted was already available 25+ years ago; not that it was
perfect -- too bad that branch got pruned too early.

In any case Plan 9 and LM are still like working under the
hood or playing with legos.  If you just want to drive your
lego car soon you discover they don't make great cars (even
great toy cars).

Re: [9fans] gcc on plan9

[quanstro]

the mmu business is a red herring.  the point here is that a process
and a file are fundamentally different.  a file is a sequence of bytes.
a process is a collection of resources (threads, file descriptors, memory
segments, etc.) which are scheduled together.

i have no experience with lisp machines, but i'm fairly confident that
it is not true that s-expressions are processes.

did lisp machines even do multiprogramming?

- erik

On Fri Jun  9 17:23:28 CDT 2006, bakul+plan9@bitblocks.com wrote:
> > > Lisp machines/environments did this 25+ years ago.
> > > Everything is an s-expression is even more fun than
> > > everything is a file!
> > 
> > I don't agree. The problem with lisp is that you don't have
> > protection. Didn't you manage to bring down the whole emacs
> > by, say, implementing your CD player in elisp?. Now, in
> > Plan 9 processes are really isolated. If one of them crashes, the other
> > ones stay alive (Probably).
> 
> Isolation by MMU is a separate issue.  If you wish you can
> think of a Lisp machine as analogous to Inferno, with Lisp as
> its virtual machine language!  Also Lisp machine != emacs.
> In any case even you admit (with your parenthetical
> "Probably") that while at process level there is isolation
> you can still run into trouble as there may be higher level
> dependencies.

Re: [9fans] gcc on plan9

[Bakul Shah]

quanstro@quanstro.net wrote:
> the mmu business is a red herring.  the point here is that a process
> and a file are fundamentally different.  a file is a sequence of bytes.
> a process is a collection of resources (threads, file descriptors, memory
> segments, etc.) which are scheduled together.

You are assuming a very traditional system.  But there are
other ways of solving the same problems.  For instance, you
can have a separate thread of control in the same address
space and not have it share anything with another thread.  If
the system guaranteed you that (modulo h/w malfunction) it
will behave sanely (no buffer overflows, no wild ptrs, no
"accidental" sharing, no way to reference freed up storage as
a normal variable), that is a viable solution with some
significant benefits as well as some shortcomings.

> i have no experience with lisp machines, but i'm fairly confident that
> it is not true that s-expressions are processes.

Whoever said s-expressions are processes? 

> did lisp machines even do multiprogramming?

They did.  Symbolics even provided virtual memory.  You may
wish to check out the wikipedia entries on lisp machines and
symbolics and follow some links if interested.

Perhaps you and nemo are assuming that a Lisp machine is just
a single threaded Lisp interpreter?  Not so.  They were
sophisticated beasts with excellent debugging support,
networking, graphics and what not.

Re: [9fans] gcc on plan9

[Francisco J Ballesteros]

> i have no experience with lisp machines, but i'm fairly confident that
> it is not true that s-expressions are processes.
>
> did lisp machines even do multiprogramming?

I used them. They were nice. For those who didn´t tried them, quite
a bit like emacs. Not too modular, that is what I meant. In Plan 9
processes and file interfaces lead to highly modular systems without
much effort. I´m now addict to that, and wouldn´t like to loose it.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Francisco J Ballesteros wrote:
>> i have no experience with lisp machines, but i'm fairly confident that
>> it is not true that s-expressions are processes.
>>
>> did lisp machines even do multiprogramming?
> 
> 
> I used them. They were nice. For those who didn´t tried them, quite
> a bit like emacs. Not too modular, that is what I meant. In Plan 9
> processes and file interfaces lead to highly modular systems without
> much effort. I´m now addict to that, and wouldn´t like to loose it.

We had lisp machines on our CM-2 years ago.

What killed them? The SPARCs came in and ran all the LISP faster.

They say  in a corner after that. I loved 'em, but ...

ron

Re: [9fans] gcc on plan9

[LiteStar numnums]

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

> What killed them? The SPARCs came in and ran all the LISP faster.
Didn't Genera take something like 1/2 hour to boot & configure itself?
Even on the LISPM emulators Genera takes about 10 mins to boot
on a decently fast alpha...
A decent reading set for any one interested:
http://bitsavers.org/pdf/mit/cadr/chinual_6thEd_Jan84/
The section on Processes is relatively interesting as well.


-- 
Lead thou me on, O Zeus, and Destiny,
To that goal long ago to me assigned.
I'll follow and not falter; if my will
Prove weak and craven, still I'll follow on.
-- Epictetus

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

Re: [9fans] gcc on plan9

[Harri Haataja]

On Fri, Jun 09, 2006 at 03:22:22PM -0700, Bakul Shah wrote:
> Isolation by MMU is a separate issue.  If you wish you can
> think of a Lisp machine as analogous to Inferno, with Lisp as
> its virtual machine language!  Also Lisp machine != emacs.

What I have for a fair while dremed about is a lisp (preferrably scheme)
that uses Inferno as a VM.

-- 
Last night I played a blank tape at full blast. The mime next door went nuts.
		-- Stephen Wright

Re: [9fans] gcc on plan9

[Bruce Ellis]

I've looked into that (so has Charles I think).  It is quite feasible.

brucee

On 6/10/06, Harri Haataja <harriha@mail.student.oulu.fi> wrote:
> On Fri, Jun 09, 2006 at 03:22:22PM -0700, Bakul Shah wrote:
> > Isolation by MMU is a separate issue.  If you wish you can
> > think of a Lisp machine as analogous to Inferno, with Lisp as
> > its virtual machine language!  Also Lisp machine != emacs.
>
> What I have for a fair while dremed about is a lisp (preferrably scheme)
> that uses Inferno as a VM.
>
> --
> Last night I played a blank tape at full blast. The mime next door went nuts.
>                -- Stephen Wright
>

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Fri, Jun 09, 2006 at 03:22:22PM -0700, Bakul Shah wrote:
> > I mean, you have "red lines" that protect you. I wouldnб╢t throw away
> > my MMU, just for protection.
> 
> I understand that well.  My point was only that what Roman
> wanted was already available 25+ years ago; not that it was
> perfect -- too bad that branch got pruned too early.
  
  Point taken. But here are two problems I have with native LISP 
  systems (if you find any of them to be out of lack of education
  please let me know ;-)

     * there's no sane way to map LISP into modern hardware. Whether
       we like it or not, the modern CPUs are really C language VMs
       all the MMU business is there only to support a particular language
       construct called pointers, yet let more than one process run
       on a system. Sun has done some pretty cool things with trying
       to build a hardware version of JavaVM and that thing had a
       potential: no MMU, etc. but it got hit with a different evolutionary
       artifact of the modern hardware -- the cache. Basically there
       were no sane way to map the Garbage Collection into the hardware.

     * LISP makes it harder for nonLISP things to reuse system components.
       Or at least it feels that way to me: suppose we end up with an ultra 
       efficient hardware implementation of a LISP system -- but can we build 
       a Java layer on top of it ? What about /bin/rc layer ? What about 
       awk layer ? How would these three talk to each other on such a system ?
  
Thanks,
Roman.

Re: [9fans] gcc on plan9

[Iruatã Souza (muzgo)]

>      * there's no sane way to map LISP into modern hardware. Whether
>        we like it or not, the modern CPUs are really C language VMs
>        all the MMU business is there only to support a particular language
>        construct called pointers, yet let more than one process run
>        on a system. Sun has done some pretty cool things with trying
>        to build a hardware version of JavaVM and that thing had a
>        potential: no MMU, etc. but it got hit with a different evolutionary
>        artifact of the modern hardware -- the cache. Basically there
>        were no sane way to map the Garbage Collection into the hardware.
I don't know if this is a silly question but could you explain me
(privately if so you wish) what's is the big issue with that (GC
hardware mapping)?

>      * LISP makes it harder for nonLISP things to reuse system components.
>        Or at least it feels that way to me: suppose we end up with an ultra
>        efficient hardware implementation of a LISP system -- but can we build
>        a Java layer on top of it ? What about /bin/rc layer ? What about
>        awk layer ? How would these three talk to each other on such a system ?
>

What do you mean by 'layer'? Does a prolog interpreter written is Lisp
satisfies your definition?
I have somewhere in my bookmarks an emulator of the MIT CADR Lisp
Machine for x86 machines (for UN*X I guess).
Let me know if you want that link to answer some of your questions.

iru (muzgo)

Re: [9fans] gcc on plan9

[Roman Shaposhnik]

On Sat, 2006-06-10 at 01:37 -0300, Iruatã Souza (muzgo) wrote:
> >      * there's no sane way to map LISP into modern hardware. Whether
> >        we like it or not, the modern CPUs are really C language VMs
> >        all the MMU business is there only to support a particular language
> >        construct called pointers, yet let more than one process run
> >        on a system. Sun has done some pretty cool things with trying
> >        to build a hardware version of JavaVM and that thing had a
> >        potential: no MMU, etc. but it got hit with a different evolutionary
> >        artifact of the modern hardware -- the cache. Basically there
> >        were no sane way to map the Garbage Collection into the hardware.
>
> I don't know if this is a silly question but could you explain me
> (privately if so you wish) what's is the big issue with that (GC
> hardware mapping)?

  Its not a silly question at all. There's much more to it than I was
able to cram into the above passage. For more details see this:
    http://research.sun.com/techrep/2005/abstract-143.html

A very different approach for trying to treat memory as part of general
purpose virtual machine and make it do more than load/store has been
tried by Elbrus-3 (a second generation USSR super computer). And that
beast was the most fun to write compilers for. That is, until Itanium
came about. ;-)

> 
> >      * LISP makes it harder for nonLISP things to reuse system components.
> >        Or at least it feels that way to me: suppose we end up with an ultra
> >        efficient hardware implementation of a LISP system -- but can we build
> >        a Java layer on top of it ? What about /bin/rc layer ? What about
> >        awk layer ? How would these three talk to each other on such a system ?
> >
> 
> What do you mean by 'layer'?

  Reading a bit further in this thread you can find an excellent summary
of what I meant by 'layer' and 'talk' in a posting from Roger.

>  Does a prolog interpreter written is Lisp
> satisfies your definition?
> I have somewhere in my bookmarks an emulator of the MIT CADR Lisp
> Machine for x86 machines (for UN*X I guess).
> Let me know if you want that link to answer some of your questions.

  See, that's exactly the problem -- it *is* and emulator (and to my
knowledge there's no other way for LISP) and, as Roger quite elegantly
put it: "Lisp provides a very expressive framework, but it's too rich.
its very richness is an obstacle to the problem that 9p
solves - the component-level connection of software components."

Thanks,
Roman.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[quanstro]

this glue is called /bin/rc.  

- erik

On Fri Jun  9 16:28:51 CDT 2006, bakul+plan9@bitblocks.com wrote:
> 
> Files are really like persistent global variables.  Plan9
> "files" are sort of like variables with getter/setter
> functions.  But you still need lambdas (procedures) as glue.

Re: [9fans] gcc on plan9

[rog]

> Lisp machines/environments did this 25+ years ago.
> Everything is an s-expression is even more fun than
> everything is a file!

the advantage that the file metaphor has is that it has a
small fixed number of entities (at one level). all the operations
on those entities have intuitive and well-defined meanings.

this means you can write useful software that operates only
in terms of those operations.

if i'm writing a service, it is *not* usually expressed
most naturally as a set of file operations. if one is
providing an API within a given framework (e.g. C, Java RMI, Lisp, TCP/IP)
then the natural tendency is to map one-for-one
operations on the service to entities in the API.
for instance a Java RMI interface will tend to have one
method for each operation on the service; a TCP/IP interface
will define a protocol where each message corresponds similarly.

by forcing developers to express a service in terms of
a small number of primitive operations, we automatically
gain compatibility with anything else that uses those operations.

of course the danger with doing this is that it becomes
too hard to express important parts of the service's interface;
that there's no easy and obvious way of setting up the mapping.

the beauty with 9p, as i see it, is that the operations provided
by many kinds of service can be mapped quite closely and intuitively into
9p operations. and that those operations themselves naturally provide
multiplexing at several different levels, and are efficiently implementable.

Lisp provides a very expressive framework, but it's too rich.
its very richness is an obstacle to the problem that 9p
solves - the component-level connection of software components.

Re: [9fans] gcc on plan9

[Christoph Lohmann]

Good evening.

Am Wed, 7 Jun 2006 15:39:43 -0700 schrieb "Corey" <corey_s@qwest.net>:

> Do you use Plan 9 for your general-purpose, everyday, recreational
> computing environment?

Yes.

> I have neither the morale nor the power to write even a single line of
> code for this new  "integrated graphical desktop environment" on Plan 9
> -- I merely intend to assemble the work that others are doing; I'm like
> a child clumsily playing with lego bricks. The best that I can do is
> help write the gluework to get it working together nicely.

So why are you discussing this, when you are not going to write any source
code?

> _Were_ there a choice between running a
> general-purpose/consumer-oriented Plan 9 "distribution" of sorts, and
> running yet another linux distro - I would opt for the Plan 9
> "distro" ( or whatever it would be called ); this hypothetical
> operating system would of course only be interesting so long as it were
> designed complementary to the very cool underlying Plan 9 concepts.

That is only a propaganda position and not a technical one. Propaganda is
boring.

> You give the impression that the only way of writing 9p fileservers and 
> consumer-oriented applications on Plan 9 is with pure C, and that this
> will always be the only  way, and that it should always be the only
> way. 

No, I said, that we use file servers in Plan 9, that speak 9P or the
appropriate syscalls. C is just good taste, but you can still do the
same in whatever language you like.

> You  also make it sound as though higher-level libraries and/or
> object-oriented programming on Plan 9 are a complete waste in all
> circumstances.

Yes they are, but that is only a question of taste.

> I honestly don't understand, but I'm also very ignorant - which is why
> I was hoping for friendly explanations on how and why my assumptions
> don't meet the reality. I think the primary rift is that the idea of a
> general-purpose, user-grade version of Plan 9 is distastefull and/or
> useless.

First define "general-purpose", "user-grade", "distastefull" and
"useless".

> Anyhow, I'm probably just becoming line-noise at this point.  (c8=

Yes.

Sincerely,

Christoph

Re: [9fans] gcc on plan9

[Dan Cross]

On Thu, Jun 08, 2006 at 12:56:35AM +0200, Christoph Lohmann wrote:
> Good evening.

Why do you always put the appropriate greeting of the day in your emails?

> > I have neither the morale nor the power to write even a single line of
> > code for this new  "integrated graphical desktop environment" on Plan 9
> > -- I merely intend to assemble the work that others are doing; I'm like
> > a child clumsily playing with lego bricks. The best that I can do is
> > help write the gluework to get it working together nicely.
> 
> So why are you discussing this, when you are not going to write any source
> code?

Because he doesn't want to invent a new window system and programming
abstractions for it, but he's interesting in using one if it already exists?
Why shouldn't he discuss it?

What a stupid, arrogantly elitist attitude.

> That is only a propaganda position and not a technical one. Propaganda is
> boring.

More wisdom from the IRC crowd.  What, collectively, have you people ever
done?  We're still waiting for Uriel's 9load replacement, if I recall
correctly.

	- Dan C.

Re: [9fans] gcc on plan9

[Federico G. Benavento]

> On Thu, Jun 08, 2006 at 12:56:35AM +0200, Christoph Lohmann wrote:
>> Good evening.
> 
> Why do you always put the appropriate greeting of the day in your emails?
> 
>> > I have neither the morale nor the power to write even a single line of
>> > code for this new  "integrated graphical desktop environment" on Plan 9
>> > -- I merely intend to assemble the work that others are doing; I'm like
>> > a child clumsily playing with lego bricks. The best that I can do is
>> > help write the gluework to get it working together nicely.
>> 
>> So why are you discussing this, when you are not going to write any source
>> code?
> 
> Because he doesn't want to invent a new window system and programming
> abstractions for it, but he's interesting in using one if it already exists?
> Why shouldn't he discuss it?
> 
> What a stupid, arrogantly elitist attitude.
> 
>> That is only a propaganda position and not a technical one. Propaganda is
>> boring.
> 
> More wisdom from the IRC crowd.  What, collectively, have you people ever
> done?  We're still waiting for Uriel's 9load replacement, if I recall
> correctly.
> 

you can run "9fs sources; cd /n/sources/contrib/zwansch; ls", can you?

judging all "the IRC crowd" by what uriel said is the same as judging all 9fans by what you say.

Federico G. Benavento

Re: [9fans] gcc on plan9

[Dan Cross]

On Wed, Jun 07, 2006 at 08:32:12PM -0300, Federico G. Benavento wrote:
> you can run "9fs sources; cd /n/sources/contrib/zwansch; ls", can you?

At the moment, no, I can't.

> judging all "the IRC crowd" by what uriel said is the same as judging all
> 9fans by what you say.

It's not just that, but the snarky attitudes and IRC logs, and the attitudes
that, ``we use Plan 9, so we're better than everyone else.''  I'm sorry, I'm
not convinced.

	- Dan C.

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 15:56, Christoph Lohmann wrote:
> Am Wed, 7 Jun 2006 15:39:43 -0700 schrieb "Corey" <corey_s@qwest.net>:
> 
> > Do you use Plan 9 for your general-purpose, everyday, recreational
> > computing environment?
> 
> Yes.
>

That's definitely remarkable, and respect-worthy.

Not necessarily because you use Plan 9, but because of all the things you
obviously _don't_ use while using Plan 9 - such as graphical/current web-browsing 
apps, various media apps, pim apps, vector graphics editing apps, spreadsheet
and publishing apps, pdf, relational database management systems, etc. etc.


> > I have neither the morale nor the power to write even a single line of
> > code for this new  "integrated graphical desktop environment" on Plan 9
> > -- I merely intend to assemble the work that others are doing; I'm like
> > a child clumsily playing with lego bricks. The best that I can do is
> > help write the gluework to get it working together nicely.
> 
> So why are you discussing this, when you are not going to write any source
> code?
>

Because I firmly believe that writing source code is for suckers!

Wait, no - because I am not Super-Programmer. And also because, one of the 
primary benefits of open-source software and code-reuse in general is... well,
so. that. people. may. reuse. code.


> > You give the impression that the only way of writing 9p fileservers and 
> > consumer-oriented applications on Plan 9 is with pure C, and that this
> > will always be the only  way, and that it should always be the only
> > way. 
> 
> No, I said, that we use file servers in Plan 9, that speak 9P or the
> appropriate syscalls.
>

Appologies for misinterpreting your words.

I had got the impression that you were rejecting the notion that using an 
object-oriented language with some higher-level libraries is a potentially 
more suitable basis as the foundation for a more fully-realized integrated 
user environment on Plan 9 than is pure-C.


> C is just good taste, but you can still do the same in whatever language you 
> like. 
> 

That seems reasonable.

Which low-level languages besides C are currently available on Plan 9? 

For instance, I was merely asking about objective-c; which is not an option at 
this time, nor will it perhaps ever be an option if current gcc and it's ugly friends 
are not ported. Alas, the world may never see my all-new, totally awesome os.

So here's the rub - whatever existing language and/or environment besides
C or perhaps Limbo one would like to use under Plan 9, requires either a port, 
or a complete rewrite. But there appears to be some negative-feedback  on 
porting the gnu-land toolchain, and complete rewrites require unrealistic
amounts of time and effort and man hours to implement


Cheers,

Corey

Re: [9fans] gcc on plan9

[jmk]

When I got home this evening after a very frustrating
couple of days (weeks, really) and found my mailbox slashdotted
with this, it took physical restraint to prevent me from
replying.

But this was too good to resist:

On Wed Jun  7 20:33:26 EDT 2006, corey_s@qwest.net wrote:
> ...
> Wait, no - because I am not Super-Programmer. And also because, one of the 
> primary benefits of open-source software and code-reuse in general is... well,
> so. that. people. may. reuse. code.
> ...

You missed the 'bad' before 'code'.

People are lazy and stupid (me included) and will always look for
the easy way out. Open Source (as it is generally understood) has
merely lowered the standard for entry.

Lucho's work to upgrade David Hogan's GCC port is being done for a
very particular purpose, it's part of a Department of Energy research
project looking at operating system requirements for the next
generation of peta-scale supercomputers and it's necessary to run
some of the accepted supercomputer applications on Plan 9 for comparison.
The resulting GCC will be, as now, walled off in its own ghetto and
not play any part in the day to day life or death struggles of Plan 9.
If it proves to be too difficult to get the targeted applications to
run this way, we'll look for another solution.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

jmk@plan9.bell-labs.com wrote:

> If it proves to be too difficult to get the targeted applications to
> run this way, we'll look for another solution.

exact-a-mundo. Whatever that word means.

We've already looked at a few things here that we have not discussed, 
including source-to-source transformation using the U. Oregon PDT. It's 
just a messy problem. We have yet to find a really satisfying solution. 
I can't say I like the gcc path, but we've tried a fair number of ideas 
and we keep getting back to that one.

ron

Re: [9fans] gcc on plan9

[Ronald G Minnich]

so, end of this thread, we hope.

GARSH, Mickey, I had no idea this would happen. You make one simple 
comment, and ... ah well.

anyways, a few thoughts on another tangent.

linux nowadays is all about building a windows desktop. BORING. Or a Mac 
OSX ripoff desktop. BORING. And just look at all that great vista stuff. 
oh boy, I can slant my windows or something. Who the F*** cares?

What if you had a window manager that could be recursive? that would set 
it up so you can name windows by a path name? that would let you treat 
the recursive desktops -- to any level -- as just another window? that 
would trivially allow you to connect mouse clicks in a window to control 
actions for one or more other windows (i.e. you could logically group 
windows and then control all of them via mouse clicks)? That would maybe 
let you easily connect output from a process in one window to another? 
that would let you build little widgets that  could easily control other 
windows? That would let you display all window state in another window? 
That would let you set, say, all windows with a browser with the label 
abaco-### (### a number), with a simple text command; and let you find 
all windows with the label abaco.* with, in the limit, a grep? That 
would make it easy to group all windows with the label 'abaco.*' so that 
you could say 'hide all abaco' with a simple script?

Wouldn't that be neat? I mean, that's a real bitch in X, right?

Except ... you already have it.

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnik]

Ronald G Minnich wrote:
> so, end of this thread, we hope.
Well, I've writing a reply to your earlier email in a separate window, 
but except that
one (and one question which I'm saving for the end of this email) I 
think we've had enough.

The discussion helped me understand where you guys are coming from and 
why gcc is
just a means to an end for you. One question that I still have, though, 
is what
makes you think that once you're done with porting gcc (big task) and 
porting HPC apps to
gcc/Plan9 (even bigger one!) they will *execute* faster than they do on 
Linux ? Or is the
ease of building clusters (along the lines of what you've presented at 
SuperComputing in
Seattle) alone worth the trouble. Please help me understand (and feel 
free to change the
subject ;-)).

> linux nowadays is all about building a windows desktop. BORING. Or a 
> Mac OSX ripoff desktop. BORING. And just look at all that great vista 
> stuff. oh boy, I can slant my windows or something. Who the F*** cares?
  Unwashed masses, perhaps ? ;-)

> What if you had a window manager that could be recursive? that would 
> set it up so you can name windows by a path name? that would let you 
> treat the recursive desktops -- to any level -- as just another 
> window? that would trivially allow you to connect mouse clicks in a 
> window to control actions for one or more other windows (i.e. you 
> could logically group windows and then control all of them via mouse 
> clicks)? That would maybe let you easily connect output from a process 
> in one window to another? that would let you build little widgets 
> that  could easily control other windows? That would let you display 
> all window state in another window? That would let you set, say, all 
> windows with a browser with the label abaco-### (### a number), with a 
> simple text command; and let you find all windows with the label 
> abaco.* with, in the limit, a grep? That would make it easy to group 
> all windows with the label 'abaco.*' so that you could say 'hide all 
> abaco' with a simple script?
>
> Wouldn't that be neat? I mean, that's a real bitch in X, right?
>
> Except ... you already have it.
  You're absolutely onto something here, Ron! In fact, if everything 
goes right, I really want to explore
a possibility of building a clean desktop (don't laugh yet!) on top of 
Plan9. I really think that what Nemo
has been doing with building UIs is quite convincing and has lots of 
potential. But I have to start at
even lower level, making "/dev/draw" do all the basic things I care 
about in a desktop.

Will see where it goes, but one thing for sure -- I'll be asking lots of 
questions in this forum ;-)

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnik wrote:
> One question that I still have, though, 
> is what
> makes you think that once you're done with porting gcc (big task) and 
> porting HPC apps to
> gcc/Plan9 (even bigger one!) they will *execute* faster than they do on 
> Linux ?

Excellent question.

It's all about parallel performance; making sure your 1000 nodes run 
1000 times as fast as 1 node, or, if they don't, that it's Somebody 
Else's Problem. The reason that the OS can impact parallel performance 
boils down to the kinds of tasks that go on in OSes that can be run at 
awkward times,and in turn interfere with parallel applications, and 
result in degraded performance. (for another approach, see Cray's 
synchronised scheduler work; make all nodes schedule the app at the same 
time).

Imagine you have one of these lovely apps, on a 1000-node cluster with a 
5-microsecond latency network. Let us further imagine (this stuff 
exists; see Quadrics) that you can do a broadcast/global sum op in 5 
microseconds. After 1 millisecond, they all need to talk to each other, 
and can not proceed until they're all agreed on (say) the value of a 
computed number -- e.g. some sort of global sum of a variable held by 
each of 1000 procs. The generic term for this type of thing is 'global 
reduction' -- you reduce a vector to a scalar of some sort.

The math is pretty easy to do, but it boils down to this: OS activities 
can interfere with, say, just one task, and kill the parallel 
performance of the app, making your 1000-node app run like a 750 node 
app -- or worse.

Pretend you're delayed one microsecond; do the math; it's depressing. 
One millisecond compute interval is a really extreme case, chosen for 
ease of illustration, but ...

In the clustering world, what a lot of people do is run real heavy nodes 
in clusters -- they have stuff like cron running, if you can believe it! 
They pretty much do a full desktop install, then turn off a few daemons, 
and away they go. Some really famous companies actually run clusters 
this way -- you'd be surprised at who. So do some famous gov't labs.

If they're lucky, interference never hits them. If they're not, they get 
less-than-ideal app performance. Then, they draw a conjecture from the 
OS interference that comes with such bad configuration: you can't run a 
cluster node with anything but a custom OS which has no clock 
interrupts, and, for that matter, no ability to run more than one 
process at a time. See the computational node kernel on the BG/L for one 
example, or the catamount kernel on Red Storm. Those kernels are really 
constrained; just running one proc at a time is only part of the story.

Here at LANL, we run pretty light cluster nodes.

Here is a cluster node running xcpu (under busybox, as you can see):
     1 ?        S      0:00 /bin/ash /linuxrc
     2 ?        S      0:00 [migration/0]
     3 ?        SN     0:00 [ksoftirqd/0]
     4 ?        S      0:00 [watchdog/0]
     5 ?        S      0:00 [migration/1]
     6 ?        SN     0:00 [ksoftirqd/1]
     7 ?        S      0:00 [watchdog/1]
     8 ?        S      0:00 [migration/2]
     9 ?        SN     0:00 [ksoftirqd/2]
    10 ?        S      0:00 [watchdog/2]
    11 ?        S      0:00 [migration/3]
    12 ?        SN     0:00 [ksoftirqd/3]
    13 ?        S      0:00 [watchdog/3]
    14 ?        S<     0:00 [events/0]
    15 ?        S<     0:00 [events/1]
    16 ?        S<     0:00 [events/2]
    17 ?        S<     0:00 [events/3]
    18 ?        S<     0:00 [khelper]
    19 ?        S<     0:00 [kthread]
    26 ?        S<     0:00 [kblockd/0]
    27 ?        S<     0:00 [kblockd/1]
    28 ?        S<     0:00 [kblockd/2]
    29 ?        S<     0:00 [kblockd/3]
   105 ?        S      0:00 [pdflush]
   106 ?        S      0:00 [pdflush]
   107 ?        S      0:00 [kswapd1]
   109 ?        S<     0:00 [aio/0]
   108 ?        S      0:00 [kswapd0]
   110 ?        S<     0:00 [aio/1]
   111 ?        S<     0:00 [aio/2]
   112 ?        S<     0:00 [aio/3]
   697 ?        S<     0:00 [kseriod]
   855 ?        S      0:00 xsrv -D 0 tcp!*!20001
   857 ?        S      0:00 9pserve -u tcp!*!20001
   864 ?        S      0:00 u9fs -a none -u root -m 65560 -p 564
   865 ?        S      0:00 /bin/ash

see how little we have running? Oh, but wait, what's all that stuff in 
[]? It's the stuff we can't turn off. Note there is per-cpu stuff, and 
other junk. Note that this node has been up for five hours, and this 
stuff is pretty quiet(0 run time); our nodes are the quietest (in the OS 
interference sense) Linux nodes I have yet seen. But, that said, all 
this can hit you.

And, in Linux, there's a lot of stuff people are finding you can't turn 
off. Lots of timers down there, lots of magic that goes on, and you just 
can't turn it off, or adjust it, try as you might.

Plan 9, our conjecture goes, is a small, tight, kernel, with lots of 
stuff moved to user mode (file systems); and, we believe that the Plan 9 
architecture is a good match to future HPC (High Performance Computing) 
systems, as typified by Red Storm and BG/L: small, fixed-configuration 
nodes with memory, network, CPU, and nothing else. The ability to not 
even have a file system on the node is a big plus. The ability to 
transparently have the file system remote/local puts the application 
into the driver's seat as to how the node is configured, and what 
tradeoffs are made; the system as a whole is incredibly flexible.

Our measurements, so far, do show that Plan 9 is "quieter" than Linux. A 
full Plan 9 desktop has less OS noise than a Linux box at the login 
prompt. This matters.

But it only matters if people can run their apps. Hence our concern 
about getting gcc-based cra-- er, applications code, running.

I'm not really trying to make Plan 9 look like Linux. I just want to run 
MPQC for a friend of mine :-)

thanks

ron

Re: [9fans] gcc on plan9

[Federico G. Benavento]

> I'm not really trying to make Plan 9 look like Linux. I just want to run 
> MPQC for a friend of mine :-)
> 

gcc/g++/whatever crap is needed, if you are a human being you need apps
I don't like gcc either, but having to write every app by hand it's not an option.

Re: [9fans] gcc on plan9

[Micah Stetson]

> I'm not really trying to make Plan 9 look like Linux. I just want to run
> MPQC for a friend of mine :-)

Have you thought of updating/finishing Russ's Linux emulator?  Then
you could just run the Linux binaries on the Plan 9 kernel.  Might
that be less work than keeping up-to-date ports of all the required
GNU stuff?

Micah

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Micah Stetson wrote:
>> I'm not really trying to make Plan 9 look like Linux. I just want to run
>> MPQC for a friend of mine :-)
> 
> 
> Have you thought of updating/finishing Russ's Linux emulator?  Then
> you could just run the Linux binaries on the Plan 9 kernel.  Might
> that be less work than keeping up-to-date ports of all the required
> GNU stuff?

I don't even know about it ...
ron

Re: [9fans] gcc on plan9

[Iruatã Souza (muzgo)]

2006/6/8, Micah Stetson <micah@stetsonnet.org>:
> > I'm not really trying to make Plan 9 look like Linux. I just want to run
> > MPQC for a friend of mine :-)
>
> Have you thought of updating/finishing Russ's Linux emulator?  Then
> you could just run the Linux binaries on the Plan 9 kernel.  Might
> that be less work than keeping up-to-date ports of all the required
> GNU stuff?
>
> Micah
>

I was not pretending to say something here...
But I'm working on linuxemu.

Re: [9fans] gcc on plan9

[andrey mirtchovski]

>
> I was not pretending to say something here...
> But I'm working on linuxemu.

we need to talk! :)

Re: [9fans] gcc on plan9

[Iruatã Souza (muzgo)]

2006/6/8, andrey mirtchovski <andrey@lanl.gov>:
> >
> > I was not pretending to say something here...
> > But I'm working on linuxemu.
>
> we need to talk! :)
>

this thread is kinda big. mailed you privately.

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

Thanks for a thorough explanation! It all makes sense now.
I wish you luck with moving forward with this project.

Thanks,
Roman.

P.S. Keep us posted ;-)

On Wed, Jun 07, 2006 at 11:19:13PM -0600, Ronald G Minnich wrote:
> Roman Shaposhnik wrote:
> >One question that I still have, though, 
> >is what
> >makes you think that once you're done with porting gcc (big task) and 
> >porting HPC apps to
> >gcc/Plan9 (even bigger one!) they will *execute* faster than they do on 
> >Linux ?
> 
> Excellent question.
> 
> It's all about parallel performance; making sure your 1000 nodes run 
> 1000 times as fast as 1 node, or, if they don't, that it's Somebody 
> Else's Problem. The reason that the OS can impact parallel performance 
> boils down to the kinds of tasks that go on in OSes that can be run at 
> awkward times,and in turn interfere with parallel applications, and 
> result in degraded performance. (for another approach, see Cray's 
> synchronised scheduler work; make all nodes schedule the app at the same 
> time).
> 
> Imagine you have one of these lovely apps, on a 1000-node cluster with a 
> 5-microsecond latency network. Let us further imagine (this stuff 
> exists; see Quadrics) that you can do a broadcast/global sum op in 5 
> microseconds. After 1 millisecond, they all need to talk to each other, 
> and can not proceed until they're all agreed on (say) the value of a 
> computed number -- e.g. some sort of global sum of a variable held by 
> each of 1000 procs. The generic term for this type of thing is 'global 
> reduction' -- you reduce a vector to a scalar of some sort.
> 
> The math is pretty easy to do, but it boils down to this: OS activities 
> can interfere with, say, just one task, and kill the parallel 
> performance of the app, making your 1000-node app run like a 750 node 
> app -- or worse.
> 
> Pretend you're delayed one microsecond; do the math; it's depressing. 
> One millisecond compute interval is a really extreme case, chosen for 
> ease of illustration, but ...
> 
> In the clustering world, what a lot of people do is run real heavy nodes 
> in clusters -- they have stuff like cron running, if you can believe it! 
> They pretty much do a full desktop install, then turn off a few daemons, 
> and away they go. Some really famous companies actually run clusters 
> this way -- you'd be surprised at who. So do some famous gov't labs.
> 
> If they're lucky, interference never hits them. If they're not, they get 
> less-than-ideal app performance. Then, they draw a conjecture from the 
> OS interference that comes with such bad configuration: you can't run a 
> cluster node with anything but a custom OS which has no clock 
> interrupts, and, for that matter, no ability to run more than one 
> process at a time. See the computational node kernel on the BG/L for one 
> example, or the catamount kernel on Red Storm. Those kernels are really 
> constrained; just running one proc at a time is only part of the story.
> 
> Here at LANL, we run pretty light cluster nodes.
> 
> Here is a cluster node running xcpu (under busybox, as you can see):
>     1 ?        S      0:00 /bin/ash /linuxrc
>     2 ?        S      0:00 [migration/0]
>     3 ?        SN     0:00 [ksoftirqd/0]
>     4 ?        S      0:00 [watchdog/0]
>     5 ?        S      0:00 [migration/1]
>     6 ?        SN     0:00 [ksoftirqd/1]
>     7 ?        S      0:00 [watchdog/1]
>     8 ?        S      0:00 [migration/2]
>     9 ?        SN     0:00 [ksoftirqd/2]
>    10 ?        S      0:00 [watchdog/2]
>    11 ?        S      0:00 [migration/3]
>    12 ?        SN     0:00 [ksoftirqd/3]
>    13 ?        S      0:00 [watchdog/3]
>    14 ?        S<     0:00 [events/0]
>    15 ?        S<     0:00 [events/1]
>    16 ?        S<     0:00 [events/2]
>    17 ?        S<     0:00 [events/3]
>    18 ?        S<     0:00 [khelper]
>    19 ?        S<     0:00 [kthread]
>    26 ?        S<     0:00 [kblockd/0]
>    27 ?        S<     0:00 [kblockd/1]
>    28 ?        S<     0:00 [kblockd/2]
>    29 ?        S<     0:00 [kblockd/3]
>   105 ?        S      0:00 [pdflush]
>   106 ?        S      0:00 [pdflush]
>   107 ?        S      0:00 [kswapd1]
>   109 ?        S<     0:00 [aio/0]
>   108 ?        S      0:00 [kswapd0]
>   110 ?        S<     0:00 [aio/1]
>   111 ?        S<     0:00 [aio/2]
>   112 ?        S<     0:00 [aio/3]
>   697 ?        S<     0:00 [kseriod]
>   855 ?        S      0:00 xsrv -D 0 tcp!*!20001
>   857 ?        S      0:00 9pserve -u tcp!*!20001
>   864 ?        S      0:00 u9fs -a none -u root -m 65560 -p 564
>   865 ?        S      0:00 /bin/ash
> 
> see how little we have running? Oh, but wait, what's all that stuff in 
> []? It's the stuff we can't turn off. Note there is per-cpu stuff, and 
> other junk. Note that this node has been up for five hours, and this 
> stuff is pretty quiet(0 run time); our nodes are the quietest (in the OS 
> interference sense) Linux nodes I have yet seen. But, that said, all 
> this can hit you.
> 
> And, in Linux, there's a lot of stuff people are finding you can't turn 
> off. Lots of timers down there, lots of magic that goes on, and you just 
> can't turn it off, or adjust it, try as you might.
> 
> Plan 9, our conjecture goes, is a small, tight, kernel, with lots of 
> stuff moved to user mode (file systems); and, we believe that the Plan 9 
> architecture is a good match to future HPC (High Performance Computing) 
> systems, as typified by Red Storm and BG/L: small, fixed-configuration 
> nodes with memory, network, CPU, and nothing else. The ability to not 
> even have a file system on the node is a big plus. The ability to 
> transparently have the file system remote/local puts the application 
> into the driver's seat as to how the node is configured, and what 
> tradeoffs are made; the system as a whole is incredibly flexible.
> 
> Our measurements, so far, do show that Plan 9 is "quieter" than Linux. A 
> full Plan 9 desktop has less OS noise than a Linux box at the login 
> prompt. This matters.
> 
> But it only matters if people can run their apps. Hence our concern 
> about getting gcc-based cra-- er, applications code, running.
> 
> I'm not really trying to make Plan 9 look like Linux. I just want to run 
> MPQC for a friend of mine :-)
> 
> thanks
> 
> ron

Re: [9fans] gcc on plan9

[quanstro]

this isn't really a solution, because linux development will outpace you,
but have you tried building a really tight kernel?  for desktop machines,
i've gotten noticable performance gains by building a moduleless kernel
with only the minimum needed functionality.  i built custom kernels for
(unnamed registrar) and we got +10% packet throughput on linux 2.4
running an (unnamed nameserver) for (unnamed tlds).

i think there are some kernel threads that you may be able to eliminate
with a different kernel.  i don't know if you need 'em though.

- erik

On Fri Jun  9 14:58:10 CDT 2006, rvs@sun.com wrote:
On Wed, Jun 07, 2006 at 11:19:13PM -0600, Ronald G Minnich wrote:
[...]
> >     3 ?        SN     0:00 [ksoftirqd/0]
> >     4 ?        S      0:00 [watchdog/0]
> >     5 ?        S      0:00 [migration/1]
> >     6 ?        SN     0:00 [ksoftirqd/1]
> >     7 ?        S      0:00 [watchdog/1]
> >     8 ?        S      0:00 [migration/2]
> >     9 ?        SN     0:00 [ksoftirqd/2]
> >    10 ?        S      0:00 [watchdog/2]
> >    11 ?        S      0:00 [migration/3]
> >    12 ?        SN     0:00 [ksoftirqd/3]
> >    13 ?        S      0:00 [watchdog/3]
> >    14 ?        S<     0:00 [events/0]
> >    15 ?        S<     0:00 [events/1]
> >    16 ?        S<     0:00 [events/2]
> >    17 ?        S<     0:00 [events/3]
> >    18 ?        S<     0:00 [khelper]
> >    19 ?        S<     0:00 [kthread]
> >    26 ?        S<     0:00 [kblockd/0]
> >    27 ?        S<     0:00 [kblockd/1]
> >    28 ?        S<     0:00 [kblockd/2]
> >    29 ?        S<     0:00 [kblockd/3]
> >   105 ?        S      0:00 [pdflush]
> >   106 ?        S      0:00 [pdflush]
> >   107 ?        S      0:00 [kswapd1]
> >   109 ?        S<     0:00 [aio/0]
> >   108 ?        S      0:00 [kswapd0]
> >   110 ?        S<     0:00 [aio/1]
> >   111 ?        S<     0:00 [aio/2]
> >   112 ?        S<     0:00 [aio/3]
> >   697 ?        S<     0:00 [kseriod]
> >   855 ?        S      0:00 xsrv -D 0 tcp!*!20001
> >   857 ?        S      0:00 9pserve -u tcp!*!20001
> >   864 ?        S      0:00 u9fs -a none -u root -m 65560 -p 564
> >   865 ?        S      0:00 /bin/ash
> > 
> > see how little we have running? Oh, but wait, what's all that stuff in 
> > []? It's the stuff we can't turn off. Note there is per-cpu stuff, and 
> > other junk. Note that this node has been up for five hours, and this 
> > stuff is pretty quiet(0 run time); our nodes are the quietest (in the OS 
> > interference sense) Linux nodes I have yet seen. But, that said, all 
> > this can hit you.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

quanstro@quanstro.net wrote:
> this isn't really a solution, because linux development will outpace you,
> but have you tried building a really tight kernel?  

yes, that is actually a pretty tight kernel.

And, it may well be that linux will fix all this, but my observation of 
the '500 cooks' phenomenon in linux nowadays is that their ability to 
take in a lot of contributions is very impressive, but it is not 
necessarily improving the kernel.

thanks

ron

Re: [9fans] gcc on plan9

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 7-Jun-06, at 8:51 PM, Ronald G Minnich wrote:
> What if you had a window manager that could be recursive? that  
> would set it up so you can name windows by a path name? that would  
> let you treat the recursive desktops -- to any level -- as just  
> another window? that would trivially allow you to connect mouse  
> clicks in a window to control actions for one or more other windows  
> (i.e. you could logically group windows and then control all of  
> them via mouse clicks)? That would maybe let you easily connect  
> output from a process in one window to another? that would let you  
> build little widgets that  could easily control other windows? That  
> would let you display all window state in another window? That  
> would let you set, say, all windows with a browser with the label  
> abaco-### (### a number), with a simple text command; and let you  
> find all windows with the label abaco.* with, in the limit, a grep?  
> That would make it easy to group all windows with the label  
> 'abaco.*' so that you could say 'hide all abaco' with a simple script?
>
> Wouldn't that be neat? I mean, that's a real bitch in X, right?
>
> Except ... you already have it.

And this is what makes me such a fan of the Plan 9 model.

Now if people wanted to do something "end-user-ish" perhaps they  
could produce those little handy tools, and hook them up to some  
simple window decorations (but that still somehow work the natural  
way they do now - perhaps a "decorated" mirror file server).

But the effort is doomed to failure - end-user-pleasers want more eye  
candy than can be coordinated without a good professional designer  
riding whip on the project.

I'm a big fan of the extreme wire-it-together we get from unixish  
tools + plan 9 file servers, but it's an environment for experts, not  
end-users.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEh6NypJeHo/Fbu1wRAqw/AJ936534UTa1fc+G9jp1ivyOIB/15ACfQ9g0
0nCHWHcleZLl8Xp/T0C3l84=
=uXfg
-----END PGP SIGNATURE-----

Re: [9fans] gcc on plan9

[ems]

On Wed, 2006-06-07 at 21:51 -0600, Ronald G Minnich wrote: 
> What if you had a window manager that could be recursive? that would set 
> it up so you can name windows by a path name? that would let you treat 
> the recursive desktops -- to any level -- as just another window? that 
> would trivially allow you to connect mouse clicks in a window to control 
> actions for one or more other windows (i.e. you could logically group 
> windows and then control all of them via mouse clicks)? That would maybe 
> let you easily connect output from a process in one window to another? 
> that would let you build little widgets that  could easily control other 
> windows? That would let you display all window state in another window? 
> That would let you set, say, all windows with a browser with the label 
> abaco-### (### a number), with a simple text command; and let you find 
> all windows with the label abaco.* with, in the limit, a grep? That 
> would make it easy to group all windows with the label 'abaco.*' so that 
> you could say 'hide all abaco' with a simple script?

________________________
| It looks like you're |
| playing with rio.    |
|                      |
| Would you like help? |
|                      |
| * Get help with      |
|   hiding windows     |
|                      |
| * Just hide the      |
|   windows without    |
|   help               |
| _                    |
||_| Don't show me     |
|    this tip again    |
|______  ______________|
       \ |    
        \|  
      Glenda

Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)

Re: [9fans] gcc on plan9

[Simon Williams]

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

Dont knock the paper clip - just the implementation
The people who designed it ( at Microsoft Research ) are seriously excellent
Bayesan statisticians who names i have forgotten ( apologies ). The problem
for the marketroids was that it didnt appear often enough for them to sell
it as a feature so they took all the careful tuned parameters and wound them
up to 11 creating the monster we have today.
Simon

On 6/8/06, ems <oat@iinet.net.au> wrote:
>
> On Wed, 2006-06-07 at 21:51 -0600, Ronald G Minnich wrote:
> > What if you had a window manager that could be recursive? that would set
> > it up so you can name windows by a path name? that would let you treat
> > the recursive desktops -- to any level -- as just another window? that
> > would trivially allow you to connect mouse clicks in a window to control
> > actions for one or more other windows (i.e. you could logically group
> > windows and then control all of them via mouse clicks)? That would maybe
> > let you easily connect output from a process in one window to another?
> > that would let you build little widgets that  could easily control other
> > windows? That would let you display all window state in another window?
> > That would let you set, say, all windows with a browser with the label
> > abaco-### (### a number), with a simple text command; and let you find
> > all windows with the label abaco.* with, in the limit, a grep? That
> > would make it easy to group all windows with the label 'abaco.*' so that
> > you could say 'hide all abaco' with a simple script?
>
> ________________________
> | It looks like you're |
> | playing with rio.    |
> |                      |
> | Would you like help? |
> |                      |
> | * Get help with      |
> |   hiding windows     |
> |                      |
> | * Just hide the      |
> |   windows without    |
> |   help               |
> | _                    |
> ||_| Don't show me     |
> |    this tip again    |
> |______  ______________|
>        \ |
>         \|
>       Glenda
>
> Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)
>

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

Re: [9fans] gcc on plan9

[Bruce Ellis]

Dont knock the paper clip - excellent way to get stuck media
out of a Mac.

If you want gcc then port it ... it won't change my world.  Run
whatever you like.  Have fun, dhog didn't.

brucee

On 6/8/06, Simon Williams <wyman.silliams@gmail.com> wrote:
> Dont knock the paper clip - just the implementation
> The people who designed it ( at Microsoft Research ) are seriously excellent
> Bayesan statisticians who names i have forgotten ( apologies ). The problem
> for the marketroids was that it didnt appear often enough for them to sell
> it as a feature so they took all the careful tuned parameters and wound them
> up to 11 creating the monster we have today.
> Simon
>
>
> On 6/8/06, ems <oat@iinet.net.au> wrote:
> > On Wed, 2006-06-07 at 21:51 -0600, Ronald G Minnich wrote:
> > > What if you had a window manager that could be recursive? that would set
> > > it up so you can name windows by a path name? that would let you treat
> > > the recursive desktops -- to any level -- as just another window? that
> > > would trivially allow you to connect mouse clicks in a window to control
> > > actions for one or more other windows (i.e. you could logically group
> > > windows and then control all of them via mouse clicks)? That would maybe
> > > let you easily connect output from a process in one window to another?
> > > that would let you build little widgets that  could easily control other
> > > windows? That would let you display all window state in another window?
> > > That would let you set, say, all windows with a browser with the label
> > > abaco-### (### a number), with a simple text command; and let you find
> > > all windows with the label abaco.* with, in the limit, a grep? That
> > > would make it easy to group all windows with the label 'abaco.*' so that
> > > you could say 'hide all abaco' with a simple script?
> >
> > ________________________
> > | It looks like you're |
> > | playing with rio.    |
> > |                      |
> > | Would you like help? |
> > |                      |
> > | * Get help with      |
> > |   hiding windows     |
> > |                      |
> > | * Just hide the      |
> > |   windows without    |
> > |   help               |
> > | _                    |
> > ||_| Don't show me     |
> > |    this tip again    |
> > |______  ______________|
> >        \ |
> >         \|
> >       Glenda
> >
> > Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)
> >
>
>

ASCII Glenda (was Re: [9fans] gcc on plan9)

[csant]

On Thu, 08 Jun 2006 07:25:59 +0200, ems <oat@iinet.net.au> wrote:

> (BTW, is there ACSII Glenda anywhere?)



      (\(\
      ¸”˘ ˘˛
      (  . .)
      |   ° ¡
      ¿     ;
     c?“─UJ”




/c (hoping to get somebody think "boy, that's ugly!" and make a better  
one...)

Re: ASCII Glenda (was Re: [9fans] gcc on plan9)

[e.c.sharpe]

On Sun, 16 Jul 2006 17:17:53 +0200
csant <csant@csant.info> wrote:

> On Thu, 08 Jun 2006 07:25:59 +0200, ems <oat@iinet.net.au> wrote:
> 
> > (BTW, is there ACSII Glenda anywhere?)
> 
> 
> 
>       (\(\
>       ¸”˘ ˘˛
>       (  . .)
>       |   ° ¡
>       ¿     ;
>      c?“─UJ”
> 
> 
> 
> 
> /c (hoping to get somebody think "boy, that's ugly!" and make a better  
> one...)

I think she's pretty cute, actually.
:)

Re: Re: ASCII Glenda (was Re: [9fans] gcc on plan9)

[Jack Johnson]

                    ::iiii;;
                    ii..;;;;ii
                    ii;;iiLLii;;
          ;;tttt;;  ..tt..GGGGii;;
        ..ii....iiii  ;;iiiiEEffii..
        ;;;;..ff;;;;tt..ii..ffKKtttt
          ii..ffEELL;;tt;;jjttLLttiiiiiiiiiiii..
          ;;ii..LLEELL;;jjtt,,            ..;;ttii
            ;;ii..iiKKDDii                      ..tt..
              ;;ii..ttff..                        ;;tt..
                ::iiii..                          ..;;ii
                    tt                              ..ttii
                  ::;;                                ;;tt
                  ;;..                                ..jj..
                  ;;;;                                iijj;;
                  ..ii                    ,,..      ..GGttii
                    ii                    LL;;        ..ttii
                    ii..                  ..      ;;....tt;;
                    ..ii                      ..ff;;ff;;tt..
                      ii                      ttLLGGDDtttt
                      ii..                    ;;ffffff;;tt
                      ;;;;                    ..tt;;;;;;tt
                      ;;;;                      ;;ii,,iiii
                      ii..                        ....iiii
                      ii..                            iiii
                      ii..                            iiii
                      ii..                            tt;;
                    iiLL..                          ..tt..
                  ..ffttii                          ::ii
                  ;;ii;;tt,,                      ..tt..
                  ..ttttjjGGii                ..ii;;tt
                    ..iittiitttt..      ;;tt....tt..ii
                              ;;ttttii;;..ii::  ;;ttii
                                      ..iiiiiiiiii..

(looks best fixed-width)

Courtesy http://www.degraeve.com/img2txt.php and
http://cm.bell-labs.com/plan9/img/plan9bunnysmwhite.jpg though I
suspect some tweaking can find a better combination.

-Jack

On 7/16/06, e.c.sharpe <bride.of.excession@gmail.com> wrote:
> On Sun, 16 Jul 2006 17:17:53 +0200
> csant <csant@csant.info> wrote:
>
> > On Thu, 08 Jun 2006 07:25:59 +0200, ems <oat@iinet.net.au> wrote:
> >
> > > (BTW, is there ACSII Glenda anywhere?)
> >
> >
> >
> >       (\(\
> >       ¸"˘ ˘˛
> >       (  . .)
> >       |   ° ¡
> >       ¿     ;
> >      c?"─UJ"
> >
> >
> >
> >
> > /c (hoping to get somebody think "boy, that's ugly!" and make a better
> > one...)
>
> I think she's pretty cute, actually.
> :)
>
>

Re: Re: ASCII Glenda (was Re: [9fans] gcc on plan9)

[Rodolfo (kix)]

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

Is very very good!



2006/7/17, Jack Johnson <knapjack@gmail.com>:
>
>                     ::iiii;;
>                     ii..;;;;ii
>                     ii;;iiLLii;;
>           ;;tttt;;  ..tt..GGGGii;;
>         ..ii....iiii  ;;iiiiEEffii..
>         ;;;;..ff;;;;tt..ii..ffKKtttt
>           ii..ffEELL;;tt;;jjttLLttiiiiiiiiiiii..
>           ;;ii..LLEELL;;jjtt,,            ..;;ttii
>             ;;ii..iiKKDDii                      ..tt..
>               ;;ii..ttff..                        ;;tt..
>                 ::iiii..                          ..;;ii
>                     tt                              ..ttii
>                   ::;;                                ;;tt
>                   ;;..                                ..jj..
>                   ;;;;                                iijj;;
>                   ..ii                    ,,..      ..GGttii
>                     ii                    LL;;        ..ttii
>                     ii..                  ..      ;;....tt;;
>                     ..ii                      ..ff;;ff;;tt..
>                       ii                      ttLLGGDDtttt
>                       ii..                    ;;ffffff;;tt
>                       ;;;;                    ..tt;;;;;;tt
>                       ;;;;                      ;;ii,,iiii
>                       ii..                        ....iiii
>                       ii..                            iiii
>                       ii..                            iiii
>                       ii..                            tt;;
>                     iiLL..                          ..tt..
>                   ..ffttii                          ::ii
>                   ;;ii;;tt,,                      ..tt..
>                   ..ttttjjGGii                ..ii;;tt
>                     ..iittiitttt..      ;;tt....tt..ii
>                               ;;ttttii;;..ii::  ;;ttii
>                                       ..iiiiiiiiii..
>
> (looks best fixed-width)
>
> Courtesy http://www.degraeve.com/img2txt.php and
> http://cm.bell-labs.com/plan9/img/plan9bunnysmwhite.jpg though I
> suspect some tweaking can find a better combination.
>
> -Jack
>
> On 7/16/06, e.c.sharpe <bride.of.excession@gmail.com> wrote:
> > On Sun, 16 Jul 2006 17:17:53 +0200
> > csant <csant@csant.info> wrote:
> >
> > > On Thu, 08 Jun 2006 07:25:59 +0200, ems <oat@iinet.net.au> wrote:
> > >
> > > > (BTW, is there ACSII Glenda anywhere?)
> > >
> > >
> > >
> > >       (\(\
> > >       ¸"˘ ˘˛
> > >       (  . .)
> > >       |   ° ¡
> > >       ¿     ;
> > >      c?"─UJ"
> > >
> > >
> > >
> > >
> > > /c (hoping to get somebody think "boy, that's ugly!" and make a better
> > > one...)
> >
> > I think she's pretty cute, actually.
> > :)
> >
> >
>



-- 
Rodolfo García "kix"

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

Re: [9fans] gcc on plan9

[geoff]

> all the things you obviously _don't_ use while using Plan 9 - such as
> graphical/current web-browsing apps, various media apps, pim apps,
> vector graphics editing apps, spreadsheet and publishing apps, pdf,
> relational database management systems, etc.  etc.

I use Safari via VNC from Plan 9 for web browsing (we do after all
have networks nowadays, so we don't have to run everything in one
machine).  page(1) reads PDF.

The rest of the above list seem to me to be mostly bling, symptoms or
check-list items.  In a pinch, my Mac Mini makes a fine multimedia
processor.  I have no interest in most of the other items
(spreadsheets!?), and actively dislike others (RDBMs).  Somehow the
lack of these things hasn't been a problem.

Re: [9fans] gcc on plan9

[quanstro]

i have found relational databases pretty useful for certian problems --
like tracking ever-changing customer and billing information.

/interfacing/ to relational databases is downright obnoxious.
but that's an implementation issue.

On Wed Jun  7 20:07:02 CDT 2006, geoff@collyer.net wrote:
> (spreadsheets!?), and actively dislike others (RDBMs).  Somehow the
> lack of these things hasn't been a problem.

Re: [9fans] gcc on plan9

[Victor Nazarov]

geoff@collyer.net wrote:

>>all the things you obviously _don't_ use while using Plan 9 - such as
>>graphical/current web-browsing apps, various media apps, pim apps,
>>vector graphics editing apps, spreadsheet and publishing apps, pdf,
>>relational database management systems, etc.  etc.
>>    
>>
>
>I use Safari via VNC from Plan 9 for web browsing (we do after all
>have networks nowadays, so we don't have to run everything in one
>machine).  page(1) reads PDF.
>
>The rest of the above list seem to me to be mostly bling, symptoms or
>check-list items.  In a pinch, my Mac Mini makes a fine multimedia
>processor.  I have no interest in most of the other items
>(spreadsheets!?), and actively dislike others (RDBMs).  Somehow the
>lack of these things hasn't been a problem.
>  
>
I actively dislike Web tecnologies (w3c as a whole). But why RDBMs? 
Actually I dislike them too, but there seems to be no real alternatives. 
And, hmm, I like spreadsheets :)
--
Victor

Re: [9fans] gcc on plan9

[Lluís Batlle]

2006/6/8, Corey <corey_s@qwest.net>:
> I have neither the morale nor the power to write even a single line of code
> for this new  "integrated graphical desktop environment" on Plan 9 -- I
> merely intend to assemble the work that others are doing; I'm like a child
> clumsily playing with lego bricks. The best that I can do is help write
> the gluework to get it working together nicely.
What do you mean by "others are doing"? I don't know about the GNUStep
general development, but a bit about Windowmaker's - there isn't more
than a message a month in their mailing lists, and I think they aren't
many people. A recent post in their lists claimed "We used to have
time when we was at university...", explaining how difficult is for
the Windowmaker's developers keep on programming.

Maybe I'm wrong? I don't know about the out-of-the-mailing-lists work.

Re: [9fans] gcc on plan9

[Corey]

On Thursday 08 June 2006 02:40, Lluís Batlle wrote:
> 2006/6/8, Corey <corey_s@qwest.net>:
> > I have neither the morale nor the power to write even a single line of code
> > for this new  "integrated graphical desktop environment" on Plan 9 -- I
> > merely intend to assemble the work that others are doing; I'm like a child
> > clumsily playing with lego bricks. The best that I can do is help write
> > the gluework to get it working together nicely.
>
> What do you mean by "others are doing"? I don't know about the GNUStep
> general development,
> 

GNUstep is quite healthy and active, and the core libraries are all either at 
"1.0" release, or very close to it.

> but a bit about Windowmaker's - there isn't more 
> than a message a month in their mailing lists, 
>

I think this is possibly where I may have been somewhat misunderstood -
I don't want to bring windowmaker and X11 and all that stuff onto a Plan 9
installation; I am "merely" interested in experimenting with Objective-C 
and the GNUstep libraries on Plan 9, in Plan fashion.

I would like to _use_ Objective-C/GNUstep _natively_ on Plan 9 in purely 
idiomatic Plan 9 style - meaning I would be writing services as file
systems through 9P. All I really need to begin this is an Objective-C compiler; 
the rest is what I would consider the "gluework" to get it working in Plan 9.  

Even the GNUstep gui framework is abstracted so well that it imposes no 
assumptions as to the backend windowing environment:

"The GNUstep GUI Library is designed in two parts.  The first part is
the front-end component which is independent of platform and display
system.  This front-end is combined with a back-end component which
handles all of the display system dependent such as specific calls to
X/Windows.  This design allows the GNUstep applications to have the
"look and feel" of the underlying display system without any changes to
the application, and the library can be easily ported to other display
systems.

The GNUstep GUI Library requires the GNU Objective-C compiler, the
GNUstep Base Library, the TIFF Graphics library, and a back-end
component like the GNUstep 'Back' Backend."

Writing a Plan 9 back-end component for the GNUstep GUI Library, is
an excellent example of the sort of "gluework" I'd be able to tackle, likely
with some help.


> Maybe I'm wrong? I don't know about the out-of-the-mailing-lists work.
> 

I'm definitely not trying to turn Plan 9 into a Linux clone; and I personally, 
despite reading through this whole thread, am still scratching my head
as to why programming 9P services on Plan 9 in some other language
besides C, awk, sed, or rc is met with such resentment and gnashing of
teeth.

Re: [9fans] gcc on plan9

[Fred Wade]

On Thursday 08 June 2006 15:55, Corey wrote:
>
> Writing a Plan 9 back-end component for the GNUstep GUI Library, is
> an excellent example of the sort of "gluework" I'd be able to tackle,
> likely with some help.

I've always been interested in objective c and Gnustep also, and would love to 
get involved in helping if this project ever gets started. I'm busy right now 
but should be available in a couple of months, with a steep learning curve  
on Plan9 coding. I have lots of C and C++ experience, and just a little 
objective c experience.

Please keep me in mind, and good luck.

Fred Wade

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 12:55:16PM -0700, Corey wrote:
> On Wednesday 07 June 2006 11:57, Francisco J Ballesteros wrote:
> > Plan9 is spartan and lean, and also very effective.
> > very much like UNIX was.
> > 
> 
> I like that about plan 9, and I'm very much an advocate of spartan and lean,
> as well as focused and well-integrated/holistic.
> 
> Objective-C and the base GNUstep library/framework very much themselves 
> contain those same attributes: light, efficient, lean.  Conceptually, I think 
> obj-c/gnustep running on plan 9 would be pretty enticing.
  
  Speaking about Objective-C, why don't you consider ObjC -> C compilers like
  this one: http://users.pandora.be/stes/compiler.html. For your project
  is sounds like a pretty good approach, especially since it plays nice
  with the underlying system (e.g. generates C code which can later be
  given to our beloved KenC).

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Corey]

On Thursday 08 June 2006 16:08, Roman Shaposhnick wrote:
>   Speaking about Objective-C, why don't you consider ObjC -> C compilers like
>   this one: http://users.pandora.be/stes/compiler.html. For your project
>   is sounds like a pretty good approach, especially since it plays nice
>   with the underlying system (e.g. generates C code which can later be
>   given to our beloved KenC).
> 

That does look promising - thank you very much for the heads-up; I don't
know how I managed to have missed that gem! 

It seems to want byacc and flex, but it looks like I got lex and yacc on Plan 9,
so there should (hopefully) be minimal fuss compiling it on Plan 9 - excellent.


Kind regards,

Corey

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey said:
> 
> Two questions - quite likely naive, so please be kind!
> 
> #1 - How difficult approximately would it be to port a
> more current release of gcc to plan9, say 4.1?

It's in my TODO list. It shouldn't be too difficult.

Thanks,
	Lucho

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 02:46:10PM -0600, Latchesar Ionkov wrote:
> On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey said:
> > 
> > Two questions - quite likely naive, so please be kind!
> > 
> > #1 - How difficult approximately would it be to port a
> > more current release of gcc to plan9, say 4.1?
> 
> It's in my TODO list. It shouldn't be too difficult.

  Does it include things like g++/gfortran/etc. ? What
  backends are you interested in supporting ? What linker
  do you intend to use ?

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

We need support for C++ and Fortran. It will use GNU binutils.
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes 
to the newest versions of the GNU utils.

Thanks,
	Lucho

On Wed, Jun 07, 2006 at 12:07:55PM -0700, Roman Shaposhnick said:
> On Wed, Jun 07, 2006 at 02:46:10PM -0600, Latchesar Ionkov wrote:
> > On Wed, Jun 07, 2006 at 10:58:35AM -0700, Corey said:
> > > 
> > > Two questions - quite likely naive, so please be kind!
> > > 
> > > #1 - How difficult approximately would it be to port a
> > > more current release of gcc to plan9, say 4.1?
> > 
> > It's in my TODO list. It shouldn't be too difficult.
> 
>   Does it include things like g++/gfortran/etc. ? What
>   backends are you interested in supporting ? What linker
>   do you intend to use ?
> 
> Thanks,
> Roman.

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 01:17:25PM -0600, Latchesar Ionkov wrote:
> We need support for C++ and Fortran. 

  Oh my! It'll be a brand new can worms to open :-(

> It will use GNU binutils.

  What about libc ? Surely you can't expect UNIX applications
  to be happy without libc or better yet glibc. Do you intend
  to port it as well ?

> What I am planning to do (and that's what we agreed on the Secret
> Plan 9 Secret Society Society meeting :) is just migrate dhogs changes 
> to the newest versions of the GNU utils.

  That is a doable thing. But I fail to see what it strives to
  accomplish on the application level, unless, of course, the other 
  "secret pact" was to bring all the GNU cruft (like glibc, libstdc++, 
  etc.) along the way.

  Please explain what's your next step, as far as application
  migration is concerned ?

Thanks,
Roman.

P.S. Sorry for being harsh, but I've just suffered a long porting
effort of the same thing. And let me tell you -- C++/g++ and glibc
ain't pretty beasts. I dread the day they appear anywhere around
Plan9.

Re: [9fans] gcc on plan9

[Brantley Coile]

Just make loading gcc and the library and anything else
that from gthe gworld gof gnu optional.  So I can rush out
and not load it.  Like the way the older gcc is now.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Brantley Coile wrote:
> Just make loading gcc and the library and anything else
> that from gthe gworld gof gnu optional.  So I can rush out
> and not load it.  Like the way the older gcc is now.
> 

yep, You don't like it, don't use it. Simple.

But I'm sick of the purity arguments.

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 02:15:00PM -0600, Ronald G Minnich wrote:
> Brantley Coile wrote:
> >Just make loading gcc and the library and anything else
> >that from gthe gworld gof gnu optional.  So I can rush out
> >and not load it.  Like the way the older gcc is now.
> >
> 
> yep, You don't like it, don't use it. Simple.
> 
> But I'm sick of the purity arguments.

  These are not purity arguments. What you're after *can* be
  implemented cleanly. There are two things I worry about however:
     
     1. Implementors having enough time to not make shortcuts
        which will render system inferior.
     
     2. Knowing when to start bugging users to fix the code
        instead of implementing yet another workaround in the system.
  
  Your tone of voice makes me think that you don't have time
  for the former and you've exhausted your patience for the
  later.

Thanks,
Roman.

P.S. As a compiler engineer working for a commercial compiler
vendor I have to face #2 all the time. And let me tell you 
it ain't a simple thing. However, serious developers usually 
understand that fixing the code (instead of asking a vendor to 
shut the compiler up) is much better long term strategy.
Unfortunately they are usually not the ones to escalate
these sort of "bugs". :-(

Re: [9fans] gcc on plan9

[Latchesar Ionkov]

On Jun 7, 2006, at 1:26 PM, Roman Shaposhnick wrote:

> On Wed, Jun 07, 2006 at 01:17:25PM -0600, Latchesar Ionkov wrote:
>> We need support for C++ and Fortran.
>
>   Oh my! It'll be a brand new can worms to open :-(
>
>> It will use GNU binutils.
>
>   What about libc ? Surely you can't expect UNIX applications
>   to be happy without libc or better yet glibc. Do you intend
>   to port it as well ?

We will try to use APE.

>
>> What I am planning to do (and that's what we agreed on the Secret
>> Plan 9 Secret Society Society meeting :) is just migrate dhogs  
>> changes
>> to the newest versions of the GNU utils.
>
>   That is a doable thing. But I fail to see what it strives to
>   accomplish on the application level, unless, of course, the other
>   "secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
>   etc.) along the way.

We would like to convince some people that Plan9 (kernel) is a useful  
alternative to Linux without  asking them to rewrite all their  
applications. Like it or not, most people won't consider spending man- 
months in effort just to check if an alternative is better.  
Especially if there is not much hype surrounding the alternative :)

>
>   Please explain what's your next step, as far as application
>   migration is concerned ?

As Ron mentioned the immediate objectives are running MPQC and some  
HPC benchmarks.

>
> Thanks,
> Roman.
>
> P.S. Sorry for being harsh, but I've just suffered a long porting
> effort of the same thing. And let me tell you -- C++/g++ and glibc
> ain't pretty beasts. I dread the day they appear anywhere around
> Plan9.

The GNU apps won't be part of the standard Plan9 distribution, so you  
can continue to ignore them :)

	Lucho

Re: [9fans] gcc on plan9

[Corey]

On Wednesday 07 June 2006 12:47, Latchesar Ionkov wrote:
> On Jun 7, 2006, at 1:26 PM, Roman Shaposhnick wrote:
> >   That is a doable thing. But I fail to see what it strives to
> >   accomplish on the application level, unless, of course, the other
> >   "secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
> >   etc.) along the way.
> 
> We would like to convince some people that Plan9 (kernel) is a useful  
> alternative to Linux without  asking them to rewrite all their  
> applications.
> 

I'm thinking in a very similar way as what Latchesar is expressing.

Re: [9fans] gcc on plan9

[Roman Shaposhnick]

On Wed, Jun 07, 2006 at 01:47:02PM -0600, Latchesar Ionkov wrote:
> >>It will use GNU binutils.
> >
> >  What about libc ? Surely you can't expect UNIX applications
> >  to be happy without libc or better yet glibc. Do you intend
> >  to port it as well ?
> 
> We will try to use APE.

  That could be interesting.

> >  That is a doable thing. But I fail to see what it strives to
> >  accomplish on the application level, unless, of course, the other
> >  "secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
> >  etc.) along the way.
> 
> We would like to convince some people that Plan9 (kernel) is a useful  
> alternative to Linux without  asking them to rewrite all their  
> applications. Like it or not, most people won't consider spending man- 
> months in effort just to check if an alternative is better.  
> Especially if there is not much hype surrounding the alternative :)

  True. However, even in Linux circles the idea that "GNU is not Unix,
  but sure seems like a lot of cruft" is now getting some recognition.
  Personally, I would very much welcome (to the point of participating 
  myself) any effort which aims at writing a clean C99 environment 
  (including compiler, libc, etc.) one can use without losing sanity.

  On the application front I would expect it to be a drop-in replacement
  for a glibc/gcc (may be with a couple of fixes here and there).

  Is it similar to what you have in mind ?
  
> >  Please explain what's your next step, as far as application
> >  migration is concerned ?
> 
> As Ron mentioned the immediate objectives are running MPQC and some  
> HPC benchmarks.
  
  What benchmarks are these ? Since I'm in HPC business myself (or at
  least I work for a team, that works for a company which tries to be
  in HPC business) I'm very curious to know what your expectations
  are w.r.t migrating from UNIX kernel to Plan9.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Roman Shaposhnick wrote:

>   On the application front I would expect it to be a drop-in replacement
>   for a glibc/gcc (may be with a couple of fixes here and there).

good idea, but ... how do we avoid making another APE?

ron

Re: [9fans] gcc on plan9

[Roman Shaposhnik]

Ronald G Minnich wrote:
> Roman Shaposhnick wrote:
>
>>   On the application front I would expect it to be a drop-in replacement
>>   for a glibc/gcc (may be with a couple of fixes here and there).
>
> good idea, but ... how do we avoid making another APE?
 APE has a slightly different purpose. 
What I'm after is a C99 complete environment,
not a POSIX-complete one.

Thanks,
Roman.

Re: [9fans] gcc on plan9

[Christoph Lohmann]

Good evening.

Am Wed, 7 Jun 2006 13:17:25 -0600 schrieb Latchesar Ionkov
<lucho@gmx.net>:

> What I am planning to do (and that's what we agreed on the Secret
> Plan 9 Secret Society Society meeting :) is just migrate dhogs changes 
> to the newest versions of the GNU utils.

In the Dissident Plan 9 IRC Kids meeting we decided that SP9SSS sucks
really hard. Does that make you any better?

Sincerely,

Christoph

Re: [9fans] gcc on plan9

[Ronald G Minnich]

Christoph Lohmann wrote:
> Good evening.
> 
> Am Wed, 7 Jun 2006 13:17:25 -0600 schrieb Latchesar Ionkov
> <lucho@gmx.net>:
> 
> 
>>What I am planning to do (and that's what we agreed on the Secret
>>Plan 9 Secret Society Society meeting :) is just migrate dhogs changes 
>>to the newest versions of the GNU utils.
> 
> 
> In the Dissident Plan 9 IRC Kids meeting we decided that SP9SSS sucks
> really hard. Does that make you any better?

of course it sucks. All secret societies do. But we have such fine 
fashion style!

ron

Re: [9fans] gcc on plan9

[Dan Cross]

On Wed, Jun 07, 2006 at 03:49:47PM -0600, Ronald G Minnich wrote:
> of course it sucks. All secret societies do. But we have such fine 
> fashion style!

Fashion and style sense are not the same thing.

	- Dan C.

RE: [9fans] quantity vs. quality

[cej]

> No, we need fresh ideas.  An infinite number of monkeys turning Plan  
> 9 into Linux is not progress.

I agree 100%. Although I would LOVE to have some loonix prgs w/o
rebooting to L. Or c++, java, perl, etc...
Attract more people to the clean design (and they will, hopefully,
rewrite everything that is(isn't;-) worth it...
IMHO.

++pac.

Re: [9fans] quantity vs. quality

[Lluís Batlle]

Maybe something capable of running an isolated linux box in plan9's
environment would do the trick, as some people do right now in Linux
in order to run plan9. Let's say... a 'xen-like-thing' running on
plan9, for running other kernels over the same hardware.

Of course, I don't plan coding that.

2006/6/8, cej@gli.cas.cz <cej@gli.cas.cz>:
> > No, we need fresh ideas.  An infinite number of monkeys turning Plan
> > 9 into Linux is not progress.
>
> I agree 100%. Although I would LOVE to have some loonix prgs w/o
> rebooting to L. Or c++, java, perl, etc...
> Attract more people to the clean design (and they will, hopefully,
> rewrite everything that is(isn't;-) worth it...
> IMHO.
>
> ++pac.
>
>

Re: [9fans] quantity vs. quality

[David Leimbach]

On 6/8/06, Lluís Batlle <viriketo@gmail.com> wrote:
> Maybe something capable of running an isolated linux box in plan9's
> environment would do the trick, as some people do right now in Linux
> in order to run plan9. Let's say... a 'xen-like-thing' running on
> plan9, for running other kernels over the same hardware.
>
> Of course, I don't plan coding that.

Hmmm, port Plan 9 to L4, run side by side with L4 Linux?

Why not just run Plan 9 as the guest for that matter.  I do that with
parallels.  It's no worse than using VNC to alleviate the pain of not
having a web browser is it?  Except I don't need VNC to do the work.

I think I'd be happy with this.  I don't see any compelling reasons
these days to load Plan 9 anywhere but in a virtualized environment
really (for my use).

Ron has a very specific need and I wish him luck.

>
> 2006/6/8, cej@gli.cas.cz <cej@gli.cas.cz>:
> > > No, we need fresh ideas.  An infinite number of monkeys turning Plan
> > > 9 into Linux is not progress.
> >
> > I agree 100%. Although I would LOVE to have some loonix prgs w/o
> > rebooting to L. Or c++, java, perl, etc...
> > Attract more people to the clean design (and they will, hopefully,
> > rewrite everything that is(isn't;-) worth it...
> > IMHO.
> >
> > ++pac.
> >
> >
>

Re: [9fans] quantity vs. quality

[jmk]

On Thu Jun  8 11:30:43 EDT 2006, leimy2k@gmail.com wrote:
> ...
> Why not just run Plan 9 as the guest for that matter.  I do that with
> parallels.  It's no worse than using VNC to alleviate the pain of not
> having a web browser is it?  Except I don't need VNC to do the work.
> 
> I think I'd be happy with this.  I don't see any compelling reasons
> these days to load Plan 9 anywhere but in a virtualized environment
> really (for my use).
> 
> Ron has a very specific need and I wish him luck.
> ...

"There is no problem in computer science that cannot be solved by
another level of indirection." - except performance. Last week I
listened to many talks which wanted to fix the problem of porting
code to supercomputers by adding virtualisation because, well, Ken,
device drivers are hard so let's just go to the mall.

Ron's needs are what are not so indirectly paying for keeping
plan9.bell-labs.com alive.

RE: [9fans] quantity vs. quality

[cej]

I usually don't care of gui apps, so there is (not yet working) linuxemu by ruuss (I think)... Would be great to have this-- it's on the wiki's TODO

++pac

-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu [mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of Lluís Batlle
Sent: 08 June 2006 11:32
To: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] quantity vs. quality


Maybe something capable of running an isolated linux box in plan9's environment would do the trick, as some people do right now in Linux in order to run plan9. Let's say... a 'xen-like-thing' running on plan9, for running other kernels over the same hardware.

Of course, I don't plan coding that.

2006/6/8, cej@gli.cas.cz <cej@gli.cas.cz>:
> > No, we need fresh ideas.  An infinite number of monkeys turning Plan 
> > 9 into Linux is not progress.
>
> I agree 100%. Although I would LOVE to have some loonix prgs w/o 
> rebooting to L. Or c++, java, perl, etc... Attract more people to the 
> clean design (and they will, hopefully, rewrite everything that 
> is(isn't;-) worth it... IMHO.
>
> ++pac.
>
>