Re: [fossil-users] Proposed improvement to inheritedprivilegessubscripts.

[Will Parsons]

Scott Robison wrote:
> --===0702352335==
> Content-Type: multipart/alternative; boundary=f46d044286d854da5a05042007d5
>
> --f46d044286d854da5a05042007d5
> Content-Type: text/plain; charset=UTF-8
>
> On Sep 28, 2014 12:49 AM, "Stephan Beal"  wrote:
>>
>> Sidenote: i'm curious why most people prefer postscript addition, when
> prefix is "never slower and sometimes faster." (Not that it matters one
> iota for a case like this, it just seems to be very deeply embedded in most
> people i know.)
>
> I think most people (I am not most people in this case) prefer / use
> postfix increment & decrement because it is what they learned first and how
> most examples seem to be written. I prefer to use prefix operators (barring
> the need for postfix side effects) just because they read more naturally in
> my native language. I think it makes more sense when thinking "increment i"
> to see "++i". The fact that it is potentially more efficient (though
> probably not in practice) is just a bonus.

I do it because it's what's most commonly used in C.  For C, any
considerations of efficiency are likely to be negligible, but if
you're writing in C++, the cost of constructing and destructing a
user-defined object *may* mean that using the prefix form has a
non-negligible efficiency advantage over the postfix form.  So, for
C++, it may make sense to get into to habit of using the prefix form,
unless there is a specific reason for using the postfix form.

-- 
Will

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Richie Adler]

Stephan Beal decía, en el mensaje "Re: [fossil-users] Pessimism about
CommonMark in fossil" del domingo, 28 de septiembre de 2014 13:45:58:
> On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté  > wrote:
> But this is still about disambiguating "Markdown", without looking at
> any other wiki or markup format.
> 
> If it is incompatible with _any_ existing Markdown dialects, then it is
> effectively a competing format. If there are over 2 dozen slightly different
> implementations, what are the real chances of getting those two dozen projects
> to consolidate on one standard? And then what are the chances that all of them
> will change their parsers to all work identically (which seems like quite a
> waste of effort, to have 20+ implementations which all work identically).
> 
> i still predict utter failure ;).

My 0.02 Credits: didn't the name "CommonMark" (and not *Markdown) had to be
created because the creator of Markdown himself disowned the effort and
DEMANDED that the name "Markdown" wasn't used?

More reason to agree with Stephan's prediction.




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[Joe Mistachkin]

As of the very latest trunk [80b4adddec], you'll also need to add the
following
to the command lines:

FOSSIL_BUILD_SSL=1

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Trevor]

Hello:

Thanks Natasha, for reviewing the CommonMark specification and
identifying issues applicable to your Fossil - Markdown parser.
Your arguments are persuasive.

Your obvious skill and knowledge about markdown and general text
parsing would be of high value to the CommonMark group and I
think any comments you presented to them would be welcomed and
might affect their specification itself.

Last year I struggled with adding markdown documents to the wiki,
intending to use Fossil for non-programmer documentation tasks.
Like other Fossil users, I decided to store documents as ordinary
versioned files and deprecated the wiki.

Another consideration was the need to generate pdf versions with
paging control. I now use John MacFarlane's pandoc program with
documents in pandoc markdown, storing them in Fossil repositories.

  http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown

John MacFarlane is a principal author of the CommonMark
specification.

I found a utility, gouda.pl, which asks for a table of contents
file for a directory's worth of markdown files and then uses pandoc
to generate html and pdf output versions, including the table of
contents as a link list. The author withdrew that perl script to
favour one written in clojure, requiring the Java virtual machine
which I did not want to install.

  http://www.unexpected-vortices.com/sw/rippledoc/

The author, John Gabrielle, wrote another version in python:

  https://github.com/npettiaux/gouda

I am still using the perl version and this combination meets my
present needs.

Your Fossil-markdown parser presents a good display for the
features that I use and treats as plain text the '\pagebreak'
instructions intended for pdf paged output.

