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

Re: [Pharo-dev] changing default theme to DarkTheme

by Stephan Eggermont

On 16/04/17 13:26, Stephane Ducasse wrote: > clement esteban is using the dark theme since several years!!!! > phil too. > No new code! Sorry, but that does not make sense to me. I've only heard complaints about dependent projects not honoring theme color settings, and I've never been able to switch themes actually work without leaving artifacts behind. I agree it makes sense to fix that, and I'm all in favor of temporarily switching default to black in 7. I strongly oppose switching themes now. Stephan

April 16, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 16 April 2017 at 16:42, Ben Coman <btc(a)openinworld.com> wrote: > A historical perspective... > Thanks for the background, Ben. It sounds like the path of least resistance is to forget Pharo 5 and focus on packaging up the Pharo 6 VM in a maintainable way. Then to get a stable VM all I need to do is go hang out at the beach for a few weeks/months while other people sort that out. That works for me :). I have the master branch VM mostly packaged for Nix now, I think. Is there an easy way to run the test suite headless? (How?) I noticed that a few tests failed in your excerpt... perhaps I would consider 99.9% pass rate as good enough to ship. Reasonable? Cheers! -Luke

April 16, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Norbert Hartl

I wonder why voting is considered something good. To me voting is rather a last resort strategy. Voting is taking power without the need for having an opinion nor any reason. To me the sense of voting is to make most people feel empowered/comfortable. And the outcome is often poor or even contradictory. my 2 cents, Norbert > Am 16.04.2017 um 17:49 schrieb Ben Coman <btc(a)openinworld.com>: > > > >> On Sat, Apr 15, 2017 at 8:01 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> Can people just explain to my why we have so many big threads each time >> a default settings is changed? > > Law of triviality. https://en.wikipedia.org/wiki/Law_of_triviality > Because its natural to have personal preferences/opinions and easy > to bike-shed about those. I'm as guilty as the next guy. > > btw, I'm in favour of the board making these sorts of executive decisions rather than voting. > Sure if a vote was 90% against the dark theme it would seem strange to go against it, > but what if it was only 51%. I don't imagine that result really smoothing community sentiment. > Now what about 55% or 60%? Where you draw the line now becomes an executive decision. > > So sometimes its more efficient to just move than have continuous discussions. Also there may > be a bigger picture to bring in more users/money (aka marketting) which we don't hear > the details of. But people do need an opportunity to vent so the board are not blind > to community sentiment. So just roll with it. > > cheers -ben > >> >> I understand that some settings need a certain default value when it >> come for discover-ability of a feature. But why so many noise for >> feature that are totally taste dependent? The principle of settings is >> that some people will like the default one and some will not like it. >> That's the point. >> >> Why are people so afraid of settings? I have the impression that Pharo >> has no setting system each time I see those threads. >> >> Neverless, I agree that we should have a way at the first launch of >> Pharo on a computer to let the user define some common settings as >> Squeak does. It's a really cool feature of most IDEs (like Intellij for >> example). Probably too late for Pharo 6, but not for Pharo 7. >> >> I am just a little tired to see this many noise for things like that. >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >

April 16, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Ben Coman

On Sat, Apr 15, 2017 at 8:01 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Can people just explain to my why we have so many big threads each time > a default settings is changed? > Law of triviality. https://en.wikipedia.org/wiki/Law_of_triviality Because its natural to have personal preferences/opinions and easy to bike-shed about those. I'm as guilty as the next guy. btw, I'm in favour of the board making these sorts of executive decisions rather than voting. Sure if a vote was 90% against the dark theme it would seem strange to go against it, but what if it was only 51%. I don't imagine that result really smoothing community sentiment. Now what about 55% or 60%? Where you draw the line now becomes an executive decision. So sometimes its more efficient to just move than have continuous discussions. Also there may be a bigger picture to bring in more users/money (aka marketting) which we don't hear the details of. But people do need an opportunity to vent so the board are not blind to community sentiment. So just roll with it. cheers -ben > > I understand that some settings need a certain default value when it > come for discover-ability of a feature. But why so many noise for > feature that are totally taste dependent? The principle of settings is > that some people will like the default one and some will not like it. > That's the point. > > Why are people so afraid of settings? I have the impression that Pharo > has no setting system each time I see those threads. > > Neverless, I agree that we should have a way at the first launch of > Pharo on a computer to let the user define some common settings as > Squeak does. It's a really cool feature of most IDEs (like Intellij for > example). Probably too late for Pharo 6, but not for Pharo 7. > > I am just a little tired to see this many noise for things like that. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

April 16, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Ben Coman

On Sun, Apr 16, 2017 at 10:50 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Ben, > > On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote: >> On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> > On 15 April 2017 at 10:08, Alistair Grant <akgrant0710(a)gmail.com> >> > wrote: >> > >> > Grabbing the source directly from Git is attractive if (a) I know >> > that I am choosing a good version and (b) I am able to build it in a >> > good way. >> > >> > Seems like a workable solution to (a) is to periodically check for a >> > new binary release, work out which commit it is based off, and build >> > that. This seems fairly reasonable and is probably also possible to >> > automate. (I suppose you got the commit-id from --version or from >> > checking Jenkins.) >> > >> > I see (b) as problematic though. The source tarball releases have a >> > simple build procedure ("make") while the Git checkouts require a >> > more involved one (bootstrapping the VM from an existing Pharo >> > image.) >> >> A historical perspective... >> >> Prior to this coming Release 6, Pharo had diverged from the parent >> build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it >> was driven from the Image generating the generated-C-sources plus the >> Cmake configuration. I guess this is what you describe as >> "bootstrap". >> >> However for Release 6 onwards, Pharo has returned to the fold and is >> directly using the OpenSmalltalk build system. The OpenSmalltalk build >> system does not require a build to invoke a Smalltalk image, and I >> notice elsewhere you've seen the ./ mvm script. Eliot currently >> manually updates the checked-in generated-C-sources at times he >> considers them stably generated from VMMaker-Image, although I think I >> saw recently some mention of doing CI on each VMMaker check-in.. > > Do you know how the linux zero conf scripts are / will be built? > > My assumption has been that they are part of the image build. I'm not familiar with the zero-conf implementation. You might learn something here... https://github.com/pharo-project/pharo-zeroconf cheers -ben

April 16, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Ben Coman

Personally I'm not adverse to this switch even though I've not used the dark theme much, but as devils advocate a few questions arise. a. How will you make Pharo 7/8/9/etc visually distinct? a1. *cough* Switch back to white theme? a2. How much visual distinction is required? a3. Would it be easier to continually alter... background Pharo logo background colour / pattern titlebar icons, font, colour b. What are the considerations of effect on documentation? b1. PBE b2. mooc c. Will this have adequate testing? c1. Its a late change with significant impact to first impressions c2. I understand that some people have been using it a lot, but they may have narrow environments. For example, enabling the Dark theme, on my laptop with brightness turned down, I find it disconcerting that I can't distinguish where title bars run into each other. https://pharo.fogbugz.com/f/cases/19941/Dark-Theme-overlapped-title-bars-ne… cheers -ben P.S. I'm travelling so I can't work on this myself for a few days. On Sat, Apr 15, 2017 at 4:23 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > tx pavel! > We need a look that we can identify pharo 60 as pharo 60 :) > > > On Fri, Apr 14, 2017 at 2:42 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> >> >> 2017-04-14 13:48 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> >>> 2017-04-14 13:27 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>> But to me it is too late for such change. I am sure there are UI >>>> widgets/projects which looks horrible in dark. And people probably test them >>>> in pharo 6 before this change. So they will be very surprised. >>>> >>>> >>>> no, dark theme is around since 3 years and is very depurated. In fact, >>>> many people already use it as they preferred theme. >>> >>> >>> Just open any project with Versioner. Symbolic versions are in green oval >>> with white label. It is almost unreadable. >> >> >> Let's be constructive :-) >> >> https://pharo.fogbugz.com/f/cases/19935/Versionner-tags-are-unreadable-in-t… >> >>> >>> >>> Do you remember how many times Steph complains about style of current >>> white theme? I am sure he not deeply look into dark. >> >> >

