gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian


From: Camm Maguire
Subject: Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian
Date: Tue, 04 May 2010 18:25:43 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings!

Faré <address@hidden> writes:

> Dear Camm,
>
> thanks a lot for your help.
>

and for your feedback!

> Based on your feedback, I removed clc and tried again. Passed that
> point, I found a few more issues.
>
> 1- the fasl compiler tries to be clever with packages and apparently
> treats defpackage specially. To go around that issue, I specially
> defpackage trivial packages on gcl. I tried to write some complex
> macrolet that does the right thing on either gcl or other systems, but
> somehow it didn't make gcl happy.
>

Are you referring to a reodering of defpackage statements?  Do you
have a sample source file showing this?

> 2- relative pathnames are parsed by gcl without a :relative in the
> directory component. That's a gcl bug. I now work around in
> merge-pathnames* and relativize-pathname-directory.
>

This I think I can fix.

> 3- GCL borks on this:
> (MAKE-PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY
>            '(:RELATIVE :WILD-INFERIORS) :DEFAULTS #P"/**/*.*")
>

The issue is with :DEFAULTS #P"/**/*.*" -- two :wild-inferiors.  Also
can be fixed.

> 4- There seem to be errors in printing conditions that prevent our
> print-methods from being called.
>

Details?

> 5- GCL is still missing support for ~W.
>

I grok this.

> 6- something prevents janderson's logical pathname tests from working on GCL.
>

Where are these?  How do they fail?

> 7- when compiling fare-utils, it looks like ASDF itself is working,
> but GCL borks on base/macros.lisp.
>

I can't find this file.  Can you post a transcript?

> Enough for today. I'm releasing ASDF 1.715, which I believe works
> better on GCL than any previous version of ASDF. You're welcome to
> include it in GCL, submit patches, etc.
>

Great!  At some point I should try to learn asdf.  Wish it was at a
lower level than CLOS so it could be used in building CLOS and more
basic components.  There have been various proposals to include
defsystem in GCL from time to time, but it does not appear in the lisp
standard.  I suppose asdf is the de facto standard of the moment, but
it would be great to have a non-moving target.

Take care,

> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> You can tell whether a man is clever by his answers.
> You can tell whether a man is wise by his questions. -- Naguib Mahfouz
>
>
>
>
> On 4 May 2010 13:36, Camm Maguire <address@hidden> wrote:
>> Greetings, and thank you so much for your reply!
>>
>> There is also a gcc-4.4 -g -Os bug on gcl_pcl_methods.c, now worked
>> around in the newly uploaded -100 package.  The clc stuff now works
>> for me.  Please let me know if this is not the case for you too.
>>
>> If you are interested in gcl development, please let me know, as I
>> have a local tree with significant enhancements as yet uncommitted,
>> due to lack of time (writing a book).
>>
>> Take care,
>>
>> Faré <address@hidden> writes:
>>
>>> Can you provide an updated gcl installation script?
>>>
>>> When I simply replace c-l-c: by clc: I get other errors.
>>>
>>> As for the missing function ASDF:PROCESS-SOURCE-REGISTRY, are you
>>> using the latest ASDF? Say 1.704 from debian or 1.714 from upstream?
>>>
>>> I removed the clc image and tried again. I can compile asdf, but
>>> gclcvs won't load it, saying package ASDF does not exist - apparently
>>> the eval-when doesn't get a chance to be run before gclcvs tries to
>>> link stuff to said package.
>>>
>>> I also tried loading asdf.lisp as a lisp file then loading a system,
>>> but then I get an
>>> Error in error:
>>> ERROR SIMPLE-TYPE-ERROR (DATUM INTERNAL-SIMPLE-MISSING-COMPONENT
>>>                                EXPECTED-TYPE
>>>                                (SATISFIES CONDITION-CLASS-P)
>>>                                FORMAT-CONTROL Not a condition type: ~S
>>>                                FORMAT-ARGUMENTS
>>>                                (INTERNAL-SIMPLE-MISSING-COMPONENT)) NIL
>>>
>>> How do I get a useful backtrace from there?
>>>
>>> [ François-René ÐVB Rideau | Reflection&Cybernethics | 
>>> http://fare.tunes.org ]
>>> There are two distinct classes of men in the Nation, those who pay taxes
>>> and those who receive and live upon the taxes. -- Thomas Paine
>>>
>>>
>>>
>>>
>>> On 2 May 2010 13:13, Camm Maguire <address@hidden> wrote:
>>>> Greetings!  The pathology was do to the failure in the clc script,
>>>> causing the clc image to be saved in an error state.
>>>> unregister.... produces a working image, and a replacement clc
>>>> installation works fine.  The nickname c-l-c went to clc.
>>>>
>>>> But now I have the following -- maybe you can suggest a fix:
>>>>
>>>> GCL_ANSI=t gclcvs -eval '(asdf:load-system :fare-utils)'
>>>> GCL (GNU Common Lisp)  2.7.0 ANSI    Apr  9 2010 18:42:13
>>>> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
>>>> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
>>>> Modifications of this banner must retain notice of a compatible license
>>>> Dedicated to the memory of W. Schelter
>>>>
>>>> Use (help) to get some basic information on how to use GCL.
>>>>
>>>> Temporary directory for compiler files set to /tmp/
>>>>
>>>> Error:
>>>> Fast links are on: do (si::use-fast-links nil) for debugging
>>>> Signalled by ASDF:OPERATE.
>>>> SIMPLE-ERROR: Can't get template for #<Standard-Method 
>>>> ASDF:PROCESS-SOURCE-REGISTRY (SYMBOL) 130356220>
>>>>
>>>> Broken at ASDF:OPERATE.  Type :H for Help.
>>>>  1 (Continue) Return to top level.
>>>> COMMON-LISP-USER>>
>>>>
>>>> Take care,
>>>>
>>>> Faré <address@hidden> writes:
>>>>
>>>>> To reproduce the problem, install the latest cl-asdf 1.704 from debian
>>>>> and common-lisp-controller 7.2 with gclcvs 2.7.0-64 and try this:
>>>>>
>>>>> GCL_ANSI=t gclcvs -eval '(asdf:load-system :fare-utils)'
>>>>>
>>>>> Use any system here - I'm using fare-utils from git because I know it
>>>>> and it has no dependencies. Try alexandria or whatever.
>>>>>
>>>>> Without debian, try downloading the latest asdf from git (currently
>>>>> 1.710) and try this:
>>>>> gcl
>>>>> (require :asdf) ; or (load "/path/to/asdf.lisp")
>>>>> (asdf:load-system :fare-utils)
>>>>>
>>>>> PS: it would be nice if gcl were packaged by clbuild.
>>>>>
>>>>> The error I get is
>>>>> Unrecoverable error: bind stack overflow.
>>>>>
>>>>> (Note: linux amd64)
>>>>>
>>>>> Haven't tried 32 bit in a while - would have to resurrect a 32-bit
>>>>> machine / installation.
>>>>>
>>>>> [ François-René ÐVB Rideau | Reflection&Cybernethics | 
>>>>> http://fare.tunes.org ]
>>>>> Death is only a state of mind.
>>>>>
>>>>> Only it doesn't leave you much time to think about anything else.
>>>>>
>>>>>
>>>>> On 29 April 2010 10:16, Camm Maguire <address@hidden> wrote:
>>>>>> Greetings!  If you could please post some failing command lines I can
>>>>>> reproduce, that would be great.
>>>>>>
>>>>>> Right now, I think the issue is that the c-l-c nickname has been
>>>>>> dropped in common-lisp-controller.  I'm assuming this is facility is
>>>>>> still the "Debian lisp way":
>>>>>>
>>>>>> INTERNAL-SIMPLE-ERROR: There is no package with the name C-L-C.
>>>>>>
>>>>>> This is from a installation script used to setup c-l-c in gclcvs.  If
>>>>>> I know what will be permanent, I can fix this and re-release.  But not
>>>>>> until the mipsel buildd is finished and migration takes place.  Would
>>>>>> like to do the kfreebsd-amd64 by then too.
>>>>>>
>>>>>> Would appreciate any feedback here as I'm more familiar with the older
>>>>>> math lisp code than the ansi cl- stuff.
>>>>>>
>>>>>> Take care,
>>>>>>
>>>>>> Faré <address@hidden> writes:
>>>>>>
>>>>>>> Is the GCL 2.7.0 package for debian maintained?
>>>>>>>
>>>>>>> I get weird Unrecoverable error: bind stack overflow while trying to
>>>>>>> use GCL to compile even the simplest ASDF systems. Where exactly the
>>>>>>> overflow happens moves *further* when I try tracing more functions, so
>>>>>>> somehow that bind stack grows more slowly with traced functions than
>>>>>>> untraced functions. Still, eventually it borks for no obvious good
>>>>>>> reason.
>>>>>>>
>>>>>>> Is that a known bug fixed upstream?
>>>>>>>
>>>>>>> Can you make GCL work with ASDF? With clbuild? That would be nice.
>>>>>>>
>>>>>>> Currently, I have to declare GCL support for ASDF and CL-Launch
>>>>>>> broken. Haven't been able to test positively for months.
>>>>>>>
>>>>>>> [ François-René ÐVB Rideau | Reflection&Cybernethics | 
>>>>>>> http://fare.tunes.org ]
>>>>>>> Corollaries to the Law of Bitur-Camember: The political process 
>>>>>>> destroys the
>>>>>>> value of all known resources that are up for grabs. The socialist 
>>>>>>> process of
>>>>>>> systematically denying legitimacy to property rights applies the 
>>>>>>> political
>>>>>>> process universally and destroys the value of all available resources.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Camm Maguire                                       address@hidden
>>>> ==========================================================================
>>>> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Camm Maguire                                       address@hidden
>> ==========================================================================
>> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>>
>
>
>
>

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