<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.lisp.cclan.general">
    <title>gmane.lisp.cclan.general</title>
    <link>http://blog.gmane.org/gmane.lisp.cclan.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/893"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/892"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/891"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/890"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/876"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/873"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/872"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/871"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/869"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/866"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/864"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/854"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/849"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/846"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/845"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/842"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/841"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/840"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/837"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.cclan.general/836"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/893">
    <title>[PATCH] COMPONENT-DEPENDS-ON and operation subclasses</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/893</link>
    <description>Hello,

The method of COMPONENT-DEPENDS-ON specializing on OPERATION and
COMPONENT doesn't do what I'd expect when the operation is an indirect
instance of an operation class in a component's IN-ORDER-TO slot.
Here's an example involving two SBCL contribs with an inter-system
dependency:

* (asdf:find-system "sb-md5")

#&lt;ASDF:SYSTEM "sb-md5" {10024D6DC1}&gt;
* (asdf:component-depends-on (make-instance 'asdf:load-op)
                             (asdf:find-system "sb-md5"))

((ASDF:COMPILE-OP "sb-md5") (ASDF:LOAD-OP SB-MD5-SYSTEM::SB-ROTATE-BYTE))
* (defclass my-load-op (asdf:load-op) ())

#&lt;STANDARD-CLASS MY-LOAD-OP&gt;
* (asdf:component-depends-on (make-instance 'my-load-op)
                             (asdf:find-system "sb-md5"))

((ASDF:COMPILE-OP "sb-md5"))

The net effect is that subclasses of operation classes don't inherit
dependency behavior; in the example above, MY-LOAD-OP isn't able to load
sb-md5, because sb-rotate-byte doesn't get loaded.  I think it would
make sense for operation subclasses to inher</description>
    <dc:creator>Richard M Kreuter</dc:creator>
    <dc:date>2008-11-07T14:31:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/892">
    <title>asdf replacement</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/892</link>
    <description>Note that if you want to develop something that's incompatible with
ASDF yet has a migration path from ASDF, you might be interested in
hacking XCVB. It's not production-ready yet (and it currently depends
on ASDF to be installed itself), but it does its job and brings
interesting new features like separate compilation.

[ François-René ÐVB Rideau | Reflection&amp;Cybernethics | http://fare.tunes.org ]
Be liberal in what you accept and conservative in what you send.
        -- Jon Postel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; 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&amp;url=/
</description>
    <dc:creator>Faré</dc:creator>
    <dc:date>2008-10-18T18:46:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/891">
    <title>a non-contentious patch for ASDF... &lt;smile&gt;</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/891</link>
    <description>I made a mistake when I applied Richard Kreuter's fix for ASDF's  
broken circularity detection a while back: I kept in the old ASDF code  
and added Richard's fix. The patch below removes the code that should  
have been removed then. With this in, ASDF passes all 14-tests.

Index: asdf.lisp
===================================================================
RCS file: /cvsroot/cclan/asdf/asdf.lisp,v
retrieving revision 1.129
diff -u -w -r1.129 asdf.lisp
--- asdf.lisp4 Oct 2008 22:41:04 -00001.129
+++ asdf.lisp15 Oct 2008 18:52:03 -0000
&lt; at &gt;&lt; at &gt; -751,8 +751,6 &lt; at &gt;&lt; at &gt;
        (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))
        (unwind-protect
     (progn
       (loop for (required-op . deps) in

I've just committed this.
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkw</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-15T18:54:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/890">
    <title>adding system-loaded-p to ASDF</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/890</link>
    <description>AFAIK, there is no _easy_ way to tell if a system has been loaded in  
ASDF. #'find-system lets me know if a system is defined but I have to  
look at operation-done-p to know whether or not it has been loaded.  
The following adds #'system-loaded-p and two methods on #'operation- 
done-p to make it easier to use by converting symbols into instances  
of reasonable classes.

(in-package #:asdf)

(defmethod operation-done-p ((o symbol) (c t))
  (operation-done-p (make-instance o) c))

(defmethod operation-done-p ((o t) (c symbol))
  (operation-done-p o (find-system c)))

(defun system-loaded-p (system)
  (operation-done-p 'load-op (find-system system)))

If there is no disagreement, I'll add some documentation and tests and  
commit.
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the cool</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-15T19:01:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/876">
    <title>rfc - delay the parsing of system components</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/876</link>
    <description>I just finished a rough cut of an ASDF overall that makes three  
largish changes:

1. delays the parsing of system components until needed by traverse.  
In particular, this means that the :components clause of defsystem  
form happens after that system's dependencies have been loaded rather  
than when the ASD file itself is loaded.

2. rewrites traverse as a set of methods that immediately call perform  
(rather than building up a list of perform actions that  are then  
called in operate).

3. does away with :do-first and moves what it did into :in-order-to

The main motivation for change #1 is to be able to define new  
operations and source file classes in a system's dependencies and have  
them used in that systems definitions; the main motivation#2 was #1:  
it does no good to delay parsing of the defsystem form if traverse has  
to complete the parse before anything else happens!. As for #3, while  
doing three things at once is just very human (and besides, it made #2  
easier).

I've got several h</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-08T14:12:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/873">
    <title>in-order-to and/or do-first</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/873</link>
    <description>Can anyone recall why we have both in-order-to and do-first? Doesn't  
in-order-to subsume do-first?

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





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; 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&amp;url=/
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-07T23:45:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/872">
    <title>small patch for asdf output</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/872</link>
    <description>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.lisp4 Oct 2008 22:41:04 -00001.129
+++ asdf.lisp5 Oct 2008 19:46:02 -0000
&lt; at &gt;&lt; at &gt; -150,6 +150,10 &lt; at &gt;&lt; at &gt;
  (define-modify-macro appendf (&amp;rest args)
    append "Append onto list")

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

&lt; at &gt;&lt; at &gt; -399,6 +403,15 &lt; at &gt;&lt; at &gt;
            (package (try counter) (try counter)))
           (package package))))

+;;; special handling for cmucl
+;; FIXME: This wants to be (ENOU</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-05T19:48:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/871">
    <title>removed load-preferences support from ASDF</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/871</link>
    <description>As was discussed several months ago, I have removed load-preferences  
support from ASDF

2007-10-04 10:55  gwking&lt; at &gt;metabang.com

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





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; 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&amp;url=/
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-10-04T22:42:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/869">
    <title>ASDF component-self-dependencies</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/869</link>
    <description>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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux </description>
    <dc:creator>Robert Goldman</dc:creator>
    <dc:date>2008-09-23T19:38:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/866">
    <title>Circularity detection fix exposed a bug</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/866</link>
    <description>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.lisp6 Sep 2008 22:57:16 -00001.127
+++ asdf.lisp9 Sep 2008 13:28:30 -0000
&lt; at &gt;&lt; at &gt; -725,45 +725,47 &lt; at &gt;&lt; at &gt;
       (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)
-      </description>
    <dc:creator>Richard M Kreuter</dc:creator>
    <dc:date>2008-09-09T14:48:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/864">
    <title>operation-done-p (test-op system)</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/864</link>
    <description>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





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; 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&amp;url=/
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-09-06T22:30:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/854">
    <title>on using system-registered-p where it can be used.</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/854</link>
    <description>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.lisp5 Jul 2008 02:57:20 -00001.123
+++ asdf.lisp4 Sep 2008 12:55:13 -0000
&lt; at &gt;&lt; at &gt; -375,7 +375,7 &lt; at &gt;&lt; at &gt;
      (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)))))))

