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

Re: [Pharo-project] Question about HostMenuSystem

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: March 16, 2010 7:29:12 PM GMT+01:00 > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: do you remember the fix for the hostMenu > Reply-To: johnmci(a)smalltalkconsulting.com > > The fix seems to be in > > PharoCore1.1ALPHA > Latest update: #11254 > > > peekEvent > "Look ahead at the next event." > | nextEvent | > nextEvent := eventQueue peek. > ^((nextEvent notNil) and: [(nextEvent at: 1) ~= EventTypeMenu]) > ifTrue: [self processEvent: nextEvent] > > On 2010-03-15, at 12:58 PM, stephane ducasse wrote: > >> Hi john >> >> I would like to add the HostMenus back to 1.1 and get the tests green. >> Do you have the fix for the menus somewhere? >> >> Stef > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > >

March 19, 2010

Re: [Pharo-project] Question about HostMenuSystem

by StÃ©phane Ducasse

adrian the duplication was solved :) Now what mariano is aiming at is can be get minicore in place and from minicore reload core :) if you see what I mean. Stef On Mar 19, 2010, at 8:43 AM, Adrian Lienhard wrote: > Hi Mariano, > > As you may remember, I have removed HostSystemMenus from PharoCore 1.0 some time ago. > > What I did in this case was "Smalltalk at: #HostSystemMenus ifPresent:...", which is not very nice but easily solves the problem. > > Thanks for removing it in 1.1. Until the duplication of events due to this package/plugin is solved, we should not have it in PharoCore. Or maybe even better we should not have it in PharoCore at all and load it only in Pharo (when it works). > > Cheers, > Adrian > > > On Mar 18, 2010, at 23:38 , Mariano Martinez Peck wrote: > >> 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 >> _______________________________________________ >> 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 19, 2010

Re: [Pharo-project] CleanUp unused packages

by StÃ©phane Ducasse

lukas could you publish somewhere (soon on the lint chapter) the gofer and rb expression to fix all the _ Stef On Mar 19, 2010, at 8:18 AM, Lukas Renggli wrote: >> I am not sure, but I think FixUnderscores should be useful for old packages >> loaded in pharo. > > The problem with the FixUnderscores package is that it does a string > replacement and thus might perform incorrect transformations. You need > to manually visit each change to be sure that it did correctly. The RB > engine does a tree based transformation, which is always correct. > > I am all for kicking this package. It also contains old code that > changes font glyphs, that's not needed any longer. > > Lukas > > >> For example, some projects still use _, so we need FixUnderscore to fix them >> automatically. >> Personally, I use it on the whole Pharo 3 months ago. >> Cheers, >> Jannik >> >> On Mar 18, 2010, at 23:37 , Mariano Martinez Peck wrote: >> >> 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 >> _______________________________________________ >> 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 >> > > > > -- > 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

March 19, 2010

Re: [Pharo-project] CleanUp unused packages

by StÃ©phane Ducasse

thanks On Mar 18, 2010, at 11:37 PM, Mariano Martinez Peck wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2010

Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

by StÃ©phane Ducasse

On Mar 19, 2010, at 7:39 AM, Carla F. Griggio wrote: > I guess it depends on how you'd like to represent a date and time. > We may have 2 representations here, the DateAndTime object and the string. If you consider that the string '1901-01-01T00:00:00+12:00' actually represents that day and time and it's not just the way you would print it, then I think it's valid to compare one representation and another of the same concept, because they really mean the same to you. we are in object-oriented programming not string oriented programming so this is not valid to a date and its string representation to be equal. :) > If you see '1901-01-01T00:00:00+12:00' and say "that's not a date and time, it's just how I'd print it" maybe the only valid representation of the date and time for you is a DateAndTime object, then it doesn't make sense comparing de DateAndTime object with it's string. exact!!! > > Personally, I think the string it's just the "print string", I agree with you. But maybe originally the people who implemented that comparison considered it as a date and time representation too, so it makes sense to compare them they probably wanted to do too much. Stef

March 19, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Adrian Lienhard

