> You’re quoting me out of context. If deterministic by default had no
> cost associated with it, it would clearly be the desirable
> choice. But it has a cost associated with it, so this is less
> clear.
am i right to assume here that the costs we are talking about is
merely adding markers to th
> I prefer the defaults of the CL implementation of my choice not to
> be overridden by some tool whose primary purpose is something
> unrelated to those defaults. That’s all.
i fail to see how ASDF's primary purpose is unrelated to global state
that affects the outcome of a build process.
--
•
On 29 Mar 2014, at 20:07, Stelian Ionescu wrote:
> On Sat, 2014-03-29 at 19:59 +0100, Pascal Costanza wrote:
> [...]
> That's not how it works, unless you include a bit for *rdff* in the
> name of the fasl cache directory — and since the planning is done
> based on pathnames before t
On Sat, 2014-03-29 at 19:59 +0100, Pascal Costanza wrote:
[...]
> >>> That's not how it works, unless you include a bit for *rdff* in the
> >>> name of the fasl cache directory — and since the planning is done
> >>> based on pathnames before the compilation happens, that should still
> >>> be *rdff
On 29 Mar 2014, at 19:47, Faré wrote:
>>> (1) guaranteeing a value of *read-default-float-format*
>>> and other syntax variables when compiling a library.
>>> I still argue that (1) is essential for build determinism,
>>> and enabling users to change syntax at the REPL.
>>
>> Are you also consi
>> (1) guaranteeing a value of *read-default-float-format*
>> and other syntax variables when compiling a library.
>> I still argue that (1) is essential for build determinism,
>> and enabling users to change syntax at the REPL.
>
> Are you also considering the following use case?
>
> - Assume I’m
On 29 Mar 2014, at 18:07, Faré wrote:
>> : p-cos
>
>>> no upgrade, no breakage.
>>
>> If you can’t upgrade ASDF, you may also not be able to upgrade quicklisp. If
>> you can’t upgrade quicklisp, you may also not be able to get updates to
>> existing libraries. At least, it may be harder than
>: p-cos
>> no upgrade, no breakage.
>
> If you can’t upgrade ASDF, you may also not be able to upgrade quicklisp. If
> you can’t upgrade quicklisp, you may also not be able to get updates to
> existing libraries. At least, it may be harder than necessary (like in the
> pre-quicklisp, pre-asdf-
> We can provide new, improved functionality without breaking anything.
> And keep old systems working forever with new ASDF.
"forever" is a very strong word Anton. e.g. if CL doesn't fade into
the category of history in 10 years, meaning that a significant number
of people will still use it to d
On 28 Mar 2014, at 20:37, Attila Lendvai wrote:
>>> regarding the recent discussions i'm generally baffled why it is at
>
>>> all a question whether to make a build software deterministic or
>>> not. in my view if there's anything in the global state that has an
>>> effect on the building of a
29.03.2014, 02:32, "Faré" :
>
> Additionally, my ASDF syntax-control branch has a mechanism that
> allows systems to specify variables they want to bind around their
> system, so you could specify:
> (defsystem foo :variables ((*read-default-float-format* . (constantly
> double-float))) ...)
> wher
I think ASDF should not change the semantics and break existing system.
We can provide new, improved functionality without breaking anything.
And keep old systems working forever with new ASDF.
Lets fist consider and decide, how exactly the best
support for syntax customizations should work.
Wit
Hi all,
Would it be possible to have a special header in asdf files indicate that
the contained system(s) should be loaded using the new syntax mechanism?
Something like the "#lang" mechanism in Racket, file variables in Emacs,
etc.
Here's a fairly CL-friendly format. Read the first line i
> by now the time on spent discussing this would have easily been enough
> to fix all of them twice over, and to add a section to the top of the
> manual, with bold, that lists the global state that ASDF guarantees
> and isolates.
>
I've sent patches to all 16 libraries that depended on
*read-defau
On 28 Mar 2014, at 19:00, Robert Goldman wrote:
> I would be much happier to see this conversation direct itself towards a
> design for providing strict mode, rather than arguing about whether or
> not "strict mode" should be universally imposed. I will say it again:
> that will not happen.
Rob
>> and if this state can be set in a way that it leaks out and influences
>> builds later in time, then it's an ugly bug feasting on programmer
>> nerves and time.
>>
>
> This would be true only if "a software" was equivalent to "an ASDF
> system." That is not the case. I have seen many applicati
Attila Lendvai writes:
>>> regarding the recent discussions i'm generally baffled why it is at
>
>>> all a question whether to make a build software deterministic or
>>> not. in my view if there's anything in the global state that has an
>>> effect on the building of a software, anything, then it
>> regarding the recent discussions i'm generally baffled why it is at
>> all a question whether to make a build software deterministic or
>> not. in my view if there's anything in the global state that has an
>> effect on the building of a software, anything, then it's a bug.
>
> I think one ques
Attila Lendvai wrote:
>> I do have control: If femlisp or any other library makes a boneheaded
>> decision that breaks my software, I can stop using it.
>
>
> yes, resolving that is trivial -- once you have identified the
> problem.
>
> regarding the recent discussions i'm generally baffled why
>> regarding the recent discussions i'm generally baffled why it is at
>> all a question whether to make a build software deterministic or
>> not. in my view if there's anything in the global state that has an
>> effect on the building of a software, anything, then it's a bug.
>
> I think one quest
Attila Lendvai writes:
>> I do have control: If femlisp or any other library makes a boneheaded
>> decision that breaks my software, I can stop using it.
>
>
> yes, resolving that is trivial -- once you have identified the
> problem.
>
> regarding the recent discussions i'm generally baffled why
> I do have control: If femlisp or any other library makes a boneheaded
> decision that breaks my software, I can stop using it.
yes, resolving that is trivial -- once you have identified the
problem.
regarding the recent discussions i'm generally baffled why it is at
all a question whether to m
27.03.2014, 01:21, "Faré" :
> Can you re-run a full test with what I just pushed in branch syntax-control?
Fare, here are the results for the syntax-control, commit d32afa0c:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-40.html
Looks like several libraries rely on single-float.
Bes
Thanks a lot, Anton!
Well, here's a valid argument in favor of 'single-float as the
default: making 'double-float the default breaks 22 systems in
Quicklisp (a bit fewer when you consider that some systems only
depended on a broken one, but still), when making it 'single-float
only broke 4 of them
On Thu, Mar 27, 2014 at 2:00 PM, Anton Vodonosov wrote:
> Fare, if femlisp configures *read-default-float-format*
> why does it fail with your ASDF change? Do you restore standard
> CL syntax around every file compilation?
Yes I do, although I just committed a change to override
*read-default-floa
Fare, if femlisp configures *read-default-float-format*
why does it fail with your ASDF change? Do you restore standard
CL syntax around every file compilation?
Maybe isolating syntax changes at system boundary is more
convenient?
On Thu, Mar 27, 2014 at 1:20 PM, Zach Beane wrote:
>> femlisp side-effects *READ-DEFAULT-FLOAT-FORMAT*, which means that
>> every system compiled after it will be treated differently than if it
>> were compiled before it — and once again, whoever writes the system
>> does not and cannot control th
27.03.2014, 18:44, "Robert P. Goldman" :
>
> While I am very grateful to cl-test-grid, we need to be conscious of its
> limitations.
If anything, I personally do not insist on any changes to be done in ASDF.
But if developers want to test whether the libraries built OK on my system
previously rema
On Thu, Mar 27, 2014 at 1:06 PM, Faré wrote:
> On Thu, Mar 27, 2014 at 12:30 PM, Robert Goldman
> wrote:
> > Zach Beane wrote:
> >> Faré writes:
> >>
> >>> femlisp raises an interesting issue: it has (setq
> >>> *READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp
>
Gendl also sets *read-
The thing that concerns me about this proposed change is that the poor
programmer may look up the CLHS and see that the default value is specified to
be 'single-float.
If anything, I'd say that ASDF should force standards compliance, and use
'SINGLE-FLOAT.
But I'd rather have ASDF just leave t
Faré writes:
> On Thu, Mar 27, 2014 at 12:30 PM, Robert Goldman wrote:
>> Zach Beane wrote:
>>> Faré writes:
>>>
femlisp raises an interesting issue: it has (setq
*READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp, which is
cancelled by the with-standard-io-syntax that I in
On Thu, Mar 27, 2014 at 12:30 PM, Robert Goldman wrote:
> Zach Beane wrote:
>> Faré writes:
>>
>>> femlisp raises an interesting issue: it has (setq
>>> *READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp, which is
>>> cancelled by the with-standard-io-syntax that I introduce in my
>>> synta
Zach Beane wrote:
> Faré writes:
>
>> femlisp raises an interesting issue: it has (setq
>> *READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp, which is
>> cancelled by the with-standard-io-syntax that I introduce in my
>> syntax-control branch. I just pushed a change in said branch to make
>
Faré writes:
> femlisp raises an interesting issue: it has (setq
> *READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp, which is
> cancelled by the with-standard-io-syntax that I introduce in my
> syntax-control branch. I just pushed a change in said branch to make
> the 'double-float the de
Faré wrote:
> The results are very encouraging: only 4 red things, that look fixable.
At the risk of being a party pooper, I don't think that these results,
while encouraging, are measuring what needs to be measured.
What needs to be measured is the extent to which this change breaks
systems that
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
pis
Hi Fare,
I didn't really understand how exactly the changes work, but here is the result:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-39.html
Best regards,
- Anton
25.03.2014, 21:54, "Faré" :
> Dear Anton,
>
> the new thing to test is the HEAD of branch syntax-control. Please
> te
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 modify
On Tue, Mar 25, 2014 at 12:16 AM, Anton Vodonosov 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 branch (commit
On Tue, Mar 25, 2014 at 12:16 AM, Anton Vodonosov 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 branch (commit
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 branch (commit 2c1107)?
16.03.2014, 09:17, "Faré" :
> Dear Anton,
>
> can you do
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* (copy-read
As a personal request, let's table this discussion for now.
This issue is too complex, and the related proposals have too many
ramifications to push it into the impending release.
I appreciate your enthusiasm for the discussion, and I apologize for
trying to shut you down.
Unfortunately, right n
> That's why, for example, we have systems that bleed readtable across
> their boundaries: the systems really aren't stand alone entities, but
> limitations on ASDF expressiveness, and the desire to get more
> modularity than the (necessarily in-line) :MODULE will permit, causes a
> proliferation o
>> Agreed, and until the dust settles, "strict mode" cannot be the default.
>> I'd argue it should become the default eventually (i.e. next year).
>>
>
> I doubt that's even feasible, since the strict mode will have to cross
> systems. It will be easier to have systems say "I know I behave
> accor
Faré wrote:
> Unhappily, strict mode is a global flag: the question is "which
> readtable is this system going to be read with?". The only reasonable
> answer is: the readtable it was meant to be read with, which the
> author knows, and should be the standard readtable by default, unless
> explicit
Faré wrote:
>> > 2. The proposed change should be modified to operate only in a "strict
>> > mode", allowing existing legal CL code to continue to work.
>> >
> Agreed, and until the dust settles, "strict mode" cannot be the default.
> I'd argue it should become the default eventually (i.e. next ye
On Sun, Mar 16, 2014 at 11:18 AM, Robert P. Goldman 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 either too vague
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 either too vague
"Make the CL syntax predictable" or too specific -- very particular
p
Faré wrote:
> The clean thing to do would be to use named-readtables and/or
> cl-syntax, and have each file evaluate (in-readtable :foo) or have a
> perform :around method or around-compile hook that does it for you.
>
> We could also support your doing (in-readtable :foo) only once for the
> enti
> The clean thing to do would be to use named-readtables and/or
> cl-syntax, and have each file evaluate (in-readtable :foo) or have a
> perform :around method or around-compile hook that does it for you.
[...]
> Without ASDF, there's no way the libraries will be safe by default.
well, there is,
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 Sat, Mar 15, 2014 at 4:52 PM, Robert P. Goldman 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 modules of t
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 modules of this distributed system.
* For each module, there is an ASDF system, wh
On Sat, Mar 15, 2014 at 9:08 AM, Zach Beane wrote:
> Faré 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_.Ubiquity%29
>
> So y
Faré 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_.Ubiquity%29
So you want to make a change rapidly to suit the deadlines of a
con
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 gl
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 behavior.
What your
>>: 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 readtab
Faré wrote:
> On Fri, Mar 14, 2014 at 6:10 PM, Robert Goldman 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
On Fri, Mar 14, 2014 at 6:10 PM, Robert Goldman 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 POIU or XCVB r
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 POIU or XCVB really veers
away from vanilla CL usage.
Vanilla CL usage encourag
Faré wrote:
> Robert, what do you think? Should we "just" copy-readtable and
> copy-pprint-dispatch around each action?
> Or should we try to share the tables for all files in a system?
> Should we try to have defsystem save the values of *readtable* and
> *print-pprint-dispatch*,
> while load-asd
On Fri, Mar 14, 2014 at 4:01 PM, Anton Vodonosov 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 expensive? On
14.03.2014, 23:47, "Faré" :
> 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 expensive? On CCL it takes 22 microseconds per readt
On Fri, Mar 14, 2014 at 12:24 PM, Anton Vodonosov wrote:
> 14.03.2014, 20:20, "Anton Vodonosov" :
>> As systems depend on each other, a failing system breaks other systems.
>>
>> To get sense of the situation the following report may help:
>> http://common-lisp.net/project/cl-test-grid/asdf/asdf-l
14.03.2014, 20:02, "Anton Vodonosov" :
> Here is the report for the syntax patch:
> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-38.html
As systems depend on each other, a failing system breaks other systems.
To get sense of the situation the following report may help:
http://common
14.03.2014, 20:20, "Anton Vodonosov" :
> As systems depend on each other, a failing system breaks other systems.
>
> To get sense of the situation the following report may help:
> http://common-lisp.net/project/cl-test-grid/asdf/asdf-load-failures-3.1.0.94.synt-patch.html
> It includes only syste
Here is the report for the syntax patch:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-38.html
On Thu, Mar 13, 2014 at 10:07 PM, Anton Vodonosov 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 problem
> - it i
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 problem
- it includes in its source code libraries like babel, incompatible
with bab
OK. Tests for 3.1.0.94 are started.
Best regards,
- Anton
12.03.2014, 05:48, "Faré" :
> 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?
>
>
72 matches
Mail list logo
