Re: [9fans] rewriting paths [was: mv vs cp]

Re: [9fans] rewriting paths [was: mv vs cp]

[Fco.J.Ballesteros]

One thing I like in Plan 9 is that by keeping the fs alive,
you can survive crashes on any other machine. The renamefs 
would make you more dependent on crashes not happening 
in the machine w/ renamefs before it moves everything around.

The other question I have: is all this worth just to avoid mv
doing a cp+rm? Beware that even if you could move, the
worm would burn a copy unless you also modify it.

Re: [9fans] rewriting paths [was: mv vs cp]

[George Michaelson]

Something maybe not covered so far is what mv etc do with sparce files,
if memory serves me right some operations are 'safe' and some have a habit
of filling the empty extent with data, having unforseen consequences for
the real size of used disk.

Of course, if 9 doesn't have them, it doesn't have the problem either.

-George

Re: [9fans] rewriting paths [was: mv vs cp]

[Richard]

Fco.J.Ballesteros writes:
>One thing I like in Plan 9 is that by keeping the fs alive,
>you can survive crashes on any other machine. The renamefs 
>would make you more dependent on crashes not happening 
>in the machine w/ renamefs before it moves everything around.

I see your point.

In renamefs's defense, I note that most users most of the time are
working on their own stuff, not making any chanages to the parts of the
network that everyone relies on.  If the renamefs is running on your own
terminal or cpued to some cpu server, and your working on your own
stuff, a crash of the renamefs will not affect the other users.

Ie, do not use renamefs when you are adminning the network.

Re: [9fans] rewriting paths [was: mv vs cp]

[Douglas A. Gwyn]

George Michaelson wrote:
> Something maybe not covered so far is what mv etc do with sparce files,
> if memory serves me right some operations are 'safe' and some have a habit
> of filling the empty extent with data, having unforseen consequences for
> the real size of used disk.
> Of course, if 9 doesn't have them, it doesn't have the problem either.

It wouldn't much matter, since it's just an optimization issue and
could be "fixed".

Re: [9fans] useful language extension, or no?

[Sam]

Ok, I'll bite and play devil's advocate.

What about the promotion of a structure from itself
to one of its members in a function call simply because
it makes locking a structure easier?  Surely passing in
a pointer to a function and having the in-func pointer completely
different violates some standard of programming languages.

Why was it worthwhile to change the language in this respect,
for the idiom of "always having to make sure the lock is the
first item in the structure for pointer coersion is a pain?"

Sam

On Tue, 16 Jul 2002, rob pike,
esq. wrote:

> > Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
> > quite possibly more efficient (without getting into a usec argument,
> > please).  Do you disagree?
>
> Yes.  The benefit is minor, too small to justify changing the language.
> You're trying to formalize an idiom; just using the idiom suits me fine.
>
> The type inclusion feature, I think, did a lot more, since it trigged type
> conversion and promotion: a much bigger deal.
>
> -rob
>

Re: [9fans] useful language extension, or no?

[rob pike, esq.]

> Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
> quite possibly more efficient (without getting into a usec argument,
> please).  Do you disagree?

Yes.  The benefit is minor, too small to justify changing the language.
You're trying to formalize an idiom; just using the idiom suits me fine.

The type inclusion feature, I think, did a lot more, since it trigged type
conversion and promotion: a much bigger deal.

-rob

Re: [9fans] more extensions

[Sam]

My next thought, but I figured I'd used all my contribution
credits today.

Sam

On Tue, 16 Jul
2002, FJ Ballesteros wrote:

>
> Including tuples (perhaps as an instance of nameless structs) would
> simplify many interfaces, right? that's one thing I learned using
> Limbo.
>
> The extension would probably be not too complex, also.
>
> I don't have time to implement this during this semester, but would
> be willing to do so in the future if people from the Labs agree.
>
> Is there agreement on this?
>

[9fans] New language?

[Sam]

> be harder than it appears.  And  there comes a point
> where an extension changes the flavor of a language
> a little too much, and I think this one might be over
> that line.

Too true.  What then, a new language based on C pulling the
yummy stuff out of limbo?  One that's not interpreted, without
a garbage collector, and no atend >:), but that has tuples, array bounds
checking, etc?  At this point should we just considering loosening up
Oberon a little and making a few additions?

I'd be willing to help so long as we fix the BCPL inherited '&'
precedence.

Sam

[9fans] more extensions

[FJ Ballesteros]

Including tuples (perhaps as an instance of nameless structs) would
simplify many interfaces, right? that's one thing I learned using
Limbo.

The extension would probably be not too complex, also. 

I don't have time to implement this during this semester, but would
be willing to do so in the future if people from the Labs agree.

Is there agreement on this?

[9fans] more extensions

[Howard Trickey]

This is tempting.  Tuples are one of my favorite things
about Limbo.

However, I'm biased, as I was the one that pushed for tuples
in Limbo, I think.

But adding them to C's already delicate grammar might
be harder than it appears.  And  there comes a point
where an extension changes the flavor of a language
a little too much, and I think this one might be over
that line.

- Howard Trickey

> Including tuples (perhaps as an instance of nameless structs) would
> simplify many interfaces, right? that's one thing I learned using
> Limbo.

Re: [9fans] more extensions

[Scott Schwartz]

| Including tuples (perhaps as an instance of nameless structs) would
| simplify many interfaces, right? that's one thing I learned using
| Limbo.

