Markdown for AMP Project https://www.ampproject.org/

Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

[-- Attachment #1.1: Type: text/plain, Size: 1123 bytes --]

I would like to know if some configuration file may be used for Pandoc to 
generate AMP HTML pages. As that is what in the markdown world is missing. 
I think Pandoc is the one prospect variety that may accomplish that task.

AMP pages are accelerated pages that contribute to the content publishing.

Major problem is the adaptation to AMP HTML tags:
https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md

If such solution already exists, let me know.

If there exist possibility to make it, that would be best idea. 

Jean Louis

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/74722d2b-3362-48e3-a0b4-fa4502bc8005%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1570 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]



AFAIK I didn’t see people doing this (but I could be wrong). Just to point 
out some problems of AMP:

   - Daring Fireball: The Problem With AMP 
   <https://daringfireball.net/linked/2017/01/17/schreiber-amp> 
   - The Guardian pulls out of Facebook’s Instant Articles and Apple News - 
   Digiday 
   <http://digiday.com/media/guardian-pulls-facebooks-instant-articles-apple-news/> 
   (I read the news somewhere else and googled this for your reference) 

The 2nd news seems to suggest that AMP is doing better among the 3. But the 
point is that all 3 efforts are about lock-in, and who knows in 10 years if 
it will still be there (in contrast with other formats that pandoc 
supports).

For big news companies they can afford throwing a lot of resources to test 
the water and reap near-term benefits. But for indie publishing and 
open-source projects, you might not have the resource to do so, and if you 
do, the resource might be best spent somewhere else. (It also depends on 
how much effort is needed. For experienced pandoc developer, it might not 
be a lot. The question is if you can find experienced pandoc developer who 
is interested in this, or if you’re willing to be that one.)
​

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/436da55e-15b1-4571-8716-bc35ae061e22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 4586 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

[-- Attachment #1.1: Type: text/plain, Size: 937 bytes --]

On Sunday, April 30, 2017 at 2:04:45 AM UTC+3, Kolen Cheung wrote:
>
> AFAIK I didn’t see people doing this (but I could be wrong). Just to point 
> out some problems of AMP:
>
>    - Daring Fireball: The Problem With AMP 
>    <https://daringfireball.net/linked/2017/01/17/schreiber-amp>
>
> I agree on those considerations. Closed case for me. 

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/3ec5c6ae-f370-4c7f-a582-319ca909ede9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 2478 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 2366 bytes --]



Oh, I don’t expect it to be so effective. (Perhaps that’s why John Gruber 
is *the* indie blogger, and the creator of markdown.)

Going back to accelerating pages in general, pandoc’s output is already 
very “accelerated”, meaning that it is very minimal and static.

Of course when you design a website, you will add your own js and css on 
top of pandoc’s output, and also add some banners / headers / etc.

The key of AMP is that they don’t allow js (apart from many other good 
practices). So you can mimic that too.

One interesting point is that if you use Google Analytics, Google Ads, 
Google Search, etc., they insert js to your page. (I don’t study AMP enough 
to see how they handle this.). So do DISQUS, and Facebook/Twitter badges, 
etc. If you googled it, people has suggested not to use the official 
provided badges but create your own static one (just an image with link).

Another note is that if you want to include Math in your webpage, where 
pandoc can handles it well, you might want to avoid using MathJax but some 
other solutions. Good alternatives are the --webtex, or jgm/pandoc-tex2svg: 
Pandoc filter to convert math to SVG using MathJax-node’s tex2svg 
<https://github.com/jgm/pandoc-tex2svg>, which makes the equations static.

On Saturday, April 29, 2017 at 5:01:31 PM UTC-7, supp…-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org wrote:

On Sunday, April 30, 2017 at 2:04:45 AM UTC+3, Kolen Cheung wrote:
>>
>> AFAIK I didn’t see people doing this (but I could be wrong). Just to 
>> point out some problems of AMP:
>>
>>    - Daring Fireball: The Problem With AMP 
>>    <https://daringfireball.net/linked/2017/01/17/schreiber-amp>
>>
>> I agree on those considerations. Closed case for me. 
>
​

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/ca2d1fee-a395-490e-a5e2-8d1142691356%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 9253 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 2783 bytes --]



By the way, PageSpeed Insights 
<https://developers.google.com/speed/pagespeed/insights/> can be useful to 
hunt down problems that makes your webpage slow. But don’t blindly follow 
all its advice. Some can never be fulfilled, or too compromised depending 
on your need.

On Saturday, April 29, 2017 at 5:26:42 PM UTC-7, Kolen Cheung wrote:

Oh, I don’t expect it to be so effective. (Perhaps that’s why John Gruber 
> is *the* indie blogger, and the creator of markdown.)
>
> Going back to accelerating pages in general, pandoc’s output is already 
> very “accelerated”, meaning that it is very minimal and static.
>
> Of course when you design a website, you will add your own js and css on 
> top of pandoc’s output, and also add some banners / headers / etc.
>
> The key of AMP is that they don’t allow js (apart from many other good 
> practices). So you can mimic that too.
>
> One interesting point is that if you use Google Analytics, Google Ads, 
> Google Search, etc., they insert js to your page. (I don’t study AMP enough 
> to see how they handle this.). So do DISQUS, and Facebook/Twitter badges, 
> etc. If you googled it, people has suggested not to use the official 
> provided badges but create your own static one (just an image with link).
>
> Another note is that if you want to include Math in your webpage, where 
> pandoc can handles it well, you might want to avoid using MathJax but some 
> other solutions. Good alternatives are the --webtex, or jgm/pandoc-tex2svg: 
> Pandoc filter to convert math to SVG using MathJax-node’s tex2svg 
> <https://github.com/jgm/pandoc-tex2svg>, which makes the equations static.
>
> On Saturday, April 29, 2017 at 5:01:31 PM UTC-7, supp…-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org wrote:
>
> On Sunday, April 30, 2017 at 2:04:45 AM UTC+3, Kolen Cheung wrote:
>>>
>>> AFAIK I didn’t see people doing this (but I could be wrong). Just to 
>>> point out some problems of AMP:
>>>
>>>    - Daring Fireball: The Problem With AMP 
>>>    <https://daringfireball.net/linked/2017/01/17/schreiber-amp>
>>>
>>> I agree on those considerations. Closed case for me. 
>>
> ​
>
​

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/aefedaf2-8b5f-48a4-ab4f-b64ef59390f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 23370 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1: Type: text/plain, Size: 3955 bytes --]

