On Tue, Jan 17, 2017 at 11:35 AM, Hans Hagen <pragma@wxs.nl> wrote:
On 1/16/2017 8:31 PM, Sergey Slyusarev wrote:
the (subtle) difference between the two [*MPinclusions and */MPinitializations/] is not a bug but a feature

If I understood correctly, *MPinitializations affects everything and can't be assigned to a specific instance (or can it?),
in some cases (like mine) this difference is not so subtle.

Look at the following example (not so minimal):

\startMPinitializations

picture p;

p := image(

draw fullsquare scaled 1cm;

draw textext("1");

);

\stopMPinitializations

\startMPinitializations

picture s;

s := image(

draw (fullsquare rotated 45) scaled 1cm;

draw textext("2");

);

\stopMPinitializations

\defineMPinstance[foo][initializations=yes]

\startMPcode{foo}

picture q;

q := image(

draw fullcircle scaled 1cm;

draw textext("3");

);

draw q;

\stopMPcode

\startMPcode{foo}

draw p;

draw q shifted (2cm, 0);

draw s shifted (4cm, 0);

\stopMPcode

\defineMPinstance[bar][initializations=yes]

\startMPcode{bar}

picture r;

r := image(

draw fullcircle scaled 1cm;

draw textext("4");

);

draw r;

\stopMPcode

\startMPcode{bar}

draw p;

draw r shifted (2cm, 0);

draw s shifted (4cm, 0);

\stopMPcode


First, it shows why *MPinitializations can't replace *MPinclusions for
me (it affects all instances),

and second, it silently produces produces some really unexpected results:

It looks like it should produce (by line)

A circle with "3" inside (yes)

A square with "1" inside (yes); A circle with "3" inside again (no,
instead it produces circle with "2" inside); A rhombus with "2" inside
(no, instead it produces a rhombus with "1")

and so on.

(tested on http://live.contextgarden.net/)

In fact, I failed to declare picture variable inside with text inside
one *MPcode environment and pass it to another safely

(text either disappears or changes to other text, and this time ConTeXt
returns no error), that surely is a bug?

no, it's the way it works ... but keep in mind that textexts are something bound to a specific code snippet so you can bets do something like this:

\starttext

\defineMPinstance[foo][definitions=yes]
\defineMPinstance[bar][definitions=yes]

\startMPdefinitions{foo}
    vardef p =
        image(
            draw fullsquare scaled 1cm;
            draw textext("1");
        )
    enddef ;
\stopMPdefinitions

\startMPdefinitions{bar}
    vardef p =
        image(
            draw (fullsquare rotated 45) scaled 1cm;
            draw textext("2");
        )
    enddef;
\stopMPdefinitions

\startMPcode{foo}
    draw p;
    draw image(
        draw fullcircle scaled 1cm;
        draw textext("3");
    );
    draw p;
\stopMPcode

\startMPcode{bar}
    draw p;
    draw image(
        draw fullcircle scaled 1cm;
        draw textext("4");
    );
\stopMPcode

\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
-----------------------------------------------------------------

Thank you, Hans!
I thought of this solution too ( http://tex.stackexchange.com/questions/347908/metapost-text-labels-inside-mpinclusions/348066#348066 ), but in my particular case it didn't work, because the code inside vardef is only executed when macro is called (while image(...) is processed immediately). It would help if the macro could be called within *MPdefinitions, like this:

\starttext
\startMPdefinitions
picture tmp;
vardef p =
image(
draw fullcircle scaled 5cm;
draw textext("test");
)
enddef;
tmp := image(draw p;);
\stopMPdefinitions
\startMPcode
draw p;
\stopMPcode
\stoptext

but that predictably generates the same error ("! Equation cannot be performed (color=vacuous).").

Anyway, I solved my problem somehow (by running the code inside *reusableMPgraphic and reusing it for the first time inside \setbox that is never shown https://github.com/jemmybutton/byrne-euclid/commit/8c05cc96405f0ee33e6901a7fa66b2dffcda45ad#diff-6a58985423a46a2bb439cfdf26904e5fL30 , at the cost of being unable to modify the image).
Now I see that the fact that it's almost impossible to use images with text inside, outside of their environment of origin is not a bug, but a natural limitation of the system, and the first message should have been not about "bug", but more about something like "feature request". Sorry for being hasty.

Sergey.