Re: [9fans] new compilers

Re: [9fans] new compilers

[erik quanstrom]

uh, linux had a tcp/ip stack long, long before windows 95.

i think people forget that one of the reasons that tcp/ip came a bit later
to linux was the fact that the folks working with linux at home
had no real home network.  28.8k dialup, baby!

- erik

On Mon Apr  3 12:30:30 CDT 2006, lucio@proxima.alt.za wrote:
> Funny, you could download Linux over the 'Net, but you could not
> connect with it.  It took Win'95, in my environment, to popularise the
> 'Net.

Re: [9fans] new compilers

[erik quanstrom]

well, ya, simplicity in this sense is hard to grasp.

"complex" here seems to mean a long enumeration of
possiblities. "simple" seems to mean a small set of operations
that can be composed.  like 9p+mount/bind.  or more
ubiquitously regular expressions.

if you've ever tried to explain regular expressions to
someone, perhaps you know what i mean.

- erik

On Fri Mar 31 03:17:48 CST 2006, nemo@lsub.org wrote:
> We just came back from percom, where we
> gave a couple of talks about Plan B and Omero.
> Perhaps surprisingly, the main problem for
> people to understand what we did was not a
> particular point in Plan B, but the main Plan 9 idea.
>
> When you say "everything is a file", they get scared.
> When you convince them that those "files" are not
> files on disk, and that you exchange data using the fs
> interface, then their main argument is:
>
> 	It's so simple that this probably does not work.
>
> Simplicity seems to be hard to grasp. And also, most
> people IMHO really forgot unix and what interfaces are
> about.
>
> Type checking was also a concern. I think they did not
> understand that a data type (or xml tree) is not a guarantee
> to have the system know about "semantics". They got
> even more scared when I replied that the system should
> best not be involved in semantics (which is up to the user).
>
> So, sic.
>

Re: [9fans] new compilers

[erik quanstrom]

ioctl is so 2002.  netlink sockets are all the rage now.

- erik

On Thu Mar 30 13:59:35 CST 2006, leimy2k@gmail.com wrote:
> On 3/30/06, Rob Pike <robpike@gmail.com> wrote:
> > Also, ioctl masks the direction of data motion, while read and
> > write make it was explicit as can be.
> >
> > -rob
> >
>
> It really does seem that ioctl is just a "kitchen sink" for operations
> on resources in a filesystem that people didn't think could be
> addressed as files at the time.
>
> The xattr stuff seems neat on the surface because you effectively get
> a hierarchical namespace directly attached to your device file.  Of
> course, there's really nothing stopping us from doing that with
> directories the Plan 9 way I suppose.
>
> In fact, I often wondered why the eia* stuff kind of differed in
> structure from the sd* stuff.
>
> Any good reason not to do
> eia0/ctl
> eia0/data
> eia0/status
>
> Dave

Re: [9fans] new compilers

[Bruce Ellis]

"ioctls()s make me wanta smoke crack" - from a beck song
i think.  i'd rather an echo and a coffee.

brucee

On 4/1/06, erik quanstrom <quanstro@quanstro.net> wrote:
> ioctl is so 2002.  netlink sockets are all the rage now.
>
> - erik
>
> On Thu Mar 30 13:59:35 CST 2006, leimy2k@gmail.com wrote:
> > On 3/30/06, Rob Pike <robpike@gmail.com> wrote:
> > > Also, ioctl masks the direction of data motion, while read and
> > > write make it was explicit as can be.
> > >
> > > -rob
> > >
> >
> > It really does seem that ioctl is just a "kitchen sink" for operations
> > on resources in a filesystem that people didn't think could be
> > addressed as files at the time.
> >
> > The xattr stuff seems neat on the surface because you effectively get
> > a hierarchical namespace directly attached to your device file.  Of
> > course, there's really nothing stopping us from doing that with
> > directories the Plan 9 way I suppose.
> >
> > In fact, I often wondered why the eia* stuff kind of differed in
> > structure from the sd* stuff.
> >
> > Any good reason not to do
> > eia0/ctl
> > eia0/data
> > eia0/status
> >
> > Dave
>

Re: [9fans] new compilers

[Fco. J. Ballesteros]

:  >> When you say "everything is a file", they get scared.
:  >
:  > why is that?  were they bitten by one as a child?

I think it's because suddenly they see "no xml, no java, no arpcs, no ...
but still, it works". That hurts when you are working on "xml, java, arpcs, ...".

Re: [9fans] new compilers

[Charles Forsyth]

> I think it's because suddenly they see "no xml, no java, no arpcs, no ...
> but still, it works". That hurts when you are working on "xml, java, arpcs, ...".

they should get out a bit more.

Re: [9fans] new compilers

[Charles Forsyth]

> That hurts when you are working on "xml, java, arpcs, ...".

if they're working with that lot, they must indeed be used to pain.
you can reassure them that files don't bite.

it's a little strange, along the lines of the story about the man being
shown in early unix days how to create a file, who couldn't at first understand
how the computer could be able to create a file with
	cp this that
without specifying LRECL, BLKSIZE, VOLUME, SPACE, etc etc.

Re: [9fans] new compilers

[Bruce Ellis]

when a clueless marketing manager is given a checklist
from a clueless potential client then horrible things can and
will happen.  we've seen it.

brucee

On 4/1/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > That hurts when you are working on "xml, java, arpcs, ...".
>
> if they're working with that lot, they must indeed be used to pain.
> you can reassure them that files don't bite.
>
> it's a little strange, along the lines of the story about the man being
> shown in early unix days how to create a file, who couldn't at first understand
> how the computer could be able to create a file with
>        cp this that
> without specifying LRECL, BLKSIZE, VOLUME, SPACE, etc etc.
>
>

Re: [9fans] new compilers

[Fco. J. Ballesteros]

We just came back from percom, where we
gave a couple of talks about Plan B and Omero.
Perhaps surprisingly, the main problem for
people to understand what we did was not a
particular point in Plan B, but the main Plan 9 idea.

When you say "everything is a file", they get scared.
When you convince them that those "files" are not
files on disk, and that you exchange data using the fs
interface, then their main argument is:

	It's so simple that this probably does not work.

Simplicity seems to be hard to grasp. And also, most
people IMHO really forgot unix and what interfaces are
about.

Type checking was also a concern. I think they did not
understand that a data type (or xml tree) is not a guarantee
to have the system know about "semantics". They got
even more scared when I replied that the system should
best not be involved in semantics (which is up to the user).

So, sic.

Re: [9fans] new compilers

[Skip Tavakkolian]

> Type checking was also a concern. I think they did not
> understand that a data type (or xml tree) is not a guarantee
> to have the system know about "semantics". They got
> even more scared when I replied that the system should
> best not be involved in semantics (which is up to the user).

UBF can have "contracts" that are verifiable.

i agree about the semantics.  i am still not sure why the network
machinary in the middle would need to know what "volume 50" means if
only the requestor shell script and the noisemaker server need to
understand it's meaning.

Re: [9fans] new compilers

[Skip Tavakkolian]

> Type checking was also a concern. I think they did not
> understand that a data type (or xml tree) is not a guarantee
> to have the system know about "semantics". They got
> even more scared when I replied that the system should
> best not be involved in semantics (which is up to the user).

UBF can have "contracts" that are verifiable.

i agree about the semantics.  i am still not sure why the network
machinery in the middle would need to know what "volume 50" means if
only the requester shell script and the noisemaker server need to
understand it's meaning.

Re: [9fans] new compilers

[Charles Forsyth]

> Type checking was also a concern. I think they did not
> understand that a data type (or xml tree) is not a guarantee
> to have the system know about "semantics". They got
> even more scared when I replied that the system should
> best not be involved in semantics (which is up to the user).

i have heard that before.  it's worth noting (just for the sake of it,
not because anyone necessarily takes it in) that the system has got
certain conventions.  for instance, networks are in /net and their name spaces
must adhere to some network-independent conventions, both in terms
of names they present, and how those names behave with open/read/write.

