gmane.lisp.asdf.devel

Re: Various issues

Robert Goldman — 2012-05-24T15:21:30

I believe I disagree:  I don't think that the user of ASDF should have
to know that this is done using DESTRUCTURING-BIND --- that's a species
of data UN-abstraction.  It's also something that is difficult to
capture clearly in the defsystem grammar (because "there is only one
copy of each keyword" is not a context free grammar).  So I think if we
can help the user, that would be a good thing, and better than quietly
throwing something on the floor.

But I think that makes it up to me to propose a patch, rather than
expect anyone else to do it!  So I will see if I can make one.

Cheers,
r

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: Various issues

Faré — 2012-05-24T15:12:43

I don't know that it's a bug. As Stelian mentioned,
we're using destructuring-bind and/or apply 'make-instance,
and that's the normal behavior in these cases.
I think we should just document this behavior,
and NOT try to catch and raise an error in the case of repeated keys.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
To fight a violent enemy, violence is necessary;
but to fight violence itself, violence is vain.

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: Various issues

Tobias C Rittweiler — 2012-05-24T15:01:55

In article <4FBE3BC7.7090505-+bU95EEGNjthl2p70BpVqQ< at >public.gmane.org>,
 Robert Goldman <rpgoldman-+bU95EEGNjthl2p70BpVqQ< at >public.gmane.org> 
 wrote:


Yes ignoring the second clause was what happened on SBCL.

I will submit a ticket.

T

Re: Various issues

Robert Goldman — 2012-05-24T13:46:47

Tobias, does ASDF just take the first and quietly throw later ones on
the floor, or does it at least emit an error message?  If it emits an
error message, I think it's ok.  But if it quietly discards the second
clause, I think it's a bug, and we should make ASDF warn the programmer.
 I'd encourage you to post a launchpad bug in that case.

Sorry to bother asking you instead of just testing --- I'm traveling and
not in a good position to test anything.  Similarly not a great time for
me to make launchpad bugs.

cheers,
r

Re: Various issues

Stelian Ionescu — 2012-05-24T09:54:29

More or less, since a module's properties is parsed using
destructuring-bind, which has undefined consequences in case of
duplicate keywords


No


Static files are simply ignored. Usually used for "assets": images, css
files, etc...

:file is an alias for the current DEFSYSTEM's :default-component-class,
which if absent defaults to asdf:cl-source-file.
Example of non-standard default class:
https://github.com/sionescu/iolib/blob/master/src/iolib.os.asd


Maybe :if-component-dep-fails could be used to that purpose, or
madeira-port

Various issues

Tobias C Rittweiler — 2012-05-24T09:13:35

Hi there!

Thanks to the ASDF maintainers. I just visited ASDF's website
on common-lisp.net since a long time, and it makes a nicely
maintained impression! Well done.

I have the following issues:

  * The rather old ASDF version that I'm using ("2.010") does
    not seem to be able to cope with multiple :depends-on clauses.
    (Only one clause seems to be used.)

    Is this intended behaviour? Might it be fixed in more recent
    versions?

  * :STATIC-FILE (and :FILE for that matter) are not discussed
    or explained in the manual.

  * We generate a 'version.lisp' with a (DEFPARAMETER ...) form
    in it when using "make" to build a Lisp binary using buildapp.
    
    Is there a component that loads a file if it exists and
    if it does not exist just skips the clause?

Thanks,

T

Re: asdf-bundle

Mark Evenson — 2012-05-18T13:32:06

[…]


ABCL has [ASDF-JAR][1] in ABCL-CONTRIB, which will recursively package 
all the necessary components to run an ASDF system into a jar archive.

We'll look at supporting the ASDF-BUNDLE interface when I get a chance, 
although we are doing somewhat different things here.

[1]: 
http://trac.common-lisp.net/armedbear/browser/trunk/abcl/contrib/asdf-jar/README.markdown

Tests on Mac OS X

Robert Goldman — 2012-05-17T14:26:17

I tested on the following lisps

ccl clisp sbcl ecl abcl allegro allegromodern

with success.  Haven't tried on CMUCL yet, because of prior problems.  I
will see about picking up a snapshot sometime.

Re: lisp source debugger

Robert Goldman — 2012-05-12T22:24:10

Ditto.  TRACE is your friend, particularly TRACE with some of the more
exotic options, such as


(TRACE (<POSSIBLY-BAD-FUNCTION> :INSIDE <LOCATION-OF-BUG>))

where <LOCATION-OF-BUG> is the location that you get from Allegro
telling you where your program failed.  There should be a relatively
small number of function calls inside this function, if you lisp is
written normally (typically no multi-page functions, although there are
always exceptions).

Also, you should be able to investigate *from inside the debugger*.  If
there's a function call (FOO X Y) inside the function that's breaking,
execute (FOO X Y) within the debugger, first checking to see what X and
Y are in this stack frame, and see what happens.  Repeat until your bug
is found ;-)

