- dev-context - NTG Mailing Lists

Solarized colors
by Aditya Mahajan 13 Feb '17

13 Feb '17

Hi, I am wondering if there is any interest in adding solarized colors to the core. I am attaching colo-imp-solarized.mkiv file. (Essentially the same file will work in MkII). For those who do not know, solarized (http://ethanschoonover.com/solarized) is a 16 color palatte designed with a precise LAB lightness between the colors and is supposed to work well in a variety of lighting conditions. I have named the colors such that loading this will override the default color values of yello, orange, red, magenta, violet, blue, cyan, and green (X11 does the same, but X11's color definitions match the default). Another option is to either use CamelCase names or names such as 'solarizedYellow', etc. If you think that it is not worth having such small color palattes in the core, then I can create a separate module that collects these. Aditya

2 2

Re: [dev-context] local allocation in ConTeXt
by Sašo Živanović 26 Jan '17

26 Jan '17

Dear Hans, thank you very much for helping me out here. Aditya's rephrasal of the question might have shown a tree but hidden the forest ... ;-) Let me try to explain below, but please also take a look at my original post, https://mailman.ntg.nl/pipermail/dev-context/2016/003346.html. As far as I can see, in your 10 million example I can only work on one of the local boxes at the time, whereas I need to save an undetermined number of boxes, do some computation which uses dimensions of all these boxes (this computation potentially invokes user's code, so I don't have control over it), and then use all the saved boxes. (Btw, saving just the dimensions is not an acceptable solution, both because of speed and because in general, setting the box with same content twice won't yield the same result.) As the number of needed boxes cannot be known in advance, I'd like to be nice and "give them back" to the allocation system after using them. And I *do* know how to do that (see localloc, elocalloc, or etex), but I'm not sure if it would cause any trouble in ConTeXt: I'd prefer "not to mess with allocation" indeed and have the issue fixed systemically. > The overhead is just one box per name and you probably don't allocate > a million unique tempboxes as you will then already ran out of names. I believe this overhead is precisely what I'm trying to avoid. A further detail of my situation might help. I've got, for each node of the tree: \locbox\tempbox \setbox\tempbox\hbox{...} \expandafter\let\csname node<id>@box\endcsname\tempbox > Messing with the allocation can fail because when the content of the > boxes triggers a new box allocation itself that one might be forgotten > as well. I'm not sure I get this. Even if the new box allocation was global (so, the usual \newbox)? Best, Sašo P.S. And I did test it! Albeit with two iterations, not ten million. ;-) On 24. 01. 2017 13:48, Hans Hagen wrote: > On 1/24/2017 10:47 AM, Sašo Živanović wrote: >> I'm afraid this doesn't do the trick: \c_syst_last_allocated_box is >> definitely incremented. >> >> Let me try explaining again. This is essentially what I do: >> >> { >> \newbox\TempBox >> \setbox\TempBox\hbox{Box One} >> \let\BoxOne\TempBox >> \global\let\TempBox\relax >> >> \newbox\TempBox >> \setbox\TempBox\hbox{Box Two} >> \let\BoxTwo\TempBox >> \global\let\TempBox\relax >> >> \the\numexpr\BoxOne: [\box\BoxOne] >> \the\numexpr\BoxTwo: [\box\BoxTwo] >> } >> >> But I want the number of available box registers at entering and exiting >> the group to be the same, and substituting \newbox for \locbox is what >> does the trick in my package. So I can run the following a million times: >> >> { >> \newlocalbox\TempBox >> \setbox\TempBox\hbox{Box One} >> \let\BoxOne\TempBox >> \global\let\TempBox\relax >> >> \newlocalbox\TempBox >> \setbox\TempBox\hbox{Box Two} >> \let\BoxTwo\TempBox >> \global\let\TempBox\relax >> >> \the\numexpr\BoxOne: [\box\BoxOne] >> \the\numexpr\BoxTwo: [\box\BoxTwo] >> } >> >> Each of the million "\the\numexpr\BoxOne" should produce the same >> number, whereas in the \newbox-based example these numbers increment. > > I suppose you didn't test it ... > > \starttext > > % \unprotect > % > % \installcorenamespace{localbox} > % > % \unexpanded\def\newlocalbox#1% > % {\expandafter\let\expandafter#1\csname\??localbox\string#1\endcsname > % \ifx#1\relax > % \syst_aux_new_localbox#1% > % \fi} > % > % \def\syst_aux_new_localbox#1% > % {\expandafter\newbox\csname\??localbox\string#1\endcsname > % \newlocalbox#1} > % > % \protect > > \newbox\MyBoxA \number\MyBoxA > > \dorecurse{10} { > \dorecurse{1000000} { > \newlocalbox\TempBox > } > \writestatus{!!!}{#1 million done} > #1: \number\TempBox\par > } > > \newbox\MyBoxB \number\MyBoxB > > \stoptext > > The overhead is just one box per name and you probably don't allocate a > million unique tempboxes as you will then already ran out of names. > > Messing with the allocation can fail because when the content of the > boxes triggers a new box allocation itself that one might be forgotten > as well. > >> Best, >> Sašo >> >> On 24. 01. 2017 09:52, Hans Hagen wrote: >>>> You are asking how to define a macro, \locbox, such that the following >>>> code should not change the value of \c_syst_last_allocated_box. >>>> >>>> \bgroup >>>> \locbox\BoxOne >>>> \locbox\BoxTwo >>>> >>>> \BoxOne\hbox{Box One} >>>> \BoxTow\hbox{Box Two} >>>> % Do some measurement based on the size of the boxes >>>> \egroup >>>> >>>> The fact that a LaTeX package implements this behaviour by allocating >>>> local box numbers from the end seems to be an implementation detail. >>>> >>>> I don't know the best way to implement such a macro in ConTeXt, but I >>>> want to make sure that the user-level behavior that you want is >>>> properly >>>> understood. Given the details in your question, one can easily lose the >>>> forest for the trees (pun intended :-) >>> >>> \unprotect >>> >>> \installcorenamespace{localbox} >>> >>> \unexpanded\def\newlocalbox#1% >>> {\expandafter\let\expandafter#1\csname\??localbox\string#1\endcsname >>> \ifx#1\relax >>> \syst_aux_new_localbox#1% >>> \fi} >>> >>> \def\syst_aux_new_localbox#1% >>> {\expandafter\newbox\csname\??localbox\string#1\endcsname >>> \newlocalbox#1} >>> >>> \protect >>> >>> \starttext >>> >>> \newlocalbox\BoxOne >>> \newlocalbox\BoxTwo >>> >>> \setbox\BoxOne\hbox{Box One} >>> \setbox\BoxTwo\hbox{Box Two} >>> >>> [\box\BoxTwo] >>> [\box\BoxOne] >>> >>> \let\locbox\newlocalbox >>> >>> \stoptext >>> >>> ----------------------------------------------------------------- >>> Hans Hagen | PRAGMA ADE >>> Ridderstraat 27 | 8061 GH Hasselt | The Netherlands >>> tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl >>> ----------------------------------------------------------------- >>> _______________________________________________ >>> dev-context mailing list >>> dev-context(a)ntg.nl >>> https://mailman.ntg.nl/mailman/listinfo/dev-context >> > >

