gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] asdf


From: Faré
Subject: Re: [Gcl-devel] asdf
Date: Mon, 10 Feb 2014 16:18:01 -0500

Dear Camm and/or other GCL developers,

here is the summary of GCL bugs I've discovered while porting ASDF, so
far as I could retrieve them from our previous emails. Since GCL
doesn't seem to have an active bug tracking system, I've committed the
list to the ASDF TODO file instead.

** GCL is almost working again; but implementation bugs remain.
   See November 2013 discussion on gcl-devel.
    * Another GCL compiler bug:
    when I changed the definition of getcwd from
    (let ((*default-pathname-defaults* #p"")) (truename #p"")) to
    (let ((*default-pathname-defaults* *nil-pathname*)) (truename
*nil-pathname*))
    to guard against e.g. a logical-pathname context while loading asdf
    and parsing #p"", calls to getcwd result in a segfault.
    * An another bug: gcl refuses dynamic-extent declaration on functions.
     uiop/stream.lisp:         #-gcl (declare (dynamic-extent ,@(when
     before `(#',beforef)) ,@(when after `(#',afterf))))
    * (typep p 'logical-pathname) should be T if p has a logical-pathname host.
    * apropos is case-sensitive and returns a same symbol many times
    * compile-file fails to return proper secondary values in case of
non-style WARNING.
    * (pathname-directory #p"foo/") is incorrectly ("foo") instead of
(:RELATIVE "foo")
    * Missing: chdir, combine-fasls, and plenty more UIOP functions.
    * Do whatever it takes to pass the asdf tests, add the above?
    * Have (require "asdf") and (require "ASDF") both work.
    * Trying to uiop:slurp-stream-forms from a stream with #+(or) :foo
      (or read-file-forms from an file with same) results in an error,
      rather than nil. This is probably a bug in #+ processing.
      Unhappily, debian creates such a file in
      
/etc/common-lisp/asdf-output-translations.conf.d/01-common-lisp-controller.conf
    * Tests that try to catch an error fail (but catching a warning succeeds),
      which suggests brokenness in handler-bind and/or error.

I hope you're doing well. I understand you're otherwise out of that
scarcest of resources, time.

Regards,

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Think you can, or think you can't — either way, you'll be right. — Henry Ford



reply via email to

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