> 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. > """
FYI Pillar has the following architecture Input --Reader -> AST -> (Transformer -> AST)* -Outputers (visitor) -> Save So nothing new under the sun. Notice that we can do several transformation passes like expansions. > 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). So you will code your own text Model, AST, and visitor? Did you see that GT people are using Pillar model for the their editor? 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". Go ahead and learn. > 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 exagerating and more important under estimating the COST of using multiple systems. Let me take four simple cases - We spend hours debugging Yaml to embedd bash into a travis (no debugger of course) and we failed while we try to understand why the validator went wrong and did not like space (we tried many many combinations of `"' and more. And gave up. Guille is much better than me and Andrew on bash and we all three failed. - Pillar was using external mustache unix based library and I forced them at that time to use Norbert implementation and we can debug it. We can avoid to have bugs because converting a stream into a file then invoking make then reloading the file. - Looking during two days for a bug in bash script that tells that eveyrthing is ok while one package that should have been loaded was dropped. Now we use metacello instead relying on bash now. Do you want more... I have tons of them like that ... Each time you have a different stack you had another level of complexity and it is not linear but exponential. This is the same with servers and processes. Pillar archetypes were zipped on a Jenkins server that may be blocked from time to time. Smalltalkhub may be slow and the bash will continue without failing and your installation breaks. So we are flushing everything. No more mustache on disc, no more spurious metadata, no more separate server, no more make (see below I was not even able to add one entry to the help), no more cp -r (that is not compatible on different OSes!!!). Just plain pharo as much as possible. # Some shell magic to auto-document the main targets. To have a target appear in # the output, add a short, one-line comment with a double ## on the same line as # the target. # # See http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html .phony: help help: ## Describe the main targets (this list) @echo "Main targets you can build:" @awk -F ':|## *' \ '/^[^\t].+:.*##/ {\ printf " \033[36m%s\033[0m#%s\n", $$1, $$NF \ }' $(MAKEFILE_LIST) \ | column -s# -t @[ -n "$(ALTERNATEPRINTFORMATS)" ] \ && echo "Print format alternatives: pdf $(ALTERNATEPRINTFORMATS)" @echo "Combined format+volume targets: pdfbook, htmlchapters…" @echo "To make a single specific file/format, ask for it explicitly:" @echo " make $(OUTPUTDIRECTORY)/$(firstword $(CHAPTERS)).pdf" # Check that given variables are set and all have non-empty values, # die with an error otherwise. # # Params: # 1. Variable name(s) to test. # 2. (optional) Error message to print. # # See http://stackoverflow.com/questions/10858261/abort-makefile-if-variable-not-set check_defined = \ $(strip $(foreach 1,$1, \ $(call __check_defined,$1,$(strip $(value 2))))) __check_defined = \ $(if $(value $1),, \ $(error Undefined setting $1$(if $2, ($2)))) > 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. The argument that Coca cola is good because many people drink it does not hold. You see Pythoners have their own systems with their own syntax. So what? Pandoc is the same as Pillar. I do not care about the Pillar syntax. I care that this is implemented in Pharo. Now I will not write a markdown parser myself because I have what I need. if other people propose a not super complex parser for markdown then we can integrate it and let people use their own. > 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. Yes because we should do the web in Javascript and the math in R and .... This is always like 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. Then explore. You can also learn from Pillar :) If you want to have a look the pipeline in version 5 is obscrure and in the new pipeline guille dramatically cleaned it. and we will continue. > > 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. Ok try and learn. > > Cheers, > > Offray
