March 2019 - Pharo-users - lists.pharo.org

Per project code formatting settings and policy

by Holger Freyther

Hi! I found myself doing codereview and commenting on style (e.g. missing indention). It seems like a task that can be easily automated and in fact we have RBFormmatter/BlueInk to do it. What I didn't see is if a project can supply the style (instead of the image configuration)? How could this be achieved? holger

March 15, 2019

Pharo 7.0.2 is starting to appear suspect to me

by Tim Mackinnon

I donât know if others are using Pharo 7.0.2 in anger - I was previously using 7.0.1 - but Iâm finding that having used it for a few hours now (doing things Iâve been doing for weeks in the older version) that its not as stable. I used to be able to delete a hundred classes a few times a day (when doing some testing) and it didnât blink - but 7.0.2 is now having announcement issues. I also keep getting the font problems much more frequently and Iâve had some strange lockups (which could be associated with the Mirage task switcher). But anyway - Iâm just calling it outâ¦ Tim

March 15, 2019

Re: [Pharo-users] Corrupted fonts in P7 after loading Glamorous Toolkit

by Tim Mackinnon

And it gets more ridiculousâ¦ Pharo is trying to solve the damn problem for me... > On 31 Jan 2019, at 22:12, Tim Mackinnon <tim(a)testit.works> wrote: > > As an observation that might help with this - Iâve not been able to recreate the corruption after I had re-saved the image and cured the original corruption. I will go back to my original starting image and see if I can corrupt it from there (previously I had been able to). > > So Iâm not sure why that save and subsequent font cache reset would hold when it didnât seem to before. > > Tim > >> On 26 Jan 2019, at 08:27, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I donât think is related to GToolkit, it is an ongoing bug we are having (and we still do not understand why it happens, but we are looking at it). >> In the mean time, saving the image will âfixâ the problem (because it will reset the font caches). >> >> Esteban >> >> >>> On 25 Jan 2019, at 17:43, Hilaire <hilaire(a)drgeo.eu> wrote: >>> >>> I did got this effect with GToolkit. I am not sure it is related to >>> GToolkit as I installed immediately this package, though. >>> >>> Hilaire >>> >>> Le 25/01/2019 Ã 16:55, Tim Mackinnon a Ã©crit : >>>> Hi - I just noticed that when I loaded the Glamorous toolkit and was playing around, when I went to look in the Pharo menus they are all corrupted (the odd character is some type of glyph). Opening a playground and doing some code completion shows that method names have the same random character glyphed. >>>> >>>> Anyone else seen this? Is is it something about loading GT? >>>> >>>> This is on OSX >>>> >>>> Tim >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu >>> >>> >>> >> >> > >

March 14, 2019

Re: [Pharo-users] Corrupted fonts in P7

by Tim Mackinnon

