- Pharo-dev - lists.pharo.org

Re: [Pharo-project] recategorizing all the categories...

by Mariano Martinez Peck

I am not responsible of the consequences of the following code: First: Gofer new squeaksource: 'autoMethodCat'; package: 'AutomaticMethodCategorizer'; load. After: | autoCat | autoCat := AutomaticMethodCategorizer new. Smalltalk allClassesDo: [:each | autoCat categorizeAllUncategorizedMethodsOf: each ]. Cheers Mariano On Wed, Mar 17, 2010 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > hi guys > > I wanted to know if one you try tried to automatically recategorized all > the methods of the system. > Because I'm tired to get this as yet unclassified in my face. I looks to my > like dirt in the street. > Wanna get clean... > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2010

[Pharo-project] Question about HostMenuSystem

by Mariano Martinez Peck

Hi folks. I want to remove HostMenuSystem from PharoCore image. Probably, I can put it on PharoDev image but of course, it will be accesible also from squeaksource to download it. I don't this is a "core" package. In order to do that, I found the following problem. Look to InputEventSensor >> processMenuEvent: evt | handler localCopyOfEvt | localCopyOfEvt := evt shallowCopy. handler := (HostSystemMenus defaultMenuBarForWindowIndex: (localCopyOfEvt at: 8)) getHandlerForMenu: (localCopyOfEvt at: 3) item: (localCopyOfEvt at: 4). handler handler value: localCopyOfEvt There is the only place where HostSystemMenus is used. Now I am trying to see the best way to remove this. The first approach that came to my mind, which may not be the best to implement this method as follows: processMenuEvent: evt "By default the menu events are not handled. In case you want to handle them you should override this method" And of course, in the package HostSystemMenus we override that method with the original code. Then I though some kind of notification or oberser pattern, where someone can register as an "observer" and then, then this menu events occurs, these guys are notified. Maybe using Announcments? My skills here are quite limited. What do you think ? Can you help me ? Cheers Mariano

March 18, 2010

[Pharo-project] CleanUp unused packages

by Mariano Martinez Peck

http://code.google.com/p/pharo/issues/detail?id=2165 There are some packages that has to be removed. For example: - PinesoftEnhancementsForFreeType: This package is empty - FixUnderscores: This package is old, is not needed any more and has no references The fix is to evaluate: (MCPackage named: 'PinesoftEnhancementsForFreeType') unload. (MCPackage named: 'FixUnderscores') unload. Cheers Mariano

March 18, 2010

[Pharo-project] ESUG selected as GSoC 2010 mentoring organization!!!!

by Mariano Martinez Peck

We are incredibly proud to announce that ESUG was selected for the GSoC 2010. We have a long list of wonderful projects, mentors and a cool website. We want to thank you to all the people who help us publishing project ideas, giving feedback on the submit text or the English, etc. For the moment, we don't know the slots (amount of projects) that we will receive. Don't worry. We will contact you again very soon to let you know the following steps. Now, prepare yourself. We have to show the rest of the world why we love Smalltalk so much :) Thank you very much. The very happy GSoC admin team

March 18, 2010

Re: [Pharo-project] 'Win 32' and others....

by StÃ©phane Ducasse

>> > > Should Smalltalk os redirect to current OSPlatform ? probably something like that (at least I had in mind). But right I should finish the smalltalkImage migration and the pending issue. As well as fighting with the wrong root password on our server :( Stef

March 18, 2010

Re: [Pharo-project] [update 1.1] #11278

by StÃ©phane Ducasse

Thanks :) Stef On Mar 18, 2010, at 10:20 PM, Martin McClure wrote: > On 03/18/10 14:05, StÃ©phane Ducasse wrote: >> Ok I see >> >> I fixed isUnix... sorry for the mess. > > No problem -- proceeding with 11280. > > -Martin

March 18, 2010

Re: [Pharo-project] [update 1.1] #11278

by Martin McClure

On 03/18/10 14:05, StÃ©phane Ducasse wrote: > Ok I see > > I fixed isUnix... sorry for the mess. No problem -- proceeding with 11280. -Martin

March 18, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Dale Henrichs

