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

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Alexandre Bergel

Esteban, this is excellent!! It would be cool to have Loader new infoAbout: 'ProjectName' Alexandre On 7 Jan 2010, at 20:45, Esteban Lorenzano wrote: >>> >> Yes, I agree. But don't worry. Esteban Lorenzano is working exatly >> in that. >> You will be able to do: >> >> Loader load: 'Pharo' version: '1.0' and wala!! >> >> (Esteban, correct me if I am wrong). >> >> However, this is yet in development and we are not even sure if this >> architecture will be the choosen one. We are just trying to see >> what we can >> doo. > > yep, that's true. Currently I'm alpha-testing it and writing some > tests > and documentation, but now you can do things like: > > Loader new list. "Lists all available projects, scanning all > repositories" > Loader new search: 'Blah'. "Looks for project Blah scanning all > repositories. 'Blah' can be a segment, not just a full name" > Loader new load: 'Blah'. "Load latest usable version of > ConfigurationOfBlah." > Loader new load: 'Blah' version: '1.0'. "Load '1.0' version of > ConfigurationOfBlah." > Loader new managed. "Answers a list of current managed projects." > Loader new update. "Updates configurations for all managed projects." > Loader new update: 'Blah'. "Updates ConfigurationOfBlah." > Loader new upgrade. "Upgrades all managed project to a newest version > (if present)". > Loader new upgrade: 'Blah'. "Upgrades project 'Blah' to a newest > version (if present)". > > You can specify permanent repositories by executing: > > Loader repository: 'http://myownrepo/project'. > Loader repository: 'http://myownrepo/project' username: 'myself' > password: 'secret'. > > (this acts as adding universes to apt-get of debian) > > And you can use "temporal" repositories: > Loader new > repository: 'http://myownrepo/project'; > load: 'Blah'. > > This repostories are dropped after use it, but any managed project > keeps it for future managing. > > I hope this will solve all the loading issues. In the future, you > could > do just: > > Loader new load: 'Pharo'. and get a full PharoDev image :) > > Cheers, > Esteban > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 8, 2010

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

by Torsten Bergmann

>I don't particularly like the naming. +1 Especially I dislike the "Morphic" in the name. When I implement a custom window I want to react on simple events/ announcements like Activated, MouseHover, WindowClosing, WindowClosed, SizeChanged, ... independent of the current UI frameworks name. I think WinForms (.NET) and Java UI builders are a good template to find appropriate names and events that should be supported at a minimum. This also reduces the changes when switching/porting/adapting code to a different/refactored UI framework in a possible "life after morphic" (TM) time. It will also allow for better naming of the event handler methods #onWindowClosed handling WindowClosed vs. #onMorphicCreationWindowAnnouncementAnnounced ;) just my 2 cents bye T. -- Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

Jan. 8, 2010

Re: [Pharo-project] Screencast in mac?

by Johan Fabry

Thanks all for the replies! I'll try some of these over the weekend. On 07 Jan 2010, at 18:50, James Foster wrote: > > On Jan 7, 2010, at 1:41 PM, Randal L. Schwartz wrote: > >>>>>>> "Johan" == Johan Fabry <jfabry(a)dcc.uchile.cl> writes: >> >> Johan> hot on the tail of Stans mail: I want to do some screencasts >> on a mac, >> Johan> maybe without audio. Good experiences anyone? >> >> Very happy with ScreenFlow, which not only captures full screen at >> full speed >> (without ever missing a frame), also has a great video editing >> suite built in, >> and can handle nice HD videos for Vimeo and Youtube HD. >> >> Yeah, it's $100 but worth it. > > At Randal's suggestion (some time ago), I got ScreenFlow and have > been very happy with it. > > James > >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 >> 777 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside >> discussion >> >> _______________________________________________ >> 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 -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Jan. 8, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Adrian Lienhard

