- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-consortium] We need your successes

by StÃ©phane Ducasse

Thanks Hilaire for this cool one :) https://gforge.inria.fr/frs/download.php/30761/drgeo-teaser.pdf I should do one for http://www.synectique.eu Stef

May 12, 2012

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?

by Mariano Martinez Peck

On Sat, May 12, 2012 at 6:12 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 12, 2012, at 10:27 AM, StÃ©phane Ducasse wrote: > > > > > On May 11, 2012, at 10:27 AM, Marcus Denker wrote: > > > >> > >> With Fuel, we should take the opportunity to clean up the systm. There > are things we need to keep > >> for a while (DataStream, for example, a it is used by Monticello). > >> > >> But what about SmartRefStream? With ImageSegment already gone, does it > make sense to keep > >> it? The code looks horrible. > >> > >> One can just remove it and all remaining users like this: > >> > >> http://code.google.com/p/pharo/issues/detail?id=5859 > >> > >> Can we do that? do we need to formally deprecate it? > > > > would be good even if so boringâ¦ :) > > > I have an idea: I will integrate the removal change. But as soon as somone > who is not me > adds a tracker entry with a Slice that has a nicely deprecated version of > SmartRefStream, I will > directly add it. > > This is kind "removal inversion": normally keeping something is the cheap > and easy option. Removing > is hard. In this case, we invert: remvove, but *if* for somebody the > "keep" option is important > enough to spend *a trivial amoung of work on*, we do it. > Marcus, I wanted to do the check, but I am really busy fixing some stuff for Fuel for the PharoConf presentation. As soon as I have some time, I plan to do a pass on it. > > ;-) > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

May 12, 2012

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?

by Marcus Denker

On May 12, 2012, at 10:27 AM, StÃ©phane Ducasse wrote: > > On May 11, 2012, at 10:27 AM, Marcus Denker wrote: > >> >> With Fuel, we should take the opportunity to clean up the systm. There are things we need to keep >> for a while (DataStream, for example, a it is used by Monticello). >> >> But what about SmartRefStream? With ImageSegment already gone, does it make sense to keep >> it? The code looks horrible. >> >> One can just remove it and all remaining users like this: >> >> http://code.google.com/p/pharo/issues/detail?id=5859 >> >> Can we do that? do we need to formally deprecate it? > > would be good even if so boringâ¦ :) I have an idea: I will integrate the removal change. But as soon as somone who is not me adds a tracker entry with a Slice that has a nicely deprecated version of SmartRefStream, I will directly add it. This is kind "removal inversion": normally keeping something is the cheap and easy option. Removing is hard. In this case, we invert: remvove, but *if* for somebody the "keep" option is important enough to spend *a trivial amoung of work on*, we do it. ;-) Marcus -- Marcus Denker -- http://marcusdenker.de

May 12, 2012

[Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Issue 5874: [ENH]: Notify progress with Announcements instead of Exceptions http://code.google.com/p/pharo/issues/detail?id=5874 This seems like a natural use case for Announcements and Exceptions seems like more of a hack. I found the Exception behavior very hard to customize. I caught the ProgressInitiationException, but the ProgressNotification exceptions seemed to be caught elsewhere and I could not get to them. What do you guys think? Sean -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 12, 2012

Re: [Pharo-project] I cannot see the code in the latest Moose build

by Benjamin

Thank you guys :) It was a stupid mistake when posting versions :) So I fix it, and push the latest 2.0 fixes in the 1.4 version :) So now it seems to work properly :) Could you try and confirm please ? Thanks in advance, Ben On May 12, 2012, at 3:38 PM, Fabrizio Perin wrote: > Hi, > just download the Moose build of May the 8th > > http://ci.moosetechnology.org/job/moose-latest-dev/972/artifact/moose/ > > and open Nautilus. You will notice that the browser is empty. > > I think that either in Moose is loaded the latest version of Nautilus, so we can report bugs or suggest improvements (and we benefit from the on going work), or it pointless to load Nautilus. > If we have to rely on a fix version of a development environment than I believe it is better to rely on an old version of a mature development environment such as OB. This is why I suggested to use OB instead of Nautilus. > > Cheers, > Fabrizio > > > 2012/5/12 Tudor Girba <tudor(a)tudorgirba.com> > Hi, > > The problem is reproducible in the latest Pharo 1.4. > > Just download it, and then run: > Gofer new > url: 'http://ss3.gemstone.com/ss/Nautilus'; > package: 'ConfigurationOfNautilus'; > load. > (ConfigurationOfNautilus project version: #stable) load. > > Cheers, > Doru > > > On 12 May 2012, at 14:20, Benjamin wrote: > > > Could you please point me where I can download the image and the exact way to reproduce the issue ? > > > > Because it clearly sounds weird to me, and I am proud that Moose use Nautilus :) > > > > > > Thanks in advance, > > Ben > > > > > > On May 12, 2012, at 12:06 PM, Fabrizio Perin wrote: > > > >> If we don't use the latest version of Nautilus what about to load the working version of Omnibrowser? > >> > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfOmniBrowser'; > >> load. > >> > >> (ConfigurationOfOmniBrowser > >> project version: #stable) load: #( 'Dev' 'Dev Tests'). > >> > >> Cheers, > >> Fabrizio > >> > >> 2012/5/11 Tudor Girba <tudor(a)tudorgirba.com> > >> Now, I switched the build process to use as a seed, the fixed Nautilus image built on May 4. > >> > >> This means that, at this point, in the Moose image Nautilus does not get updated anymore. > >> > >> Cheers, > >> Doru > >> > >> > >> On 11 May 2012, at 08:52, Tudor Girba wrote: > >> > >> > I can reproduce the problem. > >> > > >> > Nautilus is loaded from its own repository like: > >> > Gofer new > >> > url: 'http://ss3.gemstone.com/ss/Nautilus'; > >> > package: 'ConfigurationOfNautilus'; > >> > load. > >> > (ConfigurationOfNautilus project version: #stable) load. > >> > > >> > > >> > It seems that when you load this in Pharo 1.4, there is a mismatch with RPackage-Core: if I load the latest RPackage-Core version, it seems to work. > >> > > >> > But, if you load the version (213) from the MetaRepoForPharo14, it works. So, now I changed the loading code to be: > >> > Gofer new > >> > squeaksource:'MetaRepoForPharo14'; > >> > package: 'ConfigurationOfNautilus'; > >> > load. > >> > (ConfigurationOfNautilus project version: #stable) load. > >> > > >> > > >> > Nevertheless, it would be good if the ConfigurationOfNautilus would continue to load properly in 1.4. > >> > > >> > Cheers, > >> > Doru > >> > > >> > > >> > > >> > On 10 May 2012, at 15:01, Fabrizio Perin wrote: > >> > > >> >> Hi, > >> >> I download the latest yellow build from the moose web site (8 may). When I open Nautilus I cannot see the code. > >> >> > >> >> I don't have any clue if it is about Nautilus or about how Nautilus is loaded in Moose or about something else. > >> >> > >> >> Any idea? > >> >> > >> >> Cheers, > >> >> Fabrizio > >> > > >> > -- > >> > www.tudorgirba.com > >> > > >> > "Sometimes the best solution is not the best solution." > >> > > >> > >> -- > >> www.tudorgirba.com > >> > >> "It's not how it is, it is how we see it." > >> > >> > >> > > > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > >

May 12, 2012

Re: [Pharo-project] Implementors of...

by Hilaire Fernandes

Ok, I did not know the behavior was as you just described it. Thanks Hilaire On 12/05/2012 14:18, Benjamin wrote: > Hello :) > > Do you have opened an entry ? > > Honestly, I am not a fan of this mechanism (as Marcus said, when I want something specific, I select it from the text, then use shortcuts :) ) > But I can understand you miss it. > > > Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) > (right now I am more in a "bugs fix" phase that "add new features" one ^^) > > Ben > > > > On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: > >> Tried from Nautilus: >> >> Why when asking 'implementors of ' in the method menu, I only got the >> implementor of this method. >> >> Am I doing something wrong? >> >> Look like the browser need a lot of love. >> >> Hilaire >> >> -- >> Dr. Geo -- http://www.drgeo.eu >> >> > > > -- Dr. Geo -- http://www.drgeo.eu