furthermore, control requests are checked by write and return an error if they are invalid.
(that by the way is something they often don't realise unless you point it out.)
this is not much different in practice from python (say) checking types of things
at run-time.  or javascript (and AJAX is all the rage, and note that the X in that is optional).
actually, it is different, because in my experience run-time errors
in python programs are not uncommon, but i never see /proc inadvertently confused with /net.
it is easy to use the wrong instance of something (eg, an inside /net not the outside one)
but then they would have the same type.

if you have the need, you can put a contract-enforcing name
space in the way of another name space.  as a simple example, a few
lines of code, easily validated, will enforce read-only access to the contents of any
name space.  that is quite hard to do with web services in general.

Re: [9fans] new compilers

[Charles Forsyth]

> When you say "everything is a file", they get scared.

why is that?  were they bitten by one as a child?
what's the greek name for that fear?

Re: [9fans] new compilers

[Skip Tavakkolian]

>> When you say "everything is a file", they get scared.
>
> why is that?  were they bitten by one as a child?
> what's the greek name for that fear?

i don't know, but our condition might be fileophilia

Re: [9fans] new compilers

[Skip Tavakkolian]

>> what's the greek name for that fear?
>
> i don't know, but our condition might be fileophilia

actually, wouldn't it be fileophobia?

Re: [9fans] new compilers

[Bruce Ellis]

dumb-ass (checking greek dictionary).

brucee

On 3/31/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> >> what's the greek name for that fear?
> >
> > i don't know, but our condition might be fileophilia
>
> actually, wouldn't it be fileophobia?
>
>

Re: [9fans] new compilers

[Charles Forsyth]

> actually, wouldn't it be fileophobia?

i imagined by analogy with xenophobia, etc that one would use a greek term for file
but my greek grammar is older than computers.

Re: [9fans] new compilers

[Skip Tavakkolian]

>> actually, wouldn't it be fileophobia?
>
> i imagined by analogy with xenophobia, etc that one would use a greek term for file
> but my greek grammar is older than computers.

mine is nonexistent; Q.E.D

Re: [9fans] new compilers

[David Leimbach]

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

On 3/31/06, Skip Tavakkolian <9nut@9netics.com> wrote:
>
> >> what's the greek name for that fear?
> >
> > i don't know, but our condition might be fileophilia
>
> actually, wouldn't it be fileophobia?
>
>
And one who is a fan of phobias is a phobiaphile ?

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

Re: [9fans] new compilers

[Bruce Ellis]

dose that make you a phobiaphilaphile?

brucee

On 4/1/06, David Leimbach <leimy2k@gmail.com> wrote:
>
>
>
> On 3/31/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> > >> what's the greek name for that fear?
> > >
> > > i don't know, but our condition might be fileophilia
> >
> > actually, wouldn't it be fileophobia?
> >
> >
>
> And one who is a fan of phobias is a phobiaphile ?
>

Re: [9fans] new compilers

[Taj Khattra]

> Simplicity seems to be hard to grasp.

deja vu.  as a wise man once said:

    "Unix is simple. It just takes a genius to understand its simplicity."

Re: [9fans] new compilers

[Ronald G Minnich]

Fco. J. Ballesteros wrote:

> When you say "everything is a file", they get scared.

yes, indeedy. "everything is a file" is a really, really bad thing to
say, I've found.


> 	It's so simple that this probably does not work.

go figure. I get that too.

>
> Simplicity seems to be hard to grasp. And also, most
> people IMHO really forgot unix and what interfaces are
> about.


what a world, what a world.

ron

Re: [9fans] new compilers

[Paul Lalonde]

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

Everything has a file-like interface; the interface is served over a
network routing protocol that makes remote interfaces look just like
local interfaces.

I've had reasonable success that way.

Paul

On 3-Apr-06, at 9:21 AM, Ronald G Minnich wrote:

> Fco. J. Ballesteros wrote:
>
>> When you say "everything is a file", they get scared.
>
> yes, indeedy. "everything is a file" is a really, really bad thing
> to say, I've found.
>
>
>> 	It's so simple that this probably does not work.
>
> go figure. I get that too.
>
>> Simplicity seems to be hard to grasp. And also, most
>> people IMHO really forgot unix and what interfaces are
>> about.
>
>
> what a world, what a world.
>
> ron

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

iD8DBQFEMViNpJeHo/Fbu1wRAvDkAKCXudkWsei10/XWTYVpf9YfKUZjTACgreCd
IqXkvMofFqOJZGRW9CN/dHI=
=to2d
-----END PGP SIGNATURE-----

Re: [9fans] new compilers

[Artem Letko]

i'd drop "routing", though.

-art

On 4/3/06, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Everything has a file-like interface; the interface is served over a
> network routing protocol that makes remote interfaces look just like
> local interfaces.
>
> I've had reasonable success that way.
>
> Paul
>
> On 3-Apr-06, at 9:21 AM, Ronald G Minnich wrote:
>
> > Fco. J. Ballesteros wrote:
> >
> >> When you say "everything is a file", they get scared.
> >
> > yes, indeedy. "everything is a file" is a really, really bad thing
> > to say, I've found.
> >
> >
> >>      It's so simple that this probably does not work.
> >
> > go figure. I get that too.
> >
> >> Simplicity seems to be hard to grasp. And also, most
> >> people IMHO really forgot unix and what interfaces are
> >> about.
> >
> >
> > what a world, what a world.
> >
> > ron
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEMViNpJeHo/Fbu1wRAvDkAKCXudkWsei10/XWTYVpf9YfKUZjTACgreCd
> IqXkvMofFqOJZGRW9CN/dHI=
> =to2d
> -----END PGP SIGNATURE-----
>

Re: [9fans] new compilers

[Paul Lalonde]

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

Yes, I would drop "routing".  Somehow my mind-brain duality flubbed
there.

Paul

On 3-Apr-06, at 12:01 PM, Artem Letko wrote:

> i'd drop "routing", though.
>
> -art
>
> On 4/3/06, Paul Lalonde <plalonde@telus.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Everything has a file-like interface; the interface is served over a
>> network routing protocol that makes remote interfaces look just like
>> local interfaces.
>>
>> I've had reasonable success that way.
>>
>> Paul
>>
>> On 3-Apr-06, at 9:21 AM, Ronald G Minnich wrote:
>>
>>> Fco. J. Ballesteros wrote:
>>>
>>>> When you say "everything is a file", they get scared.
>>>
>>> yes, indeedy. "everything is a file" is a really, really bad thing
>>> to say, I've found.
>>>
>>>
>>>>      It's so simple that this probably does not work.
>>>
>>> go figure. I get that too.
>>>
>>>> Simplicity seems to be hard to grasp. And also, most
>>>> people IMHO really forgot unix and what interfaces are
>>>> about.
>>>
>>>
>>> what a world, what a world.
>>>
>>> ron
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Darwin)
>>
>> iD8DBQFEMViNpJeHo/Fbu1wRAvDkAKCXudkWsei10/XWTYVpf9YfKUZjTACgreCd
>> IqXkvMofFqOJZGRW9CN/dHI=
>> =to2d
>> -----END PGP SIGNATURE-----
>>

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

iD8DBQFEMXYEpJeHo/Fbu1wRAkweAJ9ELYo94rvwb9SsKNqvD+okLOMKhgCfW7Go
RPogexbEoZQ30NhDZHFfqsY=
=U9+5
-----END PGP SIGNATURE-----

Re: [9fans] new compilers

[Steve Simon]

> ioctl(fd, SETVOLUME, &vol); is more comfortable.

I may be wrong, but I think
some sarscasm was indented.

-Steve

Re: [9fans] new compilers

[erik quanstrom]

i believe this is a religous question.  it depends on one's belief in the
inate sensibility of programmers.

that is to say, it depends on how many large projects (double credit
for commercial) one's worked on.

;-) erik

On Tue Mar 28 12:17:31 CST 2006, bakul+plan9@bitblocks.com wrote:
> > P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
> > the creation of Linux.
>
> Hmm... and all this time I thought Linux wouldn't have
> succeeded if Plan 9 had preceded it out in the open software
> world.
>
> May be it is wishful thinking but I suspect even now a Plan 9
> based book along the lines of "the Unix Programming
> Environment" will find a receptive audience.

Re: [9fans] new compilers

[erik quanstrom]

we should not deprive andy tannenbaum of one iota of the credit he
so richly deserves for spurring the creation of linux.

all linus wanted was the ability to distribute a pre-patched version of minix
which supported a few non-80286-compatable convienences like protected
memory.

- erik

On Sun Mar 26 02:15:00 CST 2006, lyndon@orthanc.ca wrote:
>
> On Mar 25, 2006, at 6:52 PM, quanstro@quanstro.net wrote:
>
> > i've got to say one thing in gcc's favor. it was way the heck
> > better than
> > any other compiler i had available when it was first written.
>
> I have fond memories of threatining the Sun sales sloths with death
> and worse if they didn't at least ship .h files after they unbundled
> the C compiler.  Sun is as responsible for GCC as the AT&T lawyers
> are responsible for Linux.
>
> --lyndon

Re: [9fans] new compilers

[Lyndon Nerenberg]

> we should not deprive andy tannenbaum of one iota of the credit he
> so richly deserves for spurring the creation of linux.

>> I have fond memories of threatining the Sun sales sloths with death
>> and worse if they didn't at least ship .h files after they unbundled
>> the C compiler.  Sun is as responsible for GCC as the AT&T lawyers
>> are responsible for Linux.

True enough.  My point was that both GCC and Linux received a tremendous
boost in popularity due to two massive acts of corporate stupidity.

--lyndon

P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
the creation of Linux.

Re: [9fans] new compilers

[Bakul Shah]

> P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
> the creation of Linux.

Hmm... and all this time I thought Linux wouldn't have
succeeded if Plan 9 had preceded it out in the open software
world.

May be it is wishful thinking but I suspect even now a Plan 9
based book along the lines of "the Unix Programming
Environment" will find a receptive audience.

Re: [9fans] new compilers

[Sape Mullender]

>> P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
>> the creation of Linux.

This is how myths are born.  Andy Tanenbaum (one n) had nothing to do with
Linux.  He started Minix.  Maybe the existence of Minix played a role in Linus'
decision to start Linux, maybe not.

	Sape

Re: [9fans] new compilers

[LiteStar numnums]

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

If I remember correctly Linus created Linux because he could not distributed
some of the fixes he had made for Minix in a single package. Can someone
correct or verify this?

On 3/28/06, Sape Mullender <sape@plan9.bell-labs.com> wrote:
>
> >> P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for
> spurring
> >> the creation of Linux.
>
> This is how myths are born.  Andy Tanenbaum (one n) had nothing to do with
> Linux.  He started Minix.  Maybe the existence of Minix played a role in
> Linus'
> decision to start Linux, maybe not.
>
>         Sape
>
>


--
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

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

Re: [9fans] new compilers

[Victor Nazarov]

LiteStar numnums wrote:

> If I remember correctly Linus created Linux because he could not
> distributed some of the fixes he had made for Minix in a single
> package. Can someone correct or verify this?
>
Yes. That's right. Whole story (from Linus's point of view) is in
Linus's Just for Fun book. Really Linux was just a terminal emulator for
connecting to the University computer. Linus announce the creation of
some working code in minix mailing list and Linus name himself as a
great fan of Andy Tannenbaum's book The Design and Implementation of OS
(Minix book)

--
Victor

Re: [9fans] new compilers

[Burton Samograd]

On 3/28/06, Victor Nazarov <vir@comtv.ru> wrote:
> LiteStar numnums wrote:
>
> Yes. That's right. Whole story (from Linus's point of view) is in
> Linus's Just for Fun book. Really Linux was just a terminal emulator for
> connecting to the University computer. Linus announce the creation of
> some working code in minix mailing list and Linus name himself as a
> great fan of Andy Tannenbaum's book The Design and Implementation of OS
> (Minix book)

I've been hearing this "terminal emulator" story quite a bit lately
(over the past couple of months), and, althought I do dislike talking
part in such arguments, the story that I've always heard (circa '94)
was that linux was the result of wanting to try out the protected mode
features of his spiffy new '386, which I assume that minix didn't
support.

--
burton samograd                                                kruhft@gmail.com
kruhft.blogspot.com   www.myspace.com/kruhft   metashell.blogspot.com

Re: [9fans] new compilers

[Francisco J Ballesteros]

Doesn´t the "Linus´s Just for Fun" book title answer these
questions? :-)

On 3/29/06, Burton Samograd <kruhft@gmail.com> wrote:
> On 3/28/06, Victor Nazarov <vir@comtv.ru> wrote:
> > LiteStar numnums wrote:
> >
> > Yes. That's right. Whole story (from Linus's point of view) is in
> > Linus's Just for Fun book. Really Linux was just a terminal emulator for
> > connecting to the University computer. Linus announce the creation of
> > some working code in minix mailing list and Linus name himself as a
> > great fan of Andy Tannenbaum's book The Design and Implementation of OS
> > (Minix book)
>
> I've been hearing this "terminal emulator" story quite a bit lately
> (over the past couple of months), and, althought I do dislike talking
> part in such arguments, the story that I've always heard (circa '94)
> was that linux was the result of wanting to try out the protected mode
> features of his spiffy new '386, which I assume that minix didn't
> support.
>
> --
> burton samograd                                                kruhft@gmail.com
> kruhft.blogspot.com   www.myspace.com/kruhft   metashell.blogspot.com
>
>

Re: [9fans] new compilers

[Wes Kussmaul]

Francisco J Ballesteros wrote:

>Doesn´t the "Linus´s Just for Fun" book title answer these
>questions? :-)
>  
>
Indeed, I bet Linus himself doesn't remember half the "justifications" 
for doing it.

