August 2017 - Pharo-dev - lists.pharo.org

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

by Dimitris Chloupis

On Thu, Aug 17, 2017 at 4:25 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi Dimitris (good to see you around ;) ), > > Not going anywhere , just taking a break from Pharo :) > thing isâ¦ we want to improve our tools. > > great > And improve tools sometime means to add stuff (Iâm not very happy with it > either, I would like to remove more than what I add, but it is like that). > For example, if we want to have good class comments, we need some markup > format, then the best thing we have is pillar and then we need a parser and > then the easiest to use thing we have is petit parser. > Yeah.. about that. See the issue is exactly what you just mentioned , improvement. Sometimes improving makes things worse. Markdown class comments is an excellent example of this. You do the logical thing and offer markdown for class comments , you make the image more complex by adding a feature the average user would need but you greatly improve your ability for class comments. But your average user does not even bother adding one line comment on the main class what are the chances that will use markdown ? I am willing to bet big money on "close to zero chance". Hence you end up making things actually worse by adding code that your user wont use and instead increasing the complexity and his motivation to explore and fall in love with your project. > Which means we will need an image that have a core PetitParser and a basic > Pillarâ¦ so we can have proper documentation. Of course, maybe the full > pillar is too much (as it is the full petit parser, probably) so we need to > think carefully what we put inside and what we left outside. Same is with > everything: why to put athens, or glamour, or X, Y, Z. (things that few > people use, but are very important for our echosystem in general). > Well if few people use them, how they are important to your ecosystem ? If you talking about dependencies then that means the ecosystem is deeply flawed and we go back to the modularity question. I fail to see how Athens is important to the Pharo ecosystem , apart from Roassal people I have not seen anyone else using it consistently. If you were talking about the UFFI I would agree 100% but I cannot agree by any means that Athens is so important for Pharo that must be included in the image. By the way I am a graphics guy so biased in favour of Athens. > > Now, along with this âbloatingâ movements, that adds more elements to the > system and because of that increases essential complexity, we are working > on the other direction: bootstrapping and modularising Pharo so in the near > future (it should be done for P7 or as late to P8) you will be able to > create an image with the elements you want. > > Another thing we need to work on (but thatâs in part documentation and in > part modifications to be done) we need to work on overall > availability/comprehensibility of the system. > > Soâ¦ we need to continue adding things, in order to continue improving. We > also need to remove a lot of things that are duplicated or obsolete. > Pharo will always be âthe deliverable we makeâ (including all things we > officially support as âpart of itâ)â¦ but we are making possible that > everybody can also do âthe Pharo they wantâ. > I can understand having a Parser in image to parse Pharo syntax and other things, big thumbs up for that I think that would justify the inclusion for the average user. Parsing and dealing with text is a big deal afterall. I am ok with offering a minimal image and not being the default one. As long it exists I am happy.

Aug. 17, 2017

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

by phil＠highoctane.be

