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@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

Guillermo Polito <guillermopolito@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@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@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

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@gmail.com>:

And why no Xtreams?

2012/6/13 <petton.nicolas@gmail.com>

...

Guillermo Polito <guillermopolito@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@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@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

I would have really prefer that Xtreams provide a compatible API. Because changing API means also rewrite documentation…. Nicolas else did you get Xtream working well in Pharo? 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@gmail.com>:

...

And why no Xtreams?

2012/6/13 <petton.nicolas@gmail.com>

...

Guillermo Polito <guillermopolito@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@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@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

On 13 June 2012 20:25, Stéphane Ducasse <Stephane.Ducasse@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!). 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@gmail.com>:

...

And why no Xtreams?

2012/6/13 <petton.nicolas@gmail.com>

...

Guillermo Polito <guillermopolito@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@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@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

On 14 June 2012 08:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Tx

now there is a difference between adjustments and fully new API and I would have preferred adjustments.

Stef

IMO, Xtreams design is simply superior. But i agree, we cannot throw existing streams out.. too much things tied to them, and rely on using stream protocols. :( -- Best regards, Igor Stasenko.

Here is a bit less dumb evaluation of stream protocols, top 100 Stream-messages sent in Pharo2.0 but by Stream: selectors := (Stream withAllSubclasses inject: Set new into: [:allSelectors :aClass | allSelectors addAll: aClass selectors; yourself]) sorted. references := selectors collect: [:e | e -> ((SystemNavigation default allCallsOn: e) reject: [:aRef | (Smalltalk at: (aRef classSymbol readStream upTo: Character space) asSymbol) inheritsFrom: Stream]) size ]. (references sorted: [:a :b | a value > b value ]) first: 100. {#=->7340. #size->3817. #do:->2612. #name->1366. #isEmpty->1345. #nextPutAll:->991. #nextPut:->887. #value:->792. #contents->741. #last->679. #cr->666. #initialize->634. #on:->558. #with:->547. #readStream->497. #position->314. #close->275. #white->266. #space->256. #next->245. #black->244. #printOn:->226. #print:->215. #position:->184. #string->175. #lf->171. #atEnd->165. #hash->161. #reset->156. #tab->130. #text->123. #'<<'->120. #open->112. #match:->106. #show:->97. #crlf->93. #binary->91. #confirm:->84. #timeStamp->83. #next:->80. #element->74. #fullName->68. #upToEnd->66. #removeAll->65. #peek->64. #flush->64. #skip:->63. #findFirst:->61. #postCopy->55. #replace:with:->52. #nextChunkPut:->52. #braceArray->52. #isDirectory->49. #fork->49. #url->46. #upTo:->41. #isBinary->40. #nextLine->39. #header->38. #sendCommand:->34. #release->33. #request:->32. #nextChunk->30. #uri->29. #store:->29. #directory->28. #peekFor:->26. #setToEnd->24. #crtab:->24. #trailer->23. #nextChunkText->23. #skipSeparators->21. #asUrl->20. #initialize:->19. #upToAll:->18. #textStyle->18. #unregister->16. #readOnlyCopy->16. #localName->16. #register->15. #nextOrNil->15. #fileIn->15. #objectAt:->14. #crtab->14. #contentsOfEntireFile->14. #clear->14. #on:limit:->13. #nextChar->13. #findString:->13. #write:->12. #skipTo:->12. #converter->12. #string:->11. #nextWord->11. #next:putAll:startingAt:->11. #initializeOn:->11. #endEntry->11. #converter:->11. #basicNextPut:->11. #basicNext->11} - Some should be removed due to false polymorphism - Some should be isolated because specific (TranscriptStream, Generator, Transcripter ...) - Some should be removed thanks to a rewrite of bloated converters (basic*) But this give an idea of main protocol usage in image. As for 3rd party packages, this is another story... But Pharo is in a better position than Squeak for such hard decisions. Nicolas 2012/6/14 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

I would address the problem with a compatibility layer like     'foo' reading withLegacyProtocol You have many options to add a protocol - simply add the protocol at XTReadStream/XTWriteSTream roots - just create another Xtreams wrapper, - use a Trait

I wish I had lightweight traits, I mean with traitified classes created on the fly, with a simple naming like XTCollectionReadStream + TLegacyStreamProtocol in case we have to debug it, because this way I could also keep a clean Xtreams hierarchy in parallel with legacy at very low maintenance costs.

However, this is going to be some work for sure, here is a rough measurement:

(Stream withAllSubclasses inject: Set new into: [:allSelectors :aClass | allSelectors addAll: aClass selectors; yourself]) sorted size -> 594

(XTReadStream withAllSubclasses , XTWriteStream withAllSubclasses inject: Set new into: [:allSelectors :aClass | allSelectors addAll: aClass selectors; yourself]) sorted size -> 119

You certainly don't want to support 594 compatibility messages...

Nicolas

2012/6/14 Igor Stasenko <siguctua@gmail.com>:

...

On 14 June 2012 08:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Tx

now there is a difference between adjustments and fully new API and I would have preferred adjustments.

Stef

IMO, Xtreams design is simply superior. But i agree, we cannot throw existing streams out.. too much things tied to them, and rely on using stream protocols. :(

-- Best regards, Igor Stasenko.

2012/6/14 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>:

On 14.06.2012 08:43, Igor Stasenko wrote:

...

On 14 June 2012 08:33, Stéphane Ducasse<stephane.ducasse@inria.fr>  wrote:

...

Tx

now there is a difference between adjustments and fully new API and I would have preferred adjustments.

Stef

IMO, Xtreams design is simply superior.

+100. I gave up on trying to mold the current Streams into something a bit more reasonable and still be backwards compatible quite some time ago.

That other thread about Converters? Totally related. For example, you can't do what Sven did in the Zn converters without breaking backwards compatability. Nor could you do it reasonably fast in the general case, since fast string -> bytearray streaming works for some streams, but not for others. (which, I guess, is one reason why the legacy converters do string -> string.)

IMHO, Xtreams would be a perfect fit to go with the new FileSystem as well. (using compositing on top of a "dumb" terminal)

Quite sure that it is highly ranked in Colin's plans.

...

But i agree, we cannot throw existing streams out.. too much things tied to them, and rely on using stream protocols. :(

Well, one*could* try to introduce something akin to the Zn HTTPClient compatability protocol, strictly speaking what you can do with Xtreams is a superset of what Streams currently do. The problem is all the moronic quirks of the current Streams, and clients potentially relying on that behaviour.

Cheers, Henry

I would also really like to have a chapter based on the documentation (if any).

If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that?

2012/6/14 Stéphane Ducasse <stephane.ducasse@inria.fr>

If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that?

I am very very want it:)

Ok so join forces and propose something. On Jun 14, 2012, at 3:19 PM, Denis Kudriashov wrote:

2012/6/14 Stéphane Ducasse <stephane.ducasse@inria.fr> If one group of guys would take the lead we could introduce XTream in 2.0 and slowly start to integrate and deprecate slowly the old streams. Who is interested in that?

I am very very want it:)

...

Indeed, with the new FS being almost ready in 2.0 the next big mess to tackle are the streams.

Personally I really liked the clean separation of the low level stream features (bytes) and the high-level interfaces to it (converters, characters...)

but the question remains on how to integrate them into a running system ;)

after having done the FS take-over I see that it's rather easy to create an image that works with the replaced classes. But creating a nice loadable slice / changeset is a rather fragile and tedious task :P

We can just have dedicated sprints. I think that tomorrow I would like to finish with you the FS part. Then I would not open the Xtreams work now but plan it. Stef

On 13 June 2012 23:11, Frank Shearar <frank.shearar@gmail.com> wrote:

On 13 June 2012 20:25, Stéphane Ducasse <Stephane.Ducasse@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@gmail.com>:

...

And why no Xtreams?

2012/6/13 <petton.nicolas@gmail.com>

...

Guillermo Polito <guillermopolito@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@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@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