- Pharo-dev - lists.pharo.org

strange bug , close a morph window => close the image

by ClÃ©ment Dutriez

Hello, When I want to close a morph window it's close the image. Sometimes this bug appears on Pharo 8 and pharo 7 , I'm working on Linux , I don't succeed to reproduce it. Do some of you already meet this bug? -- Dutriez ClÃ©ment

Aug. 4, 2020

Re: [Pharo-dev] Halos Broken - P9 Headless

by tesonep＠gmail.com

Cool, I will check it out. It seams like a problem with SDL event conversion in the images. As they are appearing with the click on the middle button but not with the combination Cmd + LeftClick On Tue, Aug 4, 2020 at 5:21 AM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote > > Morphic halos don't seem to be working with the Pharo 9 headless VM. They > > seem fine with headful. > > Still a bug as of Build information: > Pharo-9.0.0+build.572.sha.308d3ba56ee06f02c3d3f916da5636d04ceca15b (64 Bit) > > https://github.com/pharo-project/opensmalltalk-vm/issues/100 > > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 4, 2020

Re: [Pharo-dev] Halos Broken - P9 Headless

by Sean P. DeNigris

Sean P. DeNigris wrote > Morphic halos don't seem to be working with the Pharo 9 headless VM. They > seem fine with headful. Still a bug as of Build information: Pharo-9.0.0+build.572.sha.308d3ba56ee06f02c3d3f916da5636d04ceca15b (64 Bit) https://github.com/pharo-project/opensmalltalk-vm/issues/100 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 4, 2020

Re: [Pharo-dev] Robust Functionality vs. Minimalism (was "Microdown ?")

by Tim Mackinnon

Nice answer Norbert - I agree with the sentiment. On Mon, 3 Aug 2020, at 9:01 AM, Norbert Hartl wrote: > Sean, > > > Am 01.08.2020 um 20:23 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > > > I wonder whether/how-best to apply our principle of minimalism when it > > applies to areas of the system that, while critical, seem inherently > > non-minimalist e.g. test harnesses, documentation, etc. > > > > I thought a lot about this when trying to document and refactor SDL. The > > lack > > of a mock library in core was a big barrier to understanding the > > interactions between SDL objects. Maybe I'm being naive, but I feel like if > > someone wants a minimal image, they're not going to want to load SUnit or > > rich text documentation *at all*, so I don't see the risk-benefit of > > crippling these features. > > > > This also applies to Pillar/Microdown. While *any* rich text comments are an > > exciting development, I'd like to understand the benefit of Microdown vs. > > full Pillar syntax. > > Presumably the primary benefit is the size of the codebase. Any other > > reasons? > > A few other questions about the "rich text doc" roadmap: > > 1. Could/will this be extended to method comments? That would be really cool > > :) > > 2. How close are we for someone to use full Pillar syntax in class comments > > in their own library? Any plans to make this possible? > > NB. I originally posted a version of this on an older thread about Pillar > > but and I'm assuming it may have gotten lost in that limited context. > > > The discussion about markup is a long one we keep doing for years. I > personally don't like the pillar syntax too much and I don't see a big > reason to keep it. On the other hand markdown is the de facto standard > of simple formatting things. It is true that it is hard to parse > because the syntax is not well thought.The point being positive about > markdown is that it reads well in raw/ascii form and can be parsed into > a document model to enable rich text variants like HTML, PDF, etc. > And it plays well with the minimalist approach. Because markdown is > readable in its raw form it can be used without all of the rich text > rendering code loaded. So the goal is to have a pleasant approach to > documentation for your big development image. You can make a small > image where you can still read the class documentation in its raw form. > In a minimalist image you might even strip down class comments to save > space, so it's not an issue here. These three levels are the ones I see. > > For the markdown in method comments. This is something I think about > since a while. There is still something like the first comment as > separation to the rest. For doing a whole class documentation this > could be a low hanging fruit as a convention to start. You can use > microdown in method comments, too. And that's (again) because it reads > well in raw format. After that we have to learn. Especially to > understand that the AST and a document model are just two different > form of trees that express something about the method. If we find a > good way to interleave those trees and can have a rich text component > that is rendered nicely with the code it encloses we are a big step > nearer to explained code which reversed means executable documentation. > > Norbert > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > >

Aug. 3, 2020

Re: [Pharo-dev] Robust Functionality vs. Minimalism (was "Microdown ?")

by Norbert Hartl