This seems correct. The naming convention is: - "Pharo" for PharoCore + dev tools - "PharoCore" is the base Pharo image Adrian On Jan 8, 2010, at 13:12 , Esteban Lorenzano wrote: > btw, ConfigurationOfPharo shouldn't be ConfigurationOfPharoDev? > > On 2010-01-07 17:54:27 -0300, Mariano Martinez Peck > <marianopeck(a)gmail.com> said: > >> >> >> (Sorry for the long email) >> >> Yes, after a couple of weeks, I have written most of the needed >> Metacello >> configurations for the Dev images 1.0. Forget 1.1 for a while. Now >> we are >> able to: >> >> 1) Load stable version of packages >> 2) Manage the dependencies automatically >> 3) Each developer can create its custom PharoDev image >> 4) Flexibility to load the packages you want >> 5) Choose the browser for example: OB or O2 >> 6) Choose to load the tests or not >> 7) Load each package in a PharoCore image without having to install >> anything >> else (all the dependencies should be managed automatically) >> 8) You can take a PharoCore image and "transform" it to a Dev >> image, or even >> web. >> 9) Others... >> >> This is not completed yet. There are some things that we are >> discussing with >> Dale, but they are ok as a first step. I rather go step by step. >> >> What I did is to create all the infrastructure: >> >> a) The Configuration classes >> b) The dependencies >> c) the groups, >> >> In summary, most of the "structure" and static information. >> However, I am >> not sure which version to load of each package. I will probable >> take care of >> building the Dev images, but I won't: >> >> - Merge anything. It will not be my task to merge OB, or RB or >> whatever. >> - Check every version of each package before doing a release to see >> if it is >> stable or not. >> >> So...what I REALLY (actually, WE) need is that each developer, each >> maintainer of the packages that we load of a PharoDev image, help >> us to >> create the stable versions. To create a new version for the Metacello >> configuration is VERY easy, The hard part is already done. You just >> have to >> create a method and say which versions (except you create or >> eliminate >> packages or dependencies). If you read the code, you will probably >> understand it. However, you can read the Metacello tutorial (no >> more than >> one hour), or ask me or even more in the Metacello mailing list. >> So...PLEASE, I need the help of the maintainers to create the >> versions. So >> far, I created the first version (1.0) with the latest version. But >> the idea >> is that then you create 1.1.1 or 1.2 or whatever you consider. >> >> All the configurations can be found in >> http://www.squeaksource.com/MetacelloRepository >> >> So far, I created: ConfigurationOfNewInspector, >> ConfigurationOfOCompletion, >> ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtras, >> ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, >> ConfigurationOfShout , and......ConfigurationOfPharo!!! >> >> To install them, just download that package and evaluate the load. >> Example: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfShout'; >> load. >> >> ((Smalltalk at: #ConfigurationOfShout) project version: '1.0') load. >> >> And then, you can also for exaple do: >> >> ((Smalltalk at: #ConfigurationOfShout) project version: '1.0') >> load: 'Core' >> >> this doesn't install the tests. >> >> Or for example: (ConfigurationOfOmniBrowser project version: >> '1.0') load: >> 'Dev' >> >> etc... >> >> So, you can load any project and with the group you want. All of >> that can be >> (or should be hahahaha) perfectly loaded in a 1.0 Core image. >> >> What I would really appreciate is if each maintainer can look at >> the code, >> load the different groups and give me feedback on the dependencies or >> whatever. >> >> I really wait your feedback. >> >> Mariano >> >> ps: I will release soon the first dev image using this :) >> >> >> (Sorry for the long email) Yes, after a couple of weeks, I >> have writ= >> ten most of the needed Metacello configurations for the Dev images >> 1.0. For= >> get 1.1 for a while. Now we are able to: 1) Load stable >> version of p= >> ackages >> 2) Manage the dependencies automatically 3) Each developer can >> create it= >> s custom PharoDev image >> 4) Flexibility to load the packages you want 5) Choose the >> browser for e= >> xample: OB or O2 6) Choose to load the tests or not 7) Load >> each pack= >> age in a PharoCore image without having to install anything else >> (all the d= >> ependencies should be managed automatically) >> >> 8) You can take a PharoCore image and "transform" it to a >> Dev ima= >> ge, or even web. 9) Others... This is not completed yet. >> There a= >> re some things that we are discussing with Dale, but they are ok as >> a first= >> step. I rather go step by step. >> What I did is to create all the infrastructure: a) The >> Configura= >> tion classes b) The dependencies >> c)=A0 the groups, In summary, most of the >> "structure" and = >> static information. However, I am not sure which version to load of >> each pa= >> ckage. I will probable take care of building the Dev images, but I >> won'= >> t: >> >> - Merge anything. It will not be my task to merge OB, or RB or >> whatever= >> . - Check every version of each package before doing a release >> to see if= >> it is stable or not. So...what I REALLY (actually, WE) need >> is that= >> each developer, each maintainer of the packages that we load of a >> PharoDev= >> image, help us to create the stable versions. To create a new >> version for = >> the Metacello configuration is VERY easy, The hard part is already >> done. Yo= >> u just have to create a method and say which versions (except you >> create or= >> eliminate packages or dependencies). If you read the code, you will >> probab= >> ly understand it. However, you can read the Metacello tutorial (no >> more tha= >> n one hour), or ask me or even more in the Metacello mailing list. >> So...PLE= >> ASE, I need the help of the maintainers to create the versions. So >> far, I c= >> reated the first version (1.0) with the latest version. But the >> idea is tha= >> t then you create 1.1.1 or 1.2 or whatever you consider. >> All the configurations can be found in <a href=3D"http://www.squeaksour >> = >> ce.com/MetacelloRepository">http://www.squeaksource.com/MetacelloRepository= >> </a> So far, I created:=A0 ConfigurationOfNewInspector, >> Configuratio= >> nOfOCompletion, ConfigurationOfOmniBrowser, >> ConfigurationOfPharoMorphicExtr= >> as, ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, >> Configura= >> tionOfShout , and......ConfigurationOfPharo!!! >> To install them, just download that package and evaluate the >> load. Exam= >> ple: Gofer new =A0=A0=A0 squeaksource: >> 'MetacelloRepository&#= >> 39;; =A0=A0=A0 package: >> 'ConfigurationOfShout'; =A0=A0=A0 loa= >> d. ((Smalltalk at: #ConfigurationOfShout) project version: >> '1.0&= >> #39;) load. >> And then, you can also for exaple do:=A0 >> ((Smalltalk at: #ConfigurationOfShout) project version: >> '1.0') load= >> : 'Core'=A0 this doesn't install the tests. >> Or for = >> example:=A0 (ConfigurationOfOmniBrowser project version: >> '1.0') loa= >> d: 'Dev' >> etc... So, you can load any project and with the group >> you want.= >> All of that can be (or should be hahahaha) perfectly loaded in a >> 1.0 Core = >> image. What I would really appreciate is if each maintainer >> can look= >> at the code, load the different groups and give me feedback on the >> depende= >> ncies or whatever. >> I really wait your feedback. Mariano ps:=A0 I >> will relea= >> se soon the first dev image using this :) >> >> >> >> >> >> _______________________________________________ >> 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] [ANN] Metacello configurations for Pharo.

