[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Compiling GCL

From: Faré
Subject: Re: [Gcl-devel] Compiling GCL
Date: Fri, 1 Nov 2013 05:36:12 -0400


0- compilation is *very* slow, comparedto either clisp or sbcl, or even ecl.

1- you put a package prefix only in front of one reset-sys-paths out of three.

2- the ansi image is not built & installed by default, yet that's what asdf uses

3- the ansi build is hosed. make saved_pcl_gcl hangs with 100% CPU while running
/home/tunes/src/gcl/gcl/unixport/ -libdir /home/tunes/src/gcl/gcl/
  Last output:
;; Loading /home/tunes/src/gcl/gcl/unixport/../lsp/gcl_auto_new.lsp
;; Finished loading /home/tunes/src/gcl/gcl/unixport/../lsp/gcl_auto_new.lsp




Haven't gone further today.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"I carry a gun because a cop is too heavy." — R. Lee Wrights

On Fri, Nov 1, 2013 at 2:52 AM, Faré <address@hidden> wrote:
> 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 <address@hidden> 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é <address@hidden> writes:
>>> On Thu, Oct 24, 2013 at 3:55 PM, Faré <address@hidden> 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 
>>> ;; 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
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/gcl-devel
>> --
>> Camm Maguire                                        address@hidden
>> ==========================================================================
>> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]