Elliott Slaughter | 1 Oct 2011 01:02
Picon
Gravatar

Re: freeze for sbcl 1.0.52

On Fri, Sep 30, 2011 at 12:43 PM, David Lichteblau <david <at> lichteblau.com> wrote:

Hi Elliott,

Quoting David Lichteblau (david <at> lichteblau.com):
> Quoting Elliott Slaughter (elliottslaughter <at> gmail.com):
> > Hm, nope same error in 4aad6e46. The relevant section of the build log is
> > the same other than the error in coreparse moving down two lines.
>
> The build is broken on Windows in several respects.  I will take care of
> these issues today.

perhaps you've seen it; I've pushed fixes earlier today.

Can you test on your Windows to double-check?  Please note that there's
still the test output directory cleanup issue; sorry about that.

It compiles (with all contribs) now on 6113d10b. Some tests are failing, but I don't have any idea whether these are Windows-specific or not:



--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
David Lichteblau | 1 Oct 2011 12:32
Gravatar

Re: freeze for sbcl 1.0.52

Quoting Elliott Slaughter (elliottslaughter <at> gmail.com):
> It compiles (with all contribs) now on 6113d10b. Some tests are failing, but

Thanks for checking.

> I don't have any idea whether these are Windows-specific or not:
>
> http://elliottslaughter.com/files/build2-tests.txt

My plan is to not worry about those for the moment.  In the next release
cycle, we need to mark all currently failing tests as expected on
Windows, simply in order to establish a baseline against further
regressions.  Then we take it from there.

d.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Gabriel Dos Reis | 1 Oct 2011 16:48

formating double-float with "~G"

Hi,

Anatoly submitted the following patch 2 years ago

   http://sourceforge.net/mailarchive/message.php?msg_id=23488282

>From the mail archive, I do not see that it was discussed/considered.
I can reproduce the issues in SBCL-1.0.51.
Both OpenAxiom and FriCAS have local copies of this patch -- CCL
and GCL do not seem affected.

I would like to know whether this is one of these patches that
fall through the crack or whether it is one of those which would
never make it to SBCL.

-- Gaby

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Charles Turner | 5 Oct 2011 00:25
Picon

Possible optimisation for FROB-DO-BODY

The procedure FROB-DO-BODY in src/code/primordial-extensions.lisp seems 
like it could be optimised, in particular,

