This took a bunch of code ...

But the results are gorgeous! Seriously impressive.

... which a loop could reduce significantly.

Looping currently requires generating that code with a higher-level tool. For example, Fossil's pikchr command optionally supports inputs which contain TH1 code (TH1 being Fossil's embedded mini-dialect of TCL). Using that command, you can program the loops in TH1, run the whole thing through the pikchr command, and have it output either the resulting pikchr code or the SVG.

It's not the same as having loops built-in, but as soon as pikchr has loops, it needs logic operators and flow control (break/continue), and that starts turning the whole thing into a full-fledged programming language. As soon as a loop can be created, it becomes possible to crash rendering of your forum post, and indeed a whole forum thread, by injecting an endless loop into the post. If such a post is saved, recovering (making the affected thread readable again) would require a fossil admin "shunning" the forum post in question. Merely discovering which post in a thread is causing the problem may require attaching a debugger. That Way Lies Madness.

Though i agree that the utility would be nice at times, i'd currently argue for keeping pikchr free of those complexities and side effects.

Indeed, almost as soon as I posted it I realised that there is also no flow-control in pikchr, and without some form of flow control, loops would be difficult. (Hence the second post on objects)

I think the idea of being able to group some items into a set or object or variable, then be able to "draw" or "play" that item again and again as needed would require much less effort, no flow control, not breaking the pikchr design tenets, and help a bunch with making less code do more.

I see even in SQLite's docs the same shapes being reused lots, as well as in other example pikchrs people posted here, making me think there is some general benefit (not just my own eccentric wishes).

Anyway, these thoughts probably belong in the other thread...

So after learning about Macros (thanks to the people pointing that out), I was able to improve the spider drawing to be thrice as dense (with respect to web rungs) and simultaneously reduce the code to do it to about 40% of the original. It's a vast improvement - even if it feels more pristine (machine-made) than the original (which is what you want for most computer graphics).

The code looks more dense, but that's only because now it is properly commented.

Question: Initially this image was a bit bigger (more web loops) and while it worked in the PikchrShow web-app, here the previewer complained about it being too complex:

• Why is the complexity different between the two web interfaces?
• Is there a way to understand the complexity limits, or know when you are crossing the boundary?
• Is it a compile-time define?

It would be quite inconvenient to make an image and find some target implementation can't display it for being compiled with a lower complexity tolerance - or am I missing something obvious again?

// Spider in Web - pikchr

CP:   dot;

      $wAngle = 18;                   // Web-Angle (Only works between 0 and 20, else Angle-calcs overflow)
      $spiderScale = 1.5;             // Spider-Scaling factor
      $b = 6.5cm;                     // Beam-Size
      $h = $wAngle;                   // Start loop $h at the Web-Angle

define beam {                         // Macro for drawing radial web beams
      line go $b heading $h thin;
      move to CP;                     // Move back to Center after drawing a beam, then
      $h = $h + 20;                   // Increase beam-angle 20 degrees. 360deg / 20 = 18 beams
}

      beam; beam; beam; beam; beam; beam; beam; beam; beam;  // Draw the 18 beams
      beam; beam; beam; beam; beam; beam; beam; beam; beam;

define rung {                         // Macro for drawing web rungs between beams
      RP: line go $b heading $h thin thin;
      $h = ($h + 20 + $r);            // Increase the angle after every rung, plus a radial offset to
}                                     // cause spiraling towards the end

define webloop {
      $r = 0;
      $b = ($z * 3.14159) / 18;                  // Rung length is rung height (radius) x Pi div by 18 beams
      CS: move go $z heading $wAngle;            // Go up the start beam to the rung radius height
      line from last line.end to CS thin thin;   // Continue the line to there
      $h = $wAngle + 100;                        // 1st rung angle is start angle + half beam angle (10) + 90
      rung; rung; rung; rung; rung; rung; rung; 
      rung; rung; rung; rung; rung; rung;        // Draw first 13 rungs without angle offset ($r)
      $h = $h - 360;                             // Modulo hack (no flow-control and no modulo expression)
      $r = 4 - (4 * $z / 8);                     // Increase angle offset proportional to rung height
      rung; rung; rung; rung; // rung;           // Draw last 4 rungs (no 18th rung so spiral is seamless)
      move to CP;
      $z = $z - 0.25;                            // Set rung-height 1/4cm closer to the center for next rung
}