Re: [9fans] new compilers

[Aharon Robbins]

In article <2afc30c8b36e542ca0a16fc6f4e4c1a3@plan9.bell-labs.com> you write:
>>> P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
>>> the creation of Linux.
>
>This is how myths are born.  Andy Tanenbaum (one n) had nothing to do with
>Linux.  He started Minix.  Maybe the existence of Minix played a role in Linus'
>decision to start Linux, maybe not.
>
>	Sape

Ah, but he did. There were TONS of people begging Andy to make Minix
do virtual memory on 386 hardware and also to loosen up somewhat on the
licensing. He would do neither.

As a result, there were a huge number of people frothing at the mouth to
just hack on *something, anything* that would run on a 386, so when Linus
released his toy, the world jumped in.

There were also later exchanges between Andy and Linux about microkernel
vs. macrokernel etc.  One could probably still find all this on Google
were one really interested.

It may also help to remember that commercial Unix for 386 was several
hundred dollars a pop, for a binary-only copy, and that was SVR3 or
SVR4, not very exciting to people used to hacking on BSD Unix. (Plus
maybe some additional $$ for a compiler!)

Arnold

Re: [9fans] new compilers

[Bruce Ellis]

what else do we need in the plan9 kernel?  and when will the first
linux distribution that comes in a 10 DVD boxed set be released?

brucee

On 4/3/06, Aharon Robbins <arnold@skeeve.com> wrote:
> In article <2afc30c8b36e542ca0a16fc6f4e4c1a3@plan9.bell-labs.com> you write:
> >>> P.S.  This doesn't mean I'll ever *forgive* Andy Tannenbaum for spurring
> >>> the creation of Linux.
> >
> >This is how myths are born.  Andy Tanenbaum (one n) had nothing to do with
> >Linux.  He started Minix.  Maybe the existence of Minix played a role in Linus'
> >decision to start Linux, maybe not.
> >
> >       Sape
>
> Ah, but he did. There were TONS of people begging Andy to make Minix
> do virtual memory on 386 hardware and also to loosen up somewhat on the
> licensing. He would do neither.
>
> As a result, there were a huge number of people frothing at the mouth to
> just hack on *something, anything* that would run on a 386, so when Linus
> released his toy, the world jumped in.
>
> There were also later exchanges between Andy and Linux about microkernel
> vs. macrokernel etc.  One could probably still find all this on Google
> were one really interested.
>
> It may also help to remember that commercial Unix for 386 was several
> hundred dollars a pop, for a binary-only copy, and that was SVR3 or
> SVR4, not very exciting to people used to hacking on BSD Unix. (Plus
> maybe some additional $$ for a compiler!)
>
> Arnold
>

Re: [9fans] new compilers

[lucio]

> Ah, but he did. There were TONS of people begging Andy to make Minix
> do virtual memory on 386 hardware and also to loosen up somewhat on the
> licensing. He would do neither.

I wasn't paying attention to the public debate at the time and even
managed not to notice the micro-kernel/monolythic-kernel controversy,
but I have a pretty clear recollection that the licencing for Minix
was dictated by McGraw-Hill, the publishers of the Minix book, rather
than Tanenbaum himself.

As for 386-hardware, I already mentioned that Bruce Evans had a
legitimate minix-386 going, whether virtual memory was involved or
not, I have no recollection.  The licencing, I recall, was that you
had to have paid for the source distribution and you were then
entitled to all subsequent upgrades and so on.  I did not get the
impression that it was a show stopper at the time, I paid considerably
more for Plan 9 with a much more restrictive licence.

I had some very brief interactions with Andy (and Bruce) at the time,
and both struck me as extremely pleasant, down to earth people.
Torvalds never gave me the same warm feeling as they.

++L

Re: [9fans] new compilers

[Skip Tavakkolian]

> As for 386-hardware, I already mentioned that Bruce Evans had a
> legitimate minix-386 going, whether virtual memory was involved or
> not, I have no recollection.  The licencing, I recall, was that you
> had to have paid for the source distribution and you were then
> entitled to all subsequent upgrades and so on.  I did not get the
> impression that it was a show stopper at the time, I paid considerably
> more for Plan 9 with a much more restrictive licence.

I seem to recall that 386BSD was available at about the same time.  i
don't know why it didn't catch on the way linux did.

Re: [9fans] new compilers

[LiteStar numnums]

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

The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from BSD.

On 4/2/06, Skip Tavakkolian <9nut@9netics.com> wrote:
>
> > As for 386-hardware, I already mentioned that Bruce Evans had a
> > legitimate minix-386 going, whether virtual memory was involved or
> > not, I have no recollection.  The licencing, I recall, was that you
> > had to have paid for the source distribution and you were then
> > entitled to all subsequent upgrades and so on.  I did not get the
> > impression that it was a show stopper at the time, I paid considerably
> > more for Plan 9 with a much more restrictive licence.
>
> I seem to recall that 386BSD was available at about the same time.  i
> don't know why it didn't catch on the way linux did.
>
>


--
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

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

Re: [9fans] new compilers

[lucio]

> The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from BSD.