Looks like GoferProjectLoader class>>createRepositories is the place to start... Dale ----- "Adrian Lienhard" <adi(a)netstyle.ch> wrote: | ok, cool, then lets try to do it this way! | | Estaban, how can we make Gofer Project Loader to be initialized with | MetacelloRepositoryPharo1.0 in a Pharo 1.0 image and the other | repository in 1.1 etc.? | | Cheers, | Adrian | | On Mar 18, 2010, at 18:14 , Dale Henrichs wrote: | | > Okay, | > | > I think I am wrapping my brain around this discussion...Sometimes I | can be very thick headed:) | > | > Yes that makes perfect sense ... I was thinking about a different | issue (code that can only run in Pharo1.1 for example) ... | > | > And the Gofer Project Loader is the perfect place to manage | this...independently of Metacello ... Yes! | > | > Dale | > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | > | > | On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote: | > | | > | > Here is yet another way how we could model universes. We just | have | > | multiple Metacello repositories: | > | > | > | > - MetacelloRepository is the one that everybody can commit to | > | (testing universe) | > | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo | 1.0 | > | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo | 1.1 | > | > - etc. | > | | > | Yes this is what I was thinking. | > | In general the policy for a metacello config is to be in the | project | > | where it belongsto and **copied** to the MetacelloRepository. | > | | > | > A package always first gets into the testing universe and when | it is | > | known to work in a particular version it is copied into the | > | appropriate repository. The Gofer Project Loader would just need | to | > | know the repository for the current Pharo version. Like in Debian, | one | > | can add the testing universe to get unstable versions if needed. | > | > | > | > This setup would not need any code changes in Metacello and it | > | allows us to use access rights to assign people to manage the | process | > | and assert a certain level of quality. | > | | > | Yes! | > | | > | > | > | > Cheers, | > | > Adrian | > | > | > | > | > | > On Mar 17, 2010, at 23:41 , Miguel Enrique CobÃ¡ Martinez wrote: | > | > | > | >> El miÃ©, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribiÃ³: | > | >>> ----- "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: | > | >>> | > | >>> | > - any idea about how we go to differentiate "stable" and | > | "unstable" | > | >>> | | > | >>> | > universes for each Pharo version? How does the user know | which | > | version | > | >>> | > is the one he needs for his version of Pharo? Sorry, this | is | > | not | > | >>> | > directly related to the Gofer Project Loader but I think | it is | > | the next | > | >>> | > important step towards a working package management | system! | > | >>> | | > | >>> | No clue... maybe we need to add to Metacello a new | "dependence | > | >>> | dimension", like "minimum version of distribution"... but | Dale | > | can be | > | >>> | much more helpful than me in this area. | > | >>> | > | >>> I imagine that code targetted for specific Pharo versions will | be | > | treated like we treat code targeted for different Smalltalk | dialects. | > | So you would write specs like the following: | > | >>> | > | >>> spec for: #common do: [...]. | > | >>> spec for: #squeakCommon do: [...]. | > | >>> spec for: #pharo do: [...]. | > | >>> spec for: #'pharo1.0' do: [...]. | > | >>> spec for: #'pharo1.1' do: [...]. | > | >>> | > | >>> or possibly like the following, if a finer version granularity | is | > | needed: | > | >>> | > | >>> spec for: #common do: [...]. | > | >>> spec for: #squeakCommon do: [...]. | > | >>> spec for: #pharo do: [...]. | > | >>> spec for: #'pharo1.0' do: [...]. | > | >>> spec for: #'pharo1.0-10508' do: [...]. | > | >>> spec for: #'pharo1.0-10515' do: [...]. | > | >>> spec for: #'pharo1.1' do: [...]. | > | >>> spec for: #'pharo1.1-11508' do: [...]. | > | >>> spec for: #'pharo1.1-11515' do: [...]. | > | >>> | > | >>> Dale | > | >>> | > | >> | > | >> umm, no please! | > | >> | > | >> There would be a lot of combinations after a while. | > | >> | > | >> Why about having a new spec universes message that accept a | list | > | of | > | >> symbols, each symbol representing a given "universe" of tested | > | packages. | > | >> This list will be the only thing to modify when grouping | different | > | >> versions of the same package in different repositories. | > | >> | > | >> For example, I start with ConfigurationOfMagma version 1.0r43. | Two | > | weeks | > | >> later I release ConfigurationOfMagma with support for loading | > | 1.0r44. | > | >> Both this versions have been tested on Pharo 1.0. So the both | are | > | >> marked | > | >> | > | >> spec universes: #(#pharo10). | > | >> | > | >> A week later Pharo 1.1 is released, and I test the | configuration on | > | this | > | >> new version of pharo. Both work ok. So I modify the line to: | > | >> | > | >> spec universes: #(#pharo10 #pharo11) | > | >> | > | >> and commit. | > | >> | > | >> The tools (GoferProjectLoader) then add functionality to scan | this | > | list | > | >> and presents the users only the appropriated ones based on the | > | image the | > | >> users is querying the repository. | > | >> | > | >> Of course this is very simplistic because as the debian model | > | shows, | > | >> requires a maintainer of each configuration and the user to | report | > | if a | > | >> given #pharo11 marked version actually doesn't work. If | something | > | don't | > | >> work, or a new version is given that works, or the tag #pharo11 | is | > | >> removed from that version effectively removing it from that | given | > | >> universe until bugs are fixed or worked around. | > | >> | > | >> What do you think? | > | >> | > | >> Cheers | > | >>> _______________________________________________ | > | >>> 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 | > | | > | | > | _______________________________________________ | > | 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

March 18, 2010

Re: [Pharo-project] [update 1.1] #11278

by StÃ©phane Ducasse

Ok I see I fixed isUnix... sorry for the mess. Stef > On 03/18/10 13:26, StÃ©phane Ducasse wrote: >> I fixed it now this is strange that it did not break at my place... > > It finds the current platform with a #detect:, so once it finds your platform it doesn't send the other messages. Mac must have come earlier than Unix or Risc in the subclasses collection. And if it's a hashed collection based on identityHash the order could change from image to image. > > -Martin

March 18, 2010

Re: [Pharo-project] 'Win 32' and others....

by Nicolas Cellier

2010/3/18 Michael Rueger <m.rueger(a)acm.org>: > On 3/17/10 1:11 PM, StÃ©phane Ducasse wrote: >> >> What do you think about that? >> I think that would be good. >> >> Issue 2159: We should clean all the platformName = 'Win32' and: [osVersion >> = 'CE'] >> >> This is not good to have all these strings to encode platform support. >> We should move some code to SmalltalkImage > > isn't that what the OSPlatform classes are meant to do? > > Michael Should Smalltalk os redirect to current OSPlatform ? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2010