- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Morphic

by Levente Uzonyi

On Mon, 20 Sep 2010, Jimmie Houchin wrote: > On 9/20/2010 11:33 AM, Hilaire Fernandes wrote: >> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>>> Really I don't understand CUIS long term objective, why this work is not >>>> done in Pharo? They share the same vision. >>> You could ask the same question with Pharo and Squeak instead of Cuis >>> and Pharo, couldn't you? >> No, I can't. >> >> Pharo provides me a clear vision I can trust: a Smalltalk environment >> to build third party applications (ie makes my developer life easier). >> Squeak does not provide me this thrust nor indication of that direction. >> You can object it is matter of point of view, I will object it is a >> matter of ressources you can allocate to write an application. Mine are >> limited: I start writing DrGeo under Squeak, then I continued with >> Pharo. I can really fell the difference: nice Widgets, cleaner system I >> can understand, ease to integrate changes/improvements upstream. All in >> all, I get the job done more nicely from my perspective. > > I too agree. It is very nice to have a clean, clear vision statement in which > the community can put its resources behind to accomplish. We can accomplish > more together than each alone. The whole is greater than the sum of its > parts. Without a unifying vision, you have the sum of its parts. With a > vision, you have common goal, a unifying purpose. You have something that can > inspire. Something that can guide, in where to draw lines, what to add, what > to cut, what belongs in, what belongs out. > > You can do most anything in either Squeak or Pharo that you can do in the > other. But ultimately I believe that Pharo is moving in a direction which > empowers more people. Many of the Squeak users can use Squeak for most > anything they need or want, primarily because they are very skilled/expert in > both Smalltalk/Squeak and also interfacing outside systems via FFI, Alien, > plugins, etc. But for those of us who are not so able, who do not have the > training or knowledge, Pharo's vision and implementation therefore will IMHO > be more enabling and empowering, especially to the less than expert, the > little guy. And when Pharo achieves the smaller cleaner core, it will also be > more enabling/empowering to the expert. > > Pharo is explicitly more business friendly in its vision, goals, leadership > and community. > > I am a huge advocate of business in open source. I think as business prospers > within the Squeak/Pharo communities that the community improves as does the > artifact itself. It is my opinion that Pharo is explicitly more open towards > this synergy with business. Squeak is not necessarily against such, but is > more of the perspective of we happen to be walking together in the same > direction. > > Pharo is explicitly pro-business. > Squeak will not prohibit, but not really support. And yes I know there are > businesses based upon Squeak, but primarily owned and operated by experts. > > For me my initial push into Pharo came simply from wanting/requiring/desiring > code completion in workspaces and the browsers. Squeak was and is broken on > OCompletion. And I did not see any other alternatives. I read all the > messages, tried many things. No success. Even today the issue pops up again > on the list. 5 months after the last series of messages which had no clear > answer on how to get it working in Squeak. Pharo it just worked out of the > box. And thank you Levente for showing how to get it working in Squeak. > > That might be a little thing, but it is an important thing and it highlights > some of the differences and goals of the two projects and communities. > > I am not against Squeak. I would that we were all one big happy family > putting all our energies into something that works for all. But that is not > the case and one has to choose where to put ones energies and time. Hopefully > most efforts will be usable by both. But as each diverge that may be > increasingly difficult. > > I presently do not see a Pro-business or even particularly business-friendly > vision from Squeak. > > Just my perspective and opinions. Thanks, this is really helpful. The only thing I don't really get is what do you mean by "pro-business" and "business-friendly". What makes Pharo "pro-business"? The pre-installed tools? The familiar looking default UI? (only for mac users) Levente > > Thanks. > > Jimmie > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Levente Uzonyi

On Mon, 20 Sep 2010, Hilaire Fernandes wrote: > Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >> >>> Really I don't understand CUIS long term objective, why this work is not >>> done in Pharo? They share the same vision. >> >> You could ask the same question with Pharo and Squeak instead of Cuis >> and Pharo, couldn't you? > > No, I can't. > > Pharo provides me a clear vision I can thrust: a Smalltalk environment > to build third party applications (ie makes my developer life easier). > Squeak does not provide me this thrust nor indication of that direction. When was the last time you used Squeak? > You can object it is matter of point of view, I will object it is a > matter of ressources you can allocate to write an application. Mine are > limited: I start writing DrGeo under Squeak, then I continued with > Pharo. I can really fell the difference: nice Widgets, cleaner system I > can understand, ease to integrate changes/improvements upstream. All in > all, I get the job done more nicely from my perspective. So you're using Pharo because of Polymorph? > > In the past, project got hudge resources (ie Sophie), this project > failed to give back to the community in a proper way. Was it because I don't really get this, which project are you talking about? Levente > Squeak defunct development model? I think so. IMHO, Pharo is trying to > fix that, and this is terribly important for a community. > > Now, Squeak model of development is may be different, so it may not > happen again, I don't know. > >> IMHO the reason is having total control and that's the same reason why >> Pharo was created. > > This does not matter. > > Hilaire > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] [Metacello] Metacello as a package management system for Pharo

by Miguel CobÃ¡

El lun, 20-09-2010 a las 22:31 +0200, Mariano Martinez Peck escribiÃ³: > Hi folks. First of all, sorry for the long email (I guess it will be > long). After thinking and discussing hundred of times in the mailing > lists, last week we all meet and talk about Metacello and Pharo. Dale, > Stef, Marcus, Esteban, all were present. I want to write down all the > ideas and solution in order to: not to forget them; and to get > feedback and opinions from you. > > Problems we want to face: > > 1) Right now a user CANNOT know which version of a project is the > stable for a specific Pharo version. For example, suppose > ConfigurationOfXXX. The user cannot know that XXX 3.45 is the stable > for 1.0 and that XXX 5.7.3 is the one for 1.1....etc...so users end > up confused not knowing which version to download. In addition, > #latestVersion is not enough, because that will answer you the latest > version, but that may not be the correct one for older Pharo images. > Suppose in the previous case, latestVersion may answer 5.7.3 which may > not work in Pharo 1.0..... We want the user to be able to autaticallly > load the stable version for each pharo version without needing to know > that. > > 2) Have a repository for each Pharo version so that someone can easily > browse the available configurations for that Pharo version, and load > them. Not only one as it is now woth MetacelloRepository. > > 3) Be self contained. Sometimes developers removed packages of > versions from their repositories. In such case, Metacello cannot do > anything and the load may not work anymore. We want to be able to > reproduce the load and be able to load the same 10 years after. ok > > Solution proposed: > > The proposed solution may not even involve Metacello. You may have > heard about Metacello Project Loader developer by Esteban Lorenzano. > See http://www.smallworks.com.ar/en/community/GoferProjectLoader > The idea is rename that project to that it is a general name like > GoferProjectManager or something like that, because now it will do > load but also write :) > I will call it GoferProjectManager in this email. > > The idea is that every developer of a configuration define the stable > version for each Dialect version. There are two possible alternatives: > > a) That each Conf class implements #stableVersion: spec, which could > be something like: > > ConfigurationOfXXX >> stableVersion: spec > spec for: #Pharo1.0 do: [ ^ self version: '3.45' ]. > spec for: #Pharo1.1 do: [ ^ self version: '5.7.3' ]. > spec for: #Pharo1.2 do: [ self error: 'There is no stable > version for Pharo 1.2' ]. > spec for: #Gemstone do: [ ^ self version: '4.2' ]. > ..... This implies that the stableVersion method will be heavily modified as the software is ported to new platforms and new releases. Not a big deal. Sometimes will imply that a merge will be needed when 2 developers want to maintain the configuration. Also, I feel that disconnects the version method from the version string declaration/publication. again, not a big issue either. > > or something like that...the idea is that you define stable versions > for each platform. > > The idea is that now the user could do something like this: > ConfigurationOfXXX project stableVersion load > but he won't do that ;) > > b) another approach is to specify something in each version, for > example: > > ConfigurationOfXXX >> version345: spec > <version: '3.45' imports: #('1.2-baseline')> > > spec for: #common do: [ > spec blessing: #release. > spec description: 'Blah balh...'. > spec platformVersion: 'Pharo 1.0' > > and > > ConfigurationOfXXX >> version573: spec > <version: '5.7.3' imports: #('1.2-baseline')> > > spec for: #common do: [ > spec blessing: #release. > spec description: 'Blah balh...'. > spec platformVersion: 'Pharo 1.1' > > Now...any of those alternatives would solve problem 1) As you say they are equivalent ways to state the same information. I like this because it is only a place to modify the new version number. I personally like this, but also I can imagine that this could lead to big methods with conditionals for functionality that applies to more than one release. Maybe the first option requires less work for Dale to support this functionality. > > Now to solve 3) the idea is that GoferProjectManager could provide > something like this: > > (Gofer project 'XXX') publishVersion: '3.45' for: 'Pharo 1.0' > or then > (Gofer project 'XXX') publishVersion: '5.7.3' for: 'Pharo 1.1' > etc... > > Then this would do different things: > > a) Automatically take the conf class (it is important the name > conventions!!) > b) Commit it into the correct Pharo repository version. For example > for 3.4.5 it will commit it in PharoMetacelloRepository10 and 5.7.3 to > PharoMetacelloRepository11 > c) Traverse all the dependencies of all needed packages and commit all > of them to PharoPackagesContainer10 or > PharoPackagesContainer11....etc > Dale sent few weeks ago a script that does that: takes a conf, a > version and a repo and commits all the files to that repo. > > With all this we solve 2). The idea is that for EACH pharo version we > will have 2 repositories, one for the confs and another one for the > packages (as a backup). I like it. Now, when traversing dependencies, wouldn't be good to also rewrite the repositories they point to so that they point to self (repository). This way the problem 3 is solved too, because the configuration already points to self and not the original repo? This maybe could be easier if Metacello could have a way to indirect repository names from the configuration so that the metacello version projects only referred a keyworkd and not the real package and then on commiting the package to the repo, it would be rewritten or overriden with the container repository? For example, instead of: spec for: #squeakCommon do: [ spec project: 'OSProcess' with: [ spec className: 'ConfigurationOfOSProcess'; loads: #('default'); file: 'ConfigurationOfOSProcess'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec repository: 'http://www.squeaksource.com/Magma'; package: 'WriteBarrier' with: [ spec repository: 'http://www.squeaksource.com/WriteBarrier' ]; you'll write a baseline like: spec for: #squeakCommon do: [ spec project: 'OSProcess' with: [ spec className: 'ConfigurationOfOSProcess'; loads: #('default'); file: 'ConfigurationOfOSProcess'; repository: #osProcessRepository ]. spec repository: 'http://www.squeaksource.com/Magma'; package: 'WriteBarrier' with: [ spec repository: #writeBarrierRepository ]; and will define the repositories somewhere else: ConfigurationOfXXX>>repositoryFor: aSymbol ^ repoMap at: #aSymbol "This will return the real repo" And when commiting, maybe the GoferProjectManager will create a subclass with a method overriding the repository map to ConfigurationOfXXX>>repositoryFor: aSymbol ^ 'http://www.squeaksource.com/PharoPackagesContainerXX' I haven't used repositoryOverrides so maybe this is nonsense and not necessary and can be handled cleanly and better by Metacello itself. :) > > The last point is that when loading we should load everything from the > PharoPackagesContainer10 or PharoPackagesContainer11...but we don't > want to change all our confs (for example, they are pointing to they > own repos or MetacelloRepository)....so the solution is that we use > GoferProjectManager to load. Example: > > Gofer project: 'XXX' loadStable > > and loadStable would be something like: > > self stableVersion repositoryOverrides: (self containerRepo); load > > The idea is that it can use #repositoriesOverride to override with the > correct repository... > > So.....that's all. What do you think? does this make sense? > > Cheers > > Mariano Overall I agree. The less the user has to type and know from where the packages come the better for we all. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Schwab,Wilhelm K

Stef, I sometimes get overwhelmed and have probably hit about every other beta or release that I intended to use. The improvements are accumulating and very much appreciated. Thanks! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, September 20, 2010 4:12 PM To: Pharo-project(a)lists.gforge.inria.fr; ma.chris.m(a)gmail.com Subject: Re: [Pharo-project] [squeak-dev] Morphic On Sep 20, 2010, at 9:45 PM, Chris Muller wrote: > Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :) :) > I still develop for Pharo, but one of my concerns has been the short > time between releases. It means there is not much time for a stable, > proven Pharo foundation to form before it is abandoned already. I would not call it abandoned. Because this is not abandoned. Now the system is in such a state even if we are working a lot that we must change it. I do not like to live with duplicated code. I thought we fixed most of it. Or a texteditor/compiler from 30 years ago, even if the age is not a problem :). Did you get that many changes impacting you between 1.0 and 1.1? For example inceptive worked a lot with 1.0 and recently moved to 1.1. I do not know what is their experience but it seems to be good from their side and their application is really sexy and demanding. We do not want to have long release cycle because we get more beta phases where effort is on stabilization and feedback. With longer periods we would be too much alone hacking and people waiting to try the new one. So I think that this is nice tension. Two/Three releases per year give 3 months minimum of beta phase. Now you can also skipped on release on two. > Combined with the Pharo philosophy about backward compatibility, I am > quite nervous that Magma is going to get "stuck" in some "old" (what, > 3 months?!) version of Pharo that never had much time to gestate in > the first place.. I think that the pace of changes will probably slow down. Now what I see with Moose and moose is complex (using AST and other internal parts is that it took 1 day to migrate it). In addition, we will not change for the sake of it but there are still really places that should be changed. I think that magma can gain benefit of the bytecode rewriting library marcus will migrate on top of Opal. In addition I would really like to have more bits so that we can nicely have an immutability bit. And I imagine that the write barrier would benefit greatly of it. > > - Chris > > PS - Congratulations on your latest Dr. Geo. > > > 2010/9/20 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: >> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>> >>>> Really I don't understand CUIS long term objective, why this work is not >>>> done in Pharo? They share the same vision. >>> >>> You could ask the same question with Pharo and Squeak instead of Cuis >>> and Pharo, couldn't you? >> >> No, I can't. >> >> Pharo provides me a clear vision I can thrust: a Smalltalk environment >> to build third party applications (ie makes my developer life easier). >> Squeak does not provide me this thrust nor indication of that direction. >> You can object it is matter of point of view, I will object it is a >> matter of ressources you can allocate to write an application. Mine are >> limited: I start writing DrGeo under Squeak, then I continued with >> Pharo. I can really fell the difference: nice Widgets, cleaner system I >> can understand, ease to integrate changes/improvements upstream. All in >> all, I get the job done more nicely from my perspective. >> >> In the past, project got hudge resources (ie Sophie), this project >> failed to give back to the community in a proper way. Was it because >> Squeak defunct development model? I think so. IMHO, Pharo is trying to >> fix that, and this is terribly important for a community. >> >> Now, Squeak model of development is may be different, so it may not >> happen again, I don't know. >> >>> IMHO the reason is having total control and that's the same reason why >>> Pharo was created. >> >> This does not matter. >> >> Hilaire >> >> -- >> Dr. Geo, to discover geometry on Linux, Windows, MAC and XO >> http://community.ofset.org/index.php/DrGeo >> >> >> _______________________________________________ >> 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

Sept. 20, 2010

Re: [Pharo-project] Squeak/Pharo Talk

by Gary Chambers

Sounds cool. Wish I could be there (as I wished I could be at ESUG...). Regards, Gary ----- Original Message ----- From: "DeNigris Sean" <sean(a)clipperadams.com> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org>; <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 20, 2010 9:36 PM Subject: [Pharo-project] Squeak/Pharo Talk > If anyone is in NYC Wednesday evening, I'll be giving a talk about Squeak > and Pharo for the NYC Smalltalk group. Details are at > http://www.nycsmalltalk.org/ > > Sean > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Gary Chambers

Hopefully Polymorph can help. Hillaire. Sure there are ongoing changes, but hopefully insulated from the "end user". Not by any means perfect, but a start at having a stable interface between look-and-feel and people's expression of user interfaces... My vision, as such, for Polymorph is to evolve to a "competent" interface that can be relied upon. Both the interface and lower level details are in flux, but there's much that can be relied on. The experiment is to flesh-out the needs and standardise (with flexibility). Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr>; <ma.chris.m(a)gmail.com> Sent: Monday, September 20, 2010 9:12 PM Subject: Re: [Pharo-project] [squeak-dev] Morphic On Sep 20, 2010, at 9:45 PM, Chris Muller wrote: > Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :) :) > I still develop for Pharo, but one of my concerns has been the short > time between releases. It means there is not much time for a stable, > proven Pharo foundation to form before it is abandoned already. I would not call it abandoned. Because this is not abandoned. Now the system is in such a state even if we are working a lot that we must change it. I do not like to live with duplicated code. I thought we fixed most of it. Or a texteditor/compiler from 30 years ago, even if the age is not a problem :). Did you get that many changes impacting you between 1.0 and 1.1? For example inceptive worked a lot with 1.0 and recently moved to 1.1. I do not know what is their experience but it seems to be good from their side and their application is really sexy and demanding. We do not want to have long release cycle because we get more beta phases where effort is on stabilization and feedback. With longer periods we would be too much alone hacking and people waiting to try the new one. So I think that this is nice tension. Two/Three releases per year give 3 months minimum of beta phase. Now you can also skipped on release on two. > Combined with the Pharo philosophy about backward compatibility, I am > quite nervous that Magma is going to get "stuck" in some "old" (what, > 3 months?!) version of Pharo that never had much time to gestate in > the first place.. I think that the pace of changes will probably slow down. Now what I see with Moose and moose is complex (using AST and other internal parts is that it took 1 day to migrate it). In addition, we will not change for the sake of it but there are still really places that should be changed. I think that magma can gain benefit of the bytecode rewriting library marcus will migrate on top of Opal. In addition I would really like to have more bits so that we can nicely have an immutability bit. And I imagine that the write barrier would benefit greatly of it. > > - Chris > > PS - Congratulations on your latest Dr. Geo. > > > 2010/9/20 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: >> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>> >>>> Really I don't understand CUIS long term objective, why this work is >>>> not >>>> done in Pharo? They share the same vision. >>> >>> You could ask the same question with Pharo and Squeak instead of Cuis >>> and Pharo, couldn't you? >> >> No, I can't. >> >> Pharo provides me a clear vision I can thrust: a Smalltalk environment >> to build third party applications (ie makes my developer life easier). >> Squeak does not provide me this thrust nor indication of that direction. >> You can object it is matter of point of view, I will object it is a >> matter of ressources you can allocate to write an application. Mine are >> limited: I start writing DrGeo under Squeak, then I continued with >> Pharo. I can really fell the difference: nice Widgets, cleaner system I >> can understand, ease to integrate changes/improvements upstream. All in >> all, I get the job done more nicely from my perspective. >> >> In the past, project got hudge resources (ie Sophie), this project >> failed to give back to the community in a proper way. Was it because >> Squeak defunct development model? I think so. IMHO, Pharo is trying to >> fix that, and this is terribly important for a community. >> >> Now, Squeak model of development is may be different, so it may not >> happen again, I don't know. >> >>> IMHO the reason is having total control and that's the same reason why >>> Pharo was created. >> >> This does not matter. >> >> Hilaire >> >> -- >> Dr. Geo, to discover geometry on Linux, Windows, MAC and XO >> http://community.ofset.org/index.php/DrGeo >> >> >> _______________________________________________ >> 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

Sept. 20, 2010

[Pharo-project] Squeak/Pharo Talk

by DeNigris Sean

If anyone is in NYC Wednesday evening, I'll be giving a talk about Squeak and Pharo for the NYC Smalltalk group. Details are at http://www.nycsmalltalk.org/ Sean

Sept. 20, 2010

Re: [Pharo-project] Issue 2984 #collect:displayingProgress: vs #do:displayingProgress: (New Inspector)

by Frederic Pluquet

There is fixed in the last version of NewInspector. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Mon, Sep 20, 2010 at 8:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks this is an important reflex because of the volume and variety of > issue. > > > > Turned into http://code.google.com/p/pharo/issues/detail?id=2984 > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

[Pharo-project] Metacello as a package management system for Pharo

by Mariano Martinez Peck

Hi folks. First of all, sorry for the long email (I guess it will be long). After thinking and discussing hundred of times in the mailing lists, last week we all meet and talk about Metacello and Pharo. Dale, Stef, Marcus, Esteban, all were present. I want to write down all the ideas and solution in order to: not to forget them; and to get feedback and opinions from you. *Problems we want to face: * 1) Right now a user CANNOT know which version of a project is the stable for a specific Pharo version. For example, suppose ConfigurationOfXXX. The user cannot know that XXX 3.45 is the stable for 1.0 and that XXX 5.7.3 is the one for 1.1....etc...so users end up confused not knowing which version to download. In addition, #latestVersion is not enough, because that will answer you the latest version, but that may not be the correct one for older Pharo images. Suppose in the previous case, latestVersion may answer 5.7.3 which may not work in Pharo 1.0..... We want the user to be able to autaticallly load the stable version for each pharo version without needing to know that. 2) Have a repository for each Pharo version so that someone can easily browse the available configurations for that Pharo version, and load them. Not only one as it is now woth MetacelloRepository. 3) Be self contained. Sometimes developers removed packages of versions from their repositories. In such case, Metacello cannot do anything and the load may not work anymore. We want to be able to reproduce the load and be able to load the same 10 years after. *Solution proposed: * The proposed solution may not even involve Metacello. You may have heard about Metacello Project Loader developer by Esteban Lorenzano. See http://www.smallworks.com.ar/en/community/GoferProjectLoader The idea is rename that project to that it is a general name like GoferProjectManager or something like that, because now it will do load but also write :) I will call it GoferProjectManager in this email. The idea is that every developer of a configuration define the stable version for each Dialect version. There are two possible alternatives: a) That each Conf class implements #stableVersion: spec, which could be something like: ConfigurationOfXXX >> stableVersion: spec spec for: #Pharo1.0 do: [ ^ self version: '3.45' ]. spec for: #Pharo1.1 do: [ ^ self version: '5.7.3' ]. spec for: #Pharo1.2 do: [ self error: 'There is no stable version for Pharo 1.2' ]. spec for: #Gemstone do: [ ^ self version: '4.2' ]. ..... or something like that...the idea is that you define stable versions for each platform. The idea is that now the user could do something like this: ConfigurationOfXXX project stableVersion load but he won't do that ;) b) another approach is to specify something in each version, for example: ConfigurationOfXXX >> version345: spec <version: '3.45' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.0' and ConfigurationOfXXX >> version573: spec <version: '5.7.3' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.1' Now...any of those alternatives would solve problem 1) Now to solve 3) the idea is that GoferProjectManager could provide something like this: (Gofer project 'XXX') publishVersion: '3.45' for: 'Pharo 1.0' or then (Gofer project 'XXX') publishVersion: '5.7.3' for: 'Pharo 1.1' etc... Then this would do different things: a) Automatically take the conf class (it is important the name conventions!!) b) Commit it into the correct Pharo repository version. For example for 3.4.5 it will commit it in PharoMetacelloRepository10 and 5.7.3 to PharoMetacelloRepository11 c) Traverse all the dependencies of all needed packages and commit all of them to PharoPackagesContainer10 or PharoPackagesContainer11....etc Dale sent few weeks ago a script that does that: takes a conf, a version and a repo and commits all the files to that repo. With all this we solve 2). The idea is that for EACH pharo version we will have 2 repositories, one for the confs and another one for the packages (as a backup). The last point is that when loading we should load everything from the PharoPackagesContainer10 or PharoPackagesContainer11...but we don't want to change all our confs (for example, they are pointing to they own repos or MetacelloRepository)....so the solution is that we use GoferProjectManager to load. Example: Gofer project: 'XXX' loadStable and loadStable would be something like: self stableVersion repositoryOverrides: (self containerRepo); load The idea is that it can use #repositoriesOverride to override with the correct repository... So.....that's all. What do you think? does this make sense? Cheers Mariano

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Jimmie Houchin

