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

[Pharo-project] Beeper

by Pavel Krivanek

Hi, I would like to discuss the Beeper class a little bit. The main purpose of this class is to provide Beeper beep message and use SoundService with respect to current sound enabled settings or VM implemented primitive for beeping. I think that we should: - move the beep function to UIManager - change all calls of Beeper beep to UIManager default beep - in MorphicUIManager use classic Beeper implementation - move Beeper to System-Sound package - in default UIManager implementation use VM beep primitive There are two main reasons for that. You surely do not want to listen beeping server with Pharo images running remote UIs and I want to make Pharo Kernel independent on SoundService. What do you think? -- Pavel

Nov. 17, 2012

[Pharo-project] [update 2.0] #20404

by Marcus Denker

20404 ----- Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic http://code.google.com/p/pharo/issues/detail?id=6994 Issue 6993: update Pharo Kernel generation http://code.google.com/p/pharo/issues/detail?id=6993 Issue 6991: Move #cleanUpForProduction to its own class http://code.google.com/p/pharo/issues/detail?id=6991 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.980.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.735.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1284.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.88.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] Undoing 403 was Re: [update 2.0] #20403

by StÃ©phane Ducasse

Thanks I'm resting after yet another little crisis. Anyway it was fun to go to bern and hack during the moose dojo. I have built a nice little tool. I'm nearly there. This tool will definitively helps the Moosers and synectiquers to freeze their configuration. Stef >> This seems to break something... >> >> I will redo it witout the #cleanUpForRelease >> >> (and another example that shows that everything not tested is broken) >> > > Ok, undo done. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 17, 2012

[Pharo-project] Metacello loading semantics

by StÃ©phane Ducasse

Hi dale I implemented a little tool that - create a kind of specification (version, package, repo) for all the packages reachable from a configurationOf (see below method method packagesAndAssociatedRepositoriesFromConfigurationRecord ) It generates a script looking as follows: script3 ^ #( #('ConfigurationOfFame-TudorGirba.5.mcz' 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' 'http://www.squeaksource.com/MooseAlgos/' 'ConfigurationOfMooseAlgos' ) #('ConfigurationOfGlamour-TudorGirba.98.mcz' 'http://www.squeaksource.com/Glamour/' 'ConfigurationOfGlamour' ) #('ConfigurationOfDSM-AlexandreBergel.56.mcz' 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' 'http://www.squeaksource.com/Kumpel/' 'ConfigurationOfKumpel' ) #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) - I keep the order given by Metacello. I extract the information as follows: packagesAndAssociatedRepositoriesFromConfigurationRecord: aConfigurationRecord "| record | record := ((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record. self packagesAndAssociatedRepositoriesFromConfigurationRecord: record " | pkgs | pkgs := OrderedCollection new. aConfigurationRecord loadDirective packageDirectivesDo: [:directive | pkgs add: {directive spec name, '*'. (self removeCache: directive spec workingCopy repositoryGroup repositories) anyOne locationWithTrailingSlash} ]. ^ pkgs - then I try to load the package as follows: flatVersion47: spec <version: '4.7-flat'> spec for: #common do: [ self populateSpec: spec with: self script3 ] I load them doing (ConfigurationOfMoose project version: '4.7-flat') load Now It does not work because after fetching all the packages, the system complain that some classes that will be loaded later are not present. I imagine that you use Gofer and that Gofer does not use the merging semantics of MC over multiple projects (that you can have multiple package in any order and that the classes get loaded - as I use it for the scriptLoader and below). - before I was doing it by doing a diff between the pharo package and the one loaded and I was loading the specification after installing the repository and the working copies using the MCVersionLoader and it worked I could reload completely Moose! load: aCollectionOfPackageString "self new load: #( 'Famix-C-TudorGirba.15' 'Famix-Core-NicolasAnquetil.201'))" | loader | loader := MCVersionLoader new. (self newerVersionsIn: aCollectionOfPackageString) do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: fn). (Delay forSeconds: 2) wait.] displayingProgress: 'Adding versions...'. loader hasVersions ifTrue: [loader load]. So my question is - Does the packageDirectivesDo: provide an order that I can use to load package with the gofer-load on project at a time? May be my code does not keep the same order but I payed attention to this point. I will check that further. - may be I could extend Gofer to support multiple project merge loading. So right now I'm stuck and this is sad because freezing a complex configuration is really needed. Stef

Nov. 17, 2012

[Pharo-project] [update 2.0] #20403

by Marcus Denker

20403 ----- Issue 6989: Move DebuggerMethodMap to Compiler package http://code.google.com/p/pharo/issues/detail?id=6989 Issue 6894: Add Error tolerant parsing to RB http://code.google.com/p/pharo/issues/detail?id=6894 Diff information: http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1253.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.361.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.104.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] about sharing class binding and others

by Camillo Bruni

On 2012-11-17, at 13:22, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sat, Nov 17, 2012 at 12:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Instead of looking up the class and compiling the shared literal association, we could compile a message send >> to the current environment. >> >> self class environment at: #NameOfClass > > can something similar be done for instance variable references? slots + layouts will do that.

Nov. 17, 2012

Re: [Pharo-project] about sharing class binding and others

by Damien Cassou

On Sat, Nov 17, 2012 at 12:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Instead of looking up the class and compiling the shared literal association, we could compile a message send > to the current environment. > > self class environment at: #NameOfClass can something similar be done for instance variable references? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 17, 2012

Re: [Pharo-project] Undoing 403 was Re: [update 2.0] #20403

by Marcus Denker

On Nov 17, 2012, at 11:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 16, 2012, at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> 20403 >> ----- >> >> Issue 6989: Move DebuggerMethodMap to Compiler package >> http://code.google.com/p/pharo/issues/detail?id=6989 >> >> Issue 6988: Run #cleanUpForRelease in postscript >> http://code.google.com/p/pharo/issues/detail?id=6988 >> > > This seems to break something... > > I will redo it witout the #cleanUpForRelease > > (and another example that shows that everything not tested is broken) > Ok, undo done. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 484 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Nov. 17, 2012

[Pharo-project] Undoing 403 was Re: [update 2.0] #20403

by Marcus Denker

On Nov 16, 2012, at 4:08 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20403 > ----- > > Issue 6989: Move DebuggerMethodMap to Compiler package > http://code.google.com/p/pharo/issues/detail?id=6989 > > Issue 6988: Run #cleanUpForRelease in postscript > http://code.google.com/p/pharo/issues/detail?id=6988 > This seems to break something... I will redo it witout the #cleanUpForRelease (and another example that shows that everything not tested is broken) Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012