4 ms·

For common diagrams, you probably should. I've used Pikchr, and if you want/need to place a lot of things manually or otherwise have a larger degree of control,

by LVB 3y ago

For common diagrams, you probably should. I've used Pikchr, and if you want/need to place a lot of things manually or otherwise have a larger degree of control, then it fills that niche OK, I guess. But for whipping up a flowchart or sequence diagram, I find Mermaid or other tools with higher-level abstractions much quicker and simpler. The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support.

sgbeal 3y ago
> The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support. Sidebar... (A fossil dev here.) That would require third-party code dependencies, something all projects created by Fossil's project lead (Richard Hipp) avoid except where absolutely necessary. In fossil, the only required 3rd-party dependency is zlib, with libssl highly recommended but not strictly required. Though fossil is heavily dependent on sqlite, they're both by the same main developer so it's not really a 3rd-party dependency. Same goes for JS code like Mermaid - if it's not written by a fossil project member, it doesn't go into the source tree.
- troupo 3y ago
  There is a point at which you end up re-writing the entire universe yourself for smaller and smaller gains
  - jddj 3y ago
    Sure, but it depends how strongly you care about the security of the supply chain for a core piece of software for our industry, Vs having a more featureful way to make diagrams.
    - troupo 3y ago
      creating inline diagrams to display in documentation or comments in a VCS used to handle sqlite code isn't that much of a security issue IMO. It's bordering on paranoia :)
      - sgbeal 3y ago
        > It's bordering on paranoia :) FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that... It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind). That's the short and the long of it.
        troupo 3y ago
        I was on the both sides of the spectrum: from everythig custom-built to everything is a third-party dependency. I guess you managed to find the balance where it works. Because on the one side it often falls into "oh, we built a PDF writer, and a phone routing system, and a generalised build system from scratch, and now we have no one who knows how these work, how to upgrade them, or replace them". On the other side is "we've been running this PHP 4 project forever because the cost of upgrading every third-party library used across all the breaking changes is at least a three-year project, so we're better off not touching it" :)
- LVB 3y ago
  I’ll redo my wish into: I wish Pikchr was more expressive. I’m not attached to Mermaid, but I do like things that make the common tasks simple. AFAICT the Pikchr language is still pretty close to its PIC roots, which is comparatively low level. An expansion to better handle the sort of diagramming that has become common since PIC’s 80s time would be excellent. This is especially true in the context of Fossil, where being able to make quick flowcharts or sequence diagrams would be super useful.

by LVB 3y ago

sgbeal 3y ago

> The big use case is if you need to use Fossil, which only supports Pikchr for inline diagrams. That's a shame IMO, and I would love Mermaid support. Sidebar... (A fossil dev here.) That would require third-party code dependencies, something all projects created by Fossil's project lead (Richard Hipp) avoid except where absolutely necessary. In fossil, the only required 3rd-party dependency is zlib, with libssl highly recommended but not strictly required. Though fossil is heavily dependent on sqlite, they're both by the same main developer so it's not really a 3rd-party dependency. Same goes for JS code like Mermaid - if it's not written by a fossil project member, it doesn't go into the source tree.

troupo 3y ago
There is a point at which you end up re-writing the entire universe yourself for smaller and smaller gains
- jddj 3y ago
  Sure, but it depends how strongly you care about the security of the supply chain for a core piece of software for our industry, Vs having a more featureful way to make diagrams.
  - troupo 3y ago
    creating inline diagrams to display in documentation or comments in a VCS used to handle sqlite code isn't that much of a security issue IMO. It's bordering on paranoia :)
    - sgbeal 3y ago
      > It's bordering on paranoia :) FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that... It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind). That's the short and the long of it.
      - troupo 3y ago
        I was on the both sides of the spectrum: from everythig custom-built to everything is a third-party dependency. I guess you managed to find the balance where it works. Because on the one side it often falls into "oh, we built a PDF writer, and a phone routing system, and a generalised build system from scratch, and now we have no one who knows how these work, how to upgrade them, or replace them". On the other side is "we've been running this PHP 4 project forever because the cost of upgrading every third-party library used across all the breaking changes is at least a three-year project, so we're better off not touching it" :)
LVB 3y ago
I’ll redo my wish into: I wish Pikchr was more expressive. I’m not attached to Mermaid, but I do like things that make the common tasks simple. AFAICT the Pikchr language is still pretty close to its PIC roots, which is comparatively low level. An expansion to better handle the sort of diagramming that has become common since PIC’s 80s time would be excellent. This is especially true in the context of Fossil, where being able to make quick flowcharts or sequence diagrams would be super useful.