- Pharo-dev - lists.pharo.org

Fuel fails in squeak

by henry

I loaded the latest Fuel from squeak source and it fails when materializing a Character from a FixedObjectCluster. Character class does not support basicNew. Helpful>?? - HH

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Stephane Ducasse

Hi guille thanks for raising this point. I will wait a bit that other people comment on it since it is a crucial point. Stef On Mon, Aug 14, 2017 at 4:47 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Iâm definitely in favour of doing something (as I found it confusing, and > in a way also found it has the potential to leak what could be sensitive > information through command line contexts that are still lurking in the > image with details about previous directory structures and commands). > > I will try and and see how it impacts PharoLambda as a test example. > > Tim > > On 14 Aug 2017, at 11:42, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi all, > > I'm proposing a kind-of critical change that I believe is very good for > the health of the system: I want that the startup of the system runs in > maximum priority and becomes non-interruptable. > > Right now, when you save your image, the shutdown and startup are run in > the same priority than the process that triggered the save (usually the ui > or the command line, priority 40). This can cause lots of problems and race > conditions: processes with higher priorities can interrupt the > shutdown/startup and try to do something while the system is unstable. As a > side effect also, when you use extensively the command line, you start > stacking startup contexts from old sessions: > > ... > session 3 ctxt 4 <- This guy makes a save and a new session starts > session 3 ctxt 3 > session 3 ctxt 2 > session 3 ctxt 1 > session 2 ctxt 4 <- This guy makes a save and a new session starts > session 2 ctxt 3 > session 2 ctxt 2 > session 2 ctxt 1 > session 1 ctxt 4 <- This guy makes a save and a new session starts > session 1 ctxt 3 > session 1 ctxt 2 > session 1 ctxt 1 > > Old contexts are never collected, and the objects they referenced neither. > > To fix these two problems I propose to do every image save/session start > in a new process in maximum priority. That way, other process should not be > able to interrupt the startup process. Moreover, every session > shutdown/startup should happen in a new clean process, to avoid the session > stacking. > > For normal users, this should have no side effect at all. This change will > have a good impact on people working on the debugger and the stack such as > fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions > should be quick to run. If a startup action requires to run a long-running > action such as starting a server or managing a command line action, that > should run in a separate process with lower priority (usually > userPriority). In other words, the startup action should create a new > process managing its action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 > Current validation going on: https://ci.inria.fr/pharo-ci- > jenkins2/job/Test%20pending%20pull%20request%20and% > 20branch%20Pipeline/view/change-requests/job/PR-198/ > > Guille > > -- > > Guille Polito > > Research Engineer > 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 <+33%206%2052%2070%2066%2013> > > >

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Stephane Ducasse

