gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] asdf


From: Camm Maguire
Subject: [Gcl-devel] asdf
Date: Mon, 18 Nov 2013 10:45:56 -0500

Greetings!

Fare writes:

> Those I have investigated:
> 
> * a bug in handling directories in uiop:probe-file*;
>   I think I have a fix for that,
>   but direct support in GCL for the probe-file* interface would be great:
>   a function that given a pathname designator returns the pathname
>   to either the file or directory if it exists, and
>   only optionally resolve symlinks, and return NIL otherwise.

#'si::stat returns a list with car in '(:link :file :directory) or nil,
   never resolving links

#'truename will resolve symlinks

Will this work?

> 
>   Also, GCL BUG: TRUENAME should return a FILE-ERROR, not just an ERROR.
>   Same for DELETE-FILE and probably a lot more other functions.
> 

OK, I fixed some in truename, but if you find others, it would be
helpful if you could supply the input triggering the wrong type of
error.   I fixed delete-file for you a few cycles ago.

> * In test1, test2, test3, test-around-compile, test-asdf,
> test-builtin-source-file-type, test-compile-file-failure,
> test-concatenate-source, test-deferred-warnings, test-force,
> test-inline-methods, test-logical-pathname, test-missing-lisp-file,
> test-module-depend, test-module-excessive-depend,
> test-module-pathnames, test-multiple, test-redundant-recompile,
> test-samedir-modules, test-source-file-type, test-stamp-propagation,
> test-static-and-serial
>  TEST ABORTED: Condition in COMPILER::COMPILE-FILE1 [or a callee]:
> INTERNAL-SIMPLE-PROGRAM-ERROR: Key :EXTERNAL-FORMAT :DEFAULT not
> permitted
> 
>   GCL BUG: compile-file fails to accept :EXTERNAL-FORMAT argument.
>   I'll be working around it in uiop/lisp-build for now.
> 

OK, fixed now. Thanks!

Please don't clutter your source with #+-gcl -- it is better if you
write to, and gcl supplies, the common lisp standard, at least by the
time we're done.

You should even be able to use safety settings if you want, but I don't
think you should in your final version.  safety puts in type checks
everywhere, and these are almost always redundant, and effectively foil
the most important compiler optimizations, depending on how 'safe' is
defined.  Typically you develop using safe code, and then put your own
checks where you want them at the top, or rely on some standard
non-inlined function call to do the checking for you.

gcl defines 'safe' thusly:

0 - no type checking, supplied check-type treated as a type assertion
1 - keep supplied visible check-type calls, but omit those in inlined
    children 
2 - keep explicit check-types in all children
3 - no inlining, all variables of type t, no type inference, all checks
    in place.

One of the reasons the gcl build is so slow is we bootstrap first in
safe mode, and then use that to compile according to the safety
specified in each function.

So your original reported problem with safety 3 is a bug we should fix
before we're through.

> I have not investigated these yet:
> 
> * test-run-program.script
> TEST ABORTED: Condition in SYSTEM:STRCAT [or a callee]:
> INTERNAL-SIMPLE-PROGRAM-ERROR: MULTIPLE-VALUE-CALL [or a callee]
> requires less than sixty-seven arguments.
> 

Common lisp specifies an implementation should define a constant
call-arguments-limit which is at least 50.  In GCL, it is 63.  So if you
want to write common lisp code, you should not pass more than 49
arguments or conditionalize on the 'call-arguments-limit constant.  The
former is the recommended route, as its exceedling easy just to arrange
your calls to pass a list, which is most often what the implementation
will do for you anyway with so many arguments.

>   GCL BUG?
>   This looks like a GCL bug, since STRCAT and its callees
>   don't do anything magical with multiple values.
>   Is some optimization or rewrite causing an argument list
>   to expand beyond the limit?
> 
> * In duplicate-components-test, test8, test9, test-system-pathnames
>  TEST ABORTED: Condition in CONDITIONS::COERCE-TO-CONDITION [or a
> callee]: INTERNAL-SIMPLE-TYPE-ERROR:
> CONDITIONS::INTERNAL-SIMPLE-LOAD-SYSTEM-DEFINITION-ERROR is not of
> type (SATISFIES CONDITIONS::CONDITION-CLASS-P): Not a condition type:
> CONDITIONS::INTERNAL-SIMPLE-LOAD-SYSTEM-DEFINITION-ERROR
> 

Thanks!  This is fixed now.

>  GCL BUG? I'm not sure what triggers the initial condition yet, but
>  it looks like GCL has an error in error handling and/or reporting.
> 
> * In test-retry-loading-component-1.script
> SIMPLE-ERROR: The assertion RESTART failed.
> 

Thanks!  This is fixed now (apparently by the above mod).

>  GCL BUG? It looks like find-restart fails here. Does GCL support restarts?
> 
> * test-touch-system-1.script
> INTERNAL-SIMPLE-TYPE-ERROR: NIL is not of type REAL:
> 

Thanks!  This is fixed now (apparently by the above mod).

> Now, I've tried to add in script-support a #+gcl 0 for speed,
> to speed up the compilation, and I find what I believe to be a bug in GCL,
> whereby the form
>  (remove-if #'(lambda (x) (member x '("" ".") :test #'equal))
>                                         components)
> from uiop/pathname is compiled with an error, with bogus complaint at runtime:
> Error:
> Signalled by COMMON-LISP:MEMBER.
> Condition in COMMON-LISP:MEMBER [or a callee]:
> INTERNAL-SIMPLE-PROGRAM-ERROR: Key COMMON-LISP:NIL #<function
> 00000000011dd250> not permitted
> 

Cannot reproduce this:

>(defun foo (components) (remove-if (lambda (x) (member x '("" ".") :test 
>'equal)) components))

FOO

>(compile 'foo)

;; Compiling /tmp/gazonk_24157_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, 
(Debug quality ignored)
;; Finished compiling /tmp/gazonk_24157_0.o.
;; Loading /tmp/gazonk_24157_0.o
start address -T 0x13f4750 ;; Finished loading /tmp/gazonk_24157_0.o
#<function 0000000002053610>
NIL
NIL

>(foo '("asd" "/tmp/foo/bar/baz.z" "" "r" "." "qwe" ".."))

("asd" "/tmp/foo/bar/baz.z" "r" "qwe" "..")

>

????

My results now are:
  42 passing and 6 failing
failing test(s):  asdf-pathname-test.script test-compile-file-failure.script 
test-logical-pathname.script test-run-program.script 
test-system-pathnames.script test-utilities.script

If you could summarize the issues here, that would be helpful.  I know
there is a logical pathname issue.  I'll work on that now.

Take care,
-- 
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]