by Esteban Lorenzano

btw, ConfigurationOfPharo shouldn't be ConfigurationOfPharoDev? On 2010-01-07 17:54:27 -0300, Mariano Martinez Peck <marianopeck(a)gmail.com> said: > > > (Sorry for the long email) > > Yes, after a couple of weeks, I have written most of the needed Metacello > configurations for the Dev images 1.0. Forget 1.1 for a while. Now we are > able to: > > 1) Load stable version of packages > 2) Manage the dependencies automatically > 3) Each developer can create its custom PharoDev image > 4) Flexibility to load the packages you want > 5) Choose the browser for example: OB or O2 > 6) Choose to load the tests or not > 7) Load each package in a PharoCore image without having to install anything > else (all the dependencies should be managed automatically) > 8) You can take a PharoCore image and "transform" it to a Dev image, or even > web. > 9) Others... > > This is not completed yet. There are some things that we are discussing with > Dale, but they are ok as a first step. I rather go step by step. > > What I did is to create all the infrastructure: > > a) The Configuration classes > b) The dependencies > c) the groups, > > In summary, most of the "structure" and static information. However, I am > not sure which version to load of each package. I will probable take care of > building the Dev images, but I won't: > > - Merge anything. It will not be my task to merge OB, or RB or whatever. > - Check every version of each package before doing a release to see if it is > stable or not. > > So...what I REALLY (actually, WE) need is that each developer, each > maintainer of the packages that we load of a PharoDev image, help us to > create the stable versions. To create a new version for the Metacello > configuration is VERY easy, The hard part is already done. You just have to > create a method and say which versions (except you create or eliminate > packages or dependencies). If you read the code, you will probably > understand it. However, you can read the Metacello tutorial (no more than > one hour), or ask me or even more in the Metacello mailing list. > So...PLEASE, I need the help of the maintainers to create the versions. So > far, I created the first version (1.0) with the latest version. But the idea > is that then you create 1.1.1 or 1.2 or whatever you consider. > > All the configurations can be found in > http://www.squeaksource.com/MetacelloRepository > > So far, I created: ConfigurationOfNewInspector, ConfigurationOfOCompletion, > ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtras, > ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, > ConfigurationOfShout , and......ConfigurationOfPharo!!! > > To install them, just download that package and evaluate the load. Example: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfShout'; > load. > > ((Smalltalk at: #ConfigurationOfShout) project version: '1.0') load. > > And then, you can also for exaple do: > > ((Smalltalk at: #ConfigurationOfShout) project version: '1.0') load: 'Core' > > this doesn't install the tests. > > Or for example: (ConfigurationOfOmniBrowser project version: '1.0') load: > 'Dev' > > etc... > > So, you can load any project and with the group you want. All of that can be > (or should be hahahaha) perfectly loaded in a 1.0 Core image. > > What I would really appreciate is if each maintainer can look at the code, > load the different groups and give me feedback on the dependencies or > whatever. > > I really wait your feedback. > > Mariano > > ps: I will release soon the first dev image using this :) > > > (Sorry for the long email) Yes, after a couple of weeks, I have writ= > ten most of the needed Metacello configurations for the Dev images 1.0. For= > get 1.1 for a while. Now we are able to: 1) Load stable version of p= > ackages > 2) Manage the dependencies automatically 3) Each developer can create it= > s custom PharoDev image > 4) Flexibility to load the packages you want 5) Choose the browser for e= > xample: OB or O2 6) Choose to load the tests or not 7) Load each pack= > age in a PharoCore image without having to install anything else (all the d= > ependencies should be managed automatically) > > 8) You can take a PharoCore image and "transform" it to a Dev ima= > ge, or even web. 9) Others... This is not completed yet. There a= > re some things that we are discussing with Dale, but they are ok as a first= > step. I rather go step by step. > What I did is to create all the infrastructure: a) The Configura= > tion classes b) The dependencies > c)=A0 the groups, In summary, most of the "structure" and = > static information. However, I am not sure which version to load of each pa= > ckage. I will probable take care of building the Dev images, but I won'= > t: > > - Merge anything. It will not be my task to merge OB, or RB or whatever= > . - Check every version of each package before doing a release to see if= > it is stable or not. So...what I REALLY (actually, WE) need is that= > each developer, each maintainer of the packages that we load of a PharoDev= > image, help us to create the stable versions. To create a new version for = > the Metacello configuration is VERY easy, The hard part is already done. Yo= > u just have to create a method and say which versions (except you create or= > eliminate packages or dependencies). If you read the code, you will probab= > ly understand it. However, you can read the Metacello tutorial (no more tha= > n one hour), or ask me or even more in the Metacello mailing list. So...PLE= > ASE, I need the help of the maintainers to create the versions. So far, I c= > reated the first version (1.0) with the latest version. But the idea is tha= > t then you create 1.1.1 or 1.2 or whatever you consider. > All the configurations can be found in <a href=3D"http://www.squeaksour= > ce.com/MetacelloRepository">http://www.squeaksource.com/MetacelloRepository= > </a> So far, I created:=A0 ConfigurationOfNewInspector, Configuratio= > nOfOCompletion, ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtr= > as, ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, Configura= > tionOfShout , and......ConfigurationOfPharo!!! > To install them, just download that package and evaluate the load. Exam= > ple: Gofer new =A0=A0=A0 squeaksource: 'MetacelloRepository&#= > 39;; =A0=A0=A0 package: 'ConfigurationOfShout'; =A0=A0=A0 loa= > d. ((Smalltalk at: #ConfigurationOfShout) project version: '1.0&= > #39;) load. > And then, you can also for exaple do:=A0 > ((Smalltalk at: #ConfigurationOfShout) project version: '1.0') load= > : 'Core'=A0 this doesn't install the tests. Or for = > example:=A0 (ConfigurationOfOmniBrowser project version: '1.0') loa= > d: 'Dev' > etc... So, you can load any project and with the group you want.= > All of that can be (or should be hahahaha) perfectly loaded in a 1.0 Core = > image. What I would really appreciate is if each maintainer can look= > at the code, load the different groups and give me feedback on the depende= > ncies or whatever. > I really wait your feedback. Mariano ps:=A0 I will relea= > se soon the first dev image using this :) > > > > > > _______________________________________________ > 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 Henrik Johansen

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