Markdown is versatile, simple format but the multiplicity of
"standards" limits its universality. I hope you can contribute
to the making of such a standard.

Thanks again,

Trevor


On Sun, 28 Sep 2014 15:36:27 +
Natacha Porté  wrote:

> Hello,
> 
> as you might already know, I'm the primary author of libsoldout and
> its integration into fossil to perform markdown-to-html conversion.
> 
> If you followed recent news, you might have heard of CommonMark[1],
> which is an attempt to unify most implementations and extensions of
> Markdown, by providing a non-ambiguous specification. It's an
> honorable goal, so it makes sense to try to converge existing
> implementations towards the new standard.
> 
> Unfortunately, the architecture of the parser makes it extremely
> difficult to implement CommonMark, probably even more difficult than
> writing a new parser from scratch. In the rest of the e-mail I will
> detail why I think so, in case some of the brilliant minds find a
> mistake in my reasoning and a way to implement CommonMark easily in
> fossil.
> 
> In case I'm not wrong, it raises the question of changing the markdown
> engine integrated in fossil, or purposefully forsake CommonMark
> support (which might make sense if its adoption ends up not as wide
> as its authors hope). Fortunately, there is no rush to take such a
> decision, as a community we can reasonably to wait and see how
> CommonMark adoption pans out.
> 
> [1]: http://commonmark.org/
> 
> 
> 
> The heart of the architecture is built around an online parser: the
> input is considered as an infinite stream of characters, and each
> component of the parser either consumes input characters or hand over
> control to another component, with control transfer made in such a way
> that there is no loop without input character consumption.
> 
> The main advantage of such an architecture is how easy it is to prove
> that in actually terminates, and to prove upper bounds on memory
> usage. When components are loosely coupled, which is the case here,
> it also makes debugging much easier.
> 
> The main drawback is that there is no backtracking possible without
> cheating, and very limited look-ahead without severely tightening the
> coupling between components.
> 
> Moreover, when designing the parser, I enforced very loose coupling
> between component by requiring all language elements to be
> individually added or removed from the parser. The reason for that is
> that complete Markdown is extremely powerful, especially because of
> raw HTML input features. That's too powerful for untrusted input,
> like blog comments or wikipages. So "unsafe" features have to be
> optional. But there are different levels of "unsafety", for example
> one might want to forbid titles in blog comments, to prevent
> untrusted users from messing with the page layout. Or one might want
> to forbid all links for more-untrusted users while allowing them for
> not-so-untrusted users. So it seemed better to engineer the parser
> around making it possible to allow or forbid any combination of
> features.
> 
> So the online-parser loop variant means that any active character must
> have its semantics decided immediately, and the loose coupling means
> other language elements cann

Re: [fossil-users] Compilation with SSL option fails on Win7

[Joe Mistachkin]

to...@acm.org wrote:
>
> I'm building on Win7 64-bit.  Tomorrow, at work, I can try again on a Win7

> 32-bit, and see if that makes a difference.
> 

Ok, that explains it.  I had not tested x64 compilation with SSL enabled
prior
to today.  Thanks for the report.

Please try again with the latest trunk.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[tonyp]

I'm building on Win7 64-bit.  Tomorrow, at work, I can try again on a Win7 
32-bit, and see if that makes a difference.


Version [ee46563cbd] built without any errors, and apparently has SSL 
support (much larger file size, and an attempt to connect to an HTTPS server 
did not produce errors about missing SSL support).
So, the question is, if that older version relies on pre-built SSL 
libraries, where does it find them?  And, why can't I do the same (use these 
pre-built SSL libraries) when building the latest trunk version?


-Original Message- 
From: Joe Mistachkin

Sent: Sunday, September 28, 2014 10:44 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] Compilation with SSL option fails on Win7


to...@acm.org wrote:


When I tried with an earlier version [ee46563cbd], it worked OK.  Since

the

latest trunk fails consistently (regardless of Perl version used),

something

must have broken sometime in between these two check-ins.