April 16, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

Hi Ben, On Sun, Apr 16, 2017 at 10:42:42PM +0800, Ben Coman wrote: > On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > On 15 April 2017 at 10:08, Alistair Grant <akgrant0710(a)gmail.com> > > wrote: > > > > Grabbing the source directly from Git is attractive if (a) I know > > that I am choosing a good version and (b) I am able to build it in a > > good way. > > > > Seems like a workable solution to (a) is to periodically check for a > > new binary release, work out which commit it is based off, and build > > that. This seems fairly reasonable and is probably also possible to > > automate. (I suppose you got the commit-id from --version or from > > checking Jenkins.) > > > > I see (b) as problematic though. The source tarball releases have a > > simple build procedure ("make") while the Git checkouts require a > > more involved one (bootstrapping the VM from an existing Pharo > > image.) > > A historical perspective... > > Prior to this coming Release 6, Pharo had diverged from the parent > build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it > was driven from the Image generating the generated-C-sources plus the > Cmake configuration. I guess this is what you describe as > "bootstrap". > > However for Release 6 onwards, Pharo has returned to the fold and is > directly using the OpenSmalltalk build system. The OpenSmalltalk build > system does not require a build to invoke a Smalltalk image, and I > notice elsewhere you've seen the ./ mvm script. Eliot currently > manually updates the checked-in generated-C-sources at times he > considers them stably generated from VMMaker-Image, although I think I > saw recently some mention of doing CI on each VMMaker check-in.. Do you know how the linux zero conf scripts are / will be built? My assumption has been that they are part of the image build. Thanks, Alistair

April 16, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Ben Coman

On Sat, Apr 15, 2017 at 4:34 PM, Luke Gorrie <luke(a)snabb.co> wrote: > On 15 April 2017 at 10:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Grabbing the source directly from Git is attractive if (a) I know that I am > choosing a good version and (b) I am able to build it in a good way. > > Seems like a workable solution to (a) is to periodically check for a new > binary release, work out which commit it is based off, and build that. This > seems fairly reasonable and is probably also possible to automate. (I > suppose you got the commit-id from --version or from checking Jenkins.) > > I see (b) as problematic though. The source tarball releases have a simple > build procedure ("make") while the Git checkouts require a more involved one > (bootstrapping the VM from an existing Pharo image.) A historical perspective... Prior to this coming Release 6, Pharo had diverged from the parent build system used by OpenSmalltalk (nee Squeak-VM) such that (IIUC) it was driven from the Image generating the generated-C-sources plus the Cmake configuration. I guess this is what you describe as "bootstrap". However for Release 6 onwards, Pharo has returned to the fold and is directly using the OpenSmalltalk build system. The OpenSmalltalk build system does not require a build to invoke a Smalltalk image, and I notice elsewhere you've seen the ./mvm script. Eliot currently manually updates the checked-in generated-C-sources at times he considers them stably generated from VMMaker-Image, although I think I saw recently some mention of doing CI on each VMMaker check-in.. So the Pharo 5 in-Image CMake generation system is deprecated, and I guess there will not be much further development on the Pharo 5 VM. So I would consider *not* including the bootstrap as part of the nix process and manually perform the bootstrap per steps 1 to 3 here... * https://github.com/pharo-project/pharo-vm/tree/5.0-stable then archive those folders to create your own source-distribution Now it would be good to hear if Pharo might get a Pharo-5-stable-VM deployed from OpenSmalltalk? cheers -ben > So I would need to > revise the nix build scripts quite a bit if I want to build from Git instead > of the tarballs. However, it seems that on the master branch last week the > VM build procedure has been reworked so that it is _not_ necessary to run > the bootstrapping procedure anymore, which sounds great to me, except that I > understand this new build procedure to be quite bleeding edge and not yet > documented or used for a binary release (it's not included in the commit > that you cite above.) > > So what to make of all that? Just right now I see only bad alternatives: > sticking with the source release means not supporting Pharo 5.0, updating > the build scripts to do bootstrapping takes effort and is already obsoleted > by changes on the VM master branch, and shipping the VM master branch means > making a pseudo-release without any QA and potentially causing problems for > people downstream (there are lots of commits landing on that branch and I > have no idea which ones are important/stable.) > > So the most reasonable course of action from my point of view seems to be to > sit and wait for a better solution to come along e.g. a new source release > of the VM or a "blessed" Git commit ID that includes the updated build > scripts. The downside is that meanwhile NixOS users can't run the 5.0 image. > Could be that Pharo 6.0 will resolve this and that is fine for me -- but of > course I'd take a solution sooner if there is a simple one. > >