May 12, 2012

Re: [Pharo-project] I cannot see the code in the latest Moose build

by Fabrizio Perin

Hi, just download the Moose build of May the 8th http://ci.moosetechnology.org/job/moose-latest-dev/972/artifact/moose/ and open Nautilus. You will notice that the browser is empty. I think that either in Moose is loaded the latest version of Nautilus, so we can report bugs or suggest improvements (and we benefit from the on going work), or it pointless to load Nautilus. If we have to rely on a fix version of a development environment than I believe it is better to rely on an old version of a mature development environment such as OB. This is why I suggested to use OB instead of Nautilus. Cheers, Fabrizio 2012/5/12 Tudor Girba <tudor(a)tudorgirba.com> > Hi, > > The problem is reproducible in the latest Pharo 1.4. > > Just download it, and then run: > Gofer new > url: 'http://ss3.gemstone.com/ss/Nautilus'; > package: 'ConfigurationOfNautilus'; > load. > (ConfigurationOfNautilus project version: #stable) load. > > Cheers, > Doru > > > On 12 May 2012, at 14:20, Benjamin wrote: > > > Could you please point me where I can download the image and the exact > way to reproduce the issue ? > > > > Because it clearly sounds weird to me, and I am proud that Moose use > Nautilus :) > > > > > > Thanks in advance, > > Ben > > > > > > On May 12, 2012, at 12:06 PM, Fabrizio Perin wrote: > > > >> If we don't use the latest version of Nautilus what about to load the > working version of Omnibrowser? > >> > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfOmniBrowser'; > >> load. > >> > >> (ConfigurationOfOmniBrowser > >> project version: #stable) load: #( 'Dev' 'Dev Tests'). > >> > >> Cheers, > >> Fabrizio > >> > >> 2012/5/11 Tudor Girba <tudor(a)tudorgirba.com> > >> Now, I switched the build process to use as a seed, the fixed Nautilus > image built on May 4. > >> > >> This means that, at this point, in the Moose image Nautilus does not > get updated anymore. > >> > >> Cheers, > >> Doru > >> > >> > >> On 11 May 2012, at 08:52, Tudor Girba wrote: > >> > >> > I can reproduce the problem. > >> > > >> > Nautilus is loaded from its own repository like: > >> > Gofer new > >> > url: 'http://ss3.gemstone.com/ss/Nautilus'; > >> > package: 'ConfigurationOfNautilus'; > >> > load. > >> > (ConfigurationOfNautilus project version: #stable) load. > >> > > >> > > >> > It seems that when you load this in Pharo 1.4, there is a mismatch > with RPackage-Core: if I load the latest RPackage-Core version, it seems to > work. > >> > > >> > But, if you load the version (213) from the MetaRepoForPharo14, it > works. So, now I changed the loading code to be: > >> > Gofer new > >> > squeaksource:'MetaRepoForPharo14'; > >> > package: 'ConfigurationOfNautilus'; > >> > load. > >> > (ConfigurationOfNautilus project version: #stable) load. > >> > > >> > > >> > Nevertheless, it would be good if the ConfigurationOfNautilus would > continue to load properly in 1.4. > >> > > >> > Cheers, > >> > Doru > >> > > >> > > >> > > >> > On 10 May 2012, at 15:01, Fabrizio Perin wrote: > >> > > >> >> Hi, > >> >> I download the latest yellow build from the moose web site (8 may). > When I open Nautilus I cannot see the code. > >> >> > >> >> I don't have any clue if it is about Nautilus or about how Nautilus > is loaded in Moose or about something else. > >> >> > >> >> Any idea? > >> >> > >> >> Cheers, > >> >> Fabrizio > >> > > >> > -- > >> > www.tudorgirba.com > >> > > >> > "Sometimes the best solution is not the best solution." > >> > > >> > >> -- > >> www.tudorgirba.com > >> > >> "It's not how it is, it is how we see it." > >> > >> > >> > > > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > >

