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

[Pharo-project] Single threaded Pharo IDE?

by Andrei Stebakov

I just started to use Pharo 1.0. So please bear with me since I may not fully understand the full concept of the IDE. Sometimes the whole IDE freezes indefinitely. So questions: 1) Looks like evaluating anything from the Workspace freezes the whole UI for the time of execution. Is it a bug or a feature? 2) Sometimes executing something freezes the UI indefinitely. Is there a way to cancel the operation (other than restarting the image)? Strangely in my case the IDE froze on evaluating HTTPSocket httpGet: ' http://www.pharo-project.org/home' Thank you, Andrei

May 10, 2010

[Pharo-project] Migrating among different Pharo releases

by Mariano Martinez Peck

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

May 10, 2010

[Pharo-project] VMs for Pharo 1.1

by Mariano Martinez Peck

Hi folks. We are moving on and we need to update VMs for Pharo 1.1. I would like to know the status of each platform and where to get them: Windows: I remember a new version 4.1 or similar that Andreas did. I remember there was a problem with the windows closing or similar...but I remember Torsten fixed that. Is that integrated in Pharo ? We are able to use that VM ? Torsten, where can I get a Pharo 1.1 Windows VM ? does it include FreeType ? can you update the splash if necessary ;) Linux: It would be cool to use a new vm, build form scratch. Laurent, I know this seems to be easy now. Is there any current/known problem ? where can I get a working vm with all the gnufication code and FreeType ? How is the speed finally in compare to other vms ? Mac: John, I am not sure which VM we should use for Pharo 1.1. Can you give us a hint ? known problems ? does it include freetype ? The idea (actually, just my opinion) is to upload these "latests" and Pharo 1.1 candidate vms to the website so that we can start to test. Soon (thanks a lot to Alexandre Bergel) we will be able to release a first unstable Pharo 1.1. Cheers Mariano

May 10, 2010

Re: [Pharo-project] Acire

by laurent laffont

I've uploaded ConfigurationOfProfStef version 1.1. You can try: ProfStefBrowser go. Laurent Laffont On Mon, May 10, 2010 at 1:31 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > take a look at ProfStefBrowser package in ProfStef repository. I should > include it in ConfigurationfOfProfStef for Pharo 1.1. Maybe we can enhance > it.... > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > > On Mon, May 10, 2010 at 1:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Tudor Girba

Good point. Doru On 10 May 2010, at 22:15, Mariano Martinez Peck wrote: > OK...I like 1) also, but I would care about: > > a) Explain and document somewhere how people can install and make > truetype to work > b) Use the VMs that have the fix to issue: http://code.google.com/p/pharo/issues/detail?id=1803 > > Cheers > > Mariano > > On Mon, May 10, 2010 at 7:32 PM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > On 10 May 2010, at 19:15, StÃ©phane Ducasse wrote: > > > On May 10, 2010, at 4:01 PM, Mariano Martinez Peck wrote: > > Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in > Pharo 1.1 Cores we have a StrikeFonts. We have two possibilites: > > 1) let those (strike fonts) fonts also for the dev image > 1) > > and people can load TT if they want. > > I agree. It also makes distributing images easier. > > Cheers, > Doru > > > > > > 2) Continue to put TrueType in Pharo dev > > I am all ears. > > Cheers > > Mariano > _______________________________________________ > 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 > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > > _______________________________________________ > 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 -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

May 10, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Mariano Martinez Peck

OK...I like 1) also, but I would care about: a) Explain and document somewhere how people can install and make truetype to work b) Use the VMs that have the fix to issue: http://code.google.com/p/pharo/issues/detail?id=1803 Cheers Mariano On Mon, May 10, 2010 at 7:32 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > On 10 May 2010, at 19:15, StÃ©phane Ducasse wrote: > > >> On May 10, 2010, at 4:01 PM, Mariano Martinez Peck wrote: >> >> Hi guys. Last Pharo 1.0 images have the TrueType fonts. Now, in Pharo 1.1 >>> Cores we have a StrikeFonts. We have two possibilites: >>> >>> 1) let those (strike fonts) fonts also for the dev image >>> >> 1) >> >> and people can load TT if they want. >> > > I agree. It also makes distributing images easier. > > Cheers, > Doru > > > > >> >> 2) Continue to put TrueType in Pharo dev >>> >>> I am all ears. >>> >>> Cheers >>> >>> Mariano >>> _______________________________________________ >>> 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 >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 10, 2010

