On 30 May 2018, at 17:28, Stelian Ionescu wrote:
I used to use it, then it broke months ago on my local setup so I just
disabled it.
Two questions:
1. I'm curious about why you used it. Anything you could share would be
helpful.
2. Was the breakage due to the change in the compiler intern
I used to use it, then it broke months ago on my local setup so I just
disabled it.
>
> AFAICT, it is disabled by default, and it is not documented in the
> ASDF manual.> So is this code even live, except for in the test scripts?
> It was pretty painful to get this to work because it relies on
>
AFAICT, it is disabled by default, and it is not documented in the ASDF
manual.
So is this code even live, except for in the test scripts?
It was pretty painful to get this to work because it relies on
unexported (and hence unstable) SBCL internals.
My *guess* is that this was originally don
OK, I have pushed a better solution to gitlab on cl.net, as merge
request 95.
The history of this branch is a little messy, so I will squash-merge it
later. But I would definitely appreciate other eyes on.
I had hoped to localize the fix, but it was too hard for me -- getting
it right invol
AFAICT, `UNREIFY-WARNINGS` only `APPLY`s the SBCL constructor to stashed
property list. So it's only the `REIFY` function that needs fixing.
I'm having a lot of difficulty figuring out exactly how to do the
conditional compilation, though, because of ticklish issues about when,
exactly code i
Also, if you fix reify-warnings, you may have to fix unreify-warnings with it.
For a test, try to (uiop:enable-deferred-warnings-check) before you
build software.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Passive hope is wishful thinking, a poison of the mind.
Whoops. Looks like this doesn't work on older SBCLs. I'll fix that
now.
R
On 30 May 2018, at 15:08, Robert Goldman wrote:
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are ge
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are getting in there and rooting
around in SBCL internals in ways that seem almost guaranteed to break
again later. But for now, I th
On Wed, May 30, 2018 at 12:53 PM Eric Timmons wrote:
> Somewhat related, I was curious why ASDF doesn't use Gitlab CI to
> automatically run tests. It probably wouldn't have helped in this
> particular case since the root cause was a change outside ASDF, but
> it's still nice for things like merge
On Wed, May 30, 2018 at 10:47 AM, Robert Goldman wrote:
> Does anyone have any suggestions about testing against multiple versions of
> SBCL? This brings to a head a problem that has been pending for a long time
> -- how should I be keeping around old versions of lisp implementations so
> that I c
On 29 May 2018, at 22:51, Eric Timmons wrote:
Looks like SBCL 1.4.7 changed the slots of
sb-c::compiler-error-context (in particular enclosing-source ->
%enclosing-source, source -> %source, and original-source was
removed). As a result, deferred warnings are broken. Attached is the
output of `.
Oops. Can you provide a patch? If possible one that uses #. to test what
symbols are present and does the right thing?
There are a few examples of #+sbcl #.( in filesystem.lisp and image.lisp.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
Government — If you think
12 matches
Mail list logo
