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

[Pharo 7.0-dev] Build #801: 21756-Add-roots-and-hierarchyRoots-to-RPackage

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

There is a new Pharo build available! The status of the build #801 was: SUCCESS. The Pull Request #1243 was integrated: "21756-Add-roots-and-hierarchyRoots-to-RPackage" Pull request url: https://github.com/pharo-project/pharo/pull/1243 Issue Url: https://pharo.fogbugz.com/f/cases/21756 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Esteban Lorenzano

hi, > On 24 Apr 2018, at 00:49, monty <monty2(a)programmer.net> wrote: > > +1. > > Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. thatâs clearly because you didnât see nautilus at the inside. In fact, calypso started like thatâ¦ we wanted to refactor nautilus into something usable, but after losing two months of Denis work, we decided to go other direction, since it was just impossible to do it properly without doing it again. And the effort of doing it from scratch was less than âdestroy the house for the inside but let the faÃ§adeâ that would have been working with Nautilus. Also, in the case of Nautilus (or any system browser), there is the adding complexity of refactoring within itself. Not everything can be refactored/patched up to the infinite. > And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? catalog was a âtemporary pieceâ that stayed for years. it was never intend to stay because it has some important limitations. said that, it can evolve from the quasi-prototype it is now (I should know, it was me who did it) to a real catalog. curiously, Iâm thinking one part of making it better would be simplify it, but thatâs another story. I wonder why people is so concerned about the use of âkilling catalogâ phrase. If you know the history of Pharo, we never âkillâ anything we do not have a replacement for it so it was never in the table a proposal of just removing it. But to be good it needs: - some better way of collect baselines than force to build a configuration - a better place to be - some kind of validation rules - etc, etc, etc. So well, in this case maybe refactor it is not an option, since many of the assumptions it has are no longer valid. cheers, Esteban > > ___ > montyos.wordpress.com > > >> Sent: Sunday, April 22, 2018 at 9:29 AM >> From: "Torsten Bergmann" <astares(a)gmx.de> >> To: pharo-dev(a)lists.pharo.org >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Do we kill the catalog? >> >> Hi Stef, >> >> do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having >> or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" >> and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. >> >> If it was not clear from my writing: I only expressed my wish that we should better improve it >> instead of killing it. That's all. >> >> Because anytime we have a better idea we get more disruptive in what we provide ... and this >> leads to the unfortunate situation: >> >> - that we replace our own stuff with newer ones again and again (which can but must not be good >> as things get more diverse and complicated over time) >> - that users have to know how things historically have been progressed to find its way >> through Pharo (including the terms and tools we use) >> >> I would not see this as a rant - but rather a true effect we can spot on many places in our >> ecosystem already. >> >> Long story short: I would vote for the "fix" if the sole other option is to "remove". >> >> Bye >> T. >> >> >>> Gesendet: Samstag, 21. April 2018 um 15:31 Uhr >>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: Re: [Pharo-dev] Do we kill the catalog? >>> >>> Torsten >>> >>> Sometimes you should relax. Because if you remember I pushed the >>> catalog (in fact I love it and we need a much more powerful one) >>> and I even improved it. I made it better to automatically add MC repositories. >>> Of course Thierry is exagerating. >>> >>> Now we should fix or remove it. Simple no? >>> >>> Now you can rant in your corner thinking that I'm asshole. >>> This is ok for me. >>> >>> Stef >>> >>> On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> Even there is no learning from the past - it's deja vu all over again... >>>> >>>> >>>>> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr >>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Betreff: Re: [Pharo-dev] Do we kill the catalog? >>>>> >>>>> Hi torsten >>>>> >>>>> the wise shows the moon, the idiot sees his finger. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>>> Now today you had loading trouble with Smacc from Catalog ... and now directly want to >>>>>> kill catalog. Wow! >>>>>> >>>>>> Sometimes I have the impression that our community tries to reinvent itself each day >>>>>> doing it differently (but not only better) instead of extending, improving and supporting >>>>>> what we have have done before. Which sometimes is good ... but not always. >>>>>> >>>>>> Thx >>>>>> T. >>>>>> >>>>>>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr >>>>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>>>> Betreff: [Pharo-dev] Do we kill the catalog? >>>>>>> >>>>>>> Hi guys >>>>>>> >>>>>>> What do we do with it? >>>>>>> What alternatives? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Guillermo Polito

