From: Juho S. <js...@ik...> - 2011-09-24 01:11:15
|
Hi, I'll try to release 1.0.52 next weekend. Please be conservative with commits until then. -- Juho Snellman |
From: Elliott S. <ell...@gm...> - 2011-09-27 22:16:35
|
On MinGW compilation fails complaining that mman.h doesn't exist: gcc -g -Wall -O3 -fno-omit-frame-pointer -I. -DSBCL_PREFIX=\"'C:\Program Files (x86)/sbcl'\" -c -o coreparse.o coreparse.c coreparse.c:29:22: fatal error: sys/mman.h: No such file or directory The complete build log is available at http://elliottslaughter.com/files/build.txt On Fri, Sep 23, 2011 at 6:11 PM, Juho Snellman <js...@ik...> wrote: > Hi, > > I'll try to release 1.0.52 next weekend. Please be conservative with > commits until then. > > -- > Juho Snellman > > > ------------------------------------------------------------------------------ > 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 > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > -- 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 |
From: Juho S. <js...@ik...> - 2011-09-29 09:12:53
|
On Wed, Sep 28, 2011 at 12:16 AM, Elliott Slaughter < ell...@gm...> wrote: > On MinGW compilation fails complaining that mman.h doesn't exist: > > gcc -g -Wall -O3 -fno-omit-frame-pointer -I. -DSBCL_PREFIX=\"'C:\Program > Files (x86)/sbcl'\" -c -o coreparse.o coreparse.c > coreparse.c:29:22: fatal error: sys/mman.h: No such file or directory > > The complete build log is available at > http://elliottslaughter.com/files/build.txt > Thanks. I pushed the trivial #ifdef fix, which looks like it should be enough. But could you please check that it actually works? :-) -- Juho Snellman |
From: Elliott S. <ell...@gm...> - 2011-09-29 19:16:52
|
On Thu, Sep 29, 2011 at 2:12 AM, Juho Snellman <js...@ik...> wrote: > On Wed, Sep 28, 2011 at 12:16 AM, Elliott Slaughter < > ell...@gm...> wrote: > >> On MinGW compilation fails complaining that mman.h doesn't exist: >> >> gcc -g -Wall -O3 -fno-omit-frame-pointer -I. -DSBCL_PREFIX=\"'C:\Program >> Files (x86)/sbcl'\" -c -o coreparse.o coreparse.c >> coreparse.c:29:22: fatal error: sys/mman.h: No such file or directory >> >> The complete build log is available at >> http://elliottslaughter.com/files/build.txt >> > > Thanks. I pushed the trivial #ifdef fix, which looks like it should be > enough. But could you please check that it actually works? :-) > 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. -- 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 |
From: David L. <da...@li...> - 2011-09-30 08:10:47
|
Quoting Elliott Slaughter (ell...@gm...): > 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. d. |
From: Elliott S. <ell...@gm...> - 2011-09-30 23:02:36
|
On Fri, Sep 30, 2011 at 12:43 PM, David Lichteblau <da...@li...>wrote: > Hi Elliott, > > Quoting David Lichteblau (da...@li...): > > Quoting Elliott Slaughter (ell...@gm...): > > > 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: http://elliottslaughter.com/files/build2-tests.txt -- 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 |
From: David L. <da...@li...> - 2011-10-01 10:32:23
|
Quoting Elliott Slaughter (ell...@gm...): > 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. |
From: Juho S. <js...@ik...> - 2011-10-05 03:20:49
|
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 |
From: Paul K. <pv...@pv...> - 2011-10-05 05:21:21
|
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 |
From: Jim W. <jw...@dr...> - 2011-10-10 13:58:33
|
Juho Snellman <js...@ik...> 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. -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-10-10 13:59:11
|
Jim Wise <jw...@dr...> writes: > Juho Snellman <js...@ik...> 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 jw...@dr... |
From: Juho S. <js...@ik...> - 2011-10-10 14:13:59
|
On Mon, Oct 10, 2011 at 3:58 PM, Jim Wise <jw...@dr...> wrote: > 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. > An issue in the release script (the submodule needs to be updated), which won't be a problem in the future. I'd just forgotten to push sbcl-page again after making the fix. -- Juho Snellman |
From: Elliott S. <ell...@gm...> - 2011-10-12 04:12:48
|
1.0.52 binary for Windows is up. As usual the following patch needs to be applied to sbcl-page (or give me commit permission): diff --git a/platform-support-platforms.lisp b/platform-support-platforms.lisp index a768211..c00a19f 100644 --- a/platform-support-platforms.lisp +++ b/platform-support-platforms.lisp @@ -48,5 +48,5 @@ (define-port :x86-64 :openbsd :available "1.0.50" :os-version 49) (define-port :powerpc :openbsd :available "1.0.50" :os-version 49) -(define-port :x86 :windows :in-progress "1.0.51" :file-type "msi") +(define-port :x86 :windows :in-progress "1.0.52" :file-type "msi") (define-port :x86-64 :windows :in-progress) On Mon, Oct 10, 2011 at 6:37 AM, Jim Wise <jw...@dr...> wrote: > Juho Snellman <js...@ik...> 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. > > -- > Jim Wise > jw...@dr... > > > ------------------------------------------------------------------------------ > 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 > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > -- 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 |
From: Jim W. <jw...@dr...> - 2011-10-12 13:35:54
|
Elliott Slaughter <ell...@gm...> writes: > 1.0.52 binary for Windows is up. > > As usual the following patch needs to be applied to sbcl-page (or > give me commit permission): Change made, and site re-generated. Do we want to keep the windows port marked `in progress'? We don't otherwise seem to use that marking for ports where a download is available... -- Jim Wise jw...@dr... |