February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About common semantics :)

by Sean P. DeNigris

stephane ducasse wrote > stable: spec > > <symbolicVersion: #stable> > spec for: #'pharo1.4.x' version: '1.1'. > spec for: #'pharo2.x' version: '1.0'. Now the semantics of common in symbolic version versus in version is not clear to me. Should I transform spec for: #'common' do: [ into spec for: #'pharo2.x' do: [ and spec for: #'common' do: [ into spec for: #'pharo1.4.x' do: [ You've already used the symbolic versions to indicate the stability/status mapping from platform to MetaC version. Unless the packaged in spec for: #'common'... are specific to PharoX.Y.Z (e.g. Platform.pharo14), I would leave the #'common'. The package that works for 1.4 might also work for 1.3 and 1.2. We should confirm with Dale, but I'm pretty sure that a #'pharo1.4.x' block will override a #'common' block, so there wouldn't be any conflict... -- View this message in context: http://forum.world.st/About-common-semantics-tp4668980p4669011.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] Migrated HashTable from ss to SmalltalkHub

by Sven Van Caekenberghe

On 10 Feb 2013, at 17:07, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Interesting, nice thesis Camilo. > Why not replace Dictionary then? At least it should be integrated into Collections, in the image. > Fernando Yes, cool stuff, nice thesis; more stuff to readâ¦ If you did all this work, and it is provably better, then indeed, it should at least be an alternative in the collection framework. BTW, regarding space, a dictionary that starts as a SmallDictionary internally and adjust itself according to usage would be ideal, the there is no price to pay. > On Sun, Feb 10, 2013 at 4:38 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-10, at 16:34, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > > > > On Feb 10, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> > >> On 10 Feb 2013, at 15:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > >>> - migrated all the history > >>> - defined configurationOf > >>> - All tests are green under 1.4 and 2.0 > >>> > >>> Stef > >> > >> Dear I ask: what is HastTable and how it is different from Dictionary ? > > > I think it's a dictionary implementation based on buckets (as any other decent > dictionary implementation does...) > > I've shown in my master thesis that a simple bucket-based dictionary can outperform > our poor-mans single array collection dictionary in almost every operation. The only > drawback is the slightly bigger size in memory. > > http://scg.unibe.ch/archive/masters/Brun11a.pdf >

Feb. 10, 2013

Re: [Pharo-project] About dependency granularity in metacello

by stephane ducasse

Thanks mariano in essence what you are saying is that when we depend on a project we have the responsibility to define at our level the package from which we depend on. I think that I will add a section on the book chapter. Stef On Feb 10, 2013, at 4:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Feb 10, 2013 at 12:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi dale > > I'm migrating Moose and I got the following question. In terms of granularity of dependency when depending of project. > > Before we had Fame that depended directly on one package of phexample. > > baseline11: spec > <version: '1.1-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec description: 'Baseline 1.1 first version on SmalltalkHub, copied from baseline 1.0 on SqueakSource'. > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Fame/main'. > spec > package: 'Fame-Core'; > package: 'Fame-Util'; > package: 'Fame-ImportExport' with: [spec requires: #('Fame-Core' ) ]; > package: 'Fame-SmalltalkBinding' with: [spec requires: #('Fame-Core' ) ]; > package: 'Fame-Example'; > package: 'Phexample' with: [spec repository: 'http://www.squeaksource.com/phexample' ]; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example' 'Phexample' ) ]. > spec > group: 'Core' with: #('Fame-Core' 'Fame-ImportExport' 'Fame-Util' 'Fame-SmalltalkBinding' ); > group: 'Tests' with: #('Fame-Tests-Core' ) ]. > > Stefan created a configuration for PhExample so the Fame baseline now depends on the Phexample project > > baseline12: spec > <version: '1.2-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec description: 'Baseline 1.2 to make explicit that Fame depends on HashTable and Phexample (now on smalltalkHub and with working configurations'. > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Fame/main'. > > spec project: 'HashTable' with: [ > spec > className: 'ConfigurationOfHashTable'; > versionString: #stable; > repository: 'http://www.smalltalkhub.com/mc/Moose/HashTable/main' ]. > > spec project: 'Phexample' with: [ > spec > className: 'ConfigurationOfPhexample'; > versionString: #stable; > repository: 'http://www.smalltalkhub.com/mc/Phexample/main' ]. > > > Say you just need the package Core from Phexample (I have just invented the package name) so you can define: > > spec project: 'PhexampleCore' with: [ > spec > className: 'ConfigurationOfPhexample'; > versionString: #stable; > loads: #('Core'); > repository: 'http://www.smalltalkhub.com/mc/Phexample/main' ]. > > > And then do: > > 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example' 'PhexampleCore' ) ]. > > Notice all this above this is NOT the same as doing: > > package: 'Phexample' with: [spec repository: 'http://www.squeaksource.com/phexample' ]; > > That way you are just download a package from a repository, Metacello is not involved. So for example if PhexampleCore has dependencies....they are not laoded. > > With the code I pasted above, you don't just download a package from a repo, instead, you say Metacello you depend on a package. And that is managed as metacello. So for example if PhexampleCore has dependencies, they will be loaded and managed. > > Best, > > spec > package: 'Fame-Core' with: [spec requires: 'HashTable']; > package: 'Fame-Util'; > package: 'Fame-ImportExport' with: [spec requires: #('Fame-Core' ) ]; > package: 'Fame-SmalltalkBinding' with: [spec requires: #('Fame-Core' ) ]; > package: 'Fame-Example'; > package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example') ]. > spec > group: 'Core' with: #('Fame-Core' 'Fame-ImportExport' 'Fame-Util' 'Fame-SmalltalkBinding' ); > group: 'Tests' with: #('Fame-Tests-Core' ) ]. > > > Now my question > we got from package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example' 'Phexample' ) ]. > to a dependency between project and I was wondering if this is ok because may be a project is large and we only > depend on a small part. > > Then doing so we are also losing the information that this is Fame-Tests-Core that introduces the dependency to PhExample > and for large project such information can be important > So is there a way to keep it? > > Stef > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Camillo Bruni