Professionals, maybe, but backyard hackers had little reason to care.
I looked at Linux and at 386BSD (and QNX and BSDi) and 386BSD came up
tops.  Linux had no graphics (nor had the BSDs) and KA9Q as networking
(so did the Unix PC, a little earlier, that's what I cut my teeth on),
so there was some other factor there that I did not see, then or now.
Crazily, it may have been the GNU licence, but I'm not convinced.

I'll need to ask my Linux guru (CCed).

++L

Re: [9fans] new compilers

[George Michaelson]

nobody who held a valid licence from the regents had any reason to care
about that lawsuit.

[I worked in several academic/research institutions holding BSD regents
 licences, and while the were a complet PITA to deal with over
 re-re-re-signings and the like (if you couldn't dig up the corpse and
 use the hand to sign the documents with a forgery of the original
 signatures on the first paperwork ever signed with Berkeley, then you
 couldn't renew licences: like the role of 'vice chancellor' never
 changes in the lifetime of a business relationship with Berkeley!) ]

[having said which, the longest delay I ever saw on a tape was due to
 British customs holding 4.2BSD until they got payment on some
 calculated VAT value.]

-G

Re: [9fans] new compilers

[Lyndon Nerenberg]

On Apr 2, 2006, at 10:38 PM, George Michaelson wrote:

> [I worked in several academic/research institutions holding BSD
> regents
>  licences, and while the were a complet PITA to deal with over
>  re-re-re-signings and the like (if you couldn't dig up the corpse and
>  use the hand to sign the documents with a forgery of the original
>  signatures on the first paperwork ever signed with Berkeley, then you
>  couldn't renew licences: like the role of 'vice chancellor' never
>  changes in the lifetime of a business relationship with Berkeley!) ]

How was this different from dealing with AT&T?  Both had assinine
beaurocracy.

It took me close to a month to register for the SVR3 kernel internals
course.  As a Canadian, I didn't have a US social security number.  I
never did find out why that was a pre-requisite.  They did finally
settle for my phone number instead.

--lyndon

Re: [9fans] new compilers

[LiteStar numnums]

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

I think the suit had alot to do with it. There was no question as to the
origins
or legality of linux. It was free, open & mutable. 386BSD was all of these
things,
but the stigma of a lawsuit, regardless of merit, can make people question
where
they will want to invest their time. Even though linux was not a the same
level
as 386BSD when it was released, it was without any questions as to whether
or
not your code & work will continue to be fruitful (it's nice to make
sentances run).
I believe that linux was at the right place at the right time; before
'hacking' became
some nebulous & mediocre buzz word. Simply ripe for the picking.

On 4/3/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
>
> > The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from
> BSD.
>
> Professionals, maybe, but backyard hackers had little reason to care.
> I looked at Linux and at 386BSD (and QNX and BSDi) and 386BSD came up
> tops.  Linux had no graphics (nor had the BSDs) and KA9Q as networking
> (so did the Unix PC, a little earlier, that's what I cut my teeth on),
> so there was some other factor there that I did not see, then or now.
> Crazily, it may have been the GNU licence, but I'm not convinced.
>
> I'll need to ask my Linux guru (CCed).
>
> ++L
>
>


--
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

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

Re: [9fans] new compilers

[Lyndon Nerenberg]

> Professionals, maybe, but backyard hackers had little reason to care.

But the pro's had the commercial distributions; I don't think it
really mattered to them.  (I had Irix and Solaris (and SCO :-P) at
work.  My interest in *BSD was to have something I could experiment
with outside of my day job.)

> Linux had no graphics (nor had the BSDs)

I don't think that's true.  X11 was around and reasonably portable.
(BSDi had it in the alpha and beta releases circa 1993.)

> and KA9Q as networking

Phil's code had a narrow audience at the time.  I ran both NOS and
early Linux at the time, and settled on NOS because it was more
reliable than the Linux kernels of the day.  The Linux code was also
almost impossible to configure and install at that time.  I ended up
running a mailing list for six months off a PC running NOS.  Ugly,
but it worked.  (But NOS kicked Linux hands down for the radio side
of things, and I was running a couple of high-traffic AX25 gateways
at the time.)

--lyndon

Re: [9fans] new compilers

[uriel]

I don't know how to put this politely, so I won't.

Please take this thread to the lunix-history-fans list.

Thank you

uriel

Re: [9fans] new compilers

[Martin C. Atkins]

On Mon, 3 Apr 2006 11:36:01 +0200 uriel@cat-v.org wrote:
> I don't know how to put this politely, so I won't.
>
> Please take this thread to the lunix-history-fans list.

I must say, that I think that was very polite!
>
> Thank you

Thank you!

>
> uriel
>
Martin

--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] new compilers

[lucio]

>> Professionals, maybe, but backyard hackers had little reason to care.
>
> But the pro's had the commercial distributions; I don't think it
> really mattered to them.  (I had Irix and Solaris (and SCO :-P) at
> work.  My interest in *BSD was to have something I could experiment
> with outside of my day job.)
>
I guess we are in agreement, Linux and the BSDs were the hackers'
options.  Minix was, too.

>> Linux had no graphics (nor had the BSDs)
>
> I don't think that's true.  X11 was around and reasonably portable.
> (BSDi had it in the alpha and beta releases circa 1993.)
>
Well, it had X before TCP/IP, which originally was...

>> and KA9Q as networking
>
> Phil's code had a narrow audience at the time.

By some measure, sure, but I ran a dial-in Internet access service
using a (badly) hacked PPP module in KA9Q.  Someone even released a
local version of KA9Q as a South African product, in contravention of
its licence.  Within my circle of Internet "heads", KA9Q was all the
rage.  And Bdale Garbee (sp?)'s manual.doc is still my recommendation
to learn the fundamentals of TCP/IP.  Not that anyone has listened to
my recommendation :-(

Funny, you could download Linux over the 'Net, but you could not
connect with it.  It took Win'95, in my environment, to popularise the
'Net.

I think X was a bit of a toy until TCP/IP became a reality, porting X
without TCP/IP deedn't seem any easier than running *BSD without
TCP/IP.  Possible, but not easy.

++L

Re: [9fans] new compilers

[Brantley Coile]

BSDi was the way I went in those days before Plan 9 was released.  It
was cheap, it had all the source and it was easier to install
than the other systems I'd played with.

But as soon as I could switch back to plan 9 ....


lucio@proxima.alt.za wrote:
>>The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from BSD.
>
>
> Professionals, maybe, but backyard hackers had little reason to care.
> I looked at Linux and at 386BSD (and QNX and BSDi) and 386BSD came up
> tops.  Linux had no graphics (nor had the BSDs) and KA9Q as networking
> (so did the Unix PC, a little earlier, that's what I cut my teeth on),
> so there was some other factor there that I did not see, then or now.
> Crazily, it may have been the GNU licence, but I'm not convinced.
>
> I'll need to ask my Linux guru (CCed).
>
> ++L
>

Re: [9fans] new compilers

[David Leimbach]

On 4/2/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from BSD.
>
> Professionals, maybe, but backyard hackers had little reason to care.
> I looked at Linux and at 386BSD (and QNX and BSDi) and 386BSD came up
> tops.  Linux had no graphics (nor had the BSDs) and KA9Q as networking
> (so did the Unix PC, a little earlier, that's what I cut my teeth on),
> so there was some other factor there that I did not see, then or now.
> Crazily, it may have been the GNU licence, but I'm not convinced.
>
> I'll need to ask my Linux guru (CCed).
>
> ++L
>
>

Alan Cox of Linux fame says he used linux because it had FP emulation.
(IIRC).  Otherwise he'd have used 386BSD instead.

Re: [9fans] new compilers

[Bruce Ellis]

i recall a prof who bought a mac becasue "it wasn't unix" and "it wasn't intel".
that was years ago .... things have changed huh?

brucee

On 4/4/06, David Leimbach <leimy2k@gmail.com> wrote:
> On 4/2/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > > The whole AT&T vs. BSD lawsuit fiasco scared alot of people away from BSD.
> >
> > Professionals, maybe, but backyard hackers had little reason to care.
> > I looked at Linux and at 386BSD (and QNX and BSDi) and 386BSD came up
> > tops.  Linux had no graphics (nor had the BSDs) and KA9Q as networking
> > (so did the Unix PC, a little earlier, that's what I cut my teeth on),
> > so there was some other factor there that I did not see, then or now.
> > Crazily, it may have been the GNU licence, but I'm not convinced.
> >
> > I'll need to ask my Linux guru (CCed).
> >
> > ++L
> >
> >
>
> Alan Cox of Linux fame says he used linux because it had FP emulation.
> (IIRC).  Otherwise he'd have used 386BSD instead.
>

Re: [9fans] new compilers

[Jack Johnson]

On 4/3/06, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> i recall a prof who bought a mac becasue "it wasn't unix" and "it wasn't intel".
> that was years ago .... things have changed huh?

Speaking of which, does anyone have any opinion of Objective-C, other
than the preponderance of things like
kAudioHardwarePropertyBootChimeVolumeRangeDecibels in the prevalent
code?

-Jack

Re: [9fans] new compilers

[uriel]

> On 4/3/06, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> i recall a prof who bought a mac becasue "it wasn't unix" and "it wasn't intel".
>> that was years ago .... things have changed huh?
>
> Speaking of which, does anyone have any opinion of Objective-C, other
> than the preponderance of things like
> kAudioHardwarePropertyBootChimeVolumeRangeDecibels in the prevalent
> code?

I would rather ask:

	"What is wrong with C?"

 and then

	"What is wrong with C that Limbo didn't fix?"


Maybe 9fans should be renamed lunix-history-buffs-and-apple-fanboys...

uriel

Re: [9fans] new compilers

[Ronald G Minnich]

uriel@cat-v.org wrote:

> Maybe 9fans should be renamed lunix-history-buffs-and-apple-fanboys...

, no, no, no.

LinuxHistoryBuffsAndAppleFanboysAndBSDToo

I did not know that being a 9fan meant you were unable to like other
things as well. Polygamy is legal in the software game.

ron

Re: [9fans] new compilers

[Bruce Ellis]

it would need at least an Ex version to add more 0 parameters.

LinuxHistoryBuffsAndAppleFanboysAndBSDTooEx(0,0,0,0,0,0,0,0)

brucee

On 4/4/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> uriel@cat-v.org wrote:
>
> > Maybe 9fans should be renamed lunix-history-buffs-and-apple-fanboys...
>
> , no, no, no.
>
> LinuxHistoryBuffsAndAppleFanboysAndBSDToo
>
> I did not know that being a 9fan meant you were unable to like other
> things as well. Polygamy is legal in the software game.
>
> ron
>

Re: [9fans] new compilers

[Anthony Sorace]

On 4/3/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
// I did not know that being a 9fan meant you were unable
// to like other things as well.

can someone gen ron a copy of the Fanboy Handbook? i've mislaid mine.
c'mon, ron - zealotry  is mandatory! perspective is for philosophers.

Re: [9fans] new compilers

[Bruce Ellis]

can someone set up a scsi drive in less than 4 months?

ask yourself.

brucee

On 4/4/06, Anthony Sorace <anothy@gmail.com> wrote:
> On 4/3/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> // I did not know that being a 9fan meant you were unable
> // to like other things as well.
>
> can someone gen ron a copy of the Fanboy Handbook? i've mislaid mine.
> c'mon, ron - zealotry  is mandatory! perspective is for philosophers.
>

Re: [9fans] new compilers

[Jack Johnson]

On 4/3/06, uriel@cat-v.org <uriel@cat-v.org> wrote:
> I would rather ask:

So, are you say

Re: [9fans] new compilers

[Jack Johnson]

On 4/3/06, uriel@cat-v.org <uriel@cat-v.org> wrote:
> I would rather ask:

So, are you saying you have no opinion, or would you rather not share
it?  You might as well have asked what's wrong with Ford that BMW
didn't fix?

I have no opinion--no experience with it--which is why I'm asking. 
I'm not out to berate someone else's choice.  And, not to belittle
Limbo, but one motivation for creating Objective-C was to avoid
Smalltalk's VM.  So, if you really believe Limbo in some way fixed C,
are you also implying that avoiding the VM in Objective-C was a poor
design choice?

-Jack

Re: [9fans] new compilers

[David Leimbach]

On 4/3/06, Jack Johnson <knapjack@gmail.com> wrote:
> On 4/3/06, uriel@cat-v.org <uriel@cat-v.org> wrote:
> > I would rather ask:
>
> So, are you saying you have no opinion, or would you rather not share
> it?  You might as well have asked what's wrong with Ford that BMW
> didn't fix?
>
> I have no opinion--no experience with it--which is why I'm asking.
> I'm not out to berate someone else's choice.  And, not to belittle
> Limbo, but one motivation for creating Objective-C was to avoid
> Smalltalk's VM.  So, if you really believe Limbo in some way fixed C,
> are you also implying that avoiding the VM in Objective-C was a poor
> design choice?
>
> -Jack
>
No VM but a pretty interesting runtime, with lots of ways to pass data
around of any type but then find out if it's supported at runtime.

I think Objective-C opened a lot of GUI programming possibilities that
might have been trickier to express in other languages.

There is no one tool that does the job all the time that I've found.

All the world is not a nail.

Dave

Re: [9fans] new compilers

[lucio]

> I would rather ask:
>
> 	"What is wrong with C?"
>
>  and then
>
> 	"What is wrong with C that Limbo didn't fix?"
>
>
> Maybe 9fans should be renamed lunix-history-buffs-and-apple-fanboys...

Well, why don't you fix C _and_ Limbo and we'll humbly allow you to
call the mailing list precisely what you want to.

In fact why don't you go run your own mailing list?

++L

Re: [9fans] new compilers

[Brantley Coile]

uriel@cat-v.org wrote:
> I would rather ask:
>
> 	"What is wrong with C?"
>
>  and then
>
> 	"What is wrong with C that Limbo didn't fix?"
>
>

I don't think the question makes sense.  If you mean why do any other
language than C, then you have to ask, to do what?  Not the beginning
of a discourse, but I just wanted to point out the what's wrong with
the question.

Re: [9fans] new compilers

[Bruce Ellis]

i think charles once said that it was 'leisurely" to program in limbo.
i agree.  the compiler is great, as is the debugger.  use what
ever you like.  i write nearly everything in limbo or VHDL (the limbo
helpers generate most of the VHDL).  it's easier to write a limbo
program to produce the VHDL ...

brucee

On 4/5/06, Brantley Coile <brantley@coraid.com> wrote:
> uriel@cat-v.org wrote:
> > I would rather ask:
> >
> >       "What is wrong with C?"
> >
> >  and then
> >
> >       "What is wrong with C that Limbo didn't fix?"
> >
> >
>
> I don't think the question makes sense.  If you mean why do any other
> language than C, then you have to ask, to do what?  Not the beginning
> of a discourse, but I just wanted to point out the what's wrong with
> the question.
>

Re: [9fans] new compilers

[rog]

actually, the kAudioHardwarePropertyBootChimeVolumeRangeDecibels-type constants
are part of a C interface. i'm not sure if there was an objective-C-style
interface.

i used objective C for a number of years, and i came away with the opinion
that it had initially been quite a neat little (operative word) hack to give
some dynamic binding and a bit of structure to C, but it had turned into
something of a monster. its main problem was lack of modularity - all object
methods lived in the same namespace, and since there were many of them,
huge names were necessitated. the fix for this was to put in place a some
more conventional static class-based typechecking, which was a big mistake
in my view, because one of the nice things about the early objective-C was
freedom of implementation - if you implemented the right methods, then
it didn't matter what class (if any) you inherited from.

in the end objective C suffers from the same flawed inheritance design
as most of the other "object oriented" languages. interfaces are usually
designed by extension rather than by use, so one has to spend much time
writing silly little pieces of non-code to try to mesh what one would
like to do with the design of the interface. the result is often a
tangle of interwoven dependencies that is difficult to understand,
harder to maintain, and almost impossible to refactor.

for something with a stated aim of encouraging software reuse, this style
of OO certainly does a good job of actively discouraging it!

in contrast i've found Limbo's statically typed (but dynamically implemented)
module structure to be excellent for reuse. if objective C
had gone more wholeheartedly down the protocol route, it might have ended
up with something a bit more like this.

Re: [9fans] new compilers

[plan9]

On Sun, Apr 02, 2006 at 09:47:03PM +0200, lucio@proxima.alt.za wrote:
>
> I wasn't paying attention to the public debate at the time and even
> managed not to notice the micro-kernel/monolythic-kernel controversy,
> but I have a pretty clear recollection that the licencing for Minix
> was dictated by McGraw-Hill, the publishers of the Minix book, rather
> than Tanenbaum himself.

The publisher was Prentice Hall, not that anyone really cares.

Re: [9fans] new compilers

[lucio]

> The publisher was Prentice Hall, not that anyone really cares.

Oh, they might, if I'm accusing the wrong ones of blocking
technological progress!

:-(

Thank you for the correction.

++L

Re: [9fans] new compilers

[erik quanstrom]

this sort of programming has a lot in common with the stage of learning
a language where you understand the grammar but don't know the vocabulary.
read two lines. lookup unknown words. lather. rince. repeat.

- erik

On Mon Mar 27 11:30:49 CST 2006, rog@vitanuova.com wrote:
> > I find the notion of pre-compiled headers for anything other than
> > a very special situation rather odd.
>
> it is odd.  i've just been playing with trying to get some stuff
> working under macos x, and the interfaces are just amazing.  the
> standard approach seems to be to enumerate every possible situation
> (often literally, with enums) in the interface.  a few days ago i did
> a little test, just to appreciate the full extent of things.  cpp of a
> null source file (with only the #includes i needed) gave over 100,000
> lines of code.  there were at least 20,000 enum constants defined,
> with names such as kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
> and kAudioFormatProperty_AvailableEncodeChannelLayoutTags.
>
> and the interfaces that are presented are almost unusable even if you
> take that on board.  i've been looking at the audio interfaces;
> functionality provided by the system includes facilities to read mp3
> files, do sample-rate conversion, and produce sound output, so i
> thought, as a first test, i'd try to play an mp3 file.  i haven't
> succeeded yet.
>
> after struggling for a good while, i found some example code that does
> this.  it's over 1000 lines of code.  when it should be about 10.  i'd
> think perhaps it was deliberate, if it didn't all seem so carefully
> done, with loving attention given to every misbegotten line of header
> file.
>
> as charles put it recently, with relation to usb: ``enough is
> specified to make it complicated, but not enough to be complete, once
> for all.'' so true.
>
> given that kind of programming environment, the decision to use
> precompiled headers becomes slightly more understandable, i suppose.
>
> i guess the only good thing is that by using interfaces like that, they'll
> be wasting countless man-hours of programmer time, potentially
> allowing those using smaller, smarter interfaces a competitive advantage.
> yeah right.
>

[9fans] new compilers

[Russ Cox]

Compiler changes yesterday:

  - compiler suite is 3,000 lines smaller
  - incorrect "set and not used" warnings gone
  - incorrect "no return at end of function" warnings gone
  - missing "no return at end of function" warnings added
  - eliminate more dead code in object files,
     especially in 7c kc qc vc.

I did a lot of regression testing, so I'm fairly confident
in the new code.  If you do see new odd behavior
from your programs, try compiling with
/n/sourcesdump/2006/0325/plan9/386/bin/8c.
If that makes a difference, please let me know.

Also, if you get an incorrect warning from the compiler,
or you don't get a warning that you should (like not being
warned about a non-void function missing a return statement),
please mail me a test program and I will fix the compiler.

Thanks.
Russ

Re: [9fans] new compilers

[David Leimbach]

On 3/25/06, Russ Cox <rsc@swtch.com> wrote:
> Compiler changes yesterday:
>
>   - compiler suite is 3,000 lines smaller

no no no... when you change code you're supposed to add more code. 
Aren't you paying attention to the way software development apparently
works? :)

I'll check it out later.  My old Plan 9 disk died but I've been pretty
happy in "Q" lately on my intel mac.

Dave

Re: [9fans] new compilers

[Burton Samograd]

> >   - compiler suite is 3,000 lines smaller
>
> no no no... when you change code you're supposed to add more code.
> Aren't you paying attention to the way software development apparently
> works? :)

I wish more software was written that way.  I always try to compress
and minimize my projects, of course it takes me forever to do
anything, so it's not really productive (or doesn't show off your
productivity to the managers) if software is your business (which I
guess is why it's not mine, full time, anymore :).

--
burton samograd                                                kruhft@gmail.com
kruhft.blogspot.com   www.myspace.com/kruhft   metashell.blogspot.com

Re: [9fans] new compilers

[David Leimbach]

On 3/25/06, Burton Samograd <kruhft@gmail.com> wrote:
> > >   - compiler suite is 3,000 lines smaller
> >
> > no no no... when you change code you're supposed to add more code.
> > Aren't you paying attention to the way software development apparently
> > works? :)
>
> I wish more software was written that way.  I always try to compress
> and minimize my projects, of course it takes me forever to do
> anything, so it's not really productive (or doesn't show off your
> productivity to the managers) if software is your business (which I
> guess is why it's not mine, full time, anymore :).
>
Yeah, this is where the right way to do things and then the way to
write commercial software seem to diverge, at least according to what
matters to the people who sign paychecks.

The rumors about Vista being 60% rewritten are interesting.  I hope
Microsoft really gets it together, not that I'm a huge fan of their
stuff in the past (Though I must say Windows 2000 and even XP Pro were
surprisingly stable and better compared to Windows 98/ME :))

Re: [9fans] new compilers

[Charles Forsyth]

> no no no... when you change code you're supposed to add more code.
> Aren't you paying attention to the way software development apparently
> works? :)

in some ways, the code reduction result is closer to the general approach
encouraged by earlier pioneers in the field.  it's one reason there was once
a little dismay of the choice of `lines of code produced' as a productivity metric.
these days, it sells code generators.  not the sort that russ changed that does some real work,
but the sort that generates thousands of lines of asn.1 parser that people then tweak by hand.
but i digress...

ken's compilers used a `copy and change' method rather than an elaborate portability
layer (or many many layers, or many many #ifdefs, which is gcc's technique).
in this case, however, after 15 or more architectures failed to change a copied section appreciably,
russ declared it portable after nearly 20 years, and moved it to ../cc

with any luck, it might start a trend.
two trends: the copy+change technique makes it easier to read the code,
and also the bit you pointed out, namely revision of code leads to less of it that does as much.
and there would be much rejoicing.

sadly, there currently seems to be fat chance of thin code.

Re: [9fans] new compilers

[Brantley Coile]

> the copy+change technique makes it easier to read the code,

N. Wirth used this with his Oberon compilers.

Re: [9fans] new compilers

[quanstro]

On Sat Mar 25 14:06:26 CST 2006, forsyth@terzarima.net wrote:
> > no no no... when you change code you're supposed to add more code.
> > Aren't you paying attention to the way software development apparently
> > works? :)
>
> in some ways, the code reduction result is closer to the general approach
> encouraged by earlier pioneers in the field.  it's one reason there was once
> a little dismay of the choice of `lines of code produced' as a productivity metric.
> these days, it sells code generators.  not the sort that russ changed that does some real work,
> but the sort that generates thousands of lines of asn.1 parser that people then tweak by hand.
> but i digress...
>
> ken's compilers used a `copy and change' method rather than an elaborate portability
> layer (or many many layers, or many many #ifdefs, which is gcc's technique).
> in this case, however, after 15 or more architectures failed to change a copied section appreciably,
> russ declared it portable after nearly 20 years, and moved it to ../cc

the ifdefs mostly solve a different problem -- getting gcc to compile with different
compilers, with different operating systems and different c libraries. that is not
a problem that kenc addresses.

gcc's "portability" from one arch to another is based on machine definitions, rtl
(that goofy, lispy intermediate language gcc uses) and "backends".

i'm fuzzy on how these interact, but i think the rtl+machine definition does
the intermediate work, while a chip-family-specific backend does the actual code
generation.

so, since this is a stack-based email, the thesis comes last. i think the relationship between the
code in ?c is similar to that in gcc. the major difference is that ?c is targets ? whereas
it's not immediately clear what "gcc" targets. thus libtool uses i686-pc-linux-gnu-gcc.
also ?c doesn't bother with an intermediate representation like rtl.

- erik

Re: [9fans] new compilers

[Brantley Coile]

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

{I remember Boyd.}

#ifdef's are only for commenting out code.

Kenc is finished compiling while gcc is still paging in.

The syntax tree in kenc is the intermediate representation.

The man page for GCC is 1.5 times larger than the 8c source.

RTL is just a way to make C into lisp.


{I miss him.}

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

From: quanstro@quanstro.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] new compilers
Date: Sat, 25 Mar 2006 15:28:35 -0600
Message-ID: <ea82c1826ccb5b5d81e337c45ee8a61f@quanstro.net>

On Sat Mar 25 14:06:26 CST 2006, forsyth@terzarima.net wrote:
> > no no no... when you change code you're supposed to add more code.
> > Aren't you paying attention to the way software development apparently
> > works? :)
>
> in some ways, the code reduction result is closer to the general approach
> encouraged by earlier pioneers in the field.  it's one reason there was once
> a little dismay of the choice of `lines of code produced' as a productivity metric.
> these days, it sells code generators.  not the sort that russ changed that does some real work,
> but the sort that generates thousands of lines of asn.1 parser that people then tweak by hand.
> but i digress...
>
> ken's compilers used a `copy and change' method rather than an elaborate portability
> layer (or many many layers, or many many #ifdefs, which is gcc's technique).
> in this case, however, after 15 or more architectures failed to change a copied section appreciably,
> russ declared it portable after nearly 20 years, and moved it to ../cc

the ifdefs mostly solve a different problem -- getting gcc to compile with different
compilers, with different operating systems and different c libraries. that is not
a problem that kenc addresses.

gcc's "portability" from one arch to another is based on machine definitions, rtl
(that goofy, lispy intermediate language gcc uses) and "backends".

i'm fuzzy on how these interact, but i think the rtl+machine definition does
the intermediate work, while a chip-family-specific backend does the actual code
generation.

so, since this is a stack-based email, the thesis comes last. i think the relationship between the
code in ?c is similar to that in gcc. the major difference is that ?c is targets ? whereas
it's not immediately clear what "gcc" targets. thus libtool uses i686-pc-linux-gnu-gcc.
also ?c doesn't bother with an intermediate representation like rtl.

- erik

Re: [9fans] new compilers

[quanstro]

the man pages is just a small percentage of the gcc documentation;
try info gcc.

- erik

On Sat Mar 25 15:37:21 CST 2006, brantley@coraid.com wrote:

> {I remember Boyd.}
>
> #ifdef's are only for commenting out code.
>
> Kenc is finished compiling while gcc is still paging in.
>
> The syntax tree in kenc is the intermediate representation.
>
> The man page for GCC is 1.5 times larger than the 8c source.
>
> RTL is just a way to make C into lisp.
>
>
> {I miss him.}
>

Re: [9fans] new compilers

[quanstro]

eighty-megs and constantly swapping. and that's just the editor.

if you look at the apple link i couldn't resist cluttering the list with,
you'll love some of the ways they work around the fact that gcc is slooow.
precompiled headers, speculative compiling (you saved a c file, we'll
compile it now, just in case you might need it), distcc, etc.

that's not to mention the bizzare workarounds to their slow linker.

- erik

On Sat Mar 25 15:37:21 CST 2006, brantley@coraid.com wrote:

> {I remember Boyd.}
>
> #ifdef's are only for commenting out code.
>
> Kenc is finished compiling while gcc is still paging in.
>
> The syntax tree in kenc is the intermediate representation.
>
> The man page for GCC is 1.5 times larger than the 8c source.
>
> RTL is just a way to make C into lisp.
>
>
> {I miss him.}
>

Re: [9fans] new compilers

[jmk]

On Sat Mar 25 16:57:42 EST 2006, quanstro@quanstro.net wrote:
> eighty-megs and constantly swapping. and that's just the editor.
>
> if you look at the apple link i couldn't resist cluttering the list with,
> you'll love some of the ways they work around the fact that gcc is slooow.
> precompiled headers, speculative compiling (you saved a c file, we'll
> compile it now, just in case you might need it), distcc, etc.
>
> that's not to mention the bizzare workarounds to their slow linker.
>
> - erik

I find the notion of pre-compiled headers for anything other than
a very special situation rather odd. Although the example given in
the link is trivial it demonstrates an unthinking inefficiency we
see all too often in practice:

	there's a file foo.c which has an accompanying file foo.h which
	is only ever included in foo.c

This is a poor idea in many ways and is perhaps one of the reasons
we see all these other things being necessary to make the user believe
that things are happening faster.

Recently I was poking around in a multi-file open source driver and
came across more than one instance of the following which pulled me
up short (names changed to protect the guilty):

	foo.h contains the following:

		#define THING {					\
		{ 1234, XXX_YY0, ZZZ0 },		\
		{ 5678, XXX_YY1, ZZZ1 },		\
		... 200 more of these ...
		}

	and is only included in foo.c which contains one instance of
	its use:

		static const struct
		thing thing_table[] = THING;

