From: Martin C. <cra...@co...> - 2010-04-09 15:26:16
|
I got this bug report about newish SBCLs. 1.0.36.23+ is broken, 1.0.36.13 works. (defstruct foo (r nil :type (or null simple-vector))) #S(foo :r #(#x00 #x11 #x22 #x33 #x44 #x55 #x66 #x77)) ==> The value ((SB-IMPL::|bqv|) 0 17 34 51 68 85 102 119) is not of type (OR NULL SIMPLE-VECTOR). -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: James Y K. <fo...@fu...> - 2010-04-13 04:23:43
|
On Apr 9, 2010, at 11:26 AM, Martin Cracauer wrote: > I got this bug report about newish SBCLs. 1.0.36.23+ is broken, > 1.0.36.13 works. > > (defstruct foo (r nil :type (or null simple-vector))) > #S(foo :r #(#x00 #x11 #x22 #x33 #x44 #x55 #x66 #x77)) > > ==> The value ((SB-IMPL::|bqv|) 0 17 34 51 68 85 102 119) > is not of type > (OR NULL SIMPLE-VECTOR). Seems almost certain to be due to: > 1.0.36.21: stricter handling of invalid backquote expressions > > Based on patch by: Stas Boukarev <sta...@gm...> > > Fixed launchpad bug #309093. Although I can't say I understand the code or the diff. James |
From: Martin C. <cra...@co...> - 2010-04-13 04:26:41
|
James Y Knight wrote on Tue, Apr 13, 2010 at 12:23:35AM -0400: > > On Apr 9, 2010, at 11:26 AM, Martin Cracauer wrote: > >I got this bug report about newish SBCLs. 1.0.36.23+ is broken, > >1.0.36.13 works. > > > >(defstruct foo (r nil :type (or null simple-vector))) > >#S(foo :r #(#x00 #x11 #x22 #x33 #x44 #x55 #x66 #x77)) > > > >==> The value ((SB-IMPL::|bqv|) 0 17 34 51 68 85 102 119) > > is not of type > > (OR NULL SIMPLE-VECTOR). > > > Seems almost certain to be due to: > > >1.0.36.21: stricter handling of invalid backquote expressions > > > >Based on patch by: Stas Boukarev <sta...@gm...> > > > >Fixed launchpad bug #309093. > > Although I can't say I understand the code or the diff. More specifically, the error message looks typical for a wrongly placed quote or backtick in a Lisp macro. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: Christophe R. <cs...@ca...> - 2010-04-13 06:33:03
|
James Y Knight <fo...@fu...> writes: > Seems almost certain to be due to: > >> 1.0.36.21: stricter handling of invalid backquote expressions >> >> Based on patch by: Stas Boukarev <sta...@gm...> >> >> Fixed launchpad bug #309093. > > Although I can't say I understand the code or the diff. Yeah. I'm not sure why *backquote-count* is bound to -1 around the reading of the (...) in #S(...) -- what happens if it's bound to 0 instead in (defun sharp-S ...) [src/code/sharpm.lisp]? Cheers, Christophe |
From: Stas B. <sta...@gm...> - 2010-04-16 18:47:08
|
Christophe Rhodes <cs...@ca...> writes: > James Y Knight <fo...@fu...> writes: > >> Seems almost certain to be due to: >> >>> 1.0.36.21: stricter handling of invalid backquote expressions >>> >>> Based on patch by: Stas Boukarev <sta...@gm...> >>> >>> Fixed launchpad bug #309093. >> >> Although I can't say I understand the code or the diff. > > Yeah. I'm not sure why *backquote-count* is bound to -1 around the > reading of the (...) in #S(...) -- what happens if it's bound to 0 > instead in (defun sharp-S ...) [src/code/sharpm.lisp]? > In my original patch it was bound to 0, and it works fine with 0. I don't know why Nikodemus changed it to -1. -- With Best Regards, Stas. |
From: Martin C. <cra...@co...> - 2010-04-21 00:32:41
|
Stas Boukarev wrote on Fri, Apr 16, 2010 at 10:46:56PM +0400: > Christophe Rhodes <cs...@ca...> writes: > > > James Y Knight <fo...@fu...> writes: > > > >> Seems almost certain to be due to: > >> > >>> 1.0.36.21: stricter handling of invalid backquote expressions > >>> > >>> Based on patch by: Stas Boukarev <sta...@gm...> > >>> > >>> Fixed launchpad bug #309093. > >> > >> Although I can't say I understand the code or the diff. > > > > Yeah. I'm not sure why *backquote-count* is bound to -1 around the > > reading of the (...) in #S(...) -- what happens if it's bound to 0 > > instead in (defun sharp-S ...) [src/code/sharpm.lisp]? > > > In my original patch it was bound to 0, and it works fine with 0. I > don't know why Nikodemus changed it to -1. Sorry for the delay. Changing it to 0 makes things work for me. Doesn't seem to break anything else. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: Nikodemus S. <nik...@ra...> - 2010-05-02 06:27:33
|
On 16 April 2010 21:46, Stas Boukarev <sta...@gm...> wrote: > In my original patch it was bound to 0, and it works fine with 0. I > don't know why Nikodemus changed it to -1. I honestly don't remember. I'd like to claim it was a typo, but a brainfart is far more likely. Cheers, -- Nikodemus |