Dear SBCL hackers,
I have finally released ASDF 2, officially starting with release 2.000.
http://common-lisp.net/project/asdf/
ASDF 2 is an evolution of ASDF that tries to be backwards compatible
with previous releases and their many extensions,
while at the same time improving the user experience in many important ways.
I have worked hard towards reaching the current state,
which I believe is now suitable for release
and for inclusion in all Common Lisp implementations.
I thank all those who helped develop and test this release,
including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll,
and many more.
We welcome bug reports on our launchpad site:
https://launchpad.net/asdf
I'm using ASDF 2 at ITA. Recent versions are already included in
ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty
of packages with it. While it's far from my ideal of perfection, and
admittedly only a relatively small limited of previous code,
I believe it's enough of an advance over the previous generation of ASDF
that I'd like to get it out to the world.
The code has been extensively cleaned up
while preserving previous semantics everywhere that it was well-defined.
Our testing has revealed no regressions from ASDF 1.
What has changed since ASDF 1 is documented at the following page:
http://common-lisp.net/project/asdf/asdf/FAQ.html
Improvements include:
* portable naming of files wrt directory, type, host/device, etc.
* a builtin user-configurable output translation mechanism,
superseding asdf-binary-locations and previous hacks in
common-lisp-controller and cl-launch.
* a user-configurable source registry system for finding systems
(the old *central-registry* is still available).
* improved portability to many implementations.
* improved support for Windows.
* many bug fixes
* better documentation
* the test suite, while still largely incomplete, covers more cases
and is more robust across implementations.
* substantial performance improvements when processing large systems with
thousands of components.
* API improvements: load-system, system-relative-pathname, etc.
* a sensible versioning system for ASDF 2 itself.
* ASDF can be now be upgraded in a running lisp image. Using this in-place
upgrade, ASDF releases can be decoupled from implementation releases.
* better support for various extensions used by ECL and ABCL,
and also by POIU, ASDF-DEPENDENCY-GROVEL.
Pitfalls include:
* Output translations is enabled by default. This may surprise some users,
most of them in pleasant way (we hope), a few of them in an unpleasant way.
It is trivial to disable output translations. Simply put
(ASDF:DISABLE-OUTPUT-TRANSLATIONS)
in a Lisp startup file.
* Some systems in the large have been known not to play well with
asdf output translations. They were easy to fix.
The most likely issue is to have chaining of operations
(e.g., a preprocessing before a load) where the INPUT-FILES of one operation
are related to the OUTPUT-FILES of another.
In this case many issues can be avoided by simply making
the OUTPUT-FILES primary, and having later operations' INPUT-FILES
be defined in terms of the OUTPUT-FILES of other operations
instead of directly defining the INPUT-FILES.
It is also easy to disable output translations or override its configuration.
* ASDF 2 output translations do not work with ASDF-Binary-Locations.
They replace A-B-L, and include a compatibility mode to emulate your previous
A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY.
But you shouldn't load ABL on top of ASDF 2.
* A notable performance bug on SBCL (and possibly other implementations, too):
the recursive search of configured paths in your source-registry with
(DIRECTORY "/configured/path/**/*.asd")
can waste a few seconds when initially searching for asd files
(depending on your configuration).
If it is essential for you to avoid this pause, you should override
the default source-registry and only use non-recursive :DIRECTORY
options (or shallow trees). Or just keep the default directory
hierarchies being searched empty.
* Windows support may have been insufficiently well tested.
As to how to best include ASDF in your implementation,
here is an excerpt from the FAQ section of our manual:
12.3.2 "I'm a Common Lisp implementation vendor.
When and how should I upgrade ASDF?"
Starting with current candidate releases of ASDF 2,
it should always be a good time to upgrade to a recent version of ASDF.
You may consult with the maintainer
for which specific version they recommend,
but the latest RELEASE should be correct.
We trust you to thoroughly test it with your implementation
before you release it.
If there are any issues with the current release,
it's a bug that you should report upstream and that we will fix ASAP.
In order to report bugs, please use the launchpad bug tracker.
Information about launchpad is contained in the manual.
As to how to include ASDF, we recommend the following:
* If ASDF isn't installed yet, then (require :asdf) should load the
version of ASDF that is bundled with your system.
You may have it load some other version configured by the user,
if you allow such configuration.
* If your system provides a mechanism to hook into CL:REQUIRE,
then it would be nice to add ASDF to this hook the same way
that SBCL, ECL, CMUCL, CCL and ABCL do.
* You may, like SBCL, have ASDF be implicitly used to require systems
that are bundled with your Lisp distribution.
If you do have a few magic systems that come with your implementation
in a precompiled way such that one should only use the binary version
that goes with your distribution, like SBCL does,
then you should add them in the beginning of wrapping-source-registry.
Please consult with the ASDF maintainers about that.
* If you have magic systems as above, then we explicitly ask you
to NOT distribute asdf.asd as part of those magic systems.
You should still include the file asdf.lisp in your source distribution
and precompile it in your binary distribution, but
asdf.asd if included at all, should be secluded from the magic systems,
in a separate file hierarchy, or you may otherwise rename the system
and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd.
If you make asdf.asd a magic system, then users will no longer be able to
upgrade ASDF using ASDF itself. It is helpful to be able to do this
in order for users to be able to use an ASDF version of their own choosing
that they maintain independently from your Lisp distribution.
* If you do not have any such magic systems, or have other non-magic
systems that you want to bundle with your implementation, then you may
add them to the default-source-registry, and you are welcome to
include asdf.asd amongst them.
* Please send us upstream any patches you make to ASDF itself, so we
can merge them back in for the benefit of your users when they upgrade
to the upstream version.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Reisner's Rule of Conceptual Inertia:
If you think big enough, you'll never have to do it.