Jan. 8, 2010

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

by Gary Chambers

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]. >> window := SystemWindow labelled: 'foo'. >> window openInWorld. >> >> self assert: (t = 1). >> self assert: (window == newWindowCreated). >> window delete. >> >> self assert: (t = 11). >> self assert: (window == newWindowCreated). >> -=-=-=-=-=-=-=-=-=-=-=-= >> If everybody agrees on this, it would be cool to include it in Pharo >> soon. At each new version of Morphic, I will have to update this, and >> this is boring. > > Yes I would be happy. I did not want to push this change because I could > not assess > the impact in term of slowdown. Now if we get an ok from gary and/or > others > this is ok for me. > >> >> The comment of the .mcz is >> -=-=-=-=-=-=-=-=-=-=-=-= >> This new version extends Morphic with a window event mechanism. >> It add a variables to SystemWindow (thus implies a recompilation of >> all subclasses of SystemWindow). >> It does some overrides in: >> - SystemWindow: for deletion, resize, ... >> - ScrollPane: notification for scrolling. This part is probably not >> nicely designed, but it works > > what is the increment of notification because it can geenrate a lot of > events? > >> - PasteUpMorph: World can now emit event for window creation and >> deletion >> >> The method SystemWindow>>openAsIsIn: is overriden. The new version >> belongs to Morphic, before it belonged to Polymorph. Loading this >> version make Polymorph dirty therefore. >> >> 5 test methods are provided in MorphicWindowNotificationTest. All >> tests are green in a pharo1.0-10502-rc1dev09.12.2 >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Comments are welcome >> >> Cheers, >> Alexandre >> >> >> On 7 Jan 2010, at 10:58, Gary Chambers wrote: >> >>> Fair enough. Perhaps the "global" announcer could be accessed via the >>> class-side of SystemWindow. >>> >>> Lots of evil ways of manipulating morphs too. Just thought about >>> hide/show >>> etc. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Thursday, January 07, 2010 1:28 PM >>> Subject: Re: [Pharo-project] Notifications of windows opening/ >>> closing/focus >>> >>> >>>> >>>> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: >>>> >>>>> That is one option, though it does seem to be burdensome on the >>>>> announcement >>>>> consumers to (depending upon requirements) possibly have to track >>>>> all >>>>> windows themselves. >>>>> >>>>> Regards, GaryI am not talking about Announcers, but where the >>>>> Announcement is created. >>>> >>>> I'm not talking about letting the window be the announcer, but >>>> where the >>>> announcement is made. >>>> >>>> So you'd do >>>> openAsIsIn: aWorld >>>> "current implementation" >>>> someAnnouncer announce: (WindowOpened for: self in: self world) >>>> >>>> someAnnouncer could be a global announcer for all window events. >>>> >>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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

