January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] how to import an icon

by StÃ©phane Ducasse

look into the MenuIcons class code there is a facility to import and save menuicons. Stef > Hi, > > I would like to import icons from external files in the image. These > should be used for menus and buttons. > > How should I do that? What format should be used? What size? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] Categorizing method extension with pragma

by StÃ©phane Ducasse

On Jan 10, 2010, at 2:37 PM, CÃ©drick BÃ©ler wrote: > > 2010/1/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > yes now we should pay attention about metadata in the methods. > > yes this is an extra thing to do but it might be necessary. Also it can be sort of "transparent". > > Imagine I download an image and start my new project. So I use a "project browser" (a packages context oriented browser), ie a classical browser that create new packages and each time I add extension methods, the metadata are associated automaticaly. > > Now what we can have also is that the ***package*** knows the extension > this is what my dead slowing making progress impelemntation is doing. > > uhm ok :) Maybe better.. so I'll wait and see ;) Would that autorize to have a classic method category name ? or will it still be *apackage ? it should now the problem is backward compatibility with MC. importing mc with conventions saving mc with conventions I discussed with lukas about what is the best way to handle that and now I forgot :) > > > What's difficult here to me is that maybe we need to stay backward compatible or see if squeakers want to adopt the same strategy wich is not that easy I guess. > > > > > On Jan 10, 2010, at 2:08 PM, CÃ©drick BÃ©ler wrote: > > > Hi, > > > > Just a 2 cents thought on method extension. > > > > Why not associating a pragma instead of using the package name prefixed by a star ? > > > > Say there is a package named MyPackage and I override a method in String or add a new one. What I'd like is keeping the original method category name (or find an appropriate one) instead of using *mypackage. For instance: > > > > String>>aMethod > > <package: MyPackage> > > ... > > ... > > ^result > > > > > > Then, we would have to adapt monticello for that purpose. We could also use dynamic protocols to get the list of extension method by package. > > > > What does other think ? I find it could be a good starting point to deal with packages. > > > > > > > > -- > > CÃ©drick > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] ConfigurationOfOmniBrowser

by Mariano Martinez Peck

Dale: after some discussions in Pharo mailing list, the community wants to use the Lukas repository for OB instead of wiresong. I don't know the impact it makes to you, and I don't know the best way to manage this kind of situations. Right now, I create a new version and baselind to ConfigurationOfOmniBrowser that maps to Lukas repo and I change a little the dependencies, and, of course, the versions. Any thougths about this? Cheers Mariano On Sat, Jan 9, 2010 at 1:17 AM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > just fine..thanks > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > > | On Sat, Jan 9, 2010 at 12:47 AM, Dale Henrichs > | <dale.henrichs(a)gemstone.com>wrote: > | > | > > | > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > | > > | > | So far, I created: ConfigurationOfNewInspector, > | > | ConfigurationOfOCompletion, > | > | ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtras, > | > | ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, > | > | ConfigurationOfShout , and......ConfigurationOfPharo!!! > | > > | > Mariano, > | > > | > I'm working on a ConfigurationOfOmneBrowser that works on both > | Squeak and > | > Pharo (and ultimately GemStone ...). > | > > | > Would you prefer that I start a new baseline/version or just > | overwrite 1.0? > | > > | > > | Hi Dale. Good we are working in OB. This weekend / next-week I want > | to > | create a PharoDev image with OB so maybe I would rather if you can > | create a > | new baseline (taking 1.0 as a base) and if you want, later we can > | "merge" if > | necessary. > | > | What do you think ? Is this ok for you ? > | > | > | > I lean towards overwriting, especially this early in the process, > | but I > | > want your opinion. > | > > | > Dale > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > >

Jan. 10, 2010

Re: [Pharo-project] #11147 update breaks 1.1 dev image

by StÃ©phane Ducasse