By the way, the "cleanup" notebook in the experiment branch is a pure
python version of the code which do not requires weave.

On Sat, Apr 29, 2017 at 5:28 PM, Kolen Cheung <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:

> By the way, PageSpeed Insights
> <https://developers.google.com/speed/pagespeed/insights/> can be useful
> to hunt down problems that makes your webpage slow. But don’t blindly
> follow all its advice. Some can never be fulfilled, or too compromised
> depending on your need.
>
> On Saturday, April 29, 2017 at 5:26:42 PM UTC-7, Kolen Cheung wrote:
>
> Oh, I don’t expect it to be so effective. (Perhaps that’s why John Gruber
>> is *the* indie blogger, and the creator of markdown.)
>>
>> Going back to accelerating pages in general, pandoc’s output is already
>> very “accelerated”, meaning that it is very minimal and static.
>>
>> Of course when you design a website, you will add your own js and css on
>> top of pandoc’s output, and also add some banners / headers / etc.
>>
>> The key of AMP is that they don’t allow js (apart from many other good
>> practices). So you can mimic that too.
>>
>> One interesting point is that if you use Google Analytics, Google Ads,
>> Google Search, etc., they insert js to your page. (I don’t study AMP enough
>> to see how they handle this.). So do DISQUS, and Facebook/Twitter badges,
>> etc. If you googled it, people has suggested not to use the official
>> provided badges but create your own static one (just an image with link).
>>
>> Another note is that if you want to include Math in your webpage, where
>> pandoc can handles it well, you might want to avoid using MathJax but some
>> other solutions. Good alternatives are the --webtex, or jgm/pandoc-tex2svg:
>> Pandoc filter to convert math to SVG using MathJax-node’s tex2svg
>> <https://github.com/jgm/pandoc-tex2svg>, which makes the equations
>> static.
>>
>> On Saturday, April 29, 2017 at 5:01:31 PM UTC-7, supp…-ZohPw8X7yHRhl2p70BpVqQ@public.gmane.orgm wrote:
>>
>> On Sunday, April 30, 2017 at 2:04:45 AM UTC+3, Kolen Cheung wrote:
>>>>
>>>> AFAIK I didn’t see people doing this (but I could be wrong). Just to
>>>> point out some problems of AMP:
>>>>
>>>>    - Daring Fireball: The Problem With AMP
>>>>    <https://daringfireball.net/linked/2017/01/17/schreiber-amp>
>>>>
>>>> I agree on those considerations. Closed case for me.
>>>
>> ​
>>
> ​
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pandoc-discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/pandoc-discuss/uzEEUzQAvMw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/pandoc-discuss/aefedaf2-8b5f-48a4-ab4f-b64ef59390f7%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/aefedaf2-8b5f-48a4-ab4f-b64ef59390f7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAOX6kG6cKJ5G7V4LeDQuvqKBZXmKKJouEXoer9DpBHrWa7Co%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 25293 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

[-- Attachment #1.1: Type: text/plain, Size: 950 bytes --]

I was researching AMP pages from the view point of alternate exposure in 
search engines. Not from the view point of making page faster.

The AMP pages get priority in Google, as cache pages, they show up faster. 

My doubt was the Google's cache, as people would not come to the original 
URL, but to Google's URL. And in long term, I don't think Google shall get 
that power.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/c45270dd-d9c6-4ac8-9d1d-84652642bc6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1387 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 2000 bytes --]

First, I apologize sending a wrong email to this thread (the one mentioning 
cleanup branch and weave...)... I didn't realize it until you send one more 
message.

Oh, right, yes AMP does get higher page rank. But by how much? And how high 
it will becomes to make the rank relevant? Who are your competitors, such 
that a similar search would have involve another blogs/sites such that they 
have the budget to develop a separate version of their website in AMP?

I'm just reiterating the point that only those who has fat budget might be 
able to deliver AMP in addition to what they were already delivering, and 
those may only have minor overlap with your articles. And then let say it 
move your article from rank 1000000 to rank 10000, would that be relevant? 
Only when you are so popular to be able to land on the first page of the 
search, you might need to worry about any potential benefits of page rank 
from AMP.

On Saturday, April 29, 2017 at 10:42:14 PM UTC-7, supp...-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org wrote:
>
> I was researching AMP pages from the view point of alternate exposure in 
> search engines. Not from the view point of making page faster.
>
> The AMP pages get priority in Google, as cache pages, they show up faster. 
>
> My doubt was the Google's cache, as people would not come to the original 
> URL, but to Google's URL. And in long term, I don't think Google shall get 
> that power.
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/886bb176-054d-4e41-ba2e-7058e30ad355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 2648 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

