June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Removing ReferenceStream

by Marcus Denker

On Jun 5, 2012, at 10:18 PM, Mariano Martinez Peck wrote: > Hi guys. Right now ReferenceStream is deprecated, not removed. In another thread, I asked about cleaning DataStream and let it ONLY for Monticello. That way we can really simplify DataStream, remove DiskProxy and much more. For more details see: http://code.google.com/p/pharo/issues/detail?id=6036. Then whoever need a serializer, it can use Fuel which is already integrated. > The problem is that keeping ReferenceStream as deprecated means that it has to run...meaning that I cannot remove nothing but deprecate everything...DataStream has extension methods in about 20 classses...meaning I have to rename 20 protocols from *SystemObject Storage to *Depreacted20. Apart from even more work is needed to keep it "alive". > > So...sometimes it is really hard to keep everything as deprecated. We don't have manpower enough to keep everything 100% deprecated 100% of the time. Fuel works out of the box from Pharo 1.1 to 2.0 so if anybody needs to move data from previous images, he can use Fuel. Not sure how many people is using ReferenceStream but I have been founding bugs in the last years that nobody even reported.. > > So, can I remove ReferenceStream? I think yes. Fuel is very easy to use, so clients can be changed to use Fuel quite quickly. And migration can be done by loading fuel in 1.4 (or 1.3). Marcus -- Marcus Denker -- http://marcusdenker.de

June 6, 2012

Re: [Pharo-project] String printOn: / storeOn:

by Nicolas Cellier

The assumption was that a Smalltalk literal would print itself as a Smalltalk literal. I can't tell if this is a vital feature, and we also have storeOn:... But I can tell you're gonna break a lot of expectations. What are you looking for? Something like C++stream << aString ? Keith Hodge added such support Stream>> << items items putOn: self. ^ self Stream>>putOn:aStream ^aStream nextPutAll: self. Or is it something else? Nicolas 2012/6/5 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2012-06-05, at 22:33, Chris Cunningham wrote: > >> On Tue, Jun 5, 2012 at 12:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> I think that printing on streams could be improved by changing String >> #printOn: to >>> >>> printOn: aStream >>> Â Â Â Â aStream nextPutAll: self >>> >> >> Ah, but if you change it to this, then >> >> Â Â Â String streamContents: [ :s| s print: 'an Object'] >> equals: >> Â Â Â String streamContents: [ :s| s print: Object new ] >> >> That is, from the printed version, you can't tell which one is >> actually a string. Â Which could get weird in Inspectors. > > true :) but the inspector mostly works on the real object so I wouldn't care too much about that :)

June 6, 2012

Re: [Pharo-project] String printOn: / storeOn:

by Camillo Bruni

On 2012-06-05, at 22:33, Chris Cunningham wrote: > On Tue, Jun 5, 2012 at 12:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I think that printing on streams could be improved by changing String >> #printOn: to >> >> printOn: aStream >> aStream nextPutAll: self >> > > Ah, but if you change it to this, then > > String streamContents: [ :s| s print: 'an Object'] > equals: > String streamContents: [ :s| s print: Object new ] > > That is, from the printed version, you can't tell which one is > actually a string. Which could get weird in Inspectors. true :) but the inspector mostly works on the real object so I wouldn't care too much about that :)

June 5, 2012

Re: [Pharo-project] String printOn: / storeOn:

by Chris Cunningham

On Tue, Jun 5, 2012 at 12:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I think that printing on streams could be improved by changing String >> #printOn: to > > printOn: aStream > Â Â Â Â aStream nextPutAll: self > Ah, but if you change it to this, then String streamContents: [ :s| s print: 'an Object'] equals: String streamContents: [ :s| s print: Object new ] That is, from the printed version, you can't tell which one is actually a string. Which could get weird in Inpsectors. -Chris

June 5, 2012

Re: [Pharo-project] Removing ReferenceStream

by Guillermo Polito

On Tue, Jun 5, 2012 at 10:18 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. Right now ReferenceStream is deprecated, not removed. In another > thread, I asked about cleaning DataStream and let it ONLY for Monticello. > That way we can really simplify DataStream, remove DiskProxy and much more. > For more details see: http://code.google.com/p/pharo/issues/detail?id=6036. > Then whoever need a serializer, it can use Fuel which is already > integrated. > The problem is that keeping ReferenceStream as deprecated means that it > has to run...meaning that I cannot remove nothing but deprecate > everything...DataStream has extension methods in about 20 > classses...meaning I have to rename 20 protocols from *SystemObject Storage > to *Depreacted20. Apart from even more work is needed to keep it "alive". > > So...sometimes it is really hard to keep everything as deprecated. We > don't have manpower enough to keep everything 100% deprecated 100% of the > time. Fuel works out of the box from Pharo 1.1 to 2.0 so if anybody needs > to move data from previous images, he can use Fuel. Not sure how many > people is using ReferenceStream but I have been founding bugs in the last > years that nobody even reported.. > > So, can I remove ReferenceStream? > I vote yes. If anyone needs migrate data between pharo 1.x and 2.0, and he can use fuel, then there is no problem at all. But we should document this in a wiki page and say: To migrate apps from pharo 1.x to 2.0 - if you use reference stream, you should use fuel. You can migrate the data with blablabla... - .... There is a saying in spanish "Cuentas claras mantienen la amistad" that I think can be translated in english as "Good fences make good neighbors"... > > thanks > > -- > Mariano > http://marianopeck.wordpress.com > >

June 5, 2012

Re: [Pharo-project] Removing ReferenceStream

by Esteban Lorenzano

