What is supposed to happen when upToAll: hits the end of stream?

I've got some code looking for a line of "----------------" but at
the very end of the stream it may instead find a line of "=========".
In this case I see this error in version 3.2:

error: Invalid argument nil: must be a Character
SystemExceptions.WrongClass(Exception)>>signal (ExcHandling.st:254)
SystemExceptions.WrongClass class>>signalOn:mustBe: (SysExcept.st:805)
SystemExceptions.WrongClass class>>signalOn:mustBe: (SysExcept.st:801)
String(Object)>>checkIndexableBounds:put: (Object.st:825)
String>>at:put: (String.st:329)
WriteStream>>nextPut: (WriteStream.st:93)
FileStream(Stream)>>upToAll: (Stream.st:264)

The line I was executing was this:
(pipe upToAll: '----------------------------')

The content of the pipe when this was issued was this (sans the quotes) :

"Initial revision
============================================================================="
<end of pipe>

Any ideas on whether this was proper handling or not?  I was hoping
it would return the entire string which is what I think it should
be doing based on reading the docs..
Comments?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Any ideas on whether this was proper handling or not?  I was hoping
> it would return the entire string which is what I think it should
> be doing based on reading the docs..

Looks like a better choice even if the docs said otherwise.

The only small problem is that an incomplete boundary string at the
end would of course be included in the return value.

Thanks,

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, 21 May 2010 05:56:13 +0200, Paolo Bonzini <[hidden email]> wrote:
>> Any ideas on whether this was proper handling or not?  I was hoping
>> it would return the entire string which is what I think it should
>> be doing based on reading the docs..
>
> Looks like a better choice even if the docs said otherwise.
>
> The only small problem is that an incomplete boundary string at the
> end would of course be included in the return value.

Does that mean there's something wrong with the current
implementation of upToAll:?  

-- Rick

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/21/2010 06:12 AM, Rick Flower wrote:
After actually debugging it, the bug is in pipes.  The following patch
fixes it, though I am committing another one that gets rid of the
"atEnd" instance variable completely.

diff --git a/kernel/FileDescr.st b/kernel/FileDescr.st
index 8f1d23f..54c29e2 100644
--- a/kernel/FileDescr.st
+++ b/kernel/FileDescr.st
@@ -740,7 +740,7 @@ do arbitrary processing on the files.'>
  <category: 'initialize-release'>
  self addToBeFinalized.
  access isNil ifTrue: [access := 3].
- atEnd := false
+ atEnd := nil
      ]

      readStream [

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, 21 May 2010 09:16:13 +0200, Paolo Bonzini <[hidden email]> wrote:

Thanks Paolo!  I tried changing the one line above in my 3.2
version of FileDescr.st and rebuilt.. However, now streams appear
to be completely broken.. Is there another piece to the puzzle
perhaps?

Thx!

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Fri, May 21, 2010 at 18:21, Rick Flower <[hidden email]> wrote:
No idea, I tested it very lightly.  Keep an eye on the repository.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/21/2010 06:21 PM, Rick Flower wrote:
How broken exactly?  The patch passes build & regression testing here,
plus it fixes your testcase...

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, 23 May 2010 09:52:24 +0200, Paolo Bonzini <[hidden email]> wrote:

> How broken exactly?  The patch passes build & regression testing here,
> plus it fixes your testcase...

Nevermind.. I had some other issues with my script code and it's
working fine now!  Thanks again!

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 05/25/2010 03:31 AM, Rick Flower wrote:
> On Sun, 23 May 2010 09:52:24 +0200, Paolo Bonzini<[hidden email]>  wrote:
>
>> How broken exactly?  The patch passes build&  regression testing here,
>> plus it fixes your testcase...
>
> Nevermind.. I had some other issues with my script code and it's
> working fine now!  Thanks again!

Ok, pushed, thanks.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk