HDTenEightyP/NetNews huggingface dataset:
From: sz@Materna.DE (Stefan Zimmermann)
Newsgroups: comp.programming
Subject: Re: SCCS & make
Keywords: SCCS, make, C
Date: 14 Apr 92 12:40:33 GMT

mnykanen@cs.Helsinki.FI (Matti Nykanen) writes:

>The man entry on "make" states that it works with SCCS, i.e. when a file
>is missing it tries to "SCCS get" a read-only copy for compilation
>first. This works on C source files with suffix ".c" but *not* with
>header files with suffix ".h". How could I correct this?
>-- 

Hi Matti

Try 'make -n -p' to get the target descriptions and macro definitions
(-p option, -n option means 'no execution')
When you don't find lines like this:
	line>	GFLAGS = 
	line>	GET = get
		:
	line>	.h~.h:
	line>		$(GET) $(GFLAGS) $<
then insert this lines into your Makefile

Otherwise you have a Problem:
Perhaps you forgot to define a depends between the c-file and the h-files?
like this
	expamle.c:	expamle.h elmapxe.h
or your 'make' is an defuse shell-script ;:)

but normally is work's. When you have much truble, try the GNU make, it really
work's (also with RCS-files).

	I hope, I could help
	
		Stefan.



>Internet: Matti.Nykanen@Helsinki.FI  Department of Computer Science
>Voice:    +358 0 708 4207            University of Helsinki,Finland
Newsgroups: comp.programming
From: Colin.Moneypenny@dh.boeing.com (Colin Moneypenny)
Subject: BARCODE SOFTWARE
Organization: Boeing Canada, Toronto
Distribution: comp
Date: Wed, 15 Apr 1992 12:47:11 GMT


Greetings,

	Can someone point me to a prg for printing barcodes on an HP Laserjet
or Epson DMP printer. SOurce code would be greatly appreciated.

	Thanks in advance.

--
Colin Moneypenny                     INTERNET: Colin.Moneypenny@dehavilland.ca
Systems Analyst Office Systems       
de Havilland INC		     OFFICE:   (416) 375-3222
Garratt Boulevard MS N02-02          FAX:      (416) 375-4511
Downsview, Ontario
CANADA M3K 1Y5
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: Names
Organization: NCRPDA, Curtin University
Date: Mon, 13 Apr 1992 02:18:53 GMT

In article <kufk3iINNj9b@boogie.cs.utexas.edu>, swisher@cs.utexas.edu (Janet M. Swisher) writes:

> Here is a summary of Keller's suggestions:

These were very good suggestions.  One thing I would add is a method some
friends and I developped while working on an operating system...  In your
description, everything relies on nouns and verbs, but these arent always
clear.  So we added the use of capitals/underscore to distinguish the
differ types.

> *Type Names

Type names start with a lowercase letter, and then each other word has an
upper case letter (for ease of reading), with no underscores (thus types 
should have at least two words):

> especially before names of variables of the type.  Examples: Table,
> Error, State, StateTable, FileName.

stateTable & fileName

> *Procedure Names

Procedures and Functions should have each word capitalized, with no 
unbderscores.

> of the type operated on is often appropriate.  Examples:  StoreWord,
> DisplayError, ShowPrinterStatus.

StoreWord, DisplayError, ShowPrinterStatus.
> 
> *Variable and Function Names
> *Constants

Variables and constants should be all in lowercase, with words seperated
by underscores.

> FirstState, NextState, BigWindow, EndOfList.

first_state, next_state, big_window, end_of_list.

> Treat pretty much like variables.  The prefix "Max" is often useful
> for names of limits.  Examples: MaxLineLength, MaxLinesPerPage,
> DefaultRepeatRate.

max_line_length, max_lines_per_page, default_repeat_rate.

For example:

const
  line_length_max = 80;

type
  lineRange = [1..line_length_max]
  lineString = array lineRange of char;

var
  line_length : lineRange;
  first_line : lineString;

> I'm sure plenty of people will be able to come up with legitimate
> reasons for violating any of these guidelines (no flames, please), but
> it seems to me they make a pretty good starting point.

I agree, and ther above makes a name easily recognizable with no context
or noun/verb knowledge.

Of course, I'm also the first to violate any and all of these rules, but
I'm a lone programmer, and program stuff for my own use, so that doesnt
worry me much.

Did I get the definitions right Quinn? :-)

