On Wed, Oct 19, 2011 at 21:36, Сергей Катревич linkf...@newmail.ru wrote:
I think that asdf is a big enough system in order to start its division.
But have to single file asdf.lisp - it is convenient. I propose to take
advantage of both approaches: concated many files into asdf.lisp (for
On Tue, Oct 18, 2011 at 10:22, Сергей Катревич linkf...@newmail.ru wrote:
:around-compile - wonderful solve of problem! Can add the :around-load for
similar purpose? This it seems logical.
Thanks for the appreciation!
I think :around-load is a bad idea, for reasons that Juanjo and I
mentioned
On Tue, Oct 18, 2011 at 16:50, Сергей Катревич linkf...@newmail.ru wrote:
Is there any particular effect you think would be useful at load time
that wouldn't be better done at compile-time?
The main application - monitoring changes in the Lisp system after loading
the code (see attachment)
1- I don't think asdf.lisp itself is the right place for this function,
although if someone starts a formal asdf-contrib system,
it should definitely be there.
2- For extra brownies, you ought to handle arbitrary nickname conflicts,
and properly restore things afterwards. You can assume no
Gabor, why don't you start a
contrib/asdf-contrib.asd
system under the asdf tree, or as another project?
Also, a better version of with-package-nicknames
would handle conflicts with the main name of some packages,
that could even be shadowed, and rotation of nicknames between packages as well.
On Mon, Oct 17, 2011 at 10:37, Gary King gwk...@metabang.com wrote:
Hi all,
Are there any tools extant that provide a good summary of all of the
inter-relations between systems.
I'm sure Xach has something that works with Quicklisp.
I use the attached to make a DOT file but wonder if there
(defsystem com.host.my-system
(:serial t)
(:depends-on (system-1 system-2)
(:components ((:file file1)
(:file file2 :class 1)
(:file file3 :class 2)
(:file file4 :class 1))
(:before-compile 1 #'(lambda (component) (do what you want)))
2011/10/17 Gábor Balázs gab...@gmail.com:
I think the divergence is coming from the fact that I want a special
functionality (package renaming) with a simple syntax and you want a general
functionality which cannot be represented by a simple syntax. So it is a
tradeoff between simple syntax
NB: I committed this :around-compile feature with some minimal
documentation as 2.017.18.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Foreign aid might be defined as a transfer from poor people in rich countries
to rich people in poor countries. — Douglas Casey
: Juanjo
I tend to agree on this, for CLOS is not declarative. It would become very
hard to automatically deciphering defsystem files, and what they do.
I also do not like the way that ASDF is currently extended.
But I don't have anything better to offer.
XCVB tries to have built into it all
2011/10/16 Gábor Balázs gab...@gmail.com:
But there would be a nicer way, and this is the proposal. What about a new
asdf option (eg :compile-with-nicknames), which could look like something
this?
(defsystem my-system
:depends-on (package-1 package-2 package-3 ...)
I have my function, which does the described job for me too. The point here
is to offer this functionality in public on an easy, standard way.
Agreed.
Personally, I like to have a single defsystem sexp in the asd file, so I
would prefer avoiding function definitions there.
Same here. However,
Question: in order to make this consistent, can I take away the call to
ASDF-MESSAGE and just push the output through without prefixing?
Yes. Though again, consistent would be dropping this pretense of
respecting *verbose-out* when most implementations don't and can't; at
least not without a
On Wed, Oct 12, 2011 at 12:06, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
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
In 2.017.11, I fixed the allegro version of asdf:run-shell-command on Unix.
I also changed the way that same function is broken on Windows
so at least it gives users some control, and behaves in a more
regular way across implementations — i.e. some may call CMD,
some may try to call sh instead,
sorry for the lack of response in the last days -- little time to code left
and even less for reading mailing lists.
Ningún problema.
I see that your current ECL replaces si:: by ext:
on a few symbols in its version of ASDF.
Should I merge that into the official ASDF,
or should I wait
On Fri, Oct 7, 2011 at 08:40, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
Do we want to (a) leave run-shell-command half-broken on various
combination of OSes and implementations as soon as any argument needs
quoting, do we want to (b) use heavy artillery to solve
My plan:
1- declare the interface deprecated for now
2- work with the authors of said software to migrate off of it.
3- when no one is known to use it anymore, make it issue a warning at
compile and/or runtime.
4- after a few versions, make it issue an error
I don't think that's a full
Dear Andreas,
it was fun reading your blog post:
http://boinkor.net/archives/2011/10/a-weird-problem-with-asdf-on-nfs.html
You're not the first one having experienced problems with clock skew.
In 2.011.3, we fixed an indefinite loop that could happen in defsystem
in presence of NFS clock skew.
Dear Juanjo,
I see that your current ECL replaces si:: by ext:
on a few symbols in its version of ASDF.
Should I merge that into the official ASDF,
or should I wait until you make a release of ECL?
If I should merge, here is the attached patch
that you or I can commit into ASDF.
If I should not
Do we want to (a) leave run-shell-command half-broken on various
combination of OSes and implementations as soon as any argument needs
quoting, do we want to (b) use heavy artillery to solve the problem
correctly, or should we not just (c) delete this broken functionality
that obviously nobody can
On Thu, Oct 6, 2011 at 23:14, Daniel Herring dherr...@tentpost.com wrote:
There are so many problems with portable shell programming that I don't
think (b) [fix run-shell-command] can be done in general.
[...]
IMO, the right approach is to have a core CL library that gives direct
access to
2011/10/5 Сергей Катревич linkf...@newmail.ru:
Hi Lispers!
Привет Sergey!
I research sources ASDF Library. I am not understand: Why repeat the
compilation of a file (below code and details)?
Probably a bug.
Those retry state machines date from before my time,
and though I tried not to touch
I rewrote the perform-with-restarts methods based on what I understand
they *should* be doing,
and without any of the state machine complication that I never quite
got the hang of.
Can you tell me if ASDF works better for you with the attached patch?
I passes all self-tests for me (on SBCL), but
Dear Robert,
On Mon, Oct 3, 2011 at 09:18, Robert Goldman rpgold...@sift.info wrote:
P.S. I just rebased and pushed run-shell-command, which was not (of
course) a fast-forward push
regarding your rebase push, it seems that you (probably
intentionally) didn't push to master, only to a
: fare
: rpgoldman
regarding your rebase push, it seems that you (probably
intentionally) didn't push to master, only to a branch.
To push to the branch, I recommend you delete the old branch and push
to a new one.
You could reuse the same name, but it would only create confusion to
people
On Tue, Sep 13, 2011 at 11:18, Robert Goldman rpgold...@sift.info wrote:
On 9/13/11 Sep 13 -9:08 AM, Robert Goldman wrote:
I just installed ECL from MacPorts, and when I run the test suite I get
a failure.
Using ecl -norc
Ran 35 tests:
34 passing and 1 failing
failing test(s):
, Sep 13, 2011 at 11:43, Robert Goldman rpgold...@sift.info wrote:
On 9/13/11 Sep 13 -10:29 AM, Faré wrote:
On Tue, Sep 13, 2011 at 11:18, Robert Goldman rpgold...@sift.info wrote:
On 9/13/11 Sep 13 -9:08 AM, Robert Goldman wrote:
I just installed ECL from MacPorts, and when I run the test suite I
On Tue, Sep 13, 2011 at 18:41, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
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
OK, so Robert pushed something as 2.017.3, and I made a few
adjustments as 2.017.4.
Juanjo, can you test whether this satisfies you?
Regarding ECL, do fasls have a different extension when using the
bytecode compiler than when using the normal compiler? I hope so and
suppose so. Otherwise there
On Fri, Sep 9, 2011 at 18:53, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
On Sat, Sep 10, 2011 at 12:41 AM, Faré fah...@gmail.com wrote:
On Fri, Sep 9, 2011 at 18:33, Robert Goldman rpgold...@sift.info wrote:
Question: any objection to modifying your patch so that we
OK, sorry about that. I did the bin/bump-version, and pushed.
No problem. Thanks. Just be sure to bump-version before you push to master.
As for pushing to master, while I am not perfectly confident in the
patch, it passes all the tests, and I'm as confident as I can get
without people on
On Mon, Aug 1, 2011 at 16:20, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
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
already loaded. So when I tell ASDF to load foo
(again), it says a is already loaded, I need only load b.
Unfortunately, that is not true --- the OLD a component is already
loaded, but the NEW one has not been loaded.
...
[Indeed, Faré and I had in the past discussed the possibility that when
a new
Thanks a lot!
I therefore released ASDF 2.016.3 as 2.017.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
On 26 July 2011 12:29, Zach Beane x...@xach.com wrote:
Bart Botta found the issue. clim-listener has this form:
(:file asdf :depends-on (package))
It
On 9 July 2011 15:48, Scott L. Burson sc...@ergy.com wrote:
Hi Faré!
Here's a little hack I just wrote because I wanted to see the
dependency DAG for a system I'm working on:
(in-package :asdf)
(defun* show-dependencies (system-name key descriptions?)
(let ((seen (make-hash-table :test
On 16 June 2011 08:45, Robert Goldman rpgold...@sift.info wrote:
On 6/15/11 Jun 15 -9:05 PM, Chun Tian (binghe) wrote:
Hi, Faré
It's caused by LispWorks' ASDF integration feature [1], it's also in attach.
I have following line in my LispWorks init file:
(example-compile-file misc/asdf
Recently I found a strange behaivour in latest ASDF: it internally converts
all my pathname namestrings into lower-case, although I'm using a
case-insentive HFS on Mac.
I have following items in asdf:*central-registry*, these packages are either
maintained/modified by me or not yet with
Quicklisp systems are located via a function appended to the end of
ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*. It looks like ASDF defines
this variable with DEFPARAMETER, so every time asdf.lisp is loaded, the
value is set to ASDF's initial value. It seems to me that ASDF should
use DEFVAR
Your reactions to bug reports are either null, or very discouraging.
Which bug did you report that I didn't address?
There are archives, please show me.
I usually only get fixes or workarounds by people other than you.
I'm glad you're getting support from others. Unhappily,
you won't get any
On 11 June 2011 11:00, Nikodemus Siivola nikode...@random-state.net wrote:
On 11 June 2011 17:34, Raymond Toy toy.raym...@gmail.com wrote:
Don't know about that. Cmucl has *after-save-initializations* which
is a list of functions to be run when the core is restarted.
SBCL has similar
Dear binghe,
On 12 June 2011 22:47, Chun Tian (binghe) binghe.l...@gmail.com wrote:
I don't think the new feature for RMCL really working: [...]
As above test shows, I started a clean RMCL without ASDF and then manually
compileload ASDF 2.016.2, pushing only one system directory (as POSIX
that
this could actually work in the mid run and not cause any further problems
down the line. Please make sure that it stays that way.
Best,
Pascal
On 12 Jun 2011, at 02:25, Faré wrote:
TL;DR: ASDF currently doesn't play so well with logical pathnames.
I'm seeking advice on how to make
2011/6/11 Chun Tian (binghe) binghe.l...@gmail.com:
Hi, Faré
Today I compile latest asdf.lisp in MCL and see two warnings:
? (compile-file #PMacintosh HD:Users:binghe:Lisp:packages:asdf:asdf.lisp)
;Compiler warnings for Macintosh
HD:users:binghe:Lisp:packages:asdf:asdf.lisp :
; :LAMBDA
TL;DR: ASDF currently doesn't play so well with logical pathnames.
I'm seeking advice on how to make things better —
or on whether it's worth the trouble.
Dear all,
Pascal's recent plight with logical pathnames on SBCL
once again rises the issue of how much ASDF (or SBCL)
should support logical
Regarding RMCL and logical pathnames, please test 2.016.2.
I introduce some non-trivial pathname changes.
On RMCL, ASDF sees strings as /posix/namestrings/ in its configuration.
if you want OS9-style pathnames, they are #pthat:a:way:. You can thus
both trivially share your configuration with
Here is my .sbclrc
(setf (logical-pathname-translations costanza)
`((**;*.fasl.* ,(format nil /Users/costanza/.cache/common-lisp/~A
~A/**/*.fasl
(lisp-implementation-type)
(lisp-implementation-version)))
(**;*.*.*
On 9 June 2011 09:35, Mark Evenson even...@panix.com wrote:
Stellian's [normalization to ANSI semantics of COMPILE-FILE-PATHNAME*][1]
has the unfortunate effect of breaking ABCL's translation of systems
packaged in jar files.
Oops. This wasn't caught by my tests. My sincere apologies.
Can you
Note that when I (describe #pjar:file:///foo/bar.jar!/baz/quux.lisp)
I get:
#Pjar:file:/foo/bar.jar!/baz/quux.lisp is an object of type
EXTENSIONS:JAR-PATHNAME:
HOST NIL
DEVICE (#P/foo/bar.jar)
DIRECTORY (:ABSOLUTE baz)
NAME quux
TYPE lisp
A user question:
011 13:28, Erik Winkels aeri...@xs4all.nl wrote:
Hi,
I'm not sure whether ASDF is the culprit here but I need some help tracking
down a problem I'm having:
I'm developing a program which gets called from the command line so I'm also
testing it like that. i.e. I'm using
On re-reading CLHS, I retract my admission that ABCL is non-conformant.
From the CLHS glossary a valid pathname device [is a] a string, nil,
:unspecific, or some other object defined by the implementation to be a
valid pathname device. ABCL is using the some other object ability here.
The
Please try 2.016.1 and see if it satisfies you.
Pathnames are a big FAIL of CL.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Slogans rarely convince the unconvinced. However, they do rally the troops
already on your side. — John McCarthy
[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
On 28 May 2011 14:50, Pascal Costanza p...@p-cos.net wrote:
On 23 May 2011, at 00:17, Faré wrote:
The setup is not that hard. Here is what I have in my .sbclrc
(setf (logical-pathname-translations costanza
That's fine, of course. I only object to the ASDF 2 documentation seemingly
promoting a particular approach for which there is not necessarily a
community-wide consensus that it's the best one under all circumstances.
Logical pathnames are not recommended because there is no documentation
on
Dear ASDF users,
I'd like to release ASDF 2.016 next weekend.
Can you powerusers test the current ASDF,
and tell me if you find anything wrong?
Since 2.015, changes include:
* Fix to load-source-op (broken in 2.014.13) (thanks to Martin Simmons)
* Fix infinite loops in some .asd containing
The setup is not that hard. Here is what I have in my .sbclrc
(setf (logical-pathname-translations costanza)
`((**;*.fasl.* ,(format nil /Users/costanza/.cache/common-lisp/~A
~A/**/*.fasl
(lisp-implementation-type)
Historical reasons: .asd files are meant to only contain simple stuff,
Not that this really matters, but ... this is not so.
.asd files have always been meant to contains things like custom
component definitions and defmethods for them -- not just simple
stuff. Historically speaking
I tried to use the mechanism promoted by ASDF. It worked in 7 out of 8 Common
Lisp implementations that I have checked. Unfortunately, it didn't work in
the eighth one at all, no matter what I tried. This has cost me quite some
time that was eventually wasted.
I apologize for any such bug.
On 20 May 2011 16:18, Zach Beane x...@xach.com wrote:
.asd files should not be loaded directly with cl:load or any shortcut
that involves cl:load, like cl path/to/whatever.asd. ASDF sets up an
environment when loading an .asd file that is not the same as the
environment established by
Logical pathnames work well as long as all your files follow the
naming restrictions. Which is not the case for all CL programs and
libraries, even less so when you're integrating with other languages
and their naming conventions, or (shudder) files that have version
numbers in them...
If
On 17 May 2011 07:41, Mark Evenson even...@panix.com wrote:
ASDF contains some specialized code for ABCL that enable the translation of
ASDF systems whose source is packaged into jar files to locate the
corresponding object files in ASDF's user cache.
The ASDF API:
* clear-output-translations
I'm gonna need a bit more time to chew over the ASDF code, but thanks for
the general direction. I must confess that in spite of the reasonable
looking documentation and having contributed the function translation code
to ASDF, its whole output translation API has never really gelled in my
Ok, I don't know why I didn't notice this before... but it's not over yet.
Ouch.
There is another -- very similar -- issue that causes trouble if there
are EQL method specialized on the system in the .asd file for the
system in question ... not exactly a rarity.
Try with ITERATE. It
OK, ASDF 2.015.2 should now be clever enough to avoid any such
infinite loop. If you can reproduce the previously bad setup with the
new ASDF and check that it's now working, that'd be great.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
He who refuses to do
On 10 May 2011 12:45, Nikodemus Siivola nikode...@random-state.net wrote:
Steps to reproduce:
1. Get ASDF 2.015 or .1
2. Install Quicklisp, (ql:quickload flexi-streams)
3. Install Flexi-Streams outside quicklisp as well. (For the purposes
of bug reproduction, putting a copy of
modes than
dumping a backtrace on syntax errors.
We need to find someone who wishes to lead us on that journey, though,
since Faré has announced his desire to move on to something different.
If you think there's long term future in the current ASDF
architecture, you'll need someone else than I
OK, following lp#769634 I have committed an ASDF 2.014.14,
which exports two classes cl-source-file.cl and cl-source-file.lsp
that allow you to easily define systems the source files of which
use extension .cl or .lsp instead of .lisp
-- assuming you're using a recent enough ASDF (i.e. 2.014.14 or
NB: Meh, shouldn't have gone into this long defense. I somehow took
dherring's remarks personally and don't have the guts to not post this
reply after writing it. Please ignore.
In a nutshell, things like changes to inputs (enforcing contracts), outputs
(changing what's printed) and internal
government is evil doesn't mean native
governments have a right to exist and enslave their people. — Faré
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 27 April 2011 12:57, dherr...@tentpost.com wrote:
These are probably good things, but as Zach mentioned, recently ASDF has
started dragging users through internal development. Its a gripe I have
about Slime and some other key libraries, so you are in good company, but
I cannot follow the
On 27 April 2011 14:14, Zach Beane x...@xach.com wrote:
My primary concern is that, if I don't take the time to try out the
minor commits, a change like the verbosity change would just end up in a
release. In general, I'd rather see opt-in behavior, which I can ignore
until persuaded
On 26 April 2011 12:36, Zach Beane x...@xach.com wrote:
PPS: I just made asdf more verbose in verbose mode. However, verbose
mode is the default, so this may or may not be annoying. Please tell
me.
Now that I've seen it, I do find it both annoying and confusing.
OK. Should I turn verbose off
OK. Should I turn verbose off by default, or should I make verbose
less verbose, or introduce several degrees of verbosity?
I would be pretty happy if the old behavior was reinstated, and nothing
else was changed.
OK. Reverted in 2.014.12, with some additional changes.
Was there a specific
On 23 April 2011 18:03, Zach Beane x...@xach.com wrote:
The ASDF code didn't actually mandate a string type for the slot until a
couple minor versions ago, and that's what's causing the compile-time
failure on SBCL (and only then at safety 3).
Following your failure report, I promptly
I wanted to find the system file that would be loaded by a (find-system
foo) without loading the file first.
I suppose I could reinstate some function to do that - but again,
not just pathnames could be returned, but system objects, too.
It doesn't always make sense, for instance with
I've retried with 2.014.9, and the cffi-grovel-related problems are
gone, but there's an interesting new problem.
2.014.9 includes this line:
(declaim (optimize (speed 2) (debug 3) (safety 3))) ; X debug only
Yes, my bad. I'll be gone in an upcoming 2.014.10 :-/
At (safety 3), SBCL
Following previous discussions on this list and on #lisp, I pushed yet
another change to ASDF.
The patch includes better support for system-finding functions, and
caching of source-registry data so we only hit the filesystem the
first time around. I hope this will make Xach happy. I'll export any
A cursory googling shows that system-definition-pathname is used by
bese qbook's publish-op. Should I reinstate system-definition-pathname
as an alias for system-source-file, or should I expect qbook to be
updated if anyone ever uses it again?
I'm inclined to think that reinstating it, and
I had warned before that one limitation of upgrading asdf was that it
had to be done before to load anything that depends on the new asdf.
Well, I've been bitten by it, badly, when trying to build xcvb on a
new machine. What is surprising is that I haven't been bit by it
earlier.
Symptom: on that
Fixed several issues in 2.014.7. Should make Xach's quicklisp happier,
especially on ECL.
Incompatibility: I deleted system-definition-pathname.
As an exported function, it is redundant with system-source-file.
As an internal function, it is replaced by search-for-system-definition,
which can
: Antony
(asdf:initialize-source-registry
(list :source-registry (list :tree #PC:/git/)
:inherit-configuration))
This should work, which you can check by looking at
asdf::*source-registry*
and/or using asdf:find-system to see if it can find systems.
On 30 March 2011 09:53, Azamat S. Kalimoulline tur...@alphatech.ru wrote:
On xcl it print me getenv not available on your implementation. But xcl have
implementation of getenv:
CL-USER(1): (getenv HOME)
/home/turtle
I already replied to this one. Please update your XCL (0.0.0291 or git
testing has to be manual, but releasing does not have to be.
(and can include many different consistency checks)...
Sure. And even the manual steps could be accounted for by a checklist
enforced by nagging.
Will work on it for next release. Maybe.
It's immaterial which version is shown there.
Because my release process (or lack thereof) sucks.
a `release' target in the developer makefile helps.
It would. Too many manual steps right now, including doing
things on several machines to check implementations that won't run
under Linux amd64. Or I could have chroot's and/or emulators.
On 26 March 2011 12:24, Douglas Crosher dtc-a...@scieneer.com wrote:
Attached is a patch that reworks the output formats to better fit the stream
width.
A new macro 'compatfmt is added that strips out commands that are not
supported by Genera.
Applied, with tweaks, as 2.013.7. Thanks a lot!
OK, considering the many small things I didn't get right in 2.013, I
intend to release a 2.014 by the end of next week. Now would be a good
time to test the latest ASDF (currently 2.013.6), or write tests for
your favorite functionality, report a bug, etc.
I've added tests for the most glaring
On 24 March 2011 17:54, Zach Beane x...@xach.com wrote:
Sorry for not following the line wrapping discussion earlier. Now that
I've had a chance to build some systems, the new output looks a bit ugly
to me.
OK, try with 2.013.5. I restored the previous cleverness in those messages
with
On 24 March 2011 19:28, Andreas Fuchs a...@boinkor.net wrote:
; Loading system definition from
/home/xach/src/asdf/my-very-long-system-woo-hoo.asd into #PACKAGE ASDF0
; Registering #SYSTEM #:MY-VERY-LONG-SYSTEM-WOO-HOO as
MY-VERY-LONG-SYSTEM-WOO-HOO
T
Just out of curiosity (I
On 22 March 2011 03:29, Douglas Crosher dtc-a...@scieneer.com wrote:
The file test/compile-asdf.lisp catches compiler style warnings to avoid
them being counted. However this would not appear to be necessary as the
third result of 'compile-file would seem to be just what is needed to catch
Hum. It so happened that 2.013 had various defects.
Since then, with 2.013.3, I have fixed these issues:
- It couldn't upgrade from 2.000 to 2.008, due to bug (introduced in
2.012.8) that prevented some package-wrangling. Fixed. DONE: added
simple test for upgrades from egregious previous
On 19 March 2011 14:51, Chun Tian (binghe) binghe.l...@gmail.com wrote:
Hi, ASDF developers
I think asdf:*compile-file-failure-behaviour* should never been set to
:error, just :warn is good.
Well, SBCL is known for its anal attitude towards declaring as an
error or failure anything that
.:
A group of men who individually can do nothing but as a group
decide that nothing can be done.
— Fred Allen
-- Forwarded message --
From: Faré fah...@gmail.com
Date: 20 March 2011 00:29
Subject: ASDF 2.013 released
To: asdf-annou...@common-lisp.net
Dear Common Lisp
On 18 March 2011 19:44, Nikodemus Siivola nikode...@random-state.net wrote:
On 18 March 2011 16:58, Sam Steingold s...@gnu.org wrote:
1. In all ones over ~70 characters long. Exact point doesn't seem that
important, but less than 80 at any rate.
I think this is wrong.
I think the underlying
On 17 March 2011 13:44, Zach Beane x...@xach.com wrote:
*output-translations* is:
(((#P/home/xach/.cache/common-lisp/sbcl-1.0.46-linux-amd64/**/*.* T)
(#P/usr/local/lib/sbcl/**/*.* T)
(#P/usr/local/lib/sbcl/**/*.* #P/usr/local/lib/sbcl/**/*.*)
(T
On 17 March 2011 00:22, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
Ouch, I might have messed up with the SBCL_HOME treatment of 2.012.9.
Do you get the same behavior in 2.012.8?
2.012.8 (commit 566a4234) has the style warnings but does not fail.
Thanks! So indeed 2.012.9
On 14 March 2011 10:14, Nikodemus Siivola nikode...@random-state.net wrote:
* To support Genera, I removed ~@ from our error message format
strings. Frankly, I think cuteness matters that much when printing
error.
At least few of those messages could benefit from forced newlines as
an
On 5 February 2011 17:14, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Please understand that all this is about not *hardcoding* in ASDF what the
compiler should or should not do. All you are suggesting is about reader
conditionalization (that means one ASDF file per
On 6 February 2011 16:58, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
Please, understand, I do not want to commit to a particular behavior right
now. I do not know yet how I am going to code the bytecodes compiler, or if
I will allow multiple variants or whether I will
On 5 February 2011 02:55, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:
OK, I'm going to apply this one. Are there any required changes in
asdf-ecl.lisp?
I believe not. But I am still working on this -- the goal is to be able to
plug in a second and different compiler
Do you need to change it dynamically? Why not just have a static #+ecl
or something? don't understand the use case.
Yes, it has to be changeable if the user decides to switch compilers, for
whatever reason. To name one, Windows users will get by default a bytecodes
compiler shipped in, and
1101 - 1200 of 1393 matches
Mail list logo