That version ([ee46563cbd]) makes no attempt to automatically build OpenSSL;
therefore, it relies on the OpenSSL libraries already being built.

I'm unable to replicate this issue here locally and I just built an SSL
enabled
Fossil binary here with MSVC (yesterday).

Are you building for x86 or x64?  I suspect the current "Makefile.msc" will
only
work for x86 builds.  I'll look into fixing that.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[Joe Mistachkin]

to...@acm.org wrote:
> 
> When I tried with an earlier version [ee46563cbd], it worked OK.  Since
the 
> latest trunk fails consistently (regardless of Perl version used),
something 
> must have broken sometime in between these two check-ins. 
> 

That version ([ee46563cbd]) makes no attempt to automatically build OpenSSL;
therefore, it relies on the OpenSSL libraries already being built.

I'm unable to replicate this issue here locally and I just built an SSL
enabled
Fossil binary here with MSVC (yesterday).

Are you building for x86 or x64?  I suspect the current "Makefile.msc" will
only
work for x86 builds.  I'll look into fixing that.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[tonyp]

Nope!  The same exact error.

I uninstalled StraberryPerl before installing ActivePerl.

So, the problem is elsewhere.  Also, as I mentioned in the follow-up email:

The problem appears in the latest trunk version [e061a675e6].

When I tried with an earlier version [ee46563cbd], it worked OK.  Since the 
latest trunk fails consistently (regardless of Perl version used), something 
must have broken sometime in between these two check-ins.


-Original Message- 
From: Joe Mistachkin

Sent: Sunday, September 28, 2014 9:16 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] Compilation with SSL option fails on Win7


to...@acm.org wrote:


(I have installed the latest perl - Strawberry Perl, and I have installed
openssl-1.0.1i.tar.gz under the compat subdirectory)



I suspect this may have to do with the line-endings in the OpenSSL files.

Please try again with ActiveState Perl and let us know if that fixes the
issue.

The "PERLDIR=C:\path\to\ActiveState\Perl\bin" can be used to force the build
process to use that installed instance of Perl; however, for the Command
Prompt Window being used to compile Fossil, you will also want to make sure
that none of the Strawberry Perl binary directories are located in the PATH.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Richard Hipp]

http://xkcd.com/927/

--
D. Richard Hipp
Sent from phone - Excuse brevity
On Sep 28, 2014 12:46 PM, "Stephan Beal"  wrote:

> On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté 
> wrote:
>
>> I completely share the opinion above, except I'm afraid you have
>> misunderstood the goal of CommonMark: it's not about unifying or
>> standardizing wiki format, only unifying Markdown.
>>
>
> i understand that, but there are several competing dialects already, and
> no truly overwhelming reason to consolidate them. If the benefits were 100%
> clear and compelling, it would already have replaced the other dialects.
>
>
>> But this is still about disambiguating "Markdown", without looking at
>>
> any other wiki or markup format.
>>
>
> If it is incompatible with _any_ existing Markdown dialects, then it is
> effectively a competing format. If there are over 2 dozen slightly
> different implementations, what are the real chances of getting those two
> dozen projects to consolidate on one standard? And then what are the
> chances that all of them will change their parsers to all work identically
> (which seems like quite a waste of effort, to have 20+ implementations
> which all work identically).
>
> i still predict utter failure ;).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[Joe Mistachkin]

to...@acm.org wrote:
> 
> (I have installed the latest perl - Strawberry Perl, and I have installed 
> openssl-1.0.1i.tar.gz under the compat subdirectory)
> 

I suspect this may have to do with the line-endings in the OpenSSL files.

Please try again with ActiveState Perl and let us know if that fixes the
issue.

The "PERLDIR=C:\path\to\ActiveState\Perl\bin" can be used to force the build
process to use that installed instance of Perl; however, for the Command
Prompt Window being used to compile Fossil, you will also want to make sure
that none of the Strawberry Perl binary directories are located in the PATH.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compilation with SSL option fails on Win7

