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

[Pharo-project] Issues ready for review

by Sean P. DeNigris

I have a half dozen issues ready for review [1]. I'd appreciate if someone will take a look, as some of them are blocking other issues or require second passes that I'd like to begin. Thanks. Sean [1] http://code.google.com/p/pharo/issues/list?can=2&q=reporter%3Asean.p.denigr… -- View this message in context: http://forum.world.st/Issues-ready-for-review-tp4633509.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 6, 2012

Re: [Pharo-project] Trouble loading XML RPC

by Noury Bouraqadi

On 5 juin 2012, at 19:57, garduino wrote: > >> 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. > Yes please do it. > 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. > Yes. TranscriptStream was replaced by ThreadSafeTranscriptStream in 1.4. Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

June 6, 2012

[Pharo-project] [update 2.0] #20113

by Esteban Lorenzano

20113 ----- Issue 6023: Enhance MCHttpRepository>>readStreamForFileNamed:do: to require binary data http://code.google.com/p/pharo/issues/detail?id=6023 Issue 5416: Improve MC version loading http://code.google.com/p/pharo/issues/detail?id=5416

June 6, 2012

[Pharo-project] Pharo 1.3 - Build # 39 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 6, 2012

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

by Camillo Bruni

On 2012-06-06, at 08:27, Nicolas Cellier wrote: > The assumption was that a Smalltalk literal would print itself as a > Smalltalk literal. yeah I know, that IS a somehow a nice property :) > I can't tell if this is a vital feature, and we also have storeOn:... exactly. funnily I found a few bugs in storeOn:/printOn: methods by changing the string behavior > But I can tell you're gonna break a lot of expectations. actually that will be mostly on user-side. in my test-image I had to fix a couple of tests but it perfectly keeps on working :) > What are you looking for? > Something like C++stream << aString ? well I find it a bit strange that String and Symbol behave different than all the other classes when it comes to printing. E.g. whenever you change an inst-var from String/Symbol to another class you'll have to adapt the #printOn: methods :) > Keith Hodge added such support > > Stream>> << items > items putOn: self. > ^ self > > Stream>>putOn:aStream > ^aStream nextPutAll: self. > > Or is it something else? > > Nicolas

June 6, 2012

Re: [Pharo-project] Removing ReferenceStream

by StÃ©phane Ducasse

Yes excellent idea we should update the log regularly. Stef > to "take the bull by the horns", I already started the page: http://code.google.com/p/pharo/wiki/MIgrationFrom14To20 > > we should use it and point to it somewhere in the site, to allow developers to find it (this list could be merged with http://code.google.com/p/pharo/wiki/ActionsInPharo2, I don't know).

June 6, 2012

Re: [Pharo-project] Removing ReferenceStream

by Esteban Lorenzano

Hi, I think is hard to document how to migrate everything from 1.1 to 2.0. What is possible and we should do is to document in the wiki the migration path from 1.4 to 2.0, in those cases in which an adjustment is needed (like this one). I'm not proposing to re-write documentation there, just to keep a single list of: "we are loosing compatibility with x, please use y instead" (and a link to the available documentation, if needed). to "take the bull by the horns", I already started the page: http://code.google.com/p/pharo/wiki/MIgrationFrom14To20 we should use it and point to it somewhere in the site, to allow developers to find it (this list could be merged with http://code.google.com/p/pharo/wiki/ActionsInPharo2, I don't know). Esteban On Jun 6, 2012, at 10:22 AM, Mariano Martinez Peck wrote: > Ok: http://code.google.com/p/pharo/issues/detail?id=6037 > > On Wed, Jun 6, 2012 at 10:06 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Jun 6, 2012 at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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). > > Or in 1.2 or in 1.1. > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 6, 2012

Re: [Pharo-project] Removing ReferenceStream

by Mariano Martinez Peck

Ok: http://code.google.com/p/pharo/issues/detail?id=6037 On Wed, Jun 6, 2012 at 10:06 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, Jun 6, 2012 at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> 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). >> > > Or in 1.2 or in 1.1. > > >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 6, 2012

Re: [Pharo-project] Removing ReferenceStream

by Mariano Martinez Peck

On Wed, Jun 6, 2012 at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > 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). > Or in 1.2 or in 1.1. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

June 6, 2012

[Pharo-project] Dr. Geo in your native language

by Hilaire Fernandes

Hell guys, I am looking for people to translate Dr. Geo in national languages. Kids need the interface in their native language to use it. Already we have French, Spanish (need some review), German, Chinese, Korean, Russan, Italian,... But we miss many translation in European languages: Dutch, Danish, Swedish, Portuguese, Gaelic,... . Greek will be great as DrGeo is related to Euclidean geometry! Japan is also missing! Dr. Geo in Korean: http://twitter.com/drgeo2/status/209985866741981185/photo/1 To participate it is easy, you just need a web browser pointed at http://translate.drgeo.eu, created a login, then proceed. The work can be done by small steps. I plan to release 12.07 end of June. Drop me a line if you are interested, or fell free to start. Hilaire

June 6, 2012