It would never occur to me to #define a table like that. Age, I
suppose.

--jim

Re: [9fans] new compilers

[quanstro]

i don't think anybody else undestands this method of coding either.

precompiling headers as a performance hack is akin to this kind of thinking:

	patient:	doctor, doctor it hurts when i do this.
	doctor:   i think you need a special brace. there's a specialist for these
		kind of problems. let me write you an order...

instead of

	patient:	doctor, doctor it hurts when i do this.
	doctor:   don't do that then.

to amuse yourself. try this.

	; gcc -E somefile.c
	; wc -l somefile.i

this is especially fun on a glibc machine. but code like this is not the reason gcc is so slow.
try tcc, lcc, or icc on the same source code.

- erik

p.s. i've got to say one thing in gcc's favor. it was way the heck better than
any other compiler i had available when it was first written. it actually did
prototypes and warned if things didn't match. i guess it's been all downhill
since gcc-1.38

On Sat Mar 25 19:47:10 CST 2006, jmk@plan9.bell-labs.com wrote:

> I find the notion of pre-compiled headers for anything other than
> a very special situation rather odd. Although the example given in
> the link is trivial it demonstrates an unthinking inefficiency we
> see all too often in practice:
>
> 	there's a file foo.c which has an accompanying file foo.h which
> 	is only ever included in foo.c
>
> This is a poor idea in many ways and is perhaps one of the reasons
> we see all these other things being necessary to make the user believe
> that things are happening faster.
>
> Recently I was poking around in a multi-file open source driver and
> came across more than one instance of the following which pulled me
> up short (names changed to protect the guilty):
>
> 	foo.h contains the following:
>
> 		#define THING {					\
> 		{ 1234, XXX_YY0, ZZZ0 },		\
> 		{ 5678, XXX_YY1, ZZZ1 },		\
> 		... 200 more of these ...
> 		}
>
> 	and is only included in foo.c which contains one instance of
> 	its use:
>
> 		static const struct
> 		thing thing_table[] = THING;
>
> It would never occur to me to #define a table like that. Age, I
> suppose.
>
> --jim

