From: Juho S. <js...@ik...> - 2011-05-30 12:33:00
|
I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any regressions. -- Juho Snellman |
From: Heka T. <zen...@gm...> - 2011-05-30 23:30:41
|
Please accept these cosmetic changes I did before: http://groups.google.com/group/sbcl-devel/browse_thread/thread/4e2dc3b372ef2888 (few patches in the last post). 2011/5/30, Juho Snellman <js...@ik...>: > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any > regressions. > > -- > Juho Snellman > |
From: Nikodemus S. <nik...@ra...> - 2011-05-31 07:39:04
|
On 31 May 2011 02:30, Heka Treep <zen...@gm...> wrote: > Please accept these cosmetic changes I did before: > http://groups.google.com/group/sbcl-devel/browse_thread/thread/4e2dc3b372ef2888 > (few patches in the last post). I have these in my queue for 1.0.49.early. Freeze period is pretty much reserved for fixing regressions. Cheers, -- nikodemus |
From: Jim W. <jw...@dr...> - 2011-06-01 17:47:35
|
Nikodemus Siivola <nik...@ra...> writes: > On 31 May 2011 02:30, Heka Treep <zen...@gm...> wrote: > >> Please accept these cosmetic changes I did before: >> http://groups.google.com/group/sbcl-devel/browse_thread/thread/4e2dc3b372ef2888 >> (few patches in the last post). > > I have these in my queue for 1.0.49.early. Freeze period is pretty > much reserved for fixing regressions. Also in queue for 1.0.49.early is another round of SunOS test cleanups -- a bunch of tests can now be re-enabled cleanly. I've been thinking about skipped tests -- right now, if a test isn't relevant on a platform, or crashes (as opposed to failing), we skip it, but this doesn't get counted anywhere. With the changes I have ready to go in, for instance, SunOS/x86 gives: Finished running tests. Status: Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT ok //apparent success (reached end of run-tests.sh normally) Wed Jun 1 11:39:23 EDT 2011 but in truth, all thread-related tests have been skipped (since this is a non-threaded build), and a few other tests, such as TRACE-RECURSIVE :ENCAPSULATE NIL have been skipped because they currently crash sbcl. We do similar for most non-linux platforms. I'd like to change this to something like: Finished running tests. Status: Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Skipped (broken): debug.impure.lisp / TRACE-RECURSIVE :ENCAPSULATE NIL Not relevant: 21 tests ok //apparent success (reached end of run-tests.sh normally) Wed Jun 1 11:39:23 EDT 2011 Thoughts? Barring objections, I'll try to get this glued together next week. -- Jim Wise jw...@dr... |
From: Josh E. <jo...@el...> - 2011-06-01 21:14:15
|
On Wed, Jun 01, 2011 at 01:47:18PM -0400, Jim Wise wrote: > I'd like to change this to something like: > > Finished running tests. > Status: > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT > Skipped (broken): debug.impure.lisp / TRACE-RECURSIVE :ENCAPSULATE NIL > Not relevant: 21 tests > ok > //apparent success (reached end of run-tests.sh normally) > Wed Jun 1 11:39:23 EDT 2011 > > Thoughts? Barring objections, I'll try to get this glued together next week. It seems to be in line with the idea of showing expected failures at least. It might even provide a little more motivation to interested parties toward getting the skipped tests enabled :) |
From: Jim W. <jw...@dr...> - 2011-06-02 15:54:06
|
Jim Wise <jw...@dr...> writes: > I'd like to change this to something like: > > Finished running tests. > Status: > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT > Skipped (broken): debug.impure.lisp / TRACE-RECURSIVE :ENCAPSULATE NIL > Not relevant: 21 tests > ok > //apparent success (reached end of run-tests.sh normally) > Wed Jun 1 11:39:23 EDT 2011 > > Thoughts? Barring objections, I'll try to get this glued together next week. Got a chance to hack on this on the train last night. Currently looks like this: Finished running tests. Status: Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT (2 tests skipped for this combination of platform and features) ok (This is with just a sample set of tests converted to skip based on feature checks.) I'll work on converting the remaining tests which are currently bypassed, and get this all in after 1.0.49 is cut. I'll do my best to make the new setup equivalent to the existing versions, but it would be good if people who have platforms I don't can make sure the tests still work when I'm done (I can test SunOS, Darwin, and Linux). Another issue which could pop up, but shouldn't is that the existing method (using read-time conditionals to skip tests which would break) prevents the offending test from being macro-expanded and compiled, as well as run. The new code expands and compiles the tests, but skips them at run-time, updating the tests results. If there _are_ any tests which will cause problems at expand/compile time on platforms for which they are currently disabled, this will need to be fixed. If you find any, let me know, and I'll be happy to take a look. Thanks, -- Jim Wise jw...@dr... |
From: Nikodemus S. <nik...@ra...> - 2011-06-02 17:00:54
|
On 2 June 2011 18:53, Jim Wise <jw...@dr...> wrote: >> Skipped (broken): debug.impure.lisp / TRACE-RECURSIVE :ENCAPSULATE NIL >> Not relevant: 21 tests >> Thoughts? Barring objections, I'll try to get this glued together next week. I like this! Cheers, -- nikodemus |
From: Jim W. <jw...@dr...> - 2011-06-02 20:22:49
|
Jim Wise <jw...@dr...> writes: > Got a chance to hack on this on the train last night. Currently looks > like this: With all tests which use WITH-TEST now converted, this is now Finished running tests. Status: Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT (38 tests skipped for this combination of platform and features) ok //apparent success (reached end of run-tests.sh normally) Thu Jun 2 15:59:31 EDT 2011 (For SunOS/x86, without sb-thread.) I haven't yet dealt with: * test files which use (quit :unix-status 104) to bail on a whole file of tests * tests which have not yet been converted to use WITH-TEST I'll take a stab at the former between now and when I commit this. The latter is (not surprisingly) a bigger job. -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-06-06 19:40:36
|
Jim Wise <jw...@dr...> writes: > Finished running tests. > Status: > Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) > Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT > (38 tests skipped for this combination of platform and features) > ok > //apparent success (reached end of run-tests.sh normally) > Thu Jun 2 15:59:31 EDT 2011 This is now committed. -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-06-08 16:20:21
|
Jim Wise <jw...@dr...> writes: > Jim Wise <jw...@dr...> writes: >> Finished running tests. >> Status: >> Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) >> Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) >> Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET >> Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT >> (38 tests skipped for this combination of platform and features) >> ok >> //apparent success (reached end of run-tests.sh normally) >> Thu Jun 2 15:59:31 EDT 2011 > > This is now committed. Quick question: I'd like to make the various tests under contrib/ use this stuff as well (not in a global sense -- each contrib would output its own test totals in the above format). This would stand in for the various sb-posix tests currently enabled/disabled by read-time conditionals on different platforms, and the various thread tests which don't (yet) support the lutex world. How would people prefer I do this? Load test-util from tests in the contrib test cases? Or break the test stuff out into a new sb-test contrib, and use it from both places? I'm leaning toward the latter, but don't have a strong opinion. I know there are other CL test frameworks out there, but this one is already in-tree -- any reason not to make it part of contrib? -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-05-31 18:34:24
|
Juho Snellman <js...@ik...> writes: > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of > any regressions. Sounds good. Solaris x86_64 is basically unchanged, x86 has some improvement in sb-thread behavior (through no fault of my own). I'll test both tonight and tomorrow, and make sure nothing else broke recently. I'll build and upload Solaris x86, Solaris x86_64, and Darwin x86, and Darwin x86_64 builds for this release, plus experimental threaded builds for Solaris x86, Darwin x86 and Darwin x86_64. -- Jim Wise jw...@dr... |
From: Zach B. <xa...@xa...> - 2011-06-01 15:11:06
|
Juho Snellman <js...@ik...> writes: > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any > regressions. I built the Quicklisp world with the latest checkout and everything worked fine on Linux/amd64. Zach |
From: Matthew S. <ako...@gm...> - 2011-06-01 22:58:16
|
Juho Snellman <jsnell <at> iki.fi> writes: > > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any regressions.-- Juho Snellman > Has anyone been able to build the current cvs on Win32? I've tried under cygwin and mingw, and had the c compiler error out. gcc -g -Wall -O3 -I. -DSBCL_PREFIX=\"'C:\Program Files/sbcl'\" -c -o alloc.o al loc.c In file included from alloc.c:22: os.h:137: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' tok en In file included from thread.h:20, from gc-internal.h:20, from alloc.h:17, from alloc.c:23: ... interrupt.h:110: error: expected specifier-qualifier-list before 'sigset_t' alloc.c: In function 'pa_alloc': alloc.c:46: warning: implicit declaration of function 'check_gc_signals_unblocke d_or_lose' gmake: *** [alloc.o] Error 1 gmake: Leaving directory `c:/cygwin/usr/local/src/sbcl-dev/sbcl-build/src/runtim e' In a related note is anyone building https://github.com/akovalenko/sbcl-win32-threads tls-63 under Win32 on a regular basis? |
From: Elliott S. <ell...@gm...> - 2011-06-02 00:15:48
|
On Wed, Jun 1, 2011 at 3:57 PM, Matthew Swank <ako...@gm...>wrote: > Juho Snellman <jsnell <at> iki.fi> writes: > > > > > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any > regressions.-- Juho Snellman > > > > > Has anyone been able to build the current cvs on Win32? I've tried under > cygwin > and mingw, and had the c compiler error out. > 1.0.48.35 compiles fine for me under MinGW. I'll upload a build when the release is made. gcc -g -Wall -O3 -I. -DSBCL_PREFIX=\"'C:\Program Files/sbcl'\" -c -o > alloc.o al > loc.c > In file included from alloc.c:22: > os.h:137: error: expected '=', ',', ';', 'asm' or '__attribute__' before > '*' tok > en > In file included from thread.h:20, > from gc-internal.h:20, > from alloc.h:17, > from alloc.c:23: > ... > interrupt.h:110: error: expected specifier-qualifier-list before 'sigset_t' > alloc.c: In function 'pa_alloc': > alloc.c:46: warning: implicit declaration of function > 'check_gc_signals_unblocke > d_or_lose' > gmake: *** [alloc.o] Error 1 > gmake: Leaving directory > `c:/cygwin/usr/local/src/sbcl-dev/sbcl-build/src/runtim > e' > > In a related note is anyone building > https://github.com/akovalenko/sbcl-win32-threads tls-63 under Win32 on a > regular > basis? > > > > > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with > vRanger. > Installation's a snap, and flexible recovery options mean your data is > safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > 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: Anton K. <an...@sw...> - 2011-06-02 12:16:01
|
Elliott Slaughter <ell...@gm...> writes: > In a related note is anyone building > https://github.com/akovalenko/sbcl-win32-threads tls-63 under > Win32 on a regular basis? Well, I am :) As usually, current URLs for installers and standalone executables are available at https://github.com/akovalenko/sbcl-win32-threads/wiki . Additionally, all published builds since 1.0.46.32.263.wth are now available at http://archive.siftsoft.com/sbcl/ (this link is now included in the autogenerated wiki page mentioned above). I publish binaries at the same points when I'm ready to deploy them to my own customer, so they're generally more well-tested and stable than a random snapshot from my tree. P.S. Going to add separate maintainance branches soon (official SBCL release + MS Windows patchset + occasional regression fixes only). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia |
From: Nikodemus S. <nik...@ra...> - 2011-06-02 13:36:57
|
On 2 June 2011 15:15, Anton Kovalenko <an...@sw...> wrote: > I publish binaries at the same points when I'm ready to deploy them to > my own customer, so they're generally more well-tested and stable than a > random snapshot from my tree. Apropos, I think it would be a good idea to promote the windows fork on sbcl.org, with explanations as its status. What would be a good link to provde? The forknews one? What should we say? I think it would be swell if eg. Anton could provide a short description from his POV, and eg. David -- who's working on the merge -- could say something about that. Cheers, -- nikodemus |
From: Anton K. <an...@sw...> - 2011-06-02 20:18:49
|
Nikodemus Siivola <nik...@ra...> writes: > Apropos, I think it would be a good idea to promote the windows fork > on sbcl.org, with explanations as its status. > > What would be a good link to provde? The forknews one? > > What should we say? I think it would be swell if eg. Anton could > provide a short description from his POV, and eg. David -- who's > working on the merge -- could say something about that. 1. It seems the most convenient link for potential _users_ is https://github.com/akovalenko/sbcl-win32-threads/wiki (link to current binaries + archive directory + other related URLs). One great advantage is github version control, so the whole public build history is available. I also hope that it will encourage "local" bug reports to the issue tracker instead of private e-mail. 2. Note on the integration status -- I'm preparing to roll back some stuff that proved to be useless/harmful (specifically, :SB-AUTO-FPU-SWITCH that is already disabled in my builds for several months). It will significantly reduce the amount of garbage in win32-os.c, facilitating code reviews. When it's done, I'll be ready to start providing isolated patches, gradually moving toward the merge. E.g. one of the things that is easy to isolate is stdcall callback support (and its official status is very important, to be recognized/supported by CFFI). 3. Currently, I know of the only Windows-specific problem that is yet unsolved, and it's the event loop support. I have some ideas on it (translate it to overlapped calls if supported by a handle, offload to another thread if not), but no implementation is ready yet (and FD-STREAM logic should be affected greatly by any sensible implementanion). 4. Just curious (if David has some time to clarify this): what are the reasons to prefer safepoints over signals on non-Windows? (BTW, some Windows-only safepoint-related code from my tree can be made cross-platform without much effort; since SuspendThread/GetThreadContext are dropped, the whole thing is rather easy to port. Would it be useful if I make it work e.g. on Linux?) -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia |
From: Nikodemus S. <nik...@ra...> - 2011-06-07 18:25:21
|
On 2 June 2011 23:18, Anton Kovalenko <an...@sw...> wrote: >> Apropos, I think it would be a good idea to promote the windows fork >> on sbcl.org, with explanations as its status. >> >> What would be a good link to provde? The forknews one? >> >> What should we say? I think it would be swell if eg. Anton could >> provide a short description from his POV, and eg. David -- who's >> working on the merge -- could say something about that. > > 1. It seems the most convenient link for potential _users_ is > https://github.com/akovalenko/sbcl-win32-threads/wiki (link to current > binaries + archive directory + other related URLs). > > One great advantage is github version control, so the whole public build > history is available. I also hope that it will encourage "local" bug > reports to the issue tracker instead of private e-mail. I added the following text to the SBCL website: "In addition to the official SBCL, a Windows fork exists that adds support for threads on that platform as well. Though is has not yet been incorporated into mainline, Windows users may want to consider using it in the meanwhile." where "a Windows fork" is a link to the wikipage. I'll leave David to add comments on the integration as he sees fit. Cheers, -- nikodemus |
From: Martin C. <cra...@co...> - 2011-06-02 20:24:01
|
Juho Snellman wrote on Mon, May 30, 2011 at 02:32:52PM +0200: > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any > regressions. Thingie looks fine to me. Didn't test slime. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: David L. <da...@li...> - 2011-06-02 22:21:48
|
Quoting Anton Kovalenko (an...@sw...): > 2. Note on the integration status -- I'm preparing to roll back some > stuff that proved to be useless/harmful (specifically, > :SB-AUTO-FPU-SWITCH that is already disabled in my builds for several > months). It will significantly reduce the amount of garbage in > win32-os.c, facilitating code reviews. > > When it's done, I'll be ready to start providing isolated patches, That's cool. But please keep me in the loop to avoid duplicating work, since I've already spent some time splitting your changes up. I'll publish a split repo later this month and would love getting feedback from you at that point. > gradually moving toward the merge. E.g. one of the things that is easy > to isolate is stdcall callback support (and its official status is very > important, to be recognized/supported by CFFI). > > 3. Currently, I know of the only Windows-specific problem that is yet > unsolved, and it's the event loop support. I have some ideas on it > (translate it to overlapped calls if supported by a handle, offload to > another thread if not), but no implementation is ready yet (and > FD-STREAM logic should be affected greatly by any sensible > implementanion). Can you perhaps talk with Stelian Ionescu and Tomas Hlavaty about these design issues? Tomas has been doing work to port iolib to Windows, with input from Stelian, I believe, and that includes I/O multiplexing questions. > 4. Just curious (if David has some time to clarify this): what are the > reasons to prefer safepoints over signals on non-Windows? (BTW, some A very fair question. There are two steps: Initially GC signals indeed get replaced entirely using safepoints, but the real goal is to replace pseudo-atomic (PA), which means that deferrable signals will get delayed to the next safepoint, instead of only getting delayed within PA to its end. (As long as we only take the first step, we have overhead from both safepoints and PA, which doesn't make sense in the long term.) For comparison, let's start with the disadvantages of the safepoint introduction, which conversely are the advantages of the PA approach: PA helps to minimize signal handling latency, because it delays signals only across the few sections of code that absolutely need that delay. And obviously: You don't need the pesky safepoint instructions. The advantage of safepoints boils down to this: Late signal handling makes the code easier to reason about, because you don't have to worry about signals hitting unexpectedly at all. Suddenly, allocation is not that special anymore, and in fact, has fewer instructions; there is no "block GC signals, unblock them; did we block them?" business in the runtime (since there are no GC signals!); I think that your thread_register_gc_trigger() is nicer than the old code; etc. It should be pointed out that, as far as performance is concerned, common wisdom is that safepoints are, perhaps a little bit surprisingly, not a performance problem. Nathan and Paul have researched this area, with the conclusion that, on the one hand, PA is actually pretty fast, and on the other hand, the short safepoint sequence that Paul tried (and that is in use on the windows branches now), performs within +/- 1-2% time of the standard PA code according to his results, meaning that we don't win speed, but also don't lose. Last and very much not least there is the maintainability aspect: Should Windows GC really interact with threads in a radically different way compared to other ports? I think that the answer is clearly "no", and it helps if users testing on unixlike platforms can run code that is at least close to what happens on Windows. The first thing I fixed on my branch was to clear up places that incorrectly equated #ifdef WIN32 with GC_SAFEPOINT, and it will help to keep those separate in the future. Given those tradeoffs, I think it will be understandable why I backported SB-SAFEPOINT to unixlike platforms. Initially it will be an optional feature there. > Windows-only safepoint-related code from my tree can be made > cross-platform without much effort; since SuspendThread/GetThreadContext > are dropped, the whole thing is rather easy to port. Would it be useful > if I make it work e.g. on Linux?) Let's avoid duplicating work in this area. I've mostly got it working on Linux already. More specificially, I had initially ported Dmitry's safepoint-based GC back to Linux. But earlier this week I pulled in your newer Stop The World protocol using thread-local CSP safepoints. It's already somewhat functional now, and I'll publish my git repo once I've fixed the remaining issues. d. |
From: Anton K. <an...@sw...> - 2011-06-03 00:50:35
|
>> 3. Currently, I know of the only Windows-specific problem that is yet >> unsolved, and it's the event loop support. I have some ideas on it >> (translate it to overlapped calls if supported by a handle, offload to >> another thread if not), but no implementation is ready yet (and >> FD-STREAM logic should be affected greatly by any sensible >> implementanion). > > Can you perhaps talk with Stelian Ionescu and Tomas Hlavaty about these > design issues? Tomas has been doing work to port iolib to Windows, with > input from Stelian, I believe, and that includes I/O multiplexing > questions. Thank you for info. However, iolib is designed to work across multiple CL implementations, so it seems to be rather distant from my task at hand. When I use CFFI and Gray streams, it turns out to be easy to work with I/O multiplexing on Windows. A great advantage of NT kernel is that it updates OVERLAPPED structure asynchronously, so the only situation requiring more than one syscall-per-IO-request is when a thread _really_ has to wait (unfortunately, most code ported from Unix tends to ignore this feature: while a naive-but-native Windows-style event loop would have the same scalability properties as epoll/kqueue, reusing Unix techniques results in inheriting all select() problems, amplified by the ridiculous MS Windows limitation of 64 waitable handles per thread). The I/O model implemented currently in my code has the problem described above: it's a Unix emulation, using OVERLAPPED I/O only to support interrupts (and concurrent read-write on the same socket, which is impossible otherwise). Reimplementing it in the native style is the prerequisite for event loop support. >> 4. Just curious (if David has some time to clarify this): what are the >> reasons to prefer safepoints over signals on non-Windows? (BTW, some > > A very fair question. There are two steps: Initially GC signals indeed > get replaced entirely using safepoints, but the real goal is to replace > pseudo-atomic (PA), which means that deferrable signals will get delayed > to the next safepoint, instead of only getting delayed within PA to its > end. [...] > Given those tradeoffs, I think it will be understandable why I > backported SB-SAFEPOINT to unixlike platforms. Initially it will be an > optional feature there. Thank you for the explanation. My decision to get rid of PA flags (current code artifically maintains PA-atomic around alloc() only) was largely caused by the disassembled _uglyness_ of pseudo-atomic sections on Windows; with an added indirection level for thread base access, the disassembler output started to feel like a toothache. If a normally-maintained segment register were available on Windows, my code would probably continue to use PA-bits until now :) -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia |
From: Elliott S. <ell...@gm...> - 2011-06-06 05:23:00
|
On Mon, May 30, 2011 at 5:32 AM, Juho Snellman <js...@ik...> wrote: > I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of any > regressions. > Windows binary up; would someone please commit the following to sbcl-page? Thanks. Index: platform-support-platforms.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl-page/platform-support-platforms.lisp,v retrieving revision 1.139 diff -u -r1.139 platform-support-platforms.lisp --- platform-support-platforms.lisp 5 Jun 2011 23:11:33 -0000 1.139 +++ platform-support-platforms.lisp 6 Jun 2011 05:16:55 -0000 @@ -48,4 +48,4 @@ (define-port :x86-64 :openbsd :available "1.0.48" :os-version 49) (define-port :powerpc :openbsd :available "1.0.48" :os-version 49) -(define-port :x86 :windows :in-progress "1.0.48" :file-type "msi") +(define-port :x86 :windows :in-progress "1.0.49" :file-type "msi") -- 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: Nikodemus S. <nik...@ra...> - 2011-06-06 09:24:16
|
On 6 June 2011 08:22, Elliott Slaughter <ell...@gm...> wrote: > Windows binary up; would someone please commit the following to sbcl-page? Thanks! Updated -- and sbcl-page too is now in git. Cheers, -- nikodemus |
From: Jim W. <jw...@dr...> - 2011-06-06 16:58:30
|
Jim Wise <jw...@dr...> writes: > Juho Snellman <js...@ik...> writes: > >> I'll be releasing 1.0.49 next weekend. Please let sbcl-devel know of >> any regressions. > > Sounds good. Solaris x86_64 is basically unchanged, x86 has some > improvement in sb-thread behavior (through no fault of my own). I'll > test both tonight and tomorrow, and make sure nothing else broke > recently. > > I'll build and upload Solaris x86, Solaris x86_64, and Darwin x86, and > Darwin x86_64 builds for this release, plus experimental threaded builds > for Solaris x86, Darwin x86 and Darwin x86_64. I've uploaded builds for Solaris x86, Solaris x86-64, and an experimental build for Solaris x86 with threads enabled, and updated the download page. I'll take care of darwin x86 and x86-64, including experimental threading builds, later today or tomorrow. Thanks, -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-06-07 21:20:08
|
Jim Wise <jw...@dr...> writes: > I've uploaded builds for Solaris x86, Solaris x86-64, and an > experimental build for Solaris x86 with threads enabled, and updated the > download page. > > I'll take care of darwin x86 and x86-64, including experimental > threading builds, later today or tomorrow. Darwin x86 and x86-64 are now uploaded, and the page updated. I've also uploaded an experimental threaded build for darwin x86, but not x86-64, as I had issues getting through the tests with threads enabled. I'll take a look at that in -current, when I review the enabled/disabled tests for Darwin. -- Jim Wise jw...@dr... |