We can change the syntax or propose an alternate one as soon as it uses the same internal structure. Stef On Mon, Aug 14, 2017 at 6:34 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling > the syntax is an interesting one that I hadnât thought about. > > Personally, I find having too many similar syntaxâs confusing - contributing > to things is hard enough - having to remember that its !! Instead of ## and > ââ instead of ** is just frustrating for me. > > My vote would be what Peter suggested - use http://spec.commonmark.org/0.28/ > and put our Pillar extensions back on top for things that Stef was > mentioning. (I think thatâs what Iâve understood gfm markdown is). > > Sure, maybe we were first with Pillar, but for me, lots of programming is in > other languages, and I use Smalltalk where I can, and a hybrid of multiple > languages and projects is often the reality - so a lowest common denominator > of Markdown is just easier. The fact that we are quite close to what our > colleagues in other languages use (regardless of what Python has chosen), is > quite interesting. > > That said, if the community wants to stick to its gunâs thats fine - I will > probably still investigate how to use Commonmark for myself, and will still > contribute to Pillar docs where I can (and curse history) - but I think we > are long better off trying to join emerging standards where we can > particularly if they arenât our core language thing. And it just makes it > less frictionless for ourselves and newcomers. > > Of course, if we were to move, we would need to translate a lot of quality > docs to a new format - but I would be up for contributing to that if that > was a deciding factor. > > Tim > > > On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > TL;DR > > Main points: > Their is no universally accepted markup language. > Other communities use their own markup and tools and their markup and tools > choice is not determine by other communities decisions. > We need a language and tool chain that we can control and maintain which > accomplishes our goals. > Our language and tools already exist and have existed for longer than most > of the other markup languages. Of course they existed in various different > forms over the years and have evolved into what they currently are. > It might be nice to have a GFM Markdown exporter from Pillar for GitHub > projects. > > > I just want to comment on the fact that there is no universal markup > language that every development community has settled upon. Making Markdown > or some variant the markup language for Pharo only aligns us with a certain > part of the development community. Even Markdown is not unified as is > evident by the discussion. > > It is true that GitHub uses their variant of Markdown. And as long as we use > GitHub we will need to use their variant for documents that reside on their > system. > > However as a significant counter example to lets all use gfm Markdown, is > the Python community and their documentation. > > https://docs.python.org/devguide/documenting.html > """ > 7. Documenting Python > The Python language has a substantial body of documentation, much of it > contributed by various authors. The markup used for the Python documentation > is reStructuredText, developed by the docutils project, amended by custom > directives and using a toolset named Sphinx to post-process the HTML output. > > This document describes the style guide for our documentation as well as the > custom reStructuredText markup introduced by Sphinx to support Python > documentation and how it should be used. > > The documentation in HTML, PDF or EPUB format is generated from text files > written using the reStructuredText format and contained in the CPython Git > repository. > """ > > So the Python community uses their own markup language and their own tool > chain. So therefore, it is not wrong for a community to go their own way, > for their own reasons. Even within the conventional file based languages > such as Python. > > The fact that you have tools such as Pandoc, suggest that there is not true > uniformity or unanimity among developers as to the best markup language or > tool chain. > > I believe that a language that we can control and maintain is better than > adopting some other foreign markup language that is neither better, nor > unanimously used by all. That would ultimately potentially require > extensions to accomplish our goals. Then we would be maintaining someone > else's language with our extensions that may or may not be accepted by the > larger community. This does not prevent but rather encourages fragmentation > of the existing Markdown. > > Regardless, Pillar markup already exists. The tools in Pharo already > understand it. Should someone desire to use Pharo which is far more > different from Python/Ruby/etc. than Pillar syntax is from Markdown. Then it > should be worth their effort to learn our tools. > > Pillar markup is older than Markdown, etc. It's history begins in SmallWiki. > It isn't as if we jumped up and decided to create something new in order to > be different. Our markup and tools are older. They (and others) are the ones > that decided to do their own markup and tools. And it is okay that they did > so. Nothing wrong with doing so. Every community has the right to what they > believe is best for their community. Even if other communities disagree. > > The ability to control and maintain is highly valuable. We can understand > what our requirements are for today. But we can not know what the > requirements are in the future. Nor can we know that Markdown or whomever > will have such requirements when they appear. It is easy to see in the > beginning with the Squeak Wiki syntax to the now Pillar syntax, changes that > have been made to accommodate new requirements as they became known. We need > to maintain that ability. Sure we would reserve the right to do so in any > language we adopt. But the then current standard bearer of said language > would determine whether what we do is acceptable and incorporate or whether > we are then in fact adding to their fragmentation. Pillar is ours. There is > not fragmentation when we evolve. > > However, since we have made a decision to use GitHub and GitHub has made a > decision to use their own GFM Markdown. It might be nice to have a GFM > Markdown exporter from Pillar for GitHub projects. This way we can use our > own tools and markup language to accomplish whatever we want to accomplish. > Including generating a Readme.md for our GitHub projects. > > Just wanted to toss out this simple opinion and facts about the situation. > > Jimmie > > > On 08/14/2017 04:10 AM, Tudor Girba wrote: > > Hi Tim, > > The main benefit of relying on Pillar is that we control its syntax and can > easily extend it for our purposes. Also, there was quite a bit of > engineering invested in it, and even though we still need to improve it, > there exists a pipeline that allows people to quickly publish books. > > The figure embedding problem is one example of the need to customize the > syntax and behavior, but this extensibility will become even more important > for supporting the idea of moving the documentation inside the image. For > example, the ability to refer to a class, method or other artifacts will be > quite relevant soon especially that the editor will be able to embed > advanced elements inside the text. > > Cheers, > Doru > > > On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Stef - I think yourâs is a fair requirement (in fact I hit something > similar when doing a static website using a JS markdown framework - and this > is why I mentioned Kramdown which adds a few extras to regular markdown - > but it feels like it goes a bit too far). > > My next item on my learning todo list was to try and replace that JS > generator with something from Smalltalk - so I think we can possibly come up > with something that ticks all the right boxes (Iâd like to try anyway). > > Iâll keep working away on it and compare notes with you. I think with > Pillar, it was more that things like headers, bold and italics are similar > concepts but just use different characters - so I keep typing the wrong > thing and getting frustrated particularly when we embrace Git and readme.md > is in markdown. > > > Tim > > On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi tim > > I personally do not care much about the syntax but I care about what I > can do with it > (ref, cite, ... ) > I cannot write books in markdown because reference to figures!!!!!! > were missing. > > And of course a parser because markdown is not really nice to parse > and I will not write a parser because I have something else to do. I > want to make pillar smaller, simpler, nicer. > > Now if someone come up with a parser that parse for REAL a markdown > that can be extended with decent behavior (figure reference, section > reference, cite) and can be extended because there are many things > that can be nice to have (for example I want to be able to write the > example below) and emit a PillarModel (AST) we can talk to have > another syntax for Pillar but not before. > > [[[test > 2+3 > > 5 > > ]]] > > and being able to verify that the doc is in sync. > > > Stef > > > > On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > Of course, I/we recognise and appreciate all the work that's gone into docs > in pillar - but I think it should be reasonably straightforward to write a > converter as it is pretty closely related from what I have seen. > > So I don't make the suggestion flippantly, and would want to help write a > converter and get us to a common ground where we can differentiate on the > aspects where we can excel. > > Tim > > Sent from my iPhone > > On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > A long time issue with Markdown was that there was no standardization (and > when I used Pillar's MD export ~2 years ago it didn't work well). > > However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the > de-facto standard, so it would make sense to support it bidirectionally with > Pillar. > > The readme.md that Peter is talking about is gfm markdown > > Well, technically it is just a CommonMark, as I am not using any github > extensions. > (Github uses CommonMarks and adds just couple small extensions.) > > Peter > > > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > > > > >

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Esteban A. Maringolo

