- Pharo-dev - lists.pharo.org

[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

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

by Camillo Bruni

On 2013-02-10, 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 at some point we might do it ;), we proposed this 3 years ago, but I guess Pharo wasn't ready back then... Currently I prefer replacing all the shitty streaming stuff with XTreams in 3.0.

Feb. 10, 2013

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

by Fernando Olivero

Interesting, nice thesis Camilo. Why not replace Dictionary then? At least it should be integrated into Collections, in the image. Fernando 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

[Pharo-project] About common semantics :)

by stephane ducasse

Dale working on phexample (which worked well on 2.0) I changed stable: spec <symbolicVersion: #stable> spec for: #'common' version: '1.0'. into stable: spec <symbolicVersion: #stable> spec for: #'pharo1.4.x' version: '1.1'. spec for: #'pharo2.x' version: '1.0'. because I could not get the version running in 1.4 (deprecated method usage). version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. Now the semantics of common in symbolic version versus in version is not clear to me. Should I transform version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. into version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'pharo2.x' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. and version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. into version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'pharo1.4.x' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. Thanks Stef

Feb. 10, 2013

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

by Mariano Martinez Peck

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] Migrated HashTable from ss to SmalltalkHub

by Camillo Bruni

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] Migrated HashTable from ss to SmalltalkHub

by stephane ducasse

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 ? No idea :) Fame uses it so I moved it. Tests are green and all the history is now migrated. Stef

Feb. 10, 2013

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

by Camille Teruel

On 10 fÃ©vr. 2013, at 16:22, Sven Van Caekenberghe 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 ? Not sure but I think it's an implementation with proper collision management.

Feb. 10, 2013

[Pharo-project] About dependency granularity in metacello

by StÃ©phane Ducasse

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' ]. 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

Feb. 10, 2013