[Seaside-dev] Seaside-Core-topa.811

[Tobias Pape]

On 07.04.2014, at 12:18, Philippe Marschall <philippe.marschall at gmail.com> wrote:

On Sun, Apr 6, 2014 at 10:17 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
Hey,

On 06.04.2014, at 21:58, Philippe Marschall <philippe.marschall at gmail.com> wrote:

On Sun, Apr 6, 2014 at 8:44 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
Hey,

On 06.04.2014, at 19:13, Philippe Marschall <philippe.marschall at gmail.com> wrote:

Hi

Can you elaborate a bit on the problem?
Can you supply some tests?
Will this work on GemStone (comparing classes with #==)?

This is a strange thing no matter how we look at it.

#pathStringUnencoded states
"allocate with correct size, avoid copy"

However, it is working on strings that potentially contain
unicode stuff.

So?

The way this method was written did not cope for
the underlying stream/stream’s collection to change.

How so? The type of collection should not have an influence on the
semantics of #size and if the kind is changed then #becomeForward: is
used and the collection is replaced in place.

If we were operating on a string, directly, yes.
But can we _Really_ know this for a stream? A stream can do on
its collection what it wants.


The test will
fail in mostly any squeak out there (except trunk [1]).

Why?


Because when using a write stream on a byte string and putting
a wide character onto it, the write stream would pro-actively
replace its own underlying collection with a wide one, _NOT_ doing
a #becomeForward:/#become: at all.

I see. Is that relatively new change in Squeak?

No, it is that way since 2005 at least.
Actually, I changed it so that now #becomeForward: is used.


Yet, we can only be sure that
a) the preallocated size is correct and

This is always the case.
b) the #pathUnencodedOn: will not change the collection kind
if all path segments are of the same kind (Byte/Wide in Squeak/Pharo
or one of the equivalent Unicode classes in GemStone…)

Um no. The type of collection still changes if all the elements are
made of WideString in Squeak/Pharo because the initial allocation will
be done with String new: which gives a ByteString instance which will
later change to a WideString.

But you cannot be sure to get the collection back you put in (see above).
I also do not think that this is the contract of WriteStream.

I asked a few long-time smalltalkers who said they would not expect the underlying
collection to stay the same if you put not-directly-compatible things in there.

Right. But then I would expect the fix to fail if all of the path
elements are WideString. The test would assume that it's safe since
all elements are of the same class but WriteStream will change the
collection anyways.

Hmph, yes, correct.
The inital collection should take the species of the first element of the stream
then, right?


I mean, it wouldn't work after all if you used ByteArray and numbers >256 here.
The case would be the same.
[...]
Both.
Squeak Trunk is save-ish.

Does that mean Squeak Trunk has the same behavior as Pharo or that I
should be able to work with Squeak Trunk without stuff blowing up in
my face?

The former.

Best
	-Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1625 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20140407/6b7724ad/signature.pgp