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

Re: [Pharo-dev] Changes proposal on Pre debugger

by Norbert Hartl

Thatâs definetely worth a try Norbert > Am 10.07.2019 um 20:21 schrieb Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > > Hi, > > After talking with Steven (in copy) we agreed on possible improvements > around the pre debugger. I would like to share our vision and check if > the community agrees. > > Context: > > The pre debugger is the window opening when an exception is signalled > and not catched. This window currently has two views: > - On warnings it display a text explaining the encountered problem. You > can the proceed, abandon or debug. For example, this happens on > Deprecations. > - On other exceptions it display a short stack of the context in which > the error was raised. You can abandon, open a full debugger, ... > > Before, both views were managed via the same UI class. Yesterday I > slitted this class. > > Proposed change: > > In our opinion, the pre debugger displaying a stack is useless. All the > options it proposes are in the full debugger within one click reach. The > only value we see for the pre debugger is about warnings. > > Thus, we propose to remove the stack pre debugger and display directly > the full debugger for anything else than a warning. This will save > everyone one click each time we want to debug something. We would keep > the textual view for warnings. > > In case we do this, I wonder if we should keep the setting "Open full > debugger". I think most users of this option are using it in order to > not see the stack pre debugger and not to skip warnings. So, do someone > have an opinion about keeping or removing this setting in case we remove > the stack pre debugger? > > Possible future changes: > > In the future I would also like it if the opening of the pre (or full) > debugger would be delegated to the raised exception in order to allow > the introduction of different pre debuggers. But it's just an idea and > not the scope of this mail. :) > > -- > Cyril Ferlicot > https://ferlicot.fr >

July 10, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by ducasse

Go go go! Stef > On 10 Jul 2019, at 20:21, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > After talking with Steven (in copy) we agreed on possible improvements > around the pre debugger. I would like to share our vision and check if > the community agrees. > > Context: > > The pre debugger is the window opening when an exception is signalled > and not catched. This window currently has two views: > - On warnings it display a text explaining the encountered problem. You > can the proceed, abandon or debug. For example, this happens on > Deprecations. > - On other exceptions it display a short stack of the context in which > the error was raised. You can abandon, open a full debugger, ... > > Before, both views were managed via the same UI class. Yesterday I > slitted this class. > > Proposed change: > > In our opinion, the pre debugger displaying a stack is useless. All the > options it proposes are in the full debugger within one click reach. The > only value we see for the pre debugger is about warnings. > > Thus, we propose to remove the stack pre debugger and display directly > the full debugger for anything else than a warning. This will save > everyone one click each time we want to debug something. We would keep > the textual view for warnings. > > In case we do this, I wonder if we should keep the setting "Open full > debugger". I think most users of this option are using it in order to > not see the stack pre debugger and not to skip warnings. So, do someone > have an opinion about keeping or removing this setting in case we remove > the stack pre debugger? > > Possible future changes: > > In the future I would also like it if the opening of the pre (or full) > debugger would be delegated to the raised exception in order to allow > the introduction of different pre debuggers. But it's just an idea and > not the scope of this mail. :) > > -- > Cyril Ferlicot > https://ferlicot.fr >

July 10, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Max Leske

On 10 Jul 2019, at 20:21, Cyril Ferlicot D. wrote: > Hi, > > After talking with Steven (in copy) we agreed on possible improvements > around the pre debugger. I would like to share our vision and check if > the community agrees. The community agrees! ;) > > Context: > > The pre debugger is the window opening when an exception is signalled > and not catched. This window currently has two views: > - On warnings it display a text explaining the encountered problem. > You > can the proceed, abandon or debug. For example, this happens on > Deprecations. > - On other exceptions it display a short stack of the context in which > the error was raised. You can abandon, open a full debugger, ... > > Before, both views were managed via the same UI class. Yesterday I > slitted this class. > > Proposed change: > > In our opinion, the pre debugger displaying a stack is useless. All > the > options it proposes are in the full debugger within one click reach. > The > only value we see for the pre debugger is about warnings. > > Thus, we propose to remove the stack pre debugger and display directly > the full debugger for anything else than a warning. This will save > everyone one click each time we want to debug something. We would keep > the textual view for warnings. Yes please. > > In case we do this, I wonder if we should keep the setting "Open full > debugger". I think most users of this option are using it in order to > not see the stack pre debugger and not to skip warnings. So, do > someone > have an opinion about keeping or removing this setting in case we > remove > the stack pre debugger? I agree, remove the setting. > > Possible future changes: > > In the future I would also like it if the opening of the pre (or full) > debugger would be delegated to the raised exception in order to allow > the introduction of different pre debuggers. But it's just an idea and > not the scope of this mail. :) Maybe not to the exception itself but to an optional handler than can be installed in the exception? Cheers, Max > > -- > Cyril Ferlicot > https://ferlicot.fr