[tonyp]

Update (if it helps):

The problem appears in the latest trunk version [e061a675e6].

I also tried with an earlier version [ee46563cbd], and it worked OK.  But 
the latest trunk fails consistently, so something must have broken in 
between these two.


-Original Message- 
From: to...@acm.org

Sent: Sunday, September 28, 2014 8:44 PM
To: Fossil SCM user's discussion
Subject: [fossil-users] Compilation with SSL option fails on Win7

Here's what I do:

(I have installed the latest perl - Strawberry Perl, and I have installed
openssl-1.0.1i.tar.gz under the compat subdirectory)

Then (with MSVC) I do:

nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1

and after some successful work, it halts with this message:

--
C:\temp\compat\openssl-1.0.1i>perl util\mkdef.pl 32 ssleay
1>ms\ssleay32.def

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Building OpenSSL
   perl util/copy.pl ".\crypto\buildinf.h" "tmp32\buildinf.h"
Copying: ./crypto/buildinf.h to tmp32/buildinf.h
   perl util/copy.pl ".\crypto\opensslconf.h"
"inc32\openssl\opensslconf.h"

Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
   link /nologo /subsystem:console /opt:ref /debug
/out:out32\md4test.exe @
C:\Users\Tony\AppData\Local\Temp\nmCE0C.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
12.0
\VC\BIN\link.EXE"' : return code '0x49d'
Stop.
NMAKE : fatal error U1077: 'pushd' : return code '0x2'
Stop.
--

Any ideas what's missing (link.obj apparently but why?) or misconfigured?

TIA

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Compilation with SSL option fails on Win7

[tonyp]

Here's what I do:

(I have installed the latest perl - Strawberry Perl, and I have installed 
openssl-1.0.1i.tar.gz under the compat subdirectory)


Then (with MSVC) I do:

nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1

and after some successful work, it halts with this message:

--
C:\temp\compat\openssl-1.0.1i>perl util\mkdef.pl 32 ssleay 
1>ms\ssleay32.def


Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Building OpenSSL
   perl util/copy.pl ".\crypto\buildinf.h" "tmp32\buildinf.h"
Copying: ./crypto/buildinf.h to tmp32/buildinf.h
   perl util/copy.pl ".\crypto\opensslconf.h" 
"inc32\openssl\opensslconf.h"


Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
   link /nologo /subsystem:console /opt:ref /debug 
/out:out32\md4test.exe @

C:\Users\Tony\AppData\Local\Temp\nmCE0C.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0

\VC\BIN\link.EXE"' : return code '0x49d'
Stop.
NMAKE : fatal error U1077: 'pushd' : return code '0x2'
Stop.
--

Any ideas what's missing (link.obj apparently but why?) or misconfigured?

TIA 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Stephan Beal]

On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté 
wrote:

> I completely share the opinion above, except I'm afraid you have
> misunderstood the goal of CommonMark: it's not about unifying or
> standardizing wiki format, only unifying Markdown.
>

i understand that, but there are several competing dialects already, and no
truly overwhelming reason to consolidate them. If the benefits were 100%
clear and compelling, it would already have replaced the other dialects.


> But this is still about disambiguating "Markdown", without looking at
>
any other wiki or markup format.
>

If it is incompatible with _any_ existing Markdown dialects, then it is
effectively a competing format. If there are over 2 dozen slightly
different implementations, what are the real chances of getting those two
dozen projects to consolidate on one standard? And then what are the
chances that all of them will change their parsers to all work identically
(which seems like quite a waste of effort, to have 20+ implementations
which all work identically).

i still predict utter failure ;).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Natacha Porté]

Hello,