Bumping this again, as in a new Pharo 7.0.2 image I keep getting font corruption. Saving the image seems to cure it a bit, but it seems more pronounced 7.0.2 e.g. (and ironic that I was looking at some Roman numerals tests - but setup is buggered, and a few minutes ago it was the âallâ in Remove all breakpointsâ¦. Is anything being officially looked at? How can we cure this? > On 31 Jan 2019, at 22:12, Tim Mackinnon <tim(a)testit.works> wrote: > > As an observation that might help with this - Iâve not been able to recreate the corruption after I had re-saved the image and cured the original corruption. I will go back to my original starting image and see if I can corrupt it from there (previously I had been able to). > > So Iâm not sure why that save and subsequent font cache reset would hold when it didnât seem to before. > > Tim > >> On 26 Jan 2019, at 08:27, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I donât think is related to GToolkit, it is an ongoing bug we are having (and we still do not understand why it happens, but we are looking at it). >> In the mean time, saving the image will âfixâ the problem (because it will reset the font caches). >> >> Esteban >> >> >>> On 25 Jan 2019, at 17:43, Hilaire <hilaire(a)drgeo.eu> wrote: >>> >>> I did got this effect with GToolkit. I am not sure it is related to >>> GToolkit as I installed immediately this package, though. >>> >>> Hilaire >>> >>> Le 25/01/2019 Ã 16:55, Tim Mackinnon a Ã©crit : >>>> Hi - I just noticed that when I loaded the Glamorous toolkit and was playing around, when I went to look in the Pharo menus they are all corrupted (the odd character is some type of glyph). Opening a playground and doing some code completion shows that method names have the same random character glyphed. >>>> >>>> Anyone else seen this? Is is it something about loading GT? >>>> >>>> This is on OSX >>>> >>>> Tim >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu >>> >>> >>> >> >> > >

March 14, 2019

Re: [Pharo-users] Pharo 7.0.2 osx from launcher has corrupted welcome screen?

by Tim Mackinnon

Iâll raise an issue > On 14 Mar 2019, at 20:07, N. Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Yes Tim. I've have it too. > > Noury > >> On 14 Mar 2019, at 21:02, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Has anyone else noticed that the the newer 7.0.2 image (from launcher) has a corrupted welcome screen? This is on osx (high Sierra) from today. >> >> The image seems to work fine, its just that initial welcome screen? Did something get corrupted on the deployment? >> >> Tim >> >> <PastedGraphic-7.png> > >

March 14, 2019

Is epicea on the roadmap for 8?

by Tim Mackinnon

A few times now when trying to sort out issue, Iâve wanted to search for a particular class to understand what has happened and also to recover source code for it - the current epicea only has very general search and as it replaces the change.log (which was text and searchable) we need better search tools - unless Iâm missing something obvious. Tim

March 14, 2019

Re: [Pharo-users] Pharo 7.0.2 osx from launcher has corrupted welcome screen?

by N. Bouraqadi

Yes Tim. I've have it too. Noury > On 14 Mar 2019, at 21:02, Tim Mackinnon <tim(a)testit.works> wrote: > > Has anyone else noticed that the the newer 7.0.2 image (from launcher) has a corrupted welcome screen? This is on osx (high Sierra) from today. > > The image seems to work fine, its just that initial welcome screen? Did something get corrupted on the deployment? > > Tim > > <PastedGraphic-7.png>

March 14, 2019

Pharo 7.0.2 osx from launcher has corrupted welcome screen?

by Tim Mackinnon

Has anyone else noticed that the the newer 7.0.2 image (from launcher) has a corrupted welcome screen? This is on osx (high Sierra) from today. The image seems to work fine, its just that initial welcome screen? Did something get corrupted on the deployment? Tim

March 14, 2019

Re: [Pharo-users] can I add a class to material design ?

by Cyril Ferlicot

On Thu 14 Mar 2019 at 08:17, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > I wonder if I can add a custom class to a material design card so I can > have a image on the left or a image on the top based on the dimisions of > the image. Hello, MDL works the same way as Seaside. Cards have brushes that understand the #class: message. > > Roelof > > > -- Cyril Ferlicot https://ferlicot.fr

March 14, 2019

Does the blue ink formatter setting: 'Selector and argument combined in method signature max size' work?

by Tim Mackinnon

Having done a bunch of refactoring on my code - I realised that the default settings for the code formatter arenât the greatest (and I know this is quite personal). So Iâve tweaked a few things (the default settings arenât bad but I donât understand why "retain black lines between statements" isnât on by default - as the alternative really gives us bad looking code. Ideally, there should be a number you can set - for max blanks to preserve, but the current 0 is not great). However - my question is how to stop smaller keyword messages from being wrapped? If I have the setting âmethod signature on multiple linesâ NOT checked (default), I understood that "Selector and argument combined in method signature max sizeâ would then be used to determine if a statement is wrapped or not? However even with big numbers a statement like: exercismSubmission := ExercismSubmission data: (self class sampleDataFor: 'test-ex' filenames: actualNames baseUrl: baseUrl). Always gets wrapped to: exercismSubmission := ExercismSubmission data: (self class sampleDataFor: 'test-ex' filenames: actualNames baseUrl: baseUrl). Is there some other setting I am missing? Or is this just a bug? Tim

March 14, 2019