Tags:
create new tag
, view all tags

DirectedGraphPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on DirectedGraphPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the DirectedGraphPlugin bug database.
• See DirectedGraphPluginDevArchive for older discussions

Feedback on DirectedGraphPlugin

-- ColeBeck - 25 Mar 2005

Integrated patches suggested here (except the one for using neato and other utils), and upgraded the plugin to use the sandbox security mechanism. Thanks all!

There's an item open at Bugs web (Bugs:Item2085) in case testing reveals any problems.

-- SteffenPoulsen - 12 Apr 2006

Restored old discussions to DirectedGraphPluginDevArchive so that it can be searched.

  • Thanks, forgot about the searchable aspect. -- SteffenPoulsen - 12 Apr 2006

-- PeterThoeny - 12 Apr 2006

Uploaded a new version today with Firefox areamap compatibility (minor fix). Btw: DirectedGraphWebMapPlugin is Dakar ready as well, take a look.

-- SteffenPoulsen - 16 Apr 2006

Want to start off by saying that this plugin is and continues to be extremely useful to me. Thank you so much for providing it.

One of the things I am starting to use it for is the generation network diagrams based on information defined in TWikiForms. The missing piece of this puzzle is that I can't figure out how to use custom shapes using the standard dot language shapefile directive:

yournode [shapefile="yourface.gif"];

I've uploaded all the standard Cisco icons and would love to use these instead of the standard shapes. Any help would be greatly appreciated.

-- SergeArsenault - 07 Jun 2006

Sounds like a wonderful idea! Could you upload a (hand generated?) example by any chance?

I think the idea of creating a few TWiki topics and uploading your various "shape libraries" to them is definetely interesting.

For dot to get to these "libraries" (the gif images) it would have to use the pub dir of one of these topics as its working dir (this way it will only be able to use one library at a time, though).

A way to implement this functionality would be to give the tag a new library parameter (for instance shapefiles="Web.Topic") and then change the execution code to utilize the attachment area of this topic as its working dir.

I probably won't have time to dig into this any time soon, but an example of a way to utilize a working dir can be found in the code of the PloticusPlugin if you feel like giving it a shot.

- Glad to hear this plugin is useful out there! smile

-- SteffenPoulsen - 08 Jun 2006

I had a bit of spare time this weekend to give this a first shot, see Bugs:Item2085. I need to find some additional time for a bit more of doc work for the new parameters before releasing it; any help appreciated.

-- SteffenPoulsen - 12 Jun 2006

New release uploaded, suggestions for improvements and other feedback happily received!

-- SteffenPoulsen - 12 Jun 2006

This looks great Steffen, thanks! I knew this could be useful.

-- FranzJosefSilli - 14 Jun 2006

I believe it is! I added a few examples for daily use, trying to rip a bit of the "intellectual look" from it; don't want to scare anybody - it's not that advanced after all (no mathematical group theory for me, please!) smile

The fact that stuff can be scripted to the dot format is particularly useful, for instance this little script makes a dot graph from a directory structure.

Sometimes a bit of verbatim and an output from tree can do the same, but imho this is more easily colourized / iconized / made clickable / applied what other decorations one could think of.

On another issue - refining graphs for better "human readability" - Automate the creation of graphs with Graphviz / linuxfocus.berlios.de is an excellent article, recommended.

BTW: The script is from An Introduction to GraphViz / linuxjournal.com - the article has other useful examples too.

-- SteffenPoulsen - 15 Jun 2006

Hm, I'm curious: Did you have a look at Asymptote yet?

-- FranzJosefSilli - 19 Jun 2006

I did actually, but found the syntax too obscure at the time (after a quick revisit I think I still do :-)).

I like some of their stuff, especially the flow diagrams:

- Just not enough to throw any work after it smile

(It does look as though it would be quite easy to model an eventual twiki plugin after either this plugin or one of GnuPlotPlugin or PloticusPlugin, if anybody has an interest).

Did you find Asymptote to be applicable in some of your work?

-- SteffenPoulsen - 20 Jun 2006

smile Didn't use Asymptote yet, have just been curios. It looks as if it could be useful in a LaTeX environment because of its font features.

-- FranzJosefSilli - 20 Jun 2006

Sorry for not getting back sooner; I've been away on holidays. Thank you so much for adding the shapefile functionality. This is going to be very handy! I noticed you also provide an example which is similar to what I was producing from the command-line.

-- SergeArsenault - 29 Jun 2006

After installing the latest version, I seem to have broken things. I'm running the 01 Sep 2004 release and I am getting the following errors when trying to load previously working graphs:

Can't locate object method "new" via package "TWiki::Sandbox" at /usr/local/apache/vhdocs/twiki/lib/TWiki/Plugins/DirectedGraphPlugin.pm line 115

Any suggestions would be greatly appreciated.

Serge

-- SergeArsenault - 29 Jun 2006

Oh that's right, the added sandbox ruins Cairo compatibility, bummer.

I think the solution involves installing DakarContrib and adding the code snippet from the topic somewhere where it will fit right in. Will probably be able to look into this after the weekend.

-- SteffenPoulsen - 29 Jun 2006

The plugin doesn't survive use strict;. Perhaps you can fix it so that it does?

-- MeredithLesly - 30 Jun 2006

Thanks for the quick response. The code snippet in questions appears to be in there already:

sub doInit
{
  return if $isInitialized;

    unless ( defined &TWiki::Sandbox::new ) {
        eval "use TWiki::Contrib::DakarContrib;";
        $sandbox = new TWiki::Sandbox();
    } else {
        $sandbox = $TWiki::sharedSandbox;
    }

After installing DakarContrib, I am now getting the following error:

DirectedGraph Error (9):

I have poked around much further but will do so to see if I can figure out why this is happening.

-- SergeArsenault - 30 Jun 2006

This comes from an execution problem with dot. Try enabling debug both in the plugin topic and the helper script and trace the log files. Try to run the suggested command line from the log file on the command line.

-- SteffenPoulsen - 30 Jun 2006

Thanks for the debugging tips. I've managed to get a little further and can now get expected graphical output. However, whenever I make a change and preview I get the following in the Plugin err files:

Problem with executing dot command: 'GV_FILE_PATH="/usr/local/apache/vhdocs/twiki/pub/NOC/CiscoIconMap/" 
/usr/pkg/bin/dot -Tpng /tmp/DirectedGraphPlugin394 -o 
/usr/local/apache/vhdocs/twiki/pub/Sandbox/TestTopic2/graph6dc97dfdbc26098473aa6ea75bd9046f.png 2>
/tmp/DirectedGraphPlugin394.err ', got:
Bad file descriptor

Upon saving, I get a similar error:

Problem with executing dot command: 'GV_FILE_PATH="/usr/local/apache/vhdocs/twiki/pub/NOC/CiscoIconMap/"
/usr/pkg/bin/dot -Tpng /tmp/DirectedGraphPlugin15799 -o 
/usr/local/apache/vhdocs/twiki/pub/Sandbox/TestTopic2/graphd4596c7e41431edd3c657a07bc6856e1.png 2> 
/tmp/DirectedGraphPlugin15799.err ', got:
Bad file descriptor

It isn't until I refresh the page that I get proper graphical output. Also note that the unique identifier for the generated dot, png and err files change from preview to save; not sure if this is relevant or not since I never noticed the default behaviour of the plugin when it was running properly on my system.

-- SergeArsenault - 30 Jun 2006

What do you get when running the command on the command line? (Just cut & paste the whole thing in 's).

With debug on the files should be left in the /tmp area so the command should run ok (or at least - fail in the same way :-)).

Could sound like it is the /tmp/DirectedGraphPlugin15799 file that is not created, but I have never seen that error in my own testing, so I am unsure if this is perhaps Cairo / Sandbox related.

-- SteffenPoulsen - 30 Jun 2006

Please consider adding use strict; to this plugin. Its use is important to ensuring the quality of TWiki plugins and avoiding unpleasant surprises. See UseStrict for more.

-- MeredithLesly - 02 Jul 2006

Reporting back after my Canada Day holiday. I am able to run the command from the command-line without any problems. I'll try and poke around a bit more over the course of the day today.

-- SergeArsenault - 04 Jul 2006

Addendum...I just noticed that the image map functionality doesn't seem to work either. I eventually get the diagram to show up as indicated above but the links don't work.

-- SergeArsenault - 04 Jul 2006

It works when turn on debug, but still requires to reload page one or two times. And, the image map dose not work on my test platform either. This may becasue there is NO *.map file generated in attachment.

-- RuanJianDev - 05 Jul 2006

Sounds like the attachment logic needs some rework for Cairo. Are you on Dakar or Cairo, Ruan?

-- SteffenPoulsen - 05 Jul 2006

I am on Dakar, TWiki 4.0.3 + centos3 + apache 2.0 + perl 5.8.0 + graphviz 2.8

When I remove error check in tools/DirectedGraphPlugin.pl (line 50), it seems works. I assume the dot execute always success :).

It could be system issue, my other testing seems works fine on following config: TWiki 4.0.3 + Ubuntu 6.06 + Apache 1.3 + graphviz 2.2.1, (lost perl version)

-- RuanJianDev - 05 Jul 2006

I seem to have the same situation as SergeArsenault. I've found that by removing the parameters from the tag I can get the ps or png files to display (although they do not look pretty). If I add parameters I get the DirectedGraph Error (9): error along with the debug files that say Bad file descriptor.

-- IanTegebo - 10 Jul 2006

Perhaps this is really a problem with the graphviz commands / setup then? Could you try enabling debug and re-do the graphvis commands see what result they produce when done by hand?

-- SteffenPoulsen - 10 Jul 2006

I don't get errors when I run the commands by hand (or when running the commands as my apache user.) After running the commands by hand, the png or ps files get generated but the map files don't get associated with the image.

-- IanTegebo - 10 Jul 2006

It is just the contents of the map file that is read and copied to the topic text (the map files are not used by the browser). Could you try pasting a short from the generated HTML, see what the markup of the image and map looks like?

-- SteffenPoulsen - 10 Jul 2006

I don't get any map file output in the generated HTML. All that is present is

<img usemap="#RANDOMSTUFF" src="generatedgraphfile" />

-- IanTegebo - 10 Jul 2006

What should have been present in the HTML code is something like this:

<map id="#RANDOMSTUFF" name="#RANDOMSTUFF">
<area shape="rect" href="http://twiki.org/cgi-bin/view/Plugins/PluginPackage" title="Plugins" alt="" coords="60,8,150,56"><area shape="rect" href="http://twiki.org/cgi-bin/view/Plugins/DirectedGraphPlugin" title="DirectedGraphPlugin" alt="" coords="8,104,202,152"><area shape="rect" href="http://www.twiki.org" alt="" coords="8,8,202,152">
</map>

