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

Re: [Pharo-dev] Traits methods flattened

by Hilaire

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 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-c… >> >> Test please... >> -- Pavel -- Dr. Geo http://drgeo.eu

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Tudor Girba

Really nice, indeed! Doru > On Apr 25, 2017, at 9:21 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Thank you Pavel! This looks absolutely amazing. > > Uko > >> On 25 Apr 2017, at 00:48, 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 >> >> > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

April 25, 2017

Re: [Pharo-dev] Traits methods flattened

by Hilaire

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-c… > > Test please... > -- Pavel -- Dr. Geo http://drgeo.eu

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Yuriy Tymchuk

Thank you Pavel! This looks absolutely amazing. Uko > On 25 Apr 2017, at 00:48, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Right, next try... > > https://goo.gl/photos/YnGoZTrpKjJnSbFU9 <https://goo.gl/photos/YnGoZTrpKjJnSbFU9> > > -- Pavel > > > > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>>: > Le 24/04/2017 Ã 22:13, Pavel Krivanek a Ã©crit : > > New version: > > > > https://goo.gl/photos/66Yz3pSSK62aTYV66 <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 <https://ferlicot.fr/> > > http://www.synectique.eu <http://www.synectique.eu/> > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Ben Coman

That last one is much better. I really like the presentation of the "newProcess" method. Its a quick technical dive. Perhaps the comment needs to be tuned a wider audience, describing how process creation is green-thread and and all managed by Smalltalk code. The warning about debugging this deep does't need to be shown. This is "marketing" after all. it might also be good if the comment described what class "self" is referring to, and what sending value to it does. Change "Simulation guard" to "VM simulation guard primitive". Also breaking the code down to use a variable I think makes it clearer for an outside to parse. I wonder if the method text might something like be... newProcess "The receiver (self) of this message is a closure. Return a Process (green thread) to evaluate the value of receiver's bytecode. The process is not scheduled." <primitive: 19> "VM simulation guard primitive" |executionContext| executionContext := [self value. Processor terminateActive] asContext. ^ Process forContext: executionContext priority: Processor activePriority In general its well laid out and not much room for anything else, but what do you think about having a small Playground window with text "SomeClass allInstances inspect" and then the inspector overlapping it, for some interesting SomeClass. Try masking around the "newProcess" window on a separate layer so the whole window is "brought forward". The placement of the Time Profiler is really good. Perhaps the title bar of "PetitParser Browser" can be renamed something more broadly understandable, like "Grammar Browser" or "PetitParser Grammar Browser". Pull the Epicea window down so its title bar shows and displays something understandable like "Change History" The title text of "Inspector on a RTView" might be slide to the left on the titlebar so that it shows in the less blurred part, but "RTView" is meaningless outside our community so maybe something like "Inspector on Data Chart" cheers -ben On Tue, Apr 25, 2017 at 5:48 AM, 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 >> >> >

April 25, 2017

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

by Thierry Goubier

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. >> At least, now I can easily see directly in the browser how the Pharo 6 >> development is moving packages inside configurations and baselines >> from version to version. I'll tackle next integrating that with >> Metacello, that is running project-based Metacello commands using that >> project structure. > Let me know if there are any operations that you should think > could/should be included in Metacello itself ... If you are doing things > that are similar to what I'm doing in tODE, then it probably makes sense > to move the method into Metacello, so that other tool builders cna share > common code ... Thanks, I'll do. Thierry > Dale >> >> Thierry >> >>> Dale >>> >>> >> >> > > >

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Esteban A. Maringolo

Awesome, literally, as in awe. It will be hard to measure, but I'd bet that screenshot would bring more people to Pharo tan many blog posts and other efforts. A picture is worth a thousand words. Great work! Esteban A. Maringolo 2017-04-24 18:48 GMT-03:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > 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 >> >

April 25, 2017

Re: [Pharo-dev] Pharo 6 screenshot

by Graham McLeod

Yes! G Pavel Krivanek 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 > <mailto:cyril.ferlicot@gmail.com>>: > > Le 24/04/2017 Ã 22:13, Pavel Krivanek a Ã©crit : > > New version: > > > > https://goo.gl/photos/66Yz3pSSK62aTYV66 > <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 > >

April 24, 2017

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

by Dale Henrichs

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 ... > > At least, now I can easily see directly in the browser how the Pharo 6 > development is moving packages inside configurations and baselines > from version to version. I'll tackle next integrating that with > Metacello, that is running project-based Metacello commands using that > project structure. Let me know if there are any operations that you should think could/should be included in Metacello itself ... If you are doing things that are similar to what I'm doing in tODE, then it probably makes sense to move the method into Metacello, so that other tool builders cna share common code ... Dale > > Thierry > >> Dale >> >> > >

April 24, 2017