Lefty not a Graphviz application?

Dev
1

While doing some unrelated gardening I stumbled across something curious: Lefty does not appear to depend on cgraph. Pulling the thread on this, it doesn’t appear to depend on anything except libast.

Is this correct? This seems a little odd, to have an unrelated AT&T application living in the Graphviz source tree.

2

Lefty was an early interpreter for graphics programming. It’s from about 1990 or 91, and we used it as the basis for a scriptable graphviz viewer, dotty. It was student code written by Lefteris Koutsofios. I thought there was some C code for parsing graphs but I could be wrong.

Even libast came into the picture much later, but I suppose that was done to clean up some of its OS dependencies or to make it more portable or robust in some way.

I’m ok with retiring it.

1 Like
3

Thanks, Stephen.

What should we plan, given it’s a shipped binary? E.g. it’s in Debian Sid’s Graphviz package, https://debian.pkgs.org/sid/debian-main-amd64/graphviz_2.42.2-5_amd64.deb.html.

My vote:

  1. default-disable in the Autotools build immediately; downstream packagers will have to explicitly --enable-lefty
  2. …wait for complaints/silence…
  3. if there are 6+ months of silence, git rm -rf cmd/lefty
4

SGTM. According flip Smyrna default to disabled in the Autotools build system (!2083) · Merge requests · graphviz / graphviz · GitLab, Smyrna may have superseded it.

5

lefty has its own parser, which means it has drifted from the dot language standard. In addition, there are a lot of newer graphical features that it doesn’t support, plus its interface feels very early X windows, which it is.

1 Like
6

I’d like to see lefty continue. I still find the tool very useful for a debugging aid for of all things parsers. I’ve used it quite a lot over the years via its dotty script. The dot language is ideal for structuring data structures in a manner that they can be compared to identify structure changes - a real help debugging -‘a picture paints a thousand words’

7

Thanks for the experience report. Are there particular dotty/lefty features you’re using that can’t be done with rendering an svg and opening that?

dot -Tsvg input.dot > output.svg && open output.svg

8

We could resurrect Lefty, but I think we need someone to step in and maintain it. It has 0 test coverage and hasn’t been meaningfully worked on in years.

9

I’ve been coding in C for 40yrs on multiple platforms so fixing bugs & extending functionality would be well within my skill set. What do you need doing to cover maintaining it?

10

Great, thanks for volunteering!!

The first steps would be to revert the merge requests that removed build system support:

Then we need to probably start paying down the technical debt in cmd/lefty. Most Graphviz code was written prior to ISO C standardization so, although we now build with C99, there’s a lot of code that could be modernized.

IMHO the two biggest stumbling blocks when working on Graphviz right now are:

  1. There are three parallel build systems: Autotools, CMake, MS Build. We are trying to move to only CMake, but this effort has been ongoing for many years and by this trajectory probably still has years to go.
  2. The build sprays a torrent of compiler warnings. Many of these point to legitimate problems. My main focus right now is methodically fixing these, but this is also a multi-year effort.

Do you have a Gitlab account? If so, you can begin contributing immediately by submitting merge requests to the Graphviz repository.

11

I have a Gitlab account & have cloned the repository. I see that it presently uses Autotools for make; I’ve no experience setting up a build to use these nor for that matter have I used CMake. So for 1) realistically I’d be starting from scratch with both these - I expect it might be possible to run a clean total build to list the out the actual compilations, links etc and to cast that into s suitable makefile - presuming that CMake must share some commonality with other makes.
The 2nd I could certainly help with, just need to be able to build & test.
Regarding building, I am able to build and install & had a look at reverting the changes you mentioned. Backing out the later change was ok (!2542), one conflict was obvious but the other suggests that there has been later work to further rearrange PDF handling; Running ./autogen.sh to pickup the restored lefty tree complains that HAVE_PS2PDF needs to be in AM_CONDITIONAL so I presume there is a configure.ac affecting change that really needs reverting as well, at least in part.
With svn I know how I’d approach this situation bug I’m still learning my way around git and here I need help; how with git can I identify which change would have removed the setting of HAVE_PS2PDF?

12

git log <filename> and git blame <filename> are the git equivalents for browsing history of files.

13

Thanks Mark,
I had grep’d for HAVE_PS2PDF on the ‘git log’ output on the off chance that it might have been mentioned but no and ‘git blame’ only helps with line additions and changes - line deletions don’t appear.

With svn I could checkout to a revision that contained HAVE_PS2PDF and successively advance to the change that removed it - is there a way this can be done with git?

14

You can move commit-by-commit, but I suspect what you really want is git-grep: git log -G HAVE_PS2PDF -- configure.ac Makefile.am

15

Heads up: I’ve submitted Lefty for removal, remove dotty, lefty, lneato (!2779) · Merge requests · graphviz / graphviz · GitLab.