cclan-list — Discussions of all things CCLAN

[cclan-list] small patch for asdf output

[Gary K. <gw...@me...>]

The patch below moves asdf status output into a single function, asdf- 
message, and uses this to print whatever ASDF prints.

It also moves a comment about CMUCL out into a separate function and  
uses enough-namestring when not running on CMUCL.

If no-one has objections, I'll commit in a few days.

Index: asdf.lisp
===================================================================
RCS file: /cvsroot/cclan/asdf/asdf.lisp,v
retrieving revision 1.129
diff -u -w -r1.129 asdf.lisp
--- asdf.lisp	4 Oct 2008 22:41:04 -0000	1.129
+++ asdf.lisp	5 Oct 2008 19:46:02 -0000
@@ -150,6 +150,10 @@
  (define-modify-macro appendf (&rest args)
    append "Append onto list")

+(defun asdf-message (message &rest args)
+  (declare (dynamic-extent args))
+  (apply #'format *verbose-out* message args))
+
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;; classes, condiitons

@@ -399,6 +403,15 @@
            (package (try counter) (try counter)))
           (package package))))

+;;; special handling for cmucl
+;; FIXME: This wants to be (ENOUGH-NAMESTRING
+;; ON-DISK), but CMUCL barfs on that.
+(defun asdf-enough-namestring (it)
+  #+cmucl
+  it
+  #-cmucl
+  (enough-namestring it))
+
  (defun find-system (name &optional (error-p t))
    (let* ((name (coerce-name name))
           (in-memory (system-registered-p name))
@@ -409,12 +422,9 @@
        (let ((package (make-temporary-package)))
          (unwind-protect
               (let ((*package* package))
-               (format
-                *verbose-out*
+	       (asdf-message
                  "~&~@<; ~@;loading system definition from ~A into  
~A~@:>~%"
-                ;; FIXME: This wants to be (ENOUGH-NAMESTRING
-                ;; ON-DISK), but CMUCL barfs on that.
-                on-disk
+                (asdf-enough-namestring on-disk)
                  *package*)
                 (load on-disk))
            (delete-package package))))
@@ -425,7 +435,7 @@
            (if error-p (error 'missing-component :requires name))))))

  (defun register-system (name system)
-  (format *verbose-out* "~&~@<; ~@;registering ~A as ~A~@:>~%" system  
name)
+  (asdf-message "~&~@<; ~@;registering ~A as ~A~@:>~%" system name)
    (setf (gethash (coerce-name name) *defined-systems*)
          (cons (get-universal-time) system)))

@@ -812,7 +822,7 @@
    nil)

  (defmethod explain ((operation operation) (component component))
-  (format *verbose-out* "~&;;; ~A on ~A~%" operation component))
+  (asdf-message "~&;;; ~A on ~A~%" operation component))

  ;;; compile-op


--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

[cclan-list] removed load-preferences support from ASDF

[Gary K. <gw...@me...>]

As was discussed several months ago, I have removed load-preferences  
support from ASDF

2007-10-04 10:55  gw...@me...

	Removed preference loading machinery completely. Also removed
	the following test files that tested the machinery.

	* test/test-preferences-1.lisp
	* test/test-preferences-1.script
	* test/test-preferences-system-1.asd
	* test/test-preferences-system-load.lisp
	* test/test-preferences-system-test.lisp
	* test/test6.script
	* test/test7.script

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] ASDF component-self-dependencies

[Gary K. <gw...@me...>]

HI Robert,

I don't know and it doesn't seem to return a non-nil value for any of  
the many systems I just checked. My reading of the code appears to be  
saying something like:

the input files of X, are either the output files of all the self- 
dependencies or X's pathname.

It also seems to me that direct-dependencies would be a better name  
than self-dependencies.

> Also, am I correct in thinking that component-depends-on is a  
> candidate
> for having its standard method combination replaced by append?  Or  
> would
> that be a mistake?

I think so, yes.

HTH,

On Sep 23, 2008, at 3:38 PM, Robert Goldman wrote:

> Does anyone have a clear understanding of the role of this function,  
> and
> its relationship to component-depends-on?  Examination suggests that  
> the
> coder considered the possibility that component-depends-on would
> overgenerate, returning some dependencies that actually didn't match  
> the
> component, and these dependencies would be weeded out by
> component-self-dependencies.  Is that correct?
>
> Anyone know why component-self-dependencies is a generic function?   
> It's
> internal, so I assume that the ASDF extender is not expected to extend
> this generic function.
>
> If someone can clue me in, I will try to write up a documentation  
> string
> that can be inserted into the source....
>
>
> thanks,
> r
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> cclan-list mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclan-list

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

[cclan-list] ASDF component-self-dependencies

[Robert G. <rpg...@si...>]

Does anyone have a clear understanding of the role of this function, and
its relationship to component-depends-on?  Examination suggests that the
coder considered the possibility that component-depends-on would
overgenerate, returning some dependencies that actually didn't match the
component, and these dependencies would be weeded out by
component-self-dependencies.  Is that correct?

Anyone know why component-self-dependencies is a generic function?  It's
internal, so I assume that the ASDF extender is not expected to extend
this generic function.

If someone can clue me in, I will try to write up a documentation string
that can be inserted into the source....

Also, am I correct in thinking that component-depends-on is a candidate
for having its standard method combination replaced by append?  Or would
that be a mistake?

thanks,
r

Re: [cclan-list] Circularity detection fix exposed a bug

[Gary K. <gw...@me...>]

Hi Richard,

test3 still fails for me with this patch.

I don't have time to investigate now.
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] Circularity detection fix exposed a bug

[Gary K. <gw...@me...>]

Hi Richard,

I've been meaning to post about this for the last two days but hadn't  
found the time to look for a fix yet. I'm glad you beat me to it!

On Sep 9, 2008, at 10:48 AM, Richard M Kreuter wrote:

> After the circularity detection patch applied in 1.125, test3 fails  
> with
> a spurious CIRCULAR-DEPENDENCY error.  I think the trouble is that
> TRAVERSE fails to unvisit an operation/component pair at least for
> feature-dependencies, and maybe elsewhere.  The patch below does the
> un-visiting in an UNWIND-PROTECT cleanup, so should ensure that ASDF
> always unvisit as desired.  All the tests pass with this change, but  
> I'm
> not really confident about anything TRAVERSE-related.  Does this look
> like a reasonable thing to do?


I think your fix makes good sense. I'll try it with my systems and  
then if no one else objects, I'll commit it.

I wonder if we're close to the time to rewrite traverse and friends  
with generic functions (since all the lisps we love now handle method  
combinations...).

thanks
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

[cclan-list] Circularity detection fix exposed a bug

[Richard M K. <kr...@pr...>]

Hi,

After the circularity detection patch applied in 1.125, test3 fails with
a spurious CIRCULAR-DEPENDENCY error.  I think the trouble is that
TRAVERSE fails to unvisit an operation/component pair at least for
feature-dependencies, and maybe elsewhere.  The patch below does the
un-visiting in an UNWIND-PROTECT cleanup, so should ensure that ASDF
always unvisit as desired.  All the tests pass with this change, but I'm
not really confident about anything TRAVERSE-related.  Does this look
like a reasonable thing to do?

Thanks,
Richard

--- asdf.lisp	6 Sep 2008 22:57:16 -0000	1.127
+++ asdf.lisp	9 Sep 2008 13:28:30 -0000
@@ -725,45 +725,47 @@
       (if (component-visiting-p operation c)
           (error 'circular-dependency :components (list c)))
       (setf (visiting-component operation c) t)
-      (loop for (required-op . deps) in (component-depends-on operation c)
-            do (do-dep required-op deps))
-      ;; constituent bits
-      (let ((module-ops
-             (when (typep c 'module)
-               (let ((at-least-one nil)
-                     (forced nil)
-                     (error nil))
-                 (loop for kid in (module-components c)
-                       do (handler-case
-                              (appendf forced (traverse operation kid ))
-                            (missing-dependency (condition)
-                              (if (eq (module-if-component-dep-fails c) :fail)
-                                  (error condition))
-                              (setf error condition))
-                            (:no-error (c)
-                              (declare (ignore c))
-                              (setf at-least-one t))))
-                 (when (and (eq (module-if-component-dep-fails c) :try-next)
-                            (not at-least-one))
-                   (error error))
-                 forced))))
-        ;; now the thing itself
-        (when (or forced module-ops
-                  (not (operation-done-p operation c))
-                  (let ((f (operation-forced (operation-ancestor operation))))
-                    (and f (or (not (consp f))
-                               (member (component-name
-                                        (operation-ancestor operation))
-                                       (mapcar #'coerce-name f)
-                                       :test #'string=)))))
-          (let ((do-first (cdr (assoc (class-name (class-of operation))
-                                      (slot-value c 'do-first)))))
-            (loop for (required-op . deps) in do-first
-                  do (do-dep required-op deps)))
-          (setf forced (append (delete 'pruned-op forced :key #'car)
-                               (delete 'pruned-op module-ops :key #'car)
-                               (list (cons operation c))))))
-      (setf (visiting-component operation c) nil)
+      (unwind-protect
+          (progn
+            (loop for (required-op . deps) in (component-depends-on operation c)
+                  do (do-dep required-op deps))
+            ;; constituent bits
+            (let ((module-ops
+                   (when (typep c 'module)
+                     (let ((at-least-one nil)
+                           (forced nil)
+                           (error nil))
+                       (loop for kid in (module-components c)
+                             do (handler-case
+                                    (appendf forced (traverse operation kid ))
+                                  (missing-dependency (condition)
+                                    (if (eq (module-if-component-dep-fails c) :fail)
+                                        (error condition))
+                                    (setf error condition))
+                                  (:no-error (c)
+                                    (declare (ignore c))
+                                    (setf at-least-one t))))
+                       (when (and (eq (module-if-component-dep-fails c) :try-next)
+                                  (not at-least-one))
+                         (error error))
+                       forced))))
+              ;; now the thing itself
+              (when (or forced module-ops
+                        (not (operation-done-p operation c))
+                        (let ((f (operation-forced (operation-ancestor operation))))
+                          (and f (or (not (consp f))
+                                     (member (component-name
+                                              (operation-ancestor operation))
+                                             (mapcar #'coerce-name f)
+                                             :test #'string=)))))
+                (let ((do-first (cdr (assoc (class-name (class-of operation))
+                                            (slot-value c 'do-first)))))
+                  (loop for (required-op . deps) in do-first
+                        do (do-dep required-op deps)))
+                (setf forced (append (delete 'pruned-op forced :key #'car)
+                                     (delete 'pruned-op module-ops :key #'car)
+                                     (list (cons operation c)))))))
+        (setf (visiting-component operation c) nil))
       (visit-component operation c (and forced t))
       forced)))
 

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Tobias C. R. <tc...@fr...>]

Christophe Rhodes <cs...@ca...> writes:

> I also think that the try-recompiling restart for compile-op is
> useless, because asdf already sets up a retry restart; I'd like to
> delete it, but I have a sneaking suspicion that someone will complain
> if I do.  If I don't hear confirmation about that, I'll delete it
> anyway and suck up the consequences.

FWIW, I'd really like to see a RECOMPILE-ALL restart if that's possible.

  -T.

[cclan-list] operation-done-p (test-op system)

[Gary K. <gw...@me...>]

I just applied Luís Oliveira's patch that supplies a default method  
for operation-done-p (test-op system).

(it's only been 9-months... sheesh).


--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Gary K. <gw...@me...>]

> "Attila Lendvai" <att...@gm...> writes:
>
>>> I also think that the try-recompiling restart for compile-op is
>>> useless, because asdf already sets up a retry restart
...
>
>> does the original retry restart always recompile? i think sometimes  
>> it
>> happens that the file actually compiles but with some warning
...
>
> The annoying case is when compile-op succeeds (no compilation errors
> or full warnings) but the subsequent load-op signals an error (say
> because some class is not yet defined).  At that point, the retry
> restart will attempt to reload the fasl -- not completely useless, but
> needing a little bit more manual intervention.  It is for removing
> that manual intervention that the try-recompiling restart is most
> useful, I think; simply edit the source file and select that restart.
> But for compile-op failures, I think the TRY-RECOMPILING and RETRY
> restarts have equivalent behaviour.
>

Yes.

I use "try recompiling" a fair amount when in exactly this situation  
(the compile went fine; the load failed). It seems that it should be  
possible to know whether we're loading or compiling and not include  
the restart in the latter case. That would be a good thing, yes?

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Gary K. <gw...@me...>]

> I don't think a patch came out, did it?  In any case, I prefer the
> approach (attached) of using a slightly non-standard method
> combination, which we can now do because all CLs anyone cares about
> support them.  The idea is that asdf:around methods are for internal
> use, and ordinary :around methods are the user-frobbable protocol
> hooks.

You're right that the patch never arrived (<hangs head in shame>).

I think using the method combination is a _great_ idea.

> I also think that the try-recompiling restart for compile-op is
> useless,

I'll respond to this in my next e-mail.

> When testing these changes (which also include Richard Kreuter's
> circularity detection patch), test5.script failed for me, saying that
> :load-only-p was an unknown initarg.

This was my bad; I added the test ages ago go back when we almost  
added load-only files to asdf but I never removed the test. I'll do  
that later today (<he says hopefully>).

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] asdf and relative names

[F. <fa...@gm...>]

2008/9/4 Richard M Kreuter <kr...@pr...>:
> Fair enough.  As I said, I don't object to your way of doing things, but
> I think I can think of 3 ways to acheive the desired effect without your
> patch:
>
> (1) Use modules for subdirectories, unless you need files in one
>    directory depending on files in another
>
We tried that at ITA. In a large body of code that gets constantly
refactored by tens of hackers, where dependencies are not clear and
not manageable (see the XCVB whitepaper about it), this is just not
practicable.

> (2) Supply a :pathname argument to the component's initializer, and use
>    sharp-dot to parse the string as you desire, e.g.,
We've used that a-plenty at ITA. It's very painful, redundant, and
still not portable.

> (3) Subclass SOURCE-FILE with a class that accepts an initarg for a file
>    specification string which you can then parse your own way no later
>    than COMPONENT-RELATIVE-PATHNAME.
We've used that, too. It's painful, and only used in special cases,
when my patch removes the pain and makes the feature available to
everyone.

Why not just offer relative pathnames to all ASDF users at all times?
Once again, it is ALREADY true that ASDF proposes its own non-portable
layer for component naming, only said layer won't currently handle
relative paths for you, and #\/ is forbidden from portable ASD files.
The proposed extension is thus conservative. 100% gain, and I already
paid the pain of writing, and it's been used at ITA for over a year on
a big project, so can be considered reasonably field-tested.

The only issue I see is the common bane of all extensions: that when
people start relying on it, they will need to upgrade their ASDF.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The naturalistic fallacy: "if it's natural, it's good."
The anti-naturalistic fallacy: "if it's natural, it's bad."
The a-naturalistic fallacy: "nature has no relationship to good and bad."

Re: [cclan-list] asdf and relative names

[Richard M K. <kr...@pr...>]

"Faré" writes:
> 2008/9/4 Richard M Kreuter <kr...@pr...>:
> >
> > Oh.  I thought you were reasoning that because practical portability
> > nowadays means porting among Lisps on platforms that all treat #\/
> > as a directory separator, ASDF might as well do so, too.
>
> and treat any character escaping (or lack thereof) portably across
> implementations. So that I can have a module named "foo/quux-V1.234"
> or a file component named "bar_fly/baz-1.234" (implicitly .lisp,
> :newest) and it will do the right thing.

Fair enough.  As I said, I don't object to your way of doing things, but
I think I can think of 3 ways to acheive the desired effect without your
patch:

(1) Use modules for subdirectories, unless you need files in one
    directory depending on files in another (IIRC, intercomponent
    dependencies are effectively scoped to the component's containing
    module.)

(2) Supply a :pathname argument to the component's initializer, and use
    sharp-dot to parse the string as you desire, e.g.,

    (defsystem foo
     :components ((:file "bar"
                   :pathname #.(my-string-parser "foo/bar/baz-1.2.3"))))

(3) Subclass SOURCE-FILE with a class that accepts an initarg for a file
    specification string which you can then parse your own way no later
    than COMPONENT-RELATIVE-PATHNAME.

--
Richard,
who isn't even a cCLan committer,
and so should probably be ignored

Re: [cclan-list] asdf and relative names

[F. <fa...@gm...>]

2008/9/4 Richard M Kreuter <kr...@pr...>:
> Oh.  I thought you were reasoning that because practical portability
> nowadays means porting among Lisps on platforms that all treat #\/ as a
> directory separator, ASDF might as well do so, too.
>
and treat any character escaping (or lack thereof) portably across
implementations. So that I can have a module named "foo/quux-V1.234"
or a file component named "bar_fly/baz-1.234" (implicitly .lisp,
:newest) and it will do the right thing.

> As for portability, if you write a system definition that assumes
> hierarchical file naming but doesn't use logical pathnames <I'll wait
> for the audience to stop laughing>, you're already restricting yourself
> to a subset of the file systems that Lisp's file naming mess was
> intended to accomodate, so the system definition won't be portable in
> the CLHS sense anyway.
Logical pathnames won't help with any of the examples above, which are
dear to me (or at least to ITA). By avoiding PARSE-NAMESTRING, I'm
making ASDF systems using this feature portable (though not
CLHS-portable) to more platforms, including say Genera or MCL
(irrelevant as they may be).

> But it looks as though you're saying that ASDF should supply its own
> abstract file name syntax that resembles and agrees with a de-facto
> portable range of physical pathname namestrings on extant Lisps, but
> that's strictly distinct from physical pathname namestring syntax
> everywhere.  I think that's an aesthetic lose, but I don't oppose it.
>
My interpretation is that ASDF is *already* doing that, only its
current abstract file name syntax doesn't currently support relative
pathnames.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
"Reality is that which, when you stop believing in it, doesn't go away".
                -- Philip K. Dick

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Richard M K. <kr...@pr...>]

Christophe Rhodes writes:

> I prefer the approach (attached) of using a slightly non-standard
> method combination, which we can now do because all CLs anyone cares
> about support them.  The idea is that asdf:around methods are for
> internal use, and ordinary :around methods are the user-frobbable
> protocol hooks.

Ooh, ooh!  Could we take it a bit further and allow parties between
cCLan and the end-user to add more around-like methods with a partial
ordering to ensure that a customizer's method gets invoked around
"upstream" methods?  This way, when SBCL wants to customize ASDF, and
Debian wants to customize SBCL, and the site admin wants to customize
Debian, and the user wants to customize the site configuration, the
customizations will compose, rather than conflict?

(This is one of my biggest gripes with ASDF: a fixed GF protocol and
rivalrous method space leaves only the class hierarchy for
customization.  But while subclassing works well for system authors,
it's tricky for prospective customizers to do the right thing to the
class hierarchy to customize behavior for all ASDF systems the
customizer wants to contribute to.)

If people aren't repelled by this suggestion, I'll write something up
tonight (where "tonight" is in EDT).

--
Richard

Re: [cclan-list] asdf and provide / require

[Gary K. <gw...@me...>]

> I think I came across this once before:
>
> http://article.gmane.org/gmane.lisp.cclan.general/583

excellent; thanks. That'll save me having to do it again!

> What does feature-testing have to do with REQUIRE and PROVIDE (which
> deal with *MODULES*, not *FEATURES*)?


Nothing! Both modules and features are ways of trying to do the right  
thing given the current environment. ASDF doesn't currently provide a  
(convenient) way to load stuff if it isn't there (though it can load  
more stuff if some other stuff _is_ there). The extension to feature  
will help ameliorate this.


--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] asdf and relative names

[Richard M K. <kr...@pr...>]

"Faré" writes:
> 2008/9/3 Richard M Kreuter <kr...@pr...>:
> >>
> >> At ITA, we've been happily using the attached file to allow names
> >> such as "foo/bar/baz" to be used for component names, either
> >> modules or files. It works great for us, and allows to portably use
> >> #\/ to denote relative pathnames where the character was previously
> >> forbidden in portable systems.
> >
> > Why aren't you calling PARSE-NAMESTRING on the string?  Constructing a
> > pathname from substrings you parse manually will yield different
> > results on different Lisps in various cases.
>
> The whole point of the exercise is that for .asd files to be portable,
> you do NOT want to rely on non-portable PARSE-NAMESTRING to interpret
> the relative names of modules and other components. That ASDF should
> interpret / as a directory separator in an implementation-independent
> way is a feature that makes / useful at all in portable .asd files.
> Relying on PARSE-NAMESTRING means that you have to requiring different
> module names on different implementations - which completely defeats
> the purpose.

Oh.  I thought you were reasoning that because practical portability
nowadays means porting among Lisps on platforms that all treat #\/ as a
directory separator, ASDF might as well do so, too.  

As for portability, if you write a system definition that assumes
hierarchical file naming but doesn't use logical pathnames <I'll wait
for the audience to stop laughing>, you're already restricting yourself
to a subset of the file systems that Lisp's file naming mess was
intended to accomodate, so the system definition won't be portable in
the CLHS sense anyway.  (This is why I thought it odd that you didn't
reach for PARSE-NAMESTRING.  I think it turns out that the
PARSE-NAMESTRINGs on implementations of practical consequence already
treat #\/ as a directory separator for all two physical file systems
they talk to, and so your syntax will agree with PARSE-NAMESTRING for
strings whose elements are the already-portable file name characters
plus #\/.)

But it looks as though you're saying that ASDF should supply its own
abstract file name syntax that resembles and agrees with a de-facto
portable range of physical pathname namestrings on extant Lisps, but
that's strictly distinct from physical pathname namestring syntax
everywhere.  I think that's an aesthetic lose, but I don't oppose it.

--
Richard

Re: [cclan-list] Circularity detection broken in ASDF

[Gary K. <gw...@me...>]

Hi Richard,

I've just applied this.

thanks,

On Sep 3, 2008, at 6:27 PM, Richard M Kreuter wrote:

> Hi,
>
> (I tried posting this once before, but gmane and sourceforge seem to
> disagree about what got through.  I've subscribed now.)
>
> It seems that circularity detection is broken in asdf 1.123 and
> therabouts.  Patch attached.
>
> Demonstration:
>
> * (require "ASDF")
>
> ("ASDF")
> * (progn
>   (with-open-file (f "0.lisp" :direction :output :if- 
> exists :supersede)
>     (print 'foo f))
>   (with-open-file (f "1.lisp" :direction :output :if- 
> exists :supersede)
>     (print 'bar f))
>   nil)
>
> NIL
>
> * (asdf:defsystem circ
>   :pathname *default-pathname-defaults*
>   :components ((:file "0" :depends-on ("1"))
>                (:file "1" :depends-on ("0"))))
>
> #<ASDF:SYSTEM "circ" {10025620C1}>
> * (asdf:oos 'asdf:compile-op "circ")
> Control stack guard page temporarily disabled: proceed with caution
>
> debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread  
> #<THREAD "initial thread" {1002450D61}>:
>  Control stack exhausted (no more space for function call frames).   
> This is probably due to heavily nested or infinitely recursive  
> function calls, or a tail call that SBCL cannot or has not optimized  
> away.
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>  0: [ABORT] Exit debugger, returning to top level.
>
> (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
> 0] :a
>
> --
> RmK
>
> < 
> asdf 
> .diff 
> > 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> cclan-list mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclan-list

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

[cclan-list] on using system-registered-p where it can be used.

[Gary K. <gw...@me...>]

The attached diff (which I just committed) replaces calls to gethash  
with calls to system-registered-p


Index: asdf.lisp
===================================================================
RCS file: /cvsroot/cclan/asdf/asdf.lisp,v
retrieving revision 1.123
diff -u -w -r1.123 asdf.lisp
--- asdf.lisp	5 Jul 2008 02:57:20 -0000	1.123
+++ asdf.lisp	4 Sep 2008 12:55:13 -0000
@@ -375,7 +375,7 @@
      (or
       (some (lambda (x) (funcall x system-name))
  	   *system-definition-search-functions*)
-     (let ((system-pair (gethash system-name *defined-systems*)))
+     (let ((system-pair (system-registered-p system-name)))
         (and system-pair
  	    (system-source-file (cdr system-pair)))))))

@@ -407,7 +407,7 @@

  (defun find-system (name &optional (error-p t))
    (let* ((name (coerce-name name))
-         (in-memory (gethash name *defined-systems*))
+         (in-memory (system-registered-p name))
           (on-disk (system-definition-pathname name)))
      (when (and on-disk
                 (or (not in-memory)
@@ -424,7 +424,7 @@
                  *package*)
                 (load on-disk))
            (delete-package package))))
-    (let ((in-memory (gethash name *defined-systems*)))
+    (let ((in-memory (system-registered-p name)))
        (if in-memory
            (progn (if on-disk (setf (car in-memory) (file-write-date  
on-disk)))
                   (cdr in-memory))
@@ -438,6 +438,7 @@
  (defun system-registered-p (name)
    (gethash (coerce-name name) *defined-systems*))

+
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  ;;; finding components


--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Christophe R. <cs...@ca...>]

"Attila Lendvai" <att...@gm...> writes:

>> I also think that the try-recompiling restart for compile-op is
>> useless, because asdf already sets up a retry restart; I'd like to
>> delete it, but I have a sneaking suspicion that someone will complain
>> if I do.  If I don't hear confirmation about that, I'll delete it
>> anyway and suck up the consequences.
>
> does the original retry restart always recompile? i think sometimes it
> happens that the file actually compiles but with some warning and due
> to that asdf stops with an error. in such a situation the original
> retry restart will not try to recompile the file, only reload it.
> probably the same applies to load-time errors.
>
> i admit that i may be missing something, or maybe i was ignorant when
> dealing with asdf restarts, but i did use try-recompiling often
> recently.

I think you are missing something.

If the compile-op fails (i.e. if compile-file returns a true tertiary
value), the retry restart will retry the compile-op, so you can go and
edit the file and ask for a recompilation that way.

The annoying case is when compile-op succeeds (no compilation errors
or full warnings) but the subsequent load-op signals an error (say
because some class is not yet defined).  At that point, the retry
restart will attempt to reload the fasl -- not completely useless, but
needing a little bit more manual intervention.  It is for removing
that manual intervention that the try-recompiling restart is most
useful, I think; simply edit the source file and select that restart.
But for compile-op failures, I think the TRY-RECOMPILING and RETRY
restarts have equivalent behaviour.

Best,

Christophe

Re: [cclan-list] :around methods on LOAD-OP and COMPILE-OP

[Attila L. <att...@gm...>]

> I also think that the try-recompiling restart for compile-op is
> useless, because asdf already sets up a retry restart; I'd like to
> delete it, but I have a sneaking suspicion that someone will complain
> if I do.  If I don't hear confirmation about that, I'll delete it
> anyway and suck up the consequences.

does the original retry restart always recompile? i think sometimes it
happens that the file actually compiles but with some warning and due
to that asdf stops with an error. in such a situation the original
retry restart will not try to recompile the file, only reload it.
probably the same applies to load-time errors.

i admit that i may be missing something, or maybe i was ignorant when
dealing with asdf restarts, but i did use try-recompiling often
recently.

-- 
 attila

Re: [cclan-list] asdf and relative names

[F. <fa...@gm...>]

(Assuming the response was meant for the list)

2008/9/3 Richard M Kreuter <kr...@pr...>:
>> At ITA, we've been happily using the attached file to allow names such
>> as "foo/bar/baz" to be used for component names, either modules or
>> files. It works great for us, and allows to portably use #\/ to denote
>> relative pathnames where the character was previously forbidden in
>> portable systems.
>
> Why aren't you calling PARSE-NAMESTRING on the string?  Constructing a
> pathname from substrings you parse manually will yield different
> results on different Lisps in various cases.
>
The whole point of the exercise is that for .asd files to be portable,
you do NOT want to rely on non-portable PARSE-NAMESTRING to interpret
the relative names of modules and other components. That ASDF should
interpret / as a directory separator in an implementation-independent
way is a feature that makes / useful at all in portable .asd files.
Relying on PARSE-NAMESTRING means that you have to requiring different
module names on different implementations - which completely defeats
the purpose.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
You may easily play a joke on a man who likes to argue -- agree with him.
                -- Edgar Waston Howe

Re: [cclan-list] asdf and provide / require

[Richard M K. <kr...@pr...>]

Gary King <gw...@me...> writes:

> I'd like to build a system A that loads certain files if and only if  
> some other system B is _not_ loaded. One natural way to do this would  
> be to have system B push some feature (call it :b) onto *features* and  
> have system A say something like
>
> :components ((:file "something-like-b" :depends-on ((feature  
> (not :b)))))
>
> which is supposed to say "compile and load the file 'something-like-b'  
> if the feature :b is not present when you actually get around to  
> loading this system. Depends-on isn't quite the right term but I'm  
> hoping to keep changes down to a minimum.
>
> The above won't work both because ASDF can't express anything about  
> the absence of a feature and because you can't depend on a feature  
> being present in the depends-on clause. The closest I think you can  
> get now is
>
> :in-order-to ((:compile-op (feature :foo)) (load-op (feature :bar))))
>
> Is there some other to express what I want? Is there some reason that  
> I shouldn't be trying to express this at all!
>
> (Lastly, if there is any sense to this "include file iff some feature  
> is present / absent, then why not generalize and allow
>
> ;; more complex feature tests
> (:file "some-file" :include-when ((feature (:and :foo (:not :bar))))
>
> ;; more general computation
> (:file "some-file" :include-when ((test (some-predicate-i-know-not- 
> what-p)))
>
> (In the last psuedo-example, I'm imaging that the current component  
> and system are available via specials.)
>
> thoughts and comments welcome,

I think I came across this once before:

http://article.gmane.org/gmane.lisp.cclan.general/583

(Earlier posts in that thread that are mostly me being mislead by the
asdf manual at the time.)

What does feature-testing have to do with REQUIRE and PROVIDE (which
deal with *MODULES*, not *FEATURES*)?

--
Richard

Re: [cclan-list] asdf and relative names

[Richard M K. <kr...@pr...>]

"Faré" <fa...@gm...> writes:

> At ITA, we've been happily using the attached file to allow names such
> as "foo/bar/baz" to be used for component names, either modules or
> files. It works great for us, and allows to portably use #\/ to denote
> relative pathnames where the character was previously forbidden in
> portable systems.

Why aren't you calling PARSE-NAMESTRING on the string?  Constructing a
pathname from substrings you parse manually will yield different
results on different Lisps in various cases.

--
Richard

[cclan-list] asdf and relative names

[F. <fa...@gm...>]

At ITA, we've been happily using the attached file to allow names such
as "foo/bar/baz" to be used for component names, either modules or
files. It works great for us, and allows to portably use #\/ to denote
relative pathnames where the character was previously forbidden in
portable systems.

Could cClan aintainers include it in the upstream ASDF? Or is there a
good reason not to?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Atheism is a non-prophet organization.