- Pharo-dev - lists.pharo.org

[Pharo-project] Migrating among different Pharo releases
by Mariano Martinez Peck May 11, 2010

May 11, 2010

Hi folks. I think we need to improve the changes/changelog between Pharo versions: 1.0, 1.1 etc. In addition, we need to document somewhere, how external packages maitainers should update their code. Sometimes, with a deprecated it is easy as you can say which other message to use instead. However, removing TheWorldMenu, FillInTheBlank, Preferences, etc it is more complicated as you cannot deprecated. So...if we want maintainers of external packages to update their versions to work with Pharo 1.1 we should document and explain what to do for these situations. For example, I have NO IDEA what to do with code that has references to those classes. Seriously, I don't have idea how to fix them. I propose something like Seaside at least: http://www.seaside.st/documentation/migration/28to30 Maybe the best start point is: http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne Sorry I cannot help by myself with this. I am just speaking in case someone can know and can spent few hours and help with this. Cheers Mariano

3 2

[Pharo-project] Fwd: Re: DEVImageCreator >> setDefaultPreferences (alain?)
by Alain Plantec May 11, 2010

May 11, 2010

-------- Message original -------- Sujet: Re: DEVImageCreator >> setDefaultPreferences (alain?) Date : Tue, 11 May 2010 13:55:41 +0200 De : Alain Plantec <alain.plantec(a)free.fr> RÃ©pondre Ã : alain.plantec(a)free.fr Pour : Mariano Martinez Peck <marianopeck(a)gmail.com> Hi Mariano, all Le 11/05/2010 11:43, Mariano Martinez Peck a Ã©crit : > Hi Alain. DEVImageCreator has to be updated to use the new > preferences. I can do it but it will require much more than for me > than for you ;) > > For preferences it is DEVImageCreator>> setDefaultPreferences > it is using Preferences class for the moment. It should be updated to > use Settings, isn't it ? I don't think so. There is no need for such a initialization anymore since package are defining their own preferences. If a default value is desired then it should be set by an initialization method or lazily by the getter. I find the lazy initialization better because then, the SettingBrowser can reset the preference to the default by setting it to nil. > BTW, Preferences is still present in Pharo 1.1 and thus, > setDefaultPreferences is still working but I guess it should be updated. why ? there is no need for setDefaultPreferences anymore. > > Do you know when Preferences class will be completely removed? Pharo 1.2? I don't know. Maybe we can let it in the 1.1 in order to let maintainers the possibility to port their packages and definitively remove it in 1.2. The same for TheWorldMenu I guess. Cheers Alain > > Thanks! > > Mariano

3 2

Re: [Pharo-project] Freetype plugin archive
by David T. Lewis May 11, 2010

May 11, 2010

On Sun, May 02, 2010 at 08:55:33AM -0700, Michael Rueger wrote: > On 5/1/10 11:31 AM, Bert Freudenberg wrote: > >On 01.05.2010, at 18:31, David T. Lewis wrote: > > >>Do you know if the rest of the stuff in http://source.impara.de/freetype/ > >>still has value (or has it been superceded by Freetype Plus)? > > I would think so, that's why there wasn't any further development on the > freetype plugin. > The current repositories are of somewhat historical value for e.g. the > Sophie builds. I have opened a new SqueakSource project for the Freetype plugin (FT2Plugin). MCHttpRepository location: 'http://www.squeaksource.com/FreetypePlugin' user: '' password: '' This contains copies of all the Freetype-Plugin entries from the archival repository at http://source.impara.de/freetype, as well as one additional update from Mantis 7521. Project administrators are Andy Tween, Bert Freudenberg and me. Developers are everyone whose author initials appear in the original archive. VMMaker class>>updateFromServer should now load FT2Plugin from the new FreetypePlugin repository. A similar update will be needed for ConfigurationOfVMMaker for Pharo. For now the original package name Freetype-Plugin has been retained, although I note that this conflicts with the current packaging of Freetype in SqS/Freetype Plus, so a change to the package name may be in order. FT2Plugin contains dependencies on Freetype. This is the reason that I moved it to a separate SqueakSource project rather than include it in the SqS/VMMaker repository. Dave

3 7

[Pharo-project] keyAtValue: -> keysAtValue:
by Tristan Bourgois May 11, 2010

May 11, 2010

keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo' So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value. I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question. Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 7

[Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)
by Mariano Martinez Peck May 11, 2010

May 11, 2010

