- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 2 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods CollectionsTests.Strings.StringTest.testAt

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 10:46, Frank Shearar a Ã©crit : > On 27 June 2013 09:49, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 27/06/2013 10:30, Camillo Bruni a Ã©crit : >>> >>> >>> On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>>> >>>> >>>> Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>>>>>> >>>>>>>> >>>>>> >>>>>> I like the fact that I can do git log --pretty="%H" >>>>>> path_to_method_file, and I have all the hashes I need. >>>>> >>>>> >>>>> yeah but you have the "wrong" hash as the source includes the category >>>>> :) >>>>> I prefer storing the methods in subfolders which represent categories, >>>>> so I keep >>>>> the methods sources as clean as possible. For instance this way a >>>>> recategorization >>>>> is detected as a move by standard git tools. Now that I say, we should >>>>> do the same >>>>> for the classes :P. >>>> >>>> >>>> In this case, how would you query git for all the versions of a method? >>>> If it is recategorized, you would not be able to see through the move, no? >>> >>> >>> if you store the category in the method you won't see a move of course, >>> otherwise yes: >>> >>> >>> https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe… >> >> >> I still have a worry with that, because I don't see how to load a method >> version previous to the change (except with a lot of code to understand it >> image side). >> >> When I scan for method versions, I do, given a commitID, get the method + >> metadata. If the method path is dependent on which commitID I select, it >> becomes significantly more complex. > > Why not just have a directory for the methods, and a single metadata > file for categorising methods? We've talked on and off over the years > about turning categories into tags (so a method could be in multiple > categories), which this would allow. It would _also_ mean that > recategorising a method wouldn't touch the file containing the method. Yes! I want more of that kind of suggestions :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 11:19, StÃ©phane Ducasse a Ã©crit : > > On Jun 27, 2013, at 9:54 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 27/06/2013 09:39, StÃ©phane Ducasse a Ã©crit : >>> >>>> It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( >>>> >>>> With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) >>> >>> But I save regularly on MC server or locally (after each new read and green tests is a good moment) >>> Because having git as a backend will not give you micro commit. >> >> Yes and no. You could have micro commit, it's dead easy to implement. >> >>> Then we are working on a really nice code modification logging named EPICEA to replace the old cs. >>> Because if you crash your image between two git commit. >> >> Micro-commit can be implemented on MC over git. It's a easy deal if you need it. >> >> I'm sure EPICEA will improve over the old cs format. Will that make it better than improving the package infrastructure? I'm not so sure. > > this is not related. > the source code management right now mixes > source code > log of modification. What you see in the git use is that you have to mix the two anyway. If you don't, the git users will adjust the file format so that git detect automagically the modifications (i.e. recreate the log) that you haven't written in :-P > EPICEA is about replacing the recovering crash kind of the tool (and more of course) > but it is not about source. And I hope EPICEA will help in handling source versionning :) Thierry > > > >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] [ENH]: Window Menu Registration (like World Menu)

by StÃ©phane Ducasse

yes because we are busy. Busy does not mean that we are not interested. > Nobody has looked at this in 10 days... > > > On Jun 17, 2013, at 2:12 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Sean P. DeNigris wrote >>> https://pharo.fogbugz.com/f/cases/10910/Window-Menu-Registration-like-World… >> >> New fix in inbox: >> SLICE-Issue-10910-Window-Menu-Registration-like-World-Menu-SeanDeNigris.3 >> >> This version: >> * FallbackMenu: reset the builder after debugging, or the fallback menu does >> not appear anymore (e.g. the next time the pragma menu tries to build >> itself) >> >> From version 2: >> * Remove DiscoveredMenu >> * Move most menu building logic into PragmaMenuBuilder. Now we have fallback >> menus for all buildl menus! e.g. Nautilus menus >> * Leave a #fallbackMenuOn: hook in Object (packaged with PragmaMenuBuilder), >> where custom fallback items can be added. I didn't want to do it with >> pragmas in case we ended up with neither the discovered or fallback working >> * Class comment for FallbackMenu. Thanks Cami for the review :) >> * PragmaMenuBuilder - don't #buildTree during instance creation. Wait until >> necessary (i.e. when a menu spec is built). This makes it nice and clean to >> trap all errors when the spec is built and throw up a fallback menu >> >> From version 1: >> * Use annotation <windowMenu> >> * Re-implement existing menu options with pragma/builder >> * Refactor general menu discovery code common to both World and Window menus >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ENH-Window-Menu-Registration-like-World-Menu-tp469326… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

