[cmucl-help] Re: Another spurious compilation diagnostic?

[Madhu]

* Steven Edwards <[EMAIL PROTECTED]> :
Wrote on Wed, 24 Sep 2008 14:05:22 -0400:

| Well, it may have been over 32 KB; I'm not sure.  In any case, only
| the first 1,024 bytes (or so) made it in.
|
| The expression:
|
|   (read-line (cpc-stin cpc) nil nil)
|
| Where (cpc-stin cpc) was explicitly set to *terminal-io*, and the
| input is being done from a terminal.
|
| It looks like every input test with less than about 1 KB works okay.


Were you pasting text via X (say by pasting the primary selection
through a mouseclick to CMUCL running in a  terminal?)

I'm asking to check if there are limits involved before cmucl gets to
the text

With cmucl running in an xterm I seem to have a  4k limit on the size of
the string I can paste to the repl which is running 
(read-line t nil nil)

--
Madhu

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

Well, it may have been over 32 KB; I'm not sure.  In any case, only  
the first 1,024 bytes (or so) made it in.


The expression:

  (read-line (cpc-stin cpc) nil nil)

Where (cpc-stin cpc) was explicitly set to *terminal-io*, and the  
input is being done from a terminal.


It looks like every input test with less than about 1 KB works okay.

== Steven


On Sep 24, 2008, at 1:34 PM, Raymond Toy wrote:


Steven Edwards wrote:

Oh, and one more thing: It looks like read-line has a 1,024 character
line length limit.  This isn't so bad, but it also appears to  
sometimes

hang when presented with some 30 KB of no-newline text at a time.


There used to be some limit like this but it was fixed long ago.  I
can't reproduce this.  Can you give an example of this failure?  I
created a file with 3 characters and a new line.  read-line  
reads in

this line without problems.

[cmucl-help] Re: Another spurious compilation diagnostic?

[Raymond Toy]

Steven Edwards wrote:
> Oh, and one more thing: It looks like read-line has a 1,024 character
> line length limit.  This isn't so bad, but it also appears to sometimes
> hang when presented with some 30 KB of no-newline text at a time.

There used to be some limit like this but it was fixed long ago.  I
can't reproduce this.  Can you give an example of this failure?  I
created a file with 3 characters and a new line.  read-line reads in
this line without problems.

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

Thank you for your reply.

Areas of the project are mutating at a significant rate, so it may be  
that the diagnostics will have changed or be eliminated by the release.


But as I've written, I'm sure there will be plenty of fun then.

Oh, and one more thing: It looks like read-line has a 1,024 character  
line length limit.  This isn't so bad, but it also appears to  
sometimes hang when presented with some 30 KB of no-newline text at a  
time.


== Steven


On Sep 24, 2008, at 1:00 PM, Raymond Toy wrote:


Steven Edwards wrote:

At 13 KLoC, it's a bit unwieldily.  But I hope to release the whole
source soon (ca. 1-2 months).  There will lots of fun then.


I didn't mean for you to send over everything.  But if you could  
extract
out some small bits, that would be useful.  Otherwise I'll wait for  
the

release and maybe (probably not?) look at it then.

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Raymond Toy]

Steven Edwards wrote:
> At 13 KLoC, it's a bit unwieldily.  But I hope to release the whole
> source soon (ca. 1-2 months).  There will lots of fun then.

I didn't mean for you to send over everything.  But if you could extract
out some small bits, that would be useful.  Otherwise I'll wait for the
release and maybe (probably not?) look at it then.

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

At 13 KLoC, it's a bit unwieldily.  But I hope to release the whole  
source soon (ca. 1-2 months).  There will lots of fun then.



On Sep 24, 2008, at 9:45 AM, Raymond Toy wrote:


Steven Edwards wrote:

Thank you for your assistance.

It looks like you are correct.  However, while the compiler may be
smart, it's not smart enough to see that there's a secondary guard
variable that prevents any access of the list-length result if the
argument is nil.  The same goes for the when evaluation.


It would be useful if you could extract that part out for us to look  
at.

Perhaps there's a bug in the compiler.

[cmucl-help] Re: Another spurious compilation diagnostic?

[Raymond Toy]

Steven Edwards wrote:
> Thank you for your assistance.
> 
> It looks like you are correct.  However, while the compiler may be
> smart, it's not smart enough to see that there's a secondary guard
> variable that prevents any access of the list-length result if the
> argument is nil.  The same goes for the when evaluation.

It would be useful if you could extract that part out for us to look at.
 Perhaps there's a bug in the compiler.

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

Thank you for your assistance.