Martin may be you work with the published version before 1.1-11147. Because this one should be stable at least I used it without any problem. Removing preferences was like an earthquake :) If we cannot edit text we will be in trouble :) should be fixed soon. Stef >>>>> 11147 >>>>> ----- >>>>> >>>>> Issue 1761: Unloadable-reloadable Services-Base + >>>>> DeprecatedPreferences packages (part 1 - 3) >>>>> >>>>> ... some packages are dirty. This will be fixed next, together with >>>>> part 4 and a cleanup of packages that >>>>> are defined wrongly. >>>>> >>>> When trying to update the latest downloaded 1.1-dev image (11112) it >>>> reaks on 11147 with MNU: AnObsoletePreferences class>>doesNotUnderstand: >>>> #preferenceAt:ifAbsent: >>>> >>> yes, the update is incomplete (need for part 4 which reintegrates >>> Preferences that is needed for pharo-dev) >> you need to wait for a completely rebuilt pharo-dev distribution. >> Then it should be ok, at least regarding the Preference problem. > > OK, thanks. After finding that I can't even successfully edit code in a > browser in 1.1 core (the cursor does not appear in the right place) I'm > reverting to 1.0 for now. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 9:45 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> After that I have only two tests failing :) > >> > >> - testPushAlpaBeta > >> - testUpdatesSelection > >> > >> The same it is here: > http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… > > > > I fixed the other two bugs, they were caused by a bug in the hudson > > test runner. Don't know the matter with these buggers. Will have a > > look later tonight. > > I cannot reproduce these two bugs. They always appear on the build > server, but they pass when I download the exactly same image. Always. > > Can you debug them? > > Sure. testPushAlphaBeta fails in self assertSelectionIs: 1. because in assertSelectionIs: anInteger you can see that anInteger and index are both 1, but the button answer false to the message isOn testUpdateSelection fails in self assertSelectionIs: 2 because in assertSelectionIs: anInteger and index are both 2 but isOn returns false.. Som, it seems both issue are due to the same. Let me know what else can I test. Cheers Mariano > Lukas > > > > > >> > >> :) > >> > >> Thanks > >> > >> Mariano > >> > >> > >> > >> Lukas > >> > >> -- > >> Lukas Renggli > >> http://www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] #11147 update breaks 1.1 dev image

by Martin McClure

Alain Plantec wrote: > Alain Plantec a Ã©crit : >> Martin McClure a Ã©crit : >>> Marcus Denker wrote: >>> >>>> 11147 >>>> ----- >>>> >>>> Issue 1761: Unloadable-reloadable Services-Base + >>>> DeprecatedPreferences packages (part 1 - 3) >>>> >>>> ... some packages are dirty. This will be fixed next, together with >>>> part 4 and a cleanup of packages that >>>> are defined wrongly. >>>> >>> When trying to update the latest downloaded 1.1-dev image (11112) it >>> reaks on 11147 with MNU: AnObsoletePreferences class>>doesNotUnderstand: >>> #preferenceAt:ifAbsent: >>> >> yes, the update is incomplete (need for part 4 which reintegrates >> Preferences that is needed for pharo-dev) > you need to wait for a completely rebuilt pharo-dev distribution. > Then it should be ok, at least regarding the Preference problem. OK, thanks. After finding that I can't even successfully edit code in a browser in 1.1 core (the cursor does not appear in the right place) I'm reverting to 1.0 for now. Regards, -Martin

Jan. 10, 2010

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 10:06 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I agree, it would be nice to have software update for the Pharo > images. But as long as it does not reliably work, I think it harms > more than it helps. > > +1. But...they main question is, do you know in which cases it breaks stuff? ONLY with overrides ? How many overrides do we have from external packages in Core ? > Adrian > > BTW, I believe one should regularly start with a fresh image, so > starting from a new download should not be a big issue anyway > > It depends. For us it is easy. Buy there are other users, that have data in their image and maybe it is a little more complicated than download a package from squeaksource. > On Jan 10, 2010, at 19:22 , Miguel Enrique CobÃ¡ Martinez wrote: > > > El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribiÃ³: > >> I would also rather disable it. We had numerous reports where this > >> failed. I think "the right way" to do it is to have a build server > >> that creates new Pharo images from the PharoCore version (i.e., > >> "nightly builds"). Until we have this automated, one can always grab > >> an up to date PharoCore and build a Pharo image using the Metacello > >> configuration. > > > > But this means that the users that downloaded a prior Pharo will be > > left > > on the cold and they will not receive bug fixes, including grave bug > > fixes. They will be informed that must download a new version and move > > all their code to a new image. > > > > This could generate a lot of irritation on the users because maybe > > they > > are changing images just because their current image can't apply a > > one-line fix that could be distributed by the update stream. > > > > Big decision I know, but both options have good arguments. > > Maybe a BIG warning on pressing the System->Update indicating that the > > update *could* break something in the image and suggesting to save all > > their work to a monticello package and know the consecuences and then > > giving them a button to proceed with the update. > > So if someone doesn't want to update he/she can cancel. If the haven't > > saved, they cancel and save their work, then proceed with the > > update. If > > they have everything saved, just proceed with the update knowing the > > consequences. What do you think? > > > > Cheers > > > > > >> > >> Adrian > >> > >> On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote: > >> > >>> On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike(a)mjr104.co.uk> > >>> wrote: > >>> > >>>> without its own update stream, or section in the update file, I > >>>> think > >>>> the effect of allowing the Pharo image to update itself based on > >>>> the > >>>> core update file would lead to an undefined result? > >>>> > >>>> > >>> Yes. Mostly due to overrides. > >>> > >>> > >>>> If that is the case I would disable it. > >>>> > >>>> I assume this would be replaced by some Metacello 'update stream' ? > >>>> > >>>> > >>> That's a good idea. I am not sure how to implement it, but for sure, > >>> it will > >>> be in a future ;) Maybe 1.1 > >>> > >>> > >>>> cheers, > >>>> Mike > >>>> > >>>> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>>>> It is a simple question. Do we allow that or not. Miguel wrote > >>>>> the pros > >>>> and > >>>>> cons: > >>>>> > >>>>> Pros > >>>>> - Can fix bugs after release > >>>>> - Can aply improvements to the image after release. > >>>>> > >>>>> Cons > >>>>> - Can mess the image of someone by overwriting some overridden > >>>>> method. > >>>>> - Can accidentally update more than intended in someone's image > >>>>> > >>>>> > >>>>> We have to take a decision. > >>>>> > >>>>> Cheers > >>>>> > >>>>> Mariano > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > >>>>> project > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] #11147 update breaks 1.1 dev image