July 10, 2019

Changes proposal on Pre debugger

by Cyril Ferlicot D.

Hi, After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees. Context: The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ... Before, both views were managed via the same UI class. Yesterday I slitted this class. Proposed change: In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings. Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings. In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger? Possible future changes: In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :) -- Cyril Ferlicot https://ferlicot.fr

July 10, 2019

[Pharo 8.0] Build #464: 3857-Remove-some-deprecations-from-Spec-1-to-make-image-more-usuable

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

There is a new Pharo build available! The status of the build #464 was: SUCCESS. The Pull Request #3858 was integrated: "3857-Remove-some-deprecations-from-Spec-1-to-make-image-more-usuable" Pull request url: https://github.com/pharo-project/pharo/pull/3858 Issue Url: https://github.com/pharo-project/pharo/issues/3857 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 10, 2019

[Pharo 8.0] Build #463: 3855-Improve-Athens-demos

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

There is a new Pharo build available! The status of the build #463 was: FAILURE. The Pull Request #3856 was integrated: "3855-Improve-Athens-demos" Pull request url: https://github.com/pharo-project/pharo/pull/3856 Issue Url: https://github.com/pharo-project/pharo/issues/3855 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 10, 2019

Re: [Pharo-dev] Read-only image mode

by Pavel Krivanek

Hi Stef, you may download the built image from CI to see the code in the live image https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… -- Pavel Ãºt 9. 7. 2019 v 23:13 odesÃlatel Pavel Krivanek <pavel.krivanek(a)gmail.com> napsal: > Hi Stef, > > Ãºt 9. 7. 2019 v 21:30 odesÃlatel ducasse <stepharo(a)netcourrier.com> > napsal: > >> Pavel >> >> I looked at your PR and I have some questions: >> - could the fileReference have a class/instance var pointing to the store >> instead of having yet another >> global access to a singleton like class :) >> > > FileReference has inst. var pointing to a FileSystem that points to a > Store. There is no global access from this perspective. > Of course, I tried to avoid making new globals as much as possible. The > only exception if usage in File class because > it has very low level API that does not work with file references > > >> - I was wondering why you have macStore and unixStore and â¦ >> I imagine to capture the difference but then why there is duplicated code >> e.g. file: path uid: uidInteger gid: gidInteger looks the same >> > > The ideal solution here would be the Trait usage for read-only API but in > Kernel it is not possible to use it. The current implementation > uses different strategies for every platform. For every one of them, I > added a subclass for read-only strategy. They have the same > content (which is unfortunate implementation detail) but the strategy > design here is definitely the way to go. > > >> >> I hope that the class comment explains it :) >> > > :-) I will improve it > > >> >> - Why do you have a class var for each store? and not one single >> metaclass inst var in the superclass? >> > > There are no class variables of Store classes. What do you mean, exactly? > > -- Pavel > > >> >> Stef >> >> >> On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> Hi, >> >> the current Pharo cannot deal very well in situations when you want to >> run multiple instances from one image file, especially on Windows, which >> complicates the setup of parallel applications. It is not able to work >> reasonably on read-only file-systems too. That's why I did the next attempt >> to improve this functionality of the system. >> >> In summary: >> - the image can be executed with --readOnlyMode image argument >> - the basic system tries to survive such limitation. The changes file is >> in read-only mode and new sources are installed into compiled methods >> directly, Ombu does not save content, Playground does not save cache etc. >> - PharoDebug.log and placeholder files on Windows are not created >> - the limitation is only on image-level so it is easy to bypass it. >> - the presence of the old file streams makes everything uglier and messier >> >> We have an open PR for this issue: >> https://github.com/pharo-project/pharo/pull/3837 >> >> Comments and reviews are welcome. >> >> -- Pavel >> >> >>

