April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Pharo TechTalk: Pharo 6.0 release today 25/05 16UTC

by Esteban Lorenzano

ah, and remember we are also at discord: discord <http://discord.gg/Sj2rhxn> cheers, Esteban > On 25 Apr 2017, at 16:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > So, today (in 1.5hs) I will handle the talk I didnât handle last month ;) > In fact, it will be just a small roadmap and then an open session of questions and answers. > > link for the talk is here: > https://www.youtube.com/c/EstebanLorenzano/live <https://www.youtube.com/c/EstebanLorenzano/live> > > cheers, > Esteban

April 25, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Thierry Goubier

2017-04-25 16:11 GMT+02:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: [ Shortened for brevity ... ] > >>> >> Hum. I'm not trying to determine a version for the configurations present >> in the image... and #primeRegistryFromImage seems to, and then I seem to >> get errors because it selects a wrong version (at least I got an error >> doing that with ConfigurationOfEpicea, set at version 7.8.p4 where it >> should be version 8.1.3, and Metacello fails with a version not found). >> >> I'll look a bit deeper to see what is happening and how to reproduce it. >> > It is very likely that you are running into the very type of bug that > caused me to go with the Metacello registry in the first place ... It can > be impossible for Metacello to guess the correct version of a loaded > configuration ... I'm not sure it is worth much effort to try to > characterize the problem ... better would be for Pharo to use "Metacello > new" to build the image, so that the loaded versions are registered in the > first place ... > Of course... Now, I just compute the closure of all the configuration version specs over the set of packages present in the image, by name. If a package name is present in one of the version specs, then it is considered as part of the project. > > If you insist on looking deeper:) a common cause of wrong guesses is that > the configuration specifies a project version dependency or a version of > package that is later than the versions actually loaded in the image --- > this can happen when only a partial load of the configuration is done where > those projects or packages are not actually loaded by the configuration > itself --- without the actual registration information from the load, > Metacello looks at the loaded projects/packages and tries to match it with > a version of the configuration and this "false" dependency information > causes Metacello to look for an earlier version that matches ... Yes, this is the reason. In the case of Epicea in the latest image, the last version is 8.1.3, but ConfigurationOfEpicea>>#currentVersion returns 7.8p4. 7.8p4 is the highest version for which there is a dependency on the STON project, dependency which is respected in the image (version requested is 0.17, version present is 0.23). 7.8p4 and all higher versions also have a dependency on Smark, which isn't loaded. Would that mean that: - If one of the project in requirements is present in the image, then the version is considered current (here, for 7.8p4, Ston is present, Smark is not) if, for the packages of the project, all are present with versions higher than the current configuration version spec? - If none of the projects in requirements are present in the image, then the version is not considered current (in 8.1.3, Smark is not present but I see no dependency on Ston[*]) ? I have a feeling this is a strange result, and I'd prefer 8.1.3 to have the same validity as 7.8p4. Is this MetacelloProject>>#currentVersion used to determine if a project should be upgraded? Another question, related to the original topic: if the current configurations in the image are in this state, is it a good idea to leave them in? Would it have a chance of triggering incorrect updates or suspicious errors[**] if we start using them to load Metacello projects that depends on them? Thierry [*] The dependency on Ston is removed starting version 7.8p5 [**] for example, a project requiring Epicea >= 8.0 > > > Dale > > > >

April 25, 2017

[ANN] Pharo TechTalk: Pharo 6.0 release today 25/05 16UTC

by Esteban Lorenzano

Hi, So, today (in 1.5hs) I will handle the talk I didnât handle last month ;) In fact, it will be just a small roadmap and then an open session of questions and answers. link for the talk is here: https://www.youtube.com/c/EstebanLorenzano/live <https://www.youtube.com/c/EstebanLorenzano/live> cheers, Esteban

April 25, 2017

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

by Dale Henrichs

