On 9 Jan 2002 at 14:48, Robert C Wittig wrote:
>> I have found that very large and/or complex tables can make a
>browser
>> crash.  If you're using an OS with little protection against
>> applications faults, then it can make the system crash, too.
>
>Might this be a function of insufficient memory, if the whole
>system goes down? I have never had it happen to me, but the
>tables on my own site are not all that complex, just 20 clickable
>images, nested in floating grids.

I think it's primarily a bowser fault.  Just not designed to deal with
tables with thousands of elements.  (Yes, I once found such a page; I
eventually used Lynx to verify that the page was actually one large
table, with lots and lots of formatting.  My guess is that it was
produced by some GUI WYSIWYG editor.  Note: you can use Lynx with
the -dump option on the command line, and it will output the raw
page to stdout, which can then be redirected to a file.  Very handy for
fetching the raw source of pages.)

>> Unfortunately, with the C language, to use the "gun" analogy,
>it's all
>> too easy to shoot one's self in the foot with a gun that's in
>perfect
>> working order.  Of course, the "C compiler" gun was
>deliberately
>> designed without a safety, in order to make firing it just that
>extra
>> second quicker, and uses a very large bullet, so that it does
>extra
>> damage.   Trade-offs in language and compiler design are the
>things
>> that college professors get lots of books out of.
>
>To tell the truth, my only 'C' compiler is the stock cc Unix
>compiler. For Win/DOS I have C++ compilers, which will process
>'C' style code, as long as I remember to  make C++ type
>declarations. In another weeks or so, I will have in my
>possession an old 'Borland Turbo C' compiler, and also a 1985
>'Lattice C Compiler', with complete documentation, so I finally
>be able to see what it is like, to compile 'C' with its own
>non-C++ compiler, and a set of pure 'C' rules. Should be
>interesting.

Well... I don't think you'll see much difference.  I still have my
Lattice C compiler, of about that vintage; the biggest difference is
that the compiler doesn't have all the bells and whistles that newer
ones have.  It's about like using "cc" in UNIX, but without as many
debug tools.

>> If you want a "safe" language, best look at Pascal or LISP or
>Logo. :-)
>
>I have Pascal, but have not had time to mess with it yet, my
>plate is too full, with just C/C++ and Assembler.

I might recommend leafing through a book on Pascal, just to note the
differences.  You might try your local library for the book; I've found
that many small town libraries have a computer section in their stacks
which has a few general books on computing, two or three on BASIC, and
one or two on Pascal.  All these books were acquired back in the early
to mid 80's, in my usual experience.  Sometimes, you can find some
treasures, too, like operating manuals for that Atari computer you've
got sitting in the closet. :-)

>> That's exactly what new compilers and assemblers are for - for
>finding
>> new an interesting ways to make your box bomb out! :-)
>
>I have been told repeatedly by experienced programmers, and my
>experience tends to bear it out, that one of the best ways to
>learn programming, is to first type in the example the way it is
>supposed to be... letter perfect, and after it is compiled, and
>proved to run, to start 'breaking' the code in various ways, just
>to see what happens, and what sort of errors it 'breaks' produce.
>Without this technique, I don't think I would have ever gained
>any sort of grasp on using pointers... none of the books I have
>read (or all of them combined) really gives a crystal clear
>explanation of their practical application. By seeing what
>doesn't work, and what does work, I at least get a better 'map of
>the territory'.

*nod*  Yep, this is a good way to go at it.  Especially in C/C++, where
pointers are very, very important.  Other languages don't often use
pointers in the same ways - their use is hidden under an abstraction
layer.

Anthony J. Albert
===========================================================
Anthony J. Albert                     [EMAIL PROTECTED]
Systems and Software Support Specialist          Postmaster
Computer Services - University of Maine, Presque Isle
"To know is one thing; merely to believe one knows is another.
 To know is science, but merely to believe one knows is ignorance."
        - Hippocrates, ~400 B.C.

To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with 
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html

Reply via email to