Got an architecture discussion with a client this morning and a lot of pain they face is that there are too many choices out there on some platforms. A batteries included distro with one good framework doing its thing nicely if really a good thing to have. It reduces the amount of choice and thus allows to focus on the business problem instead of diving into endless technical discussions. Phil On Thu, Aug 17, 2017 at 3:32 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 17 Aug 2017, at 15:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > hi Dimitris (good to see you around ;) ), > > thing isâ¦ we want to improve our tools. > > And improve tools sometime means to add stuff (Iâm not very happy with it > either, I would like to remove more than what I add, but it is like that). > For example, if we want to have good class comments, we need some markup > format, then the best thing we have is pillar and then we need a parser and > then the easiest to use thing we have is petit parser. > > Which means we will need an image that have a core PetitParser and a basic > Pillarâ¦ so we can have proper documentation. Of course, maybe the full > pillar is too much (as it is the full petit parser, probably) so we need to > think carefully what we put inside and what we left outside. Same is with > everything: why to put athens, or glamour, or X, Y, Z. (things that few > people use, but are very important for our echosystem in general). > > > a corollary of this is that, if we think well and we include the correct > addition, then itâs exponential (having a real parser inside can easy a lot > of developments, and can also lead to better tools). > > > Now, along with this âbloatingâ movements, that adds more elements to the > system and because of that increases essential complexity, we are working > on the other direction: bootstrapping and modularising Pharo so in the near > future (it should be done for P7 or as late to P8) you will be able to > create an image with the elements you want. > > Another thing we need to work on (but thatâs in part documentation and in > part modifications to be done) we need to work on overall > availability/comprehensibility of the system. > > Soâ¦ we need to continue adding things, in order to continue improving. We > also need to remove a lot of things that are duplicated or obsolete. > Pharo will always be âthe deliverable we makeâ (including all things we > officially support as âpart of itâ)â¦ but we are making possible that > everybody can also do âthe Pharo they wantâ. > > cheers, > Esteban > > On 17 Aug 2017, at 14:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Is it really necessary ? > > I am more a modular guy , I would love to get an image that 0.1% the size > of the current one and offer me a convenient package manager to install the > tools I like. > > I have used Pillar ALOT probably more than any other Pharo library because > I was doing Pharo documentation stuff. > I have even used Pillar to build my website , yeah I know that is not the > pupose of Pillar but with some modification and the addition of a tool I > created (Octopus) it help me generate some portion of the website via > mustache. > > Do I want Pillar in ? Nope > > Already the System Browser looks like a monster ready to eat you alive, I > think we need to make the image a lot less threatening especially for > newcomers. There is such thing as too much info. > > Pillar is in the Package Browser you just click and install it if you dont > mind the wait because its a rather big install. > > On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> Even though I've initiated this discussion I kind of stopped reading >> because everyone started discussing completely unrelated things... >> >> The initial point was.... "we are using github/gitlab more and more, lets >> leverage it more" >> >> New, lets separate the concepts at play here... >> >> "Pillar - document model" - the workhorse of pillar and (imho) the most >> important part of it, and also the part I am interested in being included. >> Because then I can generate the document directly without using any >> syntax... >> >> "Pillar - syntax" - we can have endless arguments whether the syntax is >> good or bad, and imho that should be a separate discussion unrelated to the >> Pillar inclusion >> >> "Markdown for unrelated usecases" - whether you can or cannot write your >> thesis in markdown is really irelevant here >> >> "Markdown - export" - there will always be different variants and >> extensions for Markdown, simply because the sites using markdown offer >> different capabilities. >> >> Therefore the first focus should be on the most impact/effort ratio, >> which is CommonMark (basically the only meaningful Markdown specification), >> and GFM (which is a CommonMark with added tables and strikethrough). >> >> Adding support for more extensive export support, whether code related >> (e.g. GitLab), or code unrelated (writing a thesis) should be a future >> discussion, it is not relevant or too effortful right now. >> >> "Markdown - import" - I would love to be able to write markdown and have >> it imported into the Pillar document model, however that is imho moot point >> right now, as it can always be added later >> >> >> To summarize: >> >> * primary >> * include pillar document model >> * include pillar syntax (as an import format) >> * add CommonMark+GFM export >> * secondary >> * discuss Pillar syntax if needed (in a _new_ thread) >> * discuss Markdown parser / importing CommonMark into Pillar model >> * any other discussion not pertinent here should go elsewhere >> >> Peter >> >> >> On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: >> > Hi, >> > >> > In general (you all know me), I have the policy of âdo not go alien >> just becauseâ which means we do not need to reinvent the wheel all the time >> and we need to stick with what is already there and known (I have pushed >> many changes in pharo following this direction, iceberg being just the >> latest), but we need to keep also the basis of what we are (which means: >> when we need to stay alien, we need to embrace it too). >> > >> > Said that: while I would LOVE to have a markdown compatible format, the >> amount of effort put on pillar to make it *what we need* and is a format >> used not just for doing README.md but to write books, etc., then replacing >> it would be complicated. >> > >> > butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can >> even have a stripped-pillar with would be even more like md), I would >> salute such change. >> > >> > cheers, >> > Esteban >> > >> > >> > > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > > >> > > >> > > >> > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)openinworld.com>> wrote: >> > > >> > >> >> > >> >> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo < >> emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> > >> You hit several birds with one single mail. >> > >> >> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto: >> 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 ``` >> > >> >> > >> +1. So I've posted this before... >> > >> https://www.joelonsoftware.com/2000/06/03/strategy- >> letter-iii-let-me-go-back/ <https://www.joelonsoftware. >> com/2000/06/03/strategy-letter-iii-let-me-go-back/> >> > >> describing that "The only strategy in getting people to switch to >> your product is to eliminate barriers" >> > >> >> > >> But more... the best reason for Pillar to support a Markdown-ish >> syntax, is that when we scratch-our-own-itch (nominally for Pillar) to >> build the best damn markup-editor ever (because we can!) - if this happened >> to support Markdown it can draw in Markdown-non-Pharo users (because its >> the best editor ever!). Those users later want to make modifications, and >> now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... >> > >> >> > >> So don't just promote to people "hey come and play with this cool >> toy of ours (Pharo)." >> > >> Instead give them a toy they *already-want* (Markdown editor) and >> then when they want to change the batteries, they *need* to use our special >> screwdriver (Pharo). >> > > >> > > +1! >> > > >> > >> >> > >> cheers -ben >> > >> >> > >> >> > >> > 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. 17, 2017

