Hi,
On 31/12/17 05:13, Stephane Ducasse wrote: >> 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. Cool. As I said in this thread in response to Stephan Eggermont, my concern is not about new under the sun, but in bridging cultural practices. > >> 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 don't need to. I will use CommonMark and PettitParser. I imagine GT-Tools can use the models there in the Playground. > Go ahead and learn. Wow! Finally! > >> 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 That was precisely my point. To show the absurd of exaggeration. I don't think that proposing a versatile Playground that supports several syntax highlighting (and some supporting behavior) is the same as proposing to install everything, kill Pillar efforts or anything like that. In the same way that using Pharo doesn't mean stop using anything else. But proposing anything distinct from Pillar as a documentation *alternative* in Pharo is faced time and again with overreactions. > 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. > I use just plain Pharo as much as possible in Grafoscopio. I don't have any external bash, config, yaml file to produce a document. Jus plain Pharo dictionaries and dynamic arrays stored *inside* the notebook. I use Pandoc to import/export to several formats (a place where it is superb and without any closer competitor), we started to use some Lua scripts (which are already supported in Pandoc) to query/script its document model and I have thought in using Pharo Mustache to program the Pandoc Templates. So in my "borg approach" I glue Pharo to existing ecosystems (including techs and communities) to improve them, while making bridges between what they already know and what Pharo has to offer. > > > > > # 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 I document targets as a "%metadata" node inside the Grafoscopio notebook. No shell magic beyond Pandoc one line flags. >> 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? I'm not using such ad-populum argument. I'm talking about *bridges* to what people is already using (in the backend) so we can show and use Pharo with them (in the front end) for data storytelling. > Pandoc is the same as Pillar. Maybe in the technical side, but with a more diverse and agile community devoted exclusively to think about light markup languages. Bridging with other communities shouldn't be seen as negative. > 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. > Well I just want Markdown syntax highlighting in the Playground (besides the current Smalltalk one). It amaze me how much resistance about what I want to explore and can be able to contribute, it's faced every time. > > >> 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. > Well is not. Having bridges with R (like the ones we have now) doesn't preclude or diminish the work in Polymath. Or having Garage to bridge with external data bases doesn't preclude any work in native OODBs or bridges with JSON don't preclude any work STON. Having bridges with Pandoc/Markdown, doesn't preclude/diminish any work with Pillar. I have told this since the first thread about this subject, but you insist in a confrontational approach. I will not engage in it when both can coexist and be helpful for this and other communities. > 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. I will start my exploration with PetitParser and CommonMark. >> 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. > That's all I want: explore and learn. I finally have pointers to where to start. It just be more fluent if I don't have to fight an uphill battle anytime Markdown support is mentioned. Cheers, Offray
