Re: [Gcl-devel] Compiling GCL

[Faré]

On Wed, Nov 6, 2013 at 4:09 PM, Camm Maguire <address@hidden> wrote:
>> OK, I haven't yet isolated the issue, but I can tell that frob-substring
>> in uiop/common-lisp is not being compiled properly: it works when
>> defun'd at the REPL,
>
> Thanks for this report!  It should be fixed now.
Thanks. I can't build anymore, though.

git clean -xfd ;
./configure --prefix=/home/tunes/local/stow/gcl --enable-ansi ;
make -l6 install prefix=/home/tunes/local/stow/gcl

...
echo " (system:save-system \"saved_gcl\")" >>foo
./raw_gcl /usr/local/google/home/tunes/src/gcl/gcl/unixport/  -libdir
/usr/local/google/home/tunes/src/gcl/gcl/ < foo #tmp_image
GCL (GNU Common Lisp)  April 1994  16777213 pages
Building symbol table for
/usr/local/google/home/tunes/src/gcl/gcl/unixport/raw_gcl ..
loading /usr/local/google/home/tunes/src/gcl/gcl/unixport/../lsp/gcl_export.lsp
Initializing gcl_s.o
Initializing gcl_sf.o
Initializing gcl_dl.o
Initializing gcl_fle.o
Initializing gcl_rm.o
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_predlib.o
UNDEFINED-FUNCTION NIL LET   NAME TYPEPSegmentation violation: c stack
ok:signalling errorERROR NIL LET   FORMAT-CONTROL Caught fatal error
[memory may be damaged]: ~aFORMAT-ARGUMENTS(Segmentation violation.)
Lisp initialization failed.
rm -f tmp_image
rm init_gcl.lsp.tmp pre_init.lsp post_init.lsp
make[1]: Leaving directory `/usr/local/google/home/tunes/src/gcl/gcl/unixport'
mv: cannot stat `saved_gcl': No such file or directory
make: *** [unixport/saved_pre_gcl] Error 1


> The test errors are
> reduced, with some 'does not exist' errors apparently next.
>
That's progress.

> Thanks so much for isolating this report!  You probably don't have to
> work so hard -- all I need is 'this function (source) when called as
> (call) returns (results) in the REPL and (compiled results) when
> compiled.  I expected (expected results)'.  Of course getting a small
> function is ideal, but one fitting in an emacs screen is just fine.
>
OK, will do that next time.

> Our pathname code is really bad and hard to maintain, and needs a
> rewrite.  We had a very helpful volunteer who coded it in C, but this
> made it much longer than it needs to be and harder to interactively
> modify.  Alas, I only 'sort-of' understand logical-pathnames, but am
> learning more.  The case matching rules are especially opaque to me.
> Many of your tests were failing as namestring recapitalized your host
> string, as the spec appears to say it should.  I've put in a fix, but it
> may not yet be comprehensive.
>
Can you take the code from ECL, SBCL or any existing system?

Logical pathnames are both tricky and ultimately useless. They are a
legacy thing that was never developed (premature standards cause
premature code that can't evolve) and is now replaced by better
things. I wouldn't make a priority of getting them perfect.

> We have a test suite, and all tests in ansi-tests/*logical-path*p pass.
> It would be great if you find other failures and feel in the mood to
> suggest added tests.  I do look at this frequently and it is likely to
> be kept in reasonable shape as gcl progresses.  Running the test-suite
> is the last step in my commit release cycle.
>
I suppose each of the failures found should be added as a regression
test, but oh well. I admit that for ASDF, I more often than not
skipped the test-writing.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There is joy in work. There is no happiness except in the realization that
we have accomplished something. — Henry Ford