Have fun all,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      peter@cujo.curtin.edu.au
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: +61 9 367 8141
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.programming
Subject: Re: Multi-tasking kernel
Date: 12 Apr 92 02:04:15 GMT
Organization: University of Chicago CILS

In article <1992Apr11.122628.2131@nuscc.nus.sg> eletanjm@nuscc.nus.sg (Tan Jin Meng @ NUS) writes:
|Why don't you write one yourself? You can in fact write a simple and
|completely portable non preemptive multitasking kernel by just using the
|standard C routines setjmp() and longjmp().

How? Where are the stacks stored? Suddenly you have more than one....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: vj@gserv1.dl.ac.uk (Dave Hines)
Newsgroups: comp.programming
Subject: Re: Calculating Logarithms / square root
Date: 10 Apr 92 22:08:49 GMT
	<1992Apr10.154413.11347@uwm.edu>
Reply-To: D.Hines@uk.ac.daresbury
Distribution: comp
Organization: SERC Daresbury Laboratory, Warrington, UK

In <1992Apr10.154413.11347@uwm.edu> markh@csd4.csd.uwm.edu (Mark William
Hopkins) writes:

> If you can find a good way to do square roots, especially of numbers near 1
> (where sqrt(1 + d) ~~ 1 + d/2), then the following will work [calculate
> fixed point logarithms] for large enough N:
>
>
> Y = ln(X):
> ----------
> for (Y = X, I = 0; I < N; I++) Y = sqrt(Y);
> Y--; Y <<= N;


Here is an integer square root routine I've found useful in the past. It
shouldn't be difficult to add suitable scaling to make it fixed point.

/*
* Integer square root code for a binary machine with an even number of bits in
* a long. Returns the integer square root, with the remainder in the long int
* result2.  If x is an unsigned type, the square root of a full word will be
* generated. If x is signed, a test for negative numbers should be added. (n,
* sub & tmp may be either signed or unsigned, it doesn't matter).
*/

/*
* LSQRT_MAGIC should be set to the next to the top bit in the word.
* eg. for a 32 bit machine LSQRT_MAGIC would be 0x40000000.
*/
#include <limits.h>
#define LSQRT_MAGIC	((LONG_MAX >> 1) + 1)

long result2;

