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

Re: [Pharo-project] phexample?

by Frank Shearar

On 10 February 2013 17:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm trying to debug some phexample tests. > Now I do not get why the following expression > > printer stream contents isString should beTrue > > returns nil when printer stream contents isString is true. That's expected, I would think - if printer stream contents isString is false, it'll raise a TestFailure. That's what it looks like PhexMatcher >> expect:describeShould:describeShouldNot: does. frank

Feb. 10, 2013

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

by Benjamin

+9000 Ben On Feb 10, 2013, at 5:45 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. > > 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] About dependency granularity in metacello

by Mariano Martinez Peck

On Sun, Feb 10, 2013 at 2:18 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Mariano have a look at section 1.10 :) > > Looks OK, but isn't this a duplication? "Loading speciï¬c packages" in page 21 looks similar. -- Mariano http://marianopeck.wordpress.com

Feb. 10, 2013

[Pharo-project] phexample?

by StÃ©phane Ducasse

Hi guys I'm trying to debug some phexample tests. Now I do not get why the following expression printer stream contents isString should beTrue returns nil when printer stream contents isString is true. Stef

Feb. 10, 2013

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

by Dale Henrichs

Feb. 10, 2013

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

by Dale Henrichs

Comments embedded below... ----- Original Message ----- | From: "stephane ducasse" <stephane.ducasse(a)free.fr> | To: "Dale Henrichs" <dhenrich(a)vmware.com> | Cc: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Sunday, February 10, 2013 8:01:45 AM | Subject: About common semantics :) | | 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'. ]. | I would recommend that you leave the symbolic versions alone: stable: spec <symbolicVersion: #stable> spec for: #'common' version: '1.0'. In order to accomodate your different packages for different versions you should change the version1.0 spec to the following: version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. spec for: #'pharo2.x' do: [ spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. With this spec, you are declaring that Phexample-StephaneDucasse.68 be used for all platforms except Pharo2.x where Phexample-StefanMarr.67 should be used instead... Dale

Feb. 10, 2013

[Pharo-project] Fwd: I will customize phexample to work on both 1.4 and 2.0

by Stefan Marr

Hi Stef: Begin forwarded message: > because now it only works on 2.0 > So I will use symbolic versions for real. > I think that you are working on 2.0. > On 1.4 I get DNU due to substrings... What's the best way to handle such trivial difference between different versions, or even dialects? So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. Creating a version specific package just for that methods seems to be exaggerated. However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. The latest version now breaks on Pharo 2.0 again (with a deprecation...) Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? Any other good approach to handle such small differences in a scalable way would also be interesting... Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 10, 2013

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

by stephane ducasse

provide benchs and we will take adequate action :) Not you camillo :) Stef On Feb 10, 2013, at 5:07 PM, 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 > > > > 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

Mariano have a look at section 1.10 :)

Feb. 10, 2013

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

by Camillo Bruni

On 2013-02-10, at 18:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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. This is what the dictionaries measured in my thesis do ;). We just start with one bucket, so you are slightly slower than a small dict due to 1 additional indirection, but you do no longer need a separate class for SmallDictionaries.

Feb. 10, 2013