Camillo Bruni-3 wrote
>
> 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
>
Ha ha... yes, I've noticed that too :) Also, the unintended consequences
when people start to use 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
> 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
On Thu, Jun 14, 2012 at 3:19 PM, Denis Kudriashov wrote:
> I am very very want it:)
I guess the question was not "who would like this?" but more "who will
take the lead and make it happen?"
To you or Nicolas want to take the lead and make it happen?
--
Damien Cassou
http://damiencassou.seaside
2012/6/14 Stéphane Ducasse
> 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:)
Stéphane Ducasse writes:
> 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?
Me.
Nico
>
> Stef
>
> Tx
>
> now there is a difference between adjustments and f
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?
>>
>
> 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
>>>
>> +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 brea
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?
Stef
Tx
now there is a difference between adjustments and fully new API and I
would have preferred adjus
2012/6/14 Henrik Sperre Johansen :
> On 14.06.2012 08:43, Igor Stasenko wrote:
>>
>> On 14 June 2012 08:33, Stéphane Ducasse wrote:
>>>
>>> Tx
>>>
>>> now there is a difference between adjustments and fully new API and I
>>> would have preferred adjustments.
>>>
>>> Stef
>>
>> IMO, Xtreams design
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
On 13 June 2012 23:11, Frank Shearar wrote:
> On 13 June 2012 20:25, Stéphane Ducasse 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
>
On 14.06.2012 08:43, Igor Stasenko wrote:
On 14 June 2012 08:33, Stéphane Ducasse 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 Str
On Wed, Jun 13, 2012 at 6:09 PM, wrote:
>> Now Damien, if streaming is only intended for arrays and strings, I'd
>> expect the expression 'OrderedCollection new writeStream' to raise an
>> error... :/
agree, that should be fixed
> Indeed. Also, just for my information, why aren't we using Nil
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
On 14 June 2012 08:33, Stéphane Ducasse 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
Tx
now there is a difference between adjustments and fully new API and I would
have preferred adjustments.
Stef
On Jun 14, 2012, at 12:11 AM, Frank Shearar wrote:
> On 13 June 2012 20:25, Stéphane Ducasse wrote:
>> I would have really prefer that Xtreams provide a compatible API.
>> Because
On 13 June 2012 20:25, Stéphane Ducasse 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 prot
Hi
I try it on Pharo1.4 - all tests green.
http://www.squeaksource.com/Xtreams.html page contains gofer scripts.
Without last ffi packages (for VW I thing) all are loadable and work good.
2012/6/13 Stéphane Ducasse
> I would have really prefer that Xtreams provide a compatible API.
> Because c
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
> I
By the way,
OrderedCollection new writing
write: ({1. 2. 3.} as: OrderedCollection);
conclusion
2012/6/13 Nicolas Cellier :
> 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 compo
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
And why no Xtreams?
2012/6/13
> Guillermo Polito 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 expr
Guillermo Polito 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
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... :/
On Wed, Jun 13
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:, et
On Wed, Jun 13, 2012 at 2:56 PM, Guillermo Polito
wrote:
> oc := OrderedCollection new.
> ws := oc writeStream.
streaming over an OrderedCollection is officially not supported for
standard streams (see http://scg.unibe.ch/scgbib?query=Cass09a for
details). You can only stream over an Array or Str
soo, what do I do? :D
On 6/13/12, Camillo Bruni 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 / Symbo
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)
- over
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
30 matches
Mail list logo
