Open fare opened 9 years ago
Definitely so true. I believe most of the issues are related to pathname, i.e. even this one fails to give a correct result: (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname))
git grep -i corman | wc -l 46 git grep -i clozure | wc -l 136
When done, you should be able to run the tests with make t l=corman
Corman erroneously has user-homedir-pathname return a string, rather than a pathname. To parse the string, you need add a final backslash, or the last component will fail to be parsed as a directory. See the workarounds in asdf/uiop/common-lisp.lisp.
Maybe Corman would be better off adopting the pathname code from another CL, e.g. ECL or CCL or SBCL, so as to avoid the madness of reimplementing it all correctly. SBCL seems to be most correct, but then again, it's not perfect either.
It's not a string, it's a pathname, a wrong pathname with the last directory part wrongly treated as a file name:
(user-homedir-pathname)
39 (pathname-directory ) (:ABSOLUTE "Documents and Settings") (pathname-name *) "Administrator"
Let me try to fix it. The workarounds in asdf/uiop/common-lisp.lisp should still work if (user-homedir-pathname) already has a tail "\".
I was wrong about one thing: the code in asdf/uiop/common-lisp.lisp does assume that (cl:user-homedir-pathname) returns a string but pathname. However, in CormanLisp 3.0 this is not true any more.
Any way, I have fixed the wrong behavior of USER-HOMEDIR-PATHNAME in this patch:
https://github.com/sharplispers/cormanlisp/commit/e5d73f89d46ef4dad2f1d48a152472a1f2265e5f
Now in my environment the results is this:
(user-homedir-pathname)
40 (pathname-directory *) (:ABSOLUTE "Documents and Settings" "Administrator")
All pathname components have the same values as LispWorks now.
Corman's low-level system functions like PARSE-NAMESTRING and MERGE-PATHNAMES look ugly, maybe we should really replace them with versions from SBCL...
Sigh, there's no BUILT-IN-CLASS in Closette (the trivial CLOS/MOP from the book AMOP and used by Corman without essential modifications), therefore ASDF function "coerce-class" died at the ETYPECASE form:
(etypecase normalized
((or standard-class built-in-class) normalized)
((or null keyword) nil)
(symbol (find-class normalized nil nil)))))
This is definitely an issue of CormanLisp because ANSI Common Lisp does require the presence of BUILT-IN-CLASS. And "subtypep" seems also doesn't work correctly in Corman.
I'm trying to "fix" Closette with BUILT-IN-CLASS added with minimal efforts and without breaking all exist test cases. But maybe this is a good reason to replace the whole "Closette" into "Portable Common Loops (PCL)", or (temporary) make them switchable in CormanLisp for backward compatibility.
Beware that trying to update CormanLisp to become compliant might be a lot of work and not worth it. Although if you do, it would be nice to also add a usable command-line interface so that cl-launch could work with it and asdf could be tested. What are the bits worth salvaging in CormanLisp?
@fare I think CormanLisp is a compact, efficient, native implementation on x86/win32, the most popular platform. And it's notebook-like IDE (similar to Mathematica and Maple) looks unique in modern Common Lisp world, therefore it should be the best candidate environment for CL beginners, definitely easier than those Emacs-based solutions. So the main target is for beginners in my opinion, and it can produce very small native executions (.exe).
As for ASDF, after putting a little more code into Sys/clos.lisp, I think the issue with above mentioned BUILT-IN-CLASS is gone, but some complex macro code in ASDF trigger new issues, and so far I have no idea how to fix it. I'm going to comment out some unnecessary part (i.e. uiop-debug-utility) and try compile rest of them successfully.
What is the status of ASDF on CormanLisp?
Do you have a patch to offer for inclusion in the next ASDF release?
Is there a way to invoke CormanLisp from the command-line, so as to run ASDF tests?
As far as I can tell the status of ASDF on Corman Lisp remains the same at this time. Unfortunately there is no any patch to offer. I believe that support for UIOP/ASDF is essential, but right now there is ongoing work to fix remaining Corman Lisp idiosynchrasies and prepare ground for future possible work.
It is possible to run Corman Lisp from command line using "clconsole.exe" executable (e.g. 'clconsole.exe -execute
It should be noted that there were made some important changes to the Corman Lisp recently, but they are internal and should not affect ASDF test suite at all. We probably should add the build of the current development version to the downloads section.
I have uploaded current development version of the Corman Lisp. I think it is better to use this one for any testing purposes.
If you grep -i corman in the ASDF sources, you'll find many workarounds for bugs in Corman Lisp, some of them glaring. Oh, and grep for clozure instead and find all the places where corman support is missing.
If anyone feels like hacking Corman Lisp, that would be a good place to start.
Of course, once you're done, (1) push the modifications / simplifications / fixes to ASDF upstream and (2) include a pristine updated ASDF in Corman Lisp so it can be provided by (require "asdf") and if possible also (require "ASDF").