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

Re: [Pharo-dev] MDLApplication

by Cyril Ferlicot

On Thu, Nov 28, 2019 at 11:26 AM Julien Delplanque <julien.delplanque(a)inria.fr> wrote: > > Hello Sven, > > Did you try https://github.com/jecisc/MDBaseGenerator ? > To help with discoverability, I migrated the project from my repository to DuneSt. The previous link should still work with Github redirections. > It generates a nice template for starting a new MDL webapp. > > I do not know about MDLApplication. > > Cheers, > > Julien > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 28, 2019

Re: [Pharo-dev] MDLApplication

by Sven Van Caekenberghe

> On 28 Nov 2019, at 11:55, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Thu, Nov 28, 2019 at 11:17 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. >> >> Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. >> >> Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? >> >> MDLScreen is in fact an empty class. >> >> Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. >> > > Hi, > > This class was introduced at the beginning of MDL and was used by its creator. > > This person does not contribute anymore and I never really used it so > I do not know how useful it is. I will add an issue to take a look and > either improve it or deprecate it to not make people lose time. Thanks Cyril, I suspect it was not finished and it was a bit confusing. > https://github.com/DuneSt/MaterialDesignLite/issues/292 > > As Julien told you, I usually start a standard MDL application with > the generator I wrote to get the basic infrastructure. > > I hope it helps you getting started smoothly. > >> Sven > > -- > Cyril Ferlicot > https://ferlicot.fr

Nov. 28, 2019

Re: [Pharo-dev] MDLApplication

by Cyril Ferlicot

On Thu, Nov 28, 2019 at 11:17 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. > > Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. > > Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? > > MDLScreen is in fact an empty class. > > Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. > Hi, This class was introduced at the beginning of MDL and was used by its creator. This person does not contribute anymore and I never really used it so I do not know how useful it is. I will add an issue to take a look and either improve it or deprecate it to not make people lose time. https://github.com/DuneSt/MaterialDesignLite/issues/292 As Julien told you, I usually start a standard MDL application with the generator I wrote to get the basic infrastructure. I hope it helps you getting started smoothly. > Sven -- Cyril Ferlicot https://ferlicot.fr

Nov. 28, 2019

Re: [Pharo-dev] MDLApplication

by Sven Van Caekenberghe

> On 28 Nov 2019, at 11:26, Julien Delplanque <julien.delplanque(a)inria.fr> wrote: > > Hello Sven, > > Did you try https://github.com/jecisc/MDBaseGenerator ? > > It generates a nice template for starting a new MDL webapp. OK that works fine, thanks ! > I do not know about MDLApplication. It is in the package Material-Design-Lite-Core, which seems to suggest it is an important class > Cheers, > > Julien > > Le 28/11/19 Ã 11:16, Sven Van Caekenberghe a Ã©crit : >> Hi, >> >> I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. >> >> Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. >> >> Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? >> >> MDLScreen is in fact an empty class. >> >> Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. >> >> Sven >

Nov. 28, 2019

Re: [Pharo-dev] [Mm10s] 2019-11-25

by Steven Costiou

### Last week: - halt/breakpoint manager in the spec debugger: see all halt/breakpoints and (de)activate them in one click. When deactivated, a halt/breakpoint just prints a log message in the Transcript. - Pharo IOT book writing ### This week (starting 2019-11-25): - Pharo IOT book writing - add a "watch variable" window in the debugger to track variables during debugging ### Pipeline - Pharo IOT book - Enhancing the spec debugger: better breakpoint support, adding missing features (menus, options), fixing bugs - Integrating object-centric debugging in the spec2 tools - Writing a chapter/documentation about the Pharo debugger

Nov. 28, 2019

Re: [Pharo-dev] MDLApplication

by Julien Delplanque

Hello Sven, Did you try https://github.com/jecisc/MDBaseGenerator ? It generates a nice template for starting a new MDL webapp. I do not know about MDLApplication. Cheers, Julien Le 28/11/19 Ã 11:16, Sven Van Caekenberghe a Ã©critÂ : > Hi, > > I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. > > Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. > > Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? > > MDLScreen is in fact an empty class. > > Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. > > Sven

Nov. 28, 2019

MDLApplication

by Sven Van Caekenberghe

Hi, I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? MDLScreen is in fact an empty class. Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. Sven

Nov. 28, 2019

Re: [Pharo-dev] BlueInk removal

by Sven Van Caekenberghe