define leg {                          // Macro for legs, taking 3 "parameters" for the leg-angles
      line from RDT thin chop go $ss*0.8cm heading $1 then go $ss*0.5cm heading $2 then go $ss*0.2cm heading $3;
}

define spider {                       // Macro for drawing a spider
      $ss = $spiderScale;
      BODY: ellipse width $ss*0.3cm height $ss*0.4cm fill black;                    // Body section
      RDT:  ellipse width $ss*0.2cm height $ss*0.2cm fill red at last ellipse.c;    // Red dot (Button spider)
            ellipse width $ss*0.2cm height $ss*0.1cm fill black at RDT.n;           // Mask dot North
            ellipse width $ss*0.2cm height $ss*0.1cm fill black at RDT.s;           // Mask dot South
      HEAD: ellipse with .s at BODY.n width $ss*0.14cm height $ss*0.12cm fill silver;           // Head
            line thin thin from HEAD.nw go $ss*0.08cm heading 155;                  // Attempt at fangs :)
            line thin thin from HEAD.ne go $ss*0.08cm heading 205;
      SPIN: ellipse thin at BODY.s width $ss*0.06cm height $ss*0.08cm;              // Spinner mechanism

      // 4 x Left-side legs
      leg(335, 270, 190);                        // Its questionable if we "need" this to be a macro, since
      leg(303, 229, 190);                        // we draw only 1 spider, and can only draw 1 as the legs
      leg(279, 200, 170);                        // are placed upon web rungs at the specific position.
      leg(265, 190, 150);

      // 4 x Right -side legs
      leg( 40, 109, 190);                        // Use the leg-angle parameters to place legs
      leg( 52, 136, 190);
      leg( 86, 147, 208);
      leg(108, 179, 230);

      SPE: move to SPIN.s;                       // End at the spinner-South so we can connect a web strand to it
}

      // Draw everything
      line up 0;                                        
      $z = 12cm;                                 // Start on outer web spiral loop
      webloop;  webloop;  webloop;  webloop;  webloop;  webloop;  // Draw 18 loops - this qty of loops, the
      webloop;  webloop;  webloop;  webloop;  webloop;  webloop;  // rung-height decrement, and the beam lengths
      webloop;  webloop;  webloop;  webloop;  webloop;  webloop;  // are all inter-dependent.


      move up 1.4cm right 0.1cm                  // Move to the Spider's position, and
      spider;                                    // Draw the spider 

      line thin to RP.end thin;                  // Connect the spider's spinner to the last rung line point.
     
// ---EOF---

Also, what might interest you is that macros can take arguments. Accessible using: $1, $2, $3, …. within the macro. (It support a maximum of 9 if I remember well).

Thank you Martin, it's one of those things that did not immediately work the first time I tried it (for lack of understanding on my part) and thought I would catch up with it later. That time has come thanks to you mentioning it, it works very well - I've adjusted the code use macro parameters.

Thanks!

Why is the complexity different between the two web interfaces?

The WASM file built for /pikchrshow is built as part of the pikchr project and then copied into fossil, whereas the copy of pikchr.c fossil uses is compiled by the fossil build process (the difference being that the former requires a wasm-specific toolchain). In the case of the former, the default limit on the number of tokens is 100000, but fossil's build of the .c file reduces that to 10000.

So far, you've been the only person to stumble across that difference.

Is there a way to understand the complexity limits, or know when you are crossing the boundary?

Only by looking at the source. pikchr's own interface is only a single function so can't report that type of info.

It would be quite inconvenient to make an image and find some target implementation can't display it for being compiled with a lower complexity tolerance - or am I missing something obvious again?

Not obvious, per se, but your spider pushes the limits (perhaps even surpasses them) of what pikchr's really intended for: technical diagrams for embedding into docs. That's not to say it can't/shouldn't be used for such things, just that it's overstepping the limits foreseen for fossil. Perhaps, in light of this work of art, Richard would agree to raising it by a factor of 1.5 or 2 for fossil.

but your spider pushes the limits...

I absolutely agree, and I also agree that it's not the intended use case, and that the spider is just a playtime thing to test what can be done, so I'm very happy to accept it is overpowering and not a good example use-case - nor expecting Richard to raise the complexity level (but happy if he does, if it is easily done and causes no harm).

