Hi!
Every time I read "asdf", I feel a pain. I've read that there is an
attempt to gain resources to improve asdf. I have a sort of plan.
1. Shims. Recent tightening of rules for system definitions is ok, but
there are old systems with no maintainers. If such system does not
obey the rules, one
Hi! Where the document is found?
2018-01-06 3:53 GMT+03:00, Robert Goldman :
> I just pushed an edit of syntax-control.md in which I try to capture the
> terminology.
>
> Status: several Allegro failures break for me on test-syntax-control.
> Results from Linux:
>
>
Hi!
Nicolas, can you resolve source locations at SWANK level? E.g.
functions like SWANK/SBCL::SOURCE-FILE-SOURCE-LOCATION might be
appropriate for patching: you take the location that SBCL gives you,
but then redirect SWANK to other place. I guess this is not the only
place you have to patch, it
Hi! My 2 cents (a draft for a proposal).
1. As I said, there should be a way to set up tracing and maybe
assertable preconditions that should hold before loading the system.
This way we can _diagnose_ what happens. This technique should be
supplied not for newer versions only, but for some old
Wow! Good news.
2017-10-12 21:08 GMT+03:00, Robert Goldman :
> On 12 Oct 2017, at 13:04, Faré wrote:
>
>> For those in a hurry for a fix, here is the merge request:
>> https://gitlab.common-lisp.net/asdf/asdf/merge_requests/85
>
> I will merge this into master, but do not
Warning about modifying standard readtable is issued by SBCL (at least
in my SBCL 1.3.18), please grep for the message in SBCL sources, and
it seem to be introduced in 1.0.24. I took a look at puri's definition
(maybe old, in my local copy of quicklisp) and it looks like it
actually tries to
Warning about modifying standard readtable is issued by SBCL (at least
in my SBCL 1.3.18), please grep for the message in SBCL sources, and
it seem to be introduced in 1.0.24. I took a look at puri's definition
(maybe old, in my local copy of quicklisp) and it looks like it
actually tries to
What about #. ?
I just noticed that touching sources helps a bit to work around this
bug, nothing more. Maybe :force helps too, but I didn't check that.
>Note that I'm not interested in working on this bug at this point, but
>will happily help clean up and merge a patch that you'd submit.
>>> 3. Am I right that
>> 3. Am I right that bug with incorrect system definition which loads
>> "successfully" is not fixed yet? Touching the source would help to
>> work around it.
>>
> But yes, if you have a bug in your .asd file, it's a bug.
I mean just the following known bug in asdf:
; file wrong-system.asd
Hi! Some new thoughts:
1. Sometimes we (developers) fail to describe system dependencies
correctly. Sometimes we just don't know the exact dependency graph.
But we feel that something is wrong with A system. Just deleting fasls
or touching the source or specific system helps to diagnose this.
2.
Hi!
Maybe :force works well now, but I had problems with it in the past
(don't remember which problems exactly). TANIGUCHI Masaya, you can
consult asdf source as the "canonical" example of operations.
Hi Masaya, list!
I use batch file which deletes all fasl files to do complete
cleanup. If I wanted to force recompilation of a particular system, I
would just "touch" all files.
See also
https://en.wikibooks.org/wiki/Common_Lisp/External_libraries/ASDF/Budden's_infrequently_asked_questions
Hi!
This works for me with asdf 3.1.6
https://en.wikibooks.org/wiki/Common_Lisp/External_libraries/ASDF/Budden%27s_infrequently_asked_questions#How_do_I_make_portable_lisp_program_with_it.27s_own_fasl_cache_in_a_given_directory.3F
Hi!
>In the old days, we would just put
>(asdf:load-system "extension")
That's good. This is declarative enough to be processed by tools like
quicklisp.
What goes to side effects, they are just inevitable if we want
i) asdf to be extensible
ii) some dependency language is used to declarate
Hi!
I added new bugs
https://bugs.launchpad.net/asdf/+bug/1532584
https://bugs.launchpad.net/asdf/+bug/1532586
and reported that bug affects me:
https://bugs.launchpad.net/asdf/+bug/1500578
Hi! I will open the bug, but first of all there seem to be another issue:
My system :s3 :defsystem-depends-on :gro.
I touch some file belonging to :gro.
Then I (asdf:load-system :s3).
Gro is not recompiled.
Is this the same issue or another one?
Should I combine both into one bug report or
Version 3.1.5,
Example system definition:
(defsystem :s3
:components
((cl-user::cons "file-name-does-not-matter")
))
;; eof
I try to load it, it says:
"Error while trying to load definition for system s3 from
pathname c:/clcon/lp/test/s3.asd:
don't recognize component type CONS"
Quote from the manual:
"But for code that you are actively developing, debugging, or
otherwise modifying, you should use load-system, so ASDF will pick on
your modifications and transitively re-build the modified files and
everything that depends on them. "
What does "everything that depends on
I defined variables which show current component and current system.
They can be used by IDEs to navigate to sources, or by your code to do
what you need.
I suggested this as a modification of asdf, but asdf maintainers said
that special variables are dangerous. Maybe.
My code is here:
Hi! I make a "portable file release" of my software. I want that user could just
unpack archive to some "my" directory and than have the software completely
independent from any other possible CL installations on this computer.
I found (too) many words about output translations in asdf manual, but
Hi!
Thanks for the hint. I took a look at sources. Both solutions have
their advantages.
Slime-asdf works in any CL which supports SLIME. My solution works in
SBCL and Lispworks only but does not require SLIME.
Either variant can be prefferred in different situations.
What goes to name
Hi!
SBCL on Windows isn't quite as good (and is not able to call out to CMD.EXE)
I encountered the problem recently, reported a bug and I seem to have
a workaround. Feel free to experiment with it.
https://bugs.launchpad.net/sbcl/+bug/1470500
Hi!
I believe *current-component* is rather innocent
NOT AT ALL.
Design choices is a great topic for holywar :) If variables are not
innocent for you, then you just not accept my patch. I'll continue to
use it for myself. Unfortunately, I have no time and desire to reshape
it, at least in the
I see you mean situation where we have systems
(defsystem Bad2)
(defsystem bAd2)
(defsystem :|baD2|)
In this case we can navigate to :|baD2| by name :bad2, and unable to
navigate to first two systems. Where should I err? According to
coerce-name rules, :|baD2|, :bad2 and bad2 are identical
Why would a file be loaded through the wrong system?
Sorry, I have no time to dig into techical details of that kind. I
believe *current-component* is rather innocent and sometimes useful,
but this is not so important. What I want, is that editing feature
would be available to all asdf users.
I see my previous reply was unclear
It looks like what you are building is an
extension to ASDF
not an extension but a patch
that hooks it into an editor
yes
(perhaps specifically the
lispworks IDE?).
No. I use lispworks IDE for Lispworks and EMACS (via SWANK callback)
for SBCL. EMACS/SWANK
27 matches
Mail list logo