February 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Christophe Demarey

So, problem solved. Thanks for the clarification Max. > Le 15 fÃ©vr. 2019 Ã 10:43, Max Leske <maxleske(a)gmail.com> a Ã©crit : > > Yeah. I hadn't realized that you were launching Iceberg within launcher. I launched an image first and then opened Iceberg in there. > > Max > > On 14 Feb 2019, at 23:26, Christophe Demarey wrote: > > Le 14 fÃ©vr. 2019 Ã 22:34, Sean P. DeNigris sean(a)clipperadams.com <mailto:sean@clipperadams.com> a Ã©crit : > > demarey wrote > > Probably because the email title is Â« canât install launcher â¦ Â» and the > issue only raises if you try to open Iceberg ;) > > Except Max said: > I downloaded it again... and opened Iceberg without issues. > !! > > Good catch. I should have read more carefully! > Indeed, strange that Max did not get the issue. > > Could it be that Max tried to open it in a launched image? >

Feb. 15, 2019

[Pharo 8.0] Build #81: 2556 RBkeysDoRule should be RBKeysDoRule

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #81 was: SUCCESS. The Pull Request #2557 was integrated: "2556 RBkeysDoRule should be RBKeysDoRule" Pull request url: https://github.com/pharo-project/pharo/pull/2557 Issue Url: https://pharo.fogbugz.com/f/cases/2556 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2019

DisplayableObject

by Pavel Krivanek

Hi Stef, I think that the inclusion of DisplayableObject or something like that will not help in better system design. The only thing that should really know about how to generate forms for icons, should be the UI framework. Imagine that we will want to use something like GTK framework with vector icons. The model classes should ideally never produce icons themselves. We should have maybe some class, an icon description. In the standard case, it will only hold the selector for the icon, but then it may add some additional data (like information about the small progress bar embedded in the icon). In the worst case it could provide as an additional property the form for the icon but then it will limit to use such thing effectively with other UI frameworks (like HTML rendering). If we will add a DisplayableObject, we will only make easier to make models that are not strictly separated from the UI. Cheers, -- Pavel

Feb. 15, 2019

[Pharo 8.0] Build #80: 2550 Cleanup Keymapping-Core

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #80 was: SUCCESS. The Pull Request #2551 was integrated: "2550 Cleanup Keymapping-Core" Pull request url: https://github.com/pharo-project/pharo/pull/2551 Issue Url: https://pharo.fogbugz.com/f/cases/2550 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2019

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Max Leske

Yeah. I hadn't realized that you were launching Iceberg *within* launcher. I launched an image first and then opened Iceberg in there. Max On 14 Feb 2019, at 23:26, Christophe Demarey wrote: >> Le 14 fÃ©vr. 2019 Ã 22:34, Sean P. DeNigris <sean(a)clipperadams.com> >> a Ã©crit : >> >> demarey wrote >>> Probably because the email title is Â« canât install launcher â¦ >>> Â» and the >>> issue only raises if you try to open Iceberg ;) >> >> Except Max said: >> I downloaded it again... and opened Iceberg without issues. >> !! > > Good catch. I should have read more carefully! > Indeed, strange that Max did not get the issue. > > Could it be that Max tried to open it in a launched image?

Feb. 15, 2019

[Pharo 8.0] Build #79: 2525-DiskStoredelete-UTF8-encodes-twice

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #79 was: SUCCESS. The Pull Request #2526 was integrated: "2525-DiskStoredelete-UTF8-encodes-twice" Pull request url: https://github.com/pharo-project/pharo/pull/2526 Issue Url: https://pharo.fogbugz.com/f/cases/2525 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2019

[Pharo 8.0] Build #78: Bottom88

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #78 was: FAILURE. The Pull Request #2545 was integrated: "Bottom88" Pull request url: https://github.com/pharo-project/pharo/pull/2545 Issue Url: https://pharo.fogbugz.com/f/cases/Bottom88 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2019

Re: [Pharo-dev] How does Metacello decide what is already loaded ?

by Dale Henrichs

