Linux-Hardware Digest #64, Volume #10 Mon, 19 Apr 99 09:13:51 EDT
Contents:
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?) (GAZZA)
Newbie--3c509b can't recognize ("Kevin")
Creative Banshee pci ("Tony")
Re: Programmers are gods ("Nostril Of Happiness")
----------------------------------------------------------------------------
From: GAZZA <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
Subject: Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
Date: Mon, 19 Apr 1999 10:01:18 +0800
westprog wrote:
>
> Firstly, GAZZA, thank you for remaining polite and debating the
> issues (e.g. not accusing me of inane rants, etc.); it seems that
> case sensitivity is a sensitive issue for some people. Your tabloid
> image seems to be a gross misrepresentation.
My "tabloid image"? Err...perhaps you mean that "Gazza" is the
nickname of the soccer player Paul Gascoyne (sp?). In all fairness,
I'm not that personage; my name is Gary, and Gazza is just a
"short" name for it. (Like "Tel" for "Terry"; maybe you either have
to be English or a Minder fan).
In any case, though, you haven't been rude. We have a disagreement,
but I have never seen arguments won through descent to personal
insults. Besides, you do make it easier for me to understand your
position - even if I still don't actually agree with it.
> > > This could be useful, indeed. The trouble is that now you have
> > > "Object" and "object", which mean different things - if you fail
> > > to press the shift key at the right time, you get a valid
> > > symbol in the wrong place.
> >
> > No, you don't. You get an INvalid symbol in the wrong place. This
> > distinction is very important; the compiler (or a good GUI) will
> > spot this INSTANTLY.
>
> I was trying to think of an instance where a class definition and
> instantiation could be confused by the compiler, but I couldn't
> think of it.
Actually, you've got me there. Even in Fortran, where (IIRC) you
can happily use commands as variables (ie there are no "reserved
words"), the compiler can't get confused.
So case sensitivity doesn't really buy you anything here from a
compiler perspective (although I maintain it is still a handy
thing to be able to declare a variable object of type Object).
I profess to a certain ignorance here - in a language like Delphi
(which I don't know, but I've heard is basically OO Pascal and
presumably has the same case insensitivity of Pascal), is it
possible to "overload" on class names and variable identifiers?
(It's certainly not possible in the "C family", but due to case
sensitivity it's less necessary).
> > > This leads to confusion if you are discussing the code with
> > > someone - "Object" sounds quite similar to "object", and it looks
> > > very alike when written on a whiteboard.
> >
> > I don't tend to write up code on whiteboards, just designs. When I
> > want to discuss code, I get a printout. Is my methodolody in this
> > respect so very unusual?
>
> Not unusual, but not universal. I often find myself discussing class
> definitions with colleagues, or writing brief code fragments on a
> whiteboard, where my handwriting makes Object and object very easy
> to confuse.
I accept the point, then. My handwriting is probably worse than
yours, which is a large reason I avoid writing code "freehand". ;-)
> > > I don't think that it is up to the compiler to force "natural
> > > looking" code; that is appropriate for an editor.
> >
> > Well, we disagree. Fair enough.
>
> The C standard enforces on very limited instance of coding
> standards; i.e. not having the same variable written in two
> different ways; it prevents a lot of other standards. For example,
> it isn't possible to write your keywords in uppercase, or with
> an initial uppercase letter.
This would be a feature of any language, however, if we look
outside the case for a moment. If you compare the way to write
"Hello World" to the screen in various languages, you'll instantly
note that there are always subtle differences in context. It's not
unreasonable to want a language where YOU specify what the command
to display "Hello World" looks like - and indeed you can, if you
create a function that does that and encapsulates the details away.
For example, you could create a standard include file with a bunch
of #defines to use uppercase keywords.
Although I must be honest - such a procedure is fraught with danger,
and really cannot be advised. I accept that this is a limitation
of case sensitive languages - albeit one that I don't find oppressive
(I tend to write Pascal with all lower case keywords, too).
> > > The problem I have is that case is used, as it should be, to make
> > > the text representation of a program more readable. This has, in
> > > case-sensitive languages (which AFAIK are only the C family, in
> > > the broad sense) a semantic effect.
>
> > Saying that the case-sensitive languages are "only the C family" is
> > like saying influenza only infects humans with "2 arms and 2 legs".
> > It's true, more or less, but since the C family comprises the
> > majority of programs, it's also misleading.
>
> The majority? I think that Basic, Fortran and Cobol still outnumber
> C/C++, Perl, Java, but I can't say for sure.
You may be correct. Would you accept, instead, that most NEW
development is done in the "C-family"? One COULD argue (I'm not
going to, though - see below) that this is a sign that case
sensitivity is an "improvement" on the "old" languages that didn't
have it.
> I agree that there is an awful lot of C family code around, but that
> isn't the point I was making - it is that thousands of people have
> set about designing programming languages and user interfaces and
> file systems, and only those that descend from the original
> BCPL source are case sensitive (AFAIK - I couldn't find the 100
> bottles of beer site to verify). You could, of course, argue that
> this proves what a good thing case sensitivity is, since it allowed
> C to prevail over everything else by Darwinian competition.
I don't think such an argument is particularly persuasive, though.
Similar arguments could be used to "prove" that Windows technology
is state of the art - popularity doesn't necessarily (or even
often) indicate technical superiority.
I'm hardly a "C-family" zealot; I admit I use (and like) Java and
Perl, and I'll use (and tolerate ;-) C or even C++. But they are
just tools; if another tool (Ada, for example) proves more useful,
I'll use that instead. Case sensitivity isn't really a religious
issue for me - I find its use in languages appropriate mostly
because it tends to be there "by default" in case insensitive
languages anyway, and there is something to be said for the idea
that ANYONE can pick up a C program, anywhere in the world, and
at least the keywords will be written the same. There may not be
MUCH to admire in such sentiment, of course...
I find it a little strange to have to work on Ada code from
someone who hasn't done it "my way" (for "my", read "my
company") - which is basically all capitals. I'm constantly
faced with a mad desire to "recasify" all the "wrong" code I'm
inspecting. I've never had this problem in C or Java (although
on occasion the variable identifiers people choose in C cause
me comparable problems - Sun's "universal Java coding standard"
has largely avoided this problem for Java).
> > Here's my basic issue: I think it's wrong to call something
> > "var1" in one place and refer to it as "VAR1" in another. Most
> > coding standards I've seen - for case insenstive languages such
> > as Ada - agree with me in this respect. They all enforce some
> > rule about what case to use for variables, class names, and so
> > forth.
>
> > If you're going to enforce such things ANYWAY, why not let the
> > compiler check it for you? Why not make it an error to NOT do
> > it, since (by the coding standard) it SHOULD be an error.
>
> I would love to have such an option in my Delphi compiler - "Ensure
> all tokens use same case Y/N", with an option to auto-convert.
>
> I don't think this should be enforced at the cost of limiting the
> coding standards to lower case only keywords, though.
I now find myself in a somewhat uncomfortable position, which is
not uncommon for someone who likes Java ("Use 100% Pure Java! Avoid
Third Party Non-Standard Stuff!") and Perl ("There's more than one
way to do it"). The issue here is "how much freedom should a
programmer have?" Do we go the "Java" route ("Use Sun's coding
standard; enforce universal look for Java programs all around the
world") or the "Perl" route? (which is ironic, since Perl is
certainly case sensitive, but in all other ways they have bent over
backwards to allow a large amount of freedom; the Perl style guide
is, at best, a series of "suggestions" and there are LOTS of ways
to do any given Perl task).
My personal take here is to try for the best of both worlds (IMHO).
The keywords and so forth of a language should have only one legal
representation (including case), but the language should NOT try
to enforce any other paradigms except where absolutely necessary.
It wouldn't be too difficult to write a Java preprocessor that
could take "DelphiJava" code (that is, case insensitive Java) and
spit out "Pure" Java to the compiler. So you could, if you wished,
still have case insensitivity for development purposes. This is a
(primitive) form of Roedy's SCID idea, where the representation of
code for a programmer is tailored completely to that programmer's
desires.
But in such a case you still need an underlying "standard" for
communicating ideas and printing code samples in magazines; I
suggest that this "underlying" code should be in a case sensitive
language and (ideally) even go so far as to enforce the "coding
standards" by making other possibilities syntactically illegal.
(I've never understood why, if Sun was prepared to say that all
class identifiers should start with a capital letter, they didn't
go right ahead and make class identifiers that started with a
lower case letter or an underscore illegal. Sounds to me like
they lacked the strength of their convictions, or perhaps that was
just too "anti-C" for them).
> > Programs are not normal text. It is difficult to see why they should
> > therefore be judged by such a standard.
>
> They are made up from text, and
Did your point get trimmed here?
Programs do have a certain amount of text in them, but they
also have a lot more of what closely resembles mathematical
symbols. I don't really think they can be regarded as "human
readable" unless the said human is an "expert" - ie, a programmer
who understands the language or a similar language. I don't
believe that we've really got the "language for the masses" yet.
If you look at a lot of personal Web pages, you'll see the same
Javascript (right down to logic errors) appear over and over
again - the cut-and-paste method of homepage creation is by far
the dominant paradigm, even with a simple language like Javascript.
(snip!)
> > As an analogy of the differences between your position and mine,
> > let us pretend that instead of a computer we have someone who
> > speaks only Russian, and we speak only English. Your approach is
> > to teach him English. My approach is to learn Russian.
>
> > Now, let's say that this person wasn't playing with a full deck,
> > if one forgives the euphemism. Computers, as a rule, are not
> > particularly bright. It's a lot easier for us to learn their
> > language than for them to learn ours.
>
> I would agree with this as a general rule. Case conversion, however,
> is something that the dumbest computer can do efficiently and easily.
True enough, I suppose. I do think that case-sensitivity does make
programs easier to read for humans, too, though - although I'd
have to confess that this may not be the case for a novice. Maybe
you're just a lot better than me (or a lot more tolerant than me)
at remembering "Bar is the same as bar" when reading Delphi or
Pascal code. Perhaps it's my laziness we're seeing here. ;-)
> There are plenty of both types of system out there; I don't think
> that computers run faster for being case sensitive. It is a matter
> of whether case sensitive systems are more appropriate for us.
I'd certainly agree that it's not a speed issue. It does seem to me,
though, that given you find case insensitivity more appropriate and
I find the reverse, that we have come up with more support for
Roedy's SCID idea. We could both have what we want, in such a case.
(snip!)
> > What's the problem? You're talking about possible spelling errors
> > to retrieve files, not create them.
>
> I am giving an example that I have experienced with Xemacs - if you
> do a Save As into another directory, you have to re-enter the name.
> If you want to find the file, you have to give a portion of the
> name. Even the most graphical of interfaces to a file system
> requires some typing at some stage.
For locating files, I suppose you are correct. The common case,
though, is where you know exactly where a file is and can simply
navigate the directory structure with mouse clicks. Here, there
really isn't any difference between case sensitive and insensitive
files (unless you count the order that they sort in; you could
make that case insensitive, if you prefer. Many people probably
would, at that).
> > > Just saying "use a GUI" hides the problem. Suppose you are
> > > opening a file in a directory with hundreds of different files?
> > > You remember that it has a name like myFilesomething - in a case
> > > sensitive system that is no help.
>
> > And what if all I remembered was that it was called "Filesomething"?
> > I forgot about the "my" part?
>
> Well, you're screwed. I am working on the basis that you can usually
> remember the start of a filename.
Your point basically being that "something is better than nothing",
right? Hmm. There's a certain amount of sense to that idea, I have
to admit.
> > > I don't believe that shells or GUI's should lie to me.
>
> > ??? What are you talking about? They DON'T lie to you. Nobody was
> > suggesting that they did.
>
> If a GUI implemented a case-insensitive interface to a case-sensitive
> file-system, it would be a lie, and it would catch you out sooner or
> later.
It's possible. But I confidently state that I think it could be
avoided. Mostly, all you have to do is default to the proper case
if there is ever a "clash" (ie two or more files that differ only
in case).
> > You've completely misunderstood me here.
>
> > I understood you to be complaining that you often mistyped
> > "myFilename" when you meant "MyFilename". My reply was that, if
> > you use a GUI (and therefore aren't typing EITHER) this mistake
> > doesn't happen. You seem to have construed this as me implying
> > that the GUI would misrepresent the case of the files; that wasn't
> > my point at all.
>
> My point is that even with a GUI, you need to type the names
> sometimes, or portions of them.
I see; of course, a GUI could happily try case insensitive matches
if the case sensitive match failed. But I understand that you think
such an approach could trip up eventually (I disagree, but I do
acknowledge such an interface would have to be carefully written).
> What I would _really_ like is a more sophisticated approach to data
> retrieval, where the nested directory/file/data is no longer
> relevant.
An interesting idea. What sort of features would such an approach
have?
(snip!)
> > So you're saying that if I want to create files with arbitrary
> > extensions, I have to create them with some editor that will name
> > them ".txt" and then later manually remain the files? Or am I not
> > supposed to be able to think of any extensions that weren't "in
> > the box"? Even DOS based systems don't "know" the extension of your
> > file; at best, they have a default.
>
> I think that file typing should be user definable, and it should be
> an actual file attribute.
Here I am in complete agreement. The name of the file should not
have anything to do with its type (and the extension IS part of the
name of the file, IMHO).
But I could probably argue the reverse, too. Playing Devil's
Advocate for a moment, I can make a pretty good guess by scanning
the program directory for a newly installed DOS application as
to which program I should try and execute by examing all the .EXE
files; it's not as intuitively obvious in Unix (although it is
rarely a problem; Unix programs generally come with reasonable
documentation for this sort of thing).
> I haven't solved this particular problem totally, but
> designing the best ever computer system from scratch is a big job.
> I think that file extensions, on UNIX and DOS, were an attempt to
> define file type - now I think that these types should be an
> inherent property of the file itself, not its name.
I agree. I'd even go so far as to say that DOS had it slightly
better, because at least some extensions were system defined
(.COM, .EXE, .BAT) whereas with Unix everyone could have their
own standards. On both DOS and UNIX systems, I've seen .dat files
used for either binary or text data files, and there's no way without
inspecting them that you can tell by looking.
However, such a system as you propose would require file types to
be user definable - there would need to be some sorts of guidelines,
and I'm really not convinced that it would necessarily solve the
problem. (You'd have the same people just make their files of type
"data", which still doesn't tell me whether this is something I
can read in vi or not).
(snip!)
> > Then you aren't looking very hard. What do you have, Programming
> > Perl? I just flicked mine open at random; try page 514. Better yet,
> > perldoc perlstyle.
>
> > In general:
>
> > - File handles are all uppercase by convention
> > - Package names have their first letter uppercase by convention
> > - Local variables are all lower case by convention
>
> > Frankly, if you're actually being honest here, you have a pretty
> > bad Perl book.
>
> I will accept that restrained rebuke.
Fair enough. ;-)
> I note that if all local variables are lower case by default, and
> all the language keywords and built-in functions are lower case, you
> end up with mostly lower case.
Sure. Which makes the uses of uppercase have more "jump out and
bite you" significance, and such things (user defined functions,
most commonly) are usually the parts that you will want to be
made aware of.
> > So what you're saying is that even case-insensitive language tend
> > to use a single kind of case? I don't see how this supports your
> > argument.
>
> It doesn't, but give me credit for intellectual honesty.
Oh, certainly. With the exception of that Perl remark (which I'm
prepared to accept might simply have been a bad Perl book - they're
out there), you've been scruplously honest. Gives your points a lot
more validity; a zealot would refuse to acknowledge ANY deficiencies
in case insensitivity, whereas all you're doing is saying that, on
balance, the advantages outweigh the disadvantages. I can certainly
disagree with you, but your attitude does engender a lot of respect
for your position. Note that I'm not advocating you shouldn't be
able to have what you want; I am (at best) trying to see how we can
BOTH have what we want. ;-)
> It would be trivial to print keywords in lower case, but a different
> font, even when they are entered in upper case or mixed case. I
> will check some of the more esoteric languages when I can find the
> books.
Certainly; if an IDE can instantly translate keywords to a different
colour, it can certainly change their case.
> > I hope you weren't intending that statement to be self evident in
> > meaning. I've personally seen readable programs in all three
> > languages, but I've never seen mixing case irresponsibly to be a
> > particularly valuable feature in this respect. If I name an
> > identifier "bar", then I expect a reference to "Bar" to be rejected.
>
> Just that I have found that the comparitive verbosity of Pascal
> tends to encourage more readable code. YMMV.
There are arguments for and against verbosity. (I should know; I
end up hearing most of them from both sides. Perl is a very terse
language; Java - compared to Smalltalk, say - is quite verbose).
Let me simply say that terse languages allow you to see a lot more
of the code at one time, which CAN - in some circumstances -
outweigh the (acknowledged) fact that they are more cryptic. At
the cost of a little more "translation", you save yourself some
page flipping. Sometimes the tradeoff is a good one, other times
it is not.
The biggest problem with Pascal is that ANSI Pascal can't really
do very much (by all means correct me if this has changed; I haven't
touched Pascal since Uni). IIRC, even:
program test(input, output)
is not legal in ANSI Pascal (or at least doesn't do what it does
in Borland Pascal, which is to say you're using stdin and stdout).
It's a great teaching language, but it needs extensions (such as
Borland Pascal - oh, sorry, that would be Inprise now, wouldn't it?)
to be really useful.
I've heard great things about Delphi, though.
> > If I'm reading a program and I see:
>
> > var bar:integer;
>
> > Bar := 54;
>
> > then my immediate impulse is to start looking for where Bar was
> > defined. Which is why that sort of thing is discouraged even where
> > it is syntactically legal.
>
> It should deserve a smack on the wrist, at least. I would not
> object to
>
> Var bar: Integer;
>
> or
>
> VAR bar: Integer
>
> which I think is more readable.
I wouldn't mind any of the above, IF it HAD to be that way. I'm
not enamoured of caseless reserved words - but I suppose that's
a fundamental difference we have (I like "universal" coding
standards, where as you seem to prefer to allow each individual -
or company - to decide upon their own. And I would have to say
that your position is probably going to be more popular than
mine with certain groups - Perl programmers, for example).
> Perhaps the ideal would be for the compiler to prohibit defining
> different variables purely by case differences, but to also demand
> that the same case be used throughout. Is this an original concept?
In what way is that not the same as making variables case sensitive?
Or are you suggesting that the case sensitivity ought to be applied
only to variables, and not to reserved words?
> I am generally in favour of languages being as strict as possible -
> for example, I think that the Occam use of indentation to indicate
> scope is an excellent idea.
I've not used Occam; that does sound like an interesting idea.
I do not like the Python method of inferring block structure from
indentation, though - I'm not sure if that's similar to what
Occam does.
> > Err... what about languages where the difference between a constant
> > and a variable is one that is not intuitively obvious to the editor?
> > Not all languages have a "const" keyword; and besides, you can never
> > have too many visual clues.
>
> Why do you need to know that something is constant?
In general, for things like initialization and reinitialization
functions. For example, a common theme in much of my Java code is
to have something like the following at the top of the class:
class Example {
public static final int DEFAULT_ITERATIONS = 20;
public static final String DEFAULT_NAME = "Example";
private int iterations = DEFAULT_ITERATIONS;
private String name = DEFAULT_NAME;
}
It's possible for the user to alter some of these variables, and
if they do so, and later decide to revert to the default, it's
nice to know that the default values are constants.
But outside of that situation (which is not always even necessary,
I'll admit, and even when it is can be done in different ways), I
suppose you don't really need to know.
> Seriously - one of the nice things in Pascal is that you can
> substitute a function for a variable and just not care about it.
> (Yes, this can be abused horrifically).
You'll find advocates on both sides for that one. And I couldn't
honestly say what my preference is - on occasion, I think it's
nice to know a function/method is being called. On other occasions
(accessor methods are a case in point) I would agree that it's
nice to have no distinction.
> > And what if we have to print our sourcecode on a black & white
> > printer?
>
> If you really need to know, use the typographic convention.
The point being that sometimes the IDE supplier may not have made
an "appropriate" choice for me - if they use colour coding for
their source code, and I have a black and white printer, then I
need to have my own means of distinguishing reserved words from
variables (for example).
But that's rather pedantic of me - I would imagine most IDEs
have already solved these sorts of problems.
> > You've missed the point. The point is - I don't consider that it IS
> > a problem.
>
> > "That's the way (uh huh uh huh) I like it (uh huh uh huh)".
>
> > And since you can have it the way YOU want it as well in Unix, why
> > would you try to stop me having it the way I want it?
>
> I don't think that Unix really lets you operate in a
> case-insensitive fashion, GUI or not.
I think (I'm no expert on Unix shells) that it would be possible
to write a shell that gave you case insensitive access to files.
I can't think of any reason it wouldn't be possible.
It won't help you with C or Java, of course, but they aren't
"problems" just for Unix.
(Indeed, the question must arise as to why nobody has already
written such a shell. Either nobody using Unix likes case
insensitive file matching - unlikely - or that such a shell
DOES already exist, and I'm just not aware of it).
> > > My Unix shell does exactly that. It's horrible. My point is that
> > > words in English have a correct spelling.
>
> > Debatable. How does one spell "gaol"? "Colour"? "Theatre"?
>
> > To any American reader, the above line contains 3 spelling errors.
>
> Only if they are keywords (predefined perts of the language). User
> defined names (like GAZZA) are only required to be consistent for
> all usages - you could say Gazza and that would be OK, but Gaza
> would be a mistake.
Well, yes.
However (slight tangent) I hate the way Americans force their
terrible version of English on the rest of us. Every time I have
to type in java.awt.Color, it still looks like a mistake.
Oh, you can fight it. I did, for a while. I called my variables
things like:
Color textColour, bgColour;
But it's insidious. When you initialize them, you still have to
go with:
textColour = Color.white;
bgColour = Color.black;
Sooner or later, it starts to look as if textColour and bgColour
are spelled wrongly, and the strongest of us eventually bites the
bullet and changes them to textColor and bgColor. Horrible, the
sacrifices demanded of us. ;-)
Why can't we have editors that go beyond mere case insensitivity,
and spellcheck our code for us? That way, I can have an "English"
version of the Java standard libraries, where Colour and
synchronise are spelt correctly?
I'm half joking here, but it IS annoying.
(snip!)
> > And I believe you're incorrect. It's certainly possible to have a
> > shell that ignores case sensitivity.
>
> But then if you have two files whose names differ only in case -
> which can happen - your GUI is in a pickle.
It needs to be considered, obviously. Not too hard, though -
you search for an exact match first, and then (and ONLY then)
try a case insensitive search. So if you had:
MyFileName
myFilename
MyFilename
(an extreme case), and typed in "myFile" you'd get "myFilename"
(since that would exactly match the first part), and if you typed
"myfile" you'd get "MyFileName" (no exact match, so just return
the first one that matched it imprecisely). Whether or not this
becomes a problem (maybe you wanted "myFilename" in such a case)
depends on how common the "filename clashes" are.
You could also have the shell check to see if you're about to
create a file that differs only in terms of case, and prompt to
see if that's really what you want to do.
(Maybe the shell isn't the right place for that, though; a Unix
expert would be a better person to ask).
--
Cheers,
GAZZA
------------------------------
From: "Kevin" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.setup
Subject: Newbie--3c509b can't recognize
Date: Sun, 18 Apr 1999 22:20:14 -0500
Reply-To: "Kevin" <[EMAIL PROTECTED]>
I can't get linux to find or recognize my ethernet card it's a 3c509b.
It works fine in NT but I've tried to get it to go in Xwindows, no luck.
I've redone the kernel and made sure it was enabled--nothing. When I go to
ifconfig eth0 says it's not a device. It's listed as supported? I'm using
redhat 5.2. Tthe book I'm using the guy is using the same card as reference.
Please help. Email replies please to [EMAIL PROTECTED]
Thanks
Kevin
------------------------------
From: "Tony" <[EMAIL PROTECTED]>
Subject: Creative Banshee pci
Date: Mon, 19 Apr 1999 18:21:23 +1000
I am using Red Hat 5.1 and recently bought a creative labs banshee card.
Since that, i am not able to start my xserver (KDE).
Can you help me?
------------------------------
From: "Nostril Of Happiness" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.linux.setup
Subject: Re: Programmers are gods
Date: Sun, 18 Apr 1999 20:49:25 -0700
>Try a cross platform port of engineer fortran (different from IT fortran)
>every index variable is 'i' the number of times 'i' is repeated is the
>depth in imbeded if's or loops. ie:
>if (i)
> if(ii)
> endif
>ednif
That looks like my code. Stop sharing my secrets in public.... Who are you??
Yes, comments are for wimps. They should never be used.....
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
