From: Christophe R. <cs...@ca...> - 2009-11-20 21:50:57
|
Hi, I'd like to release sbcl-1.0.33 late next week. Grumpy Release Manager Syndrome can be avoided by a surprise-free release, which itself is best assured by extensive testing and problem reporting in advance. Best, Christophe |
From: Paul K. <pv...@pv...> - 2009-11-22 21:29:46
|
On 2009-11-20, at 4:50 PM, Christophe Rhodes wrote: > I'd like to release sbcl-1.0.33 late next week. Grumpy Release Manager > Syndrome can be avoided by a surprise-free release, which itself is best > assured by extensive testing and problem reporting in advance. FBSD 7.2/x86-64 Failure: debug.impure.lisp / (THROW NO-SUCH-TAG) I don't think that's new. I couldn't test on FBSD 7.2/x86. The host didn't have the headers for a 32 bit build. Nothing unexpected on Darwin/x86[-64]. Should the tests be updated to always pass explicit -m32/-m64 to cc, on x86oids? Paul Khuong |
From: Tobias C. R. <tc...@fr...> - 2009-11-22 21:46:59
|
Christophe Rhodes <cs...@ca...> writes: > Hi, > > I'd like to release sbcl-1.0.33 late next week. Grumpy Release Manager > Syndrome can be avoided by a surprise-free release, which itself is best > assured by extensive testing and problem reporting in advance. The newly introduced XREF functions WHO-SPECIALIZES-DIRECTLY and WHO-SPECIALIZES-GENERALLY differ to the previously existing xref functions in how they deal with wrong input. E.g. (sb-introspect:who-macroexpands '#:foo) => NIL and (sb-introspect:who-macroexpands #()) => NIL whereas (sb-introspect:who-specializes-directly '#:foo) => error (sb-introspect:who-specializes-directly #()) => error Should the behaviour be adjusted? -T. |
From: Christophe R. <cs...@ca...> - 2009-11-23 09:39:10
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > The newly introduced XREF functions WHO-SPECIALIZES-DIRECTLY and > WHO-SPECIALIZES-GENERALLY differ to the previously existing xref > functions in how they deal with wrong input. > > E.g. > > (sb-introspect:who-macroexpands '#:foo) => NIL > and > (sb-introspect:who-macroexpands #()) => NIL > > whereas > > (sb-introspect:who-specializes-directly '#:foo) => error > (sb-introspect:who-specializes-directly #()) => error > > Should the behaviour be adjusted? Probably. I have no objections to minor adjustments of contribs during the freeze in general, anyway. Cheers, Christophe |
From: Tobias C. R. <tc...@fr...> - 2009-11-23 19:57:25
|
Christophe Rhodes <cs...@ca...> writes: > "Tobias C. Rittweiler" <tc...@fr...> writes: > >> The newly introduced XREF functions WHO-SPECIALIZES-DIRECTLY and >> WHO-SPECIALIZES-GENERALLY differ to the previously existing xref >> functions in how they deal with wrong input. >> >> E.g. >> >> (sb-introspect:who-macroexpands '#:foo) => NIL >> and >> (sb-introspect:who-macroexpands #()) => NIL >> >> whereas >> >> (sb-introspect:who-specializes-directly '#:foo) => error >> (sb-introspect:who-specializes-directly #()) => error >> >> Should the behaviour be adjusted? > > Probably. I have no objections to minor adjustments of contribs during > the freeze in general, anyway. It would make more sense to me if the Xref functions return NIL for _symbols_ which do not designate the things in the function's domain. And they should signal a type-error for everything else (non-symbol atoms, conses.) That would result in an "incompatible" change for the existing xref functions, though (as you can see in my OP.) I put it in quotes because, arguably, passing non-symbols to those functions results in unspecified behaviour. Is it ok for you to change the xref functions accordingly? Perhaps I should adjust who-specializes-* now, and leave the other bits for the next release? -T. |
From: Christophe R. <cs...@ca...> - 2009-11-23 21:56:12
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > It would make more sense to me if the Xref functions return NIL for > _symbols_ which do not designate the things in the function's > domain. And they should signal a type-error for everything else > (non-symbol atoms, conses.) It's not clear to me that non-symbol atoms and conses are always out of the domain of introspection functions. I can easily imagine function or macro names as conses, for example, and it's only a tiny leap of the imagination to contemplate who-calls functionality on funcallable-instances, and only another small leap to contemplate funcallable arrays or funcallable numbers. Of course, existing sb-introspect functions may not work with such exotica, but... > Is it ok for you to change the xref functions accordingly? I would prefer it if the new sb-introspect functions were made consistent with the existing ones for now; that is, to return nil on unexpected input, but I'm not too stressed if the contrib "owners" (where we define that as "anyone who actually does the work") has a different view. Cheers, Christophe |