But you say the map file is present and containing what is should?

-- SteffenPoulsen - 10 Jul 2006

Yup. The map file has been attached to the topic but isn't being displayed in the HTML.

-- IanTegebo - 10 Jul 2006

I'm afraid I don't have much clue for that issue. Perhaps you could put a few more debugging print statements in the plugin perl module, and check the debug output if it is branching away from the map inclusion prematurely or something along those lines? If you can post the <dot> soruce you are using I will try using that in a quick test also.

-- SteffenPoulsen - 10 Jul 2006

IIRC, the variable $html isn't declared anywhere, which could lead to any number of problems. (I discovered this by putting in use strict, but didn't know how to fix the error.)

Rule of thumb: if a plugin doesn't have use strict, put it in to see if it reveals errors. If it does, fix the errors. (By this I mean maintainers, not victims of bugs in plugins.)

-- MeredithLesly - 10 Jul 2006

I put the following after line 417 (line 417 is included):

       my $mapfile = TWiki::Func::readFile($cmapx);
       writeDebug("printing mapfile...");
       &writeDebug("Something should be here? $mapfile");
But I don't get anything in $mapfile. Also, the map files that get generated in pub don't have the map id and name attributes filled in for the real values (they are still 'G' and 'G').

-- IanTegebo - 10 Jul 2006

I found that by changing the helper script's print `$execCmd` to

unless(system($execCmd) == 0) {
...SOME ERROR CHECKING...
}

will then generate all graphs that don't utilize map files or antialiasing.

It looks like map="on" is not being properly processed because map=1 causes the map files to be included; now all but antialiasing seems to work for me. Also, I'm using FreeBSD and needed to pass -channel rgba into convert because I was getting a Unknown device: pnmraw error.

-- IanTegebo - 10 Jul 2006

There is an error in the helper script DirectedGraphPlugin.pl near the end of the file in line