+1 On 05/06/2012, at 22:18, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. Right now ReferenceStream is deprecated, not removed. In another thread, I asked about cleaning DataStream and let it ONLY for Monticello. That way we can really simplify DataStream, remove DiskProxy and much more. For more details see: http://code.google.com/p/pharo/issues/detail?id=6036. Then whoever need a serializer, it can use Fuel which is already integrated. > The problem is that keeping ReferenceStream as deprecated means that it has to run...meaning that I cannot remove nothing but deprecate everything...DataStream has extension methods in about 20 classses...meaning I have to rename 20 protocols from *SystemObject Storage to *Depreacted20. Apart from even more work is needed to keep it "alive". > > So...sometimes it is really hard to keep everything as deprecated. We don't have manpower enough to keep everything 100% deprecated 100% of the time. Fuel works out of the box from Pharo 1.1 to 2.0 so if anybody needs to move data from previous images, he can use Fuel. Not sure how many people is using ReferenceStream but I have been founding bugs in the last years that nobody even reported.. > > So, can I remove ReferenceStream? > > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

June 5, 2012

Re: [Pharo-project] Removing ReferenceStream

by Pavel Krivanek

AFAIK there is common consensus that some things will be removed from 2.0 without deprecation. When we offer more than adequate replacement for ReferenceStream in form of Fuel, I think that we can remove it without doubts. -- Pavel On Tue, Jun 5, 2012 at 10:18 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. Right now ReferenceStream is deprecated, not removed. In another > thread, I asked about cleaning DataStream and let it ONLY for Monticello. > That way we can really simplify DataStream, remove DiskProxy and much more. > For more details see: http://code.google.com/p/pharo/issues/detail?id=6036. > Then whoever need a serializer, it can use Fuel which is already integrated. > The problem is that keeping ReferenceStream as deprecated means that it has > to run...meaning that I cannot remove nothing but deprecate > everything...DataStream has extension methods in about 20 classses...meaning > I have to rename 20 protocols from *SystemObject Storage to *Depreacted20. > Apart from even more work is needed to keep it "alive". > > So...sometimes it is really hard to keep everything as deprecated. We don't > have manpower enough to keep everything 100% deprecated 100% of the time. > Fuel works out of the box from Pharo 1.1 to 2.0 so if anybody needs to move > data from previous images, he can use Fuel. Not sure how many people is > using ReferenceStream but I have been founding bugs in the last years that > nobody even reported.. > > So, can I remove ReferenceStream? > > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

June 5, 2012

[Pharo-project] Removing ReferenceStream

by Mariano Martinez Peck

Hi guys. Right now ReferenceStream is deprecated, not removed. In another thread, I asked about cleaning DataStream and let it ONLY for Monticello. That way we can really simplify DataStream, remove DiskProxy and much more. For more details see: http://code.google.com/p/pharo/issues/detail?id=6036. Then whoever need a serializer, it can use Fuel which is already integrated. The problem is that keeping ReferenceStream as deprecated means that it has to run...meaning that I cannot remove nothing but deprecate everything...DataStream has extension methods in about 20 classses...meaning I have to rename 20 protocols from *SystemObject Storage to *Depreacted20. Apart from even more work is needed to keep it "alive". So...sometimes it is really hard to keep everything as deprecated. We don't have manpower enough to keep everything 100% deprecated 100% of the time. Fuel works out of the box from Pharo 1.1 to 2.0 so if anybody needs to move data from previous images, he can use Fuel. Not sure how many people is using ReferenceStream but I have been founding bugs in the last years that nobody even reported.. So, can I remove ReferenceStream? thanks -- Mariano http://marianopeck.wordpress.com

June 5, 2012

[Pharo-project] String printOn: / storeOn:

by Camillo Bruni

I think that printing on streams could be improved by changing String >> #printOn: to printOn: aStream aStream nextPutAll: self because string is special when printing: String streamContents: [ :s| s print: 'asdf'] does NOT equal: String streamContents: [ :s| s nextPutAll: 'asdf' asString ] whereas String streamContents: [ :s| s print: 1] equals: String streamContents: [ :s| s nextPutAll: 1 asString ] so for any other object s nextPutAll: object asString equals s print: object Now the same implication holds for Symbol and most probably this idea is in strong contrast to the blue book :D

June 5, 2012

Re: [Pharo-project] Trouble loading XML RPC

by garduino

Ni Noury: >Actually, I get only tests from xml rpc with your procedure. >I thought there might be a way to get all tests for all required packages, to test their compatibility with >Pharo 2.0 >But, it seems that I have to load them by hand. Ahh, but is not posible to make the load modifying the configurationof? > Any way, I tried on Pharo 2.0. There is the issue of underscores, but this > is no big deal. I should re-check all the code (lot of parts are form older versions). >The good news is that the client side seems to work. At least the tests are green for parts that does not >rely on a local server (XMLRPCTest is red!). >Tests with Flicker do pass. Yes, the client side seems to work ok. Let me polish some more things. >There is however XMLROCDecoderTest>>#testDecoder that fails. The reason is that now Pharo does >take care of nanoseconds, but the encoder does not handle it. >I guess this is not supported in the protocol. Isn't it? So, I propose to fix it but putting nanoseconds to >zero >XMLRPCDateAndTime>>time: t > "set the time portion of the datetime." > time := Time fromSeconds: t seconds truncated Nice catch! I tried and Works ok. I think that will not generate any problem with the protocol. I can publish with some things I'm improving in the code if you agree. By other hand, the Transcript error at load time, have you experienced it? Is something related with some new thing in 1.4 ? I've not checked yet. Cheers and thanks by the cooperation! -- View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633389.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 5, 2012