Re: [9fans] new compilers

[Lyndon Nerenberg]

On Mar 25, 2006, at 6:52 PM, quanstro@quanstro.net wrote:

> i've got to say one thing in gcc's favor. it was way the heck
> better than
> any other compiler i had available when it was first written.

I have fond memories of threatining the Sun sales sloths with death
and worse if they didn't at least ship .h files after they unbundled
the C compiler.  Sun is as responsible for GCC as the AT&T lawyers
are responsible for Linux.

--lyndon

Re: [9fans] new compilers

[Lyndon Nerenberg]

> I have fond memories of threatining the Sun sales sloths with death
> and worse if they didn't at least ship .h files after they
> unbundled the C compiler.  Sun is as responsible for GCC as the
> AT&T lawyers are responsible for Linux.

Ignoring the lawyers, gcc out-ran all of the Sun compilers for
years.  It wasn't until ~2001 when I saw demonstrable proof that the
Sun compilers were ready to outrun the GNU bloatationiousness.  But
meanwhile, Sun's hubris lead to others not only unbundling, but
actually spending that money on compiler design!  I still love the
mipsco compilers that quote chapter and verse of the ANSI spec.  And
they worked even before DEC got MIPSed.  Oh wait, that was the
*other* DEC CPU.  (6,7,8,10,VAX,MIPS,???)  Still, the compiler worked
across all of them.

Re: [9fans] new compilers

[Bruce Ellis]

i mate, who has this habit shared by me, in that he writes
programs that write programs.  for a 4000 line program
(generated) gcc uses more than 1G of ram and takes all
night to compile it.  kenc zaps it.

brucee

On 3/26/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> > I have fond memories of threatining the Sun sales sloths with death
> > and worse if they didn't at least ship .h files after they
> > unbundled the C compiler.  Sun is as responsible for GCC as the
> > AT&T lawyers are responsible for Linux.
>
> Ignoring the lawyers, gcc out-ran all of the Sun compilers for
> years.  It wasn't until ~2001 when I saw demonstrable proof that the
> Sun compilers were ready to outrun the GNU bloatationiousness.  But
> meanwhile, Sun's hubris lead to others not only unbundling, but
> actually spending that money on compiler design!  I still love the
> mipsco compilers that quote chapter and verse of the ANSI spec.  And
> they worked even before DEC got MIPSed.  Oh wait, that was the
> *other* DEC CPU.  (6,7,8,10,VAX,MIPS,???)  Still, the compiler worked
> across all of them.
>

Re: [9fans] new compilers

[David Leimbach]

On 3/25/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> On Sat Mar 25 16:57:42 EST 2006, quanstro@quanstro.net wrote:
> > eighty-megs and constantly swapping. and that's just the editor.
> >
> > if you look at the apple link i couldn't resist cluttering the list with,
> > you'll love some of the ways they work around the fact that gcc is slooow.
> > precompiled headers, speculative compiling (you saved a c file, we'll
> > compile it now, just in case you might need it), distcc, etc.
> >
> > that's not to mention the bizzare workarounds to their slow linker.
> >
> > - erik
>
> I find the notion of pre-compiled headers for anything other than
> a very special situation rather odd. Although the example given in
> the link is trivial it demonstrates an unthinking inefficiency we
> see all too often in practice:
>
>         there's a file foo.c which has an accompanying file foo.h which
>         is only ever included in foo.c
>
> This is a poor idea in many ways and is perhaps one of the reasons
> we see all these other things being necessary to make the user believe
> that things are happening faster.
>
> Recently I was poking around in a multi-file open source driver and
> came across more than one instance of the following which pulled me
> up short (names changed to protect the guilty):
>
>         foo.h contains the following:
>
>                 #define THING {                                 \
>                 { 1234, XXX_YY0, ZZZ0 },                \
>                 { 5678, XXX_YY1, ZZZ1 },                \
>                 ... 200 more of these ...
>                 }
>
>         and is only included in foo.c which contains one instance of
>         its use:
>
>                 static const struct
>                 thing thing_table[] = THING;
>
> It would never occur to me to #define a table like that. Age, I
> suppose.
>
> --jim
>
I can think of only one reason to do this.  If it's a linux kernel
driver, sometimes you get distributions that have options for "kernel
headers" and "kernel source".  Obviously kernel source includes the
headers, but in a lot of cases the headers are all you need.  In this
case, perhaps they wanted to expose the definition of a table in the
header for people to see.

Still, I agree it's very odd to do such a thing.

Re: [9fans] new compilers

[rog]

> I find the notion of pre-compiled headers for anything other than
> a very special situation rather odd.

it is odd.  i've just been playing with trying to get some stuff
working under macos x, and the interfaces are just amazing.  the
standard approach seems to be to enumerate every possible situation
(often literally, with enums) in the interface.  a few days ago i did
a little test, just to appreciate the full extent of things.  cpp of a
null source file (with only the #includes i needed) gave over 100,000
lines of code.  there were at least 20,000 enum constants defined,
with names such as kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
and kAudioFormatProperty_AvailableEncodeChannelLayoutTags.

and the interfaces that are presented are almost unusable even if you
take that on board.  i've been looking at the audio interfaces;
functionality provided by the system includes facilities to read mp3
files, do sample-rate conversion, and produce sound output, so i
thought, as a first test, i'd try to play an mp3 file.  i haven't
succeeded yet.

after struggling for a good while, i found some example code that does
this.  it's over 1000 lines of code.  when it should be about 10.  i'd
think perhaps it was deliberate, if it didn't all seem so carefully
done, with loving attention given to every misbegotten line of header
file.

as charles put it recently, with relation to usb: ``enough is
specified to make it complicated, but not enough to be complete, once
for all.'' so true.

given that kind of programming environment, the decision to use
precompiled headers becomes slightly more understandable, i suppose.

i guess the only good thing is that by using interfaces like that, they'll
be wasting countless man-hours of programmer time, potentially
allowing those using smaller, smarter interfaces a competitive advantage.
yeah right.

Re: [9fans] new compilers

[Charles Forsyth]

> with names such as kAudioHardwarePropertyBootChimeVolumeRangeDecibels,

which says it all

Re: [9fans] new compilers

[Paul Lalonde]

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

>> with names such as
>> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,

Do you prefer kAHPBCVRD?

Frankly, these "modern" interfaces are just plain evil.

I'm working on an invited talk right now on game engine design as
real-time OS design (less most of the device drivers, thank god), and
how recent architectures make this challenging.  But at least there
is still advantage to a small system.

I'm really looking forward to ripping into naive OO as these poor
misguided students have been taught.  C-double-cross must die.

Paul

On 27-Mar-06, at 11:01 AM, Charles Forsyth wrote:

>
> which says it all
>

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

iD8DBQFEKDnppJeHo/Fbu1wRAuZFAJ4/Jvtt7m4CVN9oY2bi7h28WzH4rgCdGSme
cuE50e29pXR77tvv7JhKvZo=
=MjVI
-----END PGP SIGNATURE-----

Re: [9fans] new compilers

[Bruce Ellis]

only would be said on 9fans :-)