Sean, > Am 01.08.2020 um 20:23 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > I wonder whether/how-best to apply our principle of minimalism when it > applies to areas of the system that, while critical, seem inherently > non-minimalist e.g. test harnesses, documentation, etc. > > I thought a lot about this when trying to document and refactor SDL. The > lack > of a mock library in core was a big barrier to understanding the > interactions between SDL objects. Maybe I'm being naive, but I feel like if > someone wants a minimal image, they're not going to want to load SUnit or > rich text documentation *at all*, so I don't see the risk-benefit of > crippling these features. > > This also applies to Pillar/Microdown. While *any* rich text comments are an > exciting development, I'd like to understand the benefit of Microdown vs. > full Pillar syntax. > Presumably the primary benefit is the size of the codebase. Any other > reasons? > A few other questions about the "rich text doc" roadmap: > 1. Could/will this be extended to method comments? That would be really cool > :) > 2. How close are we for someone to use full Pillar syntax in class comments > in their own library? Any plans to make this possible? > NB. I originally posted a version of this on an older thread about Pillar > but and I'm assuming it may have gotten lost in that limited context. > The discussion about markup is a long one we keep doing for years. I personally don't like the pillar syntax too much and I don't see a big reason to keep it. On the other hand markdown is the de facto standard of simple formatting things. It is true that it is hard to parse because the syntax is not well thought.The point being positive about markdown is that it reads well in raw/ascii form and can be parsed into a document model to enable rich text variants like HTML, PDF, etc. And it plays well with the minimalist approach. Because markdown is readable in its raw form it can be used without all of the rich text rendering code loaded. So the goal is to have a pleasant approach to documentation for your big development image. You can make a small image where you can still read the class documentation in its raw form. In a minimalist image you might even strip down class comments to save space, so it's not an issue here. These three levels are the ones I see. For the markdown in method comments. This is something I think about since a while. There is still something like the first comment as separation to the rest. For doing a whole class documentation this could be a low hanging fruit as a convention to start. You can use microdown in method comments, too. And that's (again) because it reads well in raw format. After that we have to learn. Especially to understand that the AST and a document model are just two different form of trees that express something about the method. If we find a good way to interleave those trees and can have a rich text component that is rendered nicely with the code it encloses we are a big step nearer to explained code which reversed means executable documentation. Norbert > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 3, 2020

Robust Functionality vs. Minimalism (was "Microdown ?")

by Sean P. DeNigris

I wonder whether/how-best to apply our principle of minimalism when it applies to areas of the system that, while critical, seem inherently non-minimalist e.g. test harnesses, documentation, etc. I thought a lot about this when trying to document and refactor SDL. The lack of a mock library in core was a big barrier to understanding the interactions between SDL objects. Maybe I'm being naive, but I feel like if someone wants a minimal image, they're not going to want to load SUnit or rich text documentation *at all*, so I don't see the risk-benefit of crippling these features. This also applies to Pillar/Microdown. While *any* rich text comments are an exciting development, I'd like to understand the benefit of Microdown vs. full Pillar syntax. Presumably the primary benefit is the size of the codebase. Any other reasons? A few other questions about the "rich text doc" roadmap: 1. Could/will this be extended to method comments? That would be really cool :) 2. How close are we for someone to use full Pillar syntax in class comments in their own library? Any plans to make this possible? NB. I originally posted a version of this on an older thread about Pillar but and I'm assuming it may have gotten lost in that limited context. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 1, 2020

[Pharo 9.0] Build #572: Playground-Color-defined-Variables

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

There is a new Pharo build available! The status of the build #572 was: FAILURE. The Pull Request #7021 was integrated: "Playground-Color-defined-Variables" Pull request url: https://github.com/pharo-project/pharo/pull/7021 Issue Url: https://github.com/pharo-project/pharo/issues/Playground Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2020

[Pharo 9.0] Build #571: Compiler-donot-hardcode-ReservedVariables

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

There is a new Pharo build available! The status of the build #571 was: SUCCESS. The Pull Request #7030 was integrated: "Compiler-donot-hardcode-ReservedVariables" Pull request url: https://github.com/pharo-project/pharo/pull/7030 Issue Url: https://github.com/pharo-project/pharo/issues/Compiler Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 1, 2020

[Pharo 9.0] Build #570: 6952 debugger line location is uncorrect when using a breakonce

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

There is a new Pharo build available! The status of the build #570 was: FAILURE. The Pull Request #7026 was integrated: "6952 debugger line location is uncorrect when using a breakonce" Pull request url: https://github.com/pharo-project/pharo/pull/7026 Issue Url: https://github.com/pharo-project/pharo/issues/6952 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 31, 2020

[Pharo 9.0] Build #569: ReservedVariable-nameIsReserved-and-Test

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

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

July 31, 2020