My concern (or rather surprise) more stems from the fact that I did not expect it to work in one pikchr interpreter, and not in the next. I get why that is now, and now have a little flashing neon sign inside my mental workspace that is always on: "Beware the Token-Count"

I was thus hoping there was a way to measure my pikchr's token count complexity. i.e. - after figuring out the forum's limit is 10K tokens, be able to ensure my future pikchr creations are skinny enough in token terms to safely send to the forum, or to the general population. And if I do make a 1M token behemoth, to know I can only really share it with Quantum computing labs.

Perhaps an internal variable can reference the instantaneous token-count, so I can print it out at several stages in the image and see what it amounts to up to that point. Does not need to be 100% precise either, an approximate number will do.

This falls very much in the nice-to-have category - no urgency about it, even a note in the long-run roadmap would be appreciated.

... nor expecting Richard to raise the complexity level (but happy if he does, if it is easily done and causes no harm).

It's just a build-time flag with a default of 100k: /info?name=90bcc7df74ea40b5&ln=133-135

My concern (or rather surprise) more stems from the fact that I did not expect it to work in one pikchr interpreter, and not in the next.

That's definitely unfortunate and confusing but the only way to work around that is to change the default for one project or the other. That decision is up to Richard.

I was thus hoping there was a way to measure my pikchr's token count complexity.

Not without running it through pikchr, unfortunately. You can get an approximation using the Unix "wc" command - the "word" count should be relatively close to correct for most pictures.

And if I do make a 1M token behemoth, to know I can only really share it with Quantum computing labs.

Then you'll need to compile your own copy.

Perhaps an internal variable can reference the instantaneous token-count, so I can print it out at several stages in the image and see what it amounts to up to that point. Does not need to be 100% precise either, an approximate number will do.

There's programmatically no way to do that. Pikchr accepts, as inputs, its whole source code and outputs either an HTML-format error message or an SVG image. Both before and after that, the tokens don't exist, so there is no reliable way for the app-level code to know how many there are. An app can guess a token count, and get relatively close, but doing so requires more editing features than the plain HTML textarea provides. Making that calculation (approximation) in the current UI would mean passing the whole pikchr text to the calculator every time we wanted to calculate it, which would be computationally unsettlingly expensive.

This falls very much in the nice-to-have categor ...

Exactly!

BTW: see post ef8684c6955a411a for the background behind the token limit.

I agree with everything you said, but I feel we are talking past each other a bit. Allow me this one opportunity to try clarify and be sure we mean the same things:

1. I'm 100% happy to build my own pikchr, and have already started that.
2. I'm not suggesting a feature to pre-guess token counts, I'm happy for my pikchr to completely process the entire image and then, in hindsight, tell me how many tokens were involved, which it must know since it done all the token-making (so I can estimate if it is small enough for the forum or not)
3. The feature I suggested on showing the token-count during the image creation is not an interface request, I meant to physically make it so that I can issue the command (as part of the image) [box "Tokens"; print tokencount;] or something similar somewhere inside the image's pikchr text, in the same way I could do [box "Box Width"; print boxwid;] to show it in the final produced image - like a debug console.log() but ending up in the actual compiled output rather than the non-existing console.

If this is the interpretation you already understood, then apologies, feel free to ignore. If this is different, then it doesn't really change anything, except that the feature request becomes possible in principle at least and we are on the same page, but still is a nice-to-have.

This is quite tractable from a look at pikchr.y: Pik->nToken keeps the running count of tokens encountered, so you just need to patch a command that prints this value when you want to see it.

This is quite tractable from a look at pikchr.y

The data is there but exposing it requires a much different interface and there are no immediate/pressing plans to extend it.

I think I previewed a post without sending, my apologies if two similar posts show up twice.

I wrote a three-line change to pik_value which looks for a variable nToken and returns p->nToken if it sees it. A user variable named nToken will shadow this, so it shouldn't be a breaking change.

Good time to ask: does pikchr follow an open development model? I know SQLite doesn't, which I respect.

I have another patch I'm tinkering around with, I'll start a thread on that when I'm happy with the behavior. I'd be happy to sign something like the Fossil contributor's agreement if that would be helpful, and serve a Fossil branch.