r



_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: lisp source debugger

Faré — 2012-05-12T22:14:25

Which implementation are you using?
SLIME on SBCL can give you source location,
even inside internal functions (from labels or flet or lambda).
Be sure to compile with (safety 3) (debug 3) (speed 1) or so.

That said, this is not the most appropriate forum for this question.
After you try the above, ask for help on #lisp, stackoverflow,
comp.lang.lisp, etc.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Gilb's Law: Anything you need to quantify can be measured in some way
that is superior to not measuring at all.

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

lisp source debugger

Yuan Luo — 2012-05-12T22:08:46

Hi,
This maybe an irrelevant question, if so, please point me to the best list
to ask. But I am wondering whether you guys can recommend some source level
debugger that can POINT ME PRECISELY to where the error was. For example,
Allegro CL cannot because many times it tells me that there is an error in
a function, but it doesn't tell me which line even if I set their debug
flag to 3 the highest level and suppressed everything else, speed,
optimization etc. (my function has hundreds of lines then I am frustrated
...)

Best,
Yuan
_______________________________________________
asdf-devel mailing list
asdf-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: :default-component-class and custom module classes

Faré — 2012-05-07T11:12:34

On Mon, May 7, 2012 at 12:22 AM, Nikodemus Siivola
<nikodemus< at >random-state.net> wrote:
ASDF has been using the more traditional method (however arguably less flexible)
of specifying default values via initform.

