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

Re: [Pharo-project] Script passing and StartupPreferences

by Sean P. DeNigris

Sean P. DeNigris wrote > > It seems that (in 1.4, not sure about 2.0) if an image is launched with a > script (e.g. "cogvm my.image my.st"), StartupPreferences are never run. Is > that what's intended? > After experimenting a bit, it seems that preferences are loaded after script arguments are handled, so if the script ends in #snapshot:andQuit:, the prefs never get loaded. I'm thinking the prefs should be loaded before any scripts. For example, I want my shared cache to be set as the package cache before any load scripts are run. What do y'all think? Cheers, Sean -- View this message in context: http://forum.world.st/Script-passing-and-StartupPreferences-tp4643406p46437… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2012

[Pharo-project] Spec DropLists

by Sean P. DeNigris

Issue 6551: [ENH Spec]: Spec-ify DropListModel http://code.google.com/p/pharo/issues/detail?id=6551 Currently: self instantiateModels: #(dropList #DropListModel). item1 := DropListItem named: 'Red morph' do: self redMorphBlock. item2 := DropListItem named: 'Blue morph' do: self blueMorphBlock. item3 := DropListItem named: 'Green morph' do: self greenMorphBlock. dropList items: {item1. item2. item3}. I'd prefer if DropLists were uniform with the rest of Spec, namely: I'd have my domain class MyColor>>description ^ nameOfColor dropList items: {myRedColor. myBlueColor. myGreenColor}; displayBlock: [ :e | e description, ' morph' ]; whenSelectionChanged: [ :e | self showMorphFor: e ]. I'd prefer not to even know that DropListItem exists, and have the model take care of it for me. Something like: DropListModel>>items: aList "Populate the drop list with a list of objects" | items | items := aList collect: [ :e | DropListItem named: e printString do: [ ] ]. listHolder contents: items. Incidentally, #whenSelectionChanged: exists for DropListModels, but is broken. When an item is chosen from the drop list, the announcement received by this block has both new and old contents set to nil: Issue 6550: [BUG Spec]: DropListModel>>whenSelectionChanged: http://code.google.com/p/pharo/issues/detail?id=6550 Cheers, Sean -- View this message in context: http://forum.world.st/Spec-DropLists-tp4643694.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2012

[Pharo-project] [update 2.0] #20249

by Esteban Lorenzano

20249 ----- Issue 6535: New Nautilus version http://code.google.com/p/pharo/issues/detail?id=6535 Issue 6496: Remove Source Code Authors http://code.google.com/p/pharo/issues/detail?id=6496 Issue 6452: Few Morphic fixes http://code.google.com/p/pharo/issues/detail?id=6452 Issue 6317: Monkey barks when a test package has been changed http://code.google.com/p/pharo/issues/detail?id=6317

Aug. 9, 2012

Re: [Pharo-project] Question about RPackage (bug?)

by Fernando Olivero

You're right! But notice that the RPackage logic of one to one mapping with categories, only breaks when it only provides extension methods as in the case of 'AST-Core' and 'RPackage'. | p | p := RPackageOrganizer default packageNamed: 'AST-Core'. ( p extensionMethods size = 2 ) & ( p definedClasses size = 0 ) Only then, maybe this is a bug? On Thu, Aug 9, 2012 at 1:52 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero <fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> wrote: > Hi Mariano, > > I've been using RPackage so i stumbled on the same "problem". > RPackage maps System Categories (one to one), thus your problem > happens because there's no category named 'RPackage'. > > > But for the rest it works. For example: > > (RPackageOrganizer default packageNamed: 'AST-Core') > > And there is no category 'AST-Core'. > > Moreover, I have just discovered that if I evaluate: RPackageOrganizer initialize. > Then it appears :) > > > For example evaluate (RPackageOrganizer default packageNamed: 'RPackage-Core') > > Saludos, > Fernando > > On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: >> (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true >> >> (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound >> >> bug? >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 9, 2012

Re: [Pharo-project] [ANN] Graveyard20 repository created

by Alexandre Bergel

This is an excellent idea!!!! Alexandre On Aug 9, 2012, at 10:28 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I created a graveyard for packages removed from 2.0. > It is at: > > http://smalltalkhub.com/#!/~Pharo/Graveyard20 > > The purpose of the graveyard is to keep removed packages to allow users to migrate their code. > Sadly, not all packages removed will be there, because there are some so willing to live that the only way to remove them is to kill them definitively (one example of this is SystemChangeNotifier... is so dead that it is impossible to make a come back... not as a ghost, not as a zombie... and certainly not as an obsolete ;) ) > > The first inhabitant is, of course, the old FileDirectory. > > NOTICE: Since this is just a "pre-heaven (or hell)" status for those packages, most probably is that they will degrade and become earth really soon, so... don't expect them to work forever. > > ok, that's enough of dead (and bad) metaphors... enjoy :) > > Esteban -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 9, 2012

Re: [Pharo-project] color problem?

by Fernando Olivero