[Pharo-project] [update 1.1] #11139

by Marcus Denker

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!

Jan. 8, 2010

Re: [Pharo-project] Finalization quirk

by Adrian Lienhard

ah, I see. I looked in PharoCore and hence didn't find it. These are from Damien's www.squeaksource.com/ImageForDevelopers.html We should integrate one default policy into PharoCore. What would be a sensible default? Cheers, Adrian On Jan 8, 2010, at 01:10 , John M McIntosh wrote: >> initializeMemorySettingsProfileSeaSide > > is in the pharo image also initializeMemorySettingsProfileQF which I > have no idea about... > > On 2010-01-07, at 2:12 AM, Adrian Lienhard wrote: > >> >> On Jan 6, 2010, at 22:09 , John M McIntosh wrote: >> >>> Oh sure Bill you're violating rule (a). In squeak a full >>> finalization pass is require to finalize all objects. >>> This runs in to the Pharo's desire to only do incremental GCs and >>> avoid a full GC. >>> >>> SystemDictionary>>setGCParameters >>> >>> Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. >>> Smalltalk setGCBiasToGrow: 1. >>> >>> Which means that the image is happy to lurch around with a 16MB >>> working space. Once that is exceeded then a full GC will occur. >>> (yes yes, it's more complex that that, but it's just easier to say >>> that's kinda what happens). The trade is deferring a full GC at >>> the cost >>> of deferring some finalized objects.... >>> >>> Frankly the default values for vmParameterAt: 5,6,24,25 I think >>> are quite fictional based on desktop/laptop machines used in this >>> decade, >>> those values come from the era of 16Mhz 68030 macintosh SE/30 >>> machines. However I do see that in >>> initializeMemorySettingsProfileSeaSide >>> someone picked more rational numbers but I think it's time that we >>> clean those up this whole area. >> >> Where can I find #initializeMemorySettingsProfileSeaSide? Could you >> propose new parameters for these settings? It's time to adjust them >> for the new decade ;) >> >> Cheers, >> Adrian >> >> >> [...] > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > >

Jan. 8, 2010

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

by StÃ©phane Ducasse

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

Jan. 8, 2010