So, in your module class's defclass, use
  (default-component-class :initform 'my-component-class)

Does that do what you want?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Don't ask me to fix your computer. I'm a software engineer; I break computers.
        — Mark Pauley

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

:default-component-class and custom module classes

Nikodemus Siivola — 2012-05-07T04:22:29

I was trying to make a custom module class, which would have provided
its own :DEFAULT-COMPONENT-CLASS via
:DEFAULT-INITARGS, but

        (setf (module-default-component-class ret)
              (or default-component-class
                  (and (typep parent 'module)
                       (module-default-component-class parent))))

means that does work as I hoped it would. The closest I can get is by
overriding ASDF::MODULE-DEFAULT-COMPONENT-CLASS method, but that seems
fairly icky.

Is there a better way?

Cheers,

 -- Nikodemus

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: Reloading a .asd

Faré — 2012-05-06T22:25:52

Oh, well, if you want more robustness, you could redefine or advise
   search-for-system-definition
that already has such a trick to introduce a function at the beginning
of the list
(put there to avoid infinite loops, as used to happen in some edge cases
with quicklisp and other systems).
And if you want the redefinition or advice to be preserved when ASDF
is reloaded,
you could redefine or advise upgrade-asdf.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The worst thing about totalitarian regimes is not that they make people poor,
miserable and unfree — it's that they corrupt people's souls, and turning
everyone into a double-thinking, double-speaking liar for the sake of survival.

_______________________________________________
asdf-devel mailing list
asdf-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: Reloading a .asd

Robert Goldman — 2012-05-06T22:25:37

FWIW, Faré's example, where he has to push /both/ the CFFI path and the
CFFI-UFFI path into the asdf registry shows the risks of this kind of
behavior.

Mightn't it be better to provide an easy SLIME command to modify the
search behavior on the fly, than try to mess around with single-file
patching?  That seems very likely to fail for systems that have nested
or related subsystems (UFFI example, related -test system, etc.).

Cheers,
r

Re: Reloading a .asd

Stelian Ionescu — 2012-05-06T22:15:38

No guarantee in the sense that, after loading the ASDF contrib, the user
might push another function to *system-definition-search-functions* and it
will break. There's no way to guarantee that load-slime-override-sysdef
will always be the first element of *system-definition-search-functions*

Re: Reloading a .asd

Faré — 2012-05-06T22:09:22

No guarantee that my code will work? You can test and debug it;
the underlying API is not going to change.

No guarantee that the notoriously picky SLIME maintainers
will accept a contribution? I can't help you there.

There, I fixed two obvious bugs. Looks like it works:

(in-package :asdf)

(defvar *slime-override-systems* (make-hash-table :test 'equal))

(defun sysdef-slime-override (name)
  (values (gethash (coerce-name name) *slime-override-systems*)))

(defun register-slime-override ()
  (setf asdf:*system-definition-search-functions*
        (cons 'sysdef-slime-override
              (remove 'sysdef-slime-override
*system-definition-search-functions*))))

(defun load-slime-override-sysdef (name pathname)
  (let ((name (coerce-name name))
        (pathname (pathname pathname)))
    (setf (gethash name *slime-override-systems*) pathname)
    (load-sysdef name pathname)))

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Natural laws have no pity.
        — R

Re: Reloading a .asd

Stelian Ionescu — 2012-05-06T21:24:29

Yes, but I'd like to push this as Slime contrib and there's no guarantee
that this will work in any case

Re: Reloading a .asd

Faré — 2012-05-06T21:08:37

As I explained in my previous mail,
it would more be something like what follows (wholly untested),
where in your code you'd
(1) call the register function initially
(2) use load-slime-override-sysdef instead of load-sysdef in your code.

(in-package :asdf)

(defvar *slime-override-systems* (make-hash-table :test 'equal))

(defun sysdef-slime-override (name)
  (values (gethash (coerce-name system) *slime-override-systems*)))

(defun register-slime-override ()
  (setf asdf:*system-definition-search-functions*
        (cons 'sysdef-slime-override
              (remove 'sysdef-slime-override
*system-definition-search-functions*))))

(defun load-slime-override-sysdef (name pathname)
  (let ((name (coerce-name name)))
    (setf (gethash name *slime-override-systems*) pathname)
    (load-sysdef name pathname)))

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"I believe that sex is one of the most beautiful, natural, wholesome things
that money can buy." — Steve Marti

Re: Reloading a .asd

Stelian Ionescu — 2012-05-06T20:29:03

I only want to put a system into "manual" mode, and make sure that
find-system never overrides that no matter what. How about adding an
optional third parameter to load-sysdef that sets a "definitivep" flag
in the system, which makes find-system to never search it on the
file-system any more ?

Re: Reloading a .asd

Faré — 2012-05-06T20:05:59

Yes, with a catch: IF there's a system in your
central-registry, source-registry, quicklisp registry,
or wherever locate-system will find it,
then that OTHER system will be found by the next find-system,
as called whenever you try to compile it.

So load-sysdef will only help you define a system
that CANNOT be found by locate-system.

What if you want to override what locate-system finds?
Well, then override your source-registry,
by exporting CL_SOURCE_REGISTRY,
or giving an explicit parameter to asdf:initialize-source-registry.
And the system is located by some other hook that has precedence
over the source-registry (e.g. *central-registry*), then
it's your responsibility to properly configure that hook.

If the session is well-defined enough to have some initial incantation
or configuration file, I would use something like this to set it up:

(asdf:initialize-source-registry
 '(:source-registry
   (:tree "/path/to/overriding/cffi")
   (:tree "/path/to/other/overriding/library")
   :inherit-configuration))