Re: [Pharo-dev] PetitMarkdown

[H. Hirzel]

Hi Jan,

Thank you for your answer, in particular the PPMiniCommonMark example.

For me this is an interesting work, I can see a lot lot of application
areas in and out of the Pharo context. I'll have a closer look at your
implementation, in particular the test cases.

Have a good day

Hannes

On 5/3/15, Jan Kurš  wrote:
> Hi Hannes,
>
> I actually did not do any changes to the grammar, I wrote the grammar from
> scratch. The reason I did so was to have a proof of concept of my
> PetitParser extension for parsing indentation-sensitive grammars such as
> Markdown or Python.
>
> The most simplest example you can do is to evaluate following:
>
> PPMiniCommonMark new parse: '
> # Heading
>
> - list item
> - second list item
> '
> As a result, you will get HTML fragment, that corresponds to one heading
> and list of items. All the supported CommonMark syntax is covered in the
> tests, so what you don't see in the test, has to be implemented.
>
> CommonMark is kind of beast to parse, I had to do one big extension to
> parse it. It is to introduce the indentation stack (as described in
> http://scg.unibe.ch/research/indentParsing). You can see the indentation
> stack manipulation in PPMiniCommonMark rules such as: #prefix, #quoteBegin,
> #quoteEnd, #itemBullet and #itemEnd.
>
> Cheers,
> Jan
>
> On 3 May 2015 at 08:46, H. Hirzel  wrote:
>
>> Thank you Jan, for your work in enhancing PetitParser for Markdown. I
>> think I got what you did by loading PetitParser in Pharo 4.0.
>>
>> I found the examples PPMarkdownGrammarTest, category testing-documents.
>>
>> I also read http://scg.unibe.ch/research/indentParsing.
>>
>> Could you please elaborate a bit more about the changes you did to the
>> grammar and give some more usage examples?
>>
>> Regards
>>
>> Hannes
>>
>> On 4/14/15, Jan Kurš  wrote:
>> > Hey,
>> >
>> > I also created an indentation sensitive extension of PetitParser, I
>> > also
>> > included some examples including Markdown. If you load PetitParser, you
>> get
>> > the Markdown example as well.
>> >
>> > There is a short introduction to the indentation:
>> >
>> > http://scg.unibe.ch/research/indentParsing
>> >
>> > Cheers Jan
>> > On Apr 13, 2015 5:24 PM, "H. Hirzel"  wrote:
>> >
>> >> Are there any news on this?
>> >>
>> >> --Hannes
>> >>
>> >> On 12/28/14, Norbert Hartl  wrote:
>> >> > I found markdown parsers in smalltalkhub and in the configuration
>> >> browser.
>> >> >
>> >> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
>> >> > 
>> >> >
>> >> > and the one in the configuration browser
>> >> >
>> >> > PPMarkdown
>> >> >
>> >> > If I understand it correctly both are rooted into work Camillo did.
>> The
>> >> one
>> >> > in PharoExtras looks newer to me. So I assume the best would be to
>> copy
>> >> the
>> >> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and
>> >> > remove
>> >> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
>> >> >
>> >> > Norbert
>> >>
>> >>
>> >
>>
>>
>

Re: [Pharo-dev] PetitMarkdown

[Jan Kurš]

Hi Hannes,

I actually did not do any changes to the grammar, I wrote the grammar from
scratch. The reason I did so was to have a proof of concept of my
PetitParser extension for parsing indentation-sensitive grammars such as
Markdown or Python.

The most simplest example you can do is to evaluate following:

PPMiniCommonMark new parse: '
# Heading

- list item
- second list item
'
As a result, you will get HTML fragment, that corresponds to one heading
and list of items. All the supported CommonMark syntax is covered in the
tests, so what you don't see in the test, has to be implemented.

CommonMark is kind of beast to parse, I had to do one big extension to
parse it. It is to introduce the indentation stack (as described in
http://scg.unibe.ch/research/indentParsing). You can see the indentation
stack manipulation in PPMiniCommonMark rules such as: #prefix, #quoteBegin,
#quoteEnd, #itemBullet and #itemEnd.

Cheers,
Jan

On 3 May 2015 at 08:46, H. Hirzel  wrote:

> Thank you Jan, for your work in enhancing PetitParser for Markdown. I
> think I got what you did by loading PetitParser in Pharo 4.0.
>
> I found the examples PPMarkdownGrammarTest, category testing-documents.
>
> I also read http://scg.unibe.ch/research/indentParsing.
>
> Could you please elaborate a bit more about the changes you did to the
> grammar and give some more usage examples?
>
> Regards
>
> Hannes
>
> On 4/14/15, Jan Kurš  wrote:
> > Hey,
> >
> > I also created an indentation sensitive extension of PetitParser, I also
> > included some examples including Markdown. If you load PetitParser, you
> get
> > the Markdown example as well.
> >
> > There is a short introduction to the indentation:
> >
> > http://scg.unibe.ch/research/indentParsing
> >
> > Cheers Jan
> > On Apr 13, 2015 5:24 PM, "H. Hirzel"  wrote:
> >
> >> Are there any news on this?
> >>
> >> --Hannes
> >>
> >> On 12/28/14, Norbert Hartl  wrote:
> >> > I found markdown parsers in smalltalkhub and in the configuration
> >> browser.
> >> >
> >> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
> >> > 
> >> >
> >> > and the one in the configuration browser
> >> >
> >> > PPMarkdown
> >> >
> >> > If I understand it correctly both are rooted into work Camillo did.
> The
> >> one
> >> > in PharoExtras looks newer to me. So I assume the best would be to
> copy
> >> the
> >> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and
> >> > remove
> >> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
> >> >
> >> > Norbert
> >>
> >>
> >
>
>

Re: [Pharo-dev] PetitMarkdown

[H. Hirzel]

Thank you Jan, for your work in enhancing PetitParser for Markdown. I
think I got what you did by loading PetitParser in Pharo 4.0.

I found the examples PPMarkdownGrammarTest, category testing-documents.

I also read http://scg.unibe.ch/research/indentParsing.

Could you please elaborate a bit more about the changes you did to the
grammar and give some more usage examples?

Regards

Hannes

On 4/14/15, Jan Kurš  wrote:
> Hey,
>
> I also created an indentation sensitive extension of PetitParser, I also
> included some examples including Markdown. If you load PetitParser, you get
> the Markdown example as well.
>
> There is a short introduction to the indentation:
>
> http://scg.unibe.ch/research/indentParsing
>
> Cheers Jan
> On Apr 13, 2015 5:24 PM, "H. Hirzel"  wrote:
>
>> Are there any news on this?
>>
>> --Hannes
>>
>> On 12/28/14, Norbert Hartl  wrote:
>> > I found markdown parsers in smalltalkhub and in the configuration
>> browser.
>> >
>> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
>> > 
>> >
>> > and the one in the configuration browser
>> >
>> > PPMarkdown
>> >
>> > If I understand it correctly both are rooted into work Camillo did. The
>> one
>> > in PharoExtras looks newer to me. So I assume the best would be to copy
>> the
>> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and
>> > remove
>> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
>> >
>> > Norbert
>>
>>
>

Re: [Pharo-dev] PetitMarkdown

[Damien Cassou]

Dmitri Zagidulin  writes:

> Is this an issue of the version of Pillar that the book's build tools are
> using?

I thought I implemented that but you are right, it is not implemented.
If you are lucky, Cyril will see this thread and fix it (hint, it's in
PRLaTeXWriter>>writeEmbeddedPicture:).

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] PetitMarkdown

[Stephan Eggermont]

On 18/04/15 18:49, Dmitri Zagidulin wrote:

Didn't seem to work, the figure with no label was still placed
arbitrarily by LaTeX (and not in the exact location). (And, actually,
LaTeX placed the figure in the middle of a script block, which is really
odd).


Not a LaTeX problem. Scripts should be generated so that they cannot 
have orphans (or widows) and that includes the caption.


I want a WYSIWYG documentation system in Smalltalk. Something between
LaTeX and Framemaker.

Stephan

Re: [Pharo-dev] PetitMarkdown

[Dmitri Zagidulin]

On Thu, Apr 16, 2015 at 4:40 AM, Damien Cassou 
wrote:

> Please note that if in Pillar you don't specify any label you could
> reference from your text, then the figure will be placed by LaTeX at the
> exact location where you put it in Pillar. This is because, in this
> case, there is no way to write "as can be seen in Figure 3" when there
> is no label.


I tried that out in a recent UPBE chapter (here:
https://github.com/SquareBracketAssociates/UpdatedPharoByExample/commit/f0b13888e759a6fb0d214699e27b87a270d35697#diff-a251fe30d553e30bb3c8e091a0280d90L480
).

Didn't seem to work, the figure with no label was still placed arbitrarily
by LaTeX (and not in the exact location). (And, actually, LaTeX placed the
figure in the middle of a script block, which is really odd).

Is this an issue of the version of Pillar that the book's build tools are
using?

Re: [Pharo-dev] PetitMarkdown

[Damien Cassou]

p...@highoctane.be  writes:
> Customer opinion on the output: why are figures not where I expect them to
> be?


they are where the *reader* expects them to be :-). The author of TeX
thought that a machine can best decide where to put a figure because
when you write the TeX source you don't know where in the page a
particular figure will be placed when rendered as PDF: each time you add
a paragraph somewhere, you move everything after it.


