From: Juho S. <js...@ik...> - 2010-09-20 07:58:29
|
I'll release 1.0.43 this weekend. Until then testing and bugfixes would be more welcome than big changes. -- Juho Snellman |
From: Matthew S. <ako...@gm...> - 2010-09-21 16:04:04
|
Juho Snellman <jsnell <at> iki.fi> writes: > > I'll release 1.0.43 this weekend. Until then testing and bugfixes would be more welcome than big changes.-- Juho Snellman > Compiling 1.0.42.51 under Windows 7 32-bit using cygwin and sbcl 1.0.42.37, I get the following output before erring out: SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * 5 * ; in: LAMBDA (FEATURES) ; (FLET ((SB-COLD::ENABLE (SB-COLD::X) ; (PUSHNEW SB-COLD::X SB-COLD::FEATURES)) ; (SB-COLD::DISABLE (SB-COLD::X) ; (SETF SB-COLD::FEATURES #))) ; (SB-COLD::ENABLE :SB-DOC) ; (SB-COLD::ENABLE :SB-LDB) ; (SB-COLD::ENABLE :SB-AFTER-XC-CORE) ; (SB-COLD::ENABLE :SB-UNICODE) ; (SB-COLD::ENABLE :SB-SOURCE-LOCATIONS)) ; ; note: deleting unused function ; (FLET DISABLE) ; ; compilation unit finished ; printed 1 note target features *SHEBANG-FEATURES*= (:SB-AFTER-XC-CORE :ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :WIN32 :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS :CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC) target backend-subfeatures *SHEBANG-BACKEND-FEATURES*=NIL T * #<PACKAGE "SB-COLD"> * "obj/from-xc/" * T * T * ; in: LAMBDA NIL ; (THE SB!SYS:SAP-INT #:NEW-VALUE659) ; ; caught STYLE-WARNING: ; undefined type: SAP-INT ; ; compilation unit finished ; Undefined type: ; SAP-INT ; caught 1 STYLE-WARNING condition ; (THE SB!C::CLAMBDA #:NEW-VALUE667) ; ; caught STYLE-WARNING: ; undefined type: CLAMBDA ; ; compilation unit finished ; Undefined type: ; CLAMBDA ; caught 1 STYLE-WARNING condition ; (THE SB!C:TN #:NEW-VALUE681) ; ; caught STYLE-WARNING: ; undefined type: TN ; ; compilation unit finished ; Undefined type: ; TN ; caught 1 STYLE-WARNING condition ; (SB!INT:BAD-TYPE SB!IMPL::NAME 'SYMBOL "Type name is not a symbol:~% ~S" ; SB!KERNEL:FORM) ; ; caught STYLE-WARNING: ; undefined function: BAD-TYPE ; ; compilation unit finished ; Undefined function: ; BAD-TYPE ; caught 1 STYLE-WARNING condition STYLE-WARNING: redefining SB!THREAD:MAKE-MUTEX in DEFUN STYLE-WARNING: redefining SB!THREAD::MAKE-SPINLOCK in DEFUN STYLE-WARNING: new FTYPE proclamation for CLASSOID-NAME (FUNCTION (CLASSOID) (VALUES SYMBOL &OPTIONAL)) does not match the old FTYPE proclamation: (FUNCTION (CLASSOID) (VALUES T &OPTIONAL)) * debugger invoked on a SB-INT:SIMPLE-FILE-ERROR: error opening #P"C:\\cygwin\\usr\\local\\src\\sbcl-dev\\sbcl-build\\output \\object-filenames-for-genesis.lisp-expr": No such file or directory Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"C:\\cygwin\\usr\\local\\src\\sbcl-dev\\sbcl-build\\output \\object-filenames-for-genesis.lisp-expr" 2) 0] * //testing for consistency of first and second GENESIS passes diff: output/genesis-2: No such file or directory error: header files do not match between first and second GENESIS |
From: Stas B. <sta...@gm...> - 2010-09-21 16:27:03
|
Matthew Swank <ako...@gm...> writes: > Juho Snellman <jsnell <at> iki.fi> writes: > >> >> I'll release 1.0.43 this weekend. Until then testing and bugfixes would be > more welcome than big changes.-- Juho Snellman >> > Compiling 1.0.42.51 under Windows 7 32-bit using cygwin and sbcl 1.0.42.37, I > get the following output before erring out: > ... Did you run clean.sh before compiling? -- With Best Regards, Stas. |
From: Matthew S. <ako...@gm...> - 2010-09-21 16:41:42
|
Stas Boukarev <stassats <at> gmail.com> writes: > > Matthew Swank <akopa.gmane.poster <at> gmail.com> writes: > > > Compiling 1.0.42.51 under Windows 7 32-bit using cygwin and sbcl 1.0.42.37, I > > get the following output before erring out: > > ... > Did you run clean.sh before compiling? > It was a copy of a fresh (cvs) checkout, but no I did not. However, I don't see anything in the checkout that clean.sh removes. Matt |
From: Nikodemus S. <nik...@ra...> - 2010-09-21 16:49:42
|
Turns out that 1.0.42.40 broke the Windows build. 1.0.42.52 should address the issue, and builds for me at least. Can you verify? Cheers, -- Nikodemus |
From: Matthew S. <ako...@gm...> - 2010-09-21 16:56:12
|
Nikodemus Siivola <nikodemus <at> random-state.net> writes: > > Turns out that 1.0.42.40 broke the Windows build. > > 1.0.42.52 should address the issue, and builds for me at least. Can you verify? > > Cheers, > > -- Nikodemus Yes, it works swimmingly. Thank you, Matt. P.S. Is the defconstant a temporary fix? |
From: Nikodemus S. <nik...@ra...> - 2010-09-21 17:10:50
|
On 21 September 2010 19:55, Matthew Swank <ako...@gm...> wrote: > P.S. Is the defconstant a temporary fix? It duplicates the situation prior to 1.0.42.40, but I haven't looked into how select() behaves on Windows, so I'm not sure what The Right Thing actually is. So, yes, it is probably temporary, but not in the sense that "something else will be done immediately after freeze". Might take a while... Cheers, -- Nikodemus |
From: Alastair B. <ala...@gm...> - 2010-09-22 15:17:45
|
On Tue, Sep 21, 2010 at 1:10 PM, Nikodemus Siivola <nik...@ra...> wrote: > On 21 September 2010 19:55, Matthew Swank <ako...@gm...> wrote: > >> P.S. Is the defconstant a temporary fix? > > It duplicates the situation prior to 1.0.42.40, but I haven't looked > into how select() behaves on Windows, so I'm not sure what The Right > Thing actually is. For the record, the version of select() that SBCL/Win32 uses is in src/runtime/wrap.c, and was originally written by myself. The Right Thing is probably to not use file descriptors on windows in the first place (ISTR that they leak, and they're a construct of MSVCRT.DLL anyway, not of the underlying windows API). > So, yes, it is probably temporary, but not in the sense that > "something else will be done immediately after freeze". Might take a > while... > > Cheers, > > -- Nikodemus -- Alastair |
From: Juho S. <js...@ik...> - 2010-09-26 14:46:13
|
On Mon, Sep 20, 2010 at 9:58 AM, Juho Snellman <js...@ik...> wrote: > I'll release 1.0.43 this weekend. Until then testing and bugfixes would be > more welcome than big changes. > Something in 1.0.42.43 caused :DEBUGGER-NO-HANG-ON-SESSION-LOCK-IF-INTERRUPTED in threads.impure.lisp to reliably hang in a debugger prompt on Linux (tested on two machines). Nikodemus, any idea of why that could be, and whether it's easily fixable? Or should we just roll back .43 and .45 and proceed with release? -- Juho Snellman |
From: Juho S. <js...@ik...> - 2010-09-26 15:15:35
|
On Sun, Sep 26, 2010 at 4:46 PM, Juho Snellman <js...@ik...> wrote: > On Mon, Sep 20, 2010 at 9:58 AM, Juho Snellman <js...@ik...> wrote: > >> I'll release 1.0.43 this weekend. Until then testing and bugfixes would be >> more welcome than big changes. >> > > Something in 1.0.42.43 caused > :DEBUGGER-NO-HANG-ON-SESSION-LOCK-IF-INTERRUPTED in threads.impure.lisp to > reliably hang in a debugger prompt on Linux (tested on two machines). > > Nikodemus, any idea of why that could be, and whether it's easily fixable? > Or should we just roll back .43 and .45 and proceed with release? > Sigh, in addition 1.0.42.50 seems to make :TIMER :STRESS reliably fail. -- Juho Snellman |
From: Nikodemus S. <nik...@ra...> - 2010-09-27 14:15:56
|
On 26 September 2010 18:15, Juho Snellman <js...@ik...> wrote: >> Something in 1.0.42.43 caused >> :DEBUGGER-NO-HANG-ON-SESSION-LOCK-IF-INTERRUPTED in threads.impure.lisp to >> reliably hang in a debugger prompt on Linux (tested on two machines). >> Nikodemus, any idea of why that could be, and whether it's easily fixable? >> Or should we just roll back .43 and .45 and proceed with release? > > Sigh, in addition 1.0.42.50 seems to make :TIMER :STRESS reliably fail. Unless I can sort these out soonish I'll back them out. Cheers, -- Nikodemus |