Re: [Pharo-dev] Can we have subclasses of Process?

by henry

EventualProcess is in eventual_test [*], as example. Do not run RefsTest>>#testFailedArithmaticwithEventualArgument or will segfault vm. - HH [*] - http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz On Thu, Aug 17, 2017 at 08:33, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I think there is no technical limitation for it, AFAIK, the VM never checks the class of a process. I also proposed something like that in this paper: > > http://guillep.github.io/files/publications/Poli14b-IWST-GlobalStateClassif… > > On Thu, Aug 17, 2017 at 2:24 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> I've used subclasses of process for the debugger stuff without problems. >> Max >> >> On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisiydk(a)gmail.com) wrote: >> >>> Hi. >>> >>> Is it allowed to subclass Process? I remember that there were some problems with it but I could not find any information. >>> >>> Generally I think about system processes which can be represented by concrete subclasses. For example explicit UIProcess can be used to remove many #isUIProcess conditions from system. >>> >>> Best regards, >>> Denis > > -- > > Guille Polito > > 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. 17, 2017

Re: [Pharo-dev] Issue that may break Epicea

by Martin Dias

Hm, I'll take it into account anyway, thanks. I miss coding in Pharo! I have to reserve some aftenoon to work in some epicea open issues. Cheers, Martin On Thu, Aug 17, 2017 at 5:59 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Why would it break epicea? > > There is no major change in API. Only the method #createDirectory is > removed, but the only users are internal to the library. In my latest image > there are no Epicea users of it. > > On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi martin >> >> >> https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> https://github.com/pharo-project/pharo/pull/133 >> >> > > > -- > > > > 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. 17, 2017

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

by Esteban Lorenzano

> On 17 Aug 2017, at 15:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > hi Dimitris (good to see you around ;) ), > > thing isâ¦ we want to improve our tools. > > And improve tools sometime means to add stuff (Iâm not very happy with it either, I would like to remove more than what I add, but it is like that). For example, if we want to have good class comments, we need some markup format, then the best thing we have is pillar and then we need a parser and then the easiest to use thing we have is petit parser. > > Which means we will need an image that have a core PetitParser and a basic Pillarâ¦ so we can have proper documentation. Of course, maybe the full pillar is too much (as it is the full petit parser, probably) so we need to think carefully what we put inside and what we left outside. Same is with everything: why to put athens, or glamour, or X, Y, Z. (things that few people use, but are very important for our echosystem in general). a corollary of this is that, if we think well and we include the correct addition, then itâs exponential (having a real parser inside can easy a lot of developments, and can also lead to better tools). > > Now, along with this âbloatingâ movements, that adds more elements to the system and because of that increases essential complexity, we are working on the other direction: bootstrapping and modularising Pharo so in the near future (it should be done for P7 or as late to P8) you will be able to create an image with the elements you want. > > Another thing we need to work on (but thatâs in part documentation and in part modifications to be done) we need to work on overall availability/comprehensibility of the system. > > Soâ¦ we need to continue adding things, in order to continue improving. We also need to remove a lot of things that are duplicated or obsolete. > Pharo will always be âthe deliverable we makeâ (including all things we officially support as âpart of itâ)â¦ but we are making possible that everybody can also do âthe Pharo they wantâ. > > cheers, > Esteban > >> On 17 Aug 2017, at 14:01, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> Is it really necessary ? >> >> I am more a modular guy , I would love to get an image that 0.1% the size of the current one and offer me a convenient package manager to install the tools I like. >> >> I have used Pillar ALOT probably more than any other Pharo library because I was doing Pharo documentation stuff. >> I have even used Pillar to build my website , yeah I know that is not the pupose of Pillar but with some modification and the addition of a tool I created (Octopus) it help me generate some portion of the website via mustache. >> >> Do I want Pillar in ? Nope >> >> Already the System Browser looks like a monster ready to eat you alive, I think we need to make the image a lot less threatening especially for newcomers. There is such thing as too much info. >> >> Pillar is in the Package Browser you just click and install it if you dont mind the wait because its a rather big install. >> >> On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> Even though I've initiated this discussion I kind of stopped reading because everyone started discussing completely unrelated things... >> >> The initial point was.... "we are using github/gitlab more and more, lets leverage it more" >> >> New, lets separate the concepts at play here... >> >> "Pillar - document model" - the workhorse of pillar and (imho) the most important part of it, and also the part I am interested in being included. Because then I can generate the document directly without using any syntax... >> >> "Pillar - syntax" - we can have endless arguments whether the syntax is good or bad, and imho that should be a separate discussion unrelated to the Pillar inclusion >> >> "Markdown for unrelated usecases" - whether you can or cannot write your thesis in markdown is really irelevant here >> >> "Markdown - export" - there will always be different variants and extensions for Markdown, simply because the sites using markdown offer different capabilities. >> >> Therefore the first focus should be on the most impact/effort ratio, which is CommonMark (basically the only meaningful Markdown specification), and GFM (which is a CommonMark with added tables and strikethrough). >> >> Adding support for more extensive export support, whether code related (e.g. GitLab), or code unrelated (writing a thesis) should be a future discussion, it is not relevant or too effortful right now. >> >> "Markdown - import" - I would love to be able to write markdown and have it imported into the Pillar document model, however that is imho moot point right now, as it can always be added later >> >> >> To summarize: >> >> * primary >> * include pillar document model >> * include pillar syntax (as an import format) >> * add CommonMark+GFM export >> * secondary >> * discuss Pillar syntax if needed (in a _new_ thread) >> * discuss Markdown parser / importing CommonMark into Pillar model >> * any other discussion not pertinent here should go elsewhere >> >> Peter >> >> >> On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: >> > Hi, >> > >> > In general (you all know me), I have the policy of âdo not go alien just becauseâ which means we do not need to reinvent the wheel all the time and we need to stick with what is already there and known (I have pushed many changes in pharo following this direction, iceberg being just the latest), but we need to keep also the basis of what we are (which means: when we need to stay alien, we need to embrace it too). >> > >> > Said that: while I would LOVE to have a markdown compatible format, the amount of effort put on pillar to make it *what we need* and is a format used not just for doing README.md but to write books, etc., then replacing it would be complicated. >> > >> > butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can even have a stripped-pillar with would be even more like md), I would salute such change. >> > >> > cheers, >> > Esteban >> > >> > >> > > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> > > >> > > >> > > >> > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> wrote: >> > > >> > >> >> > >> >> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com> <mailto:emaringolo@gmail.com <mailto:emaringolo@gmail.com>>> wrote: >> > >> You hit several birds with one single mail. >> > >> >> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works> <mailto:tim@testit.works <mailto:tim@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 ``` >> > >> >> > >> +1. So I've posted this before... >> > >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…> <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…>> >> > >> describing that "The only strategy in getting people to switch to your product is to eliminate barriers" >> > >> >> > >> But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... >> > >> >> > >> So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." >> > >> Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). >> > > >> > > +1! >> > > >> > >> >> > >> cheers -ben >> > >> >> > >> >> > >> > 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. 17, 2017

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

by Esteban Lorenzano

hi Dimitris (good to see you around ;) ), thing isâ¦ we want to improve our tools. And improve tools sometime means to add stuff (Iâm not very happy with it either, I would like to remove more than what I add, but it is like that). For example, if we want to have good class comments, we need some markup format, then the best thing we have is pillar and then we need a parser and then the easiest to use thing we have is petit parser. Which means we will need an image that have a core PetitParser and a basic Pillarâ¦ so we can have proper documentation. Of course, maybe the full pillar is too much (as it is the full petit parser, probably) so we need to think carefully what we put inside and what we left outside. Same is with everything: why to put athens, or glamour, or X, Y, Z. (things that few people use, but are very important for our echosystem in general). Now, along with this âbloatingâ movements, that adds more elements to the system and because of that increases essential complexity, we are working on the other direction: bootstrapping and modularising Pharo so in the near future (it should be done for P7 or as late to P8) you will be able to create an image with the elements you want. Another thing we need to work on (but thatâs in part documentation and in part modifications to be done) we need to work on overall availability/comprehensibility of the system. Soâ¦ we need to continue adding things, in order to continue improving. We also need to remove a lot of things that are duplicated or obsolete. Pharo will always be âthe deliverable we makeâ (including all things we officially support as âpart of itâ)â¦ but we are making possible that everybody can also do âthe Pharo they wantâ. cheers, Esteban > On 17 Aug 2017, at 14:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Is it really necessary ? > > I am more a modular guy , I would love to get an image that 0.1% the size of the current one and offer me a convenient package manager to install the tools I like. > > I have used Pillar ALOT probably more than any other Pharo library because I was doing Pharo documentation stuff. > I have even used Pillar to build my website , yeah I know that is not the pupose of Pillar but with some modification and the addition of a tool I created (Octopus) it help me generate some portion of the website via mustache. > > Do I want Pillar in ? Nope > > Already the System Browser looks like a monster ready to eat you alive, I think we need to make the image a lot less threatening especially for newcomers. There is such thing as too much info. > > Pillar is in the Package Browser you just click and install it if you dont mind the wait because its a rather big install. > > On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > Even though I've initiated this discussion I kind of stopped reading because everyone started discussing completely unrelated things... > > The initial point was.... "we are using github/gitlab more and more, lets leverage it more" > > New, lets separate the concepts at play here... > > "Pillar - document model" - the workhorse of pillar and (imho) the most important part of it, and also the part I am interested in being included. Because then I can generate the document directly without using any syntax... > > "Pillar - syntax" - we can have endless arguments whether the syntax is good or bad, and imho that should be a separate discussion unrelated to the Pillar inclusion > > "Markdown for unrelated usecases" - whether you can or cannot write your thesis in markdown is really irelevant here > > "Markdown - export" - there will always be different variants and extensions for Markdown, simply because the sites using markdown offer different capabilities. > > Therefore the first focus should be on the most impact/effort ratio, which is CommonMark (basically the only meaningful Markdown specification), and GFM (which is a CommonMark with added tables and strikethrough). > > Adding support for more extensive export support, whether code related (e.g. GitLab), or code unrelated (writing a thesis) should be a future discussion, it is not relevant or too effortful right now. > > "Markdown - import" - I would love to be able to write markdown and have it imported into the Pillar document model, however that is imho moot point right now, as it can always be added later > > > To summarize: > > * primary > * include pillar document model > * include pillar syntax (as an import format) > * add CommonMark+GFM export > * secondary > * discuss Pillar syntax if needed (in a _new_ thread) > * discuss Markdown parser / importing CommonMark into Pillar model > * any other discussion not pertinent here should go elsewhere > > Peter > > > On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: > > Hi, > > > > In general (you all know me), I have the policy of âdo not go alien just becauseâ which means we do not need to reinvent the wheel all the time and we need to stick with what is already there and known (I have pushed many changes in pharo following this direction, iceberg being just the latest), but we need to keep also the basis of what we are (which means: when we need to stay alien, we need to embrace it too). > > > > Said that: while I would LOVE to have a markdown compatible format, the amount of effort put on pillar to make it *what we need* and is a format used not just for doing README.md but to write books, etc., then replacing it would be complicated. > > > > butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can even have a stripped-pillar with would be even more like md), I would salute such change. > > > > cheers, > > Esteban > > > > > > > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > > > > > > > > > > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> wrote: > > > > > >> > > >> > > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com> <mailto:emaringolo@gmail.com <mailto:emaringolo@gmail.com>>> wrote: > > >> You hit several birds with one single mail. > > >> > > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works <mailto:tim@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 ``` > > >> > > >> +1. So I've posted this before... > > >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…> <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…>> > > >> describing that "The only strategy in getting people to switch to your product is to eliminate barriers" > > >> > > >> But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... > > >> > > >> So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." > > >> Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). > > > > > > +1! > > > > > >> > > >> cheers -ben > > >> > > >> > > >> > 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. 17, 2017

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

by Guillermo Polito

On Mon, Aug 14, 2017 at 4:11 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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. > Ah, I was thinking with Pablo the other day that it could be a nice small and standalone library to manage paths. Then FileSystem can work on top. What do you think? That's why with Pablo we extracted the Path classes in a separate package (FileSystem-Path). We also see it has few dependencies and this means that it could go into the bootstrap :). > > 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 > > > > -- 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. 17, 2017

Re: [Pharo-dev] Can we have subclasses of Process?

by Guillermo Polito

I think there is no technical limitation for it, AFAIK, the VM never checks the class of a process. I also proposed something like that in this paper: http://guillep.github.io/files/publications/Poli14b-IWST-GlobalStateClassif… On Thu, Aug 17, 2017 at 2:24 PM, Max Leske <maxleske(a)gmail.com> wrote: > I've used subclasses of process for the debugger stuff without problems. > > Max > > > > On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisiydk(a)gmail.com) > wrote: > > Hi. > > Is it allowed to subclass Process? I remember that there were some > problems with it but I could not find any information. > > Generally I think about system processes which can be represented by > concrete subclasses. For example explicit UIProcess can be used to remove > many #isUIProcess conditions from system. > > Best regards, > Denis > > -- 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. 17, 2017

Re: [Pharo-dev] Can we have subclasses of Process?

by Max Leske

I've used subclasses of process for the debugger stuff without problems. Max On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisiydk(a)gmail.com) wrote: Hi. Is it allowed to subclass Process? I remember that there were some problems with it but I could not find any information. Generally I think about system processes which can be represented by concrete subclasses. For example explicit UIProcess can be used to remove many #isUIProcess conditions from system. Best regards, Denis

Aug. 17, 2017

Can we have subclasses of Process?

by Denis Kudriashov

Hi. Is it allowed to subclass Process? I remember that there were some problems with it but I could not find any information. Generally I think about system processes which can be represented by concrete subclasses. For example explicit UIProcess can be used to remove many #isUIProcess conditions from system. Best regards, Denis

Aug. 17, 2017