[9fans] Awk or Limbo ?
William Staniewicz
been taking place but have to admit to not
knowing much about programming and the options
that are available.
What appears to be true is that C++ is not well
received here. That comes a bit of a surprise
because when I do wander through a bookstore in
the computer section C is there in large quantity.
Some people mention Limbo and AWK. Which is used
daily by the Plan9'rs?
-Bill
Boyd Roberts
> daily by the Plan9'rs?
depends on the job.
this was what was so stupid about the SRC C++/Modula 3
'one true language' debate/meeting. taylor just psy-op'd
them into agreeing on modula 3. i could barely contain
the hilarity of the situation. the SRC labs meetings, as
a visitor, where always fun just to watch taylor in action.
geoff...@collyer.net
that they are related, but inversely. The current state of operating
systems, languages and software generally tends to support that view.)
Boyd Roberts
> One of the things about C, though, is that (IMHO) it works best as a
> systems programming language. As an application development language,
> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
> by that name once, listing many of them) ...
yup, conehead had a wealth of experience. <laugh>
snocone, anyone?
Dan Cross
Well, I use awk every day for a variety of reasons. Others use Limbo
on a daily basis. The thing about programming languages is that
they're like shoes; one pair is simply not enough for every occasion
(for instance, try skateboarding in wingtips; try getting a job on Wall
St wearing sneakers; try doing string processing in COBOL, and you'll
see what I mean).
The backlash against C++ shouldn't be too surprising, really. C++ goes
against everything that good programmers are supposed to strive for:
Simplicity, clarity, ease of understanding, ease of maintenance,
abstraction of complexity, attention to (the problem's) detail, privacy
of implementation, good engineering tradeoffs, etc. It's ironic that
many of these things are supposed to be made `easier' by C++.
When one works in C++, one finds oneself spending more time worrying
about minutae of syntax and minisule details to make the compiler happy
than worrying about the problem. The effect is rather like drinking from
a firehose; while you *ought* to be getting all the details, there's no
way you can, because there are too many, and you get bogged down.
Many programmers find the language so difficult that they throw the
``good'' parts out the window and don't even attempt to provide, eg,
abstraction through classes. Plus, the object system is all wrong,
forcing bizarre constructs like templates on the programmer, without
which it would be impossible to build anything remotely resembling a
generic container.
As pointed out by Presotto, much of this is a result of C++'s heritage
as an `extension' of C. Java, IMHO, makes a better go of it by forgoing
C compatability where it makes sense, but as Forsyth noted, it's
concurrency model is grounded in decades old tradition; hardly an
advance of the state of the art. It also falls short in a few other
places, such as making a distinction between objects and native types.
Then again, Rob Pike has described Java as an industrial response to
C++. I don't think that's inaccurate.
One likes a programming language to be expressive; a tool for
communicating an idea, if you will. Any time one gets swamped in
details imposed by the language, one is as a matter of course less
expressive in that language. The ideal language is one that allows
an individual to express his- or herself directly and succintly.
I don't know of a language that really provides that, but C does
a reasonable job in some problem domains. Languages like Python
do well in others (I really like python, even if the module system
is a little much).
One of the things about C, though, is that (IMHO) it works best as a
systems programming language. As an application development language,
it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
by that name once, listing many of them), and other annoyances, like
the lack of built-in ADTs (why should I build a dictionary myself?
99% of the time, I just want to use it; I don't care about how it's
implemented).
One does wonder, however, if the Unix utilities had been written in
another language like Limbo if we would be whitnessing all the stupid
buffer overrun attacks that the kids are using for bypassing security
these days.
Okay, I've rambled long enough.
- Dan C.
geoff...@collyer.net
deliberate or accidental, but I believe that the fundamental problem
is this: to be a good programmer, you have to be willing to cope with
all the details inherent in programming, and apparently most of the
population don't have the personality traits (patience, attention to
detail, etc.) to do it (though that doesn't stop them trying). One
of the advantages of writing substantial quantities of
assembly-language code is that everything else seems so much easier,
since there is so much less detail to deal with. Limbo removes still
more fiddly details of memory allocation. I think some of the
advantages of automatic string allocation can be had using Plan 9's
libString, which has existed for years inside upas.
But there's really no excuse for using gets() nor overrunning static
buffers. If there's isn't a suitable routine around for the task at
hand, you write one. It's amazing to me that as Sendmail, Inc. stamp
out one buffer overrun, another pops up, and it's 18 years later.
It's like a Conservation of Overruns. These problems could have been
found and fixed in a pass over the code with a small string library
(such as the one we used in C News). But the kids would rather write
yet another sorely-needed Linux desktop manager than tackle real
problems. Rotten kids...
Barry Shein commented that `X was written by seventeen-year-olds who
can't program sitting down' (I hope I haven't misquoted him) and it
shows. There's a little known program in the Plan 9 distribution,
Brenda Baker's dup(1), that one can run over the source of the latest
whiz-bang program and get a sense for how much code was cut-and-pasted
instead of converted into proper functions, presumably by the same
sort of kids with bladders full of Jolt cola. Incidentally, the
distributed /rc/bin/dup didn't work when I last looked; here's a fixed
one:
#!/bin/rc
path=(/$cputype/bin/aux $path)
pdup $* | dupstat
See http://www.collyer.net/~geoff/cant.ps (when our DSL line is up)
for a longer, somewhat dated rant.
Dan Cross
>snocone, anyone?
Have some brew and chips?
- Dan C.
Scott Schwartz
| found and fixed in a pass over the code with a small string library
| (such as the one we used in C News). But the kids would rather write
| yet another sorely-needed Linux desktop manager than tackle real
| problems.
The main problem is that there's no standard string library, but there is
a standard char* type and standard libc functions. Ordinary programmers
have never read the source for C News (or similarly nice code), so they
don't know any better, or are inclined to just do the easiest thing.
There's only one hope: Dennis Ritchie has to pick a string library,
declare it to be the One True C String Thing, and instruct, via an
announcement on slashdot, the swarming Linux minions to spread it to
the eight corners of the universe in a massive and unstoppable jihad,
followed, possibly, by it's inclusion in a future version of the
C standard.
Dan Cross
>
> [lots of good comments elided for brevity]
>
>Barry Shein commented that `X was written by seventeen-year-olds who
>can't program sitting down' (I hope I haven't misquoted him) and it
>shows. There's a little known program in the Plan 9 distribution,
>Brenda Baker's dup(1), that one can run over the source of the latest
>whiz-bang program and get a sense for how much code was cut-and-pasted
>instead of converted into proper functions, presumably by the same
>sort of kids with bladders full of Jolt cola. Incidentally, the
>distributed /rc/bin/dup didn't work when I last looked; here's a fixed
>one:
>
>#!/bin/rc
>path=(/$cputype/bin/aux $path)
>pdup $* | dupstat
Plan 9 has dup(1) in it? Not on my system unfortunately; I've been
looking for a copy for years, too....
Cutting and pasting may be bad in X, but you should have seen my last
job. Oi.
- Dan C.
Boyd Roberts
> a standard char* type and standard libc functions.
do me a favour. it's a page of code:
echo flex.h
sed 's/.//' >flex.h <<'//GO.SYSIN DD flex.h'
-/*
- * Flexible string definitions.
- *
- * @(#)flex.h 1.31
- */
-
-#define FLEXZ 128
-
-typedef struct
-{
- char *f_str;
- char *f_end;
- char *f_ptr;
-}
- flex;
-
-#define flex_char(f, c) (*((f)->f_ptr == (f)->f_end ? flex_fill(f) :
(f)->f_ptr++) = (c))
-
-extern void flex_end();
-extern char *flex_fill();
-extern void flex_init();
-extern void flex_str();
-extern void flex_nstr();
//GO.SYSIN DD flex.h
echo flex.c
sed 's/.//' >flex.c <<'//GO.SYSIN DD flex.c'
-/*
- * Flexible string handling.
- */
-
-#ifndef lint
-static char sccsid[] = "@(#)flex.c 1.31";
-#endif lint
-
-#include "mace.h"
-#include "flex.h"
-
-void
-flex_init(f)
-register flex *f;
-{
- f->f_str = f->f_ptr = salloc(FLEXZ);
- f->f_end = f->f_ptr + FLEXZ;
-}
-
-char *
-flex_fill(f)
-register flex *f;
-{
- register int s;
-
- s = f->f_end - f->f_str + FLEXZ;
-
- f->f_str = srealloc(f->f_str, s);
- f->f_end = f->f_str + s;
- f->f_ptr = f->f_end - FLEXZ;
-
- return f->f_ptr++;
-}
-
-void
-flex_end(f)
-register flex *f;
-{
- f->f_ptr = f->f_str;
-}
-
-void
-flex_str(f, s)
-register flex *f;
-register char *s;
-{
- while (*s != '\0')
- flex_char(f, *s++);
-}
-
-void
-flex_nstr(f, s, n)
-register flex *f;
-register char *s;
-register int n;
-{
- while (n-- > 0 && *s != '\0')
- flex_char(f, *s++);
-}
//GO.SYSIN DD flex.c
exit
and here's how you'd use it with an RFC 822 / STD 11 address:
-static void
-putdom(d)
-register Dom *d;
-{
- register char **p;
-
- for (p = d->sub; p != d->top; p++)
- {
- flex_str(&f, *p);
- flex_char(&f, RFC_SPEC_DOT);
- }
-
- flex_str(&f, *p);
-}
-
-/*
- * Take an Addr struct and return a textual representation that
- * a delivery agent can use to deliver the message.
- */
-char *
-make_address(a)
-register Addr *a;
-{
- register Dom *d;
- register char *p;
-
- if (f.f_str == NULLSTR)
- flex_init(&f);
-
- d = a->route;
-
- while (d != (Dom *)0 && d->next != (Dom *)0)
- {
- /* source route */
-
- flex_char(&f, RFC_SPEC_AT);
- putdom(d);
- flex_char(&f, d->next->next ? RFC_SPEC_COMMA : RFC_SPEC_COLON);
- d = d->next;
- }
-
- flex_str(&f, a->localp);
-
- if (d != (Dom *)0)
- {
- flex_char(&f, RFC_SPEC_AT);
- putdom(d);
- }
-
- flex_char(&f, '\0');
- p = newstr(f.f_str);
- flex_end(&f);
-
- return p;
-}
trivial.
Boyd Roberts
nah, snocone was a snobol interpretter.
Dan Cross
>> Have some brew and chips?
>
>nah, snocone was a snobol interpretter.
Yeah, I know; the above is a quote from the coneheads. :-)
- Dan C.
geoff...@collyer.net
with Plan 9 and indeed I don't see it in my 2nd
nor 3rd edition manuals. I can't find it in netlib
either and google only finds the papers and references
thereto. My senility must be accelerating; sorry
about that.
nos...@me.kom
Staniewicz) wrote:
>Some people mention Limbo and AWK. Which is used
>daily by the Plan9'rs?
pres...@plan9.bell-labs.com and bo...@planete.net both prefer (and
use(*) limbo, but there seems little evidence to me of common use as a
language to build applications for Plan9. Why is that?
Douglas A. Gwyn
> ... Plus, the [C++] object system is all wrong,
> forcing bizarre constructs like templates on the programmer, ...
? Templates seem like one of C++'s better features.
That and namespaces.
"Object orientation" fits GUI rather well, but is certainly
not natural for several other common programming needs.
> One of the things about C, though, is that (IMHO) it works best as a
> systems programming language. As an application development language,
> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
> by that name once, listing many of them), and other annoyances, like
> the lack of built-in ADTs (why should I build a dictionary myself?
> 99% of the time, I just want to use it; I don't care about how it's
> implemented).
ADTs are easy to build in C; but part of it is that the programmer
himself must provide some of the discipline.
> One does wonder, however, if the Unix utilities had been written in
> another language like Limbo if we would be whitnessing all the stupid
> buffer overrun attacks that the kids are using for bypassing security
> these days.
Buffer overruns are not inherent in C; they're the result of
insufficient care by the undergraduates who whipped together
networking code that the industry then adopted without any
sensible review. Similar problems occur using other languages.
Douglas A. Gwyn
library support for strings, time, bignums, etc. and arrive
at a consensus on an interface. Then, a few years from now
when we start to consider proposals for C0x, submit the
interface spec *early in the process* and find at least one
champion on WG14 to push it forward. Peter Seebach and I
are obvious choices, assuming we're still involved then.
Boyd Roberts
> Buffer overruns are not inherent in C; they're the result of
> insufficient care by the undergraduates who whipped together
> networking code that the industry then adopted without any
> sensible review. Similar problems occur using other languages.
bingo
Dan Cross
>Dan Cross wrote:
>> ... Plus, the [C++] object system is all wrong,
>> forcing bizarre constructs like templates on the programmer, ...
>
>? Templates seem like one of C++'s better features.
>That and namespaces.
They are, but that doesn't necessarily mean that they integrate well
with the rest of the programming environment, nor does it decrease
their bizarreness.
In this case, I think it's pretty clear that templates were an
afterthought, and they're grafted on in a convoluted way. That said,
if forced into using C++, they are useful, but they ain't pretty....
As a specific example, create a class hierarchy, and then use templates
to create a container of objects from your class hierarchy. (Or even
use the STL). Note, now, that when you copy a subclass into the
container, it's converted to an instance of the base class and you
loose your subclass data. Argh! This is because polymorphism in C++
is only acheived when you refer to an object through a pointer or
reference, and templates are dumb.
Eiffel has a similar concept (I believe they even call them templates),
but I seem to recall that it integrates into the language in a *much*
less obtrusive way than in C++.
>"Object orientation" fits GUI rather well, but is certainly
>not natural for several other common programming needs.
Yes.
>> One of the things about C, though, is that (IMHO) it works best as a
>> systems programming language. As an application development language,
>> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
>> by that name once, listing many of them), and other annoyances, like
>> the lack of built-in ADTs (why should I build a dictionary myself?
>> 99% of the time, I just want to use it; I don't care about how it's
>> implemented).
>
>ADTs are easy to build in C; but part of it is that the programmer
>himself must provide some of the discipline.
Sure, it's easy, but it's also easy to tie my shoes. That doesn't make
it any less annoying. :-)
When working on a problem, I start to envision what kind of structures
(in the sense of ``computational structures,'' not necessarily data
structures) I want to use to solve it. For instance, I know that I'll
need an associative lookup, some sort of list, I'll have to put a sort
in some place, etc. When I'm working in C, I have to go off and
implement most of that stuff before I can proceed. It's not hard, but
it is tedious and annoying. When working in another language (say,
smalltalk, for example) most of that stuff is already done for me, and
so I can just use it. That's handy.
>> One does wonder, however, if the Unix utilities had been written in
>> another language like Limbo if we would be whitnessing all the stupid
>> buffer overrun attacks that the kids are using for bypassing security
>> these days.
>
>Buffer overruns are not inherent in C; they're the result of
>insufficient care by the undergraduates who whipped together
>networking code that the industry then adopted without any
>sensible review. Similar problems occur using other languages.
No, they're not *inherent*, but they're a lot easier to make a mistake
which results in one. Your example of undergraduates wreaking havoc
on the industry is right on, but if you think *those* undergraduates
were bad, you should see the code they write in industry!
But don't get me wrong; I like C, a lot. I just think that it's
important to recognize that it's not the right tool for every job.
- Dan C.
geoff...@collyer.net
concurrent ("multithreaded") programs in limbo and felt comfortable
doing so, whereas using the Unix LWP (light-weight process) libraries
(or POSIX threads) directly has always seemed hazardous. Unix LWPs
are fighting Unix, specifically the libraries, that were designed
assuming one process (or "thread") per address space. This is one
reason (aside from unportability across Unixes and dubious gains) that
we let Rich Salz go off and do INN; I had no desire to deal with that
mess, especially the mess 10 years ago.
However, limbo is implemented as a part of Inferno and the two are
somewhat intertwined, so running limbo programs on Plan 9 is really
running limbo programs in Inferno on Plan 9, and Inferno's interface
as a command (emu) to the surrounding Plan 9 isn't seemless, though
it's getting better. Thus forsyth's recent comments about a native
implementation of limbo on Plan9, which would make it more appealing
for some jobs.
libthread attempts to capture some of the benefits of limbo (notably
communication) in C, but I'd rather have one kind of process (not
processes and threads) and it feels a little like LWP libraries to me,
plus you don't get the concise limbo communication syntax and
automatic memory (de)allocation.
Scott Schwartz
| concurrent ("multithreaded") programs in limbo and felt comfortable
| doing so, whereas using the Unix LWP (light-weight process) libraries
| (or POSIX threads) directly has always seemed hazardous.
On a slightly different topic, it has also seemed hazardous to me in
Plan 9. One particular thing, for example, is that there's no way to
tell the system that a cohort of processes should be treated as such.
I used to have great fun with mothra when one process would crash, and
leave the rest deadlocked or otherwise boggled. On those occasions,
I felt like a multi-threaded application should have a kernel-enforced
way to fail as a unit, as if there was a suicide_pact() system call,
or something like the "reboot" device, so that of one process dies
unexpectedly, the others do too.
| libthread attempts to capture some of the benefits of limbo (notably
| communication) in C, but I'd rather have one kind of process (not
| processes and threads) and it feels a little like LWP libraries to me,
| plus you don't get the concise limbo communication syntax and
| automatic memory (de)allocation.
Agreed.
Boyd Roberts
i coded up the pthreads version of a hash table of linked
lists -- ghastly.
bio.c had it right.
j...@plan9.bell-labs.com
There is/was a proposal on the table about a year ago for a neat way
to tidy up all this stuff. Maybe we'll get round to it once we've finished
editing all the source to get the declaration of 'main' right.
for...@caldo.demon.co.uk
>>Plan 9. One particular thing, for example, is that there's no way to
>>tell the system that a cohort of processes should be treated as such.
there are a few little traps and pitfalls in limbo/inferno too.
it's tricky, because there are conflicting requirements.
recently i've had to look at XML and its near and far relations.
it is fascinating how close they skirt to undecidability.
is that good or bad? i can't decide.
Richard Miller
> leave the rest deadlocked or otherwise boggled.
This behaviour seems to be a consequence of the atnotify handler
in the event(2) package used by mothra.
When a note is received in the main process, the handler sends a "die" note
to all the subprocesses and returns 0 to request the default exception
action (exit or suspend). But when a note is received in a subprocess, the
handler simply returns 1 to request continuation. If the note occurred
during a system call (e.g. reading from the network), in most cases the
continued mothra process will detect the abnormal return and exit. If not,
the "die" note is simply ignored and deadlock results.
I wonder whether /sys/src/libdraw/event.c:#6972,#6980 should be "return 0" ?
-- Richard
Douglas A. Gwyn
> When working on a problem, I start to envision what kind of structures
> (in the sense of ``computational structures,'' not necessarily data
> structures) I want to use to solve it. For instance, I know that I'll
> need an associative lookup, some sort of list, I'll have to put a sort
> in some place, etc. When I'm working in C, I have to go off and
> implement most of that stuff before I can proceed. It's not hard, but
> it is tedious and annoying. When working in another language (say,
> smalltalk, for example) most of that stuff is already done for me, and
> so I can just use it. That's handy.
Actually, most of this kind of support could be already done in C,
too, but the problem is that not much of it is *standard*, so you
pretty much have to carry around your own support library. I'm in
the process of updating the generally-useful packages of the MUVES
project's support library, to make it more suitable for embedded
applications. I think when I finish I can give it away to anybody
who thinks he could use it. When the time comes I'll tell more
about it, probably in comp.lang.c.moderated.
> But don't get me wrong; I like C, a lot. I just think that it's
> important to recognize that it's not the right tool for every job.
Agreed. However, it can be used to build more suitable tools..
Douglas A. Gwyn
> it is fascinating how close they skirt to undecidability.
> is that good or bad? i can't decide.
Why would it be bad? Any sufficiently interesting system
must have undecidable constructs.
oka...@granite.cias.osakafu-u.ac.jp
>for some jobs.
Isn't this a new version of Alef? Yes, it apeals us very strongly.
I thought this wasn't possible because of some "political/economic"
reasons, but not of research... I'm not blaming inferno though.
Kenji
Andrey A Mirtchovski
> Isn't this a new version of Alef? Yes, it apeals us very strongly.
>
all your alefs are belong to us :)
sorry. could not resist :)
this comment should not be understood as a pun of japanese english, but
rather as an... damit..it just sounds so ninja :)
andrey :)
who likes plan9 and www.ninjatune.net at the same time :)
--
stupendously wasting space on /n/dump since last night :)
Richard Uhtenwoldt
>Popularity and quality are not related. (A more pessimistic view is
>that they are related, but inversely. The current state of operating
>systems, languages and software generally tends to support that view.)
William K. Josephson writes:
>In fact, in my experience, the Plan 9
>source code is far *more* portable to other environments than most
>Unix source is between Unix variants, for instance.
well, you see, if all code written for Plan 9 can be easily ported to
Unix, but the code written for Unix is difficult to port to Plan 9
(because Unix is not as well thought out and well factored as Plan 9),
then people who want to use apps without having to port/rewrite/write
them will choose Unix, because the apps available for Unix will
tend to be a superset of the apps available for Plan 9.
so here we have a process whereby bad engineering actually
increases a platform's popularity. (Dijkstra noted a similar process
back in the 1970s in which DP department workers increased their job
security by choosing overly complex solutions, which IBM was happy to
sell to them.)
and even people like me, who appreciate well-engineered, well-factored
software, choose to use one of the popular, poorly-engineered
platforms, because the socioeconomic utility of a platform is
essentially proportional to the number of users of the platform.
(reasons for this omitted for space reasons.) so, I put up with the
cost in my wasted time of the poor engineering to get the
socioeconomic benefits of the popularity.
eventually a critical mass of (millions of) users will come to
recognize the true costs of poorly-engineered software, resulting in
popular software as well-engineered as Plan 9, but that is not going
to happen this decade.
what is going happen this decade to help along the eventual popularity
of well-engineered software more than anything else is the replacement
of data formats, communications protocols, APIs with secrets and
"owners" (firms with the ability to prevent their competitors from
making full use of the data format, etc) with data formats, protocols
and APIs without secrets and owners.
so, even tho the open-source platforms like Linux are poorly
engineered, the more popular they get, the better for unpopular
platforms, and thus well-engineered platforms in the long term,
because Linux's data formats, protocols and APIs have no secrets and
no "owners" so that the unpopular platforms can hook into them more
effectively. one example of this hooking in is the consulting of
Linux device-driver source code by Plan 9 developers.
this hooking in gives the users of the unpopular platform a bigger
fraction of the socioeconomic benefits of Linux than they could get
from the unpopular platform's trying to hook into proprietary
platforms, because the "owners" of the proprietary platforms will tend
to prevent competition from other platforms by denying those benefits.
Boyd Roberts
> ... code written for Unix is difficult to port to Plan 9
it's not that hard, but it depends on what sort of unix braindamage
you've got to port. i did a very rough port of 10k lines of unix
code to plan 9 in two days. of course, sam made the task a lot
easier and the code was pretty modular and ran on a variety of
unix varients -- without 'configure'!
hardest part was the mailbox locking protocol and the:
From ...
...
morF
stuff.
Russ Cox
than plan 9 code is to port to unix" observation,
while empirically true, is not a function of
those systems so much as the code itself.
as boyd points out, there exist portable programs
written for unix. it's more a question of
whether the author thought about good interfaces,
and to date plan 9 software has a better history
of that. (that may change, of course, once plan 9
displaces windows nt and linux as the dominant server
operating system.)
William Staniewicz
why I bring up another point relating to code.
How difficult is it to port FORTRAN code to Plan9? Back a few
years ago in the archives there were inquiries into a FORTRAN
compiler and there appeared to be none available.
Would it be a good idea to have one to support some
of the applications in the number crunching world?
-Bill
andrey mirtchovski
> From: "Richard Uhtenwoldt" <r...@river.org>
> > ... code written for Unix is difficult to port to Plan 9
>
> it's not that hard, but it depends on what sort of unix braindamage
> you've got to port. i did a very rough port of 10k lines of unix
> code to plan 9 in two days. of course, sam made the task a lot
> easier and the code was pretty modular and ran on a variety of
> unix varients -- without 'configure'!
i have both good and bad experiences in trying to get unix stuff running on
p9... in my opinion it all depends on how clean and well written the unix
code is...
with the plethora of software freely available for linux/*bsd these days, if
A does not want to compile and looks like too much work i simply fetch B and
give it a try.. in most cases the differences in the actual product are
minimal..
andrey
Dan Cross
>(that may change, of course, once plan 9
>displaces windows nt and linux as the dominant server
>operating system.)
You'll have to add Tsync to 9P2000 before that can happen.
- Dan C.
(Duck! Run! Hit the deck!)
Eric Grosse
We use f2c (http://plan9.bell-labs.com/netlib/f2c/) to convert Fortran to C,
and don't feel a strong need for a native Fortran compiler.
j...@plan9.bell-labs.com
From STAT(5):
A wstat request can explicitly avoid modifying some proper-
ties of the file by providing explicit ``don't touch'' val-
ues in the stat data that is sent: zero-length strings for
text values and the maximum unsigned value of appropriate
size for integral values. As a special case, if all the
entries in a Twstat message are ``don't touch'' values, the
server may interpret it as a request to guarantee that the
contents of the associated file are committed to stable
storage before the Rwstat message is returned. (Consider
the message to mean, ``make the state of the file exactly
what it claims to be.'')
rob pike
Let's ask Boyd.
-rob
oka...@granite.cias.osakafu-u.ac.jp
>A does not want to compile and looks like too much work i simply fetch B
I'm now trying to evaluate how it is difficult to port GRASS4.1, because I
changed it too many parts for other planet, I cann't reside on a newer version :-),
and found it's much cumbersome to port this kind of 'old' software, particularly
in two points, (1) X11, (2) terminal emulation such as curses!,
termios/termio/sgtty is not though.
By the way, what is designer's opinion of porting a CUI like curses to Plan 9?
Kenji
Boyd Roberts
>
> Let's ask Boyd.
curses? a port of curses? what would be the point?
been a long time since i looked into that particular mess, but it
was for use with glass ttys. apart from it being rotten to the
core, it has too many functions/macros and i'm sure you'd run
into unicode and font problems.
the horror, the horror ...
oka...@granite.cias.osakafu-u.ac.jp
Maybe simpler to write some user friendly software. ^_^
I'm considering it to replace by control(2) library, too. However,
if 'curses' is available in Plan 9, it must be easier.
>core, it has too many functions/macros and i'm sure you'd run
>into unicode and font problems.
Aa- (Japanese:-), I see. It's not any simpler...
Ok, I'll forget it. Thanks Boyd!
Kenji
Boyd Roberts
douitashimashite
Douglas A. Gwyn
> How difficult is it to port FORTRAN code to Plan9? Back a few
> years ago in the archives there were inquiries into a FORTRAN
> compiler and there appeared to be none available.
There is a Fortran-to-C translator with run-time library
under the name "f2c" in NetLib. It works well enough for
many purposes.
Douglas A. Gwyn
> From STAT(5):
> A wstat request can explicitly avoid modifying some proper-
> ties of the file by providing explicit ``don't touch'' val-
> ues in the stat data that is sent: zero-length strings for
> text values and the maximum unsigned value of appropriate
> size for integral values. As a special case, if all the
> entries in a Twstat message are ``don't touch'' values, the
> server may interpret it as a request to guarantee that the
> contents of the associated file are committed to stable
> storage before the Rwstat message is returned. (Consider
> the message to mean, ``make the state of the file exactly
> what it claims to be.'')
Oh, great, more usurping of data values for in-band
signalling of exceptional conditions.
Douglas A. Gwyn
> curses? a port of curses? what would be the point?
Probably, to allow ready import of curses-based applications
such as the Crypt Breaker's Workshop.
Russ Cox
> signalling of exceptional conditions.
You can't please all the people all the time.
j...@plan9.bell-labs.com
> j...@plan9.bell-labs.com wrote:
> > From STAT(5):
> > A wstat request can explicitly avoid modifying some proper-
> > ties of the file by providing explicit ``don't touch'' val-
> > ues in the stat data that is sent: zero-length strings for
> > text values and the maximum unsigned value of appropriate
> > size for integral values. As a special case, if all the
> > entries in a Twstat message are ``don't touch'' values, the
> > server may interpret it as a request to guarantee that the
> > contents of the associated file are committed to stable
> > storage before the Rwstat message is returned. (Consider
> > the message to mean, ``make the state of the file exactly
> > what it claims to be.'')
>
> signalling of exceptional conditions.
Oh, great, more whining.
David Gordon Hogan
> Oh, great, more usurping of data values for in-band
> signalling of exceptional conditions.
| /* alloca.c -- allocate automatically reclaimed memory
| (Mostly) portable public-domain implementation -- D A Gwyn
[snip]
| As a special case, alloca(0) reclaims storage without
| allocating any. It is a good idea to use alloca(0) in
| your main control loop, etc. to force garbage collection. */
Gotcha!
Douglas A. Gwyn
> | As a special case, alloca(0) reclaims storage without
> | allocating any. It is a good idea to use alloca(0) in
> | your main control loop, etc. to force garbage collection. */
The storage reclamation occurs anyway. The documentation
is misleading; the actual "special case" is that alloca()
always reports failure to allocate storage for a 0-sized
object. This could easily be changed (to successfully
allocate a header-only chunk, basically just remove the
short-circuit that was added to make garbage collecting
more efficient), if C were ever changed to support
0-sized objects.
By the way, my alloca implementation was meant as a
transitional measure only; I hope you're not writing new
code that relies on alloca. It's not feasible to
implement on some architectures.
Douglas A. Gwyn
It is an example of a long-standing and well-known mistake
in interface design, which *should* be one of the things
that is "rethought" in Plan 9. If you guys didn't keep
implying that the only rationally-designed software is
that in Plan 9, I might be more tolerant of your mistakes.
j...@plan9.bell-labs.com
Oh great, even more whining.
Douglas A. Gwyn
> Oh great, even more whining.
On whose part?
j...@plan9.bell-labs.com
Ant the whine goes on.
David Lukes
> in interface design, which *should* be one of the things
> that is "rethought" in Plan 9. If you guys didn't keep
> implying that the only rationally-designed software is
> that in Plan 9, I might be more tolerant of your mistakes.
Personally I think an apology is warranted.
1) While it may be a "mistake" in your opinion,
I personally think that, while it ain't perfect,
a) it works
b) it has no untoward side effects other than
a slight loss of efficiency
(if someone does a wstat with no changes,
the worst they get is a superfluous "fsync"),
2) You should first remove the plank from your own eye,
as shown by Mr. Hogan.
3) In all they years since V6,
I have seen evidence that those "guys" have many qualities,
but I have never seen anything which suggests that
they believe in their own infallibility.
Cheers,
Dave.
P.S. Thank you for finding a use for the expression
"Hoist on his own petard".
David Lukes
I don't think he's whining,
I think he's just missing the point.
Cheers,
Dave.
Dan Cross
Doug had a valid point, others disagreed with him with equally valid
points; it's not worth pursuing further.
Can we please move on now?
- Dan C.
oka...@granite.cias.osakafu-u.ac.jp
Plan 9 is a research oriented project, and hence, we don't expect 'compatibility'
to the older standards. The purpose of research is destroying that older
concepts. :-) Then, I think it's enough to ask designers why you do so,
when we feel something is missing in Plan 9. Then, if you don't like it,
you can start another project by yourself...
Kenji
oka...@granite.cias.osakafu-u.ac.jp
In the case of 2nd release, this is not so clear, because it required us
money to buy it. In this sense, it was a product in an extent. However,
this release is open to the world, and this is that attitude we are familier
with in the science world. It also indicates that anyone who cannnot
understand it has no vote to make it use. :-) This is a logical approach
to explain what is Plan 9. In the real world, however, many researchers
are responding here to newbies like me...
Kenji
Douglas A. Gwyn
> I rather think Douglas is somewhat confusing between research and
> product. Plan 9 is a research oriented project, and hence, we don't
> expect 'compatibility' to the older standards.
I don't understand that response, since I wasn't arguing for
compatibility with older standards, just for good interface design.