HDTenEightyP/NetNews huggingface dataset:
From: cek@sdc.boeing.com (Conrad Kimball)
Newsgroups: comp.programming
Subject: Re: When should a debugger be used?
Date: 18 Aug 92 23:44:08 GMT
Organization: Boeing Computer Services, Seattle, WA

|> >4.  Divide-and-conquer when things go wrong by adding some output somewhere
|> >    (usually an fprintf() added at a strategic spot).

And what do you do when the problem goes away when you add the fprintf()?
I've had that happen.  A bad pointer leading to trashed memory, and
inserting more code moves things around so the trashed memory no longer
causes the program to fail...

--
Conrad Kimball		| Unix Server Tech Services, Boeing Computer Services
cek@sdc.boeing.com	| P.O. Box 24346, MS 7A-35
(206) 865-6410		| Seattle, WA  98124-0346
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: When should a debugger be used?
Organization: /etc/organization
Date: Wed, 12 Aug 1992 23:39:04 GMT

If I have a debugger available I will try it first before I go the
"add debugging printf and recompile" route.  I will even go to some
effort to maintain a "simulated" environment where I can run a debugger
if I don't have a debugger in the actual target environment.

I prefer to use a debuggers.

However, I am intrigued by the following statement.

In article <164c9vINNijk@agate.berkeley.edu> lippin@math.berkeley.edu writes:
>
>Some bugs (e.g., memory leaks) are very nearly intractable without
>debugging tools, simply because they show few visible symptoms in
>ordinary test conditions.
>

Memory leaks are one of the areas where I have found debuggers to be
very little use.  I do use it to examine the free memory list, and say
to myself "this look suspiciously large", but that just tells me there
MIGHT be a leak.  Finding the actual is has always been more of
an analysis problem.

What features are in your debuggers that allow you to tract memory
leaks?
From: dansmith@Autodesk.COM (Daniel Smith)
Newsgroups: comp.programming
Subject: Re: what skills does a programmer need
Date: 18 Aug 92 00:22:47 GMT
Organization: Autodesk Inc., Sausalito CA, USA

In <1992Aug17.155545.15339@uwm.edu> markh@csd4.csd.uwm.edu (Hunk) writes:

> Learning: the ability to master anything in a short time when required.
> Coding:   the ability to write code that is clear and concise.

	also Attitude: knowing that just because you've got a degree, that
doesn't mean you can rest on your laurels and stop learning.  Keep an open
mind.

	Motivation: I've run into too many "programmers" who just got
into the field because it's somewhat financially lucrative, and who do not
stay current and think it's too nerdy to ever talk tech.  The "just enough
to get by" quality of their code can harm the progress and perceptions of
the software industry.  If you're only interested in money, at least be honest
about it and become a stockbroker.

	Idealism mode off :-)

				Daniel
-- 
            dansmith@autodesk.com            dansmith@well.sf.ca.us
        Daniel Smith, Autodesk, Sausalito, California, (415) 332-2344 x 2580
              Disclaimer: written by a highly caffeinated mammal
 $|=1;for("..."," hacker"," perl"," a","just"){print $l=$_.$l,"\015";sleep 1;}
Newsgroups: comp.programming
From: jcook@brazil.cs.colorado.edu (Jonathan Cook)
Subject: Re: A LITTLE BRAINTEASER... (The REAL solution!)
Organization: Universtiy of Colorado, Boulder
Date: Fri, 14 Aug 1992 02:15:37 GMT

In keeping within the spirit of the original post, only one local
variable used - but I did add argc and argv, and only a recursive
main. You might call this cheating, but run it . . .



int main(argc, argv)
int argc; int *argv;
{
   int c;
   c = getchar();
   if (c == EOF) return(0);
   if (c != '\n')
   {
       main(argc+1,&c);
   }
   else
   {
       main(1,NULL);
       c = ((int) (&c - argv));
       argv -= c * (argc-2);
       while (argv != &c)
       {
	   putchar(*argv);
	   argv += c;
       }
       putchar('\n');
   }
   return(0);
}

Newsgroups: comp.programming
From: mjn@pseudo.uucp (Murray Nesbitt)
Subject: Re: Teaching the basics
Organization: Private system in Toronto, ON
Date: Sun, 23 Aug 1992 11:19:41 GMT


markh@csd4.csd.uwm.edu (Hunk) writes:

