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

Re: [Pharo-project] A point a.k.a excuse to you

by Matthew Fulmer

On Mon, Mar 02, 2009 at 11:46:47AM +0000, Keith Hodges wrote: > > > > I believe you are correct, but not everybody sees Pharo that > > way. Edgar and Keith in particular, sometimes see it as > > non-appreciation of their work, which is similar in spirit, but > > not as well managed. > > > Matthew, > > My response to pharo is based upon the ironic situation. > > I say for 3.11 "Lets promote a process to enable integration and sharing > of the contributions of the community, accross the diverse range of > images that we use" Pharo team says "Lets go off and do our own thing", > and Edgar says the same. I find this totally ironic and sad, since you > couldn't create more fragmentation of the main squeak protagonists if > you tried. Well, for one thing, our tools were not ready for mainstream use when Pharo/Sapphire was announced. From what I can tell, the tools are just now coming to that point. We cannot expect that everybody will stop what they are doing just to alpha-test our tools. If they do, great, but if not, don't be mellow over it. > Now of course the whole point of the tools we have been working on, for > 3.11 Bob etc, is to allow diversification, so we should welcome all of > pharos efforts and innovations, and any like it. You seem puzzled as to > why I don't appreciate pharo. Do you appreciate Pharo? > The problem arises when no-sharing is done of the fundamental components > that make the sharing possible. For example SUnit needs to be a common > piece. It has to be there is no option. So if you do a fork and within > your fork you fork your own version of SUnit, you are snubbing the rest > of the community, and any possibility of working with the rest of the > community, either by ignorance or on purpose. Not everything needs to be "for the community". If we insist that it be so, we lose developers due to restrictive policy. It is more important that those who are good at fixing code (Pharo) do so, and leave the "giving it back to the community" to those who really care about it, like you and me. Pharo is providing a valuable service as a test-bed for new ideas and things that are not backward compatible. We will be providing a service to bring more commonality to the community. Both are important, and neither should halt on behalf of the other. > This has to be a managed policy decision, from the top. It is precisely > because the pharo project is not managed and planned with any such > principles in mind, that I stress my point, and will continue to do so. The lack of such concern is a good thing. > In reference to recent discussions about Preferences how am I going to > write any common code between pharo and squeak, if the preferences api > is different, between squeak and pharo? Note that the tools and > preference system can be as different as you like, but the API has to be > common at some level for any sharing to be possible. We either keep the > same api we have, or design a new one, and provide a basic specification > that can be implemented in both environments. Or, put both in for a release or two, where the old is deprecated, then remove the old after a release or two. > What we cant accept is any proposals or discussion about such an > important API without appreciating that it will be expected to support > code that comes from both environments. Such a restrictive policy is the best way to ensure that nothing will ever change, and that somebody will fork to get away from such management overhead. > The fact that 'Author' exists only as a global in the Pharo environment > and prevents code which uses it from loading in squeak is all the proof > I need that the pharo process needs a rethink. It can be backported, or ported in full, if it is a win. Traits are a win, and we backported them to 3.8 for Monticello 1.5. I don't see why we can't do that again. We can provide the service of backporting good ideas to other distributions. It will be easier when Pharo adopts Bob to some degree, but nothing prevents us from doing it now. There is a reason that Linux distributions are made of packages that are not maintained by the original coders, and that is because distribution of packages takes time. If somebody is better at coding, they should code. If somebody is better at packaging, they should package. Specialization is a good thing; everybody is more productive in the end, and has more fun, because each one is adding value while doing what they love. Always have fun. If you have fun on Pharo, than do Pharo. If you have fun on tools, then do tools. There are enough people in the world that somebody will have fun working with both, and will bridge whatever gap has formed. I believe I am such a person. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Matthew Fulmer