May 12, 2012

Re: [Pharo-project] I cannot see the code in the latest Moose build

by Tudor Girba

Hi, The problem is reproducible in the latest Pharo 1.4. Just download it, and then run: Gofer new url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (ConfigurationOfNautilus project version: #stable) load. Cheers, Doru On 12 May 2012, at 14:20, Benjamin wrote: > Could you please point me where I can download the image and the exact way to reproduce the issue ? > > Because it clearly sounds weird to me, and I am proud that Moose use Nautilus :) > > > Thanks in advance, > Ben > > > On May 12, 2012, at 12:06 PM, Fabrizio Perin wrote: > >> If we don't use the latest version of Nautilus what about to load the working version of Omnibrowser? >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfOmniBrowser'; >> load. >> >> (ConfigurationOfOmniBrowser >> project version: #stable) load: #( 'Dev' 'Dev Tests'). >> >> Cheers, >> Fabrizio >> >> 2012/5/11 Tudor Girba <tudor(a)tudorgirba.com> >> Now, I switched the build process to use as a seed, the fixed Nautilus image built on May 4. >> >> This means that, at this point, in the Moose image Nautilus does not get updated anymore. >> >> Cheers, >> Doru >> >> >> On 11 May 2012, at 08:52, Tudor Girba wrote: >> >> > I can reproduce the problem. >> > >> > Nautilus is loaded from its own repository like: >> > Gofer new >> > url: 'http://ss3.gemstone.com/ss/Nautilus'; >> > package: 'ConfigurationOfNautilus'; >> > load. >> > (ConfigurationOfNautilus project version: #stable) load. >> > >> > >> > It seems that when you load this in Pharo 1.4, there is a mismatch with RPackage-Core: if I load the latest RPackage-Core version, it seems to work. >> > >> > But, if you load the version (213) from the MetaRepoForPharo14, it works. So, now I changed the loading code to be: >> > Gofer new >> > squeaksource:'MetaRepoForPharo14'; >> > package: 'ConfigurationOfNautilus'; >> > load. >> > (ConfigurationOfNautilus project version: #stable) load. >> > >> > >> > Nevertheless, it would be good if the ConfigurationOfNautilus would continue to load properly in 1.4. >> > >> > Cheers, >> > Doru >> > >> > >> > >> > On 10 May 2012, at 15:01, Fabrizio Perin wrote: >> > >> >> Hi, >> >> I download the latest yellow build from the moose web site (8 may). When I open Nautilus I cannot see the code. >> >> >> >> I don't have any clue if it is about Nautilus or about how Nautilus is loaded in Moose or about something else. >> >> >> >> Any idea? >> >> >> >> Cheers, >> >> Fabrizio >> > >> > -- >> > www.tudorgirba.com >> > >> > "Sometimes the best solution is not the best solution." >> > >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> >> > -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

May 12, 2012

Re: [Pharo-project] Moving data into new package/image version

by Mariano Martinez Peck

On Sat, May 12, 2012 at 3:03 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I'm porting some apps that were using simple image-based persistence > (ReferenceStream) from 1.3 to 1.4. > > The first thing that I ran into was FS class name changes (e.g. FSReference > -> FileReference). Since the class wasn't present, I got an > errorKeyNotFound > [1]. Naively tried: > > Smalltalk globals > at: #FSReference put: FileReference; > at: #FSFilesystem put: FileSystem; > at: #FSAbsolutePath put: AbsolutePath; > at: #FSUnixStore put: UnixStore. > > But got "primitive #primGetPosition: in MultiByteFileStream failed" from > ReferenceStream>>next > > I have a few ideas, but has anyone gone successfully through this type of > process before? What's my best bet? I've been following Fuel and STON > (which > is quite nice for parsing json from REST APIs b.t.w.), but I'm not clear if > either would be helpful here. > > Sorry, I don't have ideas of how to solve that. However, I can only say that Fuel *does* suppor that type of problem (if I understood the problem correctly). The following test demonstrates an example: FLMigrationTest >> testClassRename | pointClass aPoint resultPoint pointClassName | pointClass := self newClassWithInstanceVariableNames: 'x y'. pointClassName := pointClass name. aPoint := pointClass new. aPoint instVarNamed: 'x' put: 7. aPoint instVarNamed: 'y' put: 11. self serialize: aPoint. pointClass renameSilently: (pointClassName, 'Renamed') asSymbol. self materializer migrateClassNamed: pointClassName toClass: pointClass. resultPoint := self materialized. self assert: (resultPoint instVarNamed: 'x') = 7. self assert: (resultPoint instVarNamed: 'y') = 11. > What do you suggest? > > Thanks, > Sean > > [1] Stack trace (heavily snipped) > SystemDictionary(Dictionary)>>errorKeyNotFound: > Receiver: a SystemDictionary(lots of globals) > Arguments and temporary variables: > aKey: #FSReference > Receiver's instance variables: > tally: 2920 > array: an Array(#MemoryHandle->MemoryHandle nil nil > #BlockClosuresTestCase->Blo...etc... > cachedClassNames: nil > cachedNonClassNames: nil > > ... > > ReferenceStream(DataStream)>>readInstance > Receiver: a ReferenceStream > Arguments and temporary variables: > instSize: 2 > aSymbol: #FSReference > refPosn: 50 > anObject: nil > newClass: nil > Receiver's instance variables: > byteStream: MultiByteFileStream: '/Volumes/Sean''s > Universe/sean/.jenkins/jobs/...etc... > topCall: nil > basePos: 0 > references: an IdentityDictionary() > objects: an IdentityDictionary(0->#(nil) 5->a > Resources 10->#Resources > 21->an O...etc... > currentReference: 55 > fwdRefEnds: an IdentityDictionary() > blockers: an IdentityDictionary() > skipping: an IdentitySet() > > -- > View this message in context: > http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 12, 2012

[Pharo-project] Moving data into new package/image version

by Sean P. DeNigris

I'm porting some apps that were using simple image-based persistence (ReferenceStream) from 1.3 to 1.4. The first thing that I ran into was FS class name changes (e.g. FSReference -> FileReference). Since the class wasn't present, I got an errorKeyNotFound [1]. Naively tried: Smalltalk globals at: #FSReference put: FileReference; at: #FSFilesystem put: FileSystem; at: #FSAbsolutePath put: AbsolutePath; at: #FSUnixStore put: UnixStore. But got "primitive #primGetPosition: in MultiByteFileStream failed" from ReferenceStream>>next I have a few ideas, but has anyone gone successfully through this type of process before? What's my best bet? I've been following Fuel and STON (which is quite nice for parsing json from REST APIs b.t.w.), but I'm not clear if either would be helpful here. What do you suggest? Thanks, Sean [1] Stack trace (heavily snipped) SystemDictionary(Dictionary)>>errorKeyNotFound: Receiver: a SystemDictionary(lots of globals) Arguments and temporary variables: aKey: #FSReference Receiver's instance variables: tally: 2920 array: an Array(#MemoryHandle->MemoryHandle nil nil #BlockClosuresTestCase->Blo...etc... cachedClassNames: nil cachedNonClassNames: nil ... ReferenceStream(DataStream)>>readInstance Receiver: a ReferenceStream Arguments and temporary variables: instSize: 2 aSymbol: #FSReference refPosn: 50 anObject: nil newClass: nil Receiver's instance variables: byteStream: MultiByteFileStream: '/Volumes/Sean''s Universe/sean/.jenkins/jobs/...etc... topCall: nil basePos: 0 references: an IdentityDictionary() objects: an IdentityDictionary(0->#(nil) 5->a Resources 10->#Resources 21->an O...etc... currentReference: 55 fwdRefEnds: an IdentityDictionary() blockers: an IdentityDictionary() skipping: an IdentitySet() -- View this message in context: http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 12, 2012