Subject: Problem installing spidery WEB

From: Geoffrey D. Alexander <[email-masked]>
Date: Fri, 19 Jan 90 17:41:01 EST

Norman,

I have run into a problem installing Spidery WEB.  The problem occur when I
try to run make boot from WEBROOT.  Here is the output produced:

===============================================================================
cd c; make  boot; cd ..
cd ../master; rm -f *.o; for i in /unc/alexande/spiderweb/master/common.c /unc/alexande/spiderweb/master/pathopen.c; do \
	cc -DDEBUG -g -DSTAT -c $i; \
	mv *.o /unc/alexande/spiderweb/master/sparc_sunos ; \
done; cd ../c
cc -DDEBUG -g -DSTAT -c tangle.c; \
cc -DDEBUG -g -DSTAT -o /unc/alexande/bin/sparc_sunos/ceetangle /unc/alexande/spiderweb/master/sparc_sunos/common.o /unc/alexande/spiderweb/master/sparc_sunos/pathopen.o tangle.o
ld: /unc/alexande/spiderweb/master/sparc_sunos/common.o: Not a directory
*** Error code 4
make: Fatal error: Command failed for target `boot'
Current working directory /tmp_mnt/auto/phi/phi2/unc/alexande/spiderweb/c
*** Error code 1
make: Fatal error: Command failed for target `boot'
===============================================================================

The problem is that there is no directory WEBROOT/master/sparc_sunos where
sparc_sunos is the value returned by cputype.  I see that Spidery WEB is
distributed with null directories WEBROOT/master/sun3 and WEBROOT/master/vax.
Instead of "precreating" these null directories, why not dynamically create
them?  Note that there wasn't anything in WEBROOT/README or
EBROOT/master/WebMake which indicated that cputype has to return either sun3
or vax (or that a null directory has to be created).

The last line of WEBROOT/BUGS is

===============================================================================
===> Bundled 29 Nov 89; all bugs into patches/008
===============================================================================

If you have any questions, please let me know.

Thanks,
Geoff

---

From: Norman Ramsey <nr>
Date: Mon, 16 Apr 90 10:57:34 EDT

> 
> Norman,
> 
> I havd the following problems installing Spidery WEB:
> 
> *  I was unable to make web in the larch subdirectory.
> Error: "comment begin" must have a restricted translation
> Error: "line begin" must have a restricted translation

Fixed.  You need <"%"> not % and <"%line"> not %line

> * I had two problems making web in the penelope subdirectory although I did
>   get a tangle and weave wiich run.  Why did I get a Fatal error from make
>   (I believe it comes from /bin/make -f SpiderMakefile $*)?  

Beats me.

> Why is there
>   potential cycle error?

Cleverness about newlines in annotations.  Context eliminates the
possibility of a cycle---check the productions.list file if you're not
clear about that.

> I recently started using Spidery WEB.  I have encountered a few minor problems.
> The first problem is that I would like to use C code in a module name.  This
> is illustrated by the following short example.
> 
> @*= Starred module with |C_code|.

This is broken just like anything else that changes catcodes in
arguments.  It's a TeX problem that nobody knows how to fix.

> As a temporary soultion for using C code in module names, I tried using \it.
> This illustrated by
> 
> @*= Starred module with {\it C\_code}.
> 
> @*= Index.
> This didn't work.  When I ran TeX, I got
> ......
> A solution which worked for me was to move \write\cont{\string... after
> \openout\cont=\contentsfile.  This is similar to the code in CWEB's
> cwebmac.tex.  Is this a good fix?

Looks good to me.

> This problem has to do with C preprocessor commands and the index.  Consider
> the following short example.
> 
> Ceeweave and TeX both run fine.  However, the index contains entries for ifdef,
> include, and endif (in italics and without the #).  I don't think preprocessor
> commands should be in the index (in any form).  What do you think?  How do I
> fix this?
>
> This problem invloves #include and the index.  Consider the following short
> example.
> 
> Both ceeweave and TeX run fine.  However the index contains entries for test
> and it.  It should contain instead an entry for test.it (or no entry).  What
> do you think?  How do I fix this?

You're not going to be able to do anything about this without
fundamentally changing Weave's idea of what an identifier is.  
If you want you could make the preprocessor directives reserved words,
suppressing their appearance in the index, but that will have
unpleasant repercussions, I'm sure.  If you really want to fix this
you'll have to do some hacking.

> This problem has to do with spacing in ANSI C function parameter
> specifications.  Consider the following short example.

Nobody has written a Spider description for ANSI C that I am aware of.
If you care to write one I'll be happy to put it in the distribution.

> This problem has to do with the running head.  Consider the following short
> example.
> 
> @*= Test of starred modules -- chapter.
> 
> @*2 Test of starred modules -- subsection.
> 
> @*4 Test of starred modules -- subsubsection.
> 
> @*=Index.
> Both ceeweave and TeX run fine.  However, the running head on page 1 has module
> number 1 and the title for module 3.  I believe that they should be consistent.

Fidget with \firstmark, \topmark, and all of their friends in
webkernel.tex.  Let me know when you have something you're happy with.

> Actually, I would like to have only starred modules which cause page ejects be
> reflected in the running head.  What do you think?  How do I fix this?

Not a bad idea.  Get hacking.

> This is not really a problem as much as a design question.  I feel that @f
> should not result in any text in the TeX output (either in the module in
> which it occurs or in the index).  @f is a directive to ceeweave; it does not
> contribute to understanding the C program.  For example, if I use Xlib, I need
> to @f a number (20+) of indetifiers which are "typed" in the Xlib header files.
> I feel that having the @f's appear in a module (and in the index) simply
> detracts from the program.  What do you think?  How might I "fix" @f?

I think that if you're going to lie to your reader by using @f, your
reader should at least have a chance to catch you in the act.  From
this you may infer that I never use @f.

Norman