> Most of the figures are HD screenshots. Moving them around sucks.


why?



> I'll try the no label thing. But labels are useful.


Labels (i.e., identifiers) are useful only when you reference a figure
from the text.

Captions (i.e., explaining texts) are useful to describe the figure.

> HTML export is not doing that.


yes, because HTML has not notion of page. PDF is very nice for printing
and LaTeX makes sure that figures are nicely placed on the paper. HTML
is not meant to be printed. If you print an HTML page, the result is
often ugly.


> LaTeX is an interim tool to get the PDF output. Would it be possible
> to use Artefact instead?


probably, but don't expect it to look nice because the (La)TeX authors
are experts in the domain and we are not. I already talked about that
with Olivier (on CC) and I think he agreed IIRC.


> LaTeX toolchain is *huge*.


agree.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] PetitMarkdown

[Stephan Eggermont]

On 16/04/15 12:07, p...@highoctane.be wrote:

Customer opinion on the output: why are figures not where I expect them
to be?

Most of the figures are HD screenshots. Moving them around sucks.
I'll try the no label thing. But labels are useful.
HTML export is not doing that.
LaTeX is an interim tool to get the PDF output. Would it be possible to
use Artefact instead?


Not without creating extremely ugly documentation,
at the current state of Artefact layouting.
Line breaking is primitive, support for other than base-14
fonts is missing, pngs are rendered, not embedded.


LaTeX toolchain is *huge*.


Yeah, it is. The best object model for documentation is that of
Framemaker. Current machines should be fast enough to run
something like that in Smalltalk instead of c now, 20 years later.

Stephan

Re: [Pharo-dev] PetitMarkdown

[p...@highoctane.be]

Le 16 avr. 2015 10:41, "Damien Cassou"  a écrit :
>
>
> Christophe Demarey  writes:
>
> > Le 14 avr. 2015 à 22:51, p...@highoctane.be a écrit :
> >
> >> I hate the figures not going where I want due to the LaTeX generation
in Pillar.
> >
> > There should be options to place it where you want. Maybe a pillar
expert could answer?
>
> this is not possible and, in my opinion, not desired.
>
> The following explains my reasons but requires some LaTeX knowledge to
> be understood.
>
> LaTeX does a really good job a placing figures at nice locations. For
> example, if your paragraph ends with 2 lines at the top of a page and
> you place a figure after this paragraph, LaTeX will make sure the figure
> appears at the top of a page and not after the 2 lines: this is because
> it would be ugly to have 2 lines, then a figure, then the rest of the
> text.
>
> In LaTeX, you have to make sure to always write things like "as can be
> seen in Figure 3" instead of "as can be seen in the figure below"
> because you can never be sure of the exact location of your figures.
>
> Please note that if in Pillar you don't specify any label you could
> reference from your text, then the figure will be placed by LaTeX at the
> exact location where you put it in Pillar. This is because, in this
> case, there is no way to write "as can be seen in Figure 3" when there
> is no label.

