- Pharo-dev - lists.pharo.org

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

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

by Mariano Martinez Peck

On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero <fernando.olivero(a)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> 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] Question about RPackage (bug?)

by Fernando Olivero

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'. 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> wrote: > (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true > > (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound > > bug? > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 9, 2012

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

by Mariano Martinez Peck

(MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound bug? -- Mariano http://marianopeck.wordpress.com

Aug. 9, 2012

Re: [Pharo-project] color problem?

by Gary Chambers

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] FileSystem differences between Pharo-2.0 and Pharo-1.4

by Camillo Bruni

On 2012-08-09, at 03:31, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Cami, > > Given that I am using Pharo-1.4 FileSystem to develop for Pharo-2.0 it would be very useful to have equivalent functionality...especially if it won't take to long for you to provide it ... > > When you have a new version of FileSystem available for Pharo-1.4 let me know ... tomorrow I have a long train ride to do, so I will most probably fix by tomorrow evening.

Aug. 9, 2012

Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4

by Dale Henrichs

Cami, Given that I am using Pharo-1.4 FileSystem to develop for Pharo-2.0 it would be very useful to have equivalent functionality...especially if it won't take to long for you to provide it ... When you have a new version of FileSystem available for Pharo-1.4 let me know ... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 8, 2012 10:35:54 AM | Subject: Re: [Pharo-project] FileSystem differences between Pharo-2.0 and Pharo-1.4 | | nope they won't work either... | I changed all of that in 2.0's FS overhaul. Maybe we should port | these changes back to 1.4 to support a working version of FS there. | | All the stream selectors in 1.4 create a FSFileStream or so, which is | a incomplete reimplementation of FileStream. They might work for a | very limited set of operations, but AFAIK there is a big mem leak of | low level file handlers which eventually will crash the VM. | | Porting the changes back to 1.4 for the FileStream subpart should be | a 0.5h task (for me ;)). | | If esteban agrees to include these changes in 1.4 I am willing to | create a patch :) | | | On 2012-08-08, at 19:32, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > Cami, | > | > How about writeStream* and readStream* are those working? It looks | > like you used those variants in your FileTree pull request... | > | > Thanks, | > | > Dale | > | > ----- Original Message ----- | > | From: "Camillo Bruni" <camillobruni(a)gmail.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, August 8, 2012 10:06:18 AM | > | Subject: Re: [Pharo-project] FileSystem differences between | > | Pharo-2.0 and Pharo-1.4 | > | | > | in pharo 1.4 #fileStream and #fileStreamDo: & Co are not working | > | properly... | > | You'll still have to use something like | > | FileStream fileNamed: reference fullName | > | otherwise it should more or less work. | > | | > | | > | On 2012-08-08, at 18:36, Dale Henrichs <dhenrich(a)vmware.com> | > | wrote: | > | | > | > I'm starting a port of FileTree to Pharo-2.0 and I'm planning | > | > on | > | > using Pharo-1.4 (summer) to do the actual port, since I can't | > | > run | > | > my development environment in Pharo-2.0 (chicken and egg | > | > problem). | > | > | > | > I'm wondering if there are any significant differences between | > | > the | > | > FileSystem implementations on the two platforms that I should | > | > be | > | > aware of... | > | > | > | > Dale | > | > | > | | > | | > | | > | | |

Aug. 9, 2012