On Sat, 29 May 2010, Vasily Vlasyuk wrote:
> Question to the community - is it feasible to port SBCL to a mobile platform, let's say Android? Does it make any sense at
> all?
If Android is your target, then one of the JVM-based implementations might
yield results sooner.
http://common-lisp.net/project/armedbear/http://www.clforjava.org/
ECL is another possibility; there have been ports to the iPhone.
- Daniel

On 30 May 2010 17:17, Christophe Rhodes <csr21@...> wrote:
> Faré <fahree@...> writes:
>
>> Would ASDF2 count as a contrib enhancement? Is it OK to commit it
>> before 1.0.39? Right after 1.0.39?
>
> (Not before 1.0.39, but that's obvious now :-) In what ways is asdf2
> backwards-incompatible with asdf as currently shipped? Are there still
> hooks or similar for sbcl to be able to build and ship loadable contribs
> without the user being able to shoot themselves in the foot too easily?
>
> (For example, one usual problem is/was an asdf-binary-locations
> configuration which wanted to change the output locations of sbcl
> contrib fasls).
>
Yes, it is too late for 1.0.39 indeed. I intend to rename 1.728 to
2.000 tomorrow and hope it can make it to 1.0.39.small_integer.
ASDF 2 *should* be fully backwards compatible with ASDF 1 in all the
features actually used by .asd files in the wild, and so far there
haven't been any known incompatibility that we haven't addressed. But
I admit I haven't tried *all* said files, just a lot of them. Others
have tried a whole lot of them, automatically, and haven't submitted a
bug report in a month - but I admit I didn't dig much into that. ABCL,
CCL, CMUCL and ECL have included recentish versions of ASDF in the
master branches of their source trees, without unaddressed complaint
so far.
The SBCL REQUIRE hook is present, and now also works on ECL, CCL, ABCL.
Where ASDF 2 is incompatible is that:
* it defines behavior in cases that used to be non-portable (notably
allowing strings as portable hierarchical pathnames, and handling
pathname merging in a portable way, too).
* it ships with asdsf output translations included and enabled by
defaults (the successor to asdf binary locations) -- however, it
arranges to leave things under SBCL_HOME invariant no matter what.
Some hack may or may not be necessary while compiling the contribs
themselves: (exporting SBCL_HOME=... or
ASDF_OUTPUT_TRANSLATION="(:output-translations :disable-cache
:inherit-configuration)"
* by default, the *central-registry* (still supported) is empty,
predefined search paths being supplied as part of the default and
wrapping values for the source-registry. This shouldn't affect anyone.
There is, however, one current slight performance regression on SBCL
in certain cases: the default value of the source-registry in ASDF 2
includes recursing through /usr/share/common-lisp/source which if you
have a lot of files there and are using SBCL can take a few
noticeable seconds when ASDF first scans these directories. I think
it's a SBCL performance bug wrt DIRECTORY doing too much
pathname/truename normalization and namestringation, especially since
other Lisp implementations seem to be much less slow by an order of
magnitude at least. But I still think it's OK, since:
* things are fast if the directories are empty.
* you can override the default source-registry and remove those
directories if you want to skip this scanning.
* a few seconds at startup is not THAT annoying, especially when
compilation takes minutes.
* I'd rather the performance bug be fixed in SBCL than in ASDF.
Note: SBCL is my main testing platform for ASDF. I also run
regressions on CCL, CLISP, ECL, Allegro, before every release.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The worst thing about totalitarian regimes is not that they make people poor,
miserable and unfree — it's that they corrupt people's souls, and turning
everyone into a double-thinking, double-speaking liar for the sake of survival.

Robert Goldman <rpgoldman@...> writes:
> I'm enclosing a patch file that adds docstrings to
> sb-ext:disable-debugger and sb-ext:enable-debugger.
>
> It also adds these functions (and some other information about the
> debugger) to the function and concept indices.
>
> This is all intended to make it easier to find information about
> controlling the debugger.
Thanks. I've merged something like this into a branch for improving the
manual that I hope to commit to CVS sometime soon (this month, rather
than this year :-)
> The only oddity I can see in the patch file is that when I ran the emacs
> texinfo mode command to update every node, it added previous and next
> links to nodes in the debugging texinfo file that didn't have them. As
> far as I can tell, those links are correctly computed, so I left them in.
>
> I'm not entirely sure of the patch submission procedure. Please let me
> know if this one is not prepared properly, and I will try to fix it.
Well, ideally not having a whole bunch of noise in the patch would have
been good -- I know emacs put them there, and I know that they were
"right", but they still made it hard to see what you were actually
adding.
Other than that, the patch was fine; I played a bit with git attributes
yesterday, though, and decided that the following was cute:
in ~/.gitattributes or .git/info/attributes
*.lisp diff=lisp
*.texinfo diff=texinfo
in ~/.gitconfig or .git/config
[diff "lisp"]
xfuncname="^(\\(def.*)$"
[diff "texinfo"]
xfuncname="^(@(sub)*section.*)$"
I am but a git novice; I'm sure that there are other people on this list
with extensive customizations for patch prettiness.
Cheers,
Christophe

Faré <fahree@...> writes:
> Would ASDF2 count as a contrib enhancement? Is it OK to commit it
> before 1.0.39? Right after 1.0.39?
(Not before 1.0.39, but that's obvious now :-) In what ways is asdf2
backwards-incompatible with asdf as currently shipped? Are there still
hooks or similar for sbcl to be able to build and ship loadable contribs
without the user being able to shoot themselves in the foot too easily?
(For example, one usual problem is/was an asdf-binary-locations
configuration which wanted to change the output locations of sbcl
contrib fasls).
Cheers,
Christophe

Hello,
This is a question to SBCL maintainers. I probably had to ask it before
nominating my patches for release in Launchpad, but anyway it is better to
ask later than to ask never:)
The question is: what should I do after I have provided the patch and
counted all notes about the problems with the patch? Should I mark the issue
'In progress', assign it to me and nominate it for release? Or I should stop
after the final patch is provided, and do not touch the ticket anymore? Do
we have any rules about this?
I see that other people never nominate a fix for the release, so maybe I
went the wrong way here.
Also, what is the issues confirmation policy? Should they be confirmed by
maintainers only, or other registered in Launchpad people also may confirm
an issue?
I am asking this to avoid confusions during Launchpad usage. It would be
good to have the 'official' rules about SBCL Launchpad site stated somewhere
and to obey them.
Regards,
Roman

The patch seems to be reasonable, especially when you have the working test
case.
Your question is not answered, because (at least for me) it is unclear what
are you trying to convert and why? Since you have missed the conversion
steps entirely, it is hard to say what is going on.
For Lisp/C strings conversion see string-to-c-string/c-string-to-string in
src/code/target-c-call.lisp, and their users. Also SBCL manual has the clear
description of alien types conversion, including the automatic cases. A
'lisp name' conversion to string is just (string 'name-to-convert).
You may also put your bug/solution to Launchpad - it will be definitely
saved for some future release in this case.
Regards,
Roman
2010/5/29 Jerry James <loganjerry@...>
> On Wed, May 26, 2010 at 8:14 PM, Jerry James <loganjerry@...> wrote:
> > Ping (on both the bug and the above question).
>
> Is anyone receiving my email, or am I just talking to a bit bucket
> somewhere?
> --
> Jerry James
> http://www.jamezone.org/
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>

On Wed, May 26, 2010 at 8:14 PM, Jerry James <loganjerry@...> wrote:
> Ping (on both the bug and the above question).
Is anyone receiving my email, or am I just talking to a bit bucket somewhere?
--
Jerry James
http://www.jamezone.org/

Stas Boukarev wrote:
>Vasily Vlasyuk <vasily.vlasyuk@...> writes:
>
>> Hi All,
>>
>> Question to the community - is it feasible to port SBCL to a mobile platform,
>> let's say Android? Does it make any sense at all?
>>
>> If yes, then, assuming this will be managed as a dedicated project (and not
>> based on best-effort-approach), how much time/money/people resources would it
>> cost?
>
>I can only point to an existing effort, albeit not active at the moment,
>of porting SBCL to ARM by Alastair Bridgewater:
>http://www.lisphacker.com/projects/sbcl-arm/port-log.txt
Alastair made a change to his GIT tree this week, maybe he could use
some help though.
There are also MIPS based devices such as the NanoNote that could be
supported.
Robert Swindells

Vasily Vlasyuk <vasily.vlasyuk@...> writes:
> Hi All,
>
> Question to the community - is it feasible to port SBCL to a mobile platform,
> let's say Android? Does it make any sense at all?
>
> If yes, then, assuming this will be managed as a dedicated project (and not
> based on best-effort-approach), how much time/money/people resources would it
> cost?
I can only point to an existing effort, albeit not active at the moment,
of porting SBCL to ARM by Alastair Bridgewater:
http://www.lisphacker.com/projects/sbcl-arm/port-log.txt
--
With Best Regards, Stas.

Hi All,
Question to the community - is it feasible to port SBCL to a mobile
platform, let's say Android? Does it make any sense at all?
If yes, then, assuming this will be managed as a dedicated project (and not
based on best-effort-approach), how much time/money/people resources would
it cost?
Thanks in advance,
Vasily

I also think that the performance impact will be small. So, I will rework
the macro as per Nathan's suggestion. But should maintainers go one step
ahead and clean the entire SBCL sources from 'high-security' feature
expression at all? Or it is useful in some situations?
Regards,
Roman
2010/5/29 James Y Knight <foom@...>
> On May 28, 2010, at 4:52 PM, Nathan Froyd wrote:
> On Fri, May 28, 2010 at 3:44 PM, Roman Marynchak
>
>> <roman.marynchak@...> wrote:
>>
>>> I have seen this feature expression in several source files, for example
>>> in
>>> /code/sysmacs.lisp:
>>>
>>> It seems that it is some old CMUCL feature expression. Is it okay to get
>>> rid
>>> of it, at least in that macro? I need the stream type check to be made by
>>> default in order to fix this issue:
>>>
>>> https://bugs.launchpad.net/sbcl/+bug/586940
>>>
>>> The first step is to pass t as a second macro argument, and the second is
>>> to
>>> remove or enable 'high-security', as one may guess from PRINT definition:
>>>
>>
>> The second macro argument seems to be totally unused, so it's probably
>> best to just delete the argument from the macro and make the check the
>> default.
>>
>
> I suppose it was omitted because of the performance cost? Although,
> checking the type of an argument can't *really* have significant performance
> cost in an output function I wouldn't think.
>
> James
>
>

On May 28, 2010, at 4:52 PM, Nathan Froyd wrote:
On Fri, May 28, 2010 at 3:44 PM, Roman Marynchak
> <roman.marynchak@...> wrote:
>> I have seen this feature expression in several source files, for
>> example in
>> /code/sysmacs.lisp:
>>
>> It seems that it is some old CMUCL feature expression. Is it okay
>> to get rid
>> of it, at least in that macro? I need the stream type check to be
>> made by
>> default in order to fix this issue:
>>
>> https://bugs.launchpad.net/sbcl/+bug/586940
>>
>> The first step is to pass t as a second macro argument, and the
>> second is to
>> remove or enable 'high-security', as one may guess from PRINT
>> definition:
>
> The second macro argument seems to be totally unused, so it's probably
> best to just delete the argument from the macro and make the check the
> default.
I suppose it was omitted because of the performance cost? Although,
checking the type of an argument can't *really* have significant
performance cost in an output function I wouldn't think.
James

On Fri, May 28, 2010 at 3:44 PM, Roman Marynchak
<roman.marynchak@...> wrote:
> I have seen this feature expression in several source files, for example in
> /code/sysmacs.lisp:
>
> It seems that it is some old CMUCL feature expression. Is it okay to get rid
> of it, at least in that macro? I need the stream type check to be made by
> default in order to fix this issue:
>
> https://bugs.launchpad.net/sbcl/+bug/586940
>
> The first step is to pass t as a second macro argument, and the second is to
> remove or enable 'high-security', as one may guess from PRINT definition:
The second macro argument seems to be totally unused, so it's probably
best to just delete the argument from the macro and make the check the
default.
-Nathan

Hello,
I have seen this feature expression in several source files, for example in
/code/sysmacs.lisp:
(defmacro out-synonym-of (stream &optional check-type)
(let ((svar (gensym)))
`(let ((,svar ,stream))
(cond ((null ,svar) *standard-output*)
((eq ,svar t) *terminal-io*)
(t ,@(when check-type `((check-type ,svar ,check-type)))
#!+high-security
(unless (output-stream-p ,svar)
(error 'simple-type-error
:datum ,svar
:expected-type '(satisfies output-stream-p)
:format-control "~S isn't an output stream."
:format-arguments (list ,svar)))
,svar)))))
It seems that it is some old CMUCL feature expression. Is it okay to get rid
of it, at least in that macro? I need the stream type check to be made by
default in order to fix this issue:
https://bugs.launchpad.net/sbcl/+bug/586940
The first step is to pass t as a second macro argument, and the second is to
remove or enable 'high-security', as one may guess from PRINT definition:
(defun print (object &optional stream)
#!+sb-doc
"Output a newline, the mostly READable printed representation of OBJECT,
and
space to the specified STREAM."
(let ((stream (out-synonym-of stream)))
(terpri stream)
(prin1 object stream)
(write-char #\space stream)
object))
Regards,
Roman

I'm enclosing a patch file that adds docstrings to
sb-ext:disable-debugger and sb-ext:enable-debugger.
It also adds these functions (and some other information about the
debugger) to the function and concept indices.
This is all intended to make it easier to find information about
controlling the debugger.
The only oddity I can see in the patch file is that when I ran the emacs
texinfo mode command to update every node, it added previous and next
links to nodes in the debugging texinfo file that didn't have them. As
far as I can tell, those links are correctly computed, so I left them in.
I'm not entirely sure of the patch submission procedure. Please let me
know if this one is not prepared properly, and I will try to fix it.
Cheers,
r

On Mon, May 24, 2010 at 8:27 PM, Jerry James <loganjerry@...> wrote:
> If you need a test case, here is one that demonstrates the problem:
[snip]
> Incidentally, is there some other way of converting the names to Lisp
> strings than calling an internal symbol in the sb-alien package?
Ping (on both the bug and the above question).
--
Jerry James
http://www.jamezone.org/

I've been working on this problem a while but i'm still pretty green
when it comes to the compiler.
Is it possible to reset the source location after the fact? Something like
(setf (fdefinition 'foo) #'bar)
(set-source-location #'bar (sb-c:source-location))
With this I could fix up the defun/cc macro to do the right thing.
On 5/22/10, William Halliburton <whalliburton@...> wrote:
> Hello all,
>
> I am using the cl-cont package and
>
> (defun/cc foo ())
>
> expands into something like
>
> (PROGN (SETF (FDEFINITION 'FOO) (MAKE-FUNCALLABLE ...))))
>
> Is there a way I can get
>
> (sb-introspect:find-definition-sources-by-name 'foo :function)
>
> to return the location of the DEFUN/CC and not the location of
> MAKE-FUNCALLABLE?
>
> Thanks much,
> Will
>

Christophe Rhodes wrote on Mon, May 24, 2010 at 09:27:11AM +0100:
> Hi,
>
> Now that most of the PPC excitement has made it, and now that I feel
> approximately competent to operate delicate machinery once more, could
> we please treat the CVS tree frozen to innovative new features, while
> still permeable to contrib enhancements and bug fixes, with the aim to
> release sbcl-1.0.39 at the weekend?
Tree looks happy from my end.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@...> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/

Hi Josh,
I saw your (sadly, unanswered) message on the OpenBSD ppc list. I had a few minutes to poke at it today and I wonder if this doucment doesn't help.
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600741775/$file/prg.pdf
Down in section 1.4 (FPSCR) they say that in general the status bits are sticky and you have to clear them. I'll poke around with this and see if this helps. I wonder if your test just didn't start looping constantly delivering SIGFPEs over and over again since the bits weren't cleared.
I do have this on my list of things to do, but, I've not gotten there yet.
cheers
bruce
----- Message d'origine -----
De: Josh Elsasser <josh@...>
Date: Sat, 22 May 2010 00:42:40 -0700
Sujet: Re: [Sbcl-devel] Thanks very much for all the PPC patches, plus OpenBSD
À: Alastair Bridgewater <alastair.bridgewater@...>
Cc: "Bruce O'Neel" <ecl@...>, sbcl-devel@...
On Fri, May 21, 2010 at 07:29:58PM -0400, Alastair Bridgewater wrote:
> Hello,
>
> I've just put together the version of the patch that I'm planning to commit.
> Unfortunately, I can't seem to access repo.or.cz right now, so I put the
> patch at . I made
> a few tweaks here and there, but nothing too egregious.
Thanks, looks fine to me aside from foreign.test.sh
> Barring being told "no, no, it doesn't work now" or code-freeze, I intend to
> commit this at some point on Sunday, the 23rd. If there's something else
> I should be doing beyond adding a NEWS snippet, now would be the time
> for another SBCL maintainer to mention it.
>
> On Fri, May 21, 2010 at 10:16 AM, Josh Elsasser wrote:
> > The failing NaN tests at least appear to be to be a problem with
> > OpenBSD and need to be fixed there instead of in SBCL. I had been
> > working on a fix but was sidetracked, I'll see if I can get it working
> > soon.
>
> I looked at these briefly earlier today, and it looks like the traps are being
> disabled for some strange reason on my linux system, which worries me,
> but indicates to me that it might be more an SBCL problem than a Linux
> problem. Don't let my conclusions stop you from approaching it as an
> OpenBSD problem, though.
There certainly is an OpenBSD problem, but of course that doesn't mean
there isn't also an SBCL problem.
> > I suppose as far as changes to SBCL are concerned, that patch is
> > pretty good. The XXX comment in src/compiler/ppc/parms.lisp can be
> > removed, if it ever becomes an issue then I or someone else can fix it
> > then.
>
> I rewrote it as a FIXME comment with a bit of the background explanation.
Works for me, it's not like anyone will ever run into it unless the
default macppc MAXDSIZ changes.
> > Something better should probably be done about that
> > handler-case-bogus-compiler-note test in dynamic-extent.impure.lisp
> > which hangs SBCL, unless the recent test infrastructure changes
> > already took care of it.
>
> They did. The problem was that a COMPILER-NOTE isn't an ERROR, so
> it slipped through the usual net.
>
> What I didn't apply was the -fPIC thing for foreign.test.sh, as it doesn't
> seem to be necessary for PPC/Linux. I'd be happier with a special case
> similar to what is done for Darwin.
Unpatched, foreign.test.sh fails quite spectacularly on
OpenBSD/macppc. When you say special case, do you mean something like
this:
http://www.elsasser.org/misc/jre-sbcl-ppc-foreign-test.diff
For the record, here are my test results with sbcl-openbsd-ppc.diff
and jre-sbcl-ppc-foreign-test.diff applied:
Finished running tests.
Status:
Unexpected success: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372)
Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
Failure: float.pure.lisp / NAN-COMPARISONS
Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346)
Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
Expected failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
Expected failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
Expected failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES)
Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE
Expected failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES
Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK
Expected failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG
Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
Failure: timer.impure.lisp / (TIMER STRESS)
Failure: timer.impure.lisp / (WITH-TIMEOUT TIMEOUT)
test failed, expected 104 return code, got 1

Would ASDF2 count as a contrib enhancement? Is it OK to commit it
before 1.0.39? Right after 1.0.39?
It would be nice if SBCL 1.0.39 came with ASDF2. If that helps, I'm
even tempted to rename ASDF 1.728 as ASDF 2.000. I haven't had any
negative feedback about ASDF for some time (and it's all been
addressed). Using it at ITA to compile a bunch of code.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
A tautology is a thing which is tautological.
On 24 May 2010 04:27, Christophe Rhodes <csr21@...> wrote:
> Hi,
>
> Now that most of the PPC excitement has made it, and now that I feel
> approximately competent to operate delicate machinery once more, could
> we please treat the CVS tree frozen to innovative new features, while
> still permeable to contrib enhancements and bug fixes, with the aim to
> release sbcl-1.0.39 at the weekend?
>
> Thanks,
>
> Christophe

Hi,
Now that most of the PPC excitement has made it, and now that I feel
approximately competent to operate delicate machinery once more, could
we please treat the CVS tree frozen to innovative new features, while
still permeable to contrib enhancements and bug fixes, with the aim to
release sbcl-1.0.39 at the weekend?
Thanks,
Christophe

On Fri, May 21, 2010 at 10:16 AM, Josh Elsasser <josh@...> wrote:
> On Fri, May 21, 2010 at 09:51:39AM +0200, Bruce O'Neel wrote:
>> I've still not gotten back to the float test oddities yet.
>
> The failing NaN tests at least appear to be to be a problem with
> OpenBSD and need to be fixed there instead of in SBCL. I had been
> working on a fix but was sidetracked, I'll see if I can get it working
> soon.
Okay, so here's the current status on all this: It all works on Linux.
The only bit that
doesn't work on OpenBSD is SIGFPE. SIGFPE is possibly completely broken on
OpenBSD. As of 1.0.38.12, there should be one expected float.pure.lisp failure.
Josh, I found your patch for fixing up SIGFPE, and I have an
observation for you and a
question. My observation is that the signal delivery mechanism does
not appear to my
(admittedly hasty) reading to consume any stack or other process
resources until the
stub in sys/arch/macppc/macppc/locore.S (sigcode) has executed at least one
instruction. My question is, did you remember to clear the accrued
exception fields in
the fpscr before returning to userland? If they (or the trap enables)
aren't cleared, then
you can obtain an infinite loop that way.
Other than that, if things still work as of 1.0.38.12, I think we're done.
--Alastair Bridgewater