Customer opinion on the output: why are figures not where I expect them to
be?

Most of the figures are HD screenshots. Moving them around sucks.
I'll try the no label thing. But labels are useful.
HTML export is not doing that.
LaTeX is an interim tool to get the PDF output. Would it be possible to use
Artefact instead?
LaTeX toolchain is *huge*.

Phil


>
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

Re: [Pharo-dev] PetitMarkdown

[Damien Cassou]

Christophe Demarey  writes:

> Le 14 avr. 2015 à 22:51, p...@highoctane.be a écrit :
>
>> I hate the figures not going where I want due to the LaTeX generation in 
>> Pillar.
>
> There should be options to place it where you want. Maybe a pillar expert 
> could answer?

this is not possible and, in my opinion, not desired.

The following explains my reasons but requires some LaTeX knowledge to
be understood.

LaTeX does a really good job a placing figures at nice locations. For
example, if your paragraph ends with 2 lines at the top of a page and
you place a figure after this paragraph, LaTeX will make sure the figure
appears at the top of a page and not after the 2 lines: this is because
it would be ugly to have 2 lines, then a figure, then the rest of the
text.

In LaTeX, you have to make sure to always write things like "as can be
seen in Figure 3" instead of "as can be seen in the figure below"
because you can never be sure of the exact location of your figures.

Please note that if in Pillar you don't specify any label you could
reference from your text, then the figure will be placed by LaTeX at the
exact location where you put it in Pillar. This is because, in this
case, there is no way to write "as can be seen in Figure 3" when there
is no label.


-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] PetitMarkdown

[Christophe Demarey]

Le 14 avr. 2015 à 22:51, p...@highoctane.be a écrit :

> I hate the figures not going where I want due to the LaTeX generation in 
> Pillar.

There should be options to place it where you want. Maybe a pillar expert could 
answer?

> As for class comments, markdown would make more sense to use when putting 
> files under source control on git and then stored in github because filetree 
> generates README.md files for such comments.
> 
> It makes for a nice reading there. In that respect, Pillar class comments 
> will be more of a nuisance than a help.

I don't agree. We can use pillar inside the image AND we can also generate a 
README.md file from pillar doc when useful.

> For generating web documentation, it is easier to provide markdown so that 
> any web framework will be able to conver (e;g; Showdown.js and 2 lines of 
> code).

We already have a pillar to MD converter.

We will have to deal with MD time to time but you do not necessarily have to 
adopt it. You just need to have a good way to interact with it.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] PetitMarkdown

[Sven Van Caekenberghe]

I am sorry, but I don't think you really have looked at this in detail. Read

  http://en.wikipedia.org/wiki/Markdown

History & Extensions, just to known about some of the differences out there.

Any language without any formal spec is close to impossible to parse well, it 
is just hacking. Note that the original MD allows HTML inside ! WTF ?

But if it is so easy, please write your own parser. Many have tried, many have 
failed. Or go read the code of one of them.

Here is a cool attempt: 
http://www.greghendershott.com/2013/11/markdown-parser-redesign.html

The fact that github implements their own variant and made it convenient says 
nothing.

For the record, I am using MD myself.

> On 14 Apr 2015, at 23:11, Dmitri Zagidulin  wrote:
> 
> On Tue, Apr 14, 2015 at 4:10 PM, Sven Van Caekenberghe  wrote:
> 
> Furthermore, there is NO MarkDown standard, nor will there ever be. There are 
> slight but annoying differences between the main implementors.
> 
> Not true. There is at least http://spec.commonmark.org/
>  
> It is super hard to write a parser for MD.
> 
> What do you mean? Why? 
> 

Re: [Pharo-dev] PetitMarkdown

[Damien Pollet]

On 14 April 2015 at 23:11, Dmitri Zagidulin  wrote:

> It is super hard to write a parser for MD.
>>
>
> What do you mean? Why?
>

The syntax depends on indentation and block layout of text. It's very hard
to express using the usual grammar tools. In PetitMarkdown, before Jan
added indent-aware parsing to PetitParser, I was thinking of doing
multi-pass parsing, first recognizing block-level, then inline syntax.

The closest thing to a standard is John Gruber's reference implementation,
and that is a sequence of regular expression search-and-replace passes. Not
exactly what you'd call a grammar :)

Anyway… https://twitter.com/willmanduffy/status/588057382225346560

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] PetitMarkdown

[kilon alios]

Stef gets "fierce emotional" at times, he is very passionate about Pharo. I
dont think he has a problem with having a good MD parser though it looks
like that will be hard to do because of the nature of the MD syntax but his
real problem is people porting doc to MD and abandoning or not even giving
Pillar a serious try. That is something that concerns me too.

I agree with Stef that Pillar is really nice and frankly MD has little to
offer over Pillar. I also dont agree that MD is significantly more readable
than Pillar to justify choosing MD over Pillar. Also making a document
format tailor made for Pharo needs and ideology comes with its own big
benefit that may not be obvious on the short term but long term may make a
big difference.

I agree also having control over your own format is always a big benefit.

Also Pillar is not opposed to MD , quite the contrary it generates MD files
as it does HTML , LATEX and PDF files.