Hi Esteban, It's a matter of percentage, meaning that you can chose an percentage of r, of g, and of b, and by default the values go from 0.0 to 1.0. If you want to use 255 as the max (as 1.0), then do as Gary posted. Fernando On Thu, Aug 9, 2012 at 4:32 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > why this is logic? shouldn't be enough just using r:g:b:alpha:? > > sorry, my graphics skills are close to zero so... no idea if what I'm saying has any sense :) > > On Aug 9, 2012, at 11:44 AM, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: > >> Color values range from 0.0 to 1.0 use >> >> (Color r: 255 g: 255 b: 122 range: 255) alpha: 1.0 >> >> instead ;-) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Wednesday, August 08, 2012 5:05 PM >> Subject: [Pharo-project] color problem? >> >> >>> Hi, >>> >>> try: >>> >>> Color r: 255 g: 255 b: 122 alpha: 255. >>> >>> AFAIK, that should bring a yellow color. And it is not. >>> Anyone knows why? >>> >>> Esteban >>> >> >> > >

Aug. 9, 2012

Re: [Pharo-project] color problem?

by Esteban Lorenzano

why this is logic? shouldn't be enough just using r:g:b:alpha:? sorry, my graphics skills are close to zero so... no idea if what I'm saying has any sense :) On Aug 9, 2012, at 11:44 AM, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: > Color values range from 0.0 to 1.0 use > > (Color r: 255 g: 255 b: 122 range: 255) alpha: 1.0 > > instead ;-) > > Regards, Gary > > ----- Original Message ----- From: "Esteban Lorenzano" <estebanlm(a)gmail.com> > To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, August 08, 2012 5:05 PM > Subject: [Pharo-project] color problem? > > >> Hi, >> >> try: >> >> Color r: 255 g: 255 b: 122 alpha: 255. >> >> AFAIK, that should bring a yellow color. And it is not. >> Anyone knows why? >> >> Esteban >> > >

Aug. 9, 2012

[Pharo-project] [ANN] Graveyard20 repository created

by Esteban Lorenzano

Hi, I created a graveyard for packages removed from 2.0. It is at: http://smalltalkhub.com/#!/~Pharo/Graveyard20 The purpose of the graveyard is to keep removed packages to allow users to migrate their code. Sadly, not all packages removed will be there, because there are some so willing to live that the only way to remove them is to kill them definitively (one example of this is SystemChangeNotifier... is so dead that it is impossible to make a come back... not as a ghost, not as a zombie... and certainly not as an obsolete ;) ) The first inhabitant is, of course, the old FileDirectory. NOTICE: Since this is just a "pre-heaven (or hell)" status for those packages, most probably is that they will degrade and become earth really soon, so... don't expect them to work forever. ok, that's enough of dead (and bad) metaphors... enjoy :) Esteban

Aug. 9, 2012

[Pharo-project] Spec (1.0): A few Things

by Sean P. DeNigris

All in all, Spec is *much* easier to work with than PolyMorph directly. The builder alone makes for much less code, as we only have to specify the attributes we care about. Ben, thanks for all the great work so far! While pushing on it, I ran into a few problems... 1. Issue 6547: [BUG Spec]: Populating a MultiColumnListModel http://code.google.com/p/pharo/issues/detail?id=6547 The following only populates runListModel if the final line is uncommented. It took quite a long time to figure out why nothing was appearing in the list! Apparently, this is an issue with MultiColumnListModel because ListComposableModels get populated w/o the update: initializeWidgets self instantiateModels: #( runListModel MultiColumnListModel). runListModel items: self model runs; menu: [ :aMenu | self runMenu: aMenu ]; displayBlock: [ :e | self wrapItem: e ]. " WorldState addDeferredUIMessage: [ runListModel updateList ]." 2. Issue 6546: [BUG Spec 1.4]: Menus don't forward action to model http://code.google.com/p/pharo/issues/detail?id=6546 Model>>perform: selector orSendTo: otherTarget ^ otherTarget perform: selector. In Pharo 2.0, #perform:orSendTo: has been moved to Object and does what it says it will. I copied that implementation to ComposableModel. It should probably be in a 1.4 platform package (although I guess there'd be little harm in adding across the board, save the duplication). 3. MultiColumnListModel sounds really cool, but seems to be in alpha. To be generally useful, it would have to have a feature set similar to Mac Finder. That is, for example: * a header row * resizable columns * editable cells (but only the ones you want to be editable) Cheers, Sean p.s. I still can't get Spec 1.1 to load in Pharo 1.4 -- View this message in context: http://forum.world.st/Spec-1-0-A-few-Things-tp4643653.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2012

Re: [Pharo-project] Pharo 2.0-20245 | Group creation

by Noury Bouraqadi

The fix is committed in the new version :-) Noury On 8 aoÃ»t 2012, at 16:41, Noury Bouraqadi wrote: > > On 7 aoÃ»t 2012, at 22:32, Mariano Martinez Peck wrote: > >> On Tue, Aug 7, 2012 at 10:29 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> Hi, >> >> Group creation raises a DNU. >> Replacing messages >> -GroupAnnouncer announcer >> by >> -GroupAnnouncer uniqueInstance >> >> seems to solve the problem, though I'm not sure if this is correct. >> >> >> Noury, update your image ;) >> http://code.google.com/p/pharo/issues/detail?id=6528 >> > But, I used the latest build from jenkins. > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

Aug. 9, 2012