Hi all, I think that we are all aligned. Stef may be "too strong" in his way of talking, but he raised an issue: we should probably do an iteration on the catalog. And I think we all agree on that? So, what would be a list of tasks for it? (I copy past what Stef put before) - Use Metacello API. Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY' This point should is easy. I can open an issue and work on it today. - Support for Baseline (no idea what it means) This point requires that we agree on how to publish baselines. Should we continue providing configurations that point to the baselines? I've read some rants against it. I know it may be "uncomfortable", but publishing some meta-data in a repository in XXX technology is kind of the same... We can argue about visibility and smalltalkhub's stability (I've seen new users struggling to create an account and making a satisfactory login), but this can be a separate issue. - What else? Now, I also think about what to do with the meta-repo's. Should Pharo7 see MetaRepo for pharo 5 and pharo 6 and pharo 4? or should only see the one for pharo 7? What about Pharo 6? What are the meta-repo's it is looking for? -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Thierry Goubier

2018-04-24 7:31 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 24 Apr 2018, at 00:49, monty <monty2(a)programmer.net> wrote: >> >> +1. >> >> Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? >> >> ___ >> montyos.wordpress.com > > Nice blog, BTW! And I note: Publishing Configurations to Pharo Meta Repositories https://montyos.wordpress.com/2018/04/22/publishing-configurations-to-pharo… Thierry

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Sven Van Caekenberghe

> On 24 Apr 2018, at 00:49, monty <monty2(a)programmer.net> wrote: > > +1. > > Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? > > ___ > montyos.wordpress.com Nice blog, BTW! Your XML work is much appreciated. >> Sent: Sunday, April 22, 2018 at 9:29 AM >> From: "Torsten Bergmann" <astares(a)gmx.de> >> To: pharo-dev(a)lists.pharo.org >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Do we kill the catalog? >> >> Hi Stef, >> >> do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having >> or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" >> and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. >> >> If it was not clear from my writing: I only expressed my wish that we should better improve it >> instead of killing it. That's all. >> >> Because anytime we have a better idea we get more disruptive in what we provide ... and this >> leads to the unfortunate situation: >> >> - that we replace our own stuff with newer ones again and again (which can but must not be good >> as things get more diverse and complicated over time) >> - that users have to know how things historically have been progressed to find its way >> through Pharo (including the terms and tools we use) >> >> I would not see this as a rant - but rather a true effect we can spot on many places in our >> ecosystem already. >> >> Long story short: I would vote for the "fix" if the sole other option is to "remove". >> >> Bye >> T. >> >> >>> Gesendet: Samstag, 21. April 2018 um 15:31 Uhr >>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: Re: [Pharo-dev] Do we kill the catalog? >>> >>> Torsten >>> >>> Sometimes you should relax. Because if you remember I pushed the >>> catalog (in fact I love it and we need a much more powerful one) >>> and I even improved it. I made it better to automatically add MC repositories. >>> Of course Thierry is exagerating. >>> >>> Now we should fix or remove it. Simple no? >>> >>> Now you can rant in your corner thinking that I'm asshole. >>> This is ok for me. >>> >>> Stef >>> >>> On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> Even there is no learning from the past - it's deja vu all over again... >>>> >>>> >>>>> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr >>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Betreff: Re: [Pharo-dev] Do we kill the catalog? >>>>> >>>>> Hi torsten >>>>> >>>>> the wise shows the moon, the idiot sees his finger. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>>> Now today you had loading trouble with Smacc from Catalog ... and now directly want to >>>>>> kill catalog. Wow! >>>>>> >>>>>> Sometimes I have the impression that our community tries to reinvent itself each day >>>>>> doing it differently (but not only better) instead of extending, improving and supporting >>>>>> what we have have done before. Which sometimes is good ... but not always. >>>>>> >>>>>> Thx >>>>>> T. >>>>>> >>>>>>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr >>>>>>> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>>>> Betreff: [Pharo-dev] Do we kill the catalog? >>>>>>> >>>>>>> Hi guys >>>>>>> >>>>>>> What do we do with it? >>>>>>> What alternatives? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >

April 24, 2018

Re: [Pharo-dev] Do we kill the catalog?

by monty

+1. Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? ___ montyos.wordpress.com > Sent: Sunday, April 22, 2018 at 9:29 AM > From: "Torsten Bergmann" <astares(a)gmx.de> > To: pharo-dev(a)lists.pharo.org > Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Do we kill the catalog? > > Hi Stef, > > do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having > or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" > and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. > > If it was not clear from my writing: I only expressed my wish that we should better improve it > instead of killing it. That's all. > > Because anytime we have a better idea we get more disruptive in what we provide ... and this > leads to the unfortunate situation: > > - that we replace our own stuff with newer ones again and again (which can but must not be good > as things get more diverse and complicated over time) > - that users have to know how things historically have been progressed to find its way > through Pharo (including the terms and tools we use) > > I would not see this as a rant - but rather a true effect we can spot on many places in our > ecosystem already. > > Long story short: I would vote for the "fix" if the sole other option is to "remove". > > Bye > T. > > > > Gesendet: Samstag, 21. April 2018 um 15:31 Uhr > > Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: Re: [Pharo-dev] Do we kill the catalog? > > > > Torsten > > > > Sometimes you should relax. Because if you remember I pushed the > > catalog (in fact I love it and we need a much more powerful one) > > and I even improved it. I made it better to automatically add MC repositories. > > Of course Thierry is exagerating. > > > > Now we should fix or remove it. Simple no? > > > > Now you can rant in your corner thinking that I'm asshole. > > This is ok for me. > > > > Stef > > > > On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Even there is no learning from the past - it's deja vu all over again... > > > > > > > > >> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr > > >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > > >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > >> Betreff: Re: [Pharo-dev] Do we kill the catalog? > > >> > > >> Hi torsten > > >> > > >> the wise shows the moon, the idiot sees his finger. > > >> > > >> Stef > > >> > > >> > > >> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > >> > Now today you had loading trouble with Smacc from Catalog ... and now directly want to > > >> > kill catalog. Wow! > > >> > > > >> > Sometimes I have the impression that our community tries to reinvent itself each day > > >> > doing it differently (but not only better) instead of extending, improving and supporting > > >> > what we have have done before. Which sometimes is good ... but not always. > > >> > > > >> > Thx > > >> > T. > > >> > > > >> >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > > >> >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > > >> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > >> >> Betreff: [Pharo-dev] Do we kill the catalog? > > >> >> > > >> >> Hi guys > > >> >> > > >> >> What do we do with it? > > >> >> What alternatives? > > >> >> > > >> >> Stef > > >> >> > > >> >> > > >> > > > >> > > >> > > > > > > > > >

April 23, 2018

Re: [Pharo-dev] [squeak-dev] How to yellow click with two buttons without changing mouse settings?

by Eliot Miranda

