Hello,
I want to use ASDF with both SBCL and Allegro. Unfortunately, both of them
have a default extension of ".fasl" for the binaries, i.e. they conflict
with each other. MK-DEFSYSTEM has the possibility to redefine the
extension for a project with ":binary-extension"? How is this best done
with ASDF?
Thank you,
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> I want to use ASDF with both SBCL and Allegro. Unfortunately, both of them
> have a default extension of ".fasl" for the binaries, i.e. they conflict
> with each other. MK-DEFSYSTEM has the possibility to redefine the
> extension for a project with ":binary-extension"? How is this best done
> with ASDF?
Try an :around method on asdf:output-files?
Christophe
Christophe Rhodes wrote:
> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
>
>>I want to use ASDF with both SBCL and Allegro. Unfortunately, both of them
>>have a default extension of ".fasl" for the binaries, i.e. they conflict
>>with each other. MK-DEFSYSTEM has the possibility to redefine the
>>extension for a project with ":binary-extension"? How is this best done
>>with ASDF?
>
>
> Try an :around method on asdf:output-files?
Hunh? How does he share a project with someone else who also uses both
implementations? Surely this has to go in the .ASD.
kt
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Not necessarily. By using an :around method, you could condition the
.fasl output to go to an asdf build directory. You could vary the
location depending on the implementation. See my blog entry for an
example of this:
http://bc.tech.coop/blog/041222.html
Cheers,
Bill
········@gmail.com wrote:
> Not necessarily. By using an :around method, you could condition the
> .fasl output to go to an asdf build directory. You could vary the
> location depending on the implementation. See my blog entry for an
> example of this:
> http://bc.tech.coop/blog/041222.html
>
> Cheers,
> Bill
>
This works for me when doing a M-x slime-load-system but is there a
setting for my .emacs file to do the same thing for C-c C-k ?
BA
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
>> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>>
>>>I want to use ASDF with both SBCL and Allegro. Unfortunately, both of them
>>>have a default extension of ".fasl" for the binaries, i.e. they conflict
>>>with each other. MK-DEFSYSTEM has the possibility to redefine the
>>>extension for a project with ":binary-extension"? How is this best done
>>>with ASDF?
>> Try an :around method on asdf:output-files?
>
> Hunh? How does he share a project with someone else who also uses both
> implementations?
In the normal way. Someone else who uses both implementations will
most likely have their own (but doubtless similar) :around method on
asdf:output-files.
> Surely this has to go in the .ASD.
Why? (It /can/ go in the .asd under some models of cooperation, but I
don't see why it /has/ to. And stop calling me "Surely".)
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
>
> Try an :around method on asdf:output-files?
>
> Christophe
Thank you for your answer and I'm sorry for the delay of trying it out (I
participated in a sailing tour to the Isle of Whight:-). What do you think
of the following:
(defmethod output-files :around (operation (c cl-source-file))
(if (equal (component-name (component-system c)) "femlisp")
(list (merge-pathnames (make-pathname
:host nil :device nil :directory nil :name nil
:type #+allegro "afasl" #+cmu "cfasl" #+sbcl "sfasl")
#p"femlisp:src;algebra;sparse.x86f"))
(call-next-method)))
Questions: what if other systems want to do the same trick? Should I
declare this around method only locally and remove it afterwards? (Looks to
me like a good application of Pascal's dynamic functions.)
Yours,
Nicolas
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> Questions: what if other systems want to do the same trick? Should
> I declare this around method only locally and remove it afterwards?
It's not logically a property of the system, though -- it's a property
of a particular user's setup. I think being a "good citizen" means
that you should put it in one of your init files, and distribute your
system (if you need to) without any such output-files method.
Or, in other words, what is so special about your _system_ that needs
this, and what is special about your general lisp environment?
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
>
>> Questions: what if other systems want to do the same trick? Should
>> I declare this around method only locally and remove it afterwards?
>
> It's not logically a property of the system, though -- it's a property
> of a particular user's setup. I think being a "good citizen" means
> that you should put it in one of your init files, and distribute your
> system (if you need to) without any such output-files method.
>
> Or, in other words, what is so special about your _system_ that needs
> this, and what is special about your general lisp environment?
>
> Christophe
First, thanks for the answers (also to Thomas).
Second: (To recall: my problem was that Allegro and SBCL both use the
.fasl-extension and with my current setup I cannot painlessly switch
between them.) Putting an :around-method for OUTPUT-FILES in my .sbclrc
which clobbers "*.fasl" for SBCL would give difficulties when precompiled
Debian packages have to be loaded. Maybe it works when I only define this
method for Allegro (which, however, could use ASDF as well).
In any case, I would very much prefer not having to tell Femlisp users that
they have to write such :around methods for their init files. Or should we
expect that someone wanting to switch between different CLs is expert
enough?
Nicolas.
Nicolas Neuss wrote:
omas).
>
> Second: (To recall: my problem was that Allegro and SBCL both use the
> .fasl-extension and with my current setup I cannot painlessly switch
> between them.)
As a simple solution, how about just creating another user account
and run ACL in one and SBCL in the other? If you have some development
files with the same problem create a development directory symbolically
linked to the src from each user account and each with its own FSL directory.
Wade
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> Second: (To recall: my problem was that Allegro and SBCL both use
> the .fasl-extension and with my current setup I cannot painlessly
> switch between them.) Putting an :around-method for OUTPUT-FILES in
> my .sbclrc which clobbers "*.fasl" for SBCL would give difficulties
> when precompiled Debian packages have to be loaded. Maybe it works
> when I only define this method for Allegro (which, however, could
> use ASDF as well).
Well, really you should only do this for packages which you control:
that is, you could test that their location is somewhere writeable by
you the user. However, I think this situation has a slight extra
problem, in that it is easy to overwrite rather than extend the method
on output-files that debian provides. This is an ideal situation for
a custom method combination, but the lack of custom method combination
support in released versions of certain lisps prevents implementing
this, so a workaround is to find the method provided by
common-lisp-controller, and be careful to use a slightly different
specialization -- if it specializes on (compile-op t), you should
specialize on (compile-op cl-source-file), and vice-versa.
> In any case, I would very much prefer not having to tell Femlisp
> users that they have to write such :around methods for their init
> files. Or should we expect that someone wanting to switch between
> different CLs is expert enough?
Again, it's not "Femlisp users", unless there's something
fundamentally different about Femlisp than every other lisp package
out there: it's "users of more than one lisp implementation with
colliding fasl-file extension". As such, unless Femlisp is the only
lisp package your users have installed, /and/ they want to use both
Allegro and SBCL, they will already have solved this problem.
Christophe
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> First, thanks for the answers (also to Thomas).
>
> Second: (To recall: my problem was that Allegro and SBCL both use the
> .fasl-extension and with my current setup I cannot painlessly switch
> between them.) Putting an :around-method for OUTPUT-FILES in my .sbclrc
> which clobbers "*.fasl" for SBCL would give difficulties when precompiled
> Debian packages have to be loaded. Maybe it works when I only define this
> method for Allegro (which, however, could use ASDF as well).
I am just evaluating the method mentioned by Bill Clementson, which was
posted in November to comp.lang.lisp by Bjoern Lindberg:
http://groups-beta.google.com/group/comp.lang.lisp/msg/bd5ea9d2008ab9fd
Could be that this is what I really need. Who else uses it? Any problems?
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>>
>> Try an :around method on asdf:output-files?
>>
>> Christophe
>
> Thank you for your answer and I'm sorry for the delay of trying it out (I
> participated in a sailing tour to the Isle of Whight:-). What do you think
> of the following:
>
> (defmethod output-files :around (operation (c cl-source-file))
> (if (equal (component-name (component-system c)) "femlisp")
> (list (merge-pathnames (make-pathname
> :host nil :device nil :directory nil :name nil
> :type #+allegro "afasl" #+cmu "cfasl" #+sbcl "sfasl")
> #p"femlisp:src;algebra;sparse.x86f"))
> (call-next-method)))
>
Oh, this was my testing version:-( Correction:
(defmethod output-files :around (operation (c cl-source-file))
(if (equal (component-name (component-system c)) "femlisp")
(list (merge-pathnames (make-pathname
:host nil :device nil :directory nil :name nil
:type #+allegro "afasl" #+cmu "cfasl" #+sbcl "sfasl")
(first (call-next-method))))
(call-next-method)))
> Questions: what if other systems want to do the same trick? Should I
> declare this around method only locally and remove it afterwards? (Looks to
> me like a good application of Pascal's dynamic functions.)
Nicolas.
Nicolas Neuss <·······@iwr.uni-heidelberg.de> writes:
> Oh, this was my testing version:-( Correction:
>
> (defmethod output-files :around (operation (c cl-source-file))
> (if (equal (component-name (component-system c)) "femlisp")
> (list (merge-pathnames (make-pathname
> :host nil :device nil :directory nil :name nil
> :type #+allegro "afasl" #+cmu "cfasl" #+sbcl "sfasl")
> (first (call-next-method))))
> (call-next-method)))
>
> > Questions: what if other systems want to do the same trick?
Subclass cl-source-file, and use that in your system instead
> > Should I
> > declare this around method only locally and remove it afterwards? (Looks to
> > me like a good application of Pascal's dynamic functions.)
That sounds like massive overkill to me.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Well, a general comment.
When we faced situations like this using DEFSYSTEM, instead of changing
the binary extension depending on which lisp compiler, we would change
the binary directory. In essence, we had a number of binary
directories, based on Lisp implmentation and version. Something like:
bin/acl6.2-sparc
bin/acl6.2-hp
bin/acl6.2-linux
bin/acl7.0
bin/cmucl18
bin/lw4.2
bin/mcl5.0
etc.
This worked particularly well with supporting multiple versions of a
particular lisp implmementation (useful during transition to new
software versions) and also for supporting multiple hardware
architectures from a central file server.
I also note that there are some lisps that don't like having it changed,
since they use the name to decide whether to use the compiled file
loader or the source loader. IIRC LispWorks is one, so you either have
to leave the extension alone or use a utility function to declare the
new extension to be a binary one.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> [useful remarks (concerning fasls in separate directories)]
Yes, this sounds very reasonable, and I think I will also go in this
direction. A problem which I see is making SLIME recognize this. Did
someone solve this already?
Thanks, Nicolas.