[Pharo-project] WriteStream, nextPutAll:, OrderedCollections

Frank Shearar frank.shearar at gmail.com
Thu Jun 14 06:19:01 EDT 2012


On 13 June 2012 23:11, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 13 June 2012 20:25, Stéphane Ducasse <Stephane.Ducasse at inria.fr> wrote:
>> I would have really prefer that Xtreams provide a compatible API.
>> Because changing API means also rewrite documentation….
>
> If I recall correctly, Michael & Martin said that it was impossible to
> provide a compatible API because the ANSI Stream protocol was
> fundamentally broken in a few key ways. I forget the details though,
> sadly.
>
>> Nicolas else did you get Xtream working well in Pharo?
>
> It should work just fine. As I recall there wasn't much adjustment
> necessary for Squeak (but of course Nicolas would know better than
> anyone!).

As it happens, the latest ConfigurationOfXtreams fails to load in
Pharo 1.4. ConfigurationOfXtreams class >> #bootstrapPackage:from:
tries to load ConfigurationOfMetacello-dkh.674 from SqueakSource. SS
doesn't have that version, so #bootstrapPackage:from:'s caller,
#ensureMetacello, should retry, and fetch the version from Metacello's
canonical repository. In Squeak this works, but not in Pharo. I'm
unsure why, unless it's just that Zinc+Monticello behaves differently
in Pharo than in Squeak.

Xtreams uses FFI and in Pharo-1.4 there's a single test failure, in
FFIPluginTests >> #testBlitToAndFromExternalForm because Form class
doesn't understand #makeStar.

However, Xtreams' tests are green in Pharo 1.4!

> frank
>
>> Because we will nearly killed all the old FileDirectory code. So stream would be good candidate to clean too.
>> Stef
>>
>>
>>> If it's about switching to a clean library maximizing the power of
>>> composition use Xtreams.
>>> If it's about maximizing compatibility, use Nile. The composition in
>>> Nile is done via Traits, this is interesting but spectrum is quite
>>> narrow. Nile also introduces lazy streams and filters, but this is
>>> less systematic than Xtreams, because the main goal was to replace
>>> legacy Stream, innovation being secondary.
>>>
>>> Of course, in the first case, you break a lot of clients because
>>> design decision is to change the whole API and force a rewrite.
>>> So you must have a long transition phase maintaining legacy Streams
>>>
>>> And in second case, you can eliminate the legacy streams more rapidly
>>> and just replace them with Nile, but you still carry some cruft,
>>> compatibility oblige...
>>>
>>> Not an easy choice, but you can guess my opinion ;)
>>>
>>> Nicolas
>>>
>>> 2012/6/13 Denis Kudriashov <dionisiydk at gmail.com>:
>>>> And why no Xtreams?
>>>>
>>>> 2012/6/13 <petton.nicolas at gmail.com>
>>>>
>>>>> Guillermo Polito <guillermopolito at gmail.com> writes:
>>>>>
>>>>>> Ok, just was expecting (very very deeply) not having to modify too
>>>>>> much in Glorp :). Anyway, I'll see what can I do in this front.
>>>>>>
>>>>>> Now Damien, if streaming is only intended for arrays and strings, I'd
>>>>>> expect the expression 'OrderedCollection new writeStream' to raise an
>>>>>> error... :/
>>>>>
>>>>> Indeed. Also, just for my information, why aren't we using Nile?
>>>>>
>>>>> Nico
>>>>>
>>>>>>
>>>>>> On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves at elte.hu> wrote:
>>>>>>
>>>>>>    On Wed, 13 Jun 2012, Guillermo Polito wrote:
>>>>>>
>>>>>>        soo, what do I do? :D
>>>>>>
>>>>>>
>>>>>>
>>>>>>    Streaming into an OrderedCollection is unnecessary, because
>>>>>>    OrderedCollection is already a stream-like object. If I were
>>>>>>    implementing Smalltalk now, I would probably add the stream
>>>>>>    protocol to it (#nextPut:, #nextPutAll:, etc).
>>>>>>    A simple fix to your problem is to replace the line
>>>>>>
>>>>>>           grownCollection := collection class new: newSize.
>>>>>>
>>>>>>    with
>>>>>>
>>>>>>           grownCollection := collection class ofSize: newSize.
>>>>>>
>>>>>>    in WriteStream >> #growTo: (note that I didn't check current Pharo
>>>>>>    code, so this might be different there).
>>>>>>
>>>>>>
>>>>>>    Levente
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>        On 6/13/12, Camillo Bruni <camillobruni at gmail.com> wrote:
>>>>>>
>>>>>>        yup I know that :D
>>>>>>            And I provided a fix on e year ago, that got lost in a big
>>>>>>            refactoring...
>>>>>>            - I added an explicit #streamSpecies on the Collection
>>>>>>            classes.
>>>>>>            - By default it returns the same class
>>>>>>            - on Set / OrderedCollection / Symbol it returns the
>>>>>>            mutable types
>>>>>>            (LinkedList as well I think)
>>>>>>            - overwrote #streamContents: to convert from the
>>>>>>            #streamSpecies type back to
>>>>>>            the original class
>>>>>>
>>>>>>
>>>>>>
>>>>>>            On 2012-06-13, at 14:56, Guillermo Polito wrote:
>>>>>>
>>>>>>                        Hi guys!
>>>>>>
>>>>>>                I'm chasing a bug that appeared in glorp under pharo
>>>>>>                1.4.  Now, the
>>>>>>                bug is due to some behavior changed in
>>>>>>                OrderedCollection I think. Look
>>>>>>                at this piece of code:
>>>>>>
>>>>>>
>>>>>>                oc := OrderedCollection new.
>>>>>>                ws := oc writeStream.
>>>>>>
>>>>>>                "this explodes"
>>>>>>                ws nextPutAll: (OrderedCollection with: 1 with: 2
>>>>>>                with: 3).
>>>>>>
>>>>>>                "this works"
>>>>>>                ws nextPutAll: {1.2.3}
>>>>>>
>>>>>>
>>>>>>                And I'm puzzled, why should one work and the other not
>>>>>>                from the pov of the
>>>>>>                user?
>>>>>>                And how should I replace that behavior if it's my bug?
>>>>>>
>>>>>>                putting an asArray for each nextPutAll: does not look
>>>>>>                good for me... :S
>>>>>>
>>>>>>                Tx,
>>>>>>                Guille
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Nicolas Petton
>>>>> http://nicolas-petton.fr
>>>>>
>>>>
>>>
>>
>>




More information about the Pharo-dev mailing list