Dear Camm, thanks for your prompt reply and quick fixes! I'll try compiling GCL again, and report on my findings.
Some old version of ASDF 2 once worked with GCL, albeit with reduced functionality, and it never passed all the tests. If I manage to get ASDF 3 to run, I expect many failures in the test suite, some of them ASDF bugs, some of them GCL bugs. Is master the branch I should be working with? Should I only try to make it work with 2.7.0? What is the recommended way to test for a "recent enough" version of GCL? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The highest goal of computer science is to automate that which can be automated. — Derek L. VerLee On Mon, Oct 28, 2013 at 9:39 AM, Camm Maguire <c...@maguirefamily.org> wrote: > Greetings, and thanks so much for trying this out! > > master has the older 2.7.0 debian code, updated for the recent 2.6 > releases through 2.6.10pre, and with further development. It is > 'bleeding edge', but I try to keep it in basic building shape. I hardly > ever run 'make install' in my tests, just make and test the saved image > in the build directory. > > The primary item keeping master from release is the slow compile times. > This branch makes heavy use of lisp source inlining. A string-hashing > accelerator will be pushed shortly to the branch inline-hashing off of > master. > > I've pushed the following to master for you: > > 1) your reset-sys-paths fix -- thanks! > 2) a fix to the defgeneric in (eval-when (compile) ...) > 3) a fix to the spurious warnings regarding predicate variables in > lambda lists. > > I would like to put 2.6.10 out soon and find time to work on master. > There is a segfault/fread restart problem on ia64, and a few windows > issues in the way. I don't think I have time for maintaining two > separate branches in Debian package form as in the past. I'm thinking > it more efficient to experiment in git and evolve one stable release > series more slowly. > > Would love to help you get asdf working. But please be aware that stuff > can and will break as master moves along. > > Take care, > > Faré <fah...@gmail.com> writes: > >> On Thu, Oct 24, 2013 at 3:55 PM, Faré <fah...@gmail.com> wrote: >>> Note that if I in the makefile I replace (reset-sys-paths ...) by >>> (system::reset-sys-paths ...) I can complete the installation, though >>> I notice it doesn't install the ANSI variant of GCL, so I did that >>> manually. >> >> Some bugs while compiling ASDF with the latest GCL from git master in ANSI >> mode: >> >> (compile (defun foo (&key (x () xp)) (declare (ignorable xp)) (list x))) >> ;; Compiling /tmp/tunes/gazonk_29875_0.lsp. >> ; (DEFUN FOO) is being compiled. >> ;; Warning: Ignore/ignorable declaration was found for not bound variable XP. >> ;; Warning: The variable XP is not used. >> >>>(compile (defun foo (&optional (x () xp)) (declare (ignorable xp)) (list x))) >> ;; Compiling /tmp/tunes/gazonk_29875_0.lsp. >> ; (DEFUN FOO) is being compiled. >> ;; Warning: Ignore/ignorable declaration was found for not bound variable XP. >> >> Apparently, the present variables aren't visible in the declaration, >> and that causes the ignorable declaration not to apply. >> Yet in the &optional case there's no warning that variable XP wasn't used. >> >> Later, the compilation aborts while compiling a defgeneric in an eval-when: >> >> ;;; gcl.lsp: >> (eval-when (:compile-toplevel :load-toplevel :execute) >> (defgeneric foo (a)) >> >> (compile-file "gcl.lsp") >> >> ;; Compiling /home/tunes/bug/gcl.lsp. >> >> Error: >> Fast links are on: do (si::use-fast-links nil) for debugging >> Signalled by FUNCTION. >> INTERNAL-SIMPLE-UNDEFINED-FUNCTION: Cell error on FOO: Undefined function: >> >> >> GCL has changed significantly since 2.6.7, and in good ways, >> but there doesn't seem to be any easy #+feature check to distinguish >> the good-enough recent versions from the old ones. >> Could you push something onto feature? >> Maybe :gcl-2.7.0 or :gcl2.7. >> >> Because ASDF fails to compile, I cannot run further tests. >> >> I didn't try any branch but master. Tell me if I should. >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• >> http://fare.tunes.org >> Being really good at C++ is like being really good at using rocks >> to sharpen sticks. — Thant Tessman >> >> _______________________________________________ >> Gcl-devel mailing list >> Gcl-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/gcl-devel > > -- > Camm Maguire c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gcl-devel