July 9, 2019

Re: [Pharo-dev] Read-only image mode

by Pavel Krivanek

Hi Stef, Ãºt 9. 7. 2019 v 21:30 odesÃlatel ducasse <stepharo(a)netcourrier.com> napsal: > Pavel > > I looked at your PR and I have some questions: > - could the fileReference have a class/instance var pointing to the store > instead of having yet another > global access to a singleton like class :) > FileReference has inst. var pointing to a FileSystem that points to a Store. There is no global access from this perspective. Of course, I tried to avoid making new globals as much as possible. The only exception if usage in File class because it has very low level API that does not work with file references > - I was wondering why you have macStore and unixStore and â¦ > I imagine to capture the difference but then why there is duplicated code > e.g. file: path uid: uidInteger gid: gidInteger looks the same > The ideal solution here would be the Trait usage for read-only API but in Kernel it is not possible to use it. The current implementation uses different strategies for every platform. For every one of them, I added a subclass for read-only strategy. They have the same content (which is unfortunate implementation detail) but the strategy design here is definitely the way to go. > > I hope that the class comment explains it :) > :-) I will improve it > > - Why do you have a class var for each store? and not one single metaclass > inst var in the superclass? > There are no class variables of Store classes. What do you mean, exactly? -- Pavel > > Stef > > > On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > the current Pharo cannot deal very well in situations when you want to run > multiple instances from one image file, especially on Windows, which > complicates the setup of parallel applications. It is not able to work > reasonably on read-only file-systems too. That's why I did the next attempt > to improve this functionality of the system. > > In summary: > - the image can be executed with --readOnlyMode image argument > - the basic system tries to survive such limitation. The changes file is > in read-only mode and new sources are installed into compiled methods > directly, Ombu does not save content, Playground does not save cache etc. > - PharoDebug.log and placeholder files on Windows are not created > - the limitation is only on image-level so it is easy to bypass it. > - the presence of the old file streams makes everything uglier and messier > > We have an open PR for this issue: > https://github.com/pharo-project/pharo/pull/3837 > > Comments and reviews are welcome. > > -- Pavel > > >

July 9, 2019

[Pharo 8.0] Build #462: 3841-Rewrite-GT-pre-debugger

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

There is a new Pharo build available! The status of the build #462 was: SUCCESS. The Pull Request #3842 was integrated: "3841-Rewrite-GT-pre-debugger" Pull request url: https://github.com/pharo-project/pharo/pull/3842 Issue Url: https://github.com/pharo-project/pharo/issues/3841 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 9, 2019

Re: [Pharo-dev] Read-only image mode

by ducasse

Pavel I looked at your PR and I have some questions: - could the fileReference have a class/instance var pointing to the store instead of having yet another global access to a singleton like class :) - I was wondering why you have macStore and unixStore and â¦ I imagine to capture the difference but then why there is duplicated code e.g. file: path uid: uidInteger gid: gidInteger looks the same I hope that the class comment explains it :) - Why do you have a class var for each store? and not one single metaclass inst var in the superclass? Stef > On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications. It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system. > > In summary: > - the image can be executed with --readOnlyMode image argument > - the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc. > - PharoDebug.log and placeholder files on Windows are not created > - the limitation is only on image-level so it is easy to bypass it. > - the presence of the old file streams makes everything uglier and messier > > We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837 <https://github.com/pharo-project/pharo/pull/3837> > > Comments and reviews are welcome. > > -- Pavel >

July 9, 2019