long
lsqrt(x)
unsigned long x;
{
    long n = LSQRT_MAGIC;
    long sub = 0;
    long tmp;

    do
    {
	tmp = sub + n;
	sub >>= 1;
	if (tmp <= x)
	{
	    x -= tmp;
	    sub += n;
	}
    } while (n >>= 2);

    result2 = x;
    return(sub);
}
--
Snail:	David Hines,  Daresbury Lab,	JANET:	D.Hines@uk.ac.daresbury
	Warrington,  WA4 4AD,  U.K.	Other:	D.Hines@daresbury.ac.uk
	('phone:  +44 925 603357)
Newsgroups: comp.programming
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: functions & return values (was Re: Reinventing the wheel)
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Researc Inc, Toronto
Date: Wed, 15 Apr 92 23:49:37 GMT

In article <1992Apr14.031852.25851@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes:
>In article <10212@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>There are many reasons to want multiple assignment; multiple function
>>results is just one of them.
>
>Yes. Occam has this (multiple assignment) which leads to the idiom,
>
>	a, b := b, a
>
>to swap the values of two variables.

A number of dialects of APL have similar capabilities. More interesting
is that the variables can be ANYTHING: They need not be scalar-valued,
in general, if you use a third variable:
      t =. a
       a =. b
      b =. t

(Obviously the trivial way to do it, but the time it takes is, for most
systems, independent of the arguments: If A and B are huge arrays,
it doesn't matter, because it all is done with pointer sloshing underneath
the hood).



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.programming
Subject: Re: need a HINT on a C code parsing name-strings
Date: 6 Apr 92 00:48:55 GMT
Organization: University of Chicago CILS

In article <92096.184215DECBC@CUNYVM.BITNET> <DECBC@CUNYVM.BITNET> writes:
|I am writing a C code to parse an input string formatted in
|'lastname,firstname,middle-initial' of each field is varying
|length and total length is 30 bytes, into three separate
|strings, 'lastname,' 'firstname,' and 'middle-initial.'
|
|My code doesn't satisfy the efficiency required by my demanding
|boss. So, folks, I really appreciate it if u would give me some hints.

Here's your hint: the choice of nul-terminated strings was one of the
worst decisions in the design of C (say, it's in the top 30 :-). You
might not be able to avoid it in interfaces, but internally you are
better served with pairs of pointers, to each end.

While you're at it, point out to your "demanding boss" that this data
format is asinine anyway: it fails for over half the people in the
world. What if your surname isn't your last name? What if don't have
exactly one "middle initial"? What if you go by "J. Peter Foonwald"?
Where does the "Jr." go? What if your name is a little longer than 30
characters? What if you have commas in your name? A decent format
would probably not need parsing anyway, because those fields have to
be distinguished up front, by function.

Oh, and what do you do if the name INFLECTS? Open question: has anyone
here ever had to deal with that?

Are you sure this isn't an assignment? MY experience is that the
source of these braindead ideas about data structures is usually
academic.... ;-)
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: edotto@uipsuxb.ps.uiuc.edu (Edward C. Otto III)
Newsgroups: comp.programming
Subject: Re: Job of COBOL (was: Programming Standards Question)
Date: 15 Apr 92 18:55:37 GMT
Organization: University of Illinois at Urbana

allan@cs.cornell.edu (James Allan) writes:

>I programmed in COBOL for several years.  On occasion, some fellow
>sufferers and I would attempt to make our COBOL as verbose as
>possible:

>	if a is greater than or equal to b

Your professor was correct. ESPECIALLY in the days when programmers
wrote COBOL in little boxes, 30 lines to a form, and sent them to
be keypunched.

That's why the language standard allowed either way.

By the way - has anyone out there seen the COBOL 9X standard yet? If so,
send me a copy.

--
Edward C. Otto III   	    *  E-mail addresses:  e-otto@uiuc.edu
Printing Services Office    *  Phone:  217/333-9422
54A E. Gregory Drive	    *  "The only thing we have to fear is
Champaign, IL  61820	    *  24 line .signature files..."
Newsgroups: comp.programming
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Subject: Re: Perfect hash summary....
Organization: University of Chicago CILS
	<STEPHEN.92Apr5190701@estragon.uchicago.edu>
	<1992Apr7.051042.3725@CSD-NewsHost.Stanford.EDU>
Date: Tue, 7 Apr 1992 06:50:43 GMT

In article <1992Apr7.051042.3725@CSD-NewsHost.Stanford.EDU> rfischer@Xenon.Stanford.EDU (Ray Fischer) writes:
|stephen@estragon.uchicago.edu (Stephen P Spackman) writes ...
|>This may seem like an odd question, but does anyone have a USE for
|>minimal perfect hashing? The "obvious" one, in programming languages,
|>is somewhat bogus, since in that case you have a symbol table anyway,
|>and it's faster and easier just to treat keywords like identifiers
|>through until the parser (unless, I suppose, your language has really
|>different rules for the two classes so that the lexer is better off
|>making the discimination).
|
|Actually it is neither easier nor faster to have the parser rather
|than the lexer identify keywords.  Consider all the work that has to 
|be done to find a symbol - if there are 200 symbols you'll have to do
|some 8 string compares to find out if it's a keyword.  Compare this
|with a hash function that only makes one pass through the string and
|does one string compare.

But (aside from the fact that it isn't true, a hash table is O(1) if
it's big enough) this is my point: you aren't interested in IF
somethig is a keyword, anyway. Take a hash table, preload it with all
the keywords, giving them unique syntactic classes (1 for BEGIN, 2 for
END, whatever). Now have your parser run off those 1's and 2's.

Identifiers, non-keyword ones, you give class 0. So, you read a token,
look it up. On hit, pass it through to the lexer. On miss, check if it
is of a lexical class for which new definitions are allowed (in C this
would cover things like "fish" but not ones like "++" - though it's
true that in C, and leaving aside how literals are treated, this test
should alwyas succeed because of the lexical structure) put a new
entry in the table, initialise all the attribute fields to top, set
the class to zero, and pass THAT on to the parser.

So the parser is seeing properly tokenised input, there is only one
table lookup, and nothing ever special-cases on WHETHER something is a
keyword....

|Besides, any time I've written a parser it was MUCH easier to have the
|lexer figure out what token a string represented rather than try and
|do it in the parser.

Well, the above is both the simplest and the fastest method I've ever
found. And I've written a few now.... It *isn't*, I admit, the way lex
thinks you want to do it, but that's another part of why I asked the
question: *WHY* do people want a lexer that picks up keywords?
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: hagbard@ark.abg.sub.org (Ralf Stephan)
Newsgroups: comp.programming
Subject: Re: New crypting algorithm???
Date: Sat, 04 Apr 92 21:58:29 GMT
Organization: Private UUCP and Transputer Site, Augsburg/Bavaria/Germany

peterk@public.sub.org (Peter Kittel) writes:

  [...]
> I like this idea, because it's very easy to implement. But perhaps it's
> also easy to crack?


And, likewise:  Could a crunched archive that is garbled after the crunching
with a small key with length N be cracked?

Much compressing packages already allow you to garble your file.
I would like to know how safe it is.

Thanks!  --Ralf
--------------------------------------------------------------------------
  The real thing in primate life is to play "hero" or to play "mother".
      "No more heroes" (The Stranglers)    "No more mothers" (Me)
--------------------------------------------------------------------------
Newsgroups: comp.programming
From: comptec91055@camins.camosun.bc.ca
Subject: network id soft.
Organization: Camosun College
Date: Wed, 15 Apr 1992 00:37:47 GMT



		Hello Hardware gurus and programmers:

			I am attempting to write a small routine which can be
executed on any pc that returns information on the resident network card (type
mem. cap. etc.)  (assembly/c routine).. My problem is that I am unsure of which
interrupts the card takes over when it is installed, whether or not these inter-
rupts are from the dos vector table or directly from the cpu, and how they can
be used to access card info.  If anyone has the time I would very much appreciate
 any information that could be provided.  I will send anyone that responds a copy
of the final program which does a series of hardware checks and verifications
on the pc, including nice output (not that anyone responding would need this,
but what the heck..)   If there are any ideas could you please e-mail them.
 			Thanks in advance,
	
			D. Rozee
Newsgroups: comp.programming
From: kondor@ee.ualberta.ca (Ran Kondor)
Subject: NEED INFO: Graphics Decoding
Organization: University Of Alberta, Edmonton Canada
Date: Fri, 17 Apr 1992 18:05:40 GMT

I am trying to write a graphics converter.  I need to know the format of
GIF, TIFF, JPG, etc. pictures so I can read and display them on the screen.

Can anyone help me?

/********************************************\
*  Ran Kondor                                *
*  University of Alberta                     *
*  Edmonton, Alberta, Canada                 *
*  Email address: kondor@bode.ee.ualberta.ca *
\********************************************/

Snow and adolescence are problems that disappear if you ignore them long enough.
-- 
/********************************************\
*  Ran Kondor                                *
*  University of Alberta                     *
*  Edmonton, Alberta, Canada                 *
Newsgroups: comp.programming
From: steven@mks.com (Steven White)
Subject: Re: The new international trade agreement...
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: Tue, 7 Apr 1992 21:37:22 GMT


In article <1992Apr3.051942.27151@bohra.cpg.oz.au> you write:
>There is another problem with this. How are we supposed to earn a living
>writing software if we have to release everything into the public
>domain??
>--
>| Craig Fisher            | Computer Power Group | P.O. Box 686       |

Perhaps by only putting out some of the algorithms that are likely
to be patented, but not the application? After all, a significant
program is likely to have a great many algorithms and massive support
structures around these algorithms? Just enough for you can smirk and
say 'prior art' to the patenter who comes by to annoy you. 

I have to admit, there is a problem with programs that are based mainly
on one algorithm, whose existence is the main advantage of your program.
Then revealing it to others will cause other people to be able to match
your products capabilities, even if the algorithm is just described, in
a journal.  An example of this might be the new routing algorithm for
your CAD program that is an order of magnitude faster.

Heh, The Secret Journal of Private Algorithms, that has a write only
policy except where it comes to trash patents? :)

Steven White
Just because you're paranoid, it doesn't mean we're not all out to get you.
From: markf@zurich.ai.mit.edu (Mark Friedman)
Newsgroups: comp.programming
Subject: Re: Multiple types of things in linked lists
Date: 9 Apr 92 15:13:42 GMT
Reply-To: markf@zurich.ai.mit.edu
Distribution: na
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: burleigh@bronze.ucs.indiana.edu's message of 9 Apr 92 03:11:37 GMT

In article <1992Apr9.031137.29927@bronze.ucs.indiana.edu> burleigh@bronze.ucs.indiana.edu (Frank Burleigh) writes:

** typedef struct LIST
** {
** WORD        Object;     /* type of objects in this list */
** void        **Lst;      /* pointer to pointers [array approach) */
** WORD        Current;    /* current item in list (array approach) */
** void        *Head;      /* first item in list (LL approach) */
** void        *CurrentN;  /* current item in list (LL approach) */
** void        (*wrF)();   /* function to display object */
** ...
** } LIST;
** 
** 2. references to a Prev and Next will be cumbersome if I want to
** continue to have generic navigation functions that work on any list
** object type.
** 
** Right now, I need ideas on the second of these two points.  Suppose
** you have a function to move to the next list object:
** 
** void moveNext(LIST *l)
** {
**       l->CurrentN=l->CurrentN->Next;  /* minimal, need to display etc */
** }
** 
** That won't work because CurrentN in LIST is a void * and therefore
** you can't get to *Next within the object pointed to by CurrentN.
** Each nagivation func could have a switch{} with case()s that cast
** and dereference for each object type handled by the program.  That
** would be ugly and bloat code.

I have two possible solutions to this problem. The first is to have
Next be a void * and do any neccessary casting at the points of
dereference. That way all the navigation functions can be generic.
It's only when you need to actually reference the objects in the lists
(as opposed to pointers to them) that you should worry about their
"real" types.

The other solution is suggested by your LIST type. It implies that
your lists are homogenous (all the objects in the list of the same
type). You could therefore include a moveNext (and movePrev, etc.)
function in the LIST struct and have your generic moveNext function
call the specific one for the type of list that is passed to it.

-Mark
--

Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139

markf@zurich.ai.mit.edu
Newsgroups: comp.programming
From: ressler@cs.cornell.edu (Gene Ressler)
Subject: Re: Programming Standards Question
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Thu, 16 Apr 1992 04:20:04 GMT

russw@cs.utexas.edu (Russ Williams) writes:

>if (isspiffy(x) && iskeen(x)) {
>    // x is fine, do nothing
>} else {
>    // must clean up x
>    ...
>}

>it seems clearer at a glance to me what's meant than in

>if (!isspiffy(x) || !iskeen(x)) {
>    // must clean up x
>    ...
>}

>or

>if (!(isspiffy(x) && iskeen(x))) {
>    // must clean up x
>    ...
>}

Agree.  Good point.  I find it really 
convenient in Common Lisp to have the dual
`one-sided' if's:

(when <condition>
   < do stuff > )

and 

(unless <condition>
   < do stuff > )

So for the above, we have

  (unless (and (is-spiffy-p x) 
	       (is-clean-p x))
    (clean-up x))

So how about

#define progn(B)	do { B } while (0)
#define when(P,B)	progn( if (P) { B } )
#define unless(P,B)	progn( if (P) ; else { B } )

Thence

  unless( isspiffy(x) && iskeen(x),

    cleanup(x);
    ...

  );

I know this is preprocessor abuse, but it works
great as long as you're not fond of using
commas to separate statements not protected by 
() or {}.  Also, at least some preprocessors 
get confused if you use #if #endif inside a macro
arg list.  gcc is ok.  TC and the ibm rs6000 `c89'
aren't.  On the other hand, TC gets the line numbers
right inside the arg list and gcc generally doesn't.

I've had similar good experience with an exogenous list 
library that whips the preprocessor. For example:

typedef struct cons { void *car; struct cons *cdr; } *CONS;

#define do_list(P,L,T,B)				\
	progn( CONS _p;					\
	       for (_p = L; _p != NULL; _p=_p->cdr) {	\
		 T *P = (T*)_p->car; B } )

Now:

  do_list(elt, lst, elt_t,

    elt->field = ...

  );

Another preprocessor trick for control flow statements:
To avoid a cascading `if' tree when separating 2^n cases 
based on n binary state variables define:

#define of2(B1,B0)		((B0)|((B1)<<1))
#define of3(B2,B1,B0)		((B0)|(of2(B1,B2)<<1))
#define of4(B3,B2,B1,B0)	((B0)|(of3(B1,B2,B3)<<1))
...
#define F 0
#define T 1

then for n=3:

  switch ( of3(n == 7, p != NULL, !!isalpha(ch)) ) {

    case of3(F, F, F): ... break;

    case of3(F, F, T):
    case of3(F, T, F): ... break;

    ...
  }

This compiles to a jump table with most compilers.

Note none of this is not my actual library code.
It may contain typos.  Use freely at your own risk.

Gene