You hit several birds with one single mail. 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling > the syntax is an interesting one that I hadnât thought about. > > Personally, I find having too many similar syntaxâs confusing - contributing > to things is hard enough - having to remember that its !! Instead of ## and > ââ instead of ** is just frustrating for me. +1 Not only for docs, most platforms like Slack/Discord share the syntax, so now I'm getting "muscle memory" when typing literals using the backtick (`) character, quoting with > or pasting snippets using ``` > Sure, maybe we were first with Pillar, but for me, lots of programming is in > other languages, and I use Smalltalk where I can, and a hybrid of multiple > languages and projects is often the reality - so a lowest common denominator > of Markdown is just easier. The fact that we are quite close to what our > colleagues in other languages use (regardless of what Python has chosen), is > quite interesting. This helps building "bridges" with other communities. The language as a means of exchange is always the lowest common denominator. As long as it's "efficient enough" then I vote to use what other communities use. > That said, if the community wants to stick to its gunâs thats fine - I will > probably still investigate how to use Commonmark for myself, and will still > contribute to Pillar docs where I can (and curse history) - but I think we > are long better off trying to join emerging standards where we can > particularly if they arenât our core language thing. And it just makes it > less frictionless for ourselves and newcomers. The "Not Invented Here" syndrome is strong among Smalltalkers, it's important to be aware of this bias and think more than once whether eating our own dogfood adds value to the core of what Pharo brings. I think we missed some good years fighting with our own SCM and in the end git (or any other file based SCM) prevailed, even when it has limitations. Pareto (80-20) for everything non-core business should be a guide. > Of course, if we were to move, we would need to translate a lot of quality > docs to a new format - but I would be up for contributing to that if that > was a deciding factor. There are some Markdown exporters AFAIK, or it could be written. Esteban A. Maringolo

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Tim Mackinnon