&lt; at &gt;&lt; at &gt; -407,7 +407,7 &lt; at &gt;&lt; at &gt;

  (defun find-system (name &amp;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</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-09-04T12:57:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/849">
    <title>Circularity detection broken in ASDF</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/849</link>
    <description>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"))))

#&lt;ASDF:SYSTEM "circ" {10025620C1}&gt;
* (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 #&lt;THREAD "initial thread" {1002450D61}&gt;:
  Control stack exhausted (no more space for function call frames).  This is probably due to heavily nested or infinitely recursive fu</description>
    <dc:creator>Richard M Kreuter</dc:creator>
    <dc:date>2008-09-03T22:27:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/846">
    <title>asdf and relative names</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/846</link>
    <description>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&amp;Cybernethics | http://fare.tunes.org ]
Atheism is a non-prophet organization.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; 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&amp;url=/_______________________________________________
cclan-list mailing list
cclan-list&lt; at &gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ccl</description>
    <dc:creator>Faré</dc:creator>
    <dc:date>2008-09-03T19:03:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/845">
    <title>asdf and provide / require</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/845</link>
    <description>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</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-09-03T02:40:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/842">
    <title>:around methods on LOAD-OP and COMPILE-OP</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/842</link>
    <description>These two are a relatively recent addition:

(defmethod perform :around ((o load-op) (c cl-source-file))
  (let ((state :initial))
    (loop until (or (eq state :success)
                    (eq state :failure)) do
         (case state
           (:recompiled
            (setf state :failure)
            (call-next-method)
            (setf state :success))
           (:failed-load
            (setf state :recompiled)
            (perform (make-instance 'asdf:compile-op) c))
           (t
            (with-simple-restart
                (:try-recompiling "Recompile ~a and try loading it again"
                                  (component-name c))
              (setf state :failed-load)
              (call-next-method)
              (setf state :success)))))))

(defmethod perform :around ((o compile-op) (c cl-source-file))
  (let ((state :initial))
    (loop until (or (eq state :success)
                    (eq state :failure)) do
         (case state
           (:recompiled
            (setf state :failure)
</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2008-07-30T08:14:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/841">
    <title>[PATCH] circularity detection broken in 1.123</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/841</link>
    <description>Hi,

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"))))

#&lt;ASDF:SYSTEM "circ" {10025620C1}&gt;
* (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 #&lt;THREAD "initial thread" {1002450D61}&gt;:
  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 exi</description>
    <dc:creator>Richard M Kreuter</dc:creator>
    <dc:date>2008-07-21T13:44:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/840">
    <title>I just updated asdf</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/840</link>
    <description>with the patch to modify system-definition-pathname so that even  
systems that are loaded "by hand" will be reloaded by ASDF if they  
change.

Also added two tests for this behavior. Tests pass on OS X under sbcl,  
clisp, allegro and allegromodern.

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





-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-07-05T02:58:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/837">
    <title>Ensuring that ASDF reloads out of date system defs,take 2</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/837</link>
    <description>The patch below is a followup / altered version to my proposed patch  
of June 15th. Both patches ensure that ASDF treats systems _it_ can  
find using *system-definition-search-functions* the same way it treats  
systems that have been loaded by hand. The previous patch modified  
find-system; this one modifies system-definition-pathname which, to me  
at least, seems to be the "right" place to put the fix. I'm going to  
add a test or two of the behavior for both kinds of system loading and  
then I'd like to commit.

Comments very welcome!


Index: asdf.lisp
===================================================================
RCS file: /cvsroot/cclan/asdf/asdf.lisp,v
retrieving revision 1.122
diff -c -r1.122 asdf.lisp
*** asdf.lisp29 Jun 2008 15:10:16 -00001.122
--- asdf.lisp29 Jun 2008 15:33:32 -0000
***************
*** 1,4 ****
! ;;; This is asdf: Another System Definition Facility.  $Revision:  
1.122 $
   ;;;
   ;;; Feedback, bug reports, and patches are all welcome: please mail  
to
   ;;; &lt;cclan-l</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-06-29T15:38:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/836">
    <title>Finally applied Matthew Swank's try-compiling patch</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/836</link>
    <description>(Sorry for the delay).
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM





-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-06-29T15:11:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.cclan.general/834">
    <title>committed patch for system-relative-pathname</title>
    <link>http://comments.gmane.org/gmane.lisp.cclan.general/834</link>
    <description>  (defun system-relative-pathname (system pathname &amp;key name type)
-  (let ((directory (pathname-directory pathname)))
+  ;; you're not allowed to muck with the return value of pathname-X
+  (let ((directory (copy-list (pathname-directory pathname))))
      (when (eq (car directory) :absolute)
        (setf (car directory) :relative))
      (merge-pathnames

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





-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
</description>
    <dc:creator>Gary King</dc:creator>
    <dc:date>2008-06-26T03:06:05</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.lisp.cclan.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.cclan.general</link>
  </textinput>
</rdf:RDF>
