On 20 Jan 2011, at 14:26, Faré wrote:

On 20 January 2011 06:49, Pascal Costanza pc@p-cos.net wrote:

...

It seems that ASDF 2.x doesn't work with RMCL (ASDF 1.x did). Is that a known issue?

What is RMCL? Digitool's MCL? It might very well have bitrotten, since I don't think anyone has tried it since we started working on ASDF 2. I certainly don't have access to a machine capable of running it.

RMCL is being maintained, is available from http://code.google.com/p/mcl/ and runs on current Mac OS X versions. (This is just for information, not a hidden attempt to convince anyone to do the work to make ASDF 2 support it.)

Look for places with #+clozure, and test the functions individually, making sure you have proper code with #+digitool. Also, some places may incorrectly be using #+ccl where #+clozure is meant, and even where it works, it is probably better to use #+(or clozure digitool).

I would be particularly wary of functions created in recent refactorings, such as SUBDIRECTORIES.

If you get it to work, please provide a patch, which I will apply. Also, it is nice if you can run the test suite.

I'll see what I can do, but cannot promise anything for the short run.

Thanks for the quick response!

Pascal

Hi, Pascal

I took some time for this. It seems that the only problem is in function "getenv":

(defun* getenv (x) (#+(or abcl clisp) ext:getenv #+allegro sys:getenv #+clozure ccl:getenv #+(or cmu scl) (lambda (x) (cdr (assoc x ext:*environment-list* :test #'string=))) #+ecl si:getenv #+gcl system:getenv #+lispworks lispworks:environment-variable #+sbcl sb-ext:posix-getenv x))

This function need to support MCL/RMCL. I couldn't find a exist function to get environment variables, so I wrote one using MCL's FFI (define-entry-point):

#+mcl (eval-when (:compile-toplevel :load-toplevel :execute) (ccl:define-entry-point (_getenv "getenv") ((name :string)) :string))

#+mcl (defun %getenv (x) (ccl:with-cstrs ((name x)) (let ((value (_getenv name))) (unless (ccl:%null-ptr-p value) (ccl:%get-cstring value)))))

(If any MCL guru could tell me a easier way to do the same thing, glad to learn it)

Any way, attached patch should fix ASDF 2 on MCL/RMCL, and I do successfully load at least one ASDF system in MCL/ASDF2.

Please confirm my patch.

Regards,

Chun Tian (binghe)

On 20 Jan 2011, at 14:26, Faré wrote:

...

On 20 January 2011 06:49, Pascal Costanza pc@p-cos.net wrote:

...

It seems that ASDF 2.x doesn't work with RMCL (ASDF 1.x did). Is that a known issue?

What is RMCL? Digitool's MCL? It might very well have bitrotten, since I don't think anyone has tried it since we started working on ASDF 2. I certainly don't have access to a machine capable of running it.

RMCL is being maintained, is available from http://code.google.com/p/mcl/ and runs on current Mac OS X versions. (This is just for information, not a hidden attempt to convince anyone to do the work to make ASDF 2 support it.)

...

Look for places with #+clozure, and test the functions individually, making sure you have proper code with #+digitool. Also, some places may incorrectly be using #+ccl where #+clozure is meant, and even where it works, it is probably better to use #+(or clozure digitool).

I would be particularly wary of functions created in recent refactorings, such as SUBDIRECTORIES.

If you get it to work, please provide a patch, which I will apply. Also, it is nice if you can run the test suite.

I'll see what I can do, but cannot promise anything for the short run.

Thanks for the quick response!

Pascal

On 1/20/11 Jan 20 -1:47 PM, Faré wrote:

Based on the patch by Chun Tian, and tests by Robert Goldman, I committed preliminary support for RMCL in ASDF 2.012.3. Things that you may want to debug further:

1- In lisp-version-string, the (subseq s 8) may or may not be warranted anymore. Is there still a big DIGITOOL starting the (lisp-implementation-version) ?

Welcome to Macintosh Common Lisp Version 5.2! ? (lisp-implementation-version) "Version 5.2"

I'm off till the middle of next week, so probably won't have anything useful for a while.

cheers, r

I guess this is going to be a nice exercise in writing portable programs... ;)

Pascal

On 21 Jan 2011, at 11:29, Pascal Costanza wrote:

Hi,

Thanks a lot to Chun Tian (binghe) and you already!!!

However, it looks like this is going to be a lot more work:

• After loading ASDF and trying to load a system, I get the following error:

...

Error: File #4P"home:" does not exist. While executing: TRUENAME

...which is triggered again by the following:

1 > (truename (user-homedir-pathname))

...

Error: File #4P"home:" does not exist. While executing: TRUENAME

Translating the user-homedir-pathname in a different way yields the following:

2 > (translate-logical-pathname (user-homedir-pathname)) #P"Macintosh HD:Users:costanza:lisp:RMCL 5.2.1:"

This is probably because Mac OS 9 didn't know about home directories.

When I try truename before attempting to load any system, I get the following:

? (truename (user-homedir-pathname)) #P"Macintosh HD:Users:costanza:lisp:RMCL 5.2.1:"

Pascal

On 20 Jan 2011, at 20:47, Faré wrote:

...

Based on the patch by Chun Tian, and tests by Robert Goldman, I committed preliminary support for RMCL in ASDF 2.012.3. Things that you may want to debug further:

1- In lisp-version-string, the (subseq s 8) may or may not be warranted anymore. Is there still a big DIGITOOL starting the (lisp-implementation-version) ?

2- In directory-pathname-p there looks like something funky is happening with :unspecific. If some good soul can identify the issue and provide a fix or workaround, that would be great.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain

-- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

---

asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

On 21 Jan 2011, at 15:17, Faré wrote:

On 21 January 2011 05:31, Pascal Costanza pc@p-cos.net wrote:

...

I guess this is going to be a nice exercise in writing portable programs... ;)

