Closed vittorioromeo closed 8 years ago
Hello,
You're right. To avoid regenerating all the graphs each time pp (or dpp) is started, pp calls dot (or neato) only is the source of the graph has changed. Maybe a solution (easier than an additional metadata file) is to put the graph type as a comment in the graph source code generated by pp. I'll fix this.
A workaround is to delete the .gv file when you change the graph type. Or to add the graph type in the source of the graph (layout = neato).
As you have noticed it, dpp is deprecated since all its features have been reimplemented as pp macros. I'm interested in your feedback. Do you think it's worth maintaining both preprocessors?
Regards, Christophe.
Maybe a solution (easier than an additional metadata file) is to put the graph type as a comment in the graph source code generated by pp.
That could work well as a temporary solution, but I feel that having an additional metadata file (or just merging eventual metadata with block data in a single file with custom format) would be better in the long run. As an example, imagine adding support for a diagram generator that uses a language with no comments.
A workaround is to delete the .gv file when you change the graph type. Or to add the graph type in the source of the graph (layout = neato).
I wrote a script to delete all .gv
files, but adding the type in the source sounds "cleaner". I think I will do that until you commit an updated version :)
As you have noticed it, dpp is deprecated since all its features have been reimplemented as pp macros. I'm interested in your feedback. Do you think it's worth maintaining both preprocessors?
I'll be honest - I didn't realize that pp
wasn't calling dpp
until I checked the Haskell source code. I would definitely opt to remove dpp
from the pp
project (and maybe put it in a separate repository for historical reasons). I don't think it's worth to maintain both preprocessors as pp
can do anything dpp
can, and more.
Thanks for the quick reply, by the way - I'm using pp
to write my BCS thesis and I'm loving it so far. I would like to directly contribute but I've only briefly experimented with Haskell in the past.
That could work well as a temporary solution, but I feel that having an additional metadata file (or just merging eventual metadata with block data in a single file with custom format) would be better in the long run. As an example, imagine adding support for a diagram generator that uses a language with no comments.
You're right. Generic is better.
pp
now creates a medata file in addition to the graph source file. The graph is generated whenever one of both files has changed.
I don't think it's worth to maintain both preprocessors as pp can do anything dpp can, and more.
That's my opinion too. One day I'll make a separate repository for the legacy dpp.
Thanks! I've tested the new version and it correctly regenerates graphs when the command is changed. I can delete my remove_generated_figures.sh
script.
Example (added a
\
before the tilde line due to GitHub code formatting issues):Let's say I have a
\dot
graph that generatesx.png
:If I change
\dot
to\neato
(or any other graph type), without changing the body of the graph, the graph will not be regenerated.The above snippet will not trigger a regeneration.
I suspect that this check in
dpp.c
only checks if the block was changed or if the file is not existent. Information regarding the used command needs to be saved in the block as well.EDIT: it seems that the block created by
saveblock
is directly passed to the GraphViz executable, so storing command information inside it would be problematic. A possible suggestion would be creating an additional "dpp
metadata file" that contains the command information, and checking that file for differences. I think it's also a future-proof solution in case additional parameters (such as forcing a specific size for images) are added todpp
commands.EDIT2: just noticed that
dpp.c
is unused inpp.hs
, as the entire functionality was reimplemented in Haskell. I skimmed throughpp.hs
and the problem seems the same: only the block forwarded to the diagram-generating runtime is saved and checked for differences, and not the command name itself.