2 5

local allocation in ConTeXt
by Sašo Živanović 24 Jan '17

24 Jan '17

Hi! I'm the author of a PGF/TikZ-based LaTeX package Forest for drawing (linguistic) trees. I have received several requests to support ConTexT and I'm trying to do that now. Forest uses a lot of \boxes. Actually, the number of boxes used cannot be known in advance, as it depends on the document. Here's why: Forest's main job is to place the nodes of a tree so that they don't overlap and to do that, it needs to first typeset the individual nodes and measure them. The typeset nodes are kept around and later used when typesetting the entire tree. There are three reasons for keeping the typeset nodes, and not typesetting them again as part of the entire tree. First (at least historically): performance. Second: there is no guarantee that running the same code twice will result in the same box. Third: changing this now would break compatibility. The typeset nodes are kept in "local" boxes. They are created using \locbox, which is defined either by plain eTeX format or package elocalloc.sty for LaTeX >2015. (Prior to LaTeX 2015, \locbox was defined in etex.sty.) elocalloc.sty's \locbox is somewhat broken, but still works, mainly because it seems no other package is using local allocation. ;-) Using normal, "global" boxes, created by \newbox, would be bad. If a \newbox was simply executed for each new node, the number of used boxes would remain increased even after Forest was done with a tree, so in a document with lots of big trees, the upper limit of 32000+ could actually be hit. An alternative approach would be to track and reuse boxes which were created by \newbox by are not used anymore. But implementing such a tracking mechanism seems quite complicated, and besides, it would not be perfect: after exiting the TeX group where the tree is drawn, the allocated boxes would persist. (So, from the outside perspective, Forest's box usage in the entire document would equal the box usage of the largest tree.) The approach taken in the implementation of \locbox seems quite appealing in its simplicity: The local boxes (counts etc) are allocated "from the top" (starting at 32767 and going down) and all the \chardefs and allocation register changes are local (i.e. not \global). A bit of care to prevent clashes with global allocation "from the bottom", and that's it. I've studied the allocation mechanism of ConTeXt --- but note that I'm new to ConTeXt! --- and it seems that I'd know how to implement \loc<thing>s using "from the top" approach, but there are two, or rather three, problems. (I took a look at both MKII and MKIV, but the changes seemed mostly cosmetic, so I concentrated on MKIV.) 1. I'm not sure how happy ConTeXt were if I changed the value of \c_syst_max_allocated_register. The name seems to imply it should be constant. 2. Simply decreasing \c_syst_max_allocated_register would while doing a \locbox would also decrease the upper limit for, say, \loccount, as they use the same upper limit, i.e. \c_syst_max_allocated_register. A proper way would be to declare \c_syst_max_allocated_box_register etc. Again, I have no idea how such a change would impact other parts of the system. (Btw, elocalloc.sty's implementation, unlike the plain eTeX one, suffers from precisely this problem.) 3. It seems that, unlike in the messy LaTeX world, ConTeXt people like to do things The Right Way. ;-) As making a change like this in a module is surely not The Right Way, I hope that ConTeXt developers can help me out here, either by implementing the local allocation (I'm happy to assist in any way) or by maybe suggesting an alternative approach. (Btw, if it helps, I guess a MKIV-only solution would be acceptable to most users.) Thanks in advance, Sašo Živanović

3 4

syst-aux.lua
by Wolfgang Schuster 17 Jan '17

17 Jan '17

Hi, line 280 (extra t in triple): local option = ( P("single") + P("double") - + P("tripple") + + P("triple") + P("quadruple") + P("quintuple") + P("sixtuple") ) * (P("empty") + P("argument")) Wolfgang

1 1

Re: [dev-context] Installing old version of context
by Taco Hoekwater 18 Nov '16

18 Nov '16

Hi, > On 18 Nov 2016, at 00:55, Lars Hamren <lh(a)sdu.se> wrote: > > > Hi, > > > i'm not sure if there are zips on the garden > > Not that I can find. There are old zips at http://context.aanhet.net/ , but there was no easy access to them until now. I just added that, and the archived zips from pragma-ade.com are now all below this directory: http://context.aanhet.net/archives/ Folder names are based on the time of mirroring. Note that I occasionally weed out duplicate mirrored files, only keeping the oldest one, so old folders sometimes are not a complete mirror of http://www.pragma-ade.com/context/ , you may have to go back a few archives to get a full set of zip files. Those zip files are also only the content of texmf-context, though. > > >> I'm sorry, but that does not answer my question. Can I install > >> a version from a certain date (à la version control), and if so, how? > > > > https://bitbucket.org/phg/context-mirror.git > > Thanks. Unfortunately it only contains the files from tex/texmf-context, > not e.g. the bin directories. > > /Lars > _______________________________________________ > dev-luatex mailing list > dev-luatex(a)ntg.nl > https://mailman.ntg.nl/mailman/listinfo/dev-luatex Taco Hoekwater Elvenkind BV

3 2

Installing old version of context
by Lars Hamren 17 Nov '16

17 Nov '16

Hi, My reference installation of context is from 2016-09-18. Suddenly it has stopped working. When I try to rebuild the formats (--make) it cant find context.lua. I have traced system calls, and it does not look in the right directories. If I copy mtx-context.lua to ./context.lua then it works. Other installations do work. According to Murphys Law, it is only the really important one that has stopped working. It must be something that I have done. But what? I have compared directory trees from about the seame time, but not found anything that motivates this failure. The best thing would be to have the original tree from that date, but I don't have a copy. All of the above is just background. Here comes the question: Is there a way that I can install context as it would have been installed on a given date? I mean all of context, not just the binaries. /Lars

2 2

\definefontsize changes definition of \tf
by Wolfgang Schuster 10 Nov '16

10 Nov '16

Hi, the \definefontsize and \definefontalternative redefine the \tf (and \it etc.) command and you can’t use it in math to get \mathtf. \starttext \begingroup \meaning\tf \endgroup \begingroup \definefontsize[e] \meaning\tf \endgroup \begingroup \definefontalternative[md] \meaning\tf \endgroup \stoptext Wolfgang

2 1

strc-con.mkvi: Unwanted vertical space
by Wolfgang Schuster 05 Nov '16

05 Nov '16

Hi, the \nobreak command after \p_strc_constructions_inbetween in the top alternative inserts a unwanted parskip. strc-con.mkvi: \startsetups[\??constructionrenderings:\v!top] \strc_sectioning_prevent_page_break\plusone \let\\=\space \noindent \copy\constructionheadbox % why copy ? \par \nobreak \edef\p_strc_constructions_inbetween{\constructionparameter\c!inbetween}% \ifx\p_strc_constructions_inbetween\empty \else \p_strc_constructions_inbetween \par \nobreak \fi \useconstructionstyleandcolor\c!style\c!color \ignorespaces \stopsetups %% begin example \definedescription [testdescription] [alternative=top, inbetween=\nowhitespace, title=yes] \setupwhitespace[2cm] \starttext \starttestdescription{Ward} \input ward \stoptestdescription \stoptext %% end example Wolfgang

2 2

strc-con.mkvi: referenceprefix
by Wolfgang Schuster 04 Nov '16

04 Nov '16

Hi Hans, can you enable the referenceprefix key for enumerations/descriptions: strc-con.mkvi: @@ -914,6 +914,10 @@ \global\let\currentconstructionexpansion\v!no \fi % + \ifx\currentconstructionreferenceprefix\empty + \global\let\currentconstructionreferenceprefix\referenceprefix + \fi + % \ifx\currentconstructionexpansion\s!xml \xmlstartraw \xdef\currentconstructiontitle {\constructionparameter\c!title}% @@ -972,7 +976,7 @@ internal \nextinternalreference order \nextinternalorderreference reference {\currentconstructionreference} - prefix {\referenceprefix} + prefix {\currentconstructionreferenceprefix} % block {\currentsectionblock} % section structures.sections.currentid(), } Wolfgang

1 0

lang-def.mkiv
by Wolfgang Schuster 27 Oct '16

27 Oct '16

Hi, the quotation marks for greek have to be fixed because \greekleftquot doesn’t exist in MkIV. I changed also the symbols from (( to « which is shown on wikipedia. \installlanguage [\s!gr] [\c!spacing=\v!packed, \c!leftsentence=\emdash, \c!rightsentence=\emdash, \c!leftsubsentence=\emdash, \c!rightsubsentence=\emdash, - \c!leftquote=\greekleftquot, - \c!rightquote=\greekrightquot, - \c!leftquotation=\greekleftquot, - \c!rightquotation=\greekrightquot, + \c!leftquote=“, + \c!rightquote=”, + \c!leftquotation=«, + \c!rightquotation=», \c!date={\v!day\space\v!month\space\v!year}, \s!patterns=\s!agr] % ok? Wolfgang

1 0