When I started using Pharo I also did not understand this obsession of
remaking so much technology in pharo. But now I know that the moment you
integrate something from scratch into a very powerful live environment like
Pharo it becomes a completely new thing. It becomes a live thing.  Its
definitely make the effort well worth it.  Now I am also a victim of this
"curse" ;)

I love Pillar, its super easy to learn, very easy to read and well its made
with Pharo which make it also easier to extend. Hands down a winner in my
book ;)

Go Pillar Go! :)

Ps: Help tool already support a very small part of Pillar syntax with its
wikisyntax pragma.


On Tue, Apr 14, 2015 at 11:03 PM, Dmitri Zagidulin 
wrote:

> Whoa.
> I genuinely don't understand the fierce emotions here. Why do Pillar and
> Markdown have to be opposed? Why is wanting support for better parsing of
> MD (a commonly used format around the web, and useful in many projects)
> somehow an insult to the work done on Pillar?
>
> (Incidentally, I don't quite understand why Pillar was created in the
> first place. Why have a slightly different and incompatible markdown format
> from what the rest of the world is using? But that's not the point. We have
> both, and it's easy to support both. What's the problem?)
>
>
> On Tue, Apr 14, 2015 at 3:08 PM, stepharo  wrote:
>
>>  I'm really pissed off. Because nearly nobody tried to write anything
>> with pillar and you just talk
>> about what you do not know.  But thanks this is great to see that we are
>> spending our energy for people
>> who will never even try to use what we are doing.
>> Superb!
>>
>> No need to reply I will not read this thread anymore. And I should not
>> even have because it was so obvious.
>>
>> And yes I 'm REALLY pissed off. You should also say to cyril that what is
>> is doing is hopeless because as soon
>> as we will have a stupid markdown parser suddenly it will be great. what
>> a shit.
>>
>> So go and write your documentation in any format and do not expect me to
>> look at it.
>> I'm fed up about people that want doc on the web and when we spend time
>> to migrate from latex to
>> pillar to generate html and latex do not even consider what we did.
>>
>> Stef
>>
>>  I would prefer pillar for class / packages comments
>>>
>>
>>  I was quite surprised there are any MD defendants considering the
>> pillar push. But since diversity is (often) a good think maybe having
>> something like gt-inspector there would be cool where you can add this in
>> whatever format you want. (And maybe one day someone will write pillar to
>> morphic/whatever converter and it would be even cooler.)
>>
>>It is a difficult topic. I agree with anyone that MarkDown is not a
>> good format for parsing. Pillar is the right thing to do here. But there is
>> one point of MarkDown that is hard to beat. A MarkDown text is always good
>> to read, eben while writing. In something like a class comment it would be
>> easy to use. What we don't want is to write system documentation in a
>> format that you need to convert first before you can see the result. It is
>> either having a wysiwyg editor for those things with pillar below or a
>> simple format that can both.
>>
>>
>>  my 2 cents,
>>
>>
>>
>>  that’s actually my main point too, yes.
>>
>>  Esteban
>>
>>
>>  norbert
>>
>>
>>
>>
>

Re: [Pharo-dev] PetitMarkdown

[Dmitri Zagidulin]

On Tue, Apr 14, 2015 at 9:21 AM, Jan Kurš  wrote:

> If there is an interest to use PetitParser/CommonMark in Pharo, I can
> spend some time on it. I guess, I would be able to parse majority of the
> examples (I am not sure about all the corner cases).
>

That would be fantastic!
In general, even regardless of the use case of using MD for in-Pharo
documentation, the ability to parse Markdown is pretty fundamental to a
programming language (behind only JSON, XML, and CSV).

Re: [Pharo-dev] PetitMarkdown

[Dmitri Zagidulin]

On Tue, Apr 14, 2015 at 4:10 PM, Sven Van Caekenberghe  wrote:

>
> Furthermore, there is NO MarkDown standard, nor will there ever be. There
> are slight but annoying differences between the main implementors.


Not true. There is at least http://spec.commonmark.org/


> It is super hard to write a parser for MD.
>

What do you mean? Why?

Re: [Pharo-dev] PetitMarkdown

[p...@highoctane.be]

Some should cool down.

I am using Pillar to write my (internal) docs.
And I use markdown too.

Both have their uses.

Compared to things like RMarkdown, knitr, and RPubs in the R community,
what we do have is passable in terms of output. We have a small community,
we have to deal with that fact.

I hate the figures not going where I want due to the LaTeX generation in
Pillar.

As for class comments, markdown would make more sense to use when putting
files under source control on git and then stored in github because
filetree generates README.md files for such comments.

It makes for a nice reading there. In that respect, Pillar class comments
will be more of a nuisance than a help.

For generating web documentation, it is easier to provide markdown so that
any web framework will be able to convert (e;g; Showdown.js and 2 lines of
code).

Furthermore, a lot of Pillar files embed non pillar markup for special
things.

For me, Pillar is for the books. And speciality applications that use the
visitors to produce other stuff (among which Markdown).

As for writing stuff, I do md and pillar files in Vim. So much for specific
tools that weren't satisfying when writing. Too slow, too cumbersome, not
enough power for editing (compared to Vim, yeah, nothing comes close in
terms of speed once you know the tricks).

Phil



On Tue, Apr 14, 2015 at 10:03 PM, Dmitri Zagidulin 
wrote:

> Whoa.
> I genuinely don't understand the fierce emotions here. Why do Pillar and
> Markdown have to be opposed? Why is wanting support for better parsing of
> MD (a commonly used format around the web, and useful in many projects)
> somehow an insult to the work done on Pillar?
>
> (Incidentally, I don't quite understand why Pillar was created in the
> first place. Why have a slightly different and incompatible markdown format
> from what the rest of the world is using? But that's not the point. We have
> both, and it's easy to support both. What's the problem?)
>
>
> On Tue, Apr 14, 2015 at 3:08 PM, stepharo  wrote:
>
>>  I'm really pissed off. Because nearly nobody tried to write anything
>> with pillar and you just talk
>> about what you do not know.  But thanks this is great to see that we are
>> spending our energy for people
>> who will never even try to use what we are doing.
>> Superb!
>>
>> No need to reply I will not read this thread anymore. And I should not
>> even have because it was so obvious.
>>
>> And yes I 'm REALLY pissed off. You should also say to cyril that what is
>> is doing is hopeless because as soon
>> as we will have a stupid markdown parser suddenly it will be great. what
>> a shit.
>>
>> So go and write your documentation in any format and do not expect me to
>> look at it.
>> I'm fed up about people that want doc on the web and when we spend time
>> to migrate from latex to
>> pillar to generate html and latex do not even consider what we did.
>>
>> Stef
>>
>>  I would prefer pillar for class / packages comments
>>>
>>
>>  I was quite surprised there are any MD defendants considering the
>> pillar push. But since diversity is (often) a good think maybe having
>> something like gt-inspector there would be cool where you can add this in
>> whatever format you want. (And maybe one day someone will write pillar to
>> morphic/whatever converter and it would be even cooler.)
>>
>>It is a difficult topic. I agree with anyone that MarkDown is not a
>> good format for parsing. Pillar is the right thing to do here. But there is
>> one point of MarkDown that is hard to beat. A MarkDown text is always good
>> to read, eben while writing. In something like a class comment it would be
>> easy to use. What we don't want is to write system documentation in a
>> format that you need to convert first before you can see the result. It is
>> either having a wysiwyg editor for those things with pillar below or a
>> simple format that can both.
>>
>>
>>  my 2 cents,
>>
>>
>>
>>  that’s actually my main point too, yes.
>>
>>  Esteban
>>
>>
>>  norbert
>>
>>
>>
>>
>


-

Re: [Pharo-dev] PetitMarkdown

[Sven Van Caekenberghe]

> On 14 Apr 2015, at 22:03, Dmitri Zagidulin  wrote:
> 
> Whoa. 
> I genuinely don't understand the fierce emotions here. Why do Pillar and 
> Markdown have to be opposed? Why is wanting support for better parsing of MD 
> (a commonly used format around the web, and useful in many projects) somehow 
> an insult to the work done on Pillar?
> 
> (Incidentally, I don't quite understand why Pillar was created in the first 
> place. Why have a slightly different and incompatible markdown format from 
> what the rest of the world is using? But that's not the point. We have both, 
> and it's easy to support both. What's the problem?)

Communication is always an issue, especially for newcomers.

Pillar was chosen because it is our format, something we control and define, 
something we can extend anyway we want, not somebody else's format that we can 
only follow.

Incidentally, Pillar precedes MarkDown by years.

Furthermore, there is NO MarkDown standard, nor will there ever be. There are 
slight but annoying differences between the main implementors. It is super hard 
to write a parser for MD.

Anyway, IMHO, the key thing is the underlying document model.

> On Tue, Apr 14, 2015 at 3:08 PM, stepharo  wrote:
> I'm really pissed off. Because nearly nobody tried to write anything with 
> pillar and you just talk 
> about what you do not know.  But thanks this is great to see that we are 
> spending our energy for people 
> who will never even try to use what we are doing. 
> Superb!
> 
> No need to reply I will not read this thread anymore. And I should not even 
> have because it was so obvious.
> 
> And yes I 'm REALLY pissed off. You should also say to cyril that what is is 
> doing is hopeless because as soon 
> as we will have a stupid markdown parser suddenly it will be great. what a 
> shit.
> 
> So go and write your documentation in any format and do not expect me to look 
> at it.
> I'm fed up about people that want doc on the web and when we spend time to 
> migrate from latex to 
> pillar to generate html and latex do not even consider what we did. 
> 
> Stef
> 
 I would prefer pillar for class / packages comments
 
 I was quite surprised there are any MD defendants considering the pillar 
 push. But since diversity is (often) a good think maybe having something 
 like gt-inspector there would be cool where you can add this in whatever 
 format you want. (And maybe one day someone will write pillar to 
 morphic/whatever converter and it would be even cooler.)
 
>>> It is a difficult topic. I agree with anyone that MarkDown is not a good 
>>> format for parsing. Pillar is the right thing to do here. But there is one 
>>> point of MarkDown that is hard to beat. A MarkDown text is always good to 
>>> read, eben while writing. In something like a class comment it would be 
>>> easy to use. What we don't want is to write system documentation in a 
>>> format that you need to convert first before you can see the result. It is 
>>> either having a wysiwyg editor for those things with pillar below or a 
>>> simple format that can both.
>>> 
>>> my 2 cents,
>> 
>> 
>> that’s actually my main point too, yes. 
>> 
>> Esteban
>> 
>>> 
>>> norbert
>> 
> 
> 

Re: [Pharo-dev] PetitMarkdown

[Dmitri Zagidulin]

Whoa.
I genuinely don't understand the fierce emotions here. Why do Pillar and
Markdown have to be opposed? Why is wanting support for better parsing of
MD (a commonly used format around the web, and useful in many projects)
somehow an insult to the work done on Pillar?

(Incidentally, I don't quite understand why Pillar was created in the first
place. Why have a slightly different and incompatible markdown format from
what the rest of the world is using? But that's not the point. We have
both, and it's easy to support both. What's the problem?)


On Tue, Apr 14, 2015 at 3:08 PM, stepharo  wrote:

>  I'm really pissed off. Because nearly nobody tried to write anything with
> pillar and you just talk
> about what you do not know.  But thanks this is great to see that we are
> spending our energy for people
> who will never even try to use what we are doing.
> Superb!
>
> No need to reply I will not read this thread anymore. And I should not
> even have because it was so obvious.
>
> And yes I 'm REALLY pissed off. You should also say to cyril that what is
> is doing is hopeless because as soon
> as we will have a stupid markdown parser suddenly it will be great. what a
> shit.
>
> So go and write your documentation in any format and do not expect me to
> look at it.
> I'm fed up about people that want doc on the web and when we spend time to
> migrate from latex to
> pillar to generate html and latex do not even consider what we did.
>
> Stef
>
>  I would prefer pillar for class / packages comments
>>
>
>  I was quite surprised there are any MD defendants considering the pillar
> push. But since diversity is (often) a good think maybe having something
> like gt-inspector there would be cool where you can add this in whatever
> format you want. (And maybe one day someone will write pillar to
> morphic/whatever converter and it would be even cooler.)
>
>It is a difficult topic. I agree with anyone that MarkDown is not a
> good format for parsing. Pillar is the right thing to do here. But there is
> one point of MarkDown that is hard to beat. A MarkDown text is always good
> to read, eben while writing. In something like a class comment it would be
> easy to use. What we don't want is to write system documentation in a
> format that you need to convert first before you can see the result. It is
> either having a wysiwyg editor for those things with pillar below or a
> simple format that can both.
>
>
>  my 2 cents,
>
>
>
>  that’s actually my main point too, yes.
>
>  Esteban
>
>
>  norbert
>
>
>
>

Re: [Pharo-dev] PetitMarkdown

[Tudor Girba]

Hi,

MD is a cool exercise for PetitParser exactly because it is a terrible
language. Jan did a great job at pushing parsing limits, but that does not
mean that we have to jump on it to use it inside Pharo :).

Actually, at this point in time, I really do not quite understand why we
are still entertaining the idea of MD inside Pharo given all the effort for
documenting using Pillar.

In any case, as you might know, there already exists support for editing
Pillar from inside Pharo (
http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspector/),
and we will likely develop significantly this support in the IDE.

Cheers,
Doru



On Tue, Apr 14, 2015 at 9:08 PM, stepharo  wrote:

>  I'm really pissed off. Because nearly nobody tried to write anything with
> pillar and you just talk
> about what you do not know.  But thanks this is great to see that we are
> spending our energy for people
> who will never even try to use what we are doing.
> Superb!
>
> No need to reply I will not read this thread anymore. And I should not
> even have because it was so obvious.
>
> And yes I 'm REALLY pissed off. You should also say to cyril that what is
> is doing is hopeless because as soon
> as we will have a stupid markdown parser suddenly it will be great. what a
> shit.
>
> So go and write your documentation in any format and do not expect me to
> look at it.
> I'm fed up about people that want doc on the web and when we spend time to
> migrate from latex to
> pillar to generate html and latex do not even consider what we did.
>
> Stef
>
>  I would prefer pillar for class / packages comments
>>
>
>  I was quite surprised there are any MD defendants considering the pillar
> push. But since diversity is (often) a good think maybe having something
> like gt-inspector there would be cool where you can add this in whatever
> format you want. (And maybe one day someone will write pillar to
> morphic/whatever converter and it would be even cooler.)
>
>It is a difficult topic. I agree with anyone that MarkDown is not a
> good format for parsing. Pillar is the right thing to do here. But there is
> one point of MarkDown that is hard to beat. A MarkDown text is always good
> to read, eben while writing. In something like a class comment it would be
> easy to use. What we don't want is to write system documentation in a
> format that you need to convert first before you can see the result. It is
> either having a wysiwyg editor for those things with pillar below or a
> simple format that can both.
>
>
>  my 2 cents,
>
>
>
>  that’s actually my main point too, yes.
>
>  Esteban
>
>
>  norbert
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] PetitMarkdown

[stepharo]

I'm really pissed off. Because nearly nobody tried to write anything 
with pillar and you just talk
about what you do not know.  But thanks this is great to see that we are 
spending our energy for people

who will never even try to use what we are doing.
Superb!

No need to reply I will not read this thread anymore. And I should not 
even have because it was so obvious.


And yes I 'm REALLY pissed off. You should also say to cyril that what 
is is doing is hopeless because as soon
as we will have a stupid markdown parser suddenly it will be great. what 
a shit.


So go and write your documentation in any format and do not expect me to 
look at it.
I'm fed up about people that want doc on the web and when we spend time 
to migrate from latex to

pillar to generate html and latex do not even consider what we did.

Stef


I would prefer pillar for class / packages comments


I was quite surprised there are any MD defendants considering the 
pillar push. But since diversity is (often) a good think maybe 
having something like gt-inspector there would be cool where you can 
add this in whatever format you want. (And maybe one day someone 
will write pillar to morphic/whatever converter and it would be even 
cooler.)


It is a difficult topic. I agree with anyone that MarkDown is not a 
good format for parsing. Pillar is the right thing to do here. But 
there is one point of MarkDown that is hard to beat. A MarkDown text 
is always good to read, eben while writing. In something like a class 
comment it would be easy to use. What we don't want is to write 
system documentation in a format that you need to convert first 
before you can see the result. It is either having a wysiwyg editor 
for those things with pillar below or a simple format that can both.


my 2 cents,



that’s actually my main point too, yes.

Esteban



norbert

Re: [Pharo-dev] PetitMarkdown

[stepharo]

Le 14/4/15 11:43, Esteban Lorenzano a écrit :

how complete it is?
we would really like to think on:

1) include petitparser in Pharo
2) allow the writing of class docs in MD format :)


seriously?
With all the efforts and that damien and me are spending on pillar!
Thanks a lot for your consideration



of course, we are talking about the not-so-near future, but is an idea 
we are thinking about… :P


and in any case, I would like to use a good MD parser for my own stuff :)

Esteban

On 14 Apr 2015, at 10:42, Jan Kurš > wrote:


Hey,

I also created an indentation sensitive extension of PetitParser, I 
also included some examples including Markdown. If you load 
PetitParser, you get the Markdown example as well.


There is a short introduction to the indentation:

http://scg.unibe.ch/research/indentParsing

Cheers Jan

On Apr 13, 2015 5:24 PM, "H. Hirzel" > wrote:


Are there any news on this?

--Hannes

