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

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

[Pharo-project] [update 2.0] #20071

by Esteban Lorenzano

20071 ----- Issue 5866: error in new CodeImporter http://code.google.com/p/pharo/issues/detail?id=5866 Issue 5835: Improved version of StartupPreferences http://code.google.com/p/pharo/issues/detail?id=5835

May 12, 2012

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

by Benjamin

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." > > >

May 12, 2012

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

by Benjamin

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 > >

May 12, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Mariano Martinez Peck

On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: > > > Hi guys. The last literal of a instance-side compiled method always > points to the SAME (#==) association of the class in Smalltalk global. > > The literals of a compiled method that refer to class variables refer to > the same association (#==) of the classPool of its class: > > > > self assert: ((GRPlatform class >> #current) literalAt: 1) == > (GRPlatform classPool associationAt: #Current). -> true > > > > However, if I do a copy of the class: > > > > | copy | > > copy := GRPlatform copy. > > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool > associationAt: #Current). > > > > this is not true anymore. Of course, you can see this because of the > Class >> #copy implementation: > > > > So my question is....is #copy breaking the contract (and therefore it > has to be fixed) or this is not mandatory for the system (as it is with the > last literal pointing to classes)? > > since namespace binding are shared between method literal and namespace, I > think that this is a bug. > > I did this workaround Class >> rebindClassVariablesInMethods self class methodDict valuesDo: [ :aCompiledMethod | 1 to: aCompiledMethod numLiterals-2 do: [ :index | | literal | literal := aCompiledMethod literalAt: index. literal isVariableBinding ifTrue: [ (self innerBindingOf: literal key) ifNotNil: [:aBinding | aCompiledMethod literalAt: index put: aBinding ] ] ] ] > Stef > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

May 12, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by StÃ©phane Ducasse

On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: > Hi guys. The last literal of a instance-side compiled method always points to the SAME (#==) association of the class in Smalltalk global. > The literals of a compiled method that refer to class variables refer to the same association (#==) of the classPool of its class: > > self assert: ((GRPlatform class >> #current) literalAt: 1) == (GRPlatform classPool associationAt: #Current). -> true > > However, if I do a copy of the class: > > | copy | > copy := GRPlatform copy. > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool associationAt: #Current). > > this is not true anymore. Of course, you can see this because of the Class >> #copy implementation: > > So my question is....is #copy breaking the contract (and therefore it has to be fixed) or this is not mandatory for the system (as it is with the last literal pointing to classes)? since namespace binding are shared between method literal and namespace, I think that this is a bug. Stef > > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com >

May 12, 2012

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

by StÃ©phane Ducasse

Hilaire on which version did you try it? Because there are a lot of changes in nautilus. Stef 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 > >

May 12, 2012