Jimmie et al. nicely reasoned arguments - and Doru's point about controlling the syntax is an interesting one that I hadnât thought about. Personally, I find having too many similar syntaxâs confusing - contributing to things is hard enough - having to remember that its !! Instead of ## and ââ instead of ** is just frustrating for me. My vote would be what Peter suggested - use http://spec.commonmark.org/0.28/ <http://spec.commonmark.org/0.28/> and put our Pillar extensions back on top for things that Stef was mentioning. (I think thatâs what Iâve understood gfm markdown is). Sure, maybe we were first with Pillar, but for me, lots of programming is in other languages, and I use Smalltalk where I can, and a hybrid of multiple languages and projects is often the reality - so a lowest common denominator of Markdown is just easier. The fact that we are quite close to what our colleagues in other languages use (regardless of what Python has chosen), is quite interesting. That said, if the community wants to stick to its gunâs thats fine - I will probably still investigate how to use Commonmark for myself, and will still contribute to Pillar docs where I can (and curse history) - but I think we are long better off trying to join emerging standards where we can particularly if they arenât our core language thing. And it just makes it less frictionless for ourselves and newcomers. Of course, if we were to move, we would need to translate a lot of quality docs to a new format - but I would be up for contributing to that if that was a deciding factor. Tim > On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > TL;DR > > Main points: > Their is no universally accepted markup language. > Other communities use their own markup and tools and their markup and tools choice is not determine by other communities decisions. > We need a language and tool chain that we can control and maintain which accomplishes our goals. > Our language and tools already exist and have existed for longer than most of the other markup languages. Of course they existed in various different forms over the years and have evolved into what they currently are. > It might be nice to have a GFM Markdown exporter from Pillar for GitHub projects. > > > I just want to comment on the fact that there is no universal markup language that every development community has settled upon. Making Markdown or some variant the markup language for Pharo only aligns us with a certain part of the development community. Even Markdown is not unified as is evident by the discussion. > > It is true that GitHub uses their variant of Markdown. And as long as we use GitHub we will need to use their variant for documents that reside on their system. > > However as a significant counter example to lets all use gfm Markdown, is the Python community and their documentation. > > https://docs.python.org/devguide/documenting.html > """ > 7. Documenting Python > The Python language has a substantial body of documentation, much of it contributed by various authors. The markup used for the Python documentation is reStructuredText, developed by the docutils project, amended by custom directives and using a toolset named Sphinx to post-process the HTML output. > > This document describes the style guide for our documentation as well as the custom reStructuredText markup introduced by Sphinx to support Python documentation and how it should be used. > > The documentation in HTML, PDF or EPUB format is generated from text files written using the reStructuredText format and contained in the CPython Git repository. > """ > > So the Python community uses their own markup language and their own tool chain. So therefore, it is not wrong for a community to go their own way, for their own reasons. Even within the conventional file based languages such as Python. > > The fact that you have tools such as Pandoc, suggest that there is not true uniformity or unanimity among developers as to the best markup language or tool chain. > > I believe that a language that we can control and maintain is better than adopting some other foreign markup language that is neither better, nor unanimously used by all. That would ultimately potentially require extensions to accomplish our goals. Then we would be maintaining someone else's language with our extensions that may or may not be accepted by the larger community. This does not prevent but rather encourages fragmentation of the existing Markdown. > > Regardless, Pillar markup already exists. The tools in Pharo already understand it. Should someone desire to use Pharo which is far more different from Python/Ruby/etc. than Pillar syntax is from Markdown. Then it should be worth their effort to learn our tools. > > Pillar markup is older than Markdown, etc. It's history begins in SmallWiki. It isn't as if we jumped up and decided to create something new in order to be different. Our markup and tools are older. They (and others) are the ones that decided to do their own markup and tools. And it is okay that they did so. Nothing wrong with doing so. Every community has the right to what they believe is best for their community. Even if other communities disagree. > > The ability to control and maintain is highly valuable. We can understand what our requirements are for today. But we can not know what the requirements are in the future. Nor can we know that Markdown or whomever will have such requirements when they appear. It is easy to see in the beginning with the Squeak Wiki syntax to the now Pillar syntax, changes that have been made to accommodate new requirements as they became known. We need to maintain that ability. Sure we would reserve the right to do so in any language we adopt. But the then current standard bearer of said language would determine whether what we do is acceptable and incorporate or whether we are then in fact adding to their fragmentation. Pillar is ours. There is not fragmentation when we evolve. > > However, since we have made a decision to use GitHub and GitHub has made a decision to use their own GFM Markdown. It might be nice to have a GFM Markdown exporter from Pillar for GitHub projects. This way we can use our own tools and markup language to accomplish whatever we want to accomplish. Including generating a Readme.md for our GitHub projects. > > Just wanted to toss out this simple opinion and facts about the situation. > > Jimmie > > > On 08/14/2017 04:10 AM, Tudor Girba wrote: >> Hi Tim, >> >> The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. >> >> The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. >> >> Cheers, >> Doru >> >> >>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >>> >>> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >>> >>> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >>> >>> >>> Tim >>> >>>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi tim >>>> >>>> I personally do not care much about the syntax but I care about what I >>>> can do with it >>>> (ref, cite, ... ) >>>> I cannot write books in markdown because reference to figures!!!!!! >>>> were missing. >>>> >>>> And of course a parser because markdown is not really nice to parse >>>> and I will not write a parser because I have something else to do. I >>>> want to make pillar smaller, simpler, nicer. >>>> >>>> Now if someone come up with a parser that parse for REAL a markdown >>>> that can be extended with decent behavior (figure reference, section >>>> reference, cite) and can be extended because there are many things >>>> that can be nice to have (for example I want to be able to write the >>>> example below) and emit a PillarModel (AST) we can talk to have >>>> another syntax for Pillar but not before. >>>> >>>> [[[test >>>> 2+3 >>>>>>> 5 >>>> ]]] >>>> >>>> and being able to verify that the doc is in sync. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>>> >>>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>>> >>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>>> >>>>>>> The readme.md that Peter is talking about is gfm markdown >>>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>>> >>>>>> Peter >>>>>> >>>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âLive like you mean it." >> >> > >

Aug. 14, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Jimmie Houchin

TL;DR Main points: Their is no universally accepted markup language. Other communities use their own markup and tools and their markup and tools choice is not determine by other communities decisions. We need a language and tool chain that we can control and maintain which accomplishes our goals. Our language and tools already exist and have existed for longer than most of the other markup languages. Of course they existed in various different forms over the years and have evolved into what they currently are. It might be nice to have a GFM Markdown exporter from Pillar for GitHub projects. I just want to comment on the fact that there is no universal markup language that every development community has settled upon. Making Markdown or some variant the markup language for Pharo only aligns us with a certain part of the development community. Even Markdown is not unified as is evident by the discussion. It is true that GitHub uses their variant of Markdown. And as long as we use GitHub we will need to use their variant for documents that reside on their system. However as a significant counter example to lets all use gfm Markdown, is the Python community and their documentation. https://docs.python.org/devguide/documenting.html """ 7. Documenting Python The Python language has a substantial body of documentation, much of it contributed by various authors. The markup used for the Python documentation is reStructuredText, developed by the docutils project, amended by custom directives and using a toolset named Sphinx to post-process the HTML output. This document describes the style guide for our documentation as well as the custom reStructuredText markup introduced by Sphinx to support Python documentation and how it should be used. The documentation in HTML, PDF or EPUB format is generated from text files written using the reStructuredText format and contained in the CPython Git repository. """ So the Python community uses their own markup language and their own tool chain. So therefore, it is not wrong for a community to go their own way, for their own reasons. Even within the conventional file based languages such as Python. The fact that you have tools such as Pandoc, suggest that there is not true uniformity or unanimity among developers as to the best markup language or tool chain. I believe that a language that we can control and maintain is better than adopting some other foreign markup language that is neither better, nor unanimously used by all. That would ultimately potentially require extensions to accomplish our goals. Then we would be maintaining someone else's language with our extensions that may or may not be accepted by the larger community. This does not prevent but rather encourages fragmentation of the existing Markdown. Regardless, Pillar markup already exists. The tools in Pharo already understand it. Should someone desire to use Pharo which is far more different from Python/Ruby/etc. than Pillar syntax is from Markdown. Then it should be worth their effort to learn our tools. Pillar markup is older than Markdown, etc. It's history begins in SmallWiki. It isn't as if we jumped up and decided to create something new in order to be different. Our markup and tools are older. They (and others) are the ones that decided to do their own markup and tools. And it is okay that they did so. Nothing wrong with doing so. Every community has the right to what they believe is best for their community. Even if other communities disagree. The ability to control and maintain is highly valuable. We can understand what our requirements are for today. But we can not know what the requirements are in the future. Nor can we know that Markdown or whomever will have such requirements when they appear. It is easy to see in the beginning with the Squeak Wiki syntax to the now Pillar syntax, changes that have been made to accommodate new requirements as they became known. We need to maintain that ability. Sure we would reserve the right to do so in any language we adopt. But the then current standard bearer of said language would determine whether what we do is acceptable and incorporate or whether we are then in fact adding to their fragmentation. Pillar is ours. There is not fragmentation when we evolve. However, since we have made a decision to use GitHub and GitHub has made a decision to use their own GFM Markdown. It might be nice to have a GFM Markdown exporter from Pillar for GitHub projects. This way we can use our own tools and markup language to accomplish whatever we want to accomplish. Including generating a Readme.md for our GitHub projects. Just wanted to toss out this simple opinion and facts about the situation. Jimmie On 08/14/2017 04:10 AM, Tudor Girba wrote: > Hi Tim, > > The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. > > The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. > > Cheers, > Doru > > >> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >> >> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >> >> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >> >> >> Tim >> >>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi tim >>> >>> I personally do not care much about the syntax but I care about what I >>> can do with it >>> (ref, cite, ... ) >>> I cannot write books in markdown because reference to figures!!!!!! >>> were missing. >>> >>> And of course a parser because markdown is not really nice to parse >>> and I will not write a parser because I have something else to do. I >>> want to make pillar smaller, simpler, nicer. >>> >>> Now if someone come up with a parser that parse for REAL a markdown >>> that can be extended with decent behavior (figure reference, section >>> reference, cite) and can be extended because there are many things >>> that can be nice to have (for example I want to be able to write the >>> example below) and emit a PillarModel (AST) we can talk to have >>> another syntax for Pillar but not before. >>> >>> [[[test >>> 2+3 >>>>>> 5 >>> ]]] >>> >>> and being able to verify that the doc is in sync. >>> >>> >>> Stef >>> >>> >>> >>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>> >>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>> >>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>> >>>>>> The readme.md that Peter is talking about is gfm markdown >>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>> >>>>> Peter >>>>> >>>> >> > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > >

Aug. 14, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Tim Mackinnon

Iâm definitely in favour of doing something (as I found it confusing, and in a way also found it has the potential to leak what could be sensitive information through command line contexts that are still lurking in the image with details about previous directory structures and commands). I will try and and see how it impacts PharoLambda as a test example. Tim > On 14 Aug 2017, at 11:42, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > Hi all, > > I'm proposing a kind-of critical change that I believe is very good for the health of the system: I want that the startup of the system runs in maximum priority and becomes non-interruptable. > > Right now, when you save your image, the shutdown and startup are run in the same priority than the process that triggered the save (usually the ui or the command line, priority 40). This can cause lots of problems and race conditions: processes with higher priorities can interrupt the shutdown/startup and try to do something while the system is unstable. As a side effect also, when you use extensively the command line, you start stacking startup contexts from old sessions: > > ... > session 3 ctxt 4 <- This guy makes a save and a new session starts > session 3 ctxt 3 > session 3 ctxt 2 > session 3 ctxt 1 > session 2 ctxt 4 <- This guy makes a save and a new session starts > session 2 ctxt 3 > session 2 ctxt 2 > session 2 ctxt 1 > session 1 ctxt 4 <- This guy makes a save and a new session starts > session 1 ctxt 3 > session 1 ctxt 2 > session 1 ctxt 1 > > Old contexts are never collected, and the objects they referenced neither. > > To fix these two problems I propose to do every image save/session start in a new process in maximum priority. That way, other process should not be able to interrupt the startup process. Moreover, every session shutdown/startup should happen in a new clean process, to avoid the session stacking. > > For normal users, this should have no side effect at all. This change will have a good impact on people working on the debugger and the stack such as fueling-out the stack because they will have a cleaner stack. > > There is however a side-effect/design point to consider: startup actions should be quick to run. If a startup action requires to run a long-running action such as starting a server or managing a command line action, that should run in a separate process with lower priority (usually userPriority). In other words, the startup action should create a new process managing its action. > > If you want to review (and I'd be glad) > > Pull request: https://github.com/pharo-project/pharo/pull/198 <https://github.com/pharo-project/pharo/pull/198> > Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 <https://pharo.fogbugz.com/f/cases/20309> > Current validation going on: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > Guille > > -- > > Guille Polito > > Research Engineer > 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

Aug. 14, 2017

Re: [Pharo-dev] Path * '' vs. Path workingDirectory

by Alistair Grant

Hi Guille, Thanks for your reply. On Mon, Aug 14, 2017 at 01:44:41PM +0200, Guillermo Polito wrote: > > > On Sun, Aug 13, 2017 at 5:54 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > Is there any practical difference between (Path * '') and (Path > workingDirectory)? > > > Being strict, Path workingDirectory does not make any sense. A path is relative > or absolute. True, but Path is considered internal, so users shouldn't normally be calling Path>>workingDirectory. I'm asking because the patch I'm preparing to improve canonicalisation affects the creation of the path in some instances ('.' asFileReference used to have a path with an empty segment, now it has Path workingDirectory). Just for the record :-) Path workingDirectory isRelative " true" > And it is relative to some other path. Right, Pharo defines the image directory as the working directory (although https://github.com/pharo-project/pharo/pull/92 will change that to the more common shell interpretation of current working directory). > I'd expect that Path workingDirectory gives you an absolute path to the current > working directory,,, But the path doesn't have a file system to resolve against. Although even FileLocator workingDirectory gives a relative path. Thanks again, Alistair > Their internal representation is different: > > - (Path * '') has one empty segment > - Path workingDirectory has no segments > > But as far as I can tell they are otherwise the same: > > > | fs frEmpty frWD | > > fs := FileSystem disk. > frEmpty := FileReference fileSystem: fs path: (Path * ''). > frWD := FileReference fileSystem: fs path: Path workingDirectory. > String streamContents: [ :stream | > stream > << 'frEmpty: '; > << frEmpty printString; cr; > << 'frWD: '; > << frWD printString; cr; > << '= : '; > << (frEmpty absolutePath = frWD absolutePath) printString; cr. > ] > > 'frEmpty: "File @ " > frWD: "File @ ." > = : true > ' > > > Cheers, > Alistair > > > > > > -- > Guille Polito > [CNRS-filaire] > > Research Engineer > > French National Center for Scientific Research - http:// > www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 >

Aug. 14, 2017

Re: [Pharo-dev] Trying to build Mac VM - ld: library not found for -lssl

by Nicolas Cellier

Reminder: i should update the readme to explain solution 2 as commented at https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/fb61b60bda7065a52d… But I need to understand first why/how the older SDK is used (no time yet...) Of course, volunteers and good will are welcome :) 2017-08-14 16:06 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi, > This is a known problem on Sierra. > There are two possible workaround: > 1) locate the Xcode lib repository and copy /usr/lib/libssl.* there > The entire procedure is explained in a Readme > see https://github.com/OpenSmalltalk/opensmalltalk- > vm/blob/Cog/build.macos32x86/HowToBuild > 2) install older SDK - for example via XcodeLegacy - > https://github.com/devernay/xcodelegacy > The second worked for me, though I don't remember specifying usage of an > older SDK anywhere > > 2017-08-14 15:38 GMT+02:00 Todd Blanchard <tblanchard(a)mac.com>: > >> Git cloned, cd to build.macosxxx/pharo.cog.spur >> >> ./mvm -A >> >> Either 32 or 64 bit builds dies trying to build libSqueakSSL with library >> not found for -lssl. >> >> Homebrew doesn't seem to have an entry for libssl. Stumped. >> >> -Todd Blanchard >> > >

Aug. 14, 2017

Re: [Pharo-dev] Trying to build Mac VM - ld: library not found for -lssl

by Nicolas Cellier

Hi, This is a known problem on Sierra. There are two possible workaround: 1) locate the Xcode lib repository and copy /usr/lib/libssl.* there The entire procedure is explained in a Readme see https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos32x86… 2) install older SDK - for example via XcodeLegacy - https://github.com/devernay/xcodelegacy The second worked for me, though I don't remember specifying usage of an older SDK anywhere 2017-08-14 15:38 GMT+02:00 Todd Blanchard <tblanchard(a)mac.com>: > Git cloned, cd to build.macosxxx/pharo.cog.spur > > ./mvm -A > > Either 32 or 64 bit builds dies trying to build libSqueakSSL with library > not found for -lssl. > > Homebrew doesn't seem to have an entry for libssl. Stumped. > > -Todd Blanchard >

Aug. 14, 2017