On 9/20/2010 11:33 AM, Hilaire Fernandes wrote: > Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>> Really I don't understand CUIS long term objective, why this work is not >>> done in Pharo? They share the same vision. >> You could ask the same question with Pharo and Squeak instead of Cuis >> and Pharo, couldn't you? > No, I can't. > > Pharo provides me a clear vision I can trust: a Smalltalk environment > to build third party applications (ie makes my developer life easier). > Squeak does not provide me this thrust nor indication of that direction. > You can object it is matter of point of view, I will object it is a > matter of ressources you can allocate to write an application. Mine are > limited: I start writing DrGeo under Squeak, then I continued with > Pharo. I can really fell the difference: nice Widgets, cleaner system I > can understand, ease to integrate changes/improvements upstream. All in > all, I get the job done more nicely from my perspective. I too agree. It is very nice to have a clean, clear vision statement in which the community can put its resources behind to accomplish. We can accomplish more together than each alone. The whole is greater than the sum of its parts. Without a unifying vision, you have the sum of its parts. With a vision, you have common goal, a unifying purpose. You have something that can inspire. Something that can guide, in where to draw lines, what to add, what to cut, what belongs in, what belongs out. You can do most anything in either Squeak or Pharo that you can do in the other. But ultimately I believe that Pharo is moving in a direction which empowers more people. Many of the Squeak users can use Squeak for most anything they need or want, primarily because they are very skilled/expert in both Smalltalk/Squeak and also interfacing outside systems via FFI, Alien, plugins, etc. But for those of us who are not so able, who do not have the training or knowledge, Pharo's vision and implementation therefore will IMHO be more enabling and empowering, especially to the less than expert, the little guy. And when Pharo achieves the smaller cleaner core, it will also be more enabling/empowering to the expert. Pharo is explicitly more business friendly in its vision, goals, leadership and community. I am a huge advocate of business in open source. I think as business prospers within the Squeak/Pharo communities that the community improves as does the artifact itself. It is my opinion that Pharo is explicitly more open towards this synergy with business. Squeak is not necessarily against such, but is more of the perspective of we happen to be walking together in the same direction. Pharo is explicitly pro-business. Squeak will not prohibit, but not really support. And yes I know there are businesses based upon Squeak, but primarily owned and operated by experts. For me my initial push into Pharo came simply from wanting/requiring/desiring code completion in workspaces and the browsers. Squeak was and is broken on OCompletion. And I did not see any other alternatives. I read all the messages, tried many things. No success. Even today the issue pops up again on the list. 5 months after the last series of messages which had no clear answer on how to get it working in Squeak. Pharo it just worked out of the box. And thank you Levente for showing how to get it working in Squeak. That might be a little thing, but it is an important thing and it highlights some of the differences and goals of the two projects and communities. I am not against Squeak. I would that we were all one big happy family putting all our energies into something that works for all. But that is not the case and one has to choose where to put ones energies and time. Hopefully most efforts will be usable by both. But as each diverge that may be increasingly difficult. I presently do not see a Pro-business or even particularly business-friendly vision from Squeak. Just my perspective and opinions. Thanks. Jimmie

Sept. 20, 2010