Smalltalk › Cincom › VisualWorks

[VW 7.7 NC] Bug: StandardIOStream>>atEnd returns wrong value

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Alan Darlington

[VW 7.7 NC] Bug: StandardIOStream>>atEnd returns wrong value

I ran into this problem while moving an application from 7.6 to 7.7 in Windows Vista. This application uses Vista's robocopy utility to copy a directory tree.

In 7.7, this crashes with the error "Unhandled exception: Strings only store Characters". A simple test case for this error is running

WinProcess new cshOne: 'robocopy /e C:\CshTest\Folder1 C:\CshTest\Folder2'

in a workspace, where Folder1exists but Folder2 does not.

On investigating, I found that in Stream>>upToEnd, "self atEnd" returns false while the next "self next" returns nil. My assumption is that StandardIOStream>>atEnd is the guilty party, but it looks messy, and I am not up to investigating further.

This might be related to switching WinProcess>>cshOne: from returning a MSCP1252String (7.6) to returning a TwoByteString (7.7) with #'UTF-16' encoding.

Perhaps Cincom could look into this.

Cheers,
Alan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Darlington

Re: [VW 7.7 NC] Bug: StandardIOStream>>atEnd returns wrong value

For what it's worth, I was able to work around this problem with the following code:

WinProcess new fork: 'robocopy' arguments:
(Array with: '/e' with: 'C:\CshTest\Folder1' with: 'C:\CshTest\Folder2').

It returns the same string that cshOne: does in VWNC 7.6.

-- Alan

From: Alan Darlington <[hidden email]>
To: VWNC List <[hidden email]>
Sent: Sun, February 7, 2010 3:34:05 PM
Subject: [vwnc] [VW 7.7 NC] Bug: StandardIOStream>>atEnd returns wrong value

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-3

Re: [VW 7.7 NC] Bug: StandardIOStream>>atEnd returns wrong value

In reply to this post by Alan Darlington

Yes, this is very likely related to the interpretation of the output. Either running without the UTF16 encoding on the VisualWorks side, or using the /UNICODE flag on robocopy would correct this.

At 06:34 PM 2010-02-07, Alan Darlington wrote:

I ran into this problem while moving an application from 7.6 to 7.7 in Windows Vista. This application uses Vista's robocopy utility to copy a directory tree.

In 7.7, this crashes with the error "Unhandled exception: Strings only store Characters". A simple test case for this error is running

WinProcess new cshOne: 'robocopy /e C:\CshTest\Folder1 C:\CshTest\Folder2'

in a workspace, where Folder1exists but Folder2 does not.

On investigating, I found that in Stream>>upToEnd, "self atEnd" returns false while the next "self next" returns nil. My assumption is that StandardIOStream>>atEnd is the guilty party, but it looks messy, and I am not up to investigating further.

This might be related to switching WinProcess>>cshOne: from returning a MSCP1252String (7.6) to returning a TwoByteString (7.7) with #'UTF-16' encoding.

Perhaps Cincom could look into this.

Cheers,
Alan

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc