bug (?) when using macro lambda list keywords in defun

The following form:

(defun foo (&whole whole) 42)

Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without SLIME,
simple using the CLI):

debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
{A8154E9}>:

    unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE. This is probably a
bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad
user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND
'COMPILE), or by stray pointers from alien code or from unsafe Lisp code;
or there might be a bug in the OS or hardware that SBCL is running on.) If
it seems to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists, which you can
find at <http://sbcl.sourceforge.net/>.

The result is the same with &environment, although any other symbol
beginning with & works.

Lukács

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: bug (?) when using macro lambda list keywords in defun

Berki Lukacs Tamas writes:
> 
> The following form:
> 
> (defun foo (&whole whole) 42)
> 
> Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without SLIME,
> simple using the CLI):
> 
> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
> {A8154E9}>:
> 
>     unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE. 

As expected.  Why would you want to use a MACRO lambda list with deFUN?

> This is probably a bug in SBCL itself. 

No, this is mandated by the CL specifications.

DEFUN uses ordinary lambda lists, not macro lambda lists.
http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm

 
> The result is the same with &environment, although any other symbol
> beginning with & works.

The other symbols beginning with & are normal symbols.  (That is, all
the symbols that are not in LAMBDA-LIST-KEYWORDS).
&FOO isn't even in the CL package!

Re: bug (?) when using macro lambda list keywords in defun

On Nov 30, 2006, at 8:35 PM, Pascal Bourguignon wrote:

> Berki Lukacs Tamas writes:
>>
>> The following form:
>>
>> (defun foo (&whole whole) 42)
>>
>> Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without  
>> SLIME,
>> simple using the CLI):
>>
>> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
>> {A8154E9}>:
>>
>>     unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE.
>
> As expected.  Why would you want to use a MACRO lambda list with  
> deFUN?
>
>> This is probably a bug in SBCL itself.
>
> No, this is mandated by the CL specifications.

The spec mandates that you drop into the debugger? I would imagine  
that the spec mandates that an error be thrown, but I admit I haven't  
looked at the spec.

> DEFUN uses ordinary lambda lists, not macro lambda lists.

Re: bug (?) when using macro lambda list keywords in defun

Cyrus Harmon <ch-sbcl <at> bobobeach.com> writes:

>>> The following form:
>>>
>>> (defun foo (&whole whole) 42)
>>>
>>> Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without  
>>> SLIME,
>>> simple using the CLI):
>>>
>>> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
>>> {A8154E9}>:
>>>
>>>     unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE.

In any case, signalling a BUG is wrong from the SBCL point of view,
since it is ment to indicate a probably bug in SBCL: invariant
violations, etc.

>> As expected.  Why would you want to use a MACRO lambda list with  
>> deFUN?
>>
>>> This is probably a bug in SBCL itself.
>>
>> No, this is mandated by the CL specifications.
>
> The spec mandates that you drop into the debugger? I would imagine  
> that the spec mandates that an error be thrown, but I admit I haven't  
> looked at the spec.

Re: threads, special variables and slime

Andras Simon <asimon <at> math.bme.hu> writes:

> While playing with threads with SBCL 0.9.18.18 (in slime) I ran into
> the following:

Thanks for the report. Just to let you know that I at least can reproduce this.
No idea what is causing this yet.

> The reason why I thought this should work is that section 11.2 of the
> manual says "bindings (e.g. using LET) are local to the thread". What
> am I missing?

Nothing. It's a bug. (Well, you could be getting hit by streams not being
threadsafe, but that is not the case here: the same behaviour can be observed
if all three results are saved to different places.)

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: GC bug on win32

"Michael Ben Yosef" <septagon <at> mweb.co.za> writes:

> Sorry if this is a bit of a useless bug report. I imagine it must be tough
> getting to the bottom of these GC issues. And sorry too if sbcl on win32 is
> not yet stable enough for this kind of thing to be worth reporting anyway.

This and other similar GC failures, and the mysterious startup
behaviours from shortcuts, etc, _seem_ to have been fixed by the
correct stack start patch by Alastair Bridgewater, merged as 1.0.0.3.

...so all of you who have witnessed any of these or similar issues are
urged to build from CVS and tell us if you can still trigger them. I
can't seem to, but most of these bugs where of somewhat ephemeral
nature, so "works for me too" confirmations would be most welcome.

