On Sat, Feb 22, 2014 at 12:23 AM, Anton Vodonosov avodono...@yandex.ru wrote:
22.02.2014, 09:05, Anton Vodonosov avodono...@yandex.ru:
Results for asdf.3.1.0.70.use-uiop are ready on
[...]
No changes from asdf.3.1.0.70
I meant of course, since asdf.3.1.0.67
On Sat, Feb 22, 2014 at 5:53 PM, Robert P. Goldman rpgold...@sift.net wrote:
Thanks, Faré. Quick follow up: is there any construct that has semantics
like If this feature is not in features, fail?
That's what the (feature feature-expression)
component-depends-on/in-order-to feature does.
Do you
On Sat, Feb 22, 2014 at 2:56 PM, Robert P. Goldman rpgold...@sift.info wrote:
I see that the grammar of dependencies in the manual specifies that
:version appears as a keyword symbol, but feature appears as *not* a
keyword symbol.
Is this a documentation bug? I think so, but you know the
Here's an improved diff, that keeps and properly documents the
(:feature feature-expression dependency-def) dependency-def, and
eliminates the (feature feature-expression) requirement (using names
from the grammar).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
The
On Sun, Feb 23, 2014 at 12:11 PM, Robert Goldman rpgold...@sift.net wrote:
The :REQUIRE directive seems undocumented.
Under what circumstances is it acceptable?
If I remember the intent and interpret the source code correctly,
it is always acceptable, but highly non-portable, and is thus
On Sun, Feb 23, 2014 at 5:55 PM, Robert P. Goldman rpgold...@sift.info wrote:
This one puts the values in SYSTEM-DEPENDS-ON,
SYSTEM-DEFSYSTEM-DEPENDS-ON, and SYSTEM-WEAKLY-DEPENDS-ON in canonical
form before returning them.
It also bundles fixes from Faré.
Thanks a lot.
I pushed minor
On Sun, Feb 23, 2014 at 10:33 PM, Robert Goldman rpgold...@sift.net wrote:
Faré wrote:
On Sun, Feb 23, 2014 at 12:11 PM, Robert Goldman rpgold...@sift.net wrote:
The :REQUIRE directive seems undocumented.
Under what circumstances is it acceptable?
If I remember the intent and interpret
So I believe what happens is that use of :REQUIRE triggers the automatic
generation of a REQUIRE-SYSTEM for the corresponding module, and then its
loading, when necessary, is handled by REQUIRE. Yes?
Well, :REQUIRE triggers the generation of a REQUIRE-SYSTEM only if the
implementation
Dear Dave,
The test-touch-system-1.script I'm not sure I understand.
Is it a case where your filesystem doesn't have second-granularity
timestamps but only minute-granularity timestamp?
What is a good way to test that?
Can you run this code?
make load l=clisp
(in-package :uiop)
(nest
Should we be treating Windows filenames as case-insensitive?
According to Stack Overflow, NTFS can be configured to be
case-sensitive, but typically isn't.
Maybe PATHNAME-EQUAL should case-flatten (string-equal) on Windows?
It's a tough call, since some filesystems (e.g. remote NFS) are
The SBCL test doesn't show any signs of Faré fixing this so that the
directory components on windows are treated as case-INsensitive
(test-utilities.script failed).
Oops, reading the CLHS, I see that EQUALP specifically does NOT
descend into pathnames, unlike other structures, and just calls
On Tue, Feb 25, 2014 at 11:26 AM, Dave Cooper david.coo...@genworks.com wrote:
Please test again with the latest ASDF and tracing
uiop/run-program::%system with two colons.
https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-test.text
On Tue, Feb 25, 2014 at 4:40 PM, Felix Lange f...@twurst.com wrote:
Sorry for hijacking this discussion.
No problem. There are no stupid questions (but see the famous
cluelessness demotivational poster).
Why are system names case sensitive at all?
Wouldn't it be more sane to just make them
On Tue, Feb 25, 2014 at 9:20 PM, Dave Cooper david.coo...@genworks.com wrote:
Thank you for your patience with my zombielike testing.
No, thank you for being my zombie in this proxy testing.
I (hopefully) fixed the SBCL failure now (see my reply to rpgoldman).
sbcl:
51 tests passing and 0
Dear Robert,
I'm not sure I like your latest restriction of system names to what
logical pathnames accept: one of the big pluses of not using logical
pathnames everywhere was to allow for a wider range of system names.
Consider the widely used cl+ssl, for instance.
At ITA, we also used to have
Dear Robert,
Logical pathnames are a horror that no one should use, and the
portability constraints of which should not be inflicted on everyone.
Could you revert this new constraint?
Not until we remove logical pathnames support from the central registry.
for ASDF2 and ASDF3, my policy
On Wed, Feb 26, 2014 at 5:45 PM, Robert P. Goldman rpgold...@sift.info wrote:
BOV5A signals ARNESI:DEFLOOKUP-REDEFINITION because of bug in EVAL-WHEN
logic.
You could push #(deflookup-redefinition arnesi) onto
uiop:*uninteresting-conditions*.
And yes, there ought to be a better way to control
On Thu, Feb 27, 2014 at 2:46 PM, Dave Cooper david.coo...@genworks.com wrote:
Here is clisp output from 3.1.0.77 with the wclisp.diff patch applied:
The patch should fail to apply, because it's already been applied.
Dear lispers,
I've just released cl-launch 4.0.0: so you can invoke CL programs from
the command-line.
My classic demo for cl-launch is as follows:
for l in allegro ccl clisp sbcl ecl lispworks abcl cmucl xcl gcl ; do
cl-launch -l $l -i '(format t '$l' ~S ~% `#5(1 ,@`(2 3)))' 21 |
grep ^$l ;
On Thu, Feb 27, 2014 at 11:46 PM, Robert P. Goldman rpgold...@sift.info wrote:
I have pushed what I hope are substantial improvements to the ASDF
manual, at least to the early parts of it.
Thanks! I pushed minor tweaks to it.
Faré: is it easily possible to push this to the web page using your
On Fri, Feb 28, 2014 at 9:18 AM, Robert P. Goldman rpgold...@sift.info wrote:
I have pushed another quick set of modifications; all grammar and
punctuation, with some chopping up by adding new subsections.
Uh, I don't see anything new on branch master.
If you didn't push, can you rebase to
On Fri, Feb 28, 2014 at 2:21 PM, Robert P. Goldman rpgold...@sift.info wrote:
I have pushed another quick set of modifications
OK, I did another pass, too, pruning old stuff, and suggesting a way
to upgrade your asdf module, if not your implementation, with a
runnable script.
—♯ƒ • François-René
of them. — Faré]
On Sat, Mar 1, 2014 at 1:39 PM, Faré fah...@gmail.com wrote:
Is anyone at all using asdf-bundle with ECL?
Well, I did hack that bundle thing, in the end.
If any ECL user uses the bundle functionality, please contact the
asdf-devel mailing-list.
* prologue and epilogue functionality was restored
Yes the prologue and epilogue is (or will be, in the publicly and officially
sanctioned ASDF-way once I send you my small MKCL mods for ASDF 3) used
after all. Maybe not really by ECL, although it should, but by MKCL.
It is an essential part of the program-op processing.
You are right about
As I am writing a parting article (for ELS 2014? ILC 2014?) on the
what and wherefore of ASDF3, I tackled the question of force and
force-not, and was reminded about that discussion whether I got it
right or backward when I gave force precedence over force-not.
On Tue, Mar 4, 2014 at 8:06 AM, Robert P. Goldman rpgold...@sift.info wrote:
This has always been my impression, as well: force-not serves to block force,
so should have precedence. I am pretty sure there is a launchpad ticket
discussing this. I would be happy to get a patch in to that effect
Regarding ASDF and ECL, it seemed to me that *load-system-operation*
had been designed
so I could/should do this in asdf/bundle:
(unless (use-ecl-byte-compiler-p)
(setf *load-system-operation* 'load-fasl-op))
Unhappily, when I did, I got 4 errors while testing. I found 1 bug in
ASDF, 2 bugs
Dear Liam,
I am using asdf-system-connections and notice a glitch in its design. As the
original author no longer maintains it, I'm try to fix this myself. This
system is designed to allow the loading of a connected system (say A)
automatically when two or more dependent systems (say B and C)
Frankly, the whole idea is bunk. A build system ought to be
predictable, reproducible, and minimize surprise.
asdf-system-connections, as it stands, is not great in this regards,
but at least does not disrupt the internal dependency model of ASDF;
it stands on top. Your proposed extension
deprecate both.
Question for Faré: you say that weakly-depends-on is not deterministic,
and that it's effects depend on load order. Off-hand, I don't see this.
weakly-depends-on should be deterministic in a given installation, so
there's that.
Load order effects happen only if some crazy extension
On Fri, Feb 28, 2014 at 3:28 AM, Faré fah...@gmail.com wrote:
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgold...@sift.info
wrote:
How would you all feel about an alternate default location for lisp
systems, in addition to
~/.local/share/common-lisp/source/
NB: I think a new
Dear Anton,
can you (1) run cl-test-grid on all implementations with 3.1.0.94, our
release candidate?
can you run the cl-test-grid on at least SBCL with the latest ASDF and
the attached patch?
In writing my article ASDF3, or Why Lisp is Now an Acceptable
Scripting Language, one of the
On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza p...@p-cos.net wrote:
This has the potential of messing up already existing configurations
(again!). The choice of ~/lisp would certainly mess up mine, and I can
imagine many other scenarios. Please don't do that.
I'm not sure what you mean by
On Wed, Mar 12, 2014 at 3:16 AM, Pascal Costanza p...@p-cos.net wrote:
I'm expecting asdf to suddenly see asd files that it shouldn't. (In my
configuration, only ~/lisp/develop/ contains active systems, the rest of
~/lisp may contain inactive ones - for example, alternate versions of the
Dear Common Lispers,
I've submitted this article to ELS 2014. Happily, the deadline has
been extended by two weeks, which leaves me time to rewrite it better,
with your feedback.
Can some of you proofread the article, both/either at a low-level and
a high-level?
I feel I didn't tie the parts of
While we are bikeshedding, I feel that asdf:load-system is (1) still
too long a name, and (2) not generic enough, in case I want to use
ASDF for stuff that isn't loading code into the current image.
Therefore I propose there be
(asdf:build 'foo)
as the shorthand for the new (as of ASDF3)
On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper david.coo...@genworks.com wrote:
On Wed, Mar 12, 2014 at 1:04 PM, Faré fah...@gmail.com wrote:
1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about
On Wed, Mar 12, 2014 at 2:02 PM, Cyrus Harmon ch-l...@bobobeach.com wrote:
I would suggest asdf:build-system (or renaming load-system, etc… to load,
etc…). Let’s be consistent here.
There is already a build-system. One of the points was to make it
short, since it's going to be used a lot at
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane x...@xach.com wrote:
Dave Cooper david.coo...@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how
1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about that.
You could make it ~/local/common-lisp/ if you're into larger paths.
I think I will put asdf into the pathname, per our earlier discussion,
On Wed, Mar 12, 2014 at 2:52 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
While we are bikeshedding, I feel that asdf:load-system is (1) still
too long a name, and (2) not generic enough, in case I want to use
ASDF for stuff that isn't loading code into the current image
On Wed, Mar 12, 2014 at 3:17 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
~/local/common-lisp/ has the advantage of being clutter-limiting,
XDG-like if not strictly XDG, clean, etc., and just one character
longer than your proposal.
I am less excited about the future and find
On Wed, Mar 12, 2014 at 3:08 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane x...@xach.com wrote:
Dave Cooper david.coo...@genworks.com writes:
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:
I don't think I
: Faré
: p-cos
: rpgoldman
asdf is not a tool for beginners. Beginners will either deal with a bare
Common Lisp implementation, or they want to experiment with third-party
libraries, in which case they want to use quicklisp these days. Once you
need to define your own systems, you're
• http://fare.tunes.org
Just because your semi-free country government is evil doesn't mean native
governments have a right to exist and enslave their people. — Faré
On Wed, Mar 12, 2014 at 7:24 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza p...@p-cos.net wrote:
Can I set CL_SOURCE_REGISTRY to a value that deactivates all default
paths? Then I don't care what the default is...
Yes
: rpgoldman
: dherring
I am sorry, but I promise you that this will NOT be consistent with XDG. I
have no idea why those people think it's a good idea to put files in
directories where ls cannot find them.
ASDF already has a deeply-nested, invisible-to-ls location that is XDG
compliant
: dherring
In my opinion, a lot of the complexity in ASDF is caused by its conflation
of two separate goals: a build system and a loader.
Actually, in my asdf3 article, which I invite you to review,
I actually list that as an asset that ASDF has compared to C systems:
by having the same
Dear Robert,
I see that your latest edit of the ASDF manual failed to include @node surgery
(why can't @node's be automatically updated by emacs or some other tool???)
I also see that regarding resetting the configuration, things weren't updated.
The situation is that there is now a function
and reported quite a lot of
bugs to Faré in the past.
Yes, and I am grateful to you (Stelian), who indeed in IRC (and live!
and launchpad) discussions contributed a lot to ASDF.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
The highest of minds / Often have built
Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no
such thing, nor the git repository.
The debian/changelog doubles as release notes. I just updated the
README to point at them.
Release notes are otherwise posted to this mailing-list as part of
each release's announcement.
It's not like my changes were done in secret.
They weren't done in secret, but many of them were just commits with no
discussion on the list.
As long as the change hasn't been released, it's up for discussion.
And it's much easier to discuss code that was committed than ideas in
the air. When
They weren't done in secret, but many of them were just commits with no
discussion on the list.
As long as the change hasn't been released, it's up for discussion.
Do you seriously expect people to review the commit stream for
potentially harmful changes/addition ?
Can you name a
On Thu, Mar 13, 2014 at 2:30 PM, Robert P. Goldman rpgold...@sift.info wrote:
Stelian Ionescu wrote:
[...]
Every release comes with release notes that mention changes to the API.
I haven't announced changes with every commit, because that would be
verbose,
and people who're interested
On Thu, Mar 13, 2014 at 2:40 PM, Robert P. Goldman rpgold...@sift.info wrote:
I'm a little concerned about making BUILD-OP be the default operation.
It seems to me that BUILD is not a good synonym for LOAD, which is
how BUILD-OP is currently interpreted.
I think the conventional
I see that your latest edit of the ASDF manual failed to include @node
surgery
(why can't @node's be automatically updated by emacs or some other tool???)
I wonder if you are actually getting the head, or if my push somehow
failed. I just did
git diff 3.1.0.94 master doc/asdf.texinfo
On Thu, Mar 13, 2014 at 4:24 PM, Robert P. Goldman rpgold...@sift.info wrote:
For the record, it's not that I'm objecting to the build-operation idea.
I'm sorry if you got that idea, and felt that you had to spend a lot of
time convincing me!
My concern was a much more limited one: that the
of sympathetic contrivances
may be as natural to future times as to us is a literary correspondence.
— Joseph Glanvill, 1661
On Thu, Mar 13, 2014 at 7:11 PM, Faré fah...@gmail.com wrote:
On Thu, Mar 13, 2014 at 4:24 PM, Robert P. Goldman rpgold...@sift.info
wrote:
For the record
: Faré
: janderson
Daniel, if you want changes only every 5 to 10 years, do like
janderson: try an upgrade every 5 years, find that it breaks your code
somehow and downgrade back to the old version without further
investigation. Then maybe 10 years from now you'll get the system
dependency
On Thu, Mar 13, 2014 at 10:07 PM, Anton Vodonosov avodono...@yandex.ru wrote:
The tests on 3.1.0.94 have completed.
No regressions detected, here is the report:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-37.html
The only failure is teepeedee2, which fails because of its own
Dear Robert,
I pushed my changes to your build-op branch. Easier than mailing patches.
Well, ASDF itself has long been described as a build system or build tool
(including in our ILC 2010 article), just like make, ant, etc.
See also Wikipedia pages for each of these.
What do these programs
On Thu, Mar 13, 2014 at 11:47 PM, Faré fah...@gmail.com wrote:
Dear Robert,
I pushed my changes to your build-op branch. Easier than mailing patches.
Well, ASDF itself has long been described as a build system or build tool
(including in our ILC 2010 article), just like make, ant, etc.
See
Note that if we rename it make, it would also be nice to rename
build-op to make-op before anyone uses it.
We should also rename :build-operation to :make-operation or :make-op
or :make, and just have some #-asdf3.1 in asdf.asd to cope with
upgrade from the one and only current client of it,
final (which if it's accepted at ELS 2014,
is April 21, 2014).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Common Lisp makes it easy for you to grow your own language; however, it
makes it difficult for that language to be the same as anyone else's. — Faré
On Fri, Mar 14, 2014 at 9:28 AM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
I get it, but now ASDF does more than one kind of build, including some
things (with the bundle-op) that look a lot more like what 'make' does
than what ASDF has done up to now.
Indeed. On the other
On Fri, Mar 14, 2014 at 12:24 PM, Anton Vodonosov avodono...@yandex.ru wrote:
14.03.2014, 20:20, Anton Vodonosov avodono...@yandex.ru:
As systems depend on each other, a failing system breaks other systems.
To get sense of the situation the following report may help:
On Fri, Mar 14, 2014 at 4:01 PM, Anton Vodonosov avodono...@yandex.ru wrote:
Why this matters:
http://fare.tunes.org/files/tmp/asdf/asdf3-2014.html#%28part._.Safety_before_.Ubiquity%29
You say Creating a fresh copy of the standard readtable around each action
is too expensive.
But why
On Fri, Mar 14, 2014 at 6:10 PM, Robert Goldman rpgold...@sift.net wrote:
Quick follow-up: what about blowing this discussion into launchpad under
the rubric of Manage CL syntax or something like that.
I would prefer not to lose the discussion.
I believe this is a place where a tool like
: Faré
: Robert
Here is my theory: safe code needs to respect hygiene, because you
never know which system are loaded before or after: it depends on the
overall plan of the toplevel target system. Therefore is it never
correct to rely on other systems having set a particular readtable
Dear Anton,
Fare, I wonder, why ironclad fails with your patch.
I have checked the source, ironclad.asd creates new *ironclad-readtable*
and binds cl:*readable* to it in the :around method for compile-op
(like a home-made around hook)
So, it looks like ironclad does not modify any global
On Sat, Mar 15, 2014 at 9:08 AM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
Should ASDF fail the libraries which modify global readtable - I doubt it's
ASDF role.
Yes it is, see my paper:
http://fare.tunes.org/files/tmp/asdf/asdf3-2014.html#%28part._.Safety_before_
On Sat, Mar 15, 2014 at 4:52 PM, Robert P. Goldman rpgold...@sift.info wrote:
Here is an example of a kind of system that will be broken by this
proposed change:
* We have a distributed system that is lisp-based.
* There is a small set of ASDF systems that constitutes the common base
of the
On Sat, Mar 15, 2014 at 9:09 PM, Jean-Claude Beaudoin
jean.claude.beaud...@gmail.com wrote:
Here is, as previously mentioned, the git format-patch with the
modifications needed to port current ASDF head to MKCL 1.1.8 and later. This
has been tested on Linux Ubuntu 12.04 and MKCL 1.1.8 where it
: Faré
: Robert
Well, but consider this hypothetical person who doesn't know what's
going to happen and who isn't familiar with ASDF already.
S/he types (asdf:make foo) and *either* gets foo loaded into his/her
lisp image or an executable file gets dropped onto his/her disk?
Whichever
Dear Anton,
can you do a cl-test-grid test with the code in the standard-syntax
branch from git://common-lisp.net/projects/asdf/asdf.git
(commit 2c1107) ?
That branch has my each system gets its own syntax thing, based on a
general-purpose each system has a set of private variables protocol.
On Sun, Mar 16, 2014 at 11:25 AM, Robert P. Goldman rpgold...@sift.info wrote:
Whichever makes sense for the given system, and that's the feature:
the user doesn't have to know which newfangled operation the system is using,
that will do the Right Thing™.
Once again, the person who knows the
I don't know enough to translate a darcs repo to git. I could probably
manage this, but tcr buried the NAMED-READTABLES repo somehow inside an
EDITOR-HINTS repo, and linked the two in some way I don't understand.
I have a script to do that somewhere on common-lisp.net.
I actually already did
On Sun, Mar 16, 2014 at 11:18 AM, Robert P. Goldman rpgold...@sift.info wrote:
PROPOSED NEXT STEPS:
1. A clear proposal for this modification be made. Right now the
details of the proposed modification are wrapped in a fairly opaque
discussion. The discussion is framed in terms that are
I've open the following bug on launchpad for this issue:
A non-hidden default source tree
https://bugs.launchpad.net/asdf/+bug/1293278
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
A programming language is low level
when its programs require attention to the
I've opened a bug on launchpad for the technical issue:
Fix defsystem to accept strings as operation designators
https://bugs.launchpad.net/asdf/+bug/1293292
I beg the maintainer to consider the technical issue for inclusion in 3.1.1,
if not the policy issue of promoting the result as default.
Looks great. A few minor nits and a larger issue.
Minor nits:
* dangling ( at end of line, not in style
* in the initialize-instance, I would still catch the :lisp-files and
assert that it's null. That's protecting against people using it
outside ECL (even on ECL, I'd like to get rid of it, but
I refactored that paper by making separate short (8 pages) and
extended versions (24 pages), thereby fitting the limit while being
able to say everything I had on my heart. I submitted the short PDF to
ELS 2014. I also moved the papers to a more permanent location.
[Source]
On Wed, Mar 19, 2014 at 5:54 PM, Robert Brown robert.br...@gmail.com wrote:
Does ASDF set compiler optimization settings before compiling
each file when building?
Not by default, though you can teach it to.
I'm concerned that changing the
optimization setting inside one source file could
• François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Yield to temptation; it may never pass your way again.
— Robert Heinlein, Time Enough For Love
On Thu, Mar 6, 2014 at 12:14 AM, Faré fah...@gmail.com wrote:
Regarding ASDF and ECL, it seemed to me that *load-system
On Thu, Mar 20, 2014 at 5:34 PM, Dave Cooper david.coo...@genworks.com wrote:
Do you plan to change the name of monolithic-fasl-op ?
Yes, it would become monolithic-compile-bundle-op.
I presume this question means means you're using it, so I'd leave an
alias behind.
I also plan to not rename
•ReflectionCybernethics• http://fare.tunes.org
Politicians are like diapers: they must be changed often.
And for the same reasons. [Also, adults don't need either of them. — Faré]
On Thu, Mar 20, 2014 at 8:20 AM, Robert Brown robert.br...@gmail.com wrote:
Here's the problem I want solved. A library author
Dear Robert,
please consider merging these two branches before release:
* renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018
* build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
I can do the merging, if you want.
—♯ƒ • François-René ÐVB Rideau
Dear Anton, dear Robert,
can you run tests with the fare-3.1 branch of asdf?
I prepared this branch fare-3.1 with the changes I'd like to see in
3.1 *plus* some attempt at a minimal syntax control feature, as
described in one previous email:
It notably has
(defvar *shared-readtable*
: Faré
: Robert
please consider merging these two branches before release:
* renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018
I'm a little uncomfortable with this, simply because I don't use the
bundle operations, so I worry that I might be letting someone else
On Tue, Mar 25, 2014 at 12:16 AM, Anton Vodonosov avodono...@yandex.ru wrote:
Hi Fare, sorry for the long reply.
Will do it, but was a bit overloaded recently by work and personal tasks,
+ was running tests for quicklisp 2014-03-17 and ABCL 1.3.0
Is you request still actual - standard-syntax
0- OK, I managed to compile MKCL from git after updating its ASDF.
Then, I massaged program-op to do what I wanted,
which involves linking UIOP or ASDF — it's committed to branch build-op.
Problems I found:
1- you look for encodings in #pSYS:ENCODINGS; (upper case,
as per the standard), which is
On Mon, Mar 24, 2014 at 6:30 PM, Faré fah...@gmail.com wrote:
* build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
This one I would rather postpone until after the next release. Getting
it into use would require even MORE modifications to the manual, and
manual updates are already
On Tue, Mar 25, 2014 at 12:16 AM, Anton Vodonosov avodono...@yandex.ru wrote:
Hi Fare, sorry for the long reply.
Will do it, but was a bit overloaded recently by work and personal tasks,
+ was running tests for quicklisp 2014-03-17 and ABCL 1.3.0
Is you request still actual - standard-syntax
Your strategy seems reasonable. How about we put into the manual a
chapter, towards the end (an appendix, perhaps?) describing the
EXPERIMENTAL build-op support, thus putting our users on alert that we
reserve the right to change BUILD-OP in ways that break their code.
I don't want there to
On Tue, Mar 25, 2014 at 9:17 AM, Robert Goldman rpgold...@sift.net wrote:
JCB complains that requiring UIOP:RESTART-IMAGE causes MKCL somehow to
end up sucking the compiler into programs, causing severe bloat.
Can we provide an option to PROGRAM-OP that does *not* invoke
RESTART-IMAGE,
Dear Anton,
the new thing to test is the HEAD of branch syntax-control. Please
test with SBCL first. This branch contains my experimental syntax
control, binding a *shared-readtable* around compilation (itself the
*readtable* at the time ASDF is loaded), so that promiscuous systems
may keep
3- if I uncomment the lines:
;;(unless (or #+ecl (use-ecl-byte-compiler-p))
;; (setf *load-system-operation* 'load-bundle-op))
I get an error in test-logical-pathname,
with the .fasb apparently mapped to the wrong directory.
???! What is the real need for this one? You see me a bit
Thanks a lot, Anton!
The results are very encouraging: only 4 red things, that look fixable.
cl-quakeinfo is still doing plenty of ugly old-style things, package
promiscuity with cl-user, etc., and needs maintenance (come on,
disable-output-translations in the .asd file itself? Ugh!) I was so
Hi,
1- encodings...
The fix should be in the MKCL git repo master head now.
It works perfectly.
However, somehow ASDF upgrade is broken:
(require :asdf)
(ASDF asdf UIOP)
(asdf:load-system :asdf)
Debugger called in: #thread Initial active (4648) 0x7f7c4f74b700
01be2000.
#a
701 - 800 of 1393 matches
Mail list logo