Re: [Pharo-project] [Vm-dev] Re: Freetype plugin archive

by laurent laffont

> > > VMMaker class>>updateFromServer should now load FT2Plugin from the new > FreetypePlugin repository. A similar update will be needed for > ConfigurationOfVMMaker for Pharo. > Done (version 1.4). All Pharo-1.0 tests green with last squeakvm revision. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

May 10, 2010

Re: [Pharo-project] [squeak-dev] Re: [Metacello] Re: Metacello questions

by Dale Henrichs

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 | > |> | > | >

May 10, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

On 10 May 2010 19:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Sorry for the infinite loop, it was my fault. > I thought it had been detected and solved already (in squeak ?). > > Destroying source pointer of un-installed methods was just a > workaround to be used in case of already broken sources. > There is another strategy : detect the source pointer of un-installed > methods and store them in the new change log. > This has to be done before logging source code of installed methods. > I'd like to point, that some trailer kinds don't need to be altered even if you condensing changes. They are completely self sufficient and not related to 'standard' source management system. In fact, a condense changes _should_ take care only about methods which having a trailers carrying the source pointers ("001000" #VarLengthSourcePointer, "111111" #SourcePointer ) while others don't need any changes. There is a test method in CompiledMethodTrailer, #hasSourcePointer which can be used to check if you need to deal with this method when condensing .changes or not. But since currently the variety of trailers its not widely adopted (most of methods just storing a source pointers there), its fine to destroy trailers of non-installed methods. In future, it could be made more clever. > Nicolas > > 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: >> On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >>> >>>> Ok, i took the 11343 >>>> - fixed the #condenseChanges >>>> - ran Â Smalltalk condenseChanges >>>> - changed the single method >>>> - saved image >>>> - ran Â Smalltalk condenseChanges again >>>> >>>> no crash reported. >>>> >>> >>> Indeed, with 11343 it seems ok. >>> With 11326 (updated -> 11346), crash during the second condenseChanges :( >> >> Alain, could you please send me an image +.changes saved just before >> running a second condenseChanges? >> I'll try to find the cause of it. >> >>> Alain >>>> >>>> >>>>> >>>>> 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. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 10, 2010

Re: [Pharo-project] could we start to organize MetacelloRepository?

by Dale Henrichs

Stef, Just thinking off the top of my head a bit. Conceptually a separate repository makes sense ... then Gofer Project could be setup to to use this repository by default and the standard instructions for loading things would be reduced to simple expressions like: Gofer project load: 'FFI'. Gofer project load: 'Magma'. The difficulty comes in keeping the repository up-to-date....First you'd need to qualify configurations for inclusion (a hudson server for validation) makes sense. For hudson, it would be nice if there were a list of candidate configuration/version pairs that would be tested against ... In reality we are really looking for an approved list of configuration/version pairs that are known to work in Pharo 1.0. So we're probably really interested in expressions like the following: Gofer project load: 'FFI' version: '1.2'. Gofer project load: 'Magma' version: '1.0r44'. At this point a separate repository becomes a little less useful ... it's not the Configuration alone that the end user is interested in as the version is very important and the important information is that it is "known to work" This leads me to think along the lines of - configs from MetacelloRepository - hudson server validating each version for each config - list of config/(latest passing version) pairs published It would seem to me that a relatively simple morphic/glamour window could be written that read the config/version pairs from the hudson server and provided a means for selecting/loading the config/version pairs. How does this sound? Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Hi Dale and others | | I would like to have a | Pharo1.0 folder in the MetacelloRepository and ideally all the | configurationOf... inside should work for Pharo 1.0. | How can we proceed to get that. | In the future we should also have a process to avoid that we get junk | inside. any idea (I was thinking about an hudson | server that would validate the configuration automatically) | | Stef

May 10, 2010