On Mon, Mar 02, 2009 at 01:59:03PM +0100, Alain Plantec wrote: > or simply : > > FreeTypeSettings class>>monitorTypeLCD > <preference:'LCD monitor type' type:#Boolean decsription:'Use of a LCD...'> > ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue default:false] Did anybody ever notice my suggestion to use Magritte for Preferences? http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.h… ----- Forwarded message from Matthew Fulmer <tapplek(a)gmail.com> ----- From: Matthew Fulmer <tapplek(a)gmail.com> To: pharo-project(a)lists.gforge.inria.fr Date: Mon, 16 Feb 2009 15:15:55 -0500 Subject: Re: [Pharo-project] Preferences refactoring On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote: > On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote: > > So, for new browser it needs to be decided what information to show as this > > will affect the pragma. > > For instance, do we still want categories, "project specific" (probably not) > > etc. > > > > I expect we will want a Preference class either way to model each preference > > in the browser. > > Making a new browser is quite an undertaking given the different types of > > preference (boolean, text, one-of-many, colour, font etc.). > > I think Magritte is the proper solution. It already handles UI > metadata like this. Something like this: prefTheme <preference category: 'User Interface'> ^ MASingleOptionDescription new options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); reference: MAStringDescription new; autoAccessor: 'theme'; label: 'Theme'; priority: 40; beSorted; yourself > Regarding preferences being optional, I think just a few tweaks > to the MC loader would work: If the Preferences Browser is not > loaded, MC will not compile the methods that return the Magritte > metadata. If this is done properly, as in MC1.5, these methods > will hang out uncompiled in the orphanage until you load the > preferences package, at which point they will be loaded into the > image. This is completely wrong. In the above example, if Magritte was not loaded, MASingleOptionDescription will bind to Undeclared. Then, if Magritte is ever loaded, it will notice the reference in Undeclared, and recompile this method to act correctly. > Out-of-order package loading is nice. Out-of-order loading, in the form of global references, has been supported since smalltalk-76 by the Undeclared object. The MC1.5 orphanage supports another kind of out-of-order loading, in addition to that supported by Undeclared. But it is irrelavant in this example. ----- End forwarded message ----- -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 2, 2009

Re: [Pharo-project] SortedCollection>>median

by Miguel Enrique CobÃ¡ MartÃnez

