> < ^ Date: Wed, 14 Dec 1994 19:27:00 -0500
> < ^ From: James McCarron <jmccarro@mercator.math.uwaterloo.ca >
> < ^ Subject: Re: how are library files used?

Hello again!

Many thanks to Steve Linton for the helpful information.

With that help, I have studied the code, and tried a few things.
I am beginning to believe this is not as easy as I had hoped.
Rather than rewriting SyFopen, SyFclose, etc., I thought that it
might be safer to write wrapper functions for these two, and then
replace them by the wrapper functions at those places where I want
to open and close compressed files.
For example, this is the wrapper function I have tried for

GzFopen(char *name, char *mode)
        long fid;               /* file identifier */

/* uncompress the file */

/* open the file */
fid = SyFopen(name, mode);

/* record the name of the file in syBuf[fid] */
syBuf[fid].fname = (char *)malloc(1 + sizeof(name)/sizeof(char));
syBuf[fid].fname = name;

return fid;

}       /* GzFopen */

The function 'Gunzip' simply uncompresses the file "name" using

This required changing the structure 'syBuf' in system.c, adding the

char fname[MAXPATHLEN];

This seems to be necessary so that, when the fid is passed to the
corresponding function 'GzFclose', which closes and then compresses
a file, we can recover the filename to pass to SyExec.
The function GzFclose takes the fid as argument, and simply
closes the file and then compresses it with a function 'Gzip', which
requires the filename;hence, the requirement for the change to syBuf.
For the moment, I am just playing with the online help. It seems
a safer place to experiment than with the library files *.g.
Okay, sounds good so far. However, when I replace all the calls
to SyFopen and SyFclose in the function SyHelp (in system.c), everything
seems to work just fine, until I try to use the online help. I think
there must be other calls to these functions, outside of SyHelp, which I
have not found. When I try to call the online help with, say


Gap replies that it cannot find the file 'manual.toc'. (I have compressed
all the manual files). If I uncompress manual.toc before trying this,
Gap will give me the list of Chapters as per normal. As expected, when
the command is complete, the file manual.toc ends up compressed. So maybe
GzFclose is working. However, any subsequent request to list chapters
fails as before.
The question is: Why might Gap not be able to find the manual.toc
file when it is compressed?
From the comments in 'system.c', I realise that malloc should not
be used. I tried this with 'SyGetmem' in place of 'malloc', but when I
use that, it gives me a Bus error and core dump. (and really messes my
terminal :-) I wonder if I may not be using 'SyGetmem' correctly? I have
used it exactly where i have 'malloc' above (same args, etc.).
I have only tried this sort of thing before in shell scripts, where
I can set up a pipeline. I wonder whether there might be a better solution
along those lines. In a shell script, one can do something like:

zcat $file | nroff -man | more

to read compressed manual pages. Could something like this be done in C,
replacing 'nroff -man | more' part by the SyHelp function? Perhaps the
way to handle this idea is to extract the help system as a standalone
program which could be run in a different window. Hmmm... I am perplexed.
Any suggestions?

By the way, is there any documentation on the implementation of GAP?
It occurs to me that some of GAP's authors might have written papers on
the *implementation* (as opposed to user documentation, which is, of course,
excellent). I found none in the bibliography of the manual.
But a project of this size must surely
have been documented in the literature? Perhaps if I studied some of this
more technical material, it would help me navigate the code.

Thanks again!


P.S. Apologies for the delay -- it's that time of year again, when final
exams must be graded. :-)

James McCarron

Department of Pure Mathematics Internet: jmccarron@barrow.uwaterloo.ca
University of Waterloo
Waterloo, Ontario
N2L 3G1

> < [top]