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

Dimitris Chloupis kilon.alios at gmail.com
Thu Aug 17 08:01:07 EDT 2017


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 at 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 at gmail.com>
> wrote:
> > >
> > >
> > >
> > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc at openinworld.com <mailto:
> btc at openinworld.com>> wrote:
> > >
> > >>
> > >>
> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <
> emaringolo at gmail.com <mailto:emaringolo at gmail.com>> wrote:
> > >> You hit several birds with one single mail.
> > >>
> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim at testit.works <mailto:
> tim at 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170817/62d3b9d1/attachment.html>


More information about the Pharo-dev mailing list