>In article <14066@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>If you don't know recursion, you don't know programming.  It is one of the
>>simpler concepts in computing.  (Much simpler than mutable variables, IMHO.)
>
>I think recursion is a farce.  And just to rub it in, here's the Towers of
>Hanoi (up to N = 31, I'm assuming long integers are 32 bits) without it (in C)

You are joking, right?  If not, I don't see how your example Hanoi
program strengthens your position that recursion is a ``farce''.

>/* Move a stack of N objects from tower A to C, using B */
>void Hanoi(int N, char A, char B, char C) {
>   unsigned long X = 0; char D;
>HANOI:
>   if (N > 0) {
>      D = B, B = C, C = D, N--;
>      X = 2*X + 2; goto HANOI; X2: X = (X - 1)/2;
>      N++, D = B, B = C, C = D;
>      printf("Move %d from %c to %c.\n", N, A, C);
>      D = A, A = B, B = D, N--;
>      X = 2*X + 1; goto HANOI; X1: X = (X - 1)/2;
>      N++, D = A, A = B, B = D;
>   }
>   if (X&1) goto X1;
>   if (X > 0) goto X2;
>}

An equivalent recursive version:

void Hanoi( int n, char start, char temp, char dest )
{
    if ( n ) {
        Hanoi( n - 1, start, dest, temp );
        printf( "Move %d from %c to %c.\n", n, start, dest );
        Hanoi( n - 1, temp, start, dest );
    }
}

Beauty is in the eye of the beholder, but in my opinion the recursive
version is a little easier to follow, to say the least.

On my system, both the native C compiler and gcc with optimization off
produce faster executables for the recursive version (although gcc -O
produces a faster iterative executable; strangely enough, gcc -O
actually slows down the recursive version).

On top of it all, the recursive version does not have an arbitrary
limit on the number of disks, and can be easily translated to any
language supporting recursion.

For some problems, it may be necessary to avoid (or reduce) recursion
in the interest of execution time.  But generally, if a recursive
solution to a problem is obvious, as is the case with Towers of Hanoi
(or binary tree traversal, etc.), it should be coded recursively.  The
clarity and elegance of a recursive solution will usually outweigh the
(possible) performance penalty.

-- 
Murray
Newsgroups: comp.programming
Subject: Teaching the basics
From: peregrin@husc13.harvard.edu
Date: 17 Aug 92 12:39:15 EDT
Organization: Harvard Business School

Hi,
	I help teach the intro to programming course here at H.U.'s night
school, and before the fall semester starts I am wondering what basic
programming skills you all think really need to be worked on at the
introductory level?
	This course is meant to teach students the basics.  Even though it
is in C, we don't really touch on pointers, and the fanciest thing we teach
is recursion (which most don't get anyways).
	So if you look around at your fellow programming peers (perhaps the
the entry level ones), what basic skills do you wish they were better prepared
in?  Documenting?  Indentation? top-down problem solving? Debugging? Numeric
methods?  Better understanding of hardware (cpu, terminal i/o)? Efficiency?
Engineering skills ? (like kludging vs. recoding; writing code so that it
can be maintained in the future; time management; reliability; human
interfaces?)

	Basically, I'm giving you all the oportunity to tell a programming
teacher what to better prepare students with.

Thanks,
James
+----------------------------------------------------------------------------+
| James Peregrino                        |       peregrin@hbsstg.harvard.edu |
| Programmer/Analyst                     |       PEREGRIN@HULAW1.BITNET      | 
| Science & Technology Interest Group    +-----------------------------------+
| Harvard Business School                | "Renovations Underway,            |
| Boston, MA 02163                       |  Thank You for Your Patience.     |
| Voice:(617)495-6307 FAX:(617)495-0351  |  Will Reopen Soon."               |
+----------------------------------------------------------------------------+
From: sammy@anagld.analytics.com (Sam Blackburn)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 21 Aug 92 00:47:18 GMT
Organization: Computer Sciences Corporation - Systems Engineering Division

mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:

>In article <13226@bnr-rsc.UUCP> sdms@bnr.ca (Andrew Sterian) writes:

>I've heard this said with quite a bit of frequency lately, but it
>isn't true.  C compilers---even ANSI ones---don't do type
>checking across separately compiled files.  If I put the function
>prototype

>        int f(double);

>in one file and call f(3.14), the compiler is happy.  If I
>then put the function

>        int f(int, char *) {... }

>in another file, the compiler won't complain about that either.
>And I don't know of any C linkers that will complain.  If the
>programmer is lucky, the program will dump core; if not, who knows
>what may happen?

>It is true that if you use a certain amount of discipline and make
>sure that the same prototype appears in both places---by putting it in
>an include file---the compiler will detect the error.  The problem is,
>there isn't any enforcement of this policy.

Ahhh, here's where coding standards come into play.  However, if you
declare the functions as static then you shouldn't have a problem.

We could start a thread about coding standards, that'll get the flame throwers
going. :-)


                                                               o
Sam Blackburn                                                    \
Internet:   sammy@sed.csc.com                                  \O/
Compuserve: 76300,326                     ||====================|====||
GEnie:      SAMMY                         ||-+-+-+-+-+-+-+-+-+-/\+-+-||
                                          ||===================\=\===||
                                          ||                         ||
                                          || Kill or be killed.      ||
Newsgroups: comp.programming
From: turkel@unixg.ubc.ca (Bill Turkel)
Subject: Teaching the basics
Originator: turkel@unixg.ubc.ca
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Fri, 21 Aug 1992 17:33:00 GMT


IMHO the most important thing a *programmer* must have (as opposed to, say
a *software engineer* or a *computer scientist*) is a highly refined
_aesthetics_.  This is the trait that I most admire in my peers and masters,
but which is totally absent from so many who do it because it is a job, and
not because it is a passion.

IMHO a lack of aesthetics leads to atrocities like 1) paying for code by the
line 2) calling programmers "technicians", and claiming that they will be
replaced by software tools real-soon-now 3) quantifying "productivity" 4)
the cut-and-paste mentality -- copy a subroutine _n_ times and change a
variable name in each copy...