This is all true, BUT ... Very few people attempt to do fundamental changes/cleanups/subsystem-replacements in the core image. This takes a lot of work, is never easy and almost always has issues. Resources are limited as well, in theory things can be done better, in practice in the real world, not so much. The alternative is to never touch anything and stay stagnant. > On 28 Nov 2019, at 10:03, Torsten Bergmann <astares(a)gmx.de> wrote: > > To me it certainly looks like a <before we freeze Pharo 8 we have to speed up with features> to get things in > by all means. Have to admit I had this kind of "panic mode" myself several times in the past too ;) > > Stef writes he now does not have the time nor energy - which I guess (including his reactions) is a tribute to his workload. > But then it would have been better to change to new Elumineire or getting rid of GTEventRecorder in Pharo 9 and now just marking > them for later exclusion. Because often we all underestimate the depencies, side effects, migration costs - even the reactions. > > Meanwhile Pharo is not only the base image - it is the full ecosystem around it which is good and a positive sign and > something we IMHO need to respect more and more. > > One has to understand that by just removing and not using deprecation the situation is getting worse and now pulling > more time and energy from other parts of the community too. Because broken stuff like Spotter, Settings, Roassal, Moose, ... > would need repair > - either directly (to help contributors who use them in P8 alpha already to give quick feedback) > - together with the Pharo 8 release so they can be used > - after Pharo 8 is released (which would be very late and might include migration surprises) > > Depreaction would help us better managing such transitions and is something that is standard in other languages too. > > The alternative would be to say this is OPP (other peoples problem) and completely ignoring that projects are built on top > of Pharo base. We all know removing leads to being incompatible and is not helpful in offering a transition path - therefore not > a good option. Because then users would always need to start from scratch with each Pharo release and loose interest quickly. > > Users want to do both: use Pharo and move their projects without having to focus on changed infrastructure > too often. Deprecation would give more room to fixing it- we have theses mechanisms like deprecations and we should really use them. > > In the past we were able to move more freely - but now we should really accept that with more users we have to > follow certain backwards compatibility and more clear rules. This slows us down yes and requires more time > and energy. But it is still a good thing because Pharo is actually used and the community can grow. > > We can not move Pharo into the "perfect" future with a crowbar as this would mean to loose users and especially > trust into the system. We might then still come up with an improved (but still imperfect) system in a few years - > but nobody would be interested anymore. If we fail to see things from the POV of the user then we will fail overall and loose them. > > I agree with Benoit that especially business users first have to solve the customers problems before they > can juggle with migrations. So lets support the overall community and not being ignorant to it. > So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 is working because things over the last > releases stabilized and also because we added more rules, depreactions, transformations and helping users. > > I personally would prefer to see that "Pharo is not perfect but strong and widely used" than "look how cool it could have been", > so lets not get too impatient. Step by step - sometimes faster sometimes slower... > > Thanks > T. >

Nov. 28, 2019

Re: [Pharo-dev] BlueInk removal

by Torsten Bergmann

To me it certainly looks like a <before we freeze Pharo 8 we have to speed up with features> to get things in by all means. Have to admit I had this kind of "panic mode" myself several times in the past too ;) Stef writes he now does not have the time nor energy - which I guess (including his reactions) is a tribute to his workload. But then it would have been better to change to new Elumineire or getting rid of GTEventRecorder in Pharo 9 and now just marking them for later exclusion. Because often we all underestimate the depencies, side effects, migration costs - even the reactions. Meanwhile Pharo is not only the base image - it is the full ecosystem around it which is good and a positive sign and something we IMHO need to respect more and more. One has to understand that by just removing and not using deprecation the situation is getting worse and now pulling more time and energy from other parts of the community too. Because broken stuff like Spotter, Settings, Roassal, Moose, ... would need repair - either directly (to help contributors who use them in P8 alpha already to give quick feedback) - together with the Pharo 8 release so they can be used - after Pharo 8 is released (which would be very late and might include migration surprises) Depreaction would help us better managing such transitions and is something that is standard in other languages too. The alternative would be to say this is OPP (other peoples problem) and completely ignoring that projects are built on top of Pharo base. We all know removing leads to being incompatible and is not helpful in offering a transition path - therefore not a good option. Because then users would always need to start from scratch with each Pharo release and loose interest quickly. Users want to do both: use Pharo and move their projects without having to focus on changed infrastructure too often. Deprecation would give more room to fixing it- we have theses mechanisms like deprecations and we should really use them. In the past we were able to move more freely - but now we should really accept that with more users we have to follow certain backwards compatibility and more clear rules. This slows us down yes and requires more time and energy. But it is still a good thing because Pharo is actually used and the community can grow. We can not move Pharo into the "perfect" future with a crowbar as this would mean to loose users and especially trust into the system. We might then still come up with an improved (but still imperfect) system in a few years - but nobody would be interested anymore. If we fail to see things from the POV of the user then we will fail overall and loose them. I agree with Benoit that especially business users first have to solve the customers problems before they can juggle with migrations. So lets support the overall community and not being ignorant to it. So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 is working because things over the last releases stabilized and also because we added more rules, depreactions, transformations and helping users. I personally would prefer to see that "Pharo is not perfect but strong and widely used" than "look how cool it could have been", so lets not get too impatient. Step by step - sometimes faster sometimes slower... Thanks T.

Nov. 28, 2019

[Pharo 8.0] Build #1022: In bootstrap: Preparing heap before writing the image to shrink its size

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

There is a new Pharo build available! The status of the build #1022 was: SUCCESS. The Pull Request #5255 was integrated: "In bootstrap: Preparing heap before writing the image to shrink its size" Pull request url: https://github.com/pharo-project/pharo/pull/5255 Issue Url: https://github.com/pharo-project/pharo/issues/Pharo8.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 28, 2019