[-- Attachment #1.1: Type: text/plain, Size: 3439 bytes --]

Alright, I asked for AMP configuration (I was thinking something like Lua 
or whatever is possible to configure pandoc), and I assume there is none 
such. I wish to get one in future, if anybody makes it.

On Monday, May 1, 2017 at 1:07:56 AM UTC+3, Kolen Cheung wrote:

> Oh, right, yes AMP does get higher page rank. But by how much? And how 
> high it will becomes to make the rank relevant? Who are your competitors, 
> such that a similar search would have involve another blogs/sites such that 
> they have the budget to develop a separate version of their website in AMP?
>

My understanding is that similar text published as AMP may get better 
exposure, faster loading, thus faster publishing through Google, and this 
in turn may bring new clients, and more business. 

When I am using markdown to generate HTML pages, the extra budget to 
develop a separate AMP page for thousands of pages is just the web space 
expense, plus some little adaptation, to run markdown twice, the second 
time to create the AMP page. 

Because some tags are different, pandoc is for me the only markdown variety 
that may produce such result. I did not study myself the Lua configuration 
yet to be able to make it myself.

As simple as that. 

I'm just reiterating the point that only those who has fat budget might be 
> able to deliver AMP in addition to what they were already delivering, and 
> those may only have minor overlap with your articles. 
>

I maintain just 30-40 websites, I don't know, maybe few thousands of pages, 
and the budget is so little of importance, as we already use more web space 
and pay for it, then it is required. It is not even a gigabyte more of 
pages, probably 100 megabytes or less.
 

> And then let say it move your article from rank 1000000 to rank 10000, 
> would that be relevant? 
>

The question is not relevant. When competing with other websites, and AMP 
is the main page, the AMP will get priority with Google. It affects mobile 
search ranking, and it is logical.
 

> Only when you are so popular to be able to land on the first page of the 
> search, you might need to worry about any potential benefits of page rank 
> from AMP.
>

Exactly.  That is my experience since long time, and I don't even consider 
using AMP for other reasons but competing on first page.

Yet popularity was not the subject. 

It is understandable that there are reasons for creating AMP pages. There 
is communication channel, that is Google, and Google will give priorities 
to AMP pages on mobile channel, and mobile channel is today and in future 
more and more important.

While AMP pages may be cached by Google, for me it does not matter, it is 
similar as distributing the flyer that is distributed from hands of third 
parties, instead of my hand, the message get across. That is what matters 
to me, not to every website publisher.


-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/88b0c4eb-44b6-4e45-966a-97b91a56097d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 4566 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

[-- Attachment #1.1: Type: text/plain, Size: 1173 bytes --]

Alright I found now solution, it is quite easy to generate the AMP pages, 
and I can modify it.

I found I can do:

pandoc --print-default-data-file sample.lua > sample.lua

and then I can modify it to conform to the special AMP HTML tags, which are 
not many in the body:
https://www.ampproject.org/docs/reference/spec

while the template may generate the header tags, and whatever is not in the 
body.

In that sense, for me this is closed, I found the way to generate AMP pages 
by using pandoc's lua extension.

My budget is zero dollars, and it allows me to make those very small 
modifications.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/382a2f59-fca3-4409-8b05-10bd7e884a70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1630 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Albert Krewinkel]

support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org writes:

> In that sense, for me this is closed, I found the way to generate AMP pages by
> using pandoc's lua extension.

Would you make the custom writer available somewhere? I'm sure there are
others facing this problem and who would be interested in a ready-made
solution.

-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

Re: Markdown for AMP Project https://www.ampproject.org/

[RCDRUN]

Once I finish it, I will send you.

It is really simple so far, just the IMG tag. That is because I am
using templates and use markdown just for the body.

On Mon, May 01, 2017 at 01:13:12PM +0200, Albert Krewinkel wrote:
> support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org writes:
> 
> > In that sense, for me this is closed, I found the way to generate AMP pages by
> > using pandoc's lua extension.
> 
> Would you make the custom writer available somewhere? I'm sure there are
> others facing this problem and who would be interested in a ready-made
> solution.
> 
> -- 
> Albert Krewinkel
> GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124
> 
> -- 
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/87fugosud3.fsf%40espresso.zeitkraut.de.
> For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[Fernando Botelho]

it would be really neat for the non-technical among us, if we could have 
this as a file format option. That way we could choose to convert to it 
as easily as we convert to normal html.


Fernando



On 05/01/2017 04:04 AM, support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org wrote:
> Alright I found now solution, it is quite easy to generate the AMP 
> pages, and I can modify it.
>
> I found I can do:
>
> pandoc --print-default-data-file sample.lua > sample.lua
>
> and then I can modify it to conform to the special AMP HTML tags, 
> which are not many in the body:
> https://www.ampproject.org/docs/reference/spec
>
> while the template may generate the header tags, and whatever is not 
> in the body.
>
> In that sense, for me this is closed, I found the way to generate AMP 
> pages by using pandoc's lua extension.
>
> My budget is zero dollars, and it allows me to make those very small 
> modifications.
> -- 
> You received this message because you are subscribed to the Google 
> Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
> <mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>.
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
> <mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/382a2f59-fca3-4409-8b05-10bd7e884a70%40googlegroups.com 
> <https://groups.google.com/d/msgid/pandoc-discuss/382a2f59-fca3-4409-8b05-10bd7e884a70%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[RCDRUN]

On Mon, May 01, 2017 at 01:39:34PM -0300, Fernando Botelho wrote:
> it would be really neat for the non-technical among us, if we could have
> this as a file format option. That way we could choose to convert to it as
> easily as we convert to normal html.

I am attaching the AMP template I am using.

I see that AMP HTML tags do not require much adaptation to normal HTML
tags. https://www.ampproject.org/docs/reference/spec

video and audio tags I am generating by using the plugin, and it is
then complicated. The plugin recognizes if it is AMP page, or if it is
email, or HTML page, and expands into corresponding correct tag.

<% (princ (cl-user::plugin-video :src "some-video.webm" :width 640 :height 480)) %>

The images were my problem, and still I don't know how to implement in
custom Lua writer possibility to provide image width and height. Once
I solve that, I can send it to the list.

I am using discount markdown that allows me to correctly specify
image sizes such as:

![SAM_0020.JPG](http://www.startyourowngoldmine.com/images/syogm/tanzania/2017/02/2017-02-04/SAM_0020.JPG  =2048x1536 "SAM_0020.JPG")

So now I am simply thinking not to use Pandoc, just to recompile the
discount markdown to have the IMG tag correct for AMP, and I am done
myself.

Jean

Re: Markdown for AMP Project https://www.ampproject.org/

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 2106 bytes --]

@Jean, you know you can specify image sizes in pandoc as well, right? see 
http://pandoc.org/MANUAL.html#images

On Monday, May 1, 2017 at 7:18:56 PM UTC+2, RCDRUN wrote:
>
> On Mon, May 01, 2017 at 01:39:34PM -0300, Fernando Botelho wrote: 
> > it would be really neat for the non-technical among us, if we could have 
> > this as a file format option. That way we could choose to convert to it 
> as 
> > easily as we convert to normal html. 
>
> I am attaching the AMP template I am using. 
>
> I see that AMP HTML tags do not require much adaptation to normal HTML 
> tags. https://www.ampproject.org/docs/reference/spec 
>
> video and audio tags I am generating by using the plugin, and it is 
> then complicated. The plugin recognizes if it is AMP page, or if it is 
> email, or HTML page, and expands into corresponding correct tag. 
>
> <% (princ (cl-user::plugin-video :src "some-video.webm" :width 640 :height 
> 480)) %> 
>
> The images were my problem, and still I don't know how to implement in 
> custom Lua writer possibility to provide image width and height. Once 
> I solve that, I can send it to the list. 
>
> I am using discount markdown that allows me to correctly specify 
> image sizes such as: 
>
> ![SAM_0020.JPG](
> http://www.startyourowngoldmine.com/images/syogm/tanzania/2017/02/2017-02-04/SAM_0020.JPG 
>  =2048x1536 "SAM_0020.JPG") 
>
> So now I am simply thinking not to use Pandoc, just to recompile the 
> discount markdown to have the IMG tag correct for AMP, and I am done 
> myself. 
>
> Jean 
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a1643278-9ec1-46a7-80d8-c0238b5b9f22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 3747 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

On Tue, May 02, 2017 at 02:09:50PM -0700, mb21 wrote:
> @Jean, you know you can specify image sizes in pandoc as well, right? see 
> http://pandoc.org/MANUAL.html#images

I see that, it is nice usable tool and I use it. I also use Pandoc to
convert HTML to text, at least temporarily, as it may show HTTP links
within the text body, which is nice feature.

Before I was using elinks browser with --dump option, and links appear
then on the bottom of the page.

However, it is not as good for my production and the website revision
system with hundreds (thousands) of markdown pages, as it is too
slow.

If I add AMP pages, that means there is double number of pages to
process. Pandoc is not thinkable for the large work, after short
review and stupid benchmark below.

time lisp -x '(loop for i from 1 to 1000 do (shell "pandoc -f markdown -t html  tmp/benchmark.md > /dev/null" ))'

NIL

real    2m30.604s
user    2m13.572s
sys     0m10.972s


time lisp -x '(loop for i from 1 to 1000 do (shell "discount_markdown tmp/benchmark.md > /dev/null" ))'
NIL

real    0m6.388s
user    0m0.060s
sys     0m0.056s

the difference should be very obvious. Discount markdown is way better
for markdown, while Pandoc is way better for general purpose
conversions and is too slow for huge collection of markdown pages.

Discount markdown: www.pell.portland.or.us/~orc/Code/discount/

Jean

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3883 bytes --]