Hi Marcel, On Sun, Apr 22, 2018 at 11:24 PM, Marcel Taeumel <marcel.taeumel(a)hpi.de> wrote: > Hi Jakob, > > do: "HandMorph showEvents: true" then do CTRL+RED/LEFT. You will see that > you get, in fact, a yellow click. I think that there is code that checks > for "control pressed" first to show the different menu. So, we do emulate > that yellow-click in the VM, but we keep the "control pressed"-flag. So, > the event state is different, even though you get "event > yellowButtonPressed = true" both times. > > To sum up some prior thoughts on this topic: > 1) The VM should not provide this single-button-mouse behavior but the > image should. > 2) The event filters to simulate those yellow/blue clicks are already > possible in the image. We do it with mouse-wheel vs. CTRL+up/down already. > 3) A good transformation for CTRL+RED in such a single-button-mouse mode > would be YELLOW and not CTRL+YELLOW. > > Anyway, this is not an easy fix or decision to make. :-) > What would be relatively straight-forward is to add an image property flag alongside the ones in the image flag word such as "floats in platform order", "processPreemptionYields", etc in vm parameter 48. This flag would tell the VM not to do any event modifications (or at least no mouse button swapping). And then we could at least experiment with allowing the image to perform event modification, making this a preference, etc, before some fine day in the future, transitioning away from VM support for event modification in a major release. Thoughts? > Best, > Marcel > > Am 21.04.2018 14:35:43 schrieb Jakob Reschke <forums.jakob(a)resfarm.de>: > Hello, > > I downloaded a VM (64 bit Cog Spur Windows) and a fresh trunk image > separately and have not changed any mouse button settings yet (swap > mouse buttons preference is on and neither 1 button mouse nor 3 button > mouse are selected in the VM preferences menu). My notebook does not > have a middle "mouse" button and the right button currently does a > blue click (opens the halo). > > In this default setting, is there any way to do a yellow click? > > I get the morph menu with ctrl+left click and in list morphs and on > the world I can invoke the menu with the Esc key, but I did not find a > modifier+button combination that would work universally to emulate a > yellow click. Have I missed it? > > After disabling swap mouse buttons, right click becomes a yellow > click. But when the preference is on, both right click and alt+left > click produce a blue click. So with a two button mouse it seems that > nothing is actually swapped, but one button is unavailable > altogether... > > A simple solution would be to turn the preference off by default. > > Kind regards, > Jakob > > > > > -- _,,,^..^,,,_ best, Eliot

April 23, 2018

Re: [Pharo-dev] Esteban's ChangeLog week of 16 April 2018

by Alexandre Bergel

Thanks Esteban. I really appreciate your log. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 23, 2018, at 3:00 AM, estebanlm(a)gmail.com wrote: > > Hello! > > This is my weekly ChangeLog, from 16 April 2018 to 22 April 2018. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=16/4/2018&to=22/4/2018 > > ChangeLog > ========= > > 16 April 2018: > -------------- > > * I finally updated Alien package into Pharo according to Torsten package modifications. > > This was [case: 20878](https://pharo.fogbugz.com/f/cases/20878) > > And PR can be seen here: [https://github.com/pharo-project/pharo/pull/1202](https://github.com/pharo-… > > > cheers! > Esteban >

April 23, 2018

[Pharo 7.0-dev] Build #800: 20020-Collectionaverage-throw-a-ZeroDivide-when-the-collection-is-empty

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

There is a new Pharo build available! The status of the build #800 was: SUCCESS. The Pull Request #1230 was integrated: "20020-Collectionaverage-throw-a-ZeroDivide-when-the-collection-is-empty" Pull request url: https://github.com/pharo-project/pharo/pull/1230 Issue Url: https://pharo.fogbugz.com/f/cases/20020 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 23, 2018

[Pharo 7.0-dev] Build #799: 21597 Deprecate initialColorInSystemWindow: as it has no sender

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

There is a new Pharo build available! The status of the build #799 was: SUCCESS. The Pull Request #1123 was integrated: "21597 Deprecate initialColorInSystemWindow: as it has no sender" Pull request url: https://github.com/pharo-project/pharo/pull/1123 Issue Url: https://pharo.fogbugz.com/f/cases/21597 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 23, 2018