Re: [NTG-context] Alternative for selector in LMTX for different heading and reference texts for descriptions
On Sat, Dec 19, 2020 at 10:43 PM Christoph Reller <
christoph.rel...@gmail.com> wrote:
> Hans Hagen schrieb am Sa., 19. Dez. 2020, 19:16:
>
>> Actually, what you want is:
>>
>> \definedescription[desc]
>> \starttext
>> \startdesc[title={Long title},reference=foo,referencetext={Short
>> Title}]
>> \input jojomayer
>> \stopdesc
>> \about[foo]
>> \stoptext
>>
>> So I'll add that (after all, occasionally we need to add some
>> functionality in order to indicate progress.)
>
>
> Great! That would be a good solution for me.
> Thanks,
> Christoph
>
Thank you for the implementation, Hans!
A small issue: When omitting the referencetext, then the shown text is now
something like "248>desc:referencetext".
MWE:
\definedescription[desc]
\starttext
\startdesc[title=Long title, reference=foo]%, referencetext=Short title]
\input jojomayer
\stopdesc
\about[foo]
\stoptext
For backward compatibility, it might be better to use the title as a
default for the reference test.
Cheers,
Christoph
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Regarding XML export and EPUB
Hello, list. I've been experimenting with the export scripts and the instructions and manuals you can find in: https://wiki.contextgarden.net/XML https://wiki.contextgarden.net/Export https://wiki.contextgarden.net/Epub https://wiki.contextgarden.net/ePub This with the expectation of being able to make an epub file form a context document that epubcheck can accept. I see there is an experimental support for epub, and I have played around with the export options a bit. However, what I would really want to know is. It's possible and if so, how can you map context's elements so they can get translated to specific html tags? I mean, the current export output uses divs with custom attributes and classes, or custom tags; but I would like to map lists to ul, list-items to li, headings to h1, h2, h3, paragraphs to etc. In the manuals I see that you can do the opposite: map xml/html tags to context's elements; I wonder if you can go the other way around, and a good place to start reading about it. Apologies if I missed something obvious. Thank you. -- Andrés Conrado Montoya Andi Kú andresconr...@gmail.com http://sesentaycuatro.com http://messier87.com http://chiquitico.org Los fines no justifican los medios, porque la medida verdadera de nuestro carácter está dada por los medios que estamos dispuestos a utilizar, no por los fines que proclamamos. “You develop an instant global consciousness, a people orientation, an intense dissatisfaction with the state of the world, and a compulsion to do something about it. From out there on the moon, international politics look so petty. You want to grab a politician by the scruff of the neck and drag him a quarter of a million miles out and say, ‘Look at that, you son of a bitch.’” — Apollo 14 astronaut Edgar Mitchell ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Polar pgfplots seems to be broken (Aditya Mahajan)
> Date: Mon, 21 Dec 2020 00:51:06 -0500 (EST)
> From: Aditya Mahajan
>
> On Sun, 20 Dec 2020, Gavin wrote:
>
>> Hello,
>>
>> I’m drawing solar system diagrams using the pgfplots module, but the polar
>> library seem to be broken. It looks like it is calling something with a
>> \begin{axis}... command. Here is the error message for a short document,
>> included below.
>>
>>> tex error > tex error on line 18 in file
>>> /Users/Gavin/Documents/Computer/ConTeXt/Polar Plot
>>> Experiments/Untitled.tex: ! Undefined control sequence
>>>
>>> \pgfplots@environment@polaraxis@ [#1]->\begin
>>> {axis}[#1,data cs=polar,axis
>>> type=polar]
>>> l.18\startpolaraxis[]
>>>
>>> 16 \startsection[title={Polar Plot}]
>>> 17 \starttikzpicture % tikz code
>>> 18 >> \startpolaraxis[]
>>> 19
>>> \addplot+[mark=none,domain=0:720,samples=600]{sin(4*x)};
>>> 20 \stoppolaraxis
>>> 21 \stoptikzpicture
>>> 22 \stopsection
>>>
>>> mtx-context | fatal error: return code: 256
>>
>> I’d love a fix or an idea for a work around.
>
> This is a bug in pgfplots macro pgfplotsdefineaxistype, which uses an
> explicit \begin{axis} ... \end{axis} instead of the more portable \axis ...
> \endaxis. Attached is a quick fix, but it has been quite a while since I
> looked at pgfplots code, so it may be better to post a bug-report on pgfplots
> mailing list for a proper fix.
>
> Aditya
>
> URL:
> <http://mailman.ntg.nl/pipermail/ntg-context/attachments/20201221/d7278aca/attachment.tex>
Aditya,
Thanks for the quick fix! I will post a bug report on the pgfplots mailing
list, including your helpful diagnosis of the problem.
Gavin
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] MetaFun - "remove the paths of text" from a rectangle to let the background visible
> On 21 Dec 2020, at 16:09, Garulfo wrote:
>
> Hi,
>
>
> * I try to "remove the paths of text" from a metapost pictures to let
> the background visible.
>
> * Using
> https://mailman.ntg.nl/pipermail/ntg-context/2018/thread.html#92725
>
> * I was able to get the following with one glyph (MVE code below)
>
> https://wiki.contextgarden.net/images/d/d2/test_extract_glyphs.pdf
>
>
> 2 questions:
>
> 1/ for some fonts (e.g. dejavu vs latin modern) the "encompassing" path
> of the B glyph can switch from B[1] to B[Bn]. Is there a trick to
> identify which id match with "the encompassing" path ?
What you get is the order of the paths as defined in the font, which is
arbitrary, as you discovered.
A quick trick (that will not always work, but should work quite well for font
variations of alphabetics) is to check the actual arclength of the paths. The
longest one will typically be the outer one.
But much depends on the font, so a generic solution is likely quite
complicated. Consider an outline font’s colon glyph ;)
>
> 2/ now, I would like to do the same, but for text... a kind of
> derivative of "textext" or "outlinetext".
> Would you please give me some guidelines ?
> does it already exist ?
> should I use something like \handletokens, \scantokens ?
> do you have examples where I can get inspiration ?
>
>
> Thanks again for your help,
> Garulfo
>
>
> %==
>
>
>
>
> \starttext
>
> %--
>
> \startluacode
>
> function document.outlinepaths(character)
>local chardata = fonts.hashes.characters[true] -- by unicode
>local shapedata = fonts.hashes.shapes[true] -- by index
>local c = chardata[character]
>if c and c.index and shapedata then
>local shapeglyphs = shapedata.glyphs or { }
>local glyph = shapeglyphs[c.index]
>if glyph and (glyph.segments or glyph.sequence) then
>local units = shapedata.units or 1000
>local factor = 100/units
>return fonts.metapost.paths(glyph,factor)
>end
>end
>return { }
> end
>
> function document.defineoutline(char,target)
>local outlines = document.outlinepaths(char)
>local nofpaths = #outlines
>context("path %s[] ;",target)
>context("numeric %sn ; %sn := %s ;",target,target,nofpaths)
>for i=1,nofpaths do
>context("%s[%i] := %s ; ",target,i,outlines[i])
>end
> end
>
> \stopluacode
>
> %--
>
> \def\mpdefineoutlines#1#2{\ctxlua{document.defineoutline(\number`#1,"#2")}}
>
> %--
>
> \startMPpage
>
> numeric dimA ; dimA := 20cm;
>
> path pathbackground ;
> pathbackground := unitsquare scaled dimA ;
> fill pathbackground withshademethod "linear" withshadedirection(0,1)
> withshadecolors (red,blue);
>
> %--
>
> \mpdefineoutlines{B}{B}
>
> %--
>
> numeric dimB ; dimB := 2cm;
> numeric vratio ; vratio := 2;
>
> path frame ;
> frame := unitsquare
> xscaled (dimA - 2 * dimB)
> yscaled (dimA / vratio)
> shifted (dimB , (dimA - (dimA / vratio))/2 );
>
> %--
>
> pair shift ; shift := center frame;
> numeric scal ; scal := (0.9) * (10cm / (bbheight B[1])) ;
>
> picture monImageB; monImageB := nullpicture;
> addto monImageB contour
> (B[1] shifted (- center B[1]) scaled scal)
> shifted shift
> withpostscript "collect";
>
> addto monImageB contour
> frame
> withpostscript "evenodd";
>
> for i=2 upto Bn :
> addto monImageB contour
>(B[i] shifted (- center B[1]) scaled scal)
>shifted shift;
> endfor ;
>
> %--
>
> draw monImageB withcolor white;
>
> \stopMPpage
>
> \stoptext
> ___
> If your question is of interest to others as well, please add an entry to the
> Wiki!
>
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage : http://www.pragma-ade.nl / http://context.aanhet.net
> archive : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___
Taco Hoekwater
Elvenkind BV
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
[NTG-context] MetaFun - "remove the paths of text" from a rectangle to let the background visible
Hi,
* I try to "remove the paths of text" from a metapost pictures to let
the background visible.
* Using
https://mailman.ntg.nl/pipermail/ntg-context/2018/thread.html#92725
* I was able to get the following with one glyph (MVE code below)
https://wiki.contextgarden.net/images/d/d2/test_extract_glyphs.pdf
2 questions:
1/ for some fonts (e.g. dejavu vs latin modern) the "encompassing" path
of the B glyph can switch from B[1] to B[Bn]. Is there a trick to
identify which id match with "the encompassing" path ?
2/ now, I would like to do the same, but for text... a kind of
derivative of "textext" or "outlinetext".
Would you please give me some guidelines ?
does it already exist ?
should I use something like \handletokens, \scantokens ?
do you have examples where I can get inspiration ?
Thanks again for your help,
Garulfo
%==
\starttext
%--
\startluacode
function document.outlinepaths(character)
local chardata = fonts.hashes.characters[true] -- by unicode
local shapedata = fonts.hashes.shapes[true] -- by index
local c = chardata[character]
if c and c.index and shapedata then
local shapeglyphs = shapedata.glyphs or { }
local glyph = shapeglyphs[c.index]
if glyph and (glyph.segments or glyph.sequence) then
local units = shapedata.units or 1000
local factor = 100/units
return fonts.metapost.paths(glyph,factor)
end
end
return { }
end
function document.defineoutline(char,target)
local outlines = document.outlinepaths(char)
local nofpaths = #outlines
context("path %s[] ;",target)
context("numeric %sn ; %sn := %s ;",target,target,nofpaths)
for i=1,nofpaths do
context("%s[%i] := %s ; ",target,i,outlines[i])
end
end
\stopluacode
%--
\def\mpdefineoutlines#1#2{\ctxlua{document.defineoutline(\number`#1,"#2")}}
%--
\startMPpage
numeric dimA ; dimA := 20cm;
path pathbackground ;
pathbackground := unitsquare scaled dimA ;
fill pathbackground withshademethod "linear" withshadedirection(0,1)
withshadecolors (red,blue);
%--
\mpdefineoutlines{B}{B}
%--
numeric dimB ; dimB := 2cm;
numeric vratio ; vratio := 2;
path frame ;
frame := unitsquare
xscaled (dimA - 2 * dimB)
yscaled (dimA / vratio)
shifted (dimB , (dimA - (dimA / vratio))/2 );
%--
pair shift ; shift := center frame;
numeric scal ; scal := (0.9) * (10cm / (bbheight B[1])) ;
picture monImageB; monImageB := nullpicture;
addto monImageB contour
(B[1] shifted (- center B[1]) scaled scal)
shifted shift
withpostscript "collect";
addto monImageB contour
frame
withpostscript "evenodd";
for i=2 upto Bn :
addto monImageB contour
(B[i] shifted (- center B[1]) scaled scal)
shifted shift;
endfor ;
%--
draw monImageB withcolor white;
\stopMPpage
\stoptext
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
On 12/21/2020 3:10 PM, Mojca Miklavec wrote:
lpeg.P('b') + lpeg.P('bb') + lpeg.P('bbb')
always put the longest (for overlapping) first, in this case you could do:
P('b')^-3
at most 3
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Problem with \Caps
Hi Joaquín,
Actually it depends on the font you are using, but on th eother hand it seems
that \Caps is broken in LMTX.
The following gives a correct result in mkiv but results in an error in LMTX:
\setupbodyfont[lucidaot]
\starttext
Test {\sc Test} {\Caps Test}
{\smallcaps Test}
\meaning\Caps
\stoptext
Best regards: Otared
> On 20 Dec 2020, at 18:59, Joaquín Ataz López wrote:
>
>
> Good day to everyone. I have a problem that may be very simple to solve, but
> for which I have not found an answer in the wiki.
>
> Until relatively recently I was using the January 2020 version of ConTeXt
> Standalone, recently I have updated it to the December 18th version, and when
> I compile a file that I used to compile well, an error is generated because
> the \Caps macro is not recognized.
>
> I can't get the desired effect with \sc, it has to be with \Caps.
>
> I have tried to compile it with LMTX but there too is considered that \Caps
> is an undefined control sequence.
>
>
> --
> Joaquín Ataz López
> Derecho Civil
> Universidad de Murcia
>
> ___
> If your question is of interest to others as well, please add an entry to the
> Wiki!
>
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage : http://www.pragma-ade.nl / http://context.aanhet.net
> archive : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
Hi, Also good reading are the first sections in Roberto’s paper: http://www.inf.puc-rio.br/~roberto/docs/peg.pdf > > In reality it just means that I was trying to add a new rule to solve > the second part of the puzzle (hidden on the website until you solve > the first part), which read something like >6: 3 | 3 6 > which would in theory be translated into something like >r6 = lpeg.V"r3" + lpeg.V"r3" * lpeg.V"r6", > if PEGs worked the way I imagined they worked, that is. Apparently they don't > :) Try this, blind guess: r6 = lpeg.V"r3" * lpeg.V”r6” + lpeg.V"r3", Best wishes, Taco Taco Hoekwater Elvenkind BV ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Title in enumeration not working?
Hi Mikael,
Indeed you are right about the fact that
> \startexample[title={Title}]
> ...
> \stopexample
is more logical and also more convenient.
Sorry for not having checked your example in mkiv, where this structure works
as intended.
So it might be a small buglet in LMTX.
Best regards: Otared
> On 21 Dec 2020, at 14:06, Mikael Sundqvist wrote:
>
> Hi Otared,
>
> Thank you for your suggestion. I would say yes and no.
>
> I want the result one gets from what you write, but I prefer the syntax
>
> \startexample[title={Title}]
> ...
> \stopexample
>
> and that has been working before. Reading in setup-en.pdf, it also looks to
> me as if that should work.
>
> Best,
>
> Mikael
>
> On Mon, Dec 21, 2020 at 11:47 AM Otared Kavian > wrote:
> Hi Mickael,
>
> Maybe this is what you want:
>
> \defineenumeration[example]
> [text=Example,
> title=yes,
> titleleft=,
> titleright={.},
> ]
>
> \starttext
> \startexample{Title}
> This is a test.
> \stopexample
> \stoptext
>
> Of course is you say
> text=,
> then you get only « Title » and a number in front of it.
>
> Best regards: OK
>
> > On 21 Dec 2020, at 11:05, Mikael Sundqvist > > wrote:
> >
> > Hi,
> >
> > Has anything changed with titles and enumerations? I expected a title
> > "Title" with the following setup.
> >
> > \defineenumeration[example][
> > text=Example,
> > title=yes,
> > ]
> >
> > \starttext
> > \startexample[title={Title}]
> > This is a test.
> > \stopexample
> > \stoptext
> >
> > But it does not show up.
> >
> > /Mikael
> >
> >
> > ___
> > If your question is of interest to others as well, please add an entry to
> > the Wiki!
> >
> > maillist : ntg-context@ntg.nl /
> > http://www.ntg.nl/mailman/listinfo/ntg-context
> >
> > webpage : http://www.pragma-ade.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
> webpage : http://www.pragma-ade.nl
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
Hi,
Thanks to both Taco and Arthur for clarifying this and pointing out
the difference between PEG and PCRE.
I'll put some links like
https://en.wikipedia.org/wiki/Parsing_expression_grammar
https://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions
on my reading list and try to understand it more thoroughly than I do
at the moment.
After that I'll probably need to re-read Taco's answer a couple more
times, and probably write some parsing grammar as an exercise, but
I'll eventually get there :)
Just a correction of my previous statement. The following doesn't
really work either:
lpeg.P('b') + lpeg.P('bb') + lpeg.P('bbb')
it just happened to work in one particular case on my minimal example,
but it doesn't help in general.
That's probably expected based on what Arthur and Taco explained to me.
> In your example, the fact that you even considered ^1 means that you were
> still thinking too much in terms of regular expressions,
In reality it just means that I was trying to add a new rule to solve
the second part of the puzzle (hidden on the website until you solve
the first part), which read something like
6: 3 | 3 6
which would in theory be translated into something like
r6 = lpeg.V"r3" + lpeg.V"r3" * lpeg.V"r6",
if PEGs worked the way I imagined they worked, that is. Apparently they don't :)
It seemed so obvious, but it would be too easy if it was true ;),
so it will force me to solve it "ab initio" (as it was initially meant) anyway.
Thanks a lot to everyone for the extra patience to explain me those
basic principles & differences,
Mojca
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
On 12/21/2020 1:16 PM, Mojca Miklavec wrote: I'm sorry for being slightly off-topic here, but this list might still be the best place to resolve lpeg-related questions :) spoiler attached ... doesn't deserve a beauty contest price not one for performence (not much different from your btw) but maybe easier for testing all kind of variants (i cannot use context helpers of course) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
On Mon, Dec 21, 2020 at 2:36 PM Taco Hoekwater wrote:
>
>
> > On 21 Dec 2020, at 14:08, Mojca Miklavec
> wrote:
> >
> > Dear Taco,
> >
> > On Mon, 21 Dec 2020 at 13:46, Taco Hoekwater wrote:
> >>> On 21 Dec 2020, at 13:16, Mojca Miklavec wrote:
> >>>
> >>> My only explanation would be that perhaps "^1" is so greedy that the
> >>> rest of the pattern doesn't get found. But I don't want to believe
> >>> that explanation.
> >>
> >> Which (of course) means that that is exactly what happens ;)
> >>
> >> The ones that match are
> >>
> >> ababbb (a (ba+bb) b) => r4 r1(r3(r5 r4) r2(r5 r5)) r5
> >> abbbab (a (bb+ba) b) => r4 r1(r2(r5 r5) r3(r5 r4)) r5
> >>
> >> With the ^1, in the “bb” cases the first “b” eats all three “b”s:
> >>
> >> ababbb fails the r5 at the end
> >>
> >> abbbab fails the first r2 already (since the second r5 therein never
> happens)
> >
> > Is this a deliberate choice, a limitation of the grammar
> > expressiveness, some misuse on my side that could/should/needs to be
> > implemented in a different way, or does it count as a "bug" on the
> > lpeg side?
> >
> > For example, I wouldn't expect a regexp "b+b" to fail on "bbb" just
> > because "b+" would eat all three "b"s at once (the regexp "b+b" in
> > fact finds "bbb", and I would expect a less-than-totally-greedy hit
> > with lpeg as well). Or is my reasoning wrong here?
>
> PEGs are greedy by design, which is a consequence of the fact that PEGS do
> not backtrack, which goes back to the underlying assumptive rule of PEGs
> that there is one (and only one!) ‘correct’ way to parse the input.
> Allowing backtracking destroys that assumption and by doing so would
> complicate the system to a level that would make it comparable to PCRE
> (with all the associated penalties on processing speed and a much greater
> codebase).
>
greedy vs non-greedy is one of the things that I always keep in mind when I
start with lpeg, and regularly I fail to apply -- because I think in the
"perl regex way".
Anyway,
http://www.gammon.com.au/lpeg
has some good lines:
e.g. this one (from the lpeg site) find the pattern anywhere in the line:
function anywhere (p)
return lpeg.P { p + 1 * lpeg.V(1) }
end
print (lpeg.match (anywhere ("dog"), target))
--
luigi
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
On Mon, Dec 21, 2020 at 02:08:11PM +0100, Mojca Miklavec wrote: > Is this a deliberate choice, a limitation of the grammar > expressiveness, some misuse on my side that could/should/needs to be > implemented in a different way, or does it count as a "bug" on the > lpeg side? That’s definitely the way parsing expression grammars work. Or rather: that’s the way LPeg (the only parsing expression grammar) works :-) > For example, I wouldn't expect a regexp "b+b" to fail on "bbb" just > because "b+" would eat all three "b"s at once (the regexp "b+b" in > fact finds "bbb", and I would expect a less-than-totally-greedy hit > with lpeg as well). Or is my reasoning wrong here? Your reasoning is correct, but applies to regular expressions, not parsing-expression grammars. Arthur ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
> On 21 Dec 2020, at 14:08, Mojca Miklavec > wrote: > > Dear Taco, > > On Mon, 21 Dec 2020 at 13:46, Taco Hoekwater wrote: >>> On 21 Dec 2020, at 13:16, Mojca Miklavec wrote: >>> >>> My only explanation would be that perhaps "^1" is so greedy that the >>> rest of the pattern doesn't get found. But I don't want to believe >>> that explanation. >> >> Which (of course) means that that is exactly what happens ;) >> >> The ones that match are >> >> ababbb (a (ba+bb) b) => r4 r1(r3(r5 r4) r2(r5 r5)) r5 >> abbbab (a (bb+ba) b) => r4 r1(r2(r5 r5) r3(r5 r4)) r5 >> >> With the ^1, in the “bb” cases the first “b” eats all three “b”s: >> >> ababbb fails the r5 at the end >> >> abbbab fails the first r2 already (since the second r5 therein never happens) > > Is this a deliberate choice, a limitation of the grammar > expressiveness, some misuse on my side that could/should/needs to be > implemented in a different way, or does it count as a "bug" on the > lpeg side? > > For example, I wouldn't expect a regexp "b+b" to fail on "bbb" just > because "b+" would eat all three "b"s at once (the regexp "b+b" in > fact finds "bbb", and I would expect a less-than-totally-greedy hit > with lpeg as well). Or is my reasoning wrong here? PEGs are greedy by design, which is a consequence of the fact that PEGS do not backtrack, which goes back to the underlying assumptive rule of PEGs that there is one (and only one!) ‘correct’ way to parse the input. Allowing backtracking destroys that assumption and by doing so would complicate the system to a level that would make it comparable to PCRE (with all the associated penalties on processing speed and a much greater codebase). Another way of thinking of it (perhaps that helps): PEGs are _declarative_ on the input, whereas REs are _interpretive_. Yet another way of thinking about it: PEGs rigorously define the (programming) language of the input. It takes a bit of rewiring your brain to get comfortable with PEGs when you are used to REs, and unpredictable input is much harder to tackle in PEGs. OTOH, using PEGs are much better if there is an explicit grammar. In your example, the fact that you even considered ^1 means that you were still thinking too much in terms of regular expressions, but I know it is very hard to learn how to do something that is _only a little_ different from something you know well already. Best wishes, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
Dear Taco,
On Mon, 21 Dec 2020 at 13:46, Taco Hoekwater wrote:
> > On 21 Dec 2020, at 13:16, Mojca Miklavec wrote:
> >
> > My only explanation would be that perhaps "^1" is so greedy that the
> > rest of the pattern doesn't get found. But I don't want to believe
> > that explanation.
>
> Which (of course) means that that is exactly what happens ;)
>
> The ones that match are
>
> ababbb (a (ba+bb) b) => r4 r1(r3(r5 r4) r2(r5 r5)) r5
> abbbab (a (bb+ba) b) => r4 r1(r2(r5 r5) r3(r5 r4)) r5
>
> With the ^1, in the “bb” cases the first “b” eats all three “b”s:
>
> ababbb fails the r5 at the end
>
> abbbab fails the first r2 already (since the second r5 therein never happens)
Is this a deliberate choice, a limitation of the grammar
expressiveness, some misuse on my side that could/should/needs to be
implemented in a different way, or does it count as a "bug" on the
lpeg side?
For example, I wouldn't expect a regexp "b+b" to fail on "bbb" just
because "b+" would eat all three "b"s at once (the regexp "b+b" in
fact finds "bbb", and I would expect a less-than-totally-greedy hit
with lpeg as well). Or is my reasoning wrong here?
It certainly works if I use
lpeg.P('b') + lpeg.P('bb') + lpeg.P('bbb') -- and a couple more
(as long as I can predict the maximum length)
but that's not really a viable workaround in general.
Thank you,
Mojca
PS: sorry, a tiny bug also crippled into my sample code. The line
after matching the 'parser1' should have used 'total1' rather than
'total':
if lpeg.match(parser1, s) then
total1 = total1 + 1
end
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Title in enumeration not working?
Hi Otared,
Thank you for your suggestion. I would say yes and no.
I want the result one gets from what you write, but I prefer the syntax
\startexample[title={Title}]
...
\stopexample
and that has been working before. Reading in setup-en.pdf, it also looks to
me as if that should work.
Best,
Mikael
On Mon, Dec 21, 2020 at 11:47 AM Otared Kavian wrote:
> Hi Mickael,
>
> Maybe this is what you want:
>
> \defineenumeration[example]
> [text=Example,
> title=yes,
> titleleft=,
> titleright={.},
> ]
>
> \starttext
> \startexample{Title}
> This is a test.
> \stopexample
> \stoptext
>
> Of course is you say
> text=,
> then you get only « Title » and a number in front of it.
>
> Best regards: OK
>
> > On 21 Dec 2020, at 11:05, Mikael Sundqvist wrote:
> >
> > Hi,
> >
> > Has anything changed with titles and enumerations? I expected a title
> "Title" with the following setup.
> >
> > \defineenumeration[example][
> > text=Example,
> > title=yes,
> > ]
> >
> > \starttext
> > \startexample[title={Title}]
> > This is a test.
> > \stopexample
> > \stoptext
> >
> > But it does not show up.
> >
> > /Mikael
> >
> >
> >
> ___
> > If your question is of interest to others as well, please add an entry
> to the Wiki!
> >
> > maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> > webpage : http://www.pragma-ade.nl / http://context.aanhet.net
> > archive : https://bitbucket.org/phg/context-mirror/commits/
> > wiki : http://contextgarden.net
> >
> ___
>
>
> ___
> If your question is of interest to others as well, please add an entry to
> the Wiki!
>
> maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage : http://www.pragma-ade.nl / http://context.aanhet.net
> archive : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
>
> ___
>
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
> On 21 Dec 2020, at 13:46, Taco Hoekwater wrote: > > > >> On 21 Dec 2020, at 13:16, Mojca Miklavec >> wrote: >> >> My only explanation would be that perhaps "^1" is so greedy that the >> rest of the pattern doesn't get found. But I don't want to believe >> that explanation. > > Which (of course) means that that is exactly what happens ;) > > The ones that match are > > ababbb (a (ba+bb) b) => r4 r1(r3(r5 r4) r2(r5 r5)) r5 > abbbab (a (bb+ba) b) => r4 r1(r2(r5 r5) r3(r5 r4)) r5 > > With the ^1, in the “bb” cases the first “b” eats all three “b”s: > > ababbb fails the r5 at the end Sorry, that was wrong, it fails at the second r5 in the r2 as well, for the same reason as below. > > abbbab fails the first r2 already (since the second r5 therein never happens) > > Best wishes, > Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Off-topic: Struggles with LPEG grammar
> On 21 Dec 2020, at 13:16, Mojca Miklavec > wrote: > > My only explanation would be that perhaps "^1" is so greedy that the > rest of the pattern doesn't get found. But I don't want to believe > that explanation. Which (of course) means that that is exactly what happens ;) The ones that match are ababbb (a (ba+bb) b) => r4 r1(r3(r5 r4) r2(r5 r5)) r5 abbbab (a (bb+ba) b) => r4 r1(r2(r5 r5) r3(r5 r4)) r5 With the ^1, in the “bb” cases the first “b” eats all three “b”s: ababbb fails the r5 at the end abbbab fails the first r2 already (since the second r5 therein never happens) Best wishes, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] Off-topic: Struggles with LPEG grammar
Hi,
I'm sorry for being slightly off-topic here, but this list might still
be the best place to resolve lpeg-related questions :)
0.) Disclaimer: the challenge that triggered this curiosity came from
Advent of Code 2020. In case you are taking part and you wan't to
avoid spoilers, please stop reading here! (You have been warned.)
https://adventofcode.com/2020/day/19
1.) My question: I don't understand why I cannot get ^1 to work "as
advertised". Isn't this supposed to mean "one or more occurences of
the pattern"? If I change "lpeg.P('b')" into "lpeg.P('b')^1" in the
example below, the strings that match the initial grammar no longer
match the modified grammar. (I would naively imagine that the secord
pattern would get more rather than less matches.)
2.) Background: Most definitely the task on that page is supposed to
be solved in a different way, but many people use Advent of Code as an
opportunity to learn a new programming language, and when I read the
task description, I wanted to figure out if I could solve it using the
cute little lpeg. My initial attempt worked correctly (at least to
solve the first puzzle), but then I realized that I cannot easily
change the pattern from "matches a letter b" into "matches any number
of b-s", and I fail to figure out why. Any hints would be greatly
appreciated.
Below is a not-so-minimal example. I can certainly try to reduce it
further, but I would first like to ask whether I'm doing something
obviously wrong by trying to replace
r5 = lpeg.P('b')
by
r5 = lpeg.P('b')^1
in order to allow more than one occurrences of the letter b?
My only explanation would be that perhaps "^1" is so greedy that the
rest of the pattern doesn't get found. But I don't want to believe
that explanation.
local lpeg = require "lpeg"
--[[
0: 4 1 5
1: 2 3 | 3 2
2: 4 4 | 5 5
3: 4 5 | 5 4
4: "a"
5: "b"
]]--
local parser = lpeg.P{
"r0";
r0 = lpeg.V"r4" * lpeg.V"r1" * lpeg.V"r5",
r1 = lpeg.V"r2" * lpeg.V"r3" + lpeg.V"r3" * lpeg.V"r2",
r2 = lpeg.V"r4" * lpeg.V"r4" + lpeg.V"r5" * lpeg.V"r5",
r3 = lpeg.V"r4" * lpeg.V"r5" + lpeg.V"r5" * lpeg.V"r4",
r4 = lpeg.P('a'),
r5 = lpeg.P('b'),
} * -1
local parser1 = lpeg.P{
"r0";
r0 = lpeg.V"r4" * lpeg.V"r1" * lpeg.V"r5",
r1 = lpeg.V"r2" * lpeg.V"r3" + lpeg.V"r3" * lpeg.V"r2",
r2 = lpeg.V"r4" * lpeg.V"r4" + lpeg.V"r5" * lpeg.V"r5",
r3 = lpeg.V"r4" * lpeg.V"r5" + lpeg.V"r5" * lpeg.V"r4",
r4 = lpeg.P('a'),
r5 = lpeg.P('b')^1, -- modified part that doesn't seem to work
} * -1
strings = {
"ababbb",
"bababa",
"abbbab",
"aaabbb",
"bbb",
};
local total = 0
local total1 = 0
for _, s in ipairs(strings) do
if lpeg.match(parser, s) then
total = total + 1
end
if lpeg.match(parser1, s) then
total = total + 1
end
end
print('total:', total, total1)
In this example, total=2, total1=0.
What I don't understand is why total1 is zero.
Thank you,
Mojca
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Problem with shading in Metafun (LMTX)
Nice. It works again. Thank you very much!
Cordially,
Jairo
El lun., 21 de dic. de 2020 2:45 a. m., Hans Hagen
escribió:
> On 12/21/2020 4:46 AM, Jairo A. del Rio wrote:
> > While shading works with MkIV, with LMTX the following breaks:
> >
> >
> > \startMPpage
> >
> > comment("two shades with named colors");
> >
> > fill fullcircle scaled 5cm
> >
> > withshademethod "circular"
> >
> > withshadecolors ((1,0,0),(0,0,1,0))
> >
> > ;
> >
> > fill fullcircle scaled 5cm shifted (6cm,0)
> >
> > withshademethod "circular"
> >
> > withcolor (1,0,0,0) shadedinto "blue"
> >
> > ;
> >
> > \stopMPpage
>
> in mp-base.mpxl there is a ; missing
>
> temp_any_u = u
>
> must be:
>
> temp_any_u := u ;
>
> (in the min and max macros)
>
> (i replaced some internal names as part of a cleanup)
>
> (there will be a new upload later that will also fix this)
>
> Hans
>
> -
>Hans Hagen | PRAGMA ADE
>Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
> tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
> -
>
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Title in enumeration not working?
Hi Mickael,
Maybe this is what you want:
\defineenumeration[example]
[text=Example,
title=yes,
titleleft=,
titleright={.},
]
\starttext
\startexample{Title}
This is a test.
\stopexample
\stoptext
Of course is you say
text=,
then you get only « Title » and a number in front of it.
Best regards: OK
> On 21 Dec 2020, at 11:05, Mikael Sundqvist wrote:
>
> Hi,
>
> Has anything changed with titles and enumerations? I expected a title "Title"
> with the following setup.
>
> \defineenumeration[example][
> text=Example,
> title=yes,
> ]
>
> \starttext
> \startexample[title={Title}]
> This is a test.
> \stopexample
> \stoptext
>
> But it does not show up.
>
> /Mikael
>
>
> ___
> If your question is of interest to others as well, please add an entry to the
> Wiki!
>
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage : http://www.pragma-ade.nl / http://context.aanhet.net
> archive : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Title in enumeration not working?
Hi,
Has anything changed with titles and enumerations? I expected a title
"Title" with the following setup.
\defineenumeration[example][
text=Example,
title=yes,
]
\starttext
\startexample[title={Title}]
This is a test.
\stopexample
\stoptext
But it does not show up.
/Mikael
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
