Recent versions of Graphviz no longer set the PATH variable on Windows.
Hence Scyther can fail to find dot.exe even though Graphviz was appropriately
installed.
This patch is a hack to try and locate dot.exe in the more common locations.
We currently have a hardcoded search through:
C:\Program Files\Graphviz*
C:\Program Files (x86)\Graphviz*
This is clearly fragile. Obviously, nobody should be solving Graphviz' problem
in such an ugly way. Change drives or languages and it stops working.
Until Graphviz provides at least an alternative environment variable (GVPATH?)
this hack will help the bulk of our users to get things up and running smoothly.
Previously, pressing 'cancel' in the verification window would leave a dangling scyther backend process.
Now the process gets correctly killed.
The following changes enable this:
- External processes are no longer invoked through the shell (otherwise they are subprocesses of the shell and cannot be reliably killed cross-platform).
- The 'safeCommand' procedure now has a hook for passing opened Popen objects.
- The GUI stores and kills the Popen objects on cancel or window close.
To do: an alternative interface for this in 'safeCommand' could expose a 'killMe' method through a callback; this might be cleaner in the long term.
Before, we were using both __file__ as well as sys.argv[0] to determine the base directory
for Scyther, and we were not taking symlinks into account.
By using the inspect module, we can consistently pick the current frame and derive
the file from that, then use realpath to strip symlinks.
To do: We still need better error handling.
- File exists: overwrite?
- Write failed popup.
- Check for empty file at the end (what if dot does not support this particular
output format?)
A long requested feature was the option to print graphs more nicely.
This is a solution for knowledgeable users: the dot data is more basic
and can be converted in various ways.
TODO: Simple image export.
Reported by ETH students last year: if you include a file, where the file has an
error in a line with a number higher than the original, the Python code crashes.
This is a *patch* only because the real underlying problem is that error reporting
does not take include commands into account, and does not propagate any
file names.
Passing the '--all-attacks' switch to the backend was not working. The reason
was the hack to get Vista working hardcoded cutting to the last attack found.
In the long term, this needs to be cleaned up, and cutting should be moved back
nicely to the Scyther C code where it used to work. Once done, switches.useAttackBuffer
can be set back to true.
BUGFIX: When cutting attacks/patterns, counts are no longer exact.
Currently, both my Feisty Ubuntu's have stopped working with the GUI of
Scyther. So to be on the safe side, PIL is disabled for now, until I've
resolved the problem.
The error is the following:
---------------------------------------------------------------------------
Traceback (most recent call last):
File "/home/cas/src/scyther-dev/gui/Gui/Scytherthread.py", line 351, in onViewButton
w = Attackwindow.AttackWindow(btn.claim)
File "/home/cas/src/scyther-dev/gui/Gui/Attackwindow.py", line 176, in __init__
self.CreateInteriorWindowComponents()
File "/home/cas/src/scyther-dev/gui/Gui/Attackwindow.py", line 209, in CreateInteriorWindowComponents
dp = AttackDisplay(self, self, attacks[0])
File "/home/cas/src/scyther-dev/gui/Gui/Attackwindow.py", line 73, in __init__
self.original = Image.open(filename)
File "/usr/lib/python2.5/site-packages/PIL/Image.py", line 1912, in open
return factory(fp, filename)
File "/usr/lib/python2.5/site-packages/PIL/ImageFile.py", line 82, in __init__
self._open()
File "/usr/lib/python2.5/site-packages/PIL/EpsImagePlugin.py", line 277, in _open
raise IOError, "cannot determine EPS bounding box"
IOError: cannot determine EPS bounding box
---------------------------------------------------------------------------
Great. Bounding boxes in eps again.
Since a while, wxPython has been refusing to correctly display strings with a dash in them in the staticText object. Given a string "xx-yy", only "xx" is displayed. This caused some problems for protocols with dashes in their protocol names. I've worked around it by replacing all occurrences of "-" by "_".