April 16, 2017

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

by Dimitris Chloupis

Just for the record the easiest way to load packages in the image the Package Browser relies solely on configurations . Is there a plan to migrate because as much I am vocal supporter of Pharo moving to git it will be a big lose if Package Browser is not ported . On Sun, 16 Apr 2017 at 09:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > However, Configurations are useful in offering people a way to understand > how the code is organized. For example, in Moose we have the inspector > extension that shows the dependencies and it is very valuable. > > The only thing we need is to Metacello to be able to load new versions of > the configuration/baseline. > > Cheers, > Doru > > > > On Apr 16, 2017, at 8:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > For the record, the way we load the latest version of Moose is to > explicitly load the configurations we know about as being in the base Pharo > image. Like this: > > > > ./pharo $JOB_NAME.image eval "Gofer new smalltalkhubUser: 'Moose' > project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; package: > 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; > package: 'ConfigurationOfGTSpotter'; package: > 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTPlaygroundCore'; > package: 'ConfigurationOfGToolkit'; package: 'ConfigurationOfGToolkitCore'; > package: 'ConfigurationOfGTEventRecorder'; load. Smalltalk snapshot: true > andQuit: true." > > > > This is a horrible hack, and like any hack it backfires in time. It > backfired now because we forgot about MooseAlgos being in the base Pharo > image :). > > > > Cheers, > > Doru > > > > > >> On Apr 15, 2017, at 11:23 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> > >> On 15/04/2017 23:16, Tudor Girba wrote: > >>> Hi, > >>> > >>> Ok, that is a better reason. > >>> > >>> As far as I can tell, the baseline situation is not much better, is it? > >>> > >>> Cheers, > >>> Doru > >>> > >> > >> Yes. > >> > >> If the process would have been the same for Pharo 7 than for Pharo 6 I > >> would have suggest to unload the configurations after every update of a > >> project using configuration. > >> > >> Here, since the process will change I wait to see how the new process > >> will look like. But I would like the configurations/baselines to be > >> unload of Pharo to avoid this. > >> > >> I would like to unload all the configurations of the image of Pharo 6 to > >> remove a potential bug source of Pharo 6 for future users who would need > >> an update of GlamourCore, a GT tool, Ston, UFFI or any other project > >> having his configuration in the image. > >> > >> -- > >> 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 > > > > "Problem solving should be focused on describing > > the problem in a way that makes the solution obvious." > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > âThe smaller and more pervasive the hardware becomes, the more physical > the software gets." > > >

April 16, 2017

Re: [Pharo-dev] Epicea should ask before recovering

by Dimitris Chloupis

Me three Recover dialog is standard on all apps anyway On Sun, 16 Apr 2017 at 16:22, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-16 12:09 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > >> Of course if I am the only person that uses images in such a way then I >> can just work around it myself. (because having endless lists of config >> options is also nightmare) > > > Me too >

April 16, 2017