On Jun 27, 2013, at 9:54 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 27/06/2013 09:39, StÃ©phane Ducasse a Ã©crit : >> >>> It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( >>> >>> With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) >> >> But I save regularly on MC server or locally (after each new read and green tests is a good moment) >> Because having git as a backend will not give you micro commit. > > Yes and no. You could have micro commit, it's dead easy to implement. > >> Then we are working on a really nice code modification logging named EPICEA to replace the old cs. >> Because if you crash your image between two git commit. > > Micro-commit can be implemented on MC over git. It's a easy deal if you need it. > > I'm sure EPICEA will improve over the old cs format. Will that make it better than improving the package infrastructure? I'm not so sure. this is not related. the source code management right now mixes source code log of modification. EPICEA is about replacing the recovering crash kind of the tool (and more of course) but it is not about source. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 27, 2013

Re: [Pharo-dev] [BUG]: Extension Methods Missing from Packages

by Marcus Denker

This fix still needs to be reviewed. On Fri, Jun 14, 2013 at 4:13 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > This bug is a major PITA. Pleeeeease review and integrate the fixes!!! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/BUG-Extension-Methods-Missing-from-Packages-tp4692842… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

June 27, 2013

Re: [Pharo-dev] [ENH]: Window Menu Registration (like World Menu)

by Marcus Denker

Nobody has looked at this in 10 days... On Jun 17, 2013, at 2:12 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote >> https://pharo.fogbugz.com/f/cases/10910/Window-Menu-Registration-like-World… > > New fix in inbox: > SLICE-Issue-10910-Window-Menu-Registration-like-World-Menu-SeanDeNigris.3 > > This version: > * FallbackMenu: reset the builder after debugging, or the fallback menu does > not appear anymore (e.g. the next time the pragma menu tries to build > itself) > > From version 2: > * Remove DiscoveredMenu > * Move most menu building logic into PragmaMenuBuilder. Now we have fallback > menus for all buildl menus! e.g. Nautilus menus > * Leave a #fallbackMenuOn: hook in Object (packaged with PragmaMenuBuilder), > where custom fallback items can be added. I didn't want to do it with > pragmas in case we ended up with neither the discovered or fallback working > * Class comment for FallbackMenu. Thanks Cami for the review :) > * PragmaMenuBuilder - don't #buildTree during instance creation. Wait until > necessary (i.e. when a menu spec is built). This makes it nice and clean to > trap all errors when the spec is built and throw up a fallback menu > > From version 1: > * Use annotation <windowMenu> > * Re-implement existing menu options with pragma/builder > * Refactor general menu discovery code common to both World and Window menus > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ENH-Window-Menu-Registration-like-World-Menu-tp469326… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 10:30, Camillo Bruni a Ã©crit : > > On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>>>> >>>> >>>> I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need. >>> >>> yeah but you have the "wrong" hash as the source includes the category :) >>> I prefer storing the methods in subfolders which represent categories, so I keep >>> the methods sources as clean as possible. For instance this way a recategorization >>> is detected as a move by standard git tools. Now that I say, we should do the same >>> for the classes :P. >> >> In this case, how would you query git for all the versions of a method? If it is recategorized, you would not be able to see through the move, no? > > if you store the category in the method you won't see a move of course, otherwise yes: > > https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe… I still have a worry with that, because I don't see how to load a method version previous to the change (except with a lot of code to understand it image side). When I scan for method versions, I do, given a commitID, get the method + metadata. If the method path is dependent on which commitID I select, it becomes significantly more complex. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Frank Shearar

On 27 June 2013 09:49, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 27/06/2013 10:30, Camillo Bruni a Ã©crit : >> >> >> On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> >>> >>> Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>>>>> >>>>>>> >>>>> >>>>> I like the fact that I can do git log --pretty="%H" >>>>> path_to_method_file, and I have all the hashes I need. >>>> >>>> >>>> yeah but you have the "wrong" hash as the source includes the category >>>> :) >>>> I prefer storing the methods in subfolders which represent categories, >>>> so I keep >>>> the methods sources as clean as possible. For instance this way a >>>> recategorization >>>> is detected as a move by standard git tools. Now that I say, we should >>>> do the same >>>> for the classes :P. >>> >>> >>> In this case, how would you query git for all the versions of a method? >>> If it is recategorized, you would not be able to see through the move, no? >> >> >> if you store the category in the method you won't see a move of course, >> otherwise yes: >> >> >> https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe… > > > I still have a worry with that, because I don't see how to load a method > version previous to the change (except with a lot of code to understand it > image side). > > When I scan for method versions, I do, given a commitID, get the method + > metadata. If the method path is dependent on which commitID I select, it > becomes significantly more complex. Why not just have a directory for the methods, and a single metadata file for categorising methods? We've talked on and off over the years about turning categories into tags (so a method could be in multiple categories), which this would allow. It would _also_ mean that recategorising a method wouldn't touch the file containing the method. frank > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 27, 2013

question about HandMorph

by plantec

Hi all, The current hand has the world as its owner but the world submorphs do not contains the current hand. Why is it like that ? Thanks Alain

June 27, 2013