On 2/14/19 11:28 AM, Sven Van Caekenberghe wrote: > OK, where is the registry, how does it work, where can I read about it ? `MetacelloProjectRegistration registry` ... It is a private registry of loaded baselines and configurations used by Metacello. It's been around roughly 6-7 years or so (ever since I added git support to Metacello and when I create the `Metacello new` style of launching Metacello loads)Â ... 6-7 years ago I wrote a first cut of documentation that Torsten references, but at that time no one cared about the features I had added to Metacello, because, well they pretty much applied to git-based support and using and the `Metacello new` style of launching Metacello andÂ it was hard enought to get folks to use `Metacello new` by itself, let alone any of the "new features" ... Metacello started out (2009) supporting Monticello repositories (ConfigurationOf) and then transitioned (2012)Â to supporting git repositories (BaselineOf). Much of the complexity in Metacello is a carry over from Monticello support ... and isn't really needed. Today (2018) I am working on Rowan which is/will be a wholesale replacement for Monticello/Metacello and the specifications for what packages will be loaded is simplified quite a bit ... So it is a bit ironic, that real interest in how Metacello works comes at a time when I am well on my way to finishing a replacement for Metacello:) Okay this is not entirely true ... over the years I have been quizzed by folks and if you look through the pharo mailing list archives, you'll probably see that I've written a few long-winded mails answering questions or trying to describe how things work:) > > Let's make this more concrete: I load Bootstrap which will load Seaside and I load Material Design Lite which will load Seaside. Will Seaside be loaded twice ? On what does this depend ? How can we as a community make sure we are talking about the same Seaside ? > > That is essentially my question. > > I know it is not an easy question, but I find it an important one. First there is the Monticello "mcz file" answer, which applies to real .mcz files and filetree repositories with Monticello meta data. The simplest case is a project without dependencies. When a Metacello load is kicked off, Metacello evaluates the configuration or baseline specification and determines theÂ list of packages in load order that are needed to satisfy the specification. Metacello then traverses the list and compares the mcz version of the Monticello package working copy in the image with the mcz version of the Monticello package on disk those Monticello packages that are newer than the loaded packages are then loaded into the image .... (how the packages are loaded is dependent upon whether not using are using #atomic or #linear loads). If there is a project dependency, Metacello determines the version of the project that is loaded in the image (looking in the registry) and compares that to the incoming version of the project. If the incoming project version is greater than or equal to the loaded project (this is a simplification of reality, since individual loads can be customized to allow or disallow a number of conflicts and or default decisions made by Metacello), the packages from the dependent project are added to the list of packages in load order ... This process is repeated until all dependent projects are accounted for ... If a dependency loop is encountered as you suggest, Metacello will choose to load the latest version of the dependent project ... In general Metacello loads the latest version of a project encountered and the latest version of package encountered ... If you inspect/print the result `Metacello new ... record` you will see a collection of load directives, which details which packages will be loaded the order that they will be loaded. Here's an example printed load directive from a GemStone image I happen to have open (Seaside is not loaded): [ Metacello new baseline: 'Seaside3'; record ] on: Warning do: [:ex | ex resume ]. linear load : linear load : baseline [BaselineOfSeaside3] load : BaselineOfGLASS1 linear load : baseline [BaselineOfSeaside3] load : BaselineOfGrease linear load : baseline [BaselineOfSeaside3] load : BaselineOfGrease linear load : baseline [BaselineOfSeaside3] linear load : baseline [BaselineOfGLASS1] load : BaselineOfGrease linear load : baseline [BaselineOfGLASS1] load : BaselineOfMetacello linear load : baseline [BaselineOfGLASS1] linear load : 1.0-alpha2.2 [ConfigurationOfGoferProjectLoader] load : Network-Url linear load : baseline [BaselineOfGrease] atomic load : 0.250 [ConfigurationOfGsCore] load : Network-Url-dkh.2 atomic load : 0.243 [ConfigurationOfGsMisc] load : Grease-Core atomic load : 0.243 [ConfigurationOfGsMisc] atomic load : 0.243 [ConfigurationOfGsMisc] load : Grease-GemStone-Core load : Grease-GemStone330-Core load : Grease-Tests-Core load : Grease-Tests-GemStone-Core.v32 linear load : baseline [BaselineOfMetacello] load : BaselineOfFileTree linear load : baseline [BaselineOfMetacello] load : Metacello-Base load : Metacello-Core load : Metacello-MC load : Metacello-Platform.gemstone load : Metacello-ToolBox load : Metacello-Cypress load : Metacello-Tutorial load : Metacello-TestsCore load : Metacello-TestsMCResources load : Metacello-TestsCommonMC.common load : Metacello-TestsMCCore load : Metacello-TestsTutorial linear load : baseline [BaselineOfFileTree] load : MonticelloFileTree-Core load : MonticelloFileTree-FileDirectory-Utilities load : Metacello-GS3x-Platform load : Metacello-FileTree load : Metacello-GitBasedRepository load : Metacello-GitHub load : Metacello-Bitbucket load : Metacello-Reference load : Metacello-TestsReference load : Metacello-TestsMC load : Metacello-TestsMCB load : Metacello-TestsCypress load : Metacello-TestsMCA load : Metacello-TestsPlatform.gemstone load : Metacello-GemStone-TestsMCB load : GemStone-Interactions load : Core.v3 load : GemStone-Compression load : Core322x load : Base-Bootstrap.v3 load : Bootstrap.v34 load : GemStone-ANSI-Streams load : GemStone-Indexing-Extensions.v34 load : OmniBrowser load : OB-GemStone-Platform load : Squeak.v34 load : Regex-Core load : Regex-Tests-Core load : GsSqueakCommon-Core load : GsSqueakCommon-CoreV30 load : PackageInfo-Base.g load : Monticello.v34 load : MonticelloGs.v33 load : GemStone-Deployment.v310 load : Change-Notification.v310 load : OB-Standard.v3 load : OB-Monticello load : OB-SymbolListBrowser load : OB-SUnitIntegration load : OB-SUnitGUI.g load : Announcements load : OB-Tools.v33 load : JadeServer load : GemStone-Release-Support load : Seaside-Squeak-Compatibility linear load : baseline [BaselineOfGrease] atomic load : 0.250 [ConfigurationOfGsCore] load : Core.v3-dkh.78 load : Core322x-dkh.2 load : Base-Bootstrap.v3-dkh.29 load : Bootstrap.v34-dkh.261 load : GemStone-ANSI-Streams-dkh.9 load : GemStone-Indexing-Extensions-dkh.3 load : Squeak.v34-dkh.339 load : Regex-Core-DaleHenrichs.3 load : Regex-Tests-Core-DaleHenrichs.5 atomic load : 0.243 [ConfigurationOfGsMisc] load : Announcements.v3-dkh.18 load : GemStone-Release-Support-dkh.67 load : Grease-Core atomic load : 0.243 [ConfigurationOfGsMisc] atomic load : 0.243 [ConfigurationOfGsMisc] load : Grease-GemStone-Core load : Grease-GemStone330-Core load : Grease-Tests-Core load : Grease-Tests-GemStone-Core.v32 load : Seaside-Continuation linear load : baseline [BaselineOfGrease] atomic load : 0.243 [ConfigurationOfGsMisc] load : Grease-Core atomic load : 0.243 [ConfigurationOfGsMisc] atomic load : 0.243 [ConfigurationOfGsMisc] load : Grease-GemStone-Core load : Grease-GemStone330-Core load : Grease-Tests-Core load : Grease-Tests-GemStone-Core.v32 load : Seaside-Core load : Seaside-GemStone320-Core load : Seaside-GemStone-Core load : Seaside-GemStone-Basic-Development load : Seaside-Tests-Core load : Seaside-Tests-GemStone-Core load : Seaside-Email load : Seaside-GemStone-Email load : Seaside-Canvas load : Seaside-JSON-Core load : Seaside-GemStone-JSON-Core load : Javascript-Core load : Javascript-GemStone-Core load : JQuery-Core load : JQuery-UI load : JQuery-JSON load : Seaside-Session load : Seaside-GemStone-Session load : Seaside-Component load : Seaside-Widgets load : Seaside-GemStone-Tools-Production load : Seaside-RenderLoop load : Seaside-Tools-Core load : Seaside-Tools-Web load : Seaside-GemStone-Tools-Web load : Seaside-Flow load : Seaside-Development load : Seaside-GemStone-Development load : Seaside-Examples load : Seaside-Environment load : Seaside-GemStone-Environment load : Seaside-Tests-Functional load : Seaside-Tests-GemStone-Functional load : Seaside-Tests-Flow load : Seaside-Tests-GemStone-Flow load : Seaside-Welcome load : Seaside-GemStone-Welcome load : Seaside-GemStone-Continuation load : Seaside-Tests-GemStone-Continuation load : Seaside-GemStone-Flow I started off talking about the Monticello load with Monticello meta data ... If you've got a metadataless repository and you've got a projectClass method in the baseline that references MetacelloCypressBaselineProject, then Metacello will ignore the mcz version calculation and load all of the packages from the target repository (which because of git, are all of the proper version). Metacello relies on the fact that Monticello does a package definition comparison before loading which means that only the changed definitions will actually be loaded ... If you don't have a projectClass method in your baseline in a metadataless repository, then Metacello _will_ apply the mcz version rule and because all of the mcz version for packages in a metadataless repository is 1, Metacello will not load anything at all ... the second time you try to load the project in the repository ... Dale

Feb. 15, 2019

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Christophe Demarey

> Le 14 fÃ©vr. 2019 Ã 22:34, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >> Probably because the email title is Â« canât install launcher â¦ Â» and the >> issue only raises if you try to open Iceberg ;) > > Except Max said: > I downloaded it again... and opened Iceberg without issues. > !! Good catch. I should have read more carefully! Indeed, strange that Max did not get the issue. Could it be that Max tried to open it in a launched image?

Feb. 14, 2019

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

by Sean P. DeNigris

demarey wrote > Probably because the email title is Â« canât install launcher â¦ Â» and the > issue only raises if you try to open Iceberg ;) Except Max said: I downloaded it again... and opened Iceberg without issues. !! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 14, 2019