Anyway (hopping off soapbox) you know what I mean.

Bill
turkel@unixg.ubc.ca
Newsgroups: comp.programming,alt.msdos.programmer,comp.sys.ibm.pc.programmer,comp.unix.programmer
From: hanso@research.ptt.nl (Otten H.A.H.)
Subject: >How can I get more info on LALR ?
Keywords: LALR
Organization: PTT Research
Date: Wed, 19 Aug 1992 13:07:27 GMT

Can anybody out there tell me more about a program called LALR by LALR
Research? It was suggested to me as an alternative to YACC/LEX. All I know is
that it runs in an MsDos environment (and I'm working in a Unix environment
with input files of 1 Mbyte on average (don't you just hate those
program-generated sources?)).

The project I'm working on involves a translator from one high-level language
to another. However, conflicts in one domain (the action part) have to be
resolved in another (the type-declaration part), and I'm not sure if LALR can
cope.

Thanks,
  Hans.

E-mail : H.A.H.Otten@research.ptt.nl (Hans Otten)


-- 
Groetjes van hans...
Newsgroups: comp.programming
From: erf@progress.COM (Eric Feigenson)
Subject: Detecting Integer Overflow/Underflow
Reply-To: erf@progress.com
Organization: Progress Software Corp.
Date: Fri, 21 Aug 1992 18:22:06 GMT

I'm sure this is a solved problem, I just haven't been able to solve
it :-)

Given: Two numbers (integers) of the same bit-width (e.g., they're
both stored as 16-bit integers), and writing in "C" (with no access to
the assembly language of the machine; it must be portable!) is it
possible to write code to detect whether the result of adding,
substracting or multiplying the two numbers will result in overflow or
underflow?  The detection can be done either before or after the
operation.  It should, of course, be as efficient as possible, but any
solutions are welcome.

Thanks in advance for any and all suggestions!

-EricF

--
Eric R. Feigenson			UUCP: {mit-eddie,linus}!progress!erf
Progress Software Corp.		    Internet: erf@progress.com
14 Oak Park			  DISCLAIMER: I don't speak for my employer,
Bedford, MA  01730		              and vice versa.
-- 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Kyle Tucker - Email Administrator  | 		Progress Software Corporation
tucker@bedford.progress.com 	   |		14 Oak Park
Newsgroups: comp.programming,comp.realtime
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Fitting a gaussian curve to data
Keywords: fit,gaussian,normal
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 17 Aug 92 11:59:05 GMT

rmal@jet.uk (Richard Lucock) writes:

>Hi,
>	I am looking for a routine (code or algorithm) to fit a
>gausian curve to data. I can do this easily using a least squares
>minimisation routine (from the Nag library in fact), but it is too
>slow (this is for a realtime application, hence the crossposting), so
>I am trying to find something faster.

Have you tried the simple-minded approach of calculating mean
and variance of your data and using them as parameters to your
gaussian? BTW, doing this numerically stable is also discussed in
Seminumerical Algorithms, Vol. 2 of The Art of Computer Programming
by Knuth.
Newsgroups: comp.programming
From: markh@csd4.csd.uwm.edu (Hunk)
Subject: Re: what skills does a programmer need
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Wed, 19 Aug 1992 14:48:22 GMT