[one test-case retained here, but please do try other things as well]
> (deftype whitespace () '(member #\Space #\Newline #\Return #\Tab))
> (deftype digit () '(member #\0 #\1 #\2 #\3 #\4 #\5 #\6 #\7 #\8 #\9))
> (deftype punctuation () '(member #\. #\, #\! #\? #\; #\" #\' #\] #\[ #\( #\) #\\ #\/  #\{ #\} #\:))
> (deftype text-type () '(not (or digit whitespace punctuation)))
> (defparameter test-string "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.
> ")
> (defun test-text-type ()
>   (loop
>      for i from 0 to (1- (length test-string))
>      collect (typep (aref test-string i) 'text-type)))

> fatal error encountered in SBCL pid 3028:
> GC invariant lost, file "gencgc.c", line 831

Re: bug (?) when using macro lambda list keywords in defun

> If someone can point a finger at a place where the &WHOLE is given
> licence to signal an error should it appear in an ordinary
> lambda-list, I'd be quite happy.

(sorry for top-posting, I was not subscribed to the list before)

CLHS section 3.4.1 states that "Implementations are free to provide
additional lambda list keywords. For a list of all lambda list keywords
used by the implementation, see lambda-list-keywords.". IMHO, if you
really want to take the spec literally, the current state of SBCL might be
considered correct, since it provides two lambda list keywords,
&environment and &whole in ordinary lambda lists, both are present in
lambda-list-keywords, and their implementation-specified behavior is that
they signal the SB-INT:BUG condition. Although this is IMHO not too
appropriate. What do you think about this simple patch?

Lukács

Index: compiler/parse-lambda-list.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/parse-lambda-list.lisp,v
retrieving revision 1.15
diff -c -5 -r1.15 parse-lambda-list.lisp
*** compiler/parse-lambda-list.lisp	14 Jul 2005 18:57:01 -0000	1.15
--- compiler/parse-lambda-list.lisp	2 Dec 2006 19:13:47 -0000
***************
*** 102,111 ****

run-program and string-streams on win32

I'm running SBCL 1.0 on Windows XP and I'm having a weird problem

;; This works fine
* (with-open-file (outstream "outfile.tmp" :direction :output)
(sb-ext:run-program "c:\\Program Files\\Perforce\\P4.exe" '() :output
outstream))

;; This hangs forever
* (with-output-to-string (outstream) (sb-ext:run-program "c:\\Program
Files\\Perforce\\p4.exe" '() :output outstream))

I searched the archives to see if this was expected behavior / a known
bug, but I didn't see anything.  Any thoughts?

-Ben
--

-- 
BookMooch - New life for Old books
http://www.bookmooch.com/m/inventory/bbelly

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: run-program and string-streams on win32

"Ben Holm" <benbelly <at> gmail.com> writes:

> I'm running SBCL 1.0 on Windows XP and I'm having a weird problem
>
> ;; This works fine
> * (with-open-file (outstream "outfile.tmp" :direction :output)
> (sb-ext:run-program "c:\\Program Files\\Perforce\\P4.exe" '() :output
> outstream))
>
> ;; This hangs forever
> * (with-output-to-string (outstream) (sb-ext:run-program "c:\\Program
> Files\\Perforce\\p4.exe" '() :output outstream))
>
> I searched the archives to see if this was expected behavior / a known
> bug, but I didn't see anything.  Any thoughts?

Expected yes, and a sort of bug -- or at least a rather serious shortcoming.
The system sets up a handler the read from the pipe connected to the program,
and copy the data to the string-stream. However, the handler-code doesn't
work properly on Windows as of yet (shades of select(2)), so the pipe gets
full and the writing end eventually blocks.

Fixing this will require rather extensive stream work, which is
partially done in my local tree, but much remains to be done.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Re: run-program and string-streams on win32

On 12/5/06, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:
>
> Expected yes, and a sort of bug -- or at least a rather serious shortcoming.
> The system sets up a handler the read from the pipe connected to the program,
> and copy the data to the string-stream. However, the handler-code doesn't
> work properly on Windows as of yet (shades of select(2)), so the pipe gets
> full and the writing end eventually blocks.
>
> Fixing this will require rather extensive stream work, which is
> partially done in my local tree, but much remains to be done.
>

Thanks for letting me know.  I just need the results, no fancy stream
behavior right now, so I'm wrapping run-program up in a function that
writes to a file, and reads the results into a string.  Not pretty,
but it gets the job done.

-Ben

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV