gcl-devel
[Top][All Lists]
Advanced

[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

Issues:

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/raw_pcl_gcl
/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

T

>
T

>

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 
>>>>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
>>> 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]