on Sunday 28 September 2014 at 17:58, Stephan Beal wrote:
> - Wiki syntaxes have always been a matter of personal taste, and there are
> no less than 100 different ones out there in use. To anyone who believes
> they can convince people to switch to a "common" dialect... i've got a
> bridge in Brooklyn i'd like to sell them.
> 
> i.e. i don't see CommonMark being more than yet another attempt to create a
> "perfect world," and history strongly suggests that they will be fighting
> an up-hill battle for a while before it ultimately runs out of steams and
> becomes simply yet another wiki markup platform.
> 
> i could very well be wrong (as i so _sorely_ was about tablets only 3 or 4
> years ago, and 19 years ago with regards to the downfall of Unix), but the
> term "wiki format standardization" is almost an oxymoron, and i don't
> foresee CommonMark breaking that pattern.

I completely share the opinion above, except I'm afraid you have
misunderstood the goal of CommonMark: it's not about unifying or
standardizing wiki format, only unifying Markdown.

The root problem was not the plethora of wiki formats, or the even larger
plethora of lightweight markup languages; it was only the ambiguities in
the original Markdown specification.

There are almost two dozen independent implementations of something
called Markdown, and yet each of them implement a language that is
subtly different from all the others. A tower-of-Babel effect.

You could argue that yet-another variant of Markdown that is subtly
different from all the others would only add to the problem
(see http://xkcd.com/927/ ), and you might very well be right. The only
hopes it won't do more are than good (with regards to fragmentation and
ambiguity of the label "Markdown") come from that the only variant that
is perfectly well-defined, without any ambiguous construct, with a
complete test-suite, and that big-website using Markdown will go for
CommonMark (Stack Exchange, GitHub and Reddit).

But this is still about disambiguating "Markdown", without looking at
any other wiki or markup format.


Natacha


pgpGMoBEco1Ac.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Pessimism about CommonMark in fossil

[Stephan Beal]

On Sun, Sep 28, 2014 at 5:36 PM, Natacha Porté 
wrote:

> authors hope). Fortunately, there is no rush to take such a decision, as
> a community we can reasonably to wait and see how CommonMark adoption
> pans out.
>
> [1]: http://commonmark.org/


i am completely ambivalent on the topic of which wiki formats Fossil
should/should not support, but will offer a few observations...

- i have never seen a project called "common-anything" which has ever
actually become "common" at all. CommonJS has been trying for years to
define common frameworks for JS, with very limited success. In practice,
standards arise "de facto" - from prominent use of the code/practices in
real-world projects, and not from an "ivory tower" decision-making process.

- Anyone trying to get a general consensus on wiki formats has probably
never observed a true standardization effort in progress. The IEEE
standardization effort of JSON has been going on for almost a year and the
members are still quibbling about details like numeric precision
guarantees. (On the one hand, they want ease of implementation and
portability, but on the other hand they want infinite-precision numbers.)
CommonJS is another case of this - each of its "standards" is made up of
multiple proposals for similar-yet-different APIs, for which there is _no_
general consensus.

- Wiki syntaxes have always been a matter of personal taste, and there are
no less than 100 different ones out there in use. To anyone who believes
they can convince people to switch to a "common" dialect... i've got a
bridge in Brooklyn i'd like to sell them.

i.e. i don't see CommonMark being more than yet another attempt to create a
"perfect world," and history strongly suggests that they will be fighting
an up-hill battle for a while before it ultimately runs out of steams and
becomes simply yet another wiki markup platform.

i could very well be wrong (as i so _sorely_ was about tablets only 3 or 4
years ago, and 19 years ago with regards to the downfall of Unix), but the
term "wiki format standardization" is almost an oxymoron, and i don't
foresee CommonMark breaking that pattern.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Pessimism about CommonMark in fossil

[Natacha Porté]

Hello,

as you might already know, I'm the primary author of libsoldout and its
integration into fossil to perform markdown-to-html conversion.

If you followed recent news, you might have heard of CommonMark[1],
which is an attempt to unify most implementations and extensions of
Markdown, by providing a non-ambiguous specification. It's an honorable
goal, so it makes sense to try to converge existing implementations
towards the new standard.