brucee

> I'm really looking forward to ripping into naive OO as these poor
> misguided students have been taught.  C-double-cross must die.
>
> Paul

Re: [9fans] new compilers

[rog]

> >> with names such as
> >> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
>
> Do you prefer kAHPBCVRD?

i'd prefer:

	fprint(ctlfd, "volume %d", vol);

Re: [9fans] new compilers

[Charles Forsyth]

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

clearly you'll be depressed if you ever come to look at OpenUSBDI.
admittedly, their names aren't quite as elaborate, but it's a big interface
to do nothing very much, partly because every action requires several types
and three or four different callback functions, excluding the proxy functions (for when you don't want a callback).
because you can't just call a function and have it return the value you wanted, you know. no, no no.
you need to ask someone who promises to progress the action on your request and get back to you.

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

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] new compilers
Date: Thu, 30 Mar 2006 18:41:28 +0100
Message-ID: <4937e6f0e033b77a2679b5853e19b96d@vitanuova.com>

> >> with names such as
> >> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
>
> Do you prefer kAHPBCVRD?

i'd prefer:

	fprint(ctlfd, "volume %d", vol);

Re: [9fans] new compilers

[Skip Tavakkolian]

> you can't just call a function and have it return the value you wanted, you know. no, no no.
> you need to ask someone who promises to progress the action on your request and get back to you.

the async call/callback stuff is very annoying.  many multithreaded
systems in c++ have to resort to it for anything that blocks.  a good
thread library - that doesn't require one to change religion to use it
- and the concept of channels would sure make a lot of that stuff go
away.

Re: [9fans] new compilers

[Christoph Lohmann]

Good evening.

Am Thu, 30 Mar 2006 18:41:28 +0100 schrieb rog@vitanuova.com:

> > >> with names such as
> > >> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
> >
> > Do you prefer kAHPBCVRD?
>
> i'd prefer:
>
> 	fprint(ctlfd, "volume %d", vol);
>

ioctl(fd, SETVOLUME, &vol); is more comfortable.

Sincerely,

Christoph

Re: [9fans] new compilers

[Sape Mullender]

> ioctl(fd, SETVOLUME, &vol); is more comfortable.

ah, but how about
	echo volume 50 >/dev/audioctl
for understandability?

	Sape

Re: [9fans] new compilers

[Skip Tavakkolian]

>> ioctl(fd, SETVOLUME, &vol); is more comfortable.
>
> ah, but how about
> 	echo volume 50 >/dev/audioctl
> for understandability?

i would also add:

import -b noisemaker /dev
echo volume 50 >/dev/audioctl

please ioctl this!

Re: [9fans] new compilers

[Gabriel Diaz]

Hello

to contribute to this ugly thread, i would say the more comfortable
way is using the hi-fi remote from your favourite armchair.

:-)

gabi

On 3/30/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.
> >
> > ah, but how about
> >       echo volume 50 >/dev/audioctl
> > for understandability?
>
> i would also add:
>
> import -b noisemaker /dev
> echo volume 50 >/dev/audioctl
>
> please ioctl this!
>
>

Re: [9fans] new compilers

[Skip Tavakkolian]

that was happening inside the remote control which
runs inferno.  didn't you see that?

> to contribute to this ugly thread, i would say the more comfortable
> way is using the hi-fi remote from your favourite armchair.
>
> :-)
>
> gabi
>
> On 3/30/06, Skip Tavakkolian <9nut@9netics.com> wrote:
>> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.
>> >
>> > ah, but how about
>> >       echo volume 50 >/dev/audioctl
>> > for understandability?
>>
>> i would also add:
>>
>> import -b noisemaker /dev
>> echo volume 50 >/dev/audioctl
>>

Re: [9fans] new compilers

[Gabriel Diaz]

ok ok , i shouldn't have said it :-D

gabi

On 3/30/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> that was happening inside the remote control which
> runs inferno.  didn't you see that?
>
> > to contribute to this ugly thread, i would say the more comfortable
> > way is using the hi-fi remote from your favourite armchair.
> >
> > :-)
> >
> > gabi
> >
> > On 3/30/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> >> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.
> >> >
> >> > ah, but how about
> >> >       echo volume 50 >/dev/audioctl
> >> > for understandability?
> >>
> >> i would also add:
> >>
> >> import -b noisemaker /dev
> >> echo volume 50 >/dev/audioctl
> >>
>
>

Re: [9fans] new compilers

[Charles Forsyth]

> to contribute to this ugly thread, i would say the more comfortable
> way is using the hi-fi remote from your favourite armchair.

yes, but what does that do underneath in the digital world?
sadly, it probably resembles the uglier parts of this thread, and is
an order of magnitude (or two) more complex than need be (cf. OSGi).
then the xml gets added to the mix.  best just to switch it all off and hide.

Re: [9fans] new compilers

[Bakul Shah]

> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.

I bet 20h was being facetious and is hugely enjoying this
"discussion".

> > ah, but how about
> > 	echo volume 50 >/dev/audioctl
> > for understandability?
>
> i would also add:
>
> import -b noisemaker /dev
> echo volume 50 >/dev/audioctl
>
> please ioctl this!

Easy!

	kldload	noisemaker.ko
	noisemakercontrol volume 50

Much more comfortable!  And the ioctl is happening inside
the noisemakercontrol program:-)

Someone needs to point out to non-plan9 people that the plan9
way is really dynamic linking + object oriented programming
on steroids.  But with a different calling convention and
different limitations.  Of course, since it uses utf8 strings
as arguments, some people will want to internationalize them
(how dare you force us to use an english word?  We in
foobarland don't say "volume").

Re: [9fans] new compilers

[Skip Tavakkolian]

>> import -b noisemaker /dev
>> echo volume 50 >/dev/audioctl
>>
>> please ioctl this!
>
> Easy!
>
> 	kldload	noisemaker.ko
> 	noisemakercontrol volume 50

where's the import?

Re: [9fans] new compilers

[Skip Tavakkolian]

> Someone needs to point out to non-plan9 people that the plan9
> way is really dynamic linking + object oriented programming
> on steroids.  But with a different calling convention and
> different limitations.  Of course, since it uses utf8 strings
> as arguments, some people will want to internationalize them
> (how dare you force us to use an english word?  We in
> foobarland don't say "volume").

i think somebody (anyone remember who?) said something like:
"Plan 9 is object oriented; its objects are files".

translation between languages could be done using pipefile
and a filter (i think).

Re: [9fans] new compilers

[uriel]

> i think somebody (anyone remember who?) said something like:
> "Plan 9 is object oriented; its objects are files".

We have persistant objects, they're called files.  -- ken

Re: [9fans] new compilers

[Bruce Ellis]

works well ... my blast room has no wires to the other rooms.
simple p9 box in the corner.  wireless audio.  and i found the
p9 box on the street. of course i can play a different song from
the studio as well, wireless (well actually it has a telco wire
for when i have to work in mutiple rooms)...

my wireless laptop can control it all.

just a few echoes (good song).

brucee

On 3/31/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.
> >
> > ah, but how about
> >       echo volume 50 >/dev/audioctl
> > for understandability?
>
> i would also add:
>
> import -b noisemaker /dev
> echo volume 50 >/dev/audioctl
>
> please ioctl this!
>
>

Re: [9fans] new compilers

[Skip Tavakkolian]

regarding structure of the information that is exchanged, which i
think Roman asked about.  one can conventionally require all fs to
provide a control file that when read, returns a dictionary of what
the fs can grok.  then the messages would follow the dictionary
format.

a while ago we had an internal discussion and brucee pointed out
that UBF's concepts would be a better choice than xml/xml-schema
business.

http://www.sics.se/~joe/talks/pittsburgh_2002_ubf.pdf

> works well ... my blast room has no wires to the other rooms.
> simple p9 box in the corner.  wireless audio.  and i found the
> p9 box on the street. of course i can play a different song from
> the studio as well, wireless (well actually it has a telco wire
> for when i have to work in mutiple rooms)...
>
> my wireless laptop can control it all.
>
> just a few echoes (good song).
>
> brucee
>
> On 3/31/06, Skip Tavakkolian <9nut@9netics.com> wrote:
>> >> ioctl(fd, SETVOLUME, &vol); is more comfortable.
>> >
>> > ah, but how about
>> >       echo volume 50 >/dev/audioctl
>> > for understandability?
>>
>> i would also add:
>>
>> import -b noisemaker /dev
>> echo volume 50 >/dev/audioctl
>>
>> please ioctl this!

Re: [9fans] new compilers

[Adrian Tritschler]

Sape Mullender wrote:
>>ioctl(fd, SETVOLUME, &vol); is more comfortable.
> 
> 
> ah, but how about
> 	echo volume 50 >/dev/audioctl
> for understandability?

Surely the maximum should be

	echo volume 11 > /dev/audioctl

> 	Sape
	Adrian

---------------------------------------------------------------
Adrian Tritschler                          mailto:ajft@ajft.org
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] new compilers

[rog]

> ioctl(fd, SETVOLUME, &vol); is more comfortable.

no typechecking. no distribution. who defines all those constants?

i could have said:
	echo volume 56 > /dev/bootchime/ctl
how comfortable is your ioctl then?

Re: [9fans] new compilers

[rog]

i said:
> no typechecking.

and this is the part that really bugs me.  endless use of void*; if
you get it wrong, who knows what'll happen.  the compiler certainly
can't help.

under the interfaces i was looking at in macos x, most things
are accessed through a trio of calls along the lines of:

find out the size of data stored for a property:
OSStatus AudioHardwareGetPropertyInfo(AudioHardwarePropertyID inPropertyID, UInt32 *outSize, Boolean *outWritable);

get the data for a property:
OSStatus AudioHardwareGetProperty(AudioHardwarePropertyID inPropertyID, UInt32 *ioPropertyDataSize, void *outPropertyData);

set the data for a property:
OSStatus AudioHardwareSetProperty(AudioHardwarePropertyID inPropertyID, UInt32 inPropertyDataSize, void *inPropertyData);

where a tag might be, for example, kAudioUnitProperty_SetRenderCallback.

IMHO this is the logical extension of the ioctl-is-comfortable school of
programming.

there are thousands of property tags, each with their own argument
type (often undocumented) and implied semantics (often under-documented).

it's incredibly clunky and error-prone to program, and i'd imagine
it's a nightmare to maintain. a piece of code that, if the interface
was right, could be just one element of an expression, takes
about 7 lines of brittle code

sorry about the off-topic rant, but perhaps it's useful to compare
the two approaches.

Re: [9fans] new compilers

[Roman Shaposhnick]

On Thu, Mar 30, 2006 at 07:27:32PM +0100, rog@vitanuova.com wrote:
> i said:
> > no typechecking.
>
> and this is the part that really bugs me.  endless use of void*; if
> you get it wrong, who knows what'll happen.  the compiler certainly
> can't help.

  Has anybody ever thought about extending the usual file-based interfaces
  with a typechecking ? I'm not even asking about implementations, more
  about ideas: you've got /foo/bar/file and you want it to be clearly
  identified as a receptacle for a certain type of data -- how would
  you do that (especially with an additional constraint that nobody
  reads man pages) ?

Thanks,
Roman.

Re: [9fans] new compilers

[Steve Simon]

>   Has anybody ever thought about extending the usual file-based interfaces
>  with a typechecking ?

It did occur to me one could have:

	echo 10 oranges > /dev/apple-count
	echo: write failed: inapropriate fruit

More seriously one of our researchers once asked me why computer
langages don't allow people to associate variables and constants
with SI units, allowing True type checking; I never managed to
come up with a good answer.

-Steve

Re: [9fans] new compilers

[Russ Cox]

> It did occur to me one could have:
>
> 	echo 10 oranges > /dev/apple-count
> 	echo: write failed: inapropriate fruit

This gets a lot harder when the data is just
space-separated decimal numbers.  For example,
bind /net/tcp /proc; ps.

Russ

Re: [9fans] new compilers

[Joel Salomon]

On 3/30/06, Steve Simon <steve@quintile.net> wrote:
> More seriously one of our researchers once asked me why computer
> langages don't allow people to associate variables and constants
> with SI units, allowing True type checking; I never managed to
> come up with a good answer.

http://www.boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html

--Joel

Re: [9fans] new compilers

[Martin C. Atkins]

Ian Currie's Newspeak language, for safety-critical programming
did that. Well, to be more precise, it added dimensional analysis
to the type analysis.

Neat.

Don't know anything else that has put it in the language. Anyone?

Martin

On Fri, 31 Mar 2006 02:15:57 +0100 "Steve Simon" <steve@quintile.net> wrote:
> More seriously one of our researchers once asked me why computer
> langages don't allow people to associate variables and constants
> with SI units, allowing True type checking; I never managed to
> come up with a good answer.
>
> -Steve


--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] new compilers

