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

Re: [Pharo-project] GUI how to screencast available

by StÃ©phane Ducasse

I found that the addMorph: fullFrame: nil to indicate that the button expand into it container is not really a sexy interface. On Jan 8, 2010, at 9:01 PM, laurent laffont wrote: > Hi, > > as I'm beginning to understand how to write a GUI in Pharo, I've made a screencast to show basic layout techniques with panels and buttons: > > http://vimeo.com/8619593 > > (or on my blog :) with source code http://magaloma.blogspot.com/2010/01/gui-et-pharo.html ) > > > It seems that several people have or plan to record screencasts on Pharo. If you can send me links, I can put all of them on a single blog. For example http://pharocasts.org ;). > > Cheers, > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

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

by Michael Roberts

unfortunately, it looks like this update has killed my build server. This image can no longer file in scripts from the command line. it looks like asUrl was removed from String. was this intentional? thanks, Mike On Fri, Jan 8, 2010 at 10:37 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 11139 > ----- > > Issue 1753: Â Â results of cycle cleaning experiment > > on 7.1.2010 we used Jannik's tool to find cyclic dependencies between packages. We started to > clean the easy ones. > > In addition, some unsent methods where removed: > > Array removeSelector: #evalStrings! > Collection removeSelector: #chooseOne:! > FileDirectory removeSelector: #directoryObject! > FileDirectory removeSelector: #updateProjectInfoFor:! > HTTPSocket class removeSelector: #httpShowGif:! > HTTPSocket class removeSelector: #httpShowJpeg:! > HTTPSocket class removeSelector: #retry:asking:ifGiveUp:! > HTTPSocket class removeSelector: #showImage:named:! > Preferences class removeSelector: #swapMouseButtons! > String removeSelector: #asIRCLowercase! > TextMorphEditor removeSelector: #selectAndScrollToTop! > TextMorphEditor removeSelector: #selectForTopFrom:to:! > TextMorphEditor removeSelector: #userHasNotEdited! > PreferenceBrowserMorph class removeSelector: #updateBrowsers! > WideString class removeSelector: #allMultiStringMethods! > WideString class removeSelector: #allNonAsciiMethods! > Utilities class removeSelector: #assureAvailabilityOfUnstableUpdateStream! > Utilities class removeSelector: #broadcastUpdatesFrom:to:except:! > Utilities class removeSelector: #fileInFromUpdatesFolder:! > Utilities class removeSelector: #initializeClosures! > Utilities class removeSelector: #openRecentSubmissionsBrowser! > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 8, 2010

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

by Nicolas Cellier

http://code.google.com/p/pharo/issues/detail?id=1760 2010/1/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Anything to do with moving methods from one package to another ? > > Yes this is that > >> Because Andreas fixed that in trunk/Monticello version (do not remove >> the method if it already belongs to another package). > > Ok we should check then. > Thanks for the information. > > >> >> Nicolas >> >> 2010/1/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> cool >>> Marcus this afternoon with finished the removal of Project isolation layers >>> so we will be able to clean >>> Â Â Â Â ChangeSet (isolation layer cat) >>> Â Â Â Â Project a bit more :) >>> >>> over the week end when the house got fixed a bit more and the project is published I >>> want to have a look at fileStream speed improvement >> >> Good thing! That's not that difficult. >> >>> >>> Stef >>> On Jan 8, 2010, at 9:11 PM, Marcus Denker wrote: >>> >>>> Issue 1759: Â lost methods after 11140 >>>> >>>> _______________________________________________ >>>> 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 >

Jan. 8, 2010

Re: [Pharo-project] GUI how to screencast available

by StÃ©phane Ducasse

laurent this is reallllllly cool! I love videos! Please do more Stef On Jan 8, 2010, at 9:01 PM, laurent laffont wrote: > Hi, > > as I'm beginning to understand how to write a GUI in Pharo, I've made a screencast to show basic layout techniques with panels and buttons: > > http://vimeo.com/8619593 > > (or on my blog :) with source code http://magaloma.blogspot.com/2010/01/gui-et-pharo.html ) > > > It seems that several people have or plan to record screencasts on Pharo. If you can send me links, I can put all of them on a single blog. For example http://pharocasts.org ;). > > Cheers, > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

