Seaside-Core-topa.811
Locked
Seaside-Core-topa.811
 
|
Re: Seaside-Core-topa.811
|
|
Hey,
On 06.04.2014, at 19:13, Philippe Marschall <[hidden email]> 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. The way this method was written did not cope for the underlying stream/stream’s collection to change. The test will fail in mostly any squeak out there (except trunk [1]). Yet, we can only be sure that a) the preallocated size is correct and 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…) Even if the #== in GemStone would fail[2], the failsafe method I added will always work, although potentially create a copy. I find it hard to come up with a dedicated test for that except for what already is done in WAUtf8UrlTest>>#testPathStringUnencoded (the one that triggered all that for me). If you need one, i try to come up with one. (note that I have no VA or VW to test with and are mostly stuck with Squeak/Pharo/Gemstone…) HTH Best -Tobias [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-March/177658.html [2] Which I suspect, do not, since classes all over the place are checked with #~~, but I actually did not test it (shame on me) _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
signature.asc (1K)
Re: Seaside-Core-topa.811
|
|
Re: Seaside-Core-topa.811
|
|
Hey,
On 06.04.2014, at 21:58, Philippe Marschall <[hidden email]> wrote: > On Sun, Apr 6, 2014 at 8:44 PM, Tobias Pape <[hidden email]> wrote: >> Hey, >> >> On 06.04.2014, at 19:13, Philippe Marschall <[hidden email]> 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. 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. >> 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. 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. I mean, it wouldn't work after all if you used ByteArray and numbers >256 here. The case would be the same. > >> Even if the #== in GemStone would fail[2], the failsafe method I >> added will always work, although potentially create a copy. >> >> >> I find it hard to come up with a dedicated test for that except for what >> already is done in WAUtf8UrlTest>>#testPathStringUnencoded (the one that >> triggered all that for me). > > If that failed then that's fine. > Which version of Squeak was that 4.4? 4.5? Both. Squeak Trunk is save-ish. Best -Tobias _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Seaside-Core-topa.811
|
|
Re: Seaside-Core-topa.811
|
|
On 07.04.2014, at 12:18, Philippe Marschall <[hidden email]> wrote: On Sun, Apr 6, 2014 at 10:17 PM, Tobias Pape <[hidden email]> wrote: Hey, On 06.04.2014, at 21:58, Philippe Marschall <[hidden email]> wrote: On Sun, Apr 6, 2014 at 8:44 PM, Tobias Pape <[hidden email]> wrote: Hey, On 06.04.2014, at 19:13, Philippe Marschall <[hidden email]> 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 _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Seaside-Core-topa.811
|
|
Re: Seaside-Core-topa.811
|
|
On 07.04.2014, at 17:43, Philippe Marschall <[hidden email]> wrote: > On Mon, Apr 7, 2014 at 3:30 PM, Tobias Pape <[hidden email]> wrote: >> >> On 07.04.2014, at 12:18, Philippe Marschall <[hidden email]> wrote: >> >> On Sun, Apr 6, 2014 at 10:17 PM, Tobias Pape <[hidden email]> wrote: >> Hey, >> >> On 06.04.2014, at 21:58, Philippe Marschall <[hidden email]> wrote: >> >> On Sun, Apr 6, 2014 at 8:44 PM, Tobias Pape <[hidden email]> wrote: >> Hey, >> >> On 06.04.2014, at 19:13, Philippe Marschall <[hidden email]> 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. > > I see. > >> 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? > > species or class I'm not sure which one. > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: Seaside-Core-topa.811
|
|
| Free forum by Nabble | Edit this page |