Hi Alain. DEVImageCreator has to be updated to use the new preferences. I can do it but it will require much more than for me than for you ;) For preferences it is DEVImageCreator >> setDefaultPreferences it is using Preferences class for the moment. It should be updated to use Settings, isn't it ? BTW, Preferences is still present in Pharo 1.1 and thus, setDefaultPreferences is still working but I guess it should be updated. Do you know when Preferences class will be completely removed? Pharo 1.2? Thanks! Mariano

1 0

[Pharo-project] "Tools" -> "more" removed from PharoCode 1.1...intentionally ? (alain ?)
by Mariano Martinez Peck May 11, 2010

May 11, 2010

Hi folks. In Pharo 1.0 we use to have under "Tools" -> "More" some tools like: Language Editor Language Editor For Monticello Browser Monticello Configurations Preference Browser Recent Submissions Search Browser Services Browser Test Runner However, in Pharo 1.1 there is not even a "more" menu item. I saw the following issues: http://code.google.com/p/pharo/issues/detail?id=1937 http://code.google.com/p/pharo/issues/detail?id=1945 but I am not sure if I understand. Alain said something has to be done in ImageForDevelopers... Thanks Maruano

2 1

[Pharo-project] VMs for Pharo 1.1
by Torsten Bergmann May 11, 2010

May 11, 2010

Hi Mariano, >Windows: I remember a new version 4.1 or similar that Andreas did. Last Squeak VM from Andreas is "SqueakVM-Win32-4.0.2-bin.zip" and we have an according "PharoVM-Win32-4.0.2-bin.zip" on gforge and http://pharo-project.org/pharo-download This VM is already included in the Pharo1.0 installer for Windows (EXE) but not in the 1.0 one click (ZIP). So anything we have to do for 1.1. is to use this VM in the 1.1 one click distribution. >I remember there was a problem with the windows closing or similar...but I >remember Torsten fixed that. There was no fix required and the Pharo VM is always 1:1 with the Squeak VM codebase, no need to fork. Any credit goes to Andreas. We just exchange ressources (icons, ...) - marketing you know ;) >Is that integrated in Pharo ? Yes, Pharo 1.1 can handle the close event. It is by default handled using an image side dialog. If one wants the old behavior you need EnableAltF4Quit = 1 in the Pharo.ini Attached is the Pharo.ini that is used in the Windows installer, which uses this option (which I like more - maybe because I'am used to it). >We are able to use that VM ? Yes >Torsten, where can I get a Pharo 1.1 Windows VM ? see above. Full link is http://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip >does it include FreeType ? Yes >can you update the splash if necessary ;) Will do tomorrow. Remind me if you dont get it. Would be call it "1.1. RC1" first? Bye -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

[Pharo-project] Acire
by Torsten Bergmann May 11, 2010

May 11, 2010

Laurent wrote: >I've uploaded ConfigurationOfProfStef version 1.1. That's what I call fast. Coool, thanks! We should include this in 1.1-dev!!! Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

1 0

[Pharo-project] Acire
by Torsten Bergmann May 10, 2010

May 10, 2010

Maybe we should enhance ProfStef with a list on the left side and the transcript included at the bottom: http://rickwagner.blogspot.com/2010/05/every-programming-language-should-ha… ;) Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 2

Re: [Pharo-project] [squeak-dev] Re: [Metacello] Re: Metacello questions
by Dale Henrichs May 10, 2010

May 10, 2010