On 2013-02-10, at 17:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 10, 2013, at 5:46 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-02-10, at 17:42, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 10 February 2013 16:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods? >>> >>> Probably because the things that use SystemNavigation - Browsers, >>> MessageSets and the like - want to render lists of things to the user. >>> >>> There is one advantage to dumb strings, which is that it's easy to >>> make a SystemNavigation that works against a remote image. But that's >>> not much to go on. Changing these kinds of methods to return >>> MethodReferences might be a useful middle ground (and permit easy >>> extension to remote tools). >>> >>> I mention remote tools because I hacked up a proof of concept a while >>> back that turned a Browser into one that could access a suitably >>> prepared image through an HTTP API. Development stalled because the >>> reflection machinery's API is a bit... involved, and it was dog slow, >>> but I could browse anything I liked. I should really wrap up the work >>> a bit so I can spread the love. >> >> we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod >> when it comes to all inspection / reflection accesses. >> > > There is Ring that can do the same, too. We need to continue merging all the meta modelsâ¦ right, that's what I meant: RGMethodDefinition

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Marcus Denker

On Feb 10, 2013, at 5:46 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-10, at 17:42, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 10 February 2013 16:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods? >> >> Probably because the things that use SystemNavigation - Browsers, >> MessageSets and the like - want to render lists of things to the user. >> >> There is one advantage to dumb strings, which is that it's easy to >> make a SystemNavigation that works against a remote image. But that's >> not much to go on. Changing these kinds of methods to return >> MethodReferences might be a useful middle ground (and permit easy >> extension to remote tools). >> >> I mention remote tools because I hacked up a proof of concept a while >> back that turned a Browser into one that could access a suitably >> prepared image through an HTTP API. Development stalled because the >> reflection machinery's API is a bit... involved, and it was dog slow, >> but I could browse anything I liked. I should really wrap up the work >> a bit so I can spread the love. > > we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod > when it comes to all inspection / reflection accesses. > There is Ring that can do the same, too. We need to continue merging all the meta modelsâ¦ Marcus

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Camillo Bruni

On 2013-02-10, at 17:42, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 10 February 2013 16:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods? > > Probably because the things that use SystemNavigation - Browsers, > MessageSets and the like - want to render lists of things to the user. > > There is one advantage to dumb strings, which is that it's easy to > make a SystemNavigation that works against a remote image. But that's > not much to go on. Changing these kinds of methods to return > MethodReferences might be a useful middle ground (and permit easy > extension to remote tools). > > I mention remote tools because I hacked up a proof of concept a while > back that turned a Browser into one that could access a suitably > prepared image through an HTTP API. Development stalled because the > reflection machinery's API is a bit... involved, and it was dog slow, > but I could browse anything I liked. I should really wrap up the work > a bit so I can spread the love. we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod when it comes to all inspection / reflection accesses. So I guess we can change that in 3.0 at some point to no longer return silly strings...

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Frank Shearar

On 10 February 2013 16:25, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods? Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user. There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools). I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love. frank

Feb. 10, 2013

Re: [Pharo-project] SystemNavigation >> #allSelect:

by Camille Teruel

On 10 fÃ©vr. 2013, at 17:25, Camillo Bruni wrote: > Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods? Yes, it's really boring to get methods back from these strings. +1 for changing this and rename the method allMethodSelect:.

Feb. 10, 2013

[Pharo-project] SystemNavigation >> #allSelect:

by Camillo Bruni

Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?

Feb. 10, 2013

[Pharo-project] [update 2.0] #20532

by Marcus Denker

20532 ----- Issue 7471: Make #testRewrites a little more readable http://code.google.com/p/pharo/issues/detail?id=7471 Issue 7468: NECCompletion still a bit askew http://code.google.com/p/pharo/issues/detail?id=7468 Issue 6550: [BUG Spec]: DropListModel>>whenSelectionChanged: http://code.google.com/p/pharo/issues/detail?id=6550 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Widgets-MarcusDenker.97.diff http://ss3.gemstone.com/ss/Pharo20/NECompletion-MarcusDenker.93.diff http://ss3.gemstone.com/ss/Pharo20/AST-Tests-Core-MarcusDenker.21.diff

Feb. 10, 2013