Re: [9fans] Install from CD fails

Re: [9fans] Install from CD fails

[erik quanstrom]

On Wed Apr 19 20:05:43 CDT 2006, rog@vitanuova.com wrote:
> i had es in mind when i wrote the inferno shell (vita nuova's, not the original tiny shell).

the inferno shell is quite nice.  good job.

> i thought then that some of the es concepts were nice, but the whole complete functional language
> thing was overkill and didn't get one very far (why make it possible to redefine
> core shell concepts such as the pipe? - it just confuses everyone if you make use of this.)

for starters, it makes a nice paper.  ;-)   also it was used for the es debugger.  i never found it confusing
(due to lexical bindings) but never made use of it, either.

> for instance:
> > 	; if {condition1} {body1} {condition2} {body2}
>
> is not implemented by the core inferno shell, but by an externally loaded
> module (std).
>

pretty nice!

>
> the main problem is that a shell of this style
> has no concept of storage of any item but a string (ok, a list of strings), so it is not
> possible to manipulate other data items directly. [...]
>
> i don't think it's possible to address these problems without
> breaking the simplicity of the whole thing; the moment you
> introduce lexical binding, differently typed variables, etc,
> a whole raft of other issues starts to drift into view.
> another kind of language might begin to help, but that's another
> story.

i think you're right.  i wrote a shell in college that was similar to rc, but
lists were allowed to contain lists.  even this proved to be unworkable, as
"for(i in *.c *.h) echo $i" would print
	a.c b.c
	x.h y.h z.h
and not what was expected.

>
> just having shell blocks as values is a big win, in my book.
> i don't think it would be hard to do this in rc.

i don't think it would be hard, but it would break td's basic design of compiling
everything at input time.  one way to thinking of es' rewriting is that it is
like rc's bytecode exposed.  i don't think it really hangs together though.  is this
	a | b
or this
	%pipe {a} 0 1 {b}
es code?

also, what does a traditional rc function do with a shell block?

>
> > a trivial grep module could make
> >	; grep {^fn} *.[ch]
> > acceptable syntax.
>
> i'm sorry, i don't see why this is preferable to the original.
> it has the same number of characters.

it doesn't!  i didn't intend to imply that it did.  it was a trivial example.

- erik

Re: [9fans] Install from CD fails

[Charles Forsyth]

> also, what does a traditional rc function do with a shell block?

invoke it.  i did something in a variant of 7th edition shell that was roughly similar.
i remember!  i converted {block} as arguments into shell functions exported to the environment
(having added 8th edition style shell functions and exported shell functions to 7th edition shell).
the shell replaced the {} block by the function name before calling the command.
thus allowing
	find usual-find-syntax -exec {mv $file /n/distant/$file}
where the modified find put the current name in the environment $file, removing the need for {} and the \;
find saw ... -exec my-exported-fn-name, and execvp would invoke /bin/sh -c my-exported-fn-name.
	time {a | pipe | line}; nohup {another; sequence; of; commands}
this relied on the environment not being shared, of course
and having the source to 7th edition.

[9fans] [OT] URI

[Charles Forsyth]

it's a pity there isn't something similar to the loader modification
recently discussed, but for eliminating the chaff from RFCs
and other standards.  for instance, RFC3986 (URI generic syntax)
defines the syntax of `uniform resource identifiers' and they
are so `uniform' that it takes a mere 56 pages excluding index to do it.
and that's just the framework!  perhaps! well, you've got to laugh;
especially when you start reading:

	For most systems, an unreserved character appearing within a URI
	component is interpreted as representing the data octet corresponding
	to that character's encoding in US-ASCII.  Consumers of URIs assume
	that the letter "X" corresponds to the octet "01011000", and even
	when that assumption is incorrect, there is no harm in making it.   [p. 15]

Re: [9fans] [OT] URI

[geoff]

An interesting idea, especially if you could tell it what to cull as
absolutely uninteresting, e.g., no OSI, no ATM, no SONET, no MPLS, no
SNMP, no RSVP, no OSPF, no XML, no UTF-7.  You'd need to have some way
to evaluate questions like `is the anal-retention and micromanagement
in SMTP (821/2821) irrelevant and thus removable?'.  I suppose any
algorithm that could cope with the Book of Armaments should be good
enough.

Re: [9fans] [OT] URI

[Brantley Coile]

There should be a service that sells cliff notes for standards.  They read
the standard and write a new one that states what we need to know to
write a program using the standard in much fewer lines.  I'd pay for such
a service.

> An interesting idea, especially if you could tell it what to cull as
> absolutely uninteresting, e.g., no OSI, no ATM, no SONET, no MPLS, no
> SNMP, no RSVP, no OSPF, no XML, no UTF-7.  You'd need to have some way
> to evaluate questions like `is the anal-retention and micromanagement
> in SMTP (821/2821) irrelevant and thus removable?'.  I suppose any
> algorithm that could cope with the Book of Armaments should be good
> enough.

Re: [9fans] [OT] URI

[Paul Lalonde]

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

O'Reilly.

And the quality varies just as much as Cliff's notes.

Paul

On 20-Apr-06, at 8:01 AM, Brantley Coile wrote:

> There should be a service that sells cliff notes for standards.
> They read
> the standard and write a new one that states what we need to know to
> write a program using the standard in much fewer lines.  I'd pay
> for such
> a service.
>
>> An interesting idea, especially if you could tell it what to cull as
>> absolutely uninteresting, e.g., no OSI, no ATM, no SONET, no MPLS, no
>> SNMP, no RSVP, no OSPF, no XML, no UTF-7.  You'd need to have some
>> way
>> to evaluate questions like `is the anal-retention and micromanagement
>> in SMTP (821/2821) irrelevant and thus removable?'.  I suppose any
>> algorithm that could cope with the Book of Armaments should be good
>> enough.
>

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

iD8DBQFER6l7pJeHo/Fbu1wRAhdyAKDhJY/TMnsKnHO+lnD+vCVLX98eTACdFXs9
aVJvHzMpODLMoEt5mDV42P0=
=Klk7
-----END PGP SIGNATURE-----

Re: [9fans] [OT] URI

[Brantley Coile]

But O'Reilly books are bigger than the rfc's.  I want less to read.

As an aside, have you noticed that Prentice Hall is printing
K&R on thicker paper to make the book look larger?  Seems too
many people don't judge a book by it's cover, but by the pound.

> O'Reilly.
>
> And the quality varies just as much as Cliff's notes.
>
> Paul

Re: [9fans] [OT] URI

[Paul Lalonde]

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

Many of them are bigger.  Some of them are actually smaller.  In a
prior life I had to care about .NET, and the O'Reilly books were the
only way to navigate the runtime environment.  And their VI book is
still the best...

It's sad how few computer (as opposed to computing science) books are
happy addressing an expert audience; writing anything that assumes
programming skills and intelligence would probably reduce the
audience to much less than a printing :-(

Paul

On 20-Apr-06, at 8:49 AM, Brantley Coile wrote:

> But O'Reilly books are bigger than the rfc's.  I want less to read.
>
> As an aside, have you noticed that Prentice Hall is printing
> K&R on thicker paper to make the book look larger?  Seems too
> many people don't judge a book by it's cover, but by the pound.
>
>> O'Reilly.
>>
>> And the quality varies just as much as Cliff's notes.
>>
>> Paul
>

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

iD8DBQFER7EipJeHo/Fbu1wRAiTkAJwJwDsuvLJyjDluD3Kyl01oHVB3tQCgun8L
pKG8enKrsqfB42XYIEGrAxA=
=rr3/
-----END PGP SIGNATURE-----

Re: [9fans] [OT] URI

[Jack Johnson]

On 4/20/06, Paul Lalonde <plalonde@telus.net> wrote:
> It's sad how few computer (as opposed to computing science) books are
> happy addressing an expert audience; writing anything that assumes
> programming skills and intelligence would probably reduce the
> audience to much less than a printing :-(

I would disagree with that assessment.

As neither an expert nor a novice, I find that most texts are at the
extremes.  It's either iPod Syncing for Dummies or Implementing
IKE-DNS Interfaces using Visual Studio, with a dearth of titles that
assume some middling knowledge by the reader.  It's either 1200 pages
of hand-holding or some tome written for some poor schmuck who has to
read it to keep his job tending the same Oracle DB day after day.

Rarely do you see From Smalltalk to Ruby, Plain Old C for the C++
Brainwashed, Your First Device Driver, or Understanding the
Model-Viewer-Controller Model.  Try finding an introduction to
assembly that assumes you haven't already done it before.  It's easy
to find architecture-specific references, but the general theory stuff
is just gone.  Either you lived through it, you went to school for it,
or you're on your own.  I'd like to see guides for the not-yet-lost.

The Practice of Programming is probably the best recent book for the
neither-drooler-nor-brainiac crowd.  I find myself picking up stuff
that's out of print, just for the perspective: Software Tools,
Starting FORTH, Project Oberon, etc.  I've heard good things about the
How to Think Like a Computer Scientist variations, but haven't read
them.

-Jack

Re: [9fans] [OT] URI

[Moritz Kiese]

On Thu, 20 Apr 2006, Jack Johnson wrote:

> On 4/20/06, Paul Lalonde <plalonde@telus.net> wrote:

[snip: NEWS: good books are rare]

> Rarely do you see From Smalltalk to Ruby, Plain Old C for the C++
> Brainwashed, Your First Device Driver, or Understanding the
> Model-Viewer-Controller Model.  Try finding an introduction to
> assembly that assumes you haven't already done it before.  It's easy
> to find architecture-specific references, but the general theory stuff
> is just gone.  Either you lived through it, you went to school for it,
> or you're on your own.  I'd like to see guides for the not-yet-lost.

I found
Computer Organization and Design. The Hardware/Software Interface. by
David A. Patterson, John L. Hennessy
combined with a (M)MIX intro by some German guys (don't have it on my
office shelf) a viable approach for the assembly part. I agree on the rest
though.

++mbk

Re: [9fans] [OT] URI

[Brantley Coile]

> I found
> Computer Organization and Design. The Hardware/Software Interface. by
> David A. Patterson, John L. Hennessy

The two books by Patterson and Hennessy are just a couple of exceptions
to the `large id bad' generalizations, not that you mention them.  I even
find one or the other of them in my local Borders book store.

Re: [9fans] [OT] URI

[quanstro]

this isn't unique to computer science.

the content of calculus textbooks is inversely proportional to their
length.

- erik

On Thu Apr 20 10:53:08 CDT 2006, brantley@coraid.com wrote:
> But O'Reilly books are bigger than the rfc's.  I want less to read.
>
> As an aside, have you noticed that Prentice Hall is printing
> K&R on thicker paper to make the book look larger?  Seems too
> many people don't judge a book by it's cover, but by the pound.
>
> > O'Reilly.
> >
> > And the quality varies just as much as Cliff's notes.
> >
> > Paul
>

1