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

[Pharo-project] Backporting fixes
by Sean P. DeNigris June 7, 2012

June 7, 2012

I want to backport some fixes from 2.0 into 1.4. What's the best way to do that? Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4... Thanks, Sean -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

6 14

[Pharo-project] Graphic Framework..
by Diogenes Moreira June 7, 2012

June 7, 2012

Hi Folk, Is there a framework for generate graphics chart, like excel.. (I'll kill one dragon hidden on the excel and access), for morphic to start, but the idea is using that image in a seaside application. Best D. http://about.me/diogenes.moreira

3 4

[Pharo-project] Fuel
by stephane ducasse June 7, 2012

June 7, 2012

mariano/martin I would like to extract PakageInfo into self packageInfo in the fuel code. Can I do it? Stef

7 7

[Pharo-project] Something does not work with issue tracker status
by Mariano Martinez Peck June 7, 2012

June 7, 2012

Hi guys. Previously, we use to mark issues as "Fixed" once someone proposed a solution. Now we have to first put it as ""FixReviewNeeded" and then when someone else takes the time to review it put it as "FixToInclude". Now...the problem is that nobody reviews and issues get outdated. And then, when trying to load the slice or .cs it does not work anyomre, or it is outdated, or whatever. Meaning that it has to be regenerated and we spend the double of time. So, what can we do to improve this???? ideas: 1) We should be more confident ourselves. Imagine we have proposed something and it is as "FixReviewNeeded". If we have run the tests, and we didn't break anything, and the problem is really fixed, and the topic is not something REALLY critical, and no one has reviewed your issue, why not to putting it as "FixToInclude" ? 2) We really need people helping review changes. There are only a few guys that do this. You DON'T need to be an expert. "FixReviewNeeded" does not mean "HasToBeReviewedByAGuruExperiencedHacker". It just means "it just requires another eyes". So, please, help us review issues. Is the only way to improve. so, what do you think? -- Mariano http://marianopeck.wordpress.com

5 4

[Pharo-project] Issues ready for review
by Sean P. DeNigris June 6, 2012

June 6, 2012

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.

3 3

[Pharo-project] removing followCursor
by StÃ©phane Ducasse June 6, 2012

June 6, 2012

Hi guys I would like to remove followCursor "Just show the Form following the mouse. 6/21/96 tk" Cursor blank showWhile: [self follow: [Sensor cursorPoint] while: [Sensor noButtonPressed]] no sender :) stef

2 1

[Pharo-project] Trouble loading XML RPC
by Noury Bouraqadi June 6, 2012

June 6, 2012

Hi, I tried loading XML RPC from SS3 as suggested by evaluating: Gofer new squeaksource3: 'XMLRPC'; package: 'ConfigurationOfXMLRPC'; package: 'Spy'; package: 'XMLRPC-Client-Core'; package: 'XMLRPC-Client-Tests'; package: 'XMLRPC-Server'; package: 'XMLRPC-Server-Core'; package: 'XMLRPC-Server-Tests'; load But I got an exeception "Unable to resolve Spy-maf.4". It seem that there is a problem, since the latest Spy is version 7. I tested on both Pharo 2 and 1.4 and got the same result. Then I tried to loadConfigurationOfXMLRPC alone Gofer new squeaksource3: 'XMLRPC'; package: 'ConfigurationOfXMLRPC'; load ConfigurationOfXMLRPC load On Pharo 2, I got notifications (see below) that make me belive that DynamicBindgs and KomHttpServer were not ported to Pharo 2. Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury ***Dynamic Bindings This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: forkWithBindings forkWithBindings: forkWithClampedBindings forkWithClampedBindings: forkWithIsolatedBindings forkWithIsolatedBindings: newProcessWithBindings newProcessWithBindings: newProcessWithClampedBindings newProcessWithClampedBindings: newProcessWithIsolatedBindings newProcessWithIsolatedBindings: valueWithBindings: valueWithBindingsContext: ***KomHttpServer This package depends on the following classes: TranscriptStream BlockContext You must resolve these dependencies before you will be able to load these definitions: doPostProcessingFor:response: processHttp processHttpRequest: processVisitor: validateForStack: visitWithValuable: isTranscriptStream 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

3 9

[Pharo-project] [update 2.0] #20113
by Esteban Lorenzano June 6, 2012

June 6, 2012

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

1 0

[Pharo-project] String printOn: / storeOn:
by Camillo Bruni June 6, 2012

June 6, 2012

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

3 4

[Pharo-project] Removing ReferenceStream
by Mariano Martinez Peck June 6, 2012

June 6, 2012

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

6 8