On Tue, Nov 10, 2009 at 11:34 PM, Robert Goldman rpgold...@sift.info wrote:
FWIW, I'd suggest
(defsystem my-package
:class rt-testable-system
:components .
)
When you do (oos 'test-op 'my-package), the rt-testable-system
(presumably a subclass of system and rt-testable-mixin) would
I have split the change into two, as I normally do in the ECL source tree
itself.
The first change only pertains asdf.lisp and it adds a slot, FLAGS, to
COMPILE-OP. These are additional flags for COMPILE-FILE. It is used by ECL
because we want to produce two files per source file: an object file
On Tue, Dec 1, 2009 at 12:17 PM, Faré fah...@gmail.com wrote:
OK, but then, I may as well drop the ECL-specific code I inserted to
support upgrade from an older ASDF.
I would say that we can focus on ensuring that ASDF can be upgraded
for ECL = 9.12.1 and leave the older versions out.
Also, I
On Tue, Dec 1, 2009 at 9:05 PM, Faré fah...@gmail.com wrote:
I think that it is the very design of ASDF that a .asd file is Lisp
source code, and that we thus reuse Lisp as the language to do magic
there. What better way to load extensions in your .asd than that?
After all, you need the
On Thu, Feb 4, 2010 at 9:23 AM, Faré fah...@gmail.com wrote:
And so, regarding ECL: please upgrade ASDF to 1.601 if you can. It
would be nice. And reduce the asdf self-upgrade strictures.
The point is that I upgraded to 1.596 on Samium's request and assurance that
it works with ECL, and now
On Thu, Feb 4, 2010 at 7:50 PM, Faré fah...@gmail.com wrote:
ASDF didn't use to support ECL for testing at all. I just added this
support and found about the warnings, so it counts as my having warned
you immediately.
How can I run the tests? run-tests.sh is not working for me.
Juanjo
--
On Thu, Feb 4, 2010 at 9:49 PM, Faré fah...@gmail.com wrote:
If it's the compile-asdf script hanging instead of exiting, I just
pushed 1.603 that has a fix for running tests in ECL w/o manual
intervention. My apologies. (No functional change to asdf itself, only
to the test script
On Sat, Mar 13, 2010 at 12:01 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
I must admit that after four hours fighting with this I am right now a bit
pissed off, so please forgive the tone of the message.
ASDF has introduced a new caching system which alters
On Sat, Mar 13, 2010 at 4:40 PM, Faré fah...@gmail.com wrote:
It's also what I committed to 1.634.
Thanks for your explanations and corrections. I just updated ECL to use
1.634.
FYI, the reason why I did not add **/*.* is because the sbcl case was just
specified like that: (getenv SBCL_HOME),
On Sat, Mar 13, 2010 at 8:50 PM, Faré fah...@gmail.com wrote:
Where is the file to be when you compile?
Where is the file to be when you load?
How do you currently do things, and what breaks?
Could say, a logical pathname host LIB:
help locate the libraries?
How do you do things without
On Sun, Mar 14, 2010 at 1:36 AM, Faré fah...@gmail.com wrote:
1- you want an ASDF operation that dumps some description of
things to be loaded.
2- you want to use a .asd itself as the output of that operation.
3- you want some location-independence in that description.
I presume the role
Before, if an operation defined by me, such as LIB-OP, did not traverse a
system, then the only operation we got was that operation applied on the
system, as a generic object.
Now TRAVERSE not only imposes the LIB-OP operation on the system, but it
also scans the components and imposes the
On Wed, Mar 17, 2010 at 11:28 PM, Robert Goldman rpgold...@sift.infowrote:
For example, if I'm writing the ASDF
definition for my FLOYD-WARSHALL transitive closure library, I can't be
putting into it
(defmethod PERFORM ((op load-op) (c cl-source-file))
)
because that means that
On Wed, Mar 17, 2010 at 11:54 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Oh, there is nothing with TRAVERSE's output _right now_.
Let me clarify this again:
- The fact that TRAVERSE now adds the same operation for all components was
new. That was my source
Narrowing down the problem, TRAVERSE now adds the LIB-OP operation to all
components of a system. I added a method
(defmethod perform ((operation lib-op) (c component))
nil)
but this method gets overriden by a more specific one which is provided by
asdf.lisp
(defmethod perform ((operation
On Thu, Mar 18, 2010 at 12:25 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Thu, Mar 18, 2010 at 12:21 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Narrowing down the problem, TRAVERSE now adds the LIB-OP operation to all
components
On Thu, Mar 18, 2010 at 1:36 AM, Robert Goldman rpgold...@sift.info wrote:
Is it possible that somehow the compilation of asdf-ecl is recording
some information about the package that is somehow damaged by the
package surgery?
I will dig into that later during the weekend. I think the point
On Thu, Mar 18, 2010 at 2:55 PM, james anderson james.ander...@setf.dewrote:
if asdf were to adopt an 11.1.2.1.2-rule, asdf-ecl.lisp would require a
change.
it would not be supported for an extension to extend 'asdf:load-op such
that load-op itself specialized an operation-done-p :around
On Thu, Mar 18, 2010 at 4:05 PM, Robert Goldman rpgold...@sift.info wrote:
OTOH, it's probably a good idea to figure out the implications of such a
rule on true extensions, so I don't think James's attentions here are
wasted.
Me neither, I just wanted to emphasize that it is not a one-sided
On Thu, Mar 18, 2010 at 3:18 PM, james anderson james.ander...@setf.dewrote:
good afternoon.
On 2010-03-18, at 15:02 , Juan Jose Garcia-Ripoll wrote:
On Thu, Mar 18, 2010 at 2:55 PM, james anderson james.ander...@setf.dewrote:
if asdf were to adopt an 11.1.2.1.2-rule, asdf-ecl.lisp would
On Thu, Mar 18, 2010 at 6:29 PM, james anderson james.ander...@setf.dewrote:
On 2010-03-18, at 16:23 , Faré wrote:
[ ...]
But I think ASDF ought to make a best effort, so that you can at
the very
least upgrade ASDF when installed as part of Common-Lisp-Controller
and
similar
This is an idea that has been long floating in the back of my mind, and was
brought back to life by these comments
http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf
The problem is that many people use *.asd files to do things like building
up packages, creating operations,
On Thu, Mar 18, 2010 at 10:04 PM, Robert Goldman rpgold...@sift.infowrote:
I can see Juanjo's point, but I would like to suggest that we defer this
until ASDF 3; it's simply too much to bite off this time around, IMO.
I agree that it is hard to get this right. However, would it be ok if I
On Thu, Mar 18, 2010 at 11:18 PM, Robert Goldman rpgold...@sift.infowrote:
Right. But do we have a clear understanding of what should and
shouldn't go in there? E.g.:
1. currently if you need an ASDF extension in order to make a defsystem
understandable [...]
2. New class and method
On Thu, Mar 18, 2010 at 10:48 PM, Robert Goldman rpgold...@sift.infowrote:
I'm reluctant to endorse this suggestion, because it means that we will
spawn YA information source to track. We'll have:
1. launchpad
I ignored ASDF was using this. I have submitted a wishlist ticket but I was
not
On Thu, Mar 18, 2010 at 11:28 PM, Faré fah...@gmail.com wrote:
In other words, I think that supporting ASDF is important, but
ultimately an evolutionary dead-end.
That is hard to read from the project leaders. I feel rather neutral about
this and please do not feel offended by the following
On Fri, Mar 19, 2010 at 3:42 AM, Robert Goldman rpgold...@sift.info wrote:
Juanjo --- do you have what you need to make asdf-ecl.lisp work again
(wrt traverse)? Is there anything we (I) can do to help with this?
I am still waiting to get see whether the package changes are fixed -- I
messed
Thansk for the latest changes, they work like a charm now.
I have done something which I do not know whether it is a desired protocol.
Namely I have submitted patches for asdf-ecl.lisp using launchpad.
I did this because I always found it more convenient to have a look at the
ECL bug/patch
On Fri, Mar 19, 2010 at 7:51 PM, Faré fah...@gmail.com wrote:
Can you help with the configuration on Windows?
What is the ECL equivalent of LispWorks' get-folder-path?
Or if there isn't one builtin, how do I read a string entry from
the registry?
We do not export in ECL any way to read the
In a system such as
(defsystem :foo
:component ((:file foo)))
where foo.lsp exists and is recognized by the lisp implementation as a valid
source file (ECL), ASDF imposes the file extension lisp. Furthermore,
adding our own extension
(defsystem :foo
:component ((:file foo.lsp)))
does not
On Fri, Mar 19, 2010 at 7:51 PM, Faré fah...@gmail.com wrote:
Can you help with the configuration on Windows?
What is the ECL equivalent of LispWorks' get-folder-path?
Or if there isn't one builtin, how do I read a string entry from
the registry? Can you test ASDF with ECL on Windows?
Do
On Sun, Mar 21, 2010 at 12:41 PM, Tobias C. Rittweiler t...@freebits.dewrote:
There, however, seems to be an inherent dependency-vs-pureness problem
with user extensions as illustrated by cffi-grovel; from [1]:
;;; CFFI-Grovel is needed for processing grovel-file components
(cl:eval-when
On Tue, Mar 23, 2010 at 2:35 PM, james anderson james.ander...@setf.dewrote:
[ ... continued ]
It was a simple experiment. Define a restricted package and interpret .asd
files with a restricted read-eval loop.
Beautiful. Could you attach this sample patch to the bug report I filed
asking
I just cut paste what I submitted to the appropriate record in launchpad
https://bugs.launchpad.net/asdf/+bug/542583
where the port can be downloaded and given a try.
I attach a straightforward port of two operations that ECL supports:
- Building a unified FASL file that contains either a
Now a couple of examples.
Suppose you have an ASDF system which is made of many sources with several
dependencies. I assume the system does not rely on other resources
(additional files, etc), but this could be extended.
If you want to build a single FASL file that contains EVERYTHING, use
On Mon, Mar 29, 2010 at 4:43 PM, Tobias C. Rittweiler t...@freebits.dewrote:
Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com writes:
What is needed for any kind of standalone system building that relies on
ASDF system definitions and is capable of incorporating all dependencies
On Mon, Mar 29, 2010 at 5:37 PM, Robert Goldman rpgold...@sift.info wrote:
Is this an alternative syntax? Do you expect:
(asdf:oos 'asdf:monolithic-binary-op :my-system :move-here ./)
to work as well?
No. The operations do not have a notion of destination, because I did not
want to mess
On Mon, Mar 29, 2010 at 5:47 PM, Robert Goldman rpgold...@sift.info wrote:
I.e., can you characterize this declaratively in terms of the values of
MODULE-COMPONENTS, and for some operation the values of INPUT-FILES
and/or OUTPUT-FILES?
I do not understand your concerns or those in other
Hi Robert,
I must say that I understand your concerns which are just, right now,
*time*. And I also understand that in prolonging this thread I risk you lose
your patience with a feeling that I am wasting your time, but please read
this email and understand the following key points that indeed
Now to the point.
ASDF right now has two modes of operation. One is building the other one
is loading. User defined operations belong to one or another class.
* compile-op is clearly a building operation, for it takes lisp files and
compiles them
* load-op is clearly a loading operation: it just
On Mon, Mar 29, 2010 at 9:30 PM, Robert P. Goldman rpgold...@sift.infowrote:
Sounds like there's a good function that can be exposed as an extension
without needing to get the component-gathering right, which would be great.
Indeed, and here I would like to get some help in getting it right.
One of the common problems that ASDF users faced when introducing the new
binary location system is finding out where things reside.
Another problem we will eventually find is locating the resources associated
to an ASDF system which has been replaced by a precompiled version.
In general it
Some considerations:
* In order to achieve a declarative syntax in ASDF, the system that we built
it with should have the least knowledge about ASDF. In other words, it
should work just the same if we bulid it with any other system.
* Following this reasoning, logical pathnames are a useful
On Tue, Mar 30, 2010 at 4:06 PM, Robert Goldman rpgold...@sift.info wrote:
FWIW, Faré provided a couple of new API functions to give ASDF users
this function, notably
SYSTEM-RELATIVE-PATHNAME
and
SYSTEM-SOURCE-DIRECTORY
I insist on the following: in order to achieve purity in ASDF files
On Tue, Mar 30, 2010 at 4:19 PM, Robert Goldman rpgold...@sift.info wrote:
On 3/29/10 Mar 29 -6:42 PM, Faré wrote:
One site per system looks like it will quickly pollute the host
namespace. What about we instead use a single logical host with
subdirectories?
On Tue, Mar 30, 2010 at 4:25 PM, Robert Goldman rpgold...@sift.info wrote:
Question: should we raise a style warning if the user supplies a
logical pathname that does not comply with the ANSI spec? I would
prefer that we do that.
The first question is whether we are going to provide a
On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman rpgold...@sift.info wrote:
Lisp development --- at least for people like me --- is primarily an
interactive process, and this is why building and loading/executing are
/inextricably/ linked.
Please note that image driven development is NOT the
On Wed, Mar 31, 2010 at 7:43 PM, Robert Goldman rpgold...@sift.info wrote:
With all due respect, this seems contentious and unsupported. I don't
see any particular reason to believe that a tool for the coherent
maintenance of a long-running image would also be a good fit for more
On Wed, Mar 31, 2010 at 8:10 PM, james anderson james.ander...@setf.dewrote:
in general, image-driven development does not preclude a release which
comprises more that one file, but if you were more specific about
requirements, it would be easier understand where the problems arise for
ecl.
On Wed, Mar 31, 2010 at 8:11 PM, Faré fah...@gmail.com wrote:
There are many things to clarify about logical pathnames and the use
thereof or not, but I don't think this should block a release of ASDF
2. Should it? And so I'd like to declare it an ASDF 2.1 or ASDF 3
issue, and invite you to
A new implementation was just uploaded which implements the
:logical-pathname argument for defsystem. It constructs four definitions,
one using Faré's favourite no-namespace-clobbering scheme and three other
ones that gives a bit more freedom to the developer, separating sources from
automatically
... with my usual trolling
http://groups.google.com/group/comp.lang.lisp/msg/4fc15114d6865348
FYI
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
___
asdf-devel mailing list
The link in Google for the ASDF manual points to
http://common-lisp.net/project/asdf/manual.html
This is so because I convinced the person with the highest page rank in that
query to place a link to this page.
However the previous link has been arbitrarily changed to become
Who uses it?
Out of 291 packages, the only uses seem to be
- Defining TEST-OP operations (greate majority)
- In a few tests, it solves a wrong ordering of files
- In two, it deactivates operations by using FEATURE (obscure way to do it)
The paradigmatic example of McClim cited here
Great! Thanks a lot.
On Thu, Apr 15, 2010 at 10:55 PM, Faré fah...@gmail.com wrote:
On 15 April 2010 08:48, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Just a warning:
Setting up a webpage with a redirect message is not advised by Google.
If you do so instead
On Fri, Apr 16, 2010 at 12:01 AM, james anderson james.ander...@setf.dewrote:
you will need to elaborate on why this matters. the primary dependencies
are all in a list which is bound to the in-order-to slot.
the :in-order-to initarg is just circumstantially involved in this. most of
the
Right now we have a situation in which load-source-op is a second class
citizen, rarely used, and for which nobody provides explicit dependencies.
More precisely
* Some compilers out there are just efficient compiling and loading source
files. The operation is the same.
* LOAD-OP can be viewed as
On Sat, Apr 17, 2010 at 11:26 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
* With this mechanism I can reimplement the fasl concatenation mechanism
*without* using classes at all. Same goes for ECL's
extensionshttp://tream.dreamhosters.com
Ok
The attached patch adds a new option to DEFSYSTEM. This option is
:TESTS test-list
test-list = (:system system-name) | function-name
system-name = keyword | string
function-name = symbol | string
The function name is a string designator that denotes a function with no
arguments to be called.
Forgot the diff file.
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
0001-Implement-a-declarative-option-TESTS-for-running-tes.patch
Description: Binary data
___
asdf-devel mailing list
On Sun, Apr 18, 2010 at 4:56 PM, Robert Goldman rpgold...@sift.info wrote:
So: what is the intended effect of :ASDF-DEPENDENCIES and
:ASDF-OPTIONAL-DEPENDENCIES? At what point in the processing of the
DEFSYSTEM are they processed? How do they interact with the processing
of other DEFSYSTEM
On Sun, Apr 18, 2010 at 5:24 PM, Robert Goldman rpgold...@sift.info wrote:
On 4/18/10 Apr 18 -10:18 AM, Juan Jose Garcia-Ripoll wrote:
Ideally the situation could be such that the loading of dependencies
could be delayed until the system is actually used. In other words, load
the system
On Sun, Apr 18, 2010 at 12:20 AM, Faré fah...@gmail.com wrote:
PS: after 2.0 is out, I'd like to resign from ASDF maintainership, to
focus on XCVB (help welcome on that, too). Is anyone volunteering to
replace me on ASDF?
After thinking about it, I am willing to step up as a possible
On Sun, Apr 18, 2010 at 10:31 PM, Robert Goldman rpgold...@sift.infowrote:
For what it's worth, I'm happy to see an agile development, but I would
strongly discourage implementation as the main way of introducing new
features.[...] Right now, the only way to get started working on ASDF is
to
Dear Fare,
I can not avoid to say that much of your previous email needed not be
written.
* THe warning about incomplete and bogus patches being submitted
* The warning that the current maintainer knows it better the pain of
maintaining and pushing new features.
* Dooms about maintainers having
On Tue, Apr 20, 2010 at 3:39 PM, Faré fah...@gmail.com wrote:
I'm sorry that my mail was taken the wrong way.
I understand that email is not always the best medium for communicating.
My plan is to freeze the master branch at the end of April,
thereupon only accepting bug fixes or trivial
On Tue, Apr 20, 2010 at 6:17 PM, james anderson james.ander...@setf.dewrote:
that there is such difficulty to select a stable term indicates that
the form of the expression is wrong.
Not really. It simply shows that some concepts are difficult to fit in one
or two words -- as in
On Tue, Apr 20, 2010 at 9:51 PM, james anderson james.ander...@setf.dewrote:
if the concepts are difficult to fit in one or two words, then the
expression form should disambiguate rather than obscure. just as
(defstruct (person (:print-function print-person)) name age sex)
It is good to
On Wed, Apr 21, 2010 at 10:31 AM, james anderson james.ander...@setf.dewrote:
the patch which was enclosed in the earlier message[2] demonstrated
an implementation which modifies the three functions - component-
pathname, input-files, and output-files, extends the function which
constructs
Why using TRUENAME + ERROR + HANDLER-CASE instead of PROBE-FILE?
I have been tracking a completely unrelated bug in ECL but found that for
loading all files ASDF calls TRUENAME with the names of FASLs that do not
exist. It finds out that by catching the corresponding error and then tries
On Thu, Jul 15, 2010 at 12:59 AM, Faré fah...@gmail.com wrote:
we use TRUENAME + HANDLER-CASE precisely because the file (or
directory, most of the time) doesn't necessarily exist and we're
trying to fully resolve any symlinks along the path, so that in the
end we may apply translations to
On Fri, Jul 16, 2010 at 12:54 AM, edgar edgar-...@web.de wrote:
I think the main problem here is that some implementations
(notably CLISP) differ between files and directories, so
PROBE-FILE cannnot be used to probe files AND directories.
Well, SBCL and ECL do not have that problem, AFAIK.
On Thu, Aug 19, 2010 at 9:04 PM, Faré fah...@gmail.com wrote:
The question is whether we should avoid creating extra packages, and
instead export all relevant functions from ASDF, or should we keep
those separate packages ASDF-BOOTSTRAP and ASDF-UTILITIES.
I think the too-many-packages
There is a rationale for the splitting of asdf.lisp.
* Sorry, but the excuse of searching for code in a file is lame :-) Would
that also apply to any thousand lines code library?
* The bootstrapping code can be different for a shipped asdf (one that comes
with the implementation) and for the
On Wed, Sep 22, 2010 at 4:35 PM, Robert Goldman rpgold...@sift.info wrote:
On 9/22/10 Sep 22 -5:26 AM, Juan Jose Garcia-Ripoll wrote: * The
bootstrapping code can be different for a shipped asdf (one that
comes with the implementation) and for the asdf that is loaded by users.
This can
On Wed, Sep 22, 2010 at 8:37 PM, Pascal J. Bourguignon
p...@informatimago.com wrote:
No. Why? I mean, the separate components are bundled into a single
asdf.lisp and this process is automated (make -f GNUmakefile
asdf.lisp). There is no new testing burden. I am just advocating for
some
On Thu, Sep 23, 2010 at 4:27 AM, Pascal J. Bourguignon
p...@informatimago.com wrote:
But when you have a smart editor such as emacs, with at least a good
search function, or even a find-tag feature, it doesn't really matter
where your functions are stored.
I use emacs, and I am not thinking
http://groups.google.com/group/comp.lang.lisp/msg/93a4b06a66b0b335
1- The new configuration and file searching mechanism is causing some grief.
2- Lack *-user mailing list and need of subscription for questions. Is there
a sufficiently large comunity here and do we want to open the list?
I
On Sun, Sep 26, 2010 at 6:09 PM, Robert Goldman rpgold...@sift.info wrote:
What is broken about having people post questions to asdf-devel?
Didier's objection to asdf-devel is that he didn't want to sign up for
the mailing list. Why would it make him any happier to sign up for
asdf-help
Right after sending the patch I realized two things:
- A debug statement was left out (TRACE ...)
- It might make sense to save the old value of COMPILE-FILE*
Attached improved diff against recent ASDF tree.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006
On Sat, Feb 5, 2011 at 12:30 AM, Faré fah...@gmail.com wrote:
On 4 February 2011 18:11, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Attached improved diff against recent ASDF tree.
OK, I'm going to apply this one. Are there any required changes in
asdf-ecl.lisp
On Sat, Feb 5, 2011 at 4:06 PM, Faré fah...@gmail.com wrote:
I massaged your patch (notably made compile-file* a gf to move your
code to an :around method rather than a manual wrapper), tested it,
and committed as 2.012.5. Enjoy!
Fare, could you please go back to the other method I posted.
On Sat, Feb 5, 2011 at 5:18 PM, Faré fah...@gmail.com wrote:
On 5 February 2011 11:13, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sat, Feb 5, 2011 at 4:06 PM, Faré fah...@gmail.com wrote:
Fare, could you please go back to the other method I posted. This one
does
On Sun, Feb 6, 2011 at 10:23 PM, Faré fah...@gmail.com wrote:
Where is the behavior to be coded? Surely it must be coded somewhere.
Is it unreasonable to upgrade ASDF when new code is required, and to change
few boolean controls to select which branch of the code applies?
Please, understand,
Apart from some documentation and copyright notices, two major changes:
- ECL will support two compilers. ASDF needs to be aware of that.
- The plug-in for REQUIRE allows ECL users to supply another default
operator. LOAD-FASL-OP is recommended because it builds each library into a
single shared
On Tue, Sep 6, 2011 at 4:51 PM, Robert Goldman rpgold...@sift.info wrote:
I'd be happy to merge and push this if someone will test this out.
Alternatively, if no member of asdf-devel but Juanjo will admit to using
ECL, then I figure we should delegate responsibility to him for vetting
patches
On Fri, Sep 9, 2011 at 9:55 PM, Robert Goldman rpgold...@sift.info wrote:
OK. But why do you need to do
(member :foo *features*)
instead of
#+foo
?
That was the original question.
Simple: because the user may switch compilers at run time at any time he/she
wishes. This is quite typical
On Tue, Sep 13, 2011 at 12:04 AM, Faré fah...@gmail.com wrote:
Juanjo, can you test whether this satisfies you?
Yes, sorry, I did not answer before: I am away from home and took some time
to get the changes. It all seems correct to me.
Regarding ECL, do fasls have a different extension when
On Tue, Sep 13, 2011 at 4:03 PM, Robert Goldman rpgold...@sift.info wrote:
Is there a way to specifically run the tests on ecl using the byte
compiler? If not, should we develop such a capability and add it to our
test suite?
I do not think this has been actually considered in the ASDF
On Tue, Sep 13, 2011 at 8:39 PM, Faré fah...@gmail.com wrote:
Am I correct that I should assume :asdf-unix when :darwin is in the
*features*
even though :unix isn't?
:darwin does imply Darwin operating system which does have '/'-separated
pathnames and thus following your definition of
On Wed, Sep 14, 2011 at 3:23 AM, Faré fah...@gmail.com wrote:
OK. Robert, Juanjo, does the 2.017.5 I just pushed work for you?
I just git-pulled the system and all seems to work with ECL on OS X.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
On Sun, Sep 18, 2011 at 3:39 AM, Robert Goldman rpgold...@sift.info wrote:
On 9/17/11 Sep 17 -1:47 AM, Juan Jose Garcia-Ripoll wrote:
On Fri, Sep 16, 2011 at 11:54 PM, Robert Goldman rpgold...@sift.info
mailto:rpgold...@sift.info wrote:
ecl-bytecomp : first compile and load asdf
On Tue, Sep 20, 2011 at 3:27 PM, Robert Goldman rpgold...@sift.info wrote:
So may we expect that the bytecodes compiler will NEVER be active out of
the box? I.e., all we need to do is turn ON the bytecode compiler when
we want it, not make sure it's off when we don't (for the purposes of
Hi Faré,
sorry for the lack of response in the last days -- little time to code left
and even less for reading mailing lists.
On Fri, Oct 7, 2011 at 10:48 PM, Faré fah...@gmail.com wrote:
I see that your current ECL replaces si:: by ext:
on a few symbols in its version of ASDF.
Should I
I apologize in advance for the stupid newbie question that follows.
I have the two systems below. When I change a file in cl-farm, it recompiles
it, but when I demand loading of cl-farm-test again, ASDF does not recompile
it, even though its dependency has changed. Why? Is this expected.
This
On Tue, Apr 24, 2012 at 4:38 AM, Faré fah...@gmail.com wrote:
is it OK with you if unbundle asdf-ecl from asdf.asd, and instead create
a somewhat portable asdf extension called asdf-bundle.asd ?
I would need some time to do that -- this means not before the next
release. What bundle
On Tue, Jul 24, 2012 at 9:31 PM, Faré fah...@gmail.com wrote:
However, I don't quite see what you're afraid of with respect to
upgrading ASDF to the latest (currently 2.23) from what you have
(currently 2.017.5).
There have been fixes in ECL regarding asdf-ecl. I need to sit down and see
how
On Fri, Oct 12, 2012 at 4:31 PM, Zach Beane x...@xach.com wrote:
I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp
to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?
Since Faré took over ASDF, ASDF has worked perfectly fine with ECL so that
is not a
On Fri, Oct 12, 2012 at 8:22 PM, Zach Beane x...@xach.com wrote:
Does ECL include asdf-ecl already, and track each new release of ASDF?
Though I have failed to track a couple of the latest releases, I try to
keep as close as possible to ASDF's releases. The configuration of ECL is
such that
On Sun, Oct 28, 2012 at 12:59 AM, Faré fah...@gmail.com wrote:
On Sun, Oct 28, 2012 at 6:41 AM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@gmail.com wrote:
Currently, ASDF ignores all file types supplied by the user when
specifying
a :PATHNAME value for a component. This did not happen
1 - 100 of 116 matches
Mail list logo