Re: [Pharo-project] GUI how to screencast available

by StÃ©phane Ducasse

good idea. Stef On Jan 8, 2010, at 9:01 PM, laurent laffont wrote: > Hi, > > as I'm beginning to understand how to write a GUI in Pharo, I've made a screencast to show basic layout techniques with panels and buttons: > > http://vimeo.com/8619593 > > (or on my blog :) with source code http://magaloma.blogspot.com/2010/01/gui-et-pharo.html ) > > > It seems that several people have or plan to record screencasts on Pharo. If you can send me links, I can put all of them on a single blog. For example http://pharocasts.org ;). > > Cheers, > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by StÃ©phane Ducasse

On Jan 8, 2010, at 9:38 PM, Schwab,Wilhelm K wrote: > Stef, > > I find it difficult to imagine your being dull on anything, but I guess we all have limits. :) > I have been pushing a little firmly on weak collections because Squeak/Pharo are _way_ behind where Dolphin was 12+ years ago, and it seems avoidable. Yes I imagine well. > So far I have created very simple thread safe (hopefully) wrappers around Dictionary (SharedLookupTable) and Set. The dictionary can be weak in keys or values. I subclass from Object to minimize problems with super classes filling gaps w/o my knowledge. this is why I suggest you publish some code in the PharoTaskForces and get some arguments with others and we all learn :)

Jan. 8, 2010

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

by StÃ©phane Ducasse

> Anything to do with moving methods from one package to another ? Yes this is that > Because Andreas fixed that in trunk/Monticello version (do not remove > the method if it already belongs to another package). Ok we should check then. Thanks for the information. > > Nicolas > > 2010/1/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> cool >> Marcus this afternoon with finished the removal of Project isolation layers >> so we will be able to clean >> ChangeSet (isolation layer cat) >> Project a bit more :) >> >> over the week end when the house got fixed a bit more and the project is published I >> want to have a look at fileStream speed improvement > > Good thing! That's not that difficult. > >> >> Stef >> On Jan 8, 2010, at 9:11 PM, Marcus Denker wrote: >> >>> Issue 1759: lost methods after 11140 >>> >>> _______________________________________________ >>> 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

Jan. 8, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Schwab,Wilhelm K

Stef, I find it difficult to imagine your being dull on anything, but I guess we all have limits. I have been pushing a little firmly on weak collections because Squeak/Pharo are _way_ behind where Dolphin was 12+ years ago, and it seems avoidable. So far I have created very simple thread safe (hopefully) wrappers around Dictionary (SharedLookupTable) and Set. The dictionary can be weak in keys or values. I subclass from Object to minimize problems with super classes filling gaps w/o my knowledge. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, January 08, 2010 3:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus I'm dull on this kind of topics ;) and this is why I listen and try to understand from the discussion. I learned a lot this year already on a lot of topics (float, complex....) stef On Jan 8, 2010, at 7:23 PM, Schwab,Wilhelm K wrote: > Stef, > > Fair enough. What do you think of the shared lookup table I posted? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > StÃ©phane Ducasse > Sent: Friday, January 08, 2010 5:06 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Notifications of windows > opening/closing/focus > > Build something and propose it. > Continue to discuss and get a group of people working on the solution. > Good solution should emerge but code is important. > > Stef > >> Henry, >> >> Then we need to fix the weak collections. Dolphin (of the mid-90's) already had thread-safe weak collections and a high-priority process to detect and clean up "damage" to them; it's time to catch up. >> >> The more I think about it, your idea is sounding a lot like the dependency days of MVC - remember #release? I'm trying to forget. >> >> I am not trying to be confrontational, but we can and should do better than this. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Henrik Sperre Johansen >> Sent: Thursday, January 07, 2010 8:27 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Notifications of windows >> opening/closing/focus >> >> On 08.01.2010 02:07, Schwab,Wilhelm K wrote: >>> Henry, >>> >>> No argument, your solution is simpler. However, we do not have announcements like this now, and it appears that the poor state of weak collections in Squeak/Pharo is standing in the way of a clean implementation. My vote is to tackle the weaklings, at least until they work well enough to support what we should have in this case. Otherwise, we kick the weak can down the road as has been done all along rather than fixing it, AND we end up with a sub-standard announcments-based framework. >>> >>> Let's do it right. We will then have an evolving/improving weak collection and something in the image that puts some stress on same. If I'm missing something, please enlighten me. >>> >>> Bill >>> >> Weak collections does not stand in the way of making the use case of unregistering dynamic registrations manually easier. >> They stand in the way of the use case of unregistrating registeration automatically. >> >> Here's what you're missing: >> No matter how you implement the automatic unregistering, it will be nondetermenistic, for the exact same reasons finalization is nondeterministic. >> Thus, if you require deterministic unregistration, you have to do it manually, and the use case of making that easier to do have value in its own right. >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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