On 12/28/14, Norbert Hartl mailto:norb...@hartl.name>> wrote:
> I found markdown parsers in smalltalkhub and in the
configuration browser.
>
> http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/

> >
>
> and the one in the configuration browser
>
> PPMarkdown
>
> If I understand it correctly both are rooted into work Camillo
did. The one
> in PharoExtras looks newer to me. So I assume the best would be
to copy the
> ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo
and remove
> the ConfigurationOfPPMarkdown. Right? Or are there any objections?
>
> Norbert

Re: [Pharo-dev] PetitMarkdown

[Esteban Lorenzano]

> On 14 Apr 2015, at 15:51, Norbert Hartl  wrote:
> 
>> 
>> Am 14.04.2015 um 14:24 schrieb Peter Uhnák > >:
>> 
>> On Tue, Apr 14, 2015 at 2:19 PM, Christophe Demarey 
>> mailto:christophe.dema...@inria.fr>> wrote:
>> 
>> Le 14 avr. 2015 à 11:43, Esteban Lorenzano a écrit :
>> 
>> > how complete it is?
>> > we would really like to think on:
>> >
>> > 1) include petitparser in Pharo
>> > 2) allow the writing of class docs in MD format :)
>> 
>> I would prefer pillar for class / packages comments
>> 
>> I was quite surprised there are any MD defendants considering the pillar 
>> push. But since diversity is (often) a good think maybe having something 
>> like gt-inspector there would be cool where you can add this in whatever 
>> format you want. (And maybe one day someone will write pillar to 
>> morphic/whatever converter and it would be even cooler.)
>> 
> It is a difficult topic. I agree with anyone that MarkDown is not a good 
> format for parsing. Pillar is the right thing to do here. But there is one 
> point of MarkDown that is hard to beat. A MarkDown text is always good to 
> read, eben while writing. In something like a class comment it would be easy 
> to use. What we don't want is to write system documentation in a format that 
> you need to convert first before you can see the result. It is either having 
> a wysiwyg editor for those things with pillar below or a simple format that 
> can both.
> 
> my 2 cents,


that’s actually my main point too, yes. 

Esteban

> 
> norbert

Re: [Pharo-dev] PetitMarkdown

[Norbert Hartl]

> Am 14.04.2015 um 14:24 schrieb Peter Uhnák :
> 
> On Tue, Apr 14, 2015 at 2:19 PM, Christophe Demarey 
> mailto:christophe.dema...@inria.fr>> wrote:
> 
> Le 14 avr. 2015 à 11:43, Esteban Lorenzano a écrit :
> 
> > how complete it is?
> > we would really like to think on:
> >
> > 1) include petitparser in Pharo
> > 2) allow the writing of class docs in MD format :)
> 
> I would prefer pillar for class / packages comments
> 
> I was quite surprised there are any MD defendants considering the pillar 
> push. But since diversity is (often) a good think maybe having something like 
> gt-inspector there would be cool where you can add this in whatever format 
> you want. (And maybe one day someone will write pillar to morphic/whatever 
> converter and it would be even cooler.)
> 
It is a difficult topic. I agree with anyone that MarkDown is not a good format 
for parsing. Pillar is the right thing to do here. But there is one point of 
MarkDown that is hard to beat. A MarkDown text is always good to read, eben 
while writing. In something like a class comment it would be easy to use. What 
we don't want is to write system documentation in a format that you need to 
convert first before you can see the result. It is either having a wysiwyg 
editor for those things with pillar below or a simple format that can both.

my 2 cents,

norbert

Re: [Pharo-dev] PetitMarkdown

[Jan Kurš]

Regarding completeness, it is not great. It was implement with an emphasiz
on the indentation/prefix-related part (the hard one, I hope) so quoted
blocks and and lists are almost complete (with arbitrary nesting). I did
not need the other stuff, so there is a basic support for headers,
paragraphs and code blocks. I followed the commonmark spec (
http://spec.commonmark.org/0.17/).

If there is an interest to use PetitParser/CommonMark in Pharo, I can spend
some time on it. I guess, I would be able to parse majority of the examples
(I am not sure about all the corner cases).

Cheers,
Jan

On 14 April 2015 at 14:24, Peter Uhnák  wrote:

> On Tue, Apr 14, 2015 at 2:19 PM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>>
>> Le 14 avr. 2015 à 11:43, Esteban Lorenzano a écrit :
>>
>> > how complete it is?
>> > we would really like to think on:
>> >
>> > 1) include petitparser in Pharo
>> > 2) allow the writing of class docs in MD format :)
>>
>> I would prefer pillar for class / packages comments
>>
>
> I was quite surprised there are any MD defendants considering the pillar
> push. But since diversity is (often) a good think maybe having something
> like gt-inspector there would be cool where you can add this in whatever
> format you want. (And maybe one day someone will write pillar to
> morphic/whatever converter and it would be even cooler.)
>
> Peter
>
>
>

Re: [Pharo-dev] PetitMarkdown

[Peter Uhnák]

On Tue, Apr 14, 2015 at 2:19 PM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

>
> Le 14 avr. 2015 à 11:43, Esteban Lorenzano a écrit :
>
> > how complete it is?
> > we would really like to think on:
> >
> > 1) include petitparser in Pharo
> > 2) allow the writing of class docs in MD format :)
>
> I would prefer pillar for class / packages comments
>

I was quite surprised there are any MD defendants considering the pillar
push. But since diversity is (often) a good think maybe having something
like gt-inspector there would be cool where you can add this in whatever
format you want. (And maybe one day someone will write pillar to
morphic/whatever converter and it would be even cooler.)

Peter

Re: [Pharo-dev] PetitMarkdown

[Christophe Demarey]

Le 14 avr. 2015 à 11:43, Esteban Lorenzano a écrit :

> how complete it is?
> we would really like to think on: 
> 
> 1) include petitparser in Pharo 
> 2) allow the writing of class docs in MD format :)