Andreas, We're talking conventions here, not hard and fast requirements. The convention is that you create a _baseline_ where you specify the list packages and projects that go into your project including repository info and dependencies. The you create a _version_ that imports a _baseline_ and simply specifies the specific mcz file and project version that goes into the project. As project structure changes, new baselines are created. As new mcz files or project versions are produced, a new version reflecting this new state is released. Separating this out from the beginning just makes it easier (in my opinion) for folks to wrap their minds around the two different concepts... structure of the project and version specification...Which I think is important to understand early on, whether or not you create separate artifacts or not... Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | On 5/10/2010 10:06 AM, Dale Henrichs wrote: | > +1 | | I'll have to admit I find this quite awkward - like designing a | framework that has only one use case. It tends to push the wrong | things | into the abstraction layer. Is there anything fundamentally wrong with | | creating the baseline only at the point where you have more than one | version to deal with? | | Cheers, | - Andreas | | > With at least one exception:) | > | > In Seaside3.0 there is a tight coupling between the Seaside3.0 | packages and the Grease packages ... to the point were (at least for | the time being) a later version of Grease is not likely to work an | earlier version of Seaside3.0, so it _is_ appropriate to slave the | versions together by specifying a version in the baseline ... When | Grease/Seaside matures to the point were structural dependencies are | no longer being worked out, the need to specify the Grease version in | the baseline can (and should) go away. | > | > Dale | > ----- "Mariano Martinez Peck"<marianopeck(a)gmail.com> wrote: | > | > | My advice is not to specify versions in a project reference. | > | | > | If you have a baseline and in such baseline you reference a | project, | > | for | > | example: | > | | > | "this piece of code is inside a baselind" | > | project: 'UI Support' with: [ | > | | > | "One or more of the following | > | attributes may | > | be defined or changed" | > | spec | > | "Name of config class | (i.e., | > | ConfigurationOfXXX)" | > | className: | > | 'ConfigurationOfUI'; | > | "Version of project to be | > | loaded. if | > | theversionString is not specified, then the latest version of the | > | project is | > | used." | > | versionString: '1.0'; | > | | > | | > | Then, DO NOT PUT versionString: there. So: | > | | > | | > | "this piece of code is inside a baselind" | > | project: 'UI Support' with: [ | > | | > | "One or more of the following | > | attributes may | > | be defined or changed" | > | spec | > | "Name of config class | (i.e., | > | ConfigurationOfXXX)" | > | className: | > | 'ConfigurationOfUI'; | > | "Version of project to be | > | loaded. if | > | theversionString is not specified, then the latest version of the | > | project is | > | used." | > | file: 'XXX'. | > | | > | | > | And in a version method that has THAT basline, you write: | > | | > | spec | > | project: 'UISupport' with: '1.0'. | > | | > | | > | In summary, don't put version information in baselines, only in | > | version | > | methods. That's just my advice. | > | | > | Cheers | > | | > | Mariano | > | | > | | > | On Thu, May 6, 2010 at 10:13 PM, Torsten Bergmann<astares(a)gmx.de> | > | wrote: | > | | > |> >Does that mean the documentation is just wrong then? | > |> | > |> I would see/interpret it like this: With the baseline you | describe a | > | set of | > |> packages (structure/dependencies) that form your app/project | > | (MyApp). Beside | > |> the usual loading of a version: | > |> | > |> (ConfigurationOfMyApp project version: '1.0') load | > |> | > |> it is possible to load also a baseline - this would load all | the | > | latest | > |> Monticello package versions of any package described in this | > | baseline: | > |> | > |> (ConfigurationOfMyApp project version: '1.0-baseline') load | > |> | > |> Note that in the baseline you dont say anything about the | > | Monticello | > |> package | > |> version to use/load. | > |> | > |> In a baseline you can also define a dependency on another | project | > | (that | > |> provides a config too, for instance ConfigurationOfMyFoo). | > |> | > |> Now you have two options: | > |> | > |> a) dont say anything about the version of | "ConfigurationOfMyFoo" | > | in the | > |> baseline | > |> => this should load the latest version of Foo's | Metacello | > |> configuration then, | > |> so you get the latest version of "Foo" when loading | the | > | baseline | > |> of MyApp | > |> | > |> b) you note/give a default version for "ConfigurationOfMyFoo" | in | > | the | > |> baseline | > |> => then this specific version of "Foo" is loaded when you | load | > | the | > |> baseline for MyApp. | > |> I think you can override the version specified in the | > | baseline in | > |> a #versionXXX of MyApp if required | > |> | > |> Loading baselines is usefull if you work in a team. If you work | on | > | the | > |> same baseline you can just load it to be up to date with the | latest | > |> commits of the other team members. | > |> | > |> If your dependencies, load order, set of packages/pre-projects | > | change then | > |> you typically create a new baseline. | > |> | > |> But it is more often the case that you just create new versions | > | based on | > |> a baseline. In a versionXXX you pin/mark the Metacello version | of | > | all | > |> packages/projects version that fit/work together to form this | > | version. | > |> | > |> Maybe Dale is able to correct me if I'm wrong. | > |> | > |> Thanks | > |> Torsten | > |> | > |> | > |> | > |> -- | > |> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! | > |> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 | > |> | > |> _______________________________________________ | > |> Pharo-project mailing list | > |> Pharo-project(a)lists.gforge.inria.fr | > |> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > |> | > | >

1 0