[Charles Forsyth]

> Don't know anything else that has put it in the language. Anyone?

i'd forgotten about it being in newspeak, but given that it was currie
it might well have worked.  poor old RSRE.  otherwise, attempts to
build it into languages turned up periodically during the 70s, but i
think it ended up being more trouble than it was worth, in the `least
of your worries' sense of that's not what usually causes the failures.
(in my case, it's usually ignorance or stupidity.) just to prove me
wrong, it's probably somewhere in perl.

Re: [9fans] new compilers

[Bruce Ellis]

#pragma perl

oh the horror ...

brucee

On 3/31/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > Don't know anything else that has put it in the language. Anyone?
>
> i'd forgotten about it being in newspeak, but given that it was currie
> it might well have worked.  poor old RSRE.  otherwise, attempts to
> build it into languages turned up periodically during the 70s, but i
> think it ended up being more trouble than it was worth, in the `least
> of your worries' sense of that's not what usually causes the failures.
> (in my case, it's usually ignorance or stupidity.) just to prove me
> wrong, it's probably somewhere in perl.
>
>

Re: [9fans] new compilers

[Taj Khattra]

> Don't know anything else that has put it in the language. Anyone?

guy steele and gang at sun research are exploring the addition of
dimension checking to oo type systems:
http://research.sun.com/projects/plrg/

Re: [9fans] new compilers

[Jack Johnson]

On 3/30/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Thu, Mar 30, 2006 at 07:27:32PM +0100, rog@vitanuova.com wrote:
>   (especially with an additional constraint that nobody
>   reads man pages) ?

Aren't man pages are what you read in between experimentation and
asking for help on IRC?

;)

-Jack

Re: [9fans] new compilers

[veritosproject]

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

Depends on how lazy you are.  Lazy people read the man page first,
hackerly types experiment, and lazy hackers spend their time on IRC
anyway so it's not much more effort to go on and ask.

;)

Jack Johnson wrote:

>On 3/30/06, Roman Shaposhnick <rvs@sun.com> wrote:
>
>
>>On Thu, Mar 30, 2006 at 07:27:32PM +0100, rog@vitanuova.com wrote:
>>  (especially with an additional constraint that nobody
>>  reads man pages) ?
>>
>>
>
>Aren't man pages are what you read in between experimentation and
>asking for help on IRC?
>
>;)
>
>-Jack
>
>
>

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

Re: [9fans] new compilers

[Charles Forsyth]

> ioctl(fd, SETVOLUME, &vol); is more comfortable.

of course.  then we can fuss trying to have the same value for SETVOLUME on each system
in a distributed set and re-learn all that The Newcastle Connection and RFS painfully discovered
about that (but Linux has yet to learn); the interface requires passing a reference to vol (just to pass its value,
so it can't be an expression, and also losing its type in the process because ioctl takes void*);
and every language needs to set up its own `binding' for all those operations and values; and ...

Re: [9fans] new compilers

[jmk]

Oh really? What if fd is a channel to a device on
a machine with a different byte order or a different
int size? Who does the conversion, how do they know?

It might be comfortable, but so is lounging in a big
enough pile of shite. Smelly, though.

On Thu Mar 30 12:52:02 EST 2006, 20h@r-36.net wrote:
> Good evening.
>
> Am Thu, 30 Mar 2006 18:41:28 +0100 schrieb rog@vitanuova.com:
>
> > > >> with names such as
> > > >> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
> > >
> > > Do you prefer kAHPBCVRD?
> >
> > i'd prefer:
> >
> > 	fprint(ctlfd, "volume %d", vol);
> >
>
> ioctl(fd, SETVOLUME, &vol); is more comfortable.
>
> Sincerely,
>
> Christoph

Re: [9fans] new compilers

[Brantley Coile]

And if you want to do streams(DMR) you have to decide how large
the thing you're going to send down the wire can be.  My versions
of streams only let you send 64 bytes objects.  The advancement in  evolution
is:

	sgetty/getty -> ioctl -> /dev/eiactl.

> Oh really? What if fd is a channel to a device on
> a machine with a different byte order or a different
> int size? Who does the conversion, how do they know?
>
> It might be comfortable, but so is lounging in a big
> enough pile of shite. Smelly, though.
>
> On Thu Mar 30 12:52:02 EST 2006, 20h@r-36.net wrote:
>> Good evening.
>>
>> Am Thu, 30 Mar 2006 18:41:28 +0100 schrieb rog@vitanuova.com:
>>
>> > > >> with names such as
>> > > >> kAudioHardwarePropertyBootChimeVolumeRangeDecibels,
>> > >
>> > > Do you prefer kAHPBCVRD?
>> >
>> > i'd prefer:
>> >
>> > 	fprint(ctlfd, "volume %d", vol);
>> >
>>
>> ioctl(fd, SETVOLUME, &vol); is more comfortable.
>>
>> Sincerely,
>>
>> Christoph

Re: [9fans] new compilers

[Burton Samograd]

> ioctl(fd, SETVOLUME, &vol); is more comfortable.

I read somewhere (but haven't actually seen it implimented yet) about
using xattrs (file system property lists) instead of ioctls and
thought that it was a pretty interesting idea.  No needing to sort
through headers to find some badly acronimized value with no docs on
how to use it, etc...

Anybody have any comments on the xattr -> ioctl type interfaces?

--
burton samograd                                                kruhft@gmail.com
kruhft.blogspot.com   www.myspace.com/kruhft   metashell.blogspot.com

Re: [9fans] new compilers

[David Leimbach]

On 3/30/06, Burton Samograd <kruhft@gmail.com> wrote:
> > ioctl(fd, SETVOLUME, &vol); is more comfortable.
>
> I read somewhere (but haven't actually seen it implimented yet) about
> using xattrs (file system property lists) instead of ioctls and
> thought that it was a pretty interesting idea.  No needing to sort
> through headers to find some badly acronimized value with no docs on
> how to use it, etc...
>
> Anybody have any comments on the xattr -> ioctl type interfaces?

Doesn't seem so bad.  It opens up new questions about things like if
all xattr APIs and implementations are created equal, and they're not.

FreeBSD has one way.

Mac OS X adopted the Linux API (believe it or not).

Mac OS X's version differs in behavior from Linux's in some fundamental ways.

I found this out working with some friends on an archiver that gathers
things like Resource Fork data between mac os x revisions, at some
point you can access the data via xattrs if you wish, which changes
the amount of data that is normally storable in an xattr interface.

The other thing I didn't like about xattrs on linux is you have to
write weird looping mechanisms to make sure you have a buffer that's
big enough to hold the xattr data when reading.

example:

----
TRYAGAIN:
buf = malloc(bufsz);

if (!buf) abort();  //pretty much screwed here.

ret = listxattr(path, buf, bufsz, xattr_flags);
if (ret < 0) {
   switch (errno) {
   case ERANGE: // bufsz is too small.
       bufsz *= 2;
       free(buf);
       goto TRYAGAIN;
----

And this is just to get a list of the key'd extended attributes
existing on the file.  Not a nice interface if you ask me.  You
basically fail upwards without being told how far off you were from
having the correct buffer size.

FreeBSD has namespaced xattrs for the SYSTEM and USERSPACE.

I'll take control files any day of the week over this mess.

Dave

>
> --
> burton samograd                                                kruhft@gmail.com
> kruhft.blogspot.com   www.myspace.com/kruhft   metashell.blogspot.com
>

Re: [9fans] new compilers

[Charles Forsyth]

> I'll take control files any day of the week over this mess.

one advantage they still have (even if the other weren't quite so messy)
is that with control files you've got a connection you can keep open,
which can be useful, and the control file itself can have different
attributes (eg permissions) from the controlled file(s) or directories.

Re: [9fans] new compilers

[Rob Pike]

Also, ioctl masks the direction of data motion, while read and
write make it was explicit as can be.

-rob

Re: [9fans] new compilers

[David Leimbach]

On 3/30/06, Rob Pike <robpike@gmail.com> wrote:
> Also, ioctl masks the direction of data motion, while read and
> write make it was explicit as can be.
>
> -rob
>

It really does seem that ioctl is just a "kitchen sink" for operations
on resources in a filesystem that people didn't think could be
addressed as files at the time.

The xattr stuff seems neat on the surface because you effectively get
a hierarchical namespace directly attached to your device file.  Of
course, there's really nothing stopping us from doing that with
directories the Plan 9 way I suppose.

In fact, I often wondered why the eia* stuff kind of differed in
structure from the sd* stuff.

Any good reason not to do
eia0/ctl
eia0/data
eia0/status

Dave