Yeah, but limbo has bounds checked arrays, which are even more useful.

Re: [9fans] more extensions

[Dan Cross]

> | Including tuples (perhaps as an instance of nameless structs) would
> | simplify many interfaces, right? that's one thing I learned using
> | Limbo.
> 
> Yeah, but limbo has bounds checked arrays, which are even more useful.

Has anyone ever wondered, ``why not just port limbo?''  Surely the
runtime environment provided by Dis can be emulated using a library.

Not in response to Scott's comment, but in general, I'm not a big fan
of changing C; C is what C is.  If you want something else, use
something else, but don't try to morph C into another language.

	- Dan C.

Re: [9fans] more extensions

[Jon Snader]

On Tue, Jul 16, 2002 at 02:47:27PM -0400, Dan Cross wrote:
> 
> Not in response to Scott's comment, but in general, I'm not a big fan
> of changing C; C is what C is.  If you want something else, use
> something else, but don't try to morph C into another language.
> 

As a wise man once said (sort of): ``If you want limbo, you know
where to get it.''

Re: [9fans] New language?

[GBA]

Don't know much about Limbo, but have you seen this?

http://www.digitalmars.com/d/index.html


> Too true.  What then, a new language based on C pulling the
> yummy stuff out of limbo?  One that's not interpreted, without
> a garbage collector, and no atend >:), but that has tuples, array bounds
> checking, etc?  At this point should we just considering loosening up
> Oberon a little and making a few additions?
> 
> I'd be willing to help so long as we fix the BCPL inherited '&'
> precedence.
> 
> Sam
> 
> 

Re: [9fans] New language?

[Lucio De Re]

On Tue, Jul 16, 2002 at 10:45:02PM -0700, GBA wrote:
> 
> Don't know much about Limbo, but have you seen this?
> 
> http://www.digitalmars.com/d/index.html
> 
What, no tuples?!

More seriously, I'm happy to work further on Alef, but I have long
ago accepted Bell Labs' view that maintaing the libraries is a
disaster.

I see the "D" people mention "versioning".  I'm insufficiently
knowledgeable to decide whether that is something I would appreciate
or despise.  I know NetBSD is hooked on it (in the sense that meat
hangs from hooks in refrigerators, sadly) because of their use of
dynamic libraries.

I guess that makes it a useful solution, if you can't get rid of
the problem in the first place.

++L

Re: [9fans] more extensions

[Douglas A. Gwyn]

FJ Ballesteros wrote:
> Including tuples ...

Tuples are truly useful.  There are some syntactic issues to solve
when adding them to C, but assuming they're dealt with I would
welcome this experiment.  It would provide some leverage in arguing
for standardization of the feature for C0x.

Re: [9fans] more extensions

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> ... I think C is not the place to do language hacking any more.

I largely agree, although there are some places in C where programmers
really could use some help.  The C language is not very "clean" due
to having accumulated features rather than having features redesigned
(which would of course have caused major problems for important
existing code).  Any really substantial changes would be done better
in a new language.  Maybe language designers could learn from
history and avoid many of the bigger mistakes, mainly overloading
single constructs with several conceptually non-identical meanings.

Re: [9fans] more extensions

[Fariborz (Skip) Tavakkolian]

That reminds me of a million dollar idea I had the other day. As we are all nearing
retirement, it would be interesting to consider retirement homes equipped with
old machines that only understand old dialects of C, FORTRAN, etc.  I'm telling you
the retiring software developer generation is a gold mine. The keyboards would
have to be drool proofed though.

(also a joke)

At 03:15 PM 7/16/2002 -0400, bwc@coraid.com wrote:
>I'll amen Howard here.  I'm just now getting used to function prototypes!
>
>(that was a joke)
>
> Brantley

Re: [9fans] more extensions

[bwc]

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

I'll amen Howard here.  I'm just now getting used to function prototypes!

(that was a joke)

 Brantley

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

From: "Howard Trickey" <howard@research.bell-labs.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] more extensions
Date: Tue, 16 Jul 2002 13:28:07 -0400
Message-ID: <000501c22cee$2608e170$bf356887@bl.belllabs.com>

This is tempting.  Tuples are one of my favorite things
about Limbo.

However, I'm biased, as I was the one that pushed for tuples
in Limbo, I think.

But adding them to C's already delicate grammar might
be harder than it appears.  And  there comes a point
where an extension changes the flavor of a language
a little too much, and I think this one might be over
that line.

- Howard Trickey

> Including tuples (perhaps as an instance of nameless structs) would
> simplify many interfaces, right? that's one thing I learned using
> Limbo.

Re: [9fans] more extensions

[rob pike, esq.]

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

I love tuples, just love them, but I think C is not the place to
do language hacking any more.  A case could even be made
that it wasn't the right place when Ken hacked it around 1988,
although a number of the changes were valuable and did make
it into the standard (e.g. indexed initializations).

-rob

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

From: FJ Ballesteros <nemo@gsyc.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: [9fans] more extensions
Date: Tue, 16 Jul 2002 19:24:58 +0200
Message-ID: <3D3456EA.4B0BC1D4@gsyc.escet.urjc.es>


Including tuples (perhaps as an instance of nameless structs) would
simplify many interfaces, right? that's one thing I learned using
Limbo.

The extension would probably be not too complex, also. 

I don't have time to implement this during this semester, but would
be willing to do so in the future if people from the Labs agree.

Is there agreement on this?