Not for me :-/

...

...

1 > (truename (user-homedir-pathname))

...

Error: File #4P"home:" does not exist. While executing: TRUENAME

Whoa, RMCL seems badly broken. Maybe you should replace TRUENAME with TRUENAMIZE everywhere that matters.

As I said before, this only happens when ASDF 2 is loaded. When ASDF 2 is not loaded, (truename (user-homedir-pathname)) returns a reasonable, although maybe somewhat unusual result.

ASDF 1 worked fine with RMCL.

Pascal

Strange, I do have ASDF2 loaded into RMCL 5.2.1, and just loaded two ASDF packages, but:

? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Snow Leopard:Users:binghe:Lisp:RMCL 5.2.1:"

Seems everything is fine on my side ...

--binghe

在 2011-1-21，18:29， Pascal Costanza 写道：

Hi,

Thanks a lot to Chun Tian (binghe) and you already!!!

However, it looks like this is going to be a lot more work:

• After loading ASDF and trying to load a system, I get the following error:

...

Error: File #4P"home:" does not exist. While executing: TRUENAME

...which is triggered again by the following:

1 > (truename (user-homedir-pathname))

...

Error: File #4P"home:" does not exist. While executing: TRUENAME

Translating the user-homedir-pathname in a different way yields the following:

2 > (translate-logical-pathname (user-homedir-pathname)) #P"Macintosh HD:Users:costanza:lisp:RMCL 5.2.1:"

This is probably because Mac OS 9 didn't know about home directories.

When I try truename before attempting to load any system, I get the following:

? (truename (user-homedir-pathname)) #P"Macintosh HD:Users:costanza:lisp:RMCL 5.2.1:"

2011/1/22 Pascal Costanza pc@p-cos.net:

The reason why I'm having problems is probably because I want to create a setup that works the same for all the Common Lisp implementations that I'm using. (I'm the maintainer of Closer to MOP, and this requires regular testing on several CL implementations, including RMCL, which is still in use by several parties.)

Uh, considering that RMCL has a different idea of what your user-homedir-pathname is than unix-aware Lisps, why not just have two sets of configuration files, one that works on Unix, and one that works for RMCL?

e.g. in your /Users/costanza/.config/common-lisp/source-registry.conf you'd have paths using the Unix names with / as separator, and in your Macintosh HD:Users:costanza:RMCL 5.2.1:.config:common-lisp:source-registry.conf you'd have paths using the Macintosh names with : as separator.

Is that a problem?

If you *really* want to automate conversion, then do just this — automate conversion.

At the moment, there are only two options to make RMCL work with ASDF 2, as far as I can tell. One is to exclusively use logical pathnames, but that requires setting up the same logical pathname translations for all the other CL implementations, as far as I can tell. (Maybe this also has other implications, but I cannot tell, because I haven't dived deeper in that direction.)

IIUC, ASDF2 can very well work with RMCL. The thing that mostly doesn't work is sharing configuration files between implementations that assume Unix-style pathnames and those that assume Mac-style pathnames. And the easy solution is: "don't do it".

Another solution is to use idioms like this in your source-registry.conf: (:tree (#+mcl #p"Macintosh HD:" #-mcl #p"/" "Users" "costanza" "lisp"))

The other option is to use *central-registry*, but one goal for me was to switch to the new recommended configuration options. Referring to section 7.1 of the ASDF user manual, none of the options described there seem to work with RMCL, as far as I can tell, because ASDF 2 seems to make strong assumptions about what physical pathnames are supposed to look like (basically, Unixy), and these assumptions simply don't hold at all for RMCL.

No, I took enormous pains so that ASDF2 shall make no assumption what physical pathnames look like. It either passes pathnames and namestrings directly to the implementation, or, when defining components, it passes pathnames directly and interprets strings using its own portable implementation of Unixy relative pathnames.

It is conceivable that a future ASDF2 should also provide its own portable interpretation of strings in the pathname-designators of source-registry and output-translations. But currently, strings there are just implementation-specific namestring (with the hope that on a current machine, implementations should agree on the syntax, which is not the case between RMCL and other implementations).

I figured out a hack that is workable for me at the moment, which consists of adding the following to my init.lisp for RMCL:

(let ((exp (with-open-file (s #P"Macintosh HD:Users:costanza:.config:common-lisp:source-registry.conf")             (read s))))  (labels ((traverse (exp)             (typecase exp               (cons (case (car exp)                       (:home (push (concatenate                                      'string                                      "Macintosh HD:Users:costanza:"                                      (substitute #: #/ (cadr exp))                                      ":")                                    asdf:*central-registry*))                       (t (traverse (car exp))                          (traverse (cdr exp)))))               (t '()))))    (traverse exp)))

Whatever works for you. Note that you probably want to do something different for :tree and :directory. You could conceivably take the result of your substitution and pass it to asdf:initialize-source-registry; or you could have one source-registry.conf use #. to convert on the fly from the master one.

This converts one particular configuration file into a form that is understood by *central-registry*. The binaries are then stored in some subfolder of the RMCL folder, but that's ok. This is all not beautiful, but it works.

Note that I'm not trying to put any pressure on anybody to fix this for me. I know that such portability issues are very difficult to deal with, and it's already amazing how well ASDF 2 works in that regard.

But please don't remove support *central-registry* in a future version of ASDF, unless you make the rest more portable.

We do not intend to remove support for *central-registry* any time soon. Maybe it'll be deprecated in ASDF3 and removed in ASDF4. Hopefully, XCVB will replace ASDF before then, or we'll all be using R8RS Scheme, or something.

Any comments about what I may be missing, or suggestions for better workarounds, are of course welcome.

If this is the kind of issues you're having, I suppose I should be declaring ASDF2 as now working on RMCL.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Opportunity is missed by most people because it comes dressed in overalls and looks like work. — T. A. Edison

On 23 Jan 2011, at 01:50, Pascal Costanza wrote:

On 22 Jan 2011, at 22:05, Faré wrote:

...

2011/1/22 Pascal Costanza pc@p-cos.net:

...

The reason why I'm having problems is probably because I want to create a setup that works the same for all the Common Lisp implementations that I'm using. (I'm the maintainer of Closer to MOP, and this requires regular testing on several CL implementations, including RMCL, which is still in use by several parties.)

Uh, considering that RMCL has a different idea of what your user-homedir-pathname is than unix-aware Lisps, why not just have two sets of configuration files, one that works on Unix, and one that works for RMCL?

I prefer to have a single configuration file, so I don't have to maintain different configuration files in parallel.

I switched to a solution where the configuration file uses exclusively logical pathnames. In all CL implementations I set up logical pathnames translations both for source and fasl files, for example like this:

(setf (logical-pathname-translations "costanza") `(("**;*.xfasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.xfasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*")))

The configuration file consists of entries such as this:

(:directory "costanza:lisp;develop;closer;contextl")

In two implementations, I encountered problems, namely ECL and RMCL.

In ECL, there seems to be a problem with ensure-directories-exist when invoking it on logical pathnames. The following patch solved this issue for me:

(defmethod asdf:perform :before ((o asdf:compile-op) (c asdf:source-file)) (loop for file in (asdf:output-files o c) for pathname = (if (typep file 'logical-pathname) (translate-logical-pathname file) file) do (ensure-directories-exist pathname)))

My guess is this should be fixed in ECL rather than in ASDF.

In RMCL, I have to make sure that the home directory is never touched, because I can't get RMCL and ASDF to agree what the notion of a home directory actually means. The only way I seem to be able to make this work is by initializing the source registry explicitly as follows:

(asdf:initialize-source-registry (with-open-file (s "Macintosh HD:Users:costanza:.config:common-lisp:source-registry.conf") (read s)))

...and by having the configuration end in this:

#-mcl :inherit-configuration #+mcl :ignore-inherited-configuration

I have the feeling that this is all more complicated than strictly necessary.

Anyway, thanks a lot for the help.

Pascal