Yes, pandoc is not optimized for speed and memory use but extensibility. If 
there's no feature you need in pandoc, there probably be better solutions 
out there. I know that MultiMarkdown is highly optimized in C too. But I 
don't know how it compares to Discount.

On the other hand, for some of us, sticking with pandoc is way easier in 
terms of extensibility and "future compatibility". And regarding 
performance, depending on your project size and the amount of new contents 
you are creating, that might be irrelevant. e.g. if you use makefile to 
build your project (or any other build system like Jekyll), it will not 
rebuild targets that's already been built and not updated. And then you can 
always do something like `make -j` to build in parallel. And lastly, if you 
are building static pages, generation speed is usually not too important 
unless your project is really really huge.

It sounds like your project is kind of large scale and want to be as 
optimized as possible (in terms of page rank, rendering speed, etc.). So if 
you describe more about your use case, we might be able to give better 
advice.

By the way, I almost forgot to mention, @jgm has mentioned that if you use 
commonmark output from pandoc, it will be much faster. If you don't need 
the extra features pandoc markdown has in addition to those in commonmark, 
you might give it a try and see if its performance satisfies you.

P.S. I has a friend who was mentored by a Haskell language designer, and he 
once said "coding in Haskell is trading time for correctness". And that's 
exactly why pandoc can handle such complexity with relative ease (@jgm has 
praised Haskell's compiler in order for him to handle this complexity).

On Tuesday, May 2, 2017 at 2:28:58 PM UTC-7, supp...-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org wrote:
>
> On Tue, May 02, 2017 at 02:09:50PM -0700, mb21 wrote: 
> > @Jean, you know you can specify image sizes in pandoc as well, right? 
> see 
> > http://pandoc.org/MANUAL.html#images 
>
> I see that, it is nice usable tool and I use it. I also use Pandoc to 
> convert HTML to text, at least temporarily, as it may show HTTP links 
> within the text body, which is nice feature. 
>
> Before I was using elinks browser with --dump option, and links appear 
> then on the bottom of the page. 
>
> However, it is not as good for my production and the website revision 
> system with hundreds (thousands) of markdown pages, as it is too 
> slow. 
>
> If I add AMP pages, that means there is double number of pages to 
> process. Pandoc is not thinkable for the large work, after short 
> review and stupid benchmark below. 
>
> time lisp -x '(loop for i from 1 to 1000 do (shell "pandoc -f markdown -t 
> html  tmp/benchmark.md > /dev/null" ))' 
>
> NIL 
>
> real    2m30.604s 
> user    2m13.572s 
> sys     0m10.972s 
>
>
> time lisp -x '(loop for i from 1 to 1000 do (shell "discount_markdown tmp/
> benchmark.md > /dev/null" ))' 
> NIL 
>
> real    0m6.388s 
> user    0m0.060s 
> sys     0m0.056s 
>
> the difference should be very obvious. Discount markdown is way better 
> for markdown, while Pandoc is way better for general purpose 
> conversions and is too slow for huge collection of markdown pages. 
>
> Discount markdown: www.pell.portland.or.us/~orc/Code/discount/ 
>
> Jean 
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/8fe02f4f-a2e4-4c86-ad1c-3fc90cdfdb72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 6522 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

Thank you.

On Tue, May 02, 2017 at 06:15:49PM -0700, Kolen Cheung wrote:
> Yes, pandoc is not optimized for speed and memory use but extensibility. If 
> there's no feature you need in pandoc, there probably be better solutions 
> out there. I know that MultiMarkdown is highly optimized in C too. But I 
> don't know how it compares to Discount.

time lisp -x '(loop for i from 1 to 1000 do (shell "pandoc -f commonmark -t html  tmp/benchmark.md > /dev/null" ))'
NIL

real    0m39.957s
user    0m24.160s
sys     0m8.036s

pandoc with commonmark is way faster, I see, still about 6 times
slower than discount markdown, but good to know it. Thank you, I will
use it.

The test with multimarkdown is little faster than pandoc, yet slower
than discount markdown:

time lisp -x '(loop for i from 1 to 1000 do (shell "./multimarkdown ~/tmp/benchmark.md > /dev/null" ))'
NIL

real    0m17.655s
user    0m11.856s
sys     0m0.284s

> On the other hand, for some of us, sticking with pandoc is way easier in 
> terms of extensibility and "future compatibility". And regarding 
> performance, depending on your project size and the amount of new contents 
> you are creating, that might be irrelevant. e.g. if you use makefile to 
> build your project (or any other build system like Jekyll), it will not 
> rebuild targets that's already been built and not updated. And then you can 
> always do something like `make -j` to build in parallel.

Yes, only no. I use database, multiple templates and variable
expansion. Static html is generated with the dynamic content produced
by database and website revision system. That means some websites are
updated daily, with prices updated.

> And lastly, if you are building static pages, generation speed is
> usually not too important unless your project is really really huge.

I am updating too often, making new content, and multiple related
pages reflecting new content on one page are updated, so speed is
always relevant.

I don't know for you and other people, but I don't like waiting on
program execution, even a second is sometimes too long, depending on
what I am doing.

> It sounds like your project is kind of large scale and want to be as
> optimized as possible (in terms of page rank, rendering speed,
> etc.). So if you describe more about your use case, we might be able
> to give better advice.

Yes, who does not want the optimizations.

For advise, if you know how to make this line compatible with pandoc,
let me know. This way I am providing image sizes to discount markdown,
and image size features are not compatible between markdown varieties,
and pages don't validate without it.

![dreamstime_xxl_35121976.jpg](http://example.com/images/depository/panama/dreamstime_xxl_35121976.jpg =2048x1365 "dreamstime_xxl_35121976.jpg") 

Then I could use pandoc to generate PDF and other complementary
formats relating to pages.

> By the way, I almost forgot to mention, @jgm has mentioned that if you use 
> commonmark output from pandoc, it will be much faster. If you don't need 
> the extra features pandoc markdown has in addition to those in commonmark, 
> you might give it a try and see if its performance satisfies you.

Yes it is few times faster, true. Yet slower then both discount
markdown and multimarkdown.

> P.S. I has a friend who was mentored by a Haskell language designer, and he 
> once said "coding in Haskell is trading time for correctness". And that's 
> exactly why pandoc can handle such complexity with relative ease (@jgm has 
> praised Haskell's compiler in order for him to handle this
> complexity).

There is high burden to install the Haskell and all compatibilities
required for pandoc -- so it is not really necessarily for me. And I
cannot even compile from source, it is such a huge trouble to compile
it from source, you would not believe it. I would need to go back to
earliest versions of Haskell, and compile it version by version to the
present time, I mean -- no.

It is easy for those who use distributions, I don't use and it hard to
understand why pandoc has this much of underlying required software,
it is really huge in size. No, I don't want to know.

Pandoc is good, but for me not as fast to generate pages. 


Jean

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3862 bytes --]

Multimarkdown also support quite extensive amount of features and because 
of that you might find it slower than Discount.

And regarding optimization, actually in the real world, a lot of people 
don't care about it. An example is a workflow to generate a large document 
from many smaller ones outlined in [Repeated Footnotes Anchors and Headers 
Across Multiple Files — Pandoc Tricks · jgm/pandoc Wiki · 
GitHub](https://github.com/jgm/pandoc/wiki/Pandoc-Tricks#repeated-footnotes-anchors-and-headers-across-multiple-files). 
If you go through that workflow, you find that a lot of redundant 
computation is done in order to guarantee I don't have repeated headers and 
footnotes anchors. (I think there's an alternative to ask pandoc to prefix 
header id as well, but I don't want the prefix.) And because my project 
involved LaTeX, the bottleneck in time is the PDF generation from LaTeX so 
I can afford time lost in the pandoc md parsing.

Going back to your use case, it seems you requires every last drop of 
performance. In markdown rendering, one thing you should shop for besides 
rendering speed is the feature sets (markdown extensions) and the syntaxes. 
In your case, you should narrow down the minimal set of features you need, 
and given that feature set, you choose the one that's fastest.

I can't speak for the others, but I can guess that for most pandoc users, 
we never care about performance but look for the feature set. When I said 
"future compatibility", I mean in the future, when I write new contents, 
what if I need one more feature that the current software stack I setup 
didn't support? How large will the migration / work-around cost be in the 
future? In order words, we trade the computer time for the 
programmers/writers' time. But this might not be realistic for other 
people, because if their project is large enough, long computer time is 
going to cost you (server time, client wait time, etc.). And it seems that 
you are exactly in this later case (especially you're generating the 
contents dynamically).

And regarding compiling from source, you actually don't need to do that if 
you are using the platforms that pandoc releases official binaries — 
Windows, Mac, Linux (`.deb`) 64-bit. From my experience, compiling from 
source on Mac with homebrew is easy, as well as using stack, but less so 
when using cabal. If you are on alternative CPU architecture (e.g. ARM), it 
is super hard (or impossible).

P.S. Haskwell is actually a very interesting language, and as far as I can 
tell, the most mathematical language. It seems such a language would be 
suited for scientific computing because all we do in science involves Math. 
But unfortunately, virtually no body is doing Science in Haskell, at least 
in HPC application, exactly because of the lack of performance. By the way, 
AFAIK in Haskell you almost get parallelization for free, but in other 
language a lot of time has to be spent on thinking about how to parallelize 
a particular algorithm (and to implement it!). IMO, the "guarantee in 
correctness" and "free parallelism" of Haskell should be major selling 
points of Haskell to scientists but for various other reasons scientists 
doesn't really use it.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b7a15adb-8e28-4d0a-9aa5-7c77b4f4f4eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 4371 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

It is good to exchange, as I almost never communicate with other
people who use markdown, even it is so much the part of publishing
process.

On Wed, May 03, 2017 at 12:23:02PM -0700, Kolen Cheung wrote:
> And regarding optimization, actually in the real world, a lot of people 
> don't care about it. An example is a workflow to generate a large document 
> from many smaller ones outlined in [Repeated Footnotes Anchors and Headers 
> Across Multiple Files — Pandoc Tricks · jgm/pandoc Wiki · 
>
> GitHub](https://github.com/jgm/pandoc/wiki/Pandoc-Tricks#repeated-footnotes-anchors-and-headers-across-multiple-files).

I have looked on that, and I try to lessen down the complexity, not to
widen it.

> Going back to your use case, it seems you requires every last drop of 
> performance.

It sounds to me surprising when you say it so. Yet again, I don't like
too many pages being generated slow. I have already removed those
websites that generated thousands of pages.

> In markdown rendering, one thing you should shop for besides
> rendering speed is the feature sets (markdown extensions) and the
> syntaxes.  In your case, you should narrow down the minimal set of
> features you need, and given that feature set, you choose the one
> that's fastest.

What I use is just images and text.

Video is expaned by use of plugins, something like:

<% (princ (cl-user::plugin-video :src "video.webm" :width 400 :height 300)) %>

then if the page is sent by email, video may show just as link, if it
is published, it gets its proper HTML,

Before I was using the fastest Perl templating engine I found the
Text::NeatTemplate and now I use the Lisp's CL-EMB templating, which
gives me more freedom and is as fast I guess.

I have tied the processing or filtering program to the template, and
multitudes of templates in the website revision system.

If I copy same template and tie it to pandoc, the template's content
would expand with pandoc.

That way I could use any variety of markdown.

For example, I use the Org mode processing by using GNU Emacs, for
some pages. The Org mode is then converted to markdown, which is then
expanded into HTML within a template, because the template is tied to
Org mode conversion.

So I can mix Org mode, pandoc, other markdowns, all together in one
website.

My process is to simply write new pages, variables are expanded before
markdown, and markdown or other filtering language expands into HTML
within a template. Each page may have different template tied to
different processor.

> I can't speak for the others, but I can guess that for most pandoc users, 
> we never care about performance but look for the feature set.

When you say so. I deal with number of pages and like when it is
fast. And I had to re-program the system to make it faster, as at some
point of time it became too bloated. My programming is dirty.

> When I said "future compatibility", I mean in the future, when I
> write new contents, what if I need one more feature that the current
> software stack I setup didn't support? How large will the migration
> / work-around cost be in the future? In order words, we trade the
> computer time for the programmers/writers' time.

I used markdown since its inception, and before that I used M4 macro
processor.

Since that time until today, I did not switch to any new features,
just pictures and text, sometimes a table and videos, maps and
similar.

If I use a plugin for video or map, I can always adapt the expansion
of HTML without changing the source of the file.

> And regarding compiling from source, you actually don't need to do
> that if you are using the platforms that pandoc releases official
> binaries — Windows, Mac, Linux (`.deb`) 64-bit.

All software is compiled from source, that is how I build the
GNU/Linux system, and I don't use distributions any more.

When I referred to compiling pandoc, I think all, including haskell
and anything else. Almost impossible task.

> From my experience, compiling from source on Mac with homebrew is
> easy, as well as using stack, but less so when using cabal.

You refer only to pandoc.

> P.S. Haskwell is actually a very interesting language, and as far as
> I can tell, the most mathematical language. It seems such a language
> would be suited for scientific computing because all we do in
> science involves Math.  But unfortunately, virtually no body is
> doing Science in Haskell, at least in HPC application, exactly
> because of the lack of performance. By the way, AFAIK in Haskell you
> almost get parallelization for free, but in other language a lot of
> time has to be spent on thinking about how to parallelize a
> particular algorithm (and to implement it!). IMO, the "guarantee in
> correctness" and "free parallelism" of Haskell should be major
> selling points of Haskell to scientists but for various other
> reasons scientists doesn't really use it.

I am sure it is used in science too, it is large and usable.

Now I am using Lisp, Common Lisp and all is good and fine for
me. There are similarities to Haskell, even I did not do anything with
it.

Jean

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170503203659.GD11153%40protected.rcdrun.com.
For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3422 bytes --]



Very interesting to know these. And don’t get me wrong, I’m not surprised 
some people need performance. I’m just saying given the requirements and 
options, pandoc really doesn’t fit your need.

Other than pandoc, I think compiling Haskell with stack is much easier. I’m 
no Haskell expert but this is what I heard. I agree cabal dependency hell 
is frustrating.

Yes, “Haskell is used in science”. It just doesn’t really “has a presence”. 
Generally, people talked about using C/C++/UPC (and CUDA), Fortran, even 
Python (PyCUDA), and then the new Julia for HPC (High Performance 
Computing). But I never heard of people talking about *deploying* a 
scientific HPC application written in Haskell. What makes me sad is that 
actually Haskell is faster than Python. But scientist chose Python over 
Haskell because of e.g. the ease to learn it, distribute, and interfacing 
with existing Fortran and C/C++ code base, and all these are difficult to 
be accomplished in Haskell. One problem many scientists have is that they 
are not professional programmers, and they don’t care about spending time 
learning a language (except when needed in their research). So many of them 
write whatever code that’s getting their research done in the least amount 
of time. For computer time dominant projects, they use Fortran/C/C++; for 
programmers’ time dominant projects, they use Python. But they (almost) 
never choose Haskell because it is hard to learn (lots of programmers time 
to pick it up, but develop time might actually be much less. But they don’t 
invest in the future but want to code right now) and slow (lots of computer 
time needed). So it’s in the middle of nowhere.

I also heard part of the reason Haskell didn’t take off in the way say 
Python does is a matter of PR — they just are not good at selling their 
product.

And then perhaps another reason Haskell is not a good fit for science is 
that Haskell focus too much on correctness. But in scientific computing, 
most of the time we actually didn’t really care if it is “correct”, but 
close enough and fast.

I wish I can use Haskell in any part of my research such that it gives me 
excuse to spend more time to learn such a beautiful language (and to 
contribute more to pandoc).

P.S. as I’m typing the above, I found that Intel has finally released the 
long-promised Haskell compiler! In the past, they released studies showing 
that in some situation, the Haskell code beats the C code by 8% in speed. 
Hopefully this could change the adoption of Haskell in scientific 
programming. Reference: IntelLabs/flrc: Haskell Research Compiler 
<https://github.com/IntelLabs/flrc>, Intel Haskell Research Compiler | 
Hacker News <https://news.ycombinator.com/item?id=14106557>
​

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/e69fce56-6677-4918-830e-ffe4fcd60cb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 8438 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

On Wed, May 03, 2017 at 09:52:24PM -0700, Kolen Cheung wrote:
> Very interesting to know these. And don’t get me wrong, I’m not surprised 
> some people need performance. I’m just saying given the requirements and 
> options, pandoc really doesn’t fit your need.

It does not fit for majority of pages, for some special pages it is
required. I have a flexible website revision system that allows using
various markdown versions or other text processing system.

By making single input/output script, then assigning it to template,
and template to the page, I could even use multiple filtering
programs, while all other page would be handled by the default
filtering program.

Pages that require their output in PDF could be handled with Pandoc
for example, then I would put special attention of what I write in
Markdown. This way is possible to get automatically the PDF book of
such pages.

> Yes, “Haskell is used in science”. It just doesn’t really “has a presence”. 
> Generally, people talked about using C/C++/UPC (and CUDA), Fortran, even 
> Python (PyCUDA), and then the new Julia for HPC (High Performance 
> Computing).

You know it, I don't know as we speak of general science. If we speak
of general science, programming language is computer science, so it is
automatically used in science in general.

I cannot speak of general knowledge.

I am practical scientist, using microscope, mathematics, physics and
programming to analyse and estimate future outcomes in mineral
processing. Not much more than that.

> I also heard part of the reason Haskell didn’t take off in the way
> say Python does is a matter of PR — they just are not good at
> selling their product.

For me it really does not matter if programming language is accepted
or not -- if you love it for any reason, you use it, and let the
future happen.

It could be frustrating only when you are the advanced student who
simply knows it better, and then you get forced to learn lesser
valuable language in your study class.

In my view and impression I have got from Internet, Haskell is very
popular and powerful.

Jean

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170504082251.GC14964%40protected.rcdrun.com.
For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1.1: Type: text/plain, Size: 3770 bytes --]

For PDF generation, there are other markdown solutions as well. Even within 
pandoc, pandoc recently added a PDF writer that uses `wkhtmltopdf` instead 
which is much faster. If you need LaTeX generated PDF for quality, 
Multimarkdown also does that. (But I doubt the difference in speed between 
MMD and pandoc would be relevant here because LaTeX is the bottleneck.) By 
the way, I personally finding that if LaTeX output is needed, using pandoc 
is much easier and powerful than using MultiMarkdown. In principle 
everything doable on one can be done in other system, but it is very 
difficult to handle the complexity in MMD, especially when multi-output is 
needd.

About the Haskell in Science: I should be more careful in the wordings. 
What I said is all about scientific programming. In fact, Haskell looks 
like as if it remains a CS research language more than a wide-spread 
language for people other that computer scientists. In the very general 
sense of Haskell's presence in science, it is undeniable, but that doesn't 
really mean anything practically.

And regarding programming language of choice, in Sience we almost always 
need to collaborate (expecially if it involves experiments and computing). 
I can guarantee my failure in the field if I write anything in Haskell. You 
will be surprised to know that people in my group even oppose to the idea 
of writing code in C/C++ and prefer everything in Python (or else use 
another library and don't care what language they are actually written). So 
I cheat and write C/C++ using Cython. And viola, I give them "Python code". 
But I hate it when I knew there's some optimzation I can do in C/C++ and 
Cython don't support it (e.g. compiler hints, SIMD vectorization, Intel 
intrinsics, etc.), and Python bool/complex vs. C++ bool/complex is a a bit 
of a problem in Cython too.

I'm not Haskell expert so I can't say for certain. But Haskell's "failure" 
in scientific computing might be intrinsic, because most of the scientific 
computing are numerical, and very procedural (sometimes because of 
optimzation). e.g. the simplest example is matrix multiplication, which 
essentially is 1 line of code in 3 nested loops in terms of the Math. But 
it turns into a huge code base for different properties of the matrix and 
different optimization to be used, etc.

But I don't think we can, and I'm also not to, deny a language's success by 
saying it is not successful in 1 field (scientific computing here). What I 
was saying is that I wish this is not true, because Haskell is such a 
mathematical language. To solve math problem in such language would 
probably be a delightful experience. Or in order words, probably it is just 
a wishful thinking to wish that we don't have to worry about algorithm 
(which Haskell helps you in this regards), but currently compiler are still 
not advanced enough for us to not worry about this. That's why I'm excited 
by the Intel's research compiler because it seems like it is trying to 
optimize functional language in a very general way (Haskell is just 1 
example), and in some cases it can beat hand-tuned C code (although their 
compiler actually generates intermediate C codes).

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b9d11088-d6ac-432b-8206-03e1962d66a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 4343 bytes --]

Re: Markdown for AMP Project https://www.ampproject.org/

[Kolen Cheung]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

Regarding AMP, FYI

https://www.theregister.co.uk/2017/05/19/open_source_insider_google_amp_bad_bad_bad/

Re: Markdown for AMP Project https://www.ampproject.org/

[John MacFarlane]

As an alternative to discount, you might try cmark, which is
about 6X faster than discount and supports the CommonMark standard.

+++ support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org [May 03 17 00:24 ]:
>the difference should be very obvious. Discount markdown is way better
>for markdown, while Pandoc is way better for general purpose
>conversions and is too slow for huge collection of markdown pages.
>
>Discount markdown: www.pell.portland.or.us/~orc/Code/discount/
>
>Jean
>
>-- 
>You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170502212420.GB3957%40protected.rcdrun.com.
>For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[support1-ZohPw8X7yHTQT0dZR+AlfA]

On Wed, May 03, 2017 at 11:47:39AM +0200, John MacFarlane wrote:
> As an alternative to discount, you might try cmark, which is
> about 6X faster than discount and supports the CommonMark standard.

Thank you much. Good to know.

I did not perform other tests, just my own simple test, and it is
faster for 1 second than discount markdown.

time lisp -x '(loop for i from 1 to 1000 do (shell "./cmark ~/tmp/benchmark.md > /dev/null" ))'
NIL

real    0m5.062s
user    0m0.096s
sys     0m0.020s

Re: Markdown for AMP Project https://www.ampproject.org/

[John MacFarlane]

And this is even faster and smaller:
https://github.com/mity/md4c

+++ support1-ZohPw8X7yHTQT0dZR+AlfA@public.gmane.org [May 03 17 13:09 ]:
>On Wed, May 03, 2017 at 11:47:39AM +0200, John MacFarlane wrote:
>> As an alternative to discount, you might try cmark, which is
>> about 6X faster than discount and supports the CommonMark standard.
>
>Thank you much. Good to know.
>
>I did not perform other tests, just my own simple test, and it is
>faster for 1 second than discount markdown.
>
>time lisp -x '(loop for i from 1 to 1000 do (shell "./cmark ~/tmp/benchmark.md > /dev/null" ))'
>NIL
>
>real    0m5.062s
>user    0m0.096s
>sys     0m0.020s
>
>-- 
>You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170503100958.GB1547%40protected.rcdrun.com.
>For more options, visit https://groups.google.com/d/optout.

Re: Markdown for AMP Project https://www.ampproject.org/

[RCDRUN]

On Wed, May 03, 2017 at 12:28:52PM +0200, John MacFarlane wrote:
> And this is even faster and smaller:
> https://github.com/mity/md4c

Thank you, that is good.

Re: Markdown for AMP Project https://www.ampproject.org/

[RCDRUN]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Template is attached.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/20170501171455.GB2499%40protected.rcdrun.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: amp-template.html --]
[-- Type: text/html, Size: 2006 bytes --]