Adrian Lienhard wrote: > On Mar 2, 2009, at 09:00 , StÃ©phane Ducasse wrote: > >> This reminds me some thoughts about time and date. >> >> Originally date and time were ok but not so great. >> Then one guy (brent) fixed it and people were happy and it was >> introduced in the base system. >> At that time when time was introduced (in 3.7 I guess) it was a >> obvious choice. >> Then chronos and aconcagua went out showing some other properties. >> >> Now retrospectively I think that it would be better to have a minimal >> version in the system and >> loadable external package. There are some exceptions to this strategy: >> announcements and regexp >> (where this is more a language decision), but in general this is a >> good strategy > > I think a good rule of thumb is whether the code is used by the > kernel. Having packages like Regex and Announcements in the core makes > only sense if they are also used in the core. Else they would better > be external packages. Then why not structure the packages in 3 parts: core- All needed to bootstrap a minimal image (kernel, packages to install more packages, logging, scripting,etc) base- All the packages that have various versions but the included one is the prefered, suggested, standarized to (Announcements, SUnit, etc) universes/distros/monticellos/squeaksources- all the packages existing and *easily* loadable by the users Then, with a core image, and a script, you can create a base image. With a base image and a script or a GUI, you can create your very own image (e.g. Damien Cassou's images) Regards, Miguel CobÃ¡ > > Not sure about median, though, as for just one method you wouldn't > want to create and load an extra package... > > Adrian > >> >> So we could rename median naiveMedian and have a package that does all >> the rest and >> that people can load it. >> >> Stef >> >> _______________________________________________ >> 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 2, 2009

Re: [Pharo-project] Website

by Adrian Lienhard

Hi Alex, I copied the links over to the web page (http://www.pharo-project.org/download ). I suggest that we remove them on the wiki and link to that page (except for the links that are specific to the development of Pharo, that is, the "Pharo from scratch" links), so that we don't need to maintain two sets of links. Cheers, Adrian On Mar 2, 2009, at 13:10 , Alexandre Bergel wrote: > Hi All, > > The download section of the website is rather incomplete. > >> http://www.pharo-project.org/download > > I added a while ago a couple of sentences in the download section on > the google website. Maybe the pharo-project.org web administrator > could cut&paste it. I could accessory do it, however I do not have an > access to the cmsbox. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

March 2, 2009

Re: [Pharo-project] loadOBApha

by Alexandre Bergel

Thanks Damien for letting us know. Anyone can provide an update? Cheers, Alexandre On 2 Mar 2009, at 15:40, Damien Cassou wrote: > On Mon, Mar 2, 2009 at 2:53 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> It seems that the RB is not loaded with loadOBAlpha >> >> Anything changed with the following universe definition? > > I fixed #loadOBAlpha, but it went to PharoTreatedInbox instead of > going to Pharo, I don't know why. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] split/join

by Alexandre Bergel

Thanks, Alexandre On 2 Mar 2009, at 11:48, CÃ©drick BÃ©ler wrote: >> What is split/join? > > I guess: > > #(1 2 3) joinWith: ', ' -> '1, 2, 3' > > '1:2:3' splitOn: $: -> #(1 2 3) > > It's more a perl shard no ? :) > > Cheers, > > -- > CÃ©drick > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] loadOBApha

by Damien Cassou

On Mon, Mar 2, 2009 at 2:53 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > It seems that the RB is not loaded with loadOBAlpha > > Anything changed with the following universe definition? I fixed #loadOBAlpha, but it went to PharoTreatedInbox instead of going to Pharo, I don't know why. -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

[Pharo-project] loadOBApha

by Alexandre Bergel

Dear List, It seems that the RB is not loaded with loadOBAlpha Anything changed with the following universe definition? self new universalInstaller universe update; addPackage: 'Shout'; addPackage: 'AST'; addPackage: 'Refactoring Core'; install. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2009

Re: [Pharo-project] UIManager>>request: does notsendProvideAnswerNotification anymore

by Damien Cassou

Thank you very much Gary. On Mon, Mar 2, 2009 at 12:27 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > In Polymorph-ToolBuilder-gvc.6 on SqueakSource. > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 02, 2009 10:43 AM > Subject: Re: [Pharo-project] UIManager>>request: does > notsendProvideAnswerNotification anymore > > >> Indeed this is the case with Polymorph. I'll see what I can do. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Damien Cassou" <damien.cassou(a)gmail.com> >> To: "Gary Chambers" <gary(a)pinesoft.co.uk>; "Pharo Development" >> <pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, March 02, 2009 10:35 AM >> Subject: [Pharo-project] UIManager>>request: does not >> sendProvideAnswerNotification anymore >> >> >>> Hi, >>> >>> it seems that calling #request: does not trigger a >>> ProvideAnswerNotification. This notification is used by >>> #valueSuppressingMessages:supplyingAnswers: to automatically fill text >>> requests. >>> >>> Can somebody check that? >>> >>> [UIManager default request: 'Please choose a username for\the >>> application ' withCRs , 'config' printString] >>> Â Â Â Â Â Â Â Â valueSuppressingMessages: Array new supplyingAnswers: >>> (Array with: (Array with: '.*username.*' with: 'admin')) >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> _______________________________________________ >>> 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 > -- Damien Cassou http://damiencassou.seasidehosting.st

March 2, 2009

Re: [Pharo-project] Dynamic dead code alpha version

by StÃ©phane Ducasse

I traced a bit my problem (using the approach of alain: DNU recompiling methods and recompiling the methods) on Morph, what is strange is that I could install some methods but from time to time it blocks my image. I have the impression that this is related to the UI event (I closed all windows and remov dockingsbar from the methods that I instrument but it still freezes in a non really reproduceable manner. Is there a higher priority thread refreshing everything.... I still do not understand why if the DNU reinstall the old methods, the system blocks. Building hypotheses is then difficult because I have no tool to verify them. Stef

March 2, 2009