On 4/24/17 9:40 PM, Thierry Goubier wrote: > Hi Dale, > > Le 25/04/2017 Ã 00:02, Dale Henrichs a Ã©crit : >> >> >> On 04/24/2017 01:49 PM, Thierry Goubier wrote: >>> Le 17/04/2017 Ã 22:13, Dale Henrichs a Ã©crit : >>>> >>>> >>>> On 04/17/2017 12:47 PM, Thierry Goubier wrote: >>>>> Hi Dale, >>>>> >>>>> Le 17/04/2017 Ã 21:05, Dale Henrichs a Ã©crit : >>>>>> I would think that a `project list` view that made the Metacello >>>>>> project >>>>>> registration visible would help developers keep things straight. >>>>>> >>>>>> It seems that the issue here is that developers can't tell what >>>>>> projects >>>>>> are already loaded in the current image and also cannot tell what >>>>>> version of the project is loaded ... if you are using the `Metacello >>>>>> new` to load projects, then Metacello knows what projects and what >>>>>> versions are loaded in the image .... and that informatation really >>>>>> needs to be exposed to the developers ... >>>>>> >>>>>> If you have a `project list` then you can do things like >>>>>> automatically >>>>>> do a get on a configuration/baseline when a project is loaded via >>>>>> the >>>>>> `project list tool` ... there are additional details that need to be >>>>>> tracked and managed, but without the a basic `project list` the >>>>>> developer is responsible for "knowing what to do" and the first >>>>>> step is >>>>>> to let the developer know exactly which versions of which >>>>>> projects are >>>>>> loaded in the base image ... >>>>> >>>>> I wrote some code to that effect in the AltBrowser (gives access to >>>>> the project, and all packages loaded via that project, via a >>>>> Metacello >>>>> registry tag). >>>>> >>>>> It didn't work as well as I expected, in part due to the interaction >>>>> between the Metacello registry and package loading into the image. >>>>> Nothing undoable, but due to the total lack of Metacello state in the >>>>> default Pharo image (nothing is loaded via Metacello in there) and >>>>> the >>>>> Catalog browser not using Metacello as well, it was a bit too >>>>> early to >>>>> invest into that. >>>>> >>>>> In short, the Metacello registry provides a nice entry point for a >>>>> system browser view of loaded projects and versions, but the Pharo >>>>> image building process is not yet there. >>>>> >>>>> If someone is interested, one need to look into the GT extensions for >>>>> Metacello objects ... those extensions are a nice source of knowledge >>>>> about extracting information from the loaded projects. >>>> This is unfortunate ... I'm willing to help anyone who wants to tackle >>>> this problem as well --- I know a thing or two about Metacello myself >>>> and I've had a working `project list` in tODE for 3-4 years now ... oh >>>> well ... >>> >>> The code isn't lost anyway. I've reintegrated it as classifying based >>> on exiting ConfigurationOf / BaselineOf objects, relying on the spec >>> if there is no registering in Metacello (kind of funky in the case of a >>> ConfigurationOf, since you don't know which version was effectively >>> loaded... so you just play guesses with the various versions available >>> in the project). >> Yeah, bootstrapping the registration is dicey business, because you can >> fall prey to the very bugs you are trying to avoid --- Metacello does a >> prime registry as a project load doit when the registration code is >> initially ... you might look at >> MetacelloProjectRegistry>>primeRegistryFromImage:baselineClasses:prioritizeConfiguration:, >> >> but it sounds like you are doing something very similar ... > > Hum. I'm not trying to determine a version for the configurations > present in the image... and #primeRegistryFromImage seems to, and then > I seem to get errors because it selects a wrong version (at least I > got an error doing that with ConfigurationOfEpicea, set at version > 7.8.p4 where it should be version 8.1.3, and Metacello fails with a > version not found). > > I'll look a bit deeper to see what is happening and how to reproduce it. It is very likely that you are running into the very type of bug that caused me to go with the Metacello registry in the first place ... It can be impossible for Metacello to guess the correct version of a loaded configuration ... I'm not sure it is worth much effort to try to characterize the problem ... better would be for Pharo to use "Metacello new" to build the image, so that the loaded versions are registered in the first place ... If you insist on looking deeper:) a common cause of wrong guesses is that the configuration specifies a project version dependency or a version of package that is later than the versions actually loaded in the image --- this can happen when only a partial load of the configuration is done where those projects or packages are not actually loaded by the configuration itself --- without the actual registration information from the load, Metacello looks at the loaded projects/packages and tries to match it with a version of the configuration and this "false" dependency information causes Metacello to look for an earlier version that matches ... Dale

April 25, 2017

Re: [Pharo-dev] [ANN] Pharo Spring Friday, April 28

by marcus.denker＠inrira.fr

Hello, I can change all the pages as wanted.. (sorry for being a bit absent right now). For links to the events, there should be a wayâ¦ I will check (sometimes this week). > On 24 Apr 2017, at 16:42, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi Marcus, > > it is a detail, but the events mentions Slack. Maybe it should mention Discord. > > I would like to improve the page http://pharo.org/contribute-events <http://pharo.org/contribute-events> > by adding a workflow and link to the Pharo Sprint App. How can I do it? > > Also it would be nice to have the https://association.pharo.org/event-2492488 <https://association.pharo.org/event-2492488> (and others) visible on that page. > Is it possible? Is there any calendar plugin that we can plug to the http://pharo.org/contribute-events <http://pharo.org/contribute-events>? > > I am happy to collaborate on this, if you (or someone else) explain me how to contribute to the web page. > > Thanks! > Juraj > >> On Apr 24, 2017, at 10:55, marcus.denker(a)inrira.fr <mailto:marcus.denker@inrira.fr> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> There will be again a Sprint this Friday. >> >> More infos here: >> >> https://association.pharo.org/event-2492488 <https://association.pharo.org/event-2492488> >> >

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Damien Pollet

Nice ! butâ¦ no debugger window ? On 25 April 2017 at 12:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > Great! > > On 25 April 2017 at 10:52, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> You are an artist! >> >> Alexandre >> >> >> > On Apr 24, 2017, at 11:48 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > Right, next try... >> > >> > https://goo.gl/photos/YnGoZTrpKjJnSbFU9 >> > >> > -- Pavel >> > >> > >> > >> > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com >> >: >> > Le 24/04/2017 Ã 22:13, Pavel Krivanek a Ã©crit : >> > > New version: >> > > >> > > https://goo.gl/photos/66Yz3pSSK62aTYV66 >> > > >> > > -- Pavel >> > > >> > >> > Pretty nice but too blurry for me. Especially on the right of the >> screen. >> > >> > But maybe it's just me. >> > >> > -- >> > Cyril Ferlicot >> > https://ferlicot.fr >> > >> > http://www.synectique.eu >> > 2 rue Jacques PrÃ©vert 01, >> > 59650 Villeneuve d'ascq France >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Igor Stasenko

Great! On 25 April 2017 at 10:52, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > You are an artist! > > Alexandre > > > > On Apr 24, 2017, at 11:48 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > Right, next try... > > > > https://goo.gl/photos/YnGoZTrpKjJnSbFU9 > > > > -- Pavel > > > > > > > > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > > Le 24/04/2017 Ã 22:13, Pavel Krivanek a Ã©crit : > > > New version: > > > > > > https://goo.gl/photos/66Yz3pSSK62aTYV66 > > > > > > -- Pavel > > > > > > > Pretty nice but too blurry for me. Especially on the right of the screen. > > > > But maybe it's just me. > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > > 59650 Villeneuve d'ascq France > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Igor Stasenko.

April 25, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60469 Home: https://github.com/pharo-project/pharo-core

April 25, 2017

[pharo-project/pharo-core] 899b87: 60469

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 899b874b1a8d9484dde90c538f2a82dd2ef0198d https://github.com/pharo-project/pharo-core/commit/899b874b1a8d9484dde90c53… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-25 (Tue, 25 Apr 2017) Changed paths: A HelpSystem-Core.package/CustomHelp.class/class/formatting/bold_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/doItFrom_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/doItScriptFrom_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/heading_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/subheading_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/underlined_.st A HelpSystem-Core.package/CustomHelp.class/class/formatting/url_.st A HelpSystem-Core.package/CustomHelp.class/class/instance creation/newColoredText_withClipboardAction_.st A HelpSystem-Core.package/CustomHelp.class/class/instance creation/newColoredText_withRunAction_.st A Morphic-Widgets-Basic.package/SimpleButtonMorph.class/instance/testing/isDefault.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/bold_.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/doItFrom_.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/heading_.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/subheading_.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/underlined_.st R Pharo-Help.package/WelcomeHelp.class/class/formatting/url_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60468.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60469.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60468.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60469.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHTextStylerST80.class/class/style table/darkStyleTable.st Log Message: ----------- 60469 19960 Comments in changed code in Diff tool https://pharo.fogbugz.com/f/cases/19960 19962 Watery theme is broken because SimpleButtonMorph does not understand isDefault https://pharo.fogbugz.com/f/cases/19962 19970 Formatting methods recently introduced for WelcomeHelp should be accessible to all Help classes https://pharo.fogbugz.com/f/cases/19970 http://files.pharo.org/image/60/60469.zip

April 25, 2017

Re: [Pharo-dev] Traits methods flattened

by Nicolai Hess

2017-04-25 10:12 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Ah, no sorry. After another try I got it right, I have to unload the > package then file it in again to get it right. > > So the fix work for my problem too, issue definitely fixed and closed. > > Thanks > > Keep in mind. 1. the way new trait methods are handled is still wrong if non-local methods (methods from a trait) aren't added to the rpackage when creating the user of this trait, why are new trait methods "flattened" into this package 2. we already have some "corrupted" (flattened) packages in the image. (some methods of users of Traits are copied from the trait). For example, traits using the trait GLMBrickExtensionTrait or test case traits using other traits (TRemoveForMultiplenessTest / TRemoveTest, TDictionaryCopyingTest/TCloneTest) > > Le 25/04/2017 Ã 09:37, Hilaire a Ã©crit : > > Is there a way I can test on a Pharo6 image, because the backport does > > not fix my problem with Traits on Pharo5? > > > > I am reopening the ticket. > > > > Hilaire > > > > > > Le 22/04/2017 Ã 16:42, Pavel Krivanek a Ã©crit : > >> backported: > >> https://pharo.fogbugz.com/f/cases/19974/backport-Traits- > methods-flattened-case-19938 > >> > >> Test please... > >> -- Pavel > > -- > Dr. Geo > http://drgeo.eu > > > >

April 25, 2017