Ah, I didn't know this was solved. I don't know about it occurring again because I mostly work in Pharo 1.0, which has the Host System Menu code removed. Is this a fix in the VM? Cheers, Adrian On Mar 19, 2010, at 08:50 , John McIntosh wrote: > I believe the duplicate events issue was solved or do you have an > example of it occuring again? > > On 3/19/10, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Mariano, >> >> As you may remember, I have removed HostSystemMenus from PharoCore 1.0 some >> time ago. >> >> What I did in this case was "Smalltalk at: #HostSystemMenus ifPresent:...", >> which is not very nice but easily solves the problem. >> >> Thanks for removing it in 1.1. Until the duplication of events due to this >> package/plugin is solved, we should not have it in PharoCore. Or maybe even >> better we should not have it in PharoCore at all and load it only in Pharo >> (when it works). >> >> Cheers, >> Adrian >> >> >> On Mar 18, 2010, at 23:38 , Mariano Martinez Peck wrote: >> >>> 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 >>> _______________________________________________ >>> 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 >> > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2010

Re: [Pharo-project] Question about HostMenuSystem

by John McIntosh

I believe the duplicate events issue was solved or do you have an example of it occuring again? On 3/19/10, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Mariano, > > As you may remember, I have removed HostSystemMenus from PharoCore 1.0 some > time ago. > > What I did in this case was "Smalltalk at: #HostSystemMenus ifPresent:...", > which is not very nice but easily solves the problem. > > Thanks for removing it in 1.1. Until the duplication of events due to this > package/plugin is solved, we should not have it in PharoCore. Or maybe even > better we should not have it in PharoCore at all and load it only in Pharo > (when it works). > > Cheers, > Adrian > > > On Mar 18, 2010, at 23:38 , Mariano Martinez Peck wrote: > >> 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 >> _______________________________________________ >> 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 > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 19, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Adrian Lienhard

Hi Mariano, As you may remember, I have removed HostSystemMenus from PharoCore 1.0 some time ago. What I did in this case was "Smalltalk at: #HostSystemMenus ifPresent:...", which is not very nice but easily solves the problem. Thanks for removing it in 1.1. Until the duplication of events due to this package/plugin is solved, we should not have it in PharoCore. Or maybe even better we should not have it in PharoCore at all and load it only in Pharo (when it works). Cheers, Adrian On Mar 18, 2010, at 23:38 , Mariano Martinez Peck wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2010

Re: [Pharo-project] CleanUp unused packages

by Lukas Renggli

> I am not sure, but I think FixUnderscores should be useful for old packages > loaded in pharo. The problem with the FixUnderscores package is that it does a string replacement and thus might perform incorrect transformations. You need to manually visit each change to be sure that it did correctly. The RB engine does a tree based transformation, which is always correct. I am all for kicking this package. It also contains old code that changes font glyphs, that's not needed any longer. Lukas > For example, some projects still use _, so we need FixUnderscore to fix them > automatically. > Personally, I use it on the whole Pharo 3 months ago. > Cheers, > Jannik > > On Mar 18, 2010, at 23:37 , Mariano Martinez Peck wrote: > > 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 > _______________________________________________ > 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 > -- Lukas Renggli http://www.lukas-renggli.ch

March 19, 2010

Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

by Carla F. Griggio

I guess it depends on how you'd like to represent a date and time. We may have 2 representations here, the DateAndTime object and the string. If you consider that the string '1901-01-01T00:00:00+12:00' actually * represents* that day and time and it's not just the way you would print it, then I think it's valid to compare one representation and another of the same concept, because they really *mean* the same to you. If you see '1901-01-01T00:00:00+12:00' and say "that's not a date and time, it's just how I'd print it" maybe the only valid representation of the date and time for you is a DateAndTime object, then it doesn't make sense comparing de DateAndTime object with it's string. Personally, I think the string it's just the "print string", I agree with you. But maybe originally the people who implemented that comparison considered it as a date and time representation too, so it makes sense to compare them. On Wed, Mar 17, 2010 at 10:22 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > > > I would expect = to be > > "reflexive" self assert: (a = a). > > "symmetric" self assert: (a = b) ==> (b = a). > > "transitive" self assert: (a = b) & (b = c) ==> (a = c). > > > > Date>>= does not seem to meet my expectations > > Yes the more I think about it the more I'm against this automatic > conversion. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 19, 2010