Hi,


On 30/12/17 16:28, Stephane Ducasse wrote:
Can you explain to me the abstractions you mention about pandoc
because I'm curious?

I think that the best places to start are the Filters documentation[1] and the Pandoc types package [2]. They essentially show how Pandoc provides structures to build a document programmaticaly including reading, exporting and manipulate it. Filters are explained in Haskell, but the documentation shows how you can use other languages to access the doc programmability.

[1] http://pandoc.org/filters.html#summary
[2] https://hackage.haskell.org/package/pandoc-types

Quoting from the filters Summary:

"""
Pandoc consists of a set of readers and writers. When converting a document from one format to another, text is parsed by a reader into pandoc���s intermediate representation of the document���an ���abstract syntax tree��� or AST���which is then converted by the writer into the target format. The pandoc AST format is defined in the module Text.Pandoc.Definition in pandoc-types.

A ���filter��� is a program that modifies the AST, between the reader and the writer:

INPUT --reader--> AST --filter--> AST --writer--> OUTPUT
Filters are ���pipes��� that read from standard input and write to standard output.
"""


BTW you did not say:
    Ok guys I want to write a Markdown parser (to contribute to
pillar, which would be cool.)
    You said I want to have a playground to edit markdown. This is
quite different to me.

Because the second thing (Markdown support inside the Playground) is the one I want to contribute to Pharo(!), not to Pillar. Contributing should not be so hard, but each time I bring this theme is an uphill battle in just getting the initial exploration questions answered (because they're about Markdown and not about Pillar). I think that Markdown support in Pharo is healthy for Pharo and a meaningful learning experience for me. At least I should be able to test that by myself in this community with a little of support like "hey we have CommonMark inside PettitParser" or "here is how you increase the Playground Syntax support, by specializing this class".�� 

About the not invented syndrome remarks, why then don't we drop Pharo?
Now if each time we want to install pharo we should install Python,
why not installing lua and Ruby and a bit of Javascript in case.

Because is not an all or nothing proposal and it has never been. It's about Pharo *playing well with* others, not about *being replaced by* others. I don't see any worth in taking this stuff to the extremes. When someone advise me Pharo, I don't think that he/she is advising me to drop my operative system and to run Pharo from bare metal because you go the Pharo way or the No Way(!).


You are under estimating the effort that we put in Pillar. We
extracted pillar from pier to be able to have an autonomous document
system with which we can write good pdf and good HTML for
documentation point of view. Because people did not like to write in
LaTeX.
Now if we would stop something each time somebody mention something
else we would be doing python, Javascript or ...
all the time.

I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in Pandoc. In fact trying to make them work better together and giving back to this community by making software with Pharo and teaching people Pharo (for free) are clear examples of my appreciation for the work done in several fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, shows practical appreciation for those formats and I don't think that we should reimplement them in Pharo (despite of several advantages of live objects as documents instead of dead-files). Instead of putting valuations I have never done on me, I would advice to try seeing worth in the reasons behind a lot of people outside this community is using (Pandoc's) Markdown for documentation and the added value that adding Markdown support brings by having more people exposed to Pharo ecosystem, ideas, community, values and technology.

So yes I'm dense and I focus on my stuff and my stuff is Pharo.
And yes I do not care about pandoc because I want to write my
exporters and tools in Pharo and I will fight for that.

But we don't need to fight for that. I value your decisions and work and I think that is healthy to ask for reciprocity and build from that, instead of wasting time because we don't think the same. Diversity is healthy in a community. The only thing I'm asking for (besides such reciprocity) is pointers to start *my* exploration.


This is why I want to use Scale instead of *&%*^)&%^ bash.
And this is why I spent most of time trying to improve Pharo because
it is not at the level I want but I can contribute
and make it better.

Stef

I don't use bash or Json config files for anything related with documentation in Grafoscopio. Just plain Pharo inside an interactive "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, Scale, would be welcomed when integration with them is ready. I spent good time also trying to make my contributions and improvements to Pharo. We don't need to fight because our ways of contribution are different.

Cheers,

Offray