`(block ,block
    (,bind ,(nreverse r-inits)
       , <at> decls
       (tagbody
          (go ,label-2)
          ,label-1
          (tagbody , <at> code)
          (,step , <at> (nreverse r-steps))
          ,label-2
          (unless ,(first endlist) (go ,label-1))
          (return-from ,block (progn , <at> (rest endlist))))))

There doesn't seem to be a need for the two tags, the attached patch in 
essence switches the check for termination and the code splice and adds 
a (go ,labe-1) at the end. I'm new to Lisp in general and SBCL in 
particular, so my apologies in advance if this is tripe. I recompiled 
with the change and ran the test suite, I noticed no regressions.

Thanks for reading,

Charles Turner
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Juho Snellman | 5 Oct 2011 05:20
Picon
Picon
Favicon

Re: freeze for sbcl 1.0.52

I didn't make the release, since a test was failing on x86-64 Linux, and I didn't have time to dig into it during the weekend. The failure is in :sleep-many-interrupts, added in e62bb3a4b9633dbd898fca05cc4af3dd0a16e0aa. It's basically checking that code like...


sleep 1.5 seconds
interrupt the sleep with a signal, spend some time in the interrupt handler
sleep returns with eintr
return to sleep

... takes about 1.5 seconds to execute. Actually it's taking a fair bit more. What seems to be happening is that the test is assuming that the remaining time of an interrupted nanosleep() will be the time from the call to the time the call returns. What I'm seeing on Linux is that it's the time from the call to the time the signal handler is called.

a) Is anyone else seeing this failure, and on what platforms?
b) Is this test valid at all? The spec for nanosleep() is of silent on the issue.

Right now I'm inclined to just remove the test, though I guess trying to compute the appropriate delays after interrupts in sb-unix::nanosleep() ourselves would be another option.

--
Juho Snellman
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Paul Khuong | 5 Oct 2011 07:21
Picon
Gravatar

Re: freeze for sbcl 1.0.52

On 2011-10-04, at 11:20 PM, Juho Snellman wrote:

> I didn't make the release, since a test was failing on x86-64 Linux, and I
> didn't have time to dig into it during the weekend. The failure is in
> :sleep-many-interrupts, added in e62bb3a4b9633dbd898fca05cc4af3dd0a16e0aa.
> It's basically checking that code like...
> 
> sleep 1.5 seconds
> interrupt the sleep with a signal, spend some time in the interrupt handler
> sleep returns with eintr
> return to sleep
> 
> ... takes about 1.5 seconds to execute. Actually it's taking a fair bit
> more. What seems to be happening is that the test is assuming that the
> remaining time of an interrupted nanosleep() will be the time from the call
> to the time the call returns. What I'm seeing on Linux is that it's the time
> from the call to the time the signal handler is called.
> 
> a) Is anyone else seeing this failure, and on what platforms?
> b) Is this test valid at all? The spec for nanosleep() is of silent on the
> issue.

I'm pretty sure that the test is invalid and depends on standard-breaking behaviour in Darwin. FWIW, POSIX
says not to do precisely what we're doing (looping around nanosleep).

Paul Khuong
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Christophe Rhodes | 7 Oct 2011 10:21
Favicon

Re: [Sbcl-help] rounding issue

Christophe Rhodes <csr21 <at> cantab.net> writes:

> [ %UNARY-ROUND brokenness, from sbcl-help ]
>
> Sorry.  Juho, can I slip this in under your freeze radar?

Actually, let me rephrase that.  The broken %unary-round prevents me
from compiling the fixed %unary-round; therefore, I think we can't
possibly release with the brokenness.  Mea maxima culpa.  Working on a
way to satisfy myself that the fix that I am going to commit actually
works.

Sorry, sorry, sorry,

Christophe

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Christophe Rhodes | 7 Oct 2011 11:16
Favicon

Re: [Sbcl-help] rounding issue

Christophe Rhodes <csr21 <at> cantab.net> writes:

> Christophe Rhodes <csr21 <at> cantab.net> writes:
>
>> [ %UNARY-ROUND brokenness, from sbcl-help ]
>>
>> Sorry.  Juho, can I slip this in under your freeze radar?
>
> Actually, let me rephrase that.  The broken %unary-round prevents me
> from compiling the fixed %unary-round; therefore, I think we can't
> possibly release with the brokenness.  Mea maxima culpa.  Working on a
> way to satisfy myself that the fix that I am going to commit actually
> works.

On that note: on my x86 machine I get a number of failing tests.  Some
of them are in things that I seem to feel there's already been some
discussion about the tests not being valid: sleep-many-interrupts and
deadlock-detection interrupts (signals.impure.lisp, threads.impure.lisp
respectively), but one is puzzling to me: "(sleep non-consing)" in
interface.pure.lisp.

* reading the disassembly of sb-unix:nanosleep on x86 reveals several
  calls to alloc_overflow_in_exx.  These may just be related to
  C-int-≥Lisp-integer conversions that never trigger; I couldn't really
  tell, because

* the disassembly is rather less comprehensible than I recall.  I could
  be wrong, but I don't recall quite so many explicit FS-SEGMENT-PREFIX
  instructions everywhere.  Here's an example:

;      6CD:       64               FS-SEGMENT-PREFIX
;      6CE:       892D5C000000     MOV [#x5C], EBP
;      6D4:       BA08000000       MOV EDX, 8
;      6D9:       64               FS-SEGMENT-PREFIX
;      6DA:       031534000000     ADD EDX, [#x34]
;      6E0:       64               FS-SEGMENT-PREFIX
;      6E1:       3B1538000000     CMP EDX, [#x38]
;      6E7:       7607             JBE L19
;      6E9:       E8F27F32FE       CALL #x80686E0             ;      alloc_overflow_edx

* there are also explicit calls to %SAP-ALIEN, which I guess are really
  the consing culprits:

;      712: L21:  8B3D6C03D409     MOV EDI, [#x9D4036C]       ; #<SB-ALIEN-INTERNALS:ALIEN-POINTER-TYPE
                                                              ;   (* #)>
;      718:       8B056403D409     MOV EAX, [#x9D40364]       ; #<FDEFINITION object for SB-ALIEN-INTERNALS:%SAP-ALIEN>

  but why?

Cheers,

Christophe

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Stig Hemmer | 7 Oct 2011 20:04
Picon

Re: Possible optimisation for FROB-DO-BODY

I started doing some benchmarking on a simple DO-loop, and discovered
no difference with and without your patch.

I disassembled the compiled code and discovered that was exactly the
same in both cases!  Apparently, the optimizer moved the code around
until it was identical.

And the compiled code looked pretty much like the pre-patch LISP code
in the order of code fragments.

I also did some manual macro-expanding to make sure:  The code is
definitely reordered by the compiler.

In retrospect it makes sense: A label(tag) doesn't cost anything, it
is just an address.. What matters is the number of instructions
executed in each iteration of the loop.  (The instructions leading up
to the loop or after the loop is relatively uninteresting since they
are only executed once)

The original macro expands and compiles to something like

pre-loop stuff
JMP L2
L1:
In-loop and stepping stuff
L2:
exit test
JMP NOT finished, L1
post-loop

In addition to the necessary stuff, there is only the conditional jump
executed each time.

A naive compilation of your code would look like:
pre-loop stuff
L2:
exit test
JMP finished, L3
In-loop and stepping stuff
JMP L2
L3:
post-loop stuff

This would involve one conditional and one non-conditional jump per
iteration.  So, this is SLOWER than the original code. Fortunately,
SBCL has a good optimizer that fixes i

It is good that people are interested in optimalization, but you
should be able to benchmark the results to see if they actually work.

Stig Hemmer

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
Jim Wise | 10 Oct 2011 15:58
Gravatar

Re: freeze for sbcl 1.0.52

Jim Wise <jwise <at> draga.com> writes:

> Juho Snellman <jsnell <at> iki.fi> writes:
>
>> Hi,
>>
>> I'll try to release 1.0.52 next weekend. Please be conservative with
>> commits until then.
>
> I've uploaded builds of 1.0.52 for Solaris/x86-64 and Darwin/x86-64.
> The x86 builds for both of these platforms had issues in testing, which
> I'm looking into -- I'll upload a README pointing users at the previous
> release later today or tomorrow.

Also, it looks like the setup for git-page isn't quite right -- the way
the git submodule is updated to get the latest release appears tied to
the version the submodule was created with, so it always pulls
sbcl-1.0.51 (and creates the pages accordingly).  I manually updated
this to 1.0.52 and rebuilt the pages, but this needs a real fix, since a
fresh checkout of sbcl-page will rebuild the pages against the 1.0.51
release.

I'm looking at this further, but this is at the edge of my git-fu.
--

-- 
				Jim Wise
				jwise <at> draga.com
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Gmane