- Pharo-dev - lists.pharo.org

[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

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

by Marcus Denker

On May 12, 2012, at 12:12 PM, Marcus Denker wrote: > > 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. >> > because this "implementors of", not "implementors of..." > We should check... what I against is to have the OB behavior that command-n gets me a list even when I pointed exactly to what I want to have the senders of. >> Am I doing something wrong? >> >> Look like the browser need a lot of love. >> > If you don't like it don't use it. > Another way to say it: We released 1.4 three weeks ago and decided that Nautilus is not yet stable and good enough to be shiped (we never even planed to ship it in 1.4). This means yes, there is work to do. But then, nothing is perfect (and Pharo was actually foundet with the principle of having realized that Perfection is Death :-) So we will improve it, step by step. Every day. This *subsumes* that from the standpoint of tomorrow, we have something imperfect today. There is nothing one can do against it (other than never finishing and releasing anything). Marcus -- Marcus Denker -- http://marcusdenker.de

May 12, 2012

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

by Marcus Denker

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. > because this "implementors of", not "implementors of..." If people really need the other (the one with the menu)? I personally never ever selected something there other than the method itself. If I want to have "senders of" something, I click in the body. > Am I doing something wrong? > > Look like the browser need a lot of love. > If you don't like it don't use it. Marcus -- Marcus Denker -- http://marcusdenker.de

May 12, 2012

Re: [Pharo-project] We need your successes

by Hilaire Fernandes

Nice idea, I will prepare one Hilaire On 11/05/2012 17:11, StÃ©phane Ducasse wrote: > Hi everybody > > We really want to build a "vitrine" showroom of Pharo and we would you to participate. > We want to build a web page with all these successes and show it to the world. :) > > We would like to get from you a three slides document: > > slide one: > a sexy picture and a teaser / who you are. > > slide two: > what is it how cool is it. > > slide three: > what cool pharo techno you used or developed. > > I did a bad one using DrGeo to give you an idea. > > So can you please send us these three slides. We would like to present them during the > Pharo conf and after put them on the web. > > Stef and marcus. > > -- Dr. Geo -- http://www.drgeo.eu

May 12, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by H. Hirzel

On 5/12/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > got three days meeting this week so crawling to get my brain aligned with > fun againâ¦ > I will read your article. I will also look at STON because I like the object > literal syntax too :). Fine...! > (note that I'm not changing my mind - I still do not get why I need > dictionary for method meta data - I agree; just for method meta data it is not needed. I just checked it in Squeak 4.3, Pharo 1.4, Cuis 4.0 and Amber {#foo -> 1. #bar -> 42} as: Dictionary. "fine for Squeak, Pharo, Cuis" {#foo -> 1. #bar -> 42} gives an Array in Amber; #as: is not understood But a literal array parser available in many dialects is still needed then. For the curly brackets syntax for dynamic array there was some discussion this week on the squeak list how it is used. The decision by Dale and others to go for JSON was driven by the availability of a parser for many Smalltalk dialects. > but we are thinking (and the team should discuss for real and not just > during lunches) that having a literal object syntax would be cool). Great! --Hannes > > Stef > > > >>> I would like to share my quick two cents regarding this subject. >>> >>> 1st cent. I would stick with JSON. Even though I find STON slick, I >>> would >>> not deviate from something that is mainstream and all Smalltalk dialects >>> already support. >>> >>> 2nd cent. A Dictionary literal syntax would be useful too. I would like >>> to >>> have it. >>> >>> It could be something like #{'this' -> 1. 'that' -> 2 }, and keep {1. >>> 2} for >>> dynamic arrays. >> >> I don't want to sound like a broken record - but you do realize that I >> wrote about this in the article and mentioned this exact syntax? >> >> I know, the article was a tad long - but just go to planet.smalltalk.org >> and search down to "Sidestory: Adding literal Dictionaries to >> Smalltalk?". >> >> regards, GÃ¶ran >> > > >

May 12, 2012