It looks like you are correct.  However, while the compiler may be  
smart, it's not smart enough to see that there's a secondary guard  
variable that prevents any access of the list-length result if the  
argument is nil.  The same goes for the when evaluation.


== Steven


On Sep 23, 2008, at 2:12 AM, Madhu wrote:


[pardon the top post, if you find it inappropriate]

The CLHS entry for LIST-LENGTH says:

,
| Returns the length of list if list is a proper list. Returns nil if
| list is a circular list.
`

This means one of the possible return values is NIL.  The compiler
diagnostics seem to indicate that it has inferred that the value
returned by LIST-LENGTH are used only in number contexts.

The compiler is warning you that there will be an error in the event
LIST-LENGTH returns NIL.

I suspect the case with the other diagnostic is similar. It is likely
you are using the return value of a (WHEN clause) where the compiler
always expects a number.

Both of these deal with the specifics of your code , so it is likely
the compiler knows better (as it has access to the code) than us (who
dont:)

[cmucl-help] Re: Another spurious compilation diagnostic?

[Madhu]

[pardon the top post, if you find it inappropriate]

The CLHS entry for LIST-LENGTH says:

,
| Returns the length of list if list is a proper list. Returns nil if
| list is a circular list.
`

This means one of the possible return values is NIL.  The compiler
diagnostics seem to indicate that it has inferred that the value
returned by LIST-LENGTH are used only in number contexts.

The compiler is warning you that there will be an error in the event
LIST-LENGTH returns NIL.

I suspect the case with the other diagnostic is similar. It is likely
you are using the return value of a (WHEN clause) where the compiler
always expects a number.

Both of these deal with the specifics of your code , so it is likely
the compiler knows better (as it has access to the code) than us (who
dont:)

* Steven Edwards  
| This might help:
|
| The problem occurs when the (list-length foobar) expression appears as  
| the right hand side of a variable binding in a let* list.
|
| A perhaps related spurious diagnostic also appears in the same let*  
| context (but in different lets):
|
| ;   (WHEN INLINE-FLAG
| ; (FETCH-DIR PAS-KING-SQ FR-SQ))
| ; --> COND IF
| ; ==>
| ;   (COND)
| ; Warning: This is not a (VALUES &OPTIONAL (MOD 536870911) &REST T):
| ;   NIL
| ; ; [Last message occurs 2 times]
|
| The above COND IF NIL stuff must be from a cmucl macro expansion as  
| it's not in the user source.
|
| I note that the resulting compiled object code for all of the spurious  
| warning cases runs fine as does the interpreted code version.  Same  
| for the clisp and gcl processors.
|
| == Steven
|
|
| On Sep 22, 2008, at 7:58 PM, Raymond Toy wrote:
|
|> Steven Edwards wrote:
|>> Greetings again, list readers:
|>>
|>> It seems that every time I compile something like:
|>>
|>>  (list-length some-random-list)
|>>
|>> I get a compiler warning:
|>>
|>> ;   (LIST-LENGTH SOME-RANDOM-LIST)
|>> ; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN
|>> ; ==>
|>> ;   (RETURN-FROM NIL NIL)
|>> ; Warning: This is not a (VALUES &OPTIONAL REAL &REST T):
|>> ;   NIL
|>> ; ; [Last message occurs 2 times]
|>>
|>> Any ideas?
|>>
|> I can't reproduce this.  What version of cmucl?  Can you provide a
|> complete example that shows this?
|>
|> Thanks,
|>
|> Ray


--
Madhu

[cmucl-help] Re: Another spurious compilation diagnostic?

[Madhu]

   [pardon the top post, if you find it inappropriate]

The CLHS entry for LIST-LENGTH says:

,
| Returns the length of list if list is a proper list. Returns nil if
| list is a circular list.
`

This means one of the possible return values is NIL.  The compiler
diagnostics seem to indicate that it has inferred that the value
returned by LIST-LENGTH are used only in number contexts.

The compiler is warning you that there will be an error in the event
LIST-LENGTH returns NIL.

I suspect the case with the other diagnostic is similar. It is likely
you are using the return value of a (WHEN clause) where the compiler
always expects a number.

Both of these deal with the specifics of your code , so it is likely
the compiler knows better (as it has access to the code) than us (who
dont:)

* Steven Edwards <[EMAIL PROTECTED]> :
Wrote on Mon, 22 Sep 2008 22:57:40 -0400:

| This might help:
|
| The problem occurs when the (list-length foobar) expression appears as
| the right hand side of a variable binding in a let* list.
|
| A perhaps related spurious diagnostic also appears in the same let*
| context (but in different lets):
|
| ;   (WHEN INLINE-FLAG
| ; (FETCH-DIR PAS-KING-SQ FR-SQ))
| ; --> COND IF
| ; ==>
| ;   (COND)
| ; Warning: This is not a (VALUES &OPTIONAL (MOD 536870911) &REST T):
| ;   NIL
| ; ; [Last message occurs 2 times]
|
| The above COND IF NIL stuff must be from a cmucl macro expansion as
| it's not in the user source.
|
| I note that the resulting compiled object code for all of the spurious
| warning cases runs fine as does the interpreted code version.  Same
| for the clisp and gcl processors.
|
| == Steven
|
|
| On Sep 22, 2008, at 7:58 PM, Raymond Toy wrote:
|
|> Steven Edwards wrote:
|>> Greetings again, list readers:
|>>
|>> It seems that every time I compile something like:
|>>
|>>  (list-length some-random-list)
|>>
|>> I get a compiler warning:
|>>
|>> ;   (LIST-LENGTH SOME-RANDOM-LIST)
|>> ; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN
|>> ; ==>
|>> ;   (RETURN-FROM NIL NIL)
|>> ; Warning: This is not a (VALUES &OPTIONAL REAL &REST T):
|>> ;   NIL
|>> ; ; [Last message occurs 2 times]
|>>
|>> Any ideas?
|>>
|> I can't reproduce this.  What version of cmucl?  Can you provide a
|> complete example that shows this?
|>
|> Thanks,
|>
|> Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

This might help:

The problem occurs when the (list-length foobar) expression appears as  
the right hand side of a variable binding in a let* list.


A perhaps related spurious diagnostic also appears in the same let*  
context (but in different lets):


;   (WHEN INLINE-FLAG
; (FETCH-DIR PAS-KING-SQ FR-SQ))
; --> COND IF
; ==>
;   (COND)
; Warning: This is not a (VALUES &OPTIONAL (MOD 536870911) &REST T):
;   NIL
; ; [Last message occurs 2 times]

The above COND IF NIL stuff must be from a cmucl macro expansion as  
it's not in the user source.


I note that the resulting compiled object code for all of the spurious  
warning cases runs fine as does the interpreted code version.  Same  
for the clisp and gcl processors.


== Steven


On Sep 22, 2008, at 7:58 PM, Raymond Toy wrote:


Steven Edwards wrote:

Greetings again, list readers:

It seems that every time I compile something like:

 (list-length some-random-list)

I get a compiler warning:

;   (LIST-LENGTH SOME-RANDOM-LIST)
; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN
; ==>
;   (RETURN-FROM NIL NIL)
; Warning: This is not a (VALUES &OPTIONAL REAL &REST T):
;   NIL
; ; [Last message occurs 2 times]

Any ideas?


I can't reproduce this.  What version of cmucl?  Can you provide a
complete example that shows this?

Thanks,

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Raymond Toy]

Steven Edwards wrote:
> Greetings again, list readers:
>
> It seems that every time I compile something like:
>
>   (list-length some-random-list)
>
> I get a compiler warning:
>
> ;   (LIST-LENGTH SOME-RANDOM-LIST)
> ; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN
> ; ==>
> ;   (RETURN-FROM NIL NIL)
> ; Warning: This is not a (VALUES &OPTIONAL REAL &REST T):
> ;   NIL
> ; ; [Last message occurs 2 times]
>
> Any ideas?
>
I can't reproduce this.  What version of cmucl?  Can you provide a
complete example that shows this?

Thanks,

Ray

[cmucl-help] Re: Another spurious compilation diagnostic?

[Steven Edwards]

Here's the banner:

CMU Common Lisp 19e (19E), running on gail
With core: /Users/sje/cmucl-19e-x86-darwin/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2008-05-01 20:38:02-04:00 on macmini
See  for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47

Alas, the original source is way too big to post.


On Sep 22, 2008, at 7:58 PM, Raymond Toy wrote:


Steven Edwards wrote:

Greetings again, list readers:

It seems that every time I compile something like:

 (list-length some-random-list)

I get a compiler warning:

;   (LIST-LENGTH SOME-RANDOM-LIST)
; --> BLOCK DO BLOCK LET TAGBODY WHEN COND IF PROGN RETURN
; ==>
;   (RETURN-FROM NIL NIL)
; Warning: This is not a (VALUES &OPTIONAL REAL &REST T):
;   NIL
; ; [Last message occurs 2 times]

Any ideas?


I can't reproduce this.  What version of cmucl?  Can you provide a
complete example that shows this?

Thanks,

Ray