I would prefer pillar for class / packages comments



smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] PetitMarkdown

[Damien Pollet]

+1

PetitMarkdown (at least in the state I left it) had an incomplete and
contorted grammar, translated from another implementation (the one used by
pandoc, I think). I started something to handle indentation, but meh. Jan's
extension of PetitParser is the way to go, and it should make the grammar
way more readable.

On 14 April 2015 at 11:43, Esteban Lorenzano  wrote:

> how complete it is?
> we would really like to think on:
>
> 1) include petitparser in Pharo
> 2) allow the writing of class docs in MD format :)
>
> of course, we are talking about the not-so-near future, but is an idea we
> are thinking about… :P
>
> and in any case, I would like to use a good MD parser for my own stuff :)
>
> Esteban
>
> On 14 Apr 2015, at 10:42, Jan Kurš  wrote:
>
> Hey,
>
> I also created an indentation sensitive extension of PetitParser, I also
> included some examples including Markdown. If you load PetitParser, you get
> the Markdown example as well.
>
> There is a short introduction to the indentation:
>
> http://scg.unibe.ch/research/indentParsing
>
> Cheers Jan
> On Apr 13, 2015 5:24 PM, "H. Hirzel"  wrote:
>
>> Are there any news on this?
>>
>> --Hannes
>>
>> On 12/28/14, Norbert Hartl  wrote:
>> > I found markdown parsers in smalltalkhub and in the configuration
>> browser.
>> >
>> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
>> > 
>> >
>> > and the one in the configuration browser
>> >
>> > PPMarkdown
>> >
>> > If I understand it correctly both are rooted into work Camillo did. The
>> one
>> > in PharoExtras looks newer to me. So I assume the best would be to copy
>> the
>> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and
>> remove
>> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
>> >
>> > Norbert
>>
>>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] PetitMarkdown

[Esteban Lorenzano]

how complete it is?
we would really like to think on: 

1) include petitparser in Pharo 
2) allow the writing of class docs in MD format :)

of course, we are talking about the not-so-near future, but is an idea we are 
thinking about… :P

and in any case, I would like to use a good MD parser for my own stuff :)

Esteban

> On 14 Apr 2015, at 10:42, Jan Kurš  wrote:
> 
> Hey,
> 
> I also created an indentation sensitive extension of PetitParser, I also 
> included some examples including Markdown. If you load PetitParser, you get 
> the Markdown example as well.
> 
> There is a short introduction to the indentation:
> 
> http://scg.unibe.ch/research/indentParsing 
> 
> Cheers Jan
> 
> On Apr 13, 2015 5:24 PM, "H. Hirzel"  > wrote:
> Are there any news on this?
> 
> --Hannes
> 
> On 12/28/14, Norbert Hartl mailto:norb...@hartl.name>> 
> wrote:
> > I found markdown parsers in smalltalkhub and in the configuration browser.
> >
> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/ 
> > 
> >  > >
> >
> > and the one in the configuration browser
> >
> > PPMarkdown
> >
> > If I understand it correctly both are rooted into work Camillo did. The one
> > in PharoExtras looks newer to me. So I assume the best would be to copy the
> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and remove
> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
> >
> > Norbert
> 

Re: [Pharo-dev] PetitMarkdown

[Jan Kurš]

Hey,

I also created an indentation sensitive extension of PetitParser, I also
included some examples including Markdown. If you load PetitParser, you get
the Markdown example as well.

There is a short introduction to the indentation:

http://scg.unibe.ch/research/indentParsing

Cheers Jan
On Apr 13, 2015 5:24 PM, "H. Hirzel"  wrote:

> Are there any news on this?
>
> --Hannes
>
> On 12/28/14, Norbert Hartl  wrote:
> > I found markdown parsers in smalltalkhub and in the configuration
> browser.
> >
> > http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
> > 
> >
> > and the one in the configuration browser
> >
> > PPMarkdown
> >
> > If I understand it correctly both are rooted into work Camillo did. The
> one
> > in PharoExtras looks newer to me. So I assume the best would be to copy
> the
> > ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and remove
> > the ConfigurationOfPPMarkdown. Right? Or are there any objections?
> >
> > Norbert
>
>

Re: [Pharo-dev] PetitMarkdown

[H. Hirzel]

Are there any news on this?

--Hannes

On 12/28/14, Norbert Hartl  wrote:
> I found markdown parsers in smalltalkhub and in the configuration browser.
>
> http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/
> 
>
> and the one in the configuration browser
>
> PPMarkdown
>
> If I understand it correctly both are rooted into work Camillo did. The one
> in PharoExtras looks newer to me. So I assume the best would be to copy the
> ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and remove
> the ConfigurationOfPPMarkdown. Right? Or are there any objections?
>
> Norbert

Re: [Pharo-dev] PetitMarkdown and pillar

[Damien Cassou]

On Sun, Dec 28, 2014 at 6:05 PM, Norbert Hartl  wrote:
> The markdown parser of PetitMarkdown looks pretty decent. Is there any code 
> that converts markdown nodes to pillar ones?


I've never heard of anything like that.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

[Pharo-dev] PetitMarkdown and pillar

[Norbert Hartl]

The markdown parser of PetitMarkdown looks pretty decent. Is there any code 
that converts markdown nodes to pillar ones?

thanks,

Norbert

[Pharo-dev] PetitMarkdown

[Norbert Hartl]

I found markdown parsers in smalltalkhub and in the configuration browser. 

http://smalltalkhub.com/#!/~PharoExtras/PetitMarkdown/ 


and the one in the configuration browser

PPMarkdown

If I understand it correctly both are rooted into work Camillo did. The one in 
PharoExtras looks newer to me. So I assume the best would be to copy the 
ConfigurationOfPetitMarkdown from PharoExtras to MetacelloRepo and remove the 
ConfigurationOfPPMarkdown. Right? Or are there any objections?

Norbert