by Alain Plantec

Alain Plantec a Ã©crit : > Martin McClure a Ã©crit : >> Marcus Denker wrote: >> >>> 11147 >>> ----- >>> >>> Issue 1761: Unloadable-reloadable Services-Base + >>> DeprecatedPreferences packages (part 1 - 3) >>> >>> ... some packages are dirty. This will be fixed next, together with >>> part 4 and a cleanup of packages that >>> are defined wrongly. >>> >> >> When trying to update the latest downloaded 1.1-dev image (11112) it >> reaks on 11147 with MNU: AnObsoletePreferences class>>doesNotUnderstand: >> #preferenceAt:ifAbsent: >> > yes, the update is incomplete (need for part 4 which reintegrates > Preferences that is needed for pharo-dev) you need to wait for a completely rebuilt pharo-dev distribution. Then it should be ok, at least regarding the Preference problem. Cheers Alain

Jan. 10, 2010

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Adrian Lienhard

I agree, it would be nice to have software update for the Pharo images. But as long as it does not reliably work, I think it harms more than it helps. Adrian BTW, I believe one should regularly start with a fresh image, so starting from a new download should not be a big issue anyway On Jan 10, 2010, at 19:22 , Miguel Enrique CobÃ¡ Martinez wrote: > El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribiÃ³: >> I would also rather disable it. We had numerous reports where this >> failed. I think "the right way" to do it is to have a build server >> that creates new Pharo images from the PharoCore version (i.e., >> "nightly builds"). Until we have this automated, one can always grab >> an up to date PharoCore and build a Pharo image using the Metacello >> configuration. > > But this means that the users that downloaded a prior Pharo will be > left > on the cold and they will not receive bug fixes, including grave bug > fixes. They will be informed that must download a new version and move > all their code to a new image. > > This could generate a lot of irritation on the users because maybe > they > are changing images just because their current image can't apply a > one-line fix that could be distributed by the update stream. > > Big decision I know, but both options have good arguments. > Maybe a BIG warning on pressing the System->Update indicating that the > update *could* break something in the image and suggesting to save all > their work to a monticello package and know the consecuences and then > giving them a button to proceed with the update. > So if someone doesn't want to update he/she can cancel. If the haven't > saved, they cancel and save their work, then proceed with the > update. If > they have everything saved, just proceed with the update knowing the > consequences. What do you think? > > Cheers > > >> >> Adrian >> >> On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote: >> >>> On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike(a)mjr104.co.uk> >>> wrote: >>> >>>> without its own update stream, or section in the update file, I >>>> think >>>> the effect of allowing the Pharo image to update itself based on >>>> the >>>> core update file would lead to an undefined result? >>>> >>>> >>> Yes. Mostly due to overrides. >>> >>> >>>> If that is the case I would disable it. >>>> >>>> I assume this would be replaced by some Metacello 'update stream' ? >>>> >>>> >>> That's a good idea. I am not sure how to implement it, but for sure, >>> it will >>> be in a future ;) Maybe 1.1 >>> >>> >>>> cheers, >>>> Mike >>>> >>>> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> It is a simple question. Do we allow that or not. Miguel wrote >>>>> the pros >>>> and >>>>> cons: >>>>> >>>>> Pros >>>>> - Can fix bugs after release >>>>> - Can aply improvements to the image after release. >>>>> >>>>> Cons >>>>> - Can mess the image of someone by overwriting some overridden >>>>> method. >>>>> - Can accidentally update more than intended in someone's image >>>>> >>>>> >>>>> We have to take a decision. >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] Pharo Smalltalk â¥

by Michael van der Gulik

On Mon, Jan 11, 2010 at 7:17 AM, Guido Stepken <gstepken(a)googlemail.com> wrote: > Pharo Smalltalk â¥ > Â Â ifTrue: [developer honk] > > > That should be valid code :) It is. You'll just need to implement those methods. http://securesqueak.blogspot.com/2008/11/unicode-in-squeak.html Gulik. -- http://gulik.pbwiki.com/

Jan. 10, 2010