Jan. 8, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Gary Chambers

If "after the fact" I'd vote for the "ed" suffix too. Make it match what is/has happening/happened. As a side note, WindowClosing is common to give a potential veto chance (i.e. deny close). Should also be a WindowClosed if it does get that far... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, January 08, 2010 8:19 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus Alexandre as soon as we will got the names right publish, add a bug tracker item and this will be integrated now about the names Closing or Closed? Collapsed? WindowMoved? what is the convention? when the event happens at the end I would prefer ed when it occurs over a long action ing any english-oriented/design remarks? ? > > Alexandre > > > <Picture 3.png> > > > On 8 Jan 2010, at 08:57, Henrik Johansen wrote: > >> On Jan 8, 2010, at 11:56 18AM, Gary Chambers wrote: >> >>> Looks ok to me. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Thursday, January 07, 2010 8:27 PM >>> Subject: Re: [Pharo-project] Notifications of windows >>> opening/closing/focus >>> >>> >>>> >>>>> Hi! >>>>> >>>>> In the PharoTaskForces SqueakSource repository I committed a new >>>>> version of Morphic (Morphic-Alexandre_Bergel.393). This version >>>>> includes the window announcement I have been working on for few months >>>>> already. >>>>> >>>>> Here is an example of a unit test. >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> MorphicWindowNotificationTest>>testWindowCreationAndDeletion >>>>> >>>>> | t window newWindowCreated r | >>>>> t := 0. >>>>> World announcer on: MorphicCreationWindowAnnouncement do: [:ann | >>>>> t := t + 1. newWindowCreated := ann window]. >>>>> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t := >>>>> t + 10. newWindowCreated := ann window]. >> I don't particularly like the naming. >> >> - Why including Announcement at the end? >> - Why does one contain a verb, and the other a >> - When are they fired? Closing implies to me it's not been closed yet, >> but fired somewhere after the closing has started, while CreationWindow I >> have no idea what means. >> >> MorphicWindowOpen(ed/ing) >> MorphicWindowClos(ed/ing) >> >> are both easier to read for me, shorter, and more in line with the naming >> convention for Pragma announcements already in Pharo. >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > 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. 8, 2010

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

by Nicolas Cellier

Anything to do with moving methods from one package to another ? Because Andreas fixed that in trunk/Monticello version (do not remove the method if it already belongs to another package). Nicolas 2010/1/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > cool > Marcus this afternoon with finished the removal of Project isolation layers > so we will be able to clean > Â Â Â Â ChangeSet (isolation layer cat) > Â Â Â Â Project a bit more :) > > over the week end when the house got fixed a bit more and the project is published I > want to have a look at fileStream speed improvement Good thing! That's not that difficult. > > Stef > On Jan 8, 2010, at 9:11 PM, Marcus Denker wrote: > >> Issue 1759: Â lost methods after 11140 >> >> _______________________________________________ >> 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. 8, 2010