if ($!) {
where $! is used to check wether the previous system comnmand was successful or not. However, as documented in perldoc perlvar, $! is not reset after a successful command. I got similar error messages like Serge posted some weeks ago, and the page did not render correctly although the images were produced without any problem. Changing $! to $? (which gives the numerical status and returns 0 on a successful command) fixes the problem. (Ian's code of course also works)

-- JChristophFuchs - 27 Jul 2006

Glad to see you around again, JChristoph smile

Thanks for explaining the return status bug, I have created a new version with the proper $? check. Also added some better logic for reporting syntax errors to the user.

-- SteffenPoulsen - 27 Jul 2006

I need help with this error. Anybody please!! You get: (if installed) DirectedGraph Error (25):

-- VishalGupta - 03 Aug 2006

Vishal, this comes from an execution problem with dot.

Try enabling debug both in the plugin topic and the helper script and trace the log files. Try to run the suggested command line (from the log file) directly from your command prompt.

-- SteffenPoulsen - 03 Aug 2006

I am getting following errors in my "/tmp/DirectedGraphPlugin.pl.log" file.

Problem executing dot command: 'GV_FILE_PATH="/home/httpd/twiki/pub/TWiki/DirectedGraphPlugin/" /home/httpd/twiki/bin/dot -Tcmapx /tmp/DirectedGraphPlugin13484 -o /home/httpd/twiki/pub/TWiki/DirectedGraphPlugin/graphcae9b41389e173b619655377015a3180.map 2> /tmp/DirectedGraphPlugin13484.err ', got:

Inappropriate ioctl for device

while i am running the same command from command line it works.

-- VishalGupta - 04 Aug 2006

I'm using cairo and got Error (2) on all anti-aliased graphs. I figured that I had to set $dotHelperPath according to my twiki install path but after that it got worse: it didn't render the DirectedGraphPlugin page anymore but gave this error:

Undefined subroutine &TWiki::Func::saveAttachment called at /var/www/html/twiki/lib/TWiki/Plugins/DirectedGraphPlugin.pm line 367.

-- WimLivens - 23 Sep 2006

The TouchGraphPlugin has not been updated since July of 2004. Could the DirectedGraphPlugin be used as a suitable replacement after upgrading to DakarRelease ?

-- KeithHelfrich - 08 Oct 2006

You mean the DirectedGraphWebMapPlugin, surely?

-- CrawfordCurrie - 11 Oct 2006

Yep, that's it thanks. I knew I'd seen it around somewhere, but when I came looking for the functionality from the DirectedGraphPlugin I didn't find what I was looking for. Thanks again.

-- KeithHelfrich - 12 Oct 2006

The "Inappropriate ioctl for device" error seems to be from the

<dot> ... </dot>
lines in the command line test input file. If you remove them then that error goes away.

I was getting DirectedGraph Error (2):, which I solved, here is what to check:

Make sure the cgi process (usually the web server) can write to all of pub. Sometimes a "chown -R www-data:www-data pub" dosn't hurt. Also check permisions in /var/lib/twiki/data and /var/lib/twiki/log. Next look for correct paths in /usr/share/perl5/TWiki/Plugins/DirectedGraphPlugin.pm (in Debian) or wherever it is. Spcifically the $dotHelperPath variable.

-- ClifCox - 19 Nov 2006

It's a wonderful Plugin. I like it very much. I have a question: after I re-edit one page more than once, there are many unused PNG files exist. Do you have any way to find out these garbage PNG files and remove them?

-- KuoFengTseng - 06 Feb 2007

So I'm having some problems using this plugin. When I try to display an anti-aliased graph, I get the following error on the topic: "DirectedGraph Error (1)". I've enabled debug in both the DirectedGraphPlugin topic and the DirectedGraphPlugin.pl helper file.

What am I missing? What's dpg-png? Google doesn't know much about it.

My /tmp/DirectedGraphPlugin.pl.log doesn't appear to have much useful information in it: | 01 Mar 2007 - 12:09 | DirectedGraphPlugin - called doInit | 01 Mar 2007 - 12:09 | DirectedGraphPlugin - doInit( ) is OK | 01 Mar 2007 - 12:09 | DirectedGraphPlugin - incoming: digraph G{ hello -> world; }; , antialias="on" , antialias = on, density = 300, size = 800x600, vectorformats = none, engine = dot, library = TWiki/DirectedGraphPlugin, doMap =

| 01 Mar 2007 - 12:09 | DirectedGraphPlugin - creating ps version .. | 01 Mar 2007 - 12:09 | DirectedGraphPlugin - dgp-png: output: status: 0 | 01 Mar 2007 - 12:09 | DirectedGraphPlugin - dgp-png: output: status: 1 | 01 Mar 2007 - 12:09 | - DirectedGraphPlugin::commonTagsHandler( DustinGoodingSandbox ) | 01 Mar 2007 - 12:09 | - DirectedGraphPlugin::commonTagsHandler( WebBottomBar ) | 01 Mar 2007 - 12:09 | - DirectedGraphPlugin::commonTagsHandler( DustinGoodingSandbox )

And twiki/data/debug.txt has this: Calling dot; got parameters: /usr/bin/dot /var/www/twiki/pub/TWiki/DirectedGraphPlugin /tmp/DirectedGraphPlugin15321 ps /var/www/twiki/pub/Sandbox/DustinGoodingSandbox/graph5e96bc9a43b635a04645b4e0914a34cb.ps /tmp/DirectedGraphPlugin15321.err Built command line: GV_FILE_PATH="/var/www/twiki/pub/TWiki/DirectedGraphPlugin/" /usr/bin/dot -Tps /tmp/DirectedGraphPlugin15321 -o /var/www/twiki/pub/Sandbox/DustinGoodingSandbox/graph5e96bc9a43b635a04645b4e0914a34cb.ps 2> /tmp/DirectedGraphPlugin15321.err

-- DustinGooding - 01 Mar 2007

For what it's worth, graphs that are not antialiased display fine. (Sorry about the malformed text above, I'm still new to this TWiki thing... yay for verbatim).

Ubuntu Server 6.06 TLS, LAMP Option.

-- DustinGooding - 01 Mar 2007

Sooo, I'm dumb. It helps to have gs installed. You can apparently have all the listed requirements for this plugin without having gs. And without gs, converting from a .ps doesn't work.

-- DustinGooding - 02 Mar 2007

Glad you found a way, Dustin smile

I have mentioned the gs requirement explicitely in a new release.

-- SteffenPoulsen - 03 Mar 2007

I am running twiki in CGI mode under Windows 2003 an Apache 2.0.55, and I am getting this error with this plugin:

*DirectedGraphPlugin error:* 

'GV_FILE_PATH' is not recognized as an internal or external command,
01: operable program or batch file.
02: 

According to http://www.graphviz.org/doc/info/command.html , one has to call the tool passing an environment variable GV_FILE_PATH and sometimes also the command-lne such as GV_FILE_PATH="images/" . I am guessing that just the cmd-line should work.

Can we have a patch please? I tried something, but my Perl skills are almost nil.

-- MarcioMarchini - 10 Mar 2007

My workaround: changed to this in DirectedGraphPlugin.pl:

my $execCmd = "$ARGV[0] -T$ARGV[3] $ARGV[2] -o $ARGV[4] 2> $ARGV[5] ";

(basically removed GV_FILE_PATH=\"$ARGV[1]/\" )

-- MarcioMarchini - 11 Mar 2007

This plugin is currently marked as test with linux only at the plugin topic, but if you find that it will work with Windows as well, we should definetely mark it as such.

Please send any comments and perhaps a "final patch" once/if you conclude it is stable on Windows?

-- SteffenPoulsen - 11 Mar 2007

I just installed this plugin on a fresh TWiki 4.1.2 installation. All the examples work except the one with the standard network icons in the background. I modified the topic to change library="Sandbox.TestDot3" to library="TWiki.DirectGraphPlugin". I see the referenced files as attachments to that topic. However when the graph renders, all you see are the words and the connecting lines but none of the icons. Any ideas?

-- RickMach - 25 Apr 2007

Hi! I have been trying to install this plugin with difficult problems...

Browser cannot find any png pictures from folders and I get error message DirectedGraph Error(1) on those locations.

If I look at twiki log there is message like:

30 May 2007 - 20:07 WikiAdmin save ContactList graph1856288574b6cce95cd6a0bf10b512b1.png 192.168.0.136

This means there has been file saving? but why folder is empy?

Centos 5.0 and TWiki-4.1.2, build 13046, Plugin API version 1.11

-- MarkoRintamaki - 31 May 2007

I do have exactly the same problem like RickMach: I do not see any of these icons. I also changed the library reference. TWiki-4.0.4-4

Help!

-- MarijanaPrusina - 28 Jun 2007

RickMach: You should try DirectedGraphPlugin instead of DirectedGraph It worked for me.

-- KhanphaphoneVongsavanthong - 05 Jul 2007

RickMach: Do you see the icons when antialiasing is disabled?

-- AndreasVoegele - 23 Jul 2007

I got the plugin working under windows. I had to update all the paths in DirectedGraphPlugin.pm. I also had to remove ~ from configure/Security Setup/{NameFilter} Perhaps a security concern for a public site.

In tools/DirectedGraphPlugin.pl, I updated execCmd; adding set, moving quote back on set, and adding &.

# GV_FILE_PATH need to be set for dot to load custom icons (shapefiles)
my $execCmd = "set \"GV_FILE_PATH=$ARGV[1]/\" & $ARGV[0] -T$ARGV[3] $ARGV[2] -o $ARGV[4] 2> $ARGV[5] ";

-- JustinLove - 07 Sep 2007

I'm having a problem with this plugin where all of the examples display, but the boxes encapsulating text are almost always too small and the text runs out the edges.

Has anyone else had a similar experience?

-- JohnMSpencer - 20 Sep 2007

I'm doing some rework of the DirectedGraphPlugin associated with expanding the FamilyTreePlugin to take advantage of DirectedGraphs and I'd like to get some feedback on changes that I'm proposing.

  • Change path configuration settings to use the Localsite.cfg file - eliminate requirement to directly edit DirectedGraphPlugin.pm
  • Add an optional parameter to control generated file names (file=xxx) to the <dot> tag.
  • If not specified, attachments would be named to DGPlugin_n.<type>, n incrementing for each instance of <dot> in a topic.
  • Store md5 hash information in a TWiki _work_area in files named $web_$topic_<filename>
  • Generate file output in a single pass of the dot file using multiple -T... -o ... parameters
  • Support any -Txxx output type supported by the underlying graphviz engine.
  • Generate all files into a temporary directory
  • Other cleanup to do file and directory manipulation only using TWiki::Func routines.

I was going to try to preserve the original hash based filenames however it appears to be cleaner to move to a generated name that is repeatable and predictable. This should eliminate the ever-growing attachment list as graphs are modified.

-- GeorgeClark - 05 Jan 2008

In digging a little more, it looks like the library capability needs to be changed to be compatible with the "store" work. The getPubDir function is deprecated. I believe that to preserve this function and be compatible with the Store function, the attachment names need to be extracted from the library topic Meta data. Then the attachments need to be copied into a temporary directory for access by graphviz.

-- GeorgeClark - 05 Jan 2008

I've created open item Bugs:Item5212 to track this.

-- GeorgeClark - 05 Jan 2008

Sounds like very fine and needed enhancements to me, please go right ahead smile

-- SteffenPoulsen - 05 Jan 2008

Hi, I'm having trouble getting this Plugin to work on FreeBSD with TWiki-4.1.2, Sat, 03 Mar 2007, build 13046, Plugin API version 1.11. It looks like engineCmd isn't expanded properly (or is that something the sandbox has to do? Anyway, I added the following line below the sandbox->sysCommand call:

&writeDebug("sandbox: cmd: $perlCmd$engineCmd\nscript: $toolsPath$dotHelper\nwrkdir:$workingDir\n output: $output \n status: $status");

And do get the following output:

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - incoming: 
digraph G { size="2,3!"; dpi="100";
         edge [arrowhead=none color=blue];
         node [fontcolor=blue color=white];

         Workstation [shapefile="Sun_Workstation.png"];
         Printer [shapefile="Printer.png"];
         Internet [shapefile="Cloud-Filled.png"];
         Router [shapefile="Wireless_Router.png"];
         Switch [shapefile="Workgroup_Switch.png"];
         Laptop [shapefile="Laptop.png"];

         Workstation -> Switch;
         Printer -> Switch;
         Switch -> Router;
         Router -> Internet;
         Laptop -> Router [style=dotted];
}
,  engine="dot"  antialias="1" size="300x300" density="100" library="TWiki.DirectedGraphPlugin" , antialias = 1, density = 100, size = 300x300, vectorformats = none, engine = dot, library = TWiki/DirectedGraphPlugin, doMap = , hash = on 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - PARAMETER engine value is dot 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - PARAMETER antialias value is 1 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - PARAMETER library value is TWiki.DirectedGraphPlugin 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - PARAMETER size value is 300x300 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - PARAMETER density value is 100 

| 01 Feb 2008 - 11:29 | DirectedGraphPlugin - sandbox: cmd: /usr/bin/perl %HELPERSCRIPT|F% %DOT|F% %WORKDIR|F% %INFILE|F% %IOSTRING|U% %ERRFILE|F% 
script: /usr/1822direkt/intranet/data/twiki/data/tools/DirectedGraphPlugin.pl
wrkdir:/usr/1822direkt/intranet/data/twiki/pub/TWiki/DirectedGraphPlugin
 output:  
 status: 2

This is with extender.pl installed. The dotfiles are generated in /tmp/twiki but the helper script under tools/ is never called.

What am I missing?

-- UlrichSpoerlein - 01 Feb 2008

I don't have FreeBSD available to try this, and I'm not sure what the status: 2 is all about. Have you enabled the "debug" parameter in the tools script to get debug messages from there as well? Is the path to the dot command set correctly in the LocalSite.cfg? Can you manually execute dot using the input file that was left behind in the temp directory?

-- GeorgeClark - 10 Feb 2008

Sorry for the late reply ...

tools/DirectedGraphPlugin.pl is never executed, setting debug=1 inside of it has no effect. The path to the dot(1) binary is correct and the .dot files are ok, I can run them through dot manually.

Somehow the Sandbox for 4.1.2 is not able to run this or isn't set up correctly. I copied over Sandbox.pm from 4.2 but this changed nothing. I guess an update to 4.2 is inevitable.

-- UlrichSpoerlein - 04 Mar 2008

All the example in the Plugin work except for the Simple Lan, where I get the erro

You get: (if installed)
DirectedGraph Error (134): Problem executing dot command

*DirectedGraphPlugin error:* 

*** glibc detected *** realloc(): invalid next size: 0x09b3a680 ***
01: 

Does anyone know what this means?

-- PeterJones - 11 Mar 2008

Hi. I have the plugin working, including the use of client-side imagemaps with my own graphs.

However, I have two problems with image maps.

1 I noticed that the client-side imagemap examples in the plugin do not work properly. The simulated examples work, but the "rendered" examples only link to "www.twiki.org", which is the URL for the graph, regardless of where in the picture I hover my cursor. I get the same result with IE 7 and Firefox 2.0.0.6.

I can see a difference in the generated HTML that may account for this behaviour. In the simulated examples, the "area" that links to www.twiki.org follows the "areas" that link to specific topics. In the generated HTML, the "area" that links to www.twiki.org precedes the other areas.

Is this a problem with the plugin or a problem with my setup?

2 The image map is corrupted if I include WikiWords in my descriptions. For example:

<dot map=1>
digraph G
{
A [URL="WebChanges"];
B [label = "Reference the WebTopicList from a label", URL="WebHome"];
A -> B;
}
</dot>

What I get is:
WebTopicList from a label" alt="" coords="355,133 346,125 322,118 283,112 234,108 180,107 126,108 77,112 38,118 14,125 5,133 14,141 38,149 77,155 126,158 180,160 234,158 283,155 322,149 346,141"/>
followed by a figure. "A" links to WebChanges, but "Reference the WebTopicList from a label" does not link to anything.

I have patched the plugin to fix this - I added another parameter that makes the plugin blank out the labels when creating the image map. However, it seems like a hack. Again - is this a problem with the plugin or a problem with my setup?

I am using GraphVis 2.12, under Ubuntu 7.10. The plugin $VERSION is 16262 (18 Jan 2008).

-- MichaelTempest - 17 Mar 2008

Hi Michael, I don't see the 1st problem. Not sure what is going on there.

I can confirm the 2nd problem - Using GraphViz 2.16 on Gentoo. If you want, open a bug report in the bugs web. I'm guessing it is something to do with the recursive expansion of the topic text in TWiki. Maybe the code should escape any wiki words inside of a directed graph tag.

I do have a heavily modified version of the plugin - I've been rewriting the file handling. I'll try to fix these on my local copy and get them all checked in at once.

-- GeorgeClark - 09 Apr 2008

I've raised bug Bugs:Item5508

I've made a fairly simple change that appears to work here, but I won't check it in for a while - too many other modifications on my local copies. At the very end of the handleDot routine is a section that begins if (doMap)

I changed the line

   return "$mapfile<img usemap=\"#$hashCode\" src=\"$src\"/>";

to read

   return "<noautolink> $mapfile<img usemap=\"#$hashCode\" src=\"$src\"/> </noautolink>";

That seems to protect the generated image map from further expansion by TWiki.

-- GeorgeClark - 09 Apr 2008

I upgraded to GraphViz 2.16 and the plugin examples now work correctly. That fixes the first problem.

The change you suggest works great (and, unlike mine, it is not a hack), so the second problem is also fixed - thank you!

-- MichaelTempest - 09 Apr 2008

I'm trying to use some of the other polygon shapes described in the Graphviz docs ( http://graphviz.org/doc/info/shapes.html ), but lots of them error or produce empty graphs, e.g., "component", "note", etc.

Do you need to install any extra Graphviz stuff to get those?

-- AaronFuleki - 01 Jul 2008

As far as I know, you shouldn't have to do anything to access all of the graphviz shapes. If you look at the raw view of the TWiki/HowtoDirectedGraphs topic installed with the plugin, you should be able to copy the dot language used to generate all of the shapes in the Howto.

You could always test the graphviz dot command directly from outside of TWiki. All the plugin does is copy the text between the dot tags and pass it to the graphviz processor.

-- GeorgeClark - 02 Jul 2008

No, I get all the shapes used in TWiki/HowtoDirectedGraphs, but not the others listed in the graphviz docs (note, component, etc., as seen in http://graphviz.org/doc/info/shapes.html). Those just render as rectangles for me (the empty graphs were another problem, I think).

Trying to define my own shape files works okay, but none of the dot commands to adjust label position work for me (e.g., 'labelloc=t'), and custom shapes aren't rendered if I enable anti aliasing.

The graphviz rpms for RHEL4 look a little old - dunno if there may be a compatibility issue. It looks like I have graphviz-2.2-1.2.el4.rf installed, according to rpm.

-- AaronFuleki - 02 Jul 2008

I'm attaching a test build of DirectedGraphPlugin that has quite a few changes. If anyone has some time to test it out, that would be great. I'd like to get some additional testing done before I generate a "release".

It addresses several bugs that I've already checked into SVN.

The most significant changes are related to workarea files. Instead of creating a single file per graph per topic, it now uses the perl Storable class to store all of the plugin metadata about a topic into a single file. The code does find and clean up older format files.

It also will now "trash" any attachments that are no longer generated in a topic, but only if the DELETEATTACHMENTS parameter is enabled. It is disabled by default. If DELETEATTACHMENTS is enabled prior to the plugin converting from old to new style workarea metadata, it will also trash all older graphs that may be left over from previous versions of the topic and plugin. Trashed attachments are moved to the Trash web.

I've added a number of other minor changes including parameters to choose the inline file format, and some other code cleanup. I also added an example for generating "ladder" diagrams.

The plugin still uses the TWiki API for creating and modifying attachments. Unfortunately this has side effect of topic change notifications whenever a graph changes, even if the graph is generated from data outside of the topic. It also requires the user to have update rights on a topic if the graph has changed for any reason.

I've had some discussion with Crawford and Peter about implementation options. Changing the plugin back to using direct file I/O for the graphs would solve the topic change problem, however use of the TWiki API is really the more forward looking implementation in that directly manipulating /pub/ attachments is deprecated and is incompatible with the "Store" backend.

There are a couple of possible solutions

  • Go back to direct file I/O into the /pub directory and deal with Store issues in the future.
  • Store files in a web accessible directory outside of the TWiki hierarchy
  • Request core to add parameters to the Attachment API so that the plugin can store attachments without recording topic changes and without authorization checking.

I'm thinking that it would be better to stick with the supported API but possibly add a configuration parameter that would allow the plugin to do direct file I/O. And if core could add parameters to the Attachment API, that would be great.

A couple of other enhancements I've been considering is adding shortcut links to other attached file types [jpg] [ps] ... Maybe making inline graphics optional.

Any other suggestions?

-- GeorgeClark - 09 Aug 2008

It will take some time to move to a storage backend for attachments, and as you notice, the current API is not sufficient for transient data, e.g. changing topic history for derived data is not good. There is also a performance issue by using the official API. Therefore for transient web accessible data I suggest to keep using the direct I/O in the pub directory as it was recommended in earlier TWiki versions.

George, if you do not yet have SVN access I recommend to ask for it. ReadmeFirst has more.

-- PeterThoeny - 16 Aug 2008

Hi Peter, Thanks. I have SVN for plugins, not for core. Using /pub works, but I took the deprecation notice in Func:: seriously. Anyway, I've found that if Autoattach is enabled, they end up in the topic anyway, and cause a bit of a mess. And although the code I wrote to do cleanup helps a lot, hiding the files and never deleting them as the original version did becomes a big problem. I orginally found some topics with nearly 100 stale graphs using the original plugin, which is what sent me down this path.

I think what I'm going try to do is:

  • Add a configuration parameter to set the storage directory. If not configured, then it will use the file attachment API.
  • Investigate/propose a patch to core to add the "ignorePermissions" flag for the attach API that the saveTopicText API already provides.
  • Same for the minor / dontNotify flags as implemented on saveTopic / saveTopicText.

-- GeorgeClark - 17 Aug 2008

I've committed an update for TWikibug:Item5954: DirectedGraphPlugin should permit direct file I/O. This adds two configuration variables to the bin/configure interface. attachPath and attachUrlPath. If attachPath is set to match TWiki's pub path, then the plugin will do direct file I/O to the pub directory and continue to use the default pub path. If attachPath is set to some other directory, then the attachUrlPath must also be set to TWiki can generate valid URLs to the files.

I've also added the ability to generate [type] links to each generated file. If the files are written to pub directly, then they will not show up as attachments. if linkattachments is enabled, then the plugin will generate [type] links for each generated file below the inline image.

I have no easy way to test the changes on a windows server. Since direct file system access is involved, there may be issues that need to be found.

I'll attach updated DirectedGraphPlugin .tgz and .zip files to this topic for testing before I upload the new release.

-- GeorgeClark - 01 Sep 2008

Hang on - I've installed this on another server to test it more thoroughly and something isn't right. Looking into it - not worth testing this for now.

-- GeorgeClark - 01 Sep 2008

One more try - attachments updated. Found one possible issue, plus my test server had auto attach enabled for files in pub

-- GeorgeClark - 01 Sep 2008

Your version works ok for me, George.

-- MartinCleaver - 18 Sep 2008

Bugs:Item6058 filed reporting some compatibility issues on Windows. Also the documentation doesn't clearly identify dependencies. ImageMagick requires that GhostScript be installed to convert files from .ps to other types.

-- GeorgeClark - 11 Oct 2008

I've attached a test build with the windows fixes, addressing Bugs:Item6058.

-- GeorgeClark - 12 Oct 2008

I had a problem with generating dot graphics.. There was no an kind of pictures until serveral try out I found there was a need for reconfigure plugins for dot? This was done by command "dot -c". After reconfigure I was able to see images smile Centos 5.2/Twiki 4.2.3 I hope this will help some of you

-- MarkoRintamaki - 14 Oct 2008

This is one amazing plugin. I got this to work on my TWiki 4.2.0 instance which is hosted on Apache 2.2.9 (Win32) with ActiveState Perl v5.8.8 build 822 on Win2k3 in one single day!

I first downloaded GraphViz 2.24 for Windows from http://www.graphviz.org/pub/graphviz/stable/windows/graphviz-2.24.msi?type=Finjan-Download&slot=00000143&id=00000142&location=B2010250. I then installed it into D:\Graphviz2.24.

Then I downloaded ImageMagick -6.3.3-10-Q16-windows-dll.exe from http://image_magick.veidrodis.com/image_magick/binaries/ and installed it into D:\ImageMagick -6.3.3-10-Q16.

I then downloaded Ghostscript 8.70 from http://sourceforge.net/projects/ghostscript/files/GPL%20Ghostscript/8.70/gs870w32.exe/download and installed it into D:\Ghostscript.

Then I ensured that the following paths were present in my PATH env var:

D:\ghostscript-8.70\gs8.70;D:\ghostscript-8.70\gs8.70\bin;d:\imagemagick-6.3.3-q16;D:\Graphviz2.24\bin

You edit the PATH env variable in Control Panel > System > Advanced > Environment Variables. I think I only needed to add the ImageMagick one manually but you should check.

Finally I installed and enabled the DirectedGraphPlugin and set the following values for my DGP parameters:

$TWiki::cfg{DirectedGraphPlugin}{enginePath} = 'D:/Graphviz2.24/bin/'; $TWiki::cfg{DirectedGraphPlugin}{magickPath} = 'D:/ImageMagick-6.3.3-Q16/'; $TWiki::cfg{DirectedGraphPlugin}{toolsPath} = 'D:/inetpub/twiki/tools/'; $TWiki::cfg{DirectedGraphPlugin}{perlCmd} = 'D:/Perl/bin/perl.exe'; $TWiki::cfg{DirectedGraphPlugin}{attachPath} = ''; $TWiki::cfg{DirectedGraphPlugin}{attachUrlPath} = '';

Then restart Apache for good measure. Voila! Thanks Cole!

-- JamesGMoore - 2009-08-27

I got this working (also in a day) on an Apache running on Windows, with Cygwin for Perl, ghostscript, GraphViz and ImageMagic. Since the default Cygwin repository does not include GraphViz nor ImageMagic, I obtained them from the CygwinPorts repository (see http://cygwinports.org ).

There is an issue when ImageMagic needs to do anti aliasing, but since we use SVG anyway it does not bother us to much.

With antialias=on (either in the dot or as a setting) I get DirectedGraph Error (4), which is not in the list of known errors... The debug shows that ImageMagic works fine for the identify step (the size is obtained correctly), but the next step (geometry) results in

| 2012-11-08 - 09:05 | DirectedGraphPlugin - dgp-antialias: output:  
 status: 4

-- JochenVanDenBossche - 2012-11-08

With the lastest version of the plugin and on TWiki 6.0.0 we get the following error

Undefined subroutine &TWiki::Func::getRequestObject called at /opt/twiki/prod/lib/TWiki/Plugins/DirectedGraphPlugin.pm line 123

Anyone seen this? What is the workaround?

-- Peter Jones - 2014-06-26

So the problem is that TWiki::Func::getRequestObject does not exist. The workaround is to change the version number to be checked in DirectedGraphPlugin.pm on line 123. At least I get the maps to render now.

-- Peter Jones - 2014-07-01

Thanks for the alert Pete. The SVN trunk version has been fixed in 2013-09, but the published DirectedGraphPlugin package was outdated. This is fixed now.

-- Peter Thoeny - 2014-07-01

Ok thanks, I see that the fix works ok

-- Peter Jones - 2014-07-09

Hi all, Here's a question about the URL feature. Using MichaelTempest's example above, I can't use standard TWiki syntax in the URL parameter to link to topics in other webs.

In other words, while this works fine for me:

<dot map=1> digraph G { A [URL="WebChanges"]; B [label = "Reference the WebTopicList from a label", URL="WebHome"]; A -> B; } </dot>

A and B end up with valid links to topics WebChanges and WebHome in the same web. However, in this example:

<dot map=1> digraph G { A [URL="Otherweb.WebChanges"]; B [label = "Reference the WebTopicList from a label", URL="Otherweb.WebHome"]; A -> B; } </dot>

the hrefs don't render properly. Is this a feature or a bug? Is there some other TWiki-like way (other than a regular, non -TWiki URL -- relative or absolute) to refer to topics in other webs?

Thanks very much in advance,

Eddie Rubeiz

-- Eddie Rubeiz - 2015-07-30

Possibly a bug, I have not checked. In any case, as a workaround you can create portable URL pointing to TWiki itself: %SCRIPTURL{view}%/Otherweb/WebChanges

-- Peter Thoeny - 2015-07-30

That works. Merci vilmal, heh.

-- Eddie Rubeiz - 2015-07-30

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng 403rc_dir_structure.png r1 manage 177.3 K 2006-06-15 - 11:29 SteffenPoulsen Example dir structure from 403rc dist
Compressed Zip archivetgz DirectedGraphPlugin.tgz r4 r3 r2 r1 manage 360.5 K 2008-10-12 - 04:03 GeorgeClark 10/12 Windows fixes
Compressed Zip archivezip DirectedGraphPlugin.zip r4 r3 r2 r1 manage 403.3 K 2008-10-12 - 04:04 GeorgeClark 10/12 Windows fixes
Texttxt dir2dot.pl.txt r1 manage 2.5 K 2006-06-15 - 11:16 SteffenPoulsen Perl script for making a dot graph of a directory structure
Edit | Attach | Watch | Print version | History: r145 < r144 < r143 < r142 < r141 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r145 - 2015-07-30 - EddieRubeiz
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.