Unfortunately, the architecture of the parser makes it extremely
difficult to implement CommonMark, probably even more difficult than
writing a new parser from scratch. In the rest of the e-mail I will
detail why I think so, in case some of the brilliant minds find a
mistake in my reasoning and a way to implement CommonMark easily in
fossil.

In case I'm not wrong, it raises the question of changing the markdown
engine integrated in fossil, or purposefully forsake CommonMark support
(which might make sense if its adoption ends up not as wide as its
authors hope). Fortunately, there is no rush to take such a decision, as
a community we can reasonably to wait and see how CommonMark adoption
pans out.

[1]: http://commonmark.org/



The heart of the architecture is built around an online parser: the
input is considered as an infinite stream of characters, and each
component of the parser either consumes input characters or hand over
control to another component, with control transfer made in such a way
that there is no loop without input character consumption.

The main advantage of such an architecture is how easy it is to prove
that in actually terminates, and to prove upper bounds on memory usage.
When components are loosely coupled, which is the case here, it also
makes debugging much easier.

The main drawback is that there is no backtracking possible without
cheating, and very limited look-ahead without severely tightening the
coupling between components.

Moreover, when designing the parser, I enforced very loose coupling
between component by requiring all language elements to be individually
added or removed from the parser. The reason for that is that complete
Markdown is extremely powerful, especially because of raw HTML input
features. That's too powerful for untrusted input, like blog comments or
wikipages. So "unsafe" features have to be optional. But there are
different levels of "unsafety", for example one might want to forbid
titles in blog comments, to prevent untrusted users from messing with
the page layout. Or one might want to forbid all links for
more-untrusted users while allowing them for not-so-untrusted users.
So it seemed better to engineer the parser around making it possible to
allow or forbid any combination of features.

So the online-parser loop variant means that any active character must
have its semantics decided immediately, and the loose coupling means
other language elements cannot interfere in the semantics decision.

Other hand, CommonMark seems to have certain ideas about parser
architecture leaking into the specification. For example the notion of
precedence is directly at odds with the description of the previous
paragraph.

Consider for example the following ambiguous Markdown code, which is
example 239 of current CommonMark specification:
*foo`*`

When the leading star is encountered, my parser has to scan for the
closing star, and doing so without considering the backtick, since
code spans might very well have been disabled. So my parser processes
it as an emphasis that happen to contain a backtick.

Meanwhile, CommonMark prescribes code spans as having a higher
precedence than emphasis, so the example should be parsed as a code span
that happens to contain a star.

As you can imagine, this isn't an isolated example, otherwise working
around it or cheating would have been easy. Most the span-level
examples / specifications actually involve the more general rule of
having "leaf" span elements taking precedence over "container" span
elements. (Which again is fine by itself, I have nothing against it, it
is just poorly compatible with my existing design.)

The precedence of fenced code blocks over reference declarations raises
a similar problem, although to a smaller extent.

I admit I haven't yet looked deeply into the subtleties of block-level
language elements, but even if everything went best on that area, the
parser would still look ridiculous on the test suite without putting
tremendous work.


I will do my best to answer to any question or comments, but because of
various issues, I might need up to a few days to post answers.


Thanks for your attention,
Natacha


pgpOk6adVqOQb.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Proposed improvement to inheritedprivilegessubscripts.

[Scott Robison]

On Sep 28, 2014 12:49 AM, "Stephan Beal"  wrote:
>
> Sidenote: i'm curious why most people prefer postscript addition, when
prefix is "never slower and sometimes faster." (Not that it matters one
iota for a case like this, it just seems to be very deeply embedded in most
people i know.)

I think most people (I am not most people in this case) prefer / use
postfix increment & decrement because it is what they learned first and how
most examples seem to be written. I prefer to use prefix operators (barring
the need for postfix side effects) just because they read more naturally in
my native language. I think it makes more sense when thinking "increment i"
to see "++i". The fact that it is potentially more efficient (though
probably not in practice) is just a bonus. Now if only I could get everyone
on board with making $ for currency a "postfix" operator (because 1$ makes
more sense than $1). :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users