In article <1992Aug19.014720.26150@fulcrum.oz.au> steve@fulcrum.oz.au (Steve Taylor) writes:
>In <17498@autodesk.COM> dansmith@Autodesk.COM (Daniel Smith) writes:
>
>>In <1992Aug17.155545.15339@uwm.edu> markh@csd4.csd.uwm.edu (Hunk) writes:
>
>>> Learning: the ability to master anything in a short time when required.
>>> Coding:   the ability to write code that is clear and concise.
>
>>	also Attitude: knowing that just because you've got a degree, that
>>doesn't mean you can rest on your laurels and stop learning.  Keep an open
>>mind.
>
>>	Motivation: I've run into too many "programmers" who just got
>
>Organisation: Programming is not really hard per se. - writing a small
>program is something almost anyone can do. Writing an extremely large
>program is something almost no one can do well.

Therefore it behooves us to make large programs small.  And that gets us back
to the clarity and conciseness criterion.
Newsgroups: comp.programming
From: slin@cisco.com (Steven Lin)
Subject: Books on RCS?
Organization: cisco Systems, Menlo Park, California, USA
Distribution: usa
Date: Thu, 13 Aug 1992 21:35:31 GMT


Can anyone provide some references to books on RCS (Revision Control System)?

Replies via e-mail, if possible.
From: brnstnd@nyu.edu (Dan Bernstein)
Newsgroups: comp.programming
Subject: --- comp.programming charter: read before you post (weekly notice)
Date: 23 Aug 92 04:00:11 GMT
Organization: IR

comp.programming	Programming issues that transcend languages and OSs.

It is a matter of courtesy to read a USENET group for at least a month
before posting anything to it. You should be familiar with this article
and with all the regular announcements in news.announce.newusers. A
newsgroup is like a crowded meeting hall filled with people who want to
talk about similar subjects. Chances are that if you just stick your
head in and shout, you'll be saying something totally inappropriate or
asking a question which someone else asked last week, and everyone will
be angry at you. To avoid this, _read_ before you post.

What you _should_ post here (the charter):

	comp.programming is an unmoderated group for discussions of
	programming issues which are not limited to a specific machine,
	operating system, or language: in particular, algorithms of all
	types. ``Programming issues'' means _practical_ programming
	issues: it is considered very bad form here to discuss issues
	with which you do not have direct programming experience.

What you _should not_ post here:

	Any issue which is limited to a specific machine, operating
	system, or language is completely inappropriate for this group.
	If you are programming under UNIX, use comp.unix.programmer. If
	you are programming a PC, use comp.os.msdos.programmer. If you
	are programming a Mac, use comp.sys.mac.programmer. If you are
	programming an Amiga, use comp.sys.amiga.programmer. If you are
	programming a game and think that your question is of interest
	to other game programmers, use rec.games.programmer. If you're
	absolutely sure that your question is on the use of the C
	language---it wouldn't make sense if you were using a different
	language---try comp.lang.c. If your question is a meta-question
	which has to do with features of various programming languages,
	use comp.lang.misc. If your question has to do with theoretical
	results which have to do with computer science rather than
	programming, try comp.theory. Finally, if you're sure that your
	question would make sense under a variety of operating systems,
	running on a variety of machines, and in a wide variety of
	programming languages, then comp.programming is probably right.

	Note added 3/9/92: If you want source code for something, you'll
	get better response in comp.sources.wanted, which was created to
	handle such requests.

Other comp.programming conventions:

	It's often difficult to talk about programming without quoting
	the results of that programming---i.e., code. There is nothing
	wrong with using a particular language to present code samples,
	as long as they _could_ have been expressed in various other
	languages. However, you are less likely to have your question
	understood if you illustrate it with a choice segment of APL
	than if you use pseudo-code, Algol, C, etc.

For future reference, comp.programming passed by a vote of 403-47. It
was created 3/1/92.

---Dan
From: black@seismo.CSS.GOV (Mike Black)
Newsgroups: comp.programming
Subject: Re: Detecting Integer Overflow/Underflow
Date: 23 Aug 92 12:36:17 GMT
Organization: Center for Seismic Studies, Arlington, VA

