Hi,
I've tested this on my OpenBSD/PPC system and three different
Linux PPC systems running 2 different Distros and it looks good.
Thanks very much!
cheers
bruce
On Thu, May 06, 2010 at 11:51:53PM -0400, Alastair Bridgewater wrote:
> Hello,
>
> [re-ccing sbcl-devel, because this really should be discussed there.]
>
> On Thu, May 6, 2010 at 10:32 PM, Josh Elsasser <josh@...> wrote:
> > I cleaned up and did some quick testing of my old PPC branch, it
> > doesn't look hugely different than your changes. The most significant
> > change would probably be the address space locations. I don't remember
> > the exact reason I used the addresses I did, but I remember being
> > concerned that someone might build a kernel with MAXDSIZ bumped up to
> > 1GB like it is on i386.
> >
> > Here's a diff of my changes against 1.0.38.5:
> >
> > http://www.elsasser.org/misc/sbcl-obsd-ppc.diff
>
> This, I mostly like. Two questions, though. First, would you mind
> resolving the comment "XXX JRE test this with a 1GB MAXDSIZ kernel"
> for the heap space parameters? Even just re-wording it to explain what
> the concern is would be an improvement over the rather cryptic note
> there. Second, can you explain the logic behind the test/foreign.test.sh
> change?
>
> Beyond that, I'd be inclined to commit this if you and Bruce can agree
> that it works.
>
> > There are several dynamic-extend test failures which I don't remember
> > from before, I had to disable one of them to avoid dropping into the
> > debugger during the test run. The failing timer tests are normal for
> > OpenBSD.
>
> I can confirm that everything but the timer and float errors are normal for
> PPC/linux. I'm not sure about the float tests, as I haven't looked deeply
> enough at floating point in general to start diagnosing it.
>
> As far as the other test results go, you might like to know why they fail:
>
> > Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346)
> > Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
>
> These two tests fail because the undefined-function trampoline function is not
> considered a valid lisp pointer by the debugger, thus causing the frame to show
> up as "bogus stack frame" instead of "undefined function" in the backtrace.
> The bug-346 case also fails because the heuristic used for detecting an
> incompletely-set-up stack frame doesn't work reliably and causes truncated
> backtraces when it fails.
>
> > Expected failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
> > Expected failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
>
> The breakpoint functionality that underlies these two tests was never properly
> implemented for PPC.
>
> > Failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES)
> > Failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES
> > Failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK
> > Failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG
>
> I suspect that these, and the disabled bogus-compiler-note test, are
> from changes
> made for x86oid dynamic-extent that were never implemented for PPC (or for other
> non-x86oid platforms, most likely). The dropping-to-debugger thing is
> at least partly
> from 1.0.37.47, when impure tests were run via run-program instead of
> fork() across
> the board (I have a partial fix in one of my trees that causes an
> unhandled exception
> instead of dropping to debugger, which at least prevents the test
> suite from hanging).
>
> > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
> > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
>
> These are both set :fails-on :sbcl. They are testing for the behavior
> of name-conflicts
> between more than two symbols with the same name at once, and expect a slightly
> nicer user experience than SBCL provides.
>
> > Expected failure: run-program.impure.lisp / (RUN-PROGRAM INHERIT-STDIN)
>
> This also dates back to 1.0.37.47, something about SIGTTIN and process groups,
> and other stuff that I've been able to make neither heads nor tails of.
>
> Anyway, that's my impression of the proposed patch and an explanation of what's
> what with the test suite.
>
> -- Alastair Bridgewater

On 8 May 2010 09:42, Roman Marynchak <roman.marynchak@...> wrote:
> It will be interesting to know the general policy regarding the issues with
> wrong arguments types during the form compilation. Should SBCL check
> everything it can check?
Most things like these are pretty far down the priority ladder, but
generally speaking more input validation is better -- so patches are
quite welcome.
Cheers,
-- Nikodemus

Hello,
It will be interesting to know the general policy regarding the issues with
wrong arguments types during the form compilation. Should SBCL check
everything it can check? For example, this issue
https://bugs.launchpad.net/sbcl/+bug/576594
exists also in CLISP and Lispworks. But this code is unlikely to be written
by somebody, unless he or she do not know about DEFTYPE syntax at all.
Should SBCL have a protection against such non-standard usage attempts? Or
we assume users to be smart enough and therefore we should not pay our
attention to such problems? I am asking about this, because there are
probably many similar issues - should I report them in the future or not? I
have already put some of them to Launchpad, but they mostly involve the
crazy code which is unlikely to occur in real life:
https://bugs.launchpad.net/sbcl/+bug/573956https://bugs.launchpad.net/sbcl/+bug/573968
Regards,
Roman

Hi,
This is a patch to fix the timer stress test unnecessarily failing due
to very short timeout on OpenBSD/i386 (and maybe other platforms ?).
I don't believe it changes any of the semantics of the test, and I'm
sure it cannot break other systems.
Cheers !
--
Thomas de Grivel
http://b.lowh.net/billitch

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details