- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] 10246

by StÃ©phane Ducasse

HI guys I declared victory over my new sink :) Now it is fixed here are some fixes and enh integrated please check if this is ok - Announcement latest version 13 - Polymorph toolbuilder fix 6 - Polymorph widgets 55 Fix for button for currently selected window in tasklist not being differentiated when using Watery 2 theme. - Scriptloader loadOBAlpha (damien) - Issue 619: Extend MessageTally to observe all processes - Issue 603: fix for NewParser parsability Stef

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Igor Stasenko

Looks nice (especially integration with notifications). Just a single straw hat man question: - how you dealing with a preferences which declared multiple times under the same name: MyAlphaClass class>>enabled <preference: 'enabled' type: #Boolean set: #setEnabled: default: #false description: 'Alpha thingy enabled'> MyBetaClass class>>enabled <preference: 'enabled' type: #Boolean set: #setEnabled: default: #false description: 'Beta thingy enabled'> it also seem would be nice to have a preference category name(s) 2009/3/2 Alain Plantec <alain.plantec(a)free.fr>: > Matthew Fulmer a Ã©crit : >> Did anybody ever notice my suggestion to use Magritte for >> Preferences? >> >> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.h… >> >> > Hi Matthew, > one should have answer something to you. sorry. > First I know what magritte is but I've never tried it so I can't give an > opinion if it is desirable, possible... > But magritte is not a part of Pharo-core. Is it planned to include it ? > What I'm trying to do (with a big help from Gary) is to implement a > proposition so people can > make their own opinion and say if it is ok or not. > I will post a new one soon (I hope), maybe you can have a look and > propose something Â with Magritte. > Cheers > alain > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 2, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

Matthew Fulmer a Ã©crit : > Did anybody ever notice my suggestion to use Magritte for > Preferences? > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.h… > > Hi Matthew, one should have answer something to you. sorry. First I know what magritte is but I've never tried it so I can't give an opinion if it is desirable, possible... But magritte is not a part of Pharo-core. Is it planned to include it ? What I'm trying to do (with a big help from Gary) is to implement a proposition so people can make their own opinion and say if it is ok or not. I will post a new one soon (I hope), maybe you can have a look and propose something with Magritte. Cheers alain

March 2, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

Michael Rueger wrote: > Philippe Marschall wrote: >> StÃ©phane Ducasse wrote: >>> I have problems to understand why this would be not reasonable that >>> people load a give kom version for seaside on squeak >>> and one for seaside on pharo. >> Loading is one thing. What bothers we more is the maintenance situation. >> Let's face it, there are far too resources behind something as important >> as Kom. Making a fork of it cuts these resources in half. > > Hmm, I think most of the discussion is simply a misunderstanding, I'm > not forking anything. > > With my changes to Pharo (which of course first need to be integrated), > the changed (not forked!) version of Kom and the few changes for Seaside > (which need to be integrated) there is no need for a fork!!! > > Those versions should work on both Squeak and Pharo. Very well then. Can you contact Giovanni to have your changes integrated at: http://www.squeaksource.com/KomHttpServer.html > It's not monkey patching, none of the packages touch other stuff any > more than they did before. I just changed Kom so its monkey patching now > works on both Seaside and Pharo. > > And that's where I need you help testing. I did a short test with Seaside 2.8 and Squeak 3.9 and it seems to work. Cheers Philippe

March 2, 2009

Re: [Pharo-project] loadOBApha

by StÃ©phane Ducasse

I probably thought that I integrated it I will try to do an update but I have to fix a sink for our kitchen now. Stef On Mar 2, 2009, at 3:40 PM, 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 >

March 2, 2009

[Pharo-project] Universes question

by Brian Brown

Hello all, I just downloaded pharo0.1-10243dev09.02.3 from the website and updated to the latest. I expected to see the Universe browser in the menus, but it isn't there, So I checked the image, and Universes is not there. I thought the Universes code was in the dev image.... what am I missing? Regards, - Brian

March 2, 2009

Re: [Pharo-project] Website

by Alexandre Bergel

Good! But I think that the download section on the website needs to be a bit more explicit. Something like maybe: Step 1: choose and download the Virtual Machine (VM) Step 2: download the SqueakV39.sources file Step 3: download either Pharo or Pharo-core. Step 4: drag and drop the .image file on the VM. Cheers, Alexandre On 2 Mar 2009, at 17:02, Adrian Lienhard wrote: > 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 > > > _______________________________________________ > 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] 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