In article <1992Aug21.182206.15853@progress.com> erf@progress.com writes:
>
>Given: Two numbers (integers) of the same bit-width (e.g., they're
>both stored as 16-bit integers), and writing in "C" (with no access to
>the assembly language of the machine; it must be portable!) is it
>possible to write code to detect whether the result of adding,
>substracting or multiplying the two numbers will result in overflow or
>underflow?  The detection can be done either before or after the
>operation.  It should, of course, be as efficient as possible, but any
>solutions are welcome.
>

I already mailed a reply to this, but after seeing the postings thought
I should add it here:

Since the person wants a solution that is portable, in C, and addresses
addition, subtraction, and multiplication a solution is quite 
straightforward.  USE LONGS!  Simply caste the operands into longs,
perform the math, and check the answer.  If the answer is within 16-bit
limits (signed or unsigned) return the answer else set overflow.

#define MAXINT 32767
#define MININT -32768

int
add(short num1,short num2,short *sum)
{
    long lnum1,lnum2,lsum;
    lnum1 = num1;
    lnum2 = num2;
    lsum = num1 + num2;
    if (lsum > MAXINT || lsum < MININT) return -1;
    else {
        *sum = lsum;
        return 0;
    }
}

main()
{
    int overflow;
    short i,j,sum;
    for(i=1,j=1;;i*=2,j*=2) {
        overflow = add(i,j,&sum);
        printf("%d %d %d\n",overflow,i,j,sum);
        if (overflow) exit(0);
    }
}

The same logic works for subtration and multiplication, just change
the operator in the routine.
Mike...
-- 
-------------------------------------------------------------------------------
: usenet: black@beno.CSS.GOV   :  land line: 407-676-2923  : I want a computer:
: real home: Melbourne, FL     :  home line: 407-242-8619  : that does it all!:
-------------------------------------------------------------------------------
Newsgroups: comp.programming
Subject: Re: ANSI C, was Re: Teaching the basics
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sun, 23 Aug 1992 02:17:56 GMT
Organization: University of Auckland, New Zealand.

boyd@prl.dec.com (Boyd Roberts) writes:

>Prototypes are cheap hack, and they can lie, whereas the actual
>function declaration specifies it exactly.  The protypes just say that the
>calls agree with the prototypes, and that's not the same as the actual
>declaration.

>Putting extra info in the object would be a total win.  Why should I go to
>declare my functions twice, when the machine can do that stuff for me?

Prototypes are at least better than nothing, if you enforce their use.
ANSI-C really could not do much better without breaking all existing C
program up to that date. If you have declared your header dependencies
in your makefile correctly, you should not have any problem.

Actually, I like the Modula-2 concept much better: Put definitions
(declarations, in C usage) into separate files and let the compiler barf
if use or implementation (definition, in C usage) do not agree with
these. Finally, let the linker check wether the compiled definition and
implementation modules actually belong together. A pity Modula-2 does
not have either decent or portable I/O libraries...
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Newsgroups: comp.programming
Subject: Re: Teaching the basics
From: peregrin@husc13.harvard.edu
Date: 19 Aug 92 13:57:44 EDT
 <1992Aug18.190506.9935@cc.gatech.edu> <1992Aug18.230426.26425@lucid.com>
Organization: Harvard Business School

In article <1992Aug18.230426.26425@lucid.com>, johng@lucid.com (John Gregory) writes:
> 
> |> In article <1992Aug17.123916.14815@husc13.harvard.edu>
> |> peregrin@husc13.harvard.edu writes:
> |> 
> |> > [...] Basically, I'm giving you all the oportunity to tell a programming
> |> > teacher what to better prepare students with.
> |> 
> 
> Have them work on a *group* project and force them to deal with integration
> issues.  Not many people hack alone in the real world, and the one's who
> do are often painfully unaware of the problems of integration (no flames 
> please).
> 
> 

	This is done in later courses.  Should it be done in the introductory
course?

	The reason I started this thread in comp.programming instead of
comp.edu, was that I wanted feedback from programmers, not teachers of
programming.  I felt that programmers know best what skills they see lacking
in their peers.

	I've had lots of good responses and I will be summarizing soon.

But first, another post ...

-James
+----------------------------------------------------------------------------+
| James Peregrino                        |       peregrin@hbsstg.harvard.edu |
| Programmer/Analyst                     |       PEREGRIN@HULAW1.BITNET      | 
| Science & Technology Interest Group    +-----------------------------------+
| Harvard Business School                | "Renovations Underway,            |
| Boston, MA 02163                       |  Thank You for Your Patience.     |
| Voice:(617)495-6307 FAX:(617)496-5265  |  Will Reopen Soon."               |
+----------------------------------------------------------------------------+



Xref: sparky comp.programming:2377 comp.realtime:973