oliviers-oss / mscgen Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/mscgen
License: GNU General Public License v2.0
Automatically exported from code.google.com/p/mscgen
License: GNU General Public License v2.0
Building Mscgen =============== Building is done with the GNU autotools and should be largely automatic. Preparation ----------- If you obtained the sources directly from the SVN repository, you will first need to run autogen.sh to generate the configure script. Note: This is not required for the downloadable source tarballs as they are already contain a configure script. Win32 - Native -------------- A native build has no runtime dependency on Cygwin and can be ran on any Windows machine. It does however use Cygwin to configure and build. You can get Cygwin from http://www.cygwin.com. The following packages need to be installed via the Cygwin setup.exe: - gcc - gcc-mingw - make - flex - bison - binutils A copy of the Win32 libgd library is also needed. If you checked out the mscgen sources from Google Code, you will already have this in the gdwin32 directory. Otherwise you can obtain a copy from the GD site, or from Google Code: http://www.libgd.org/releases/oldreleases/gd-2.0.34-win32.zip svn checkout http://mscgen.googlecode.com/svn/trunk/gdwin32 /tmp/gdwin32 You will have to unpack the zip file, and ensure the file bgd.dll is on your path. From the top level directory, run the configure script with options to build natively and use the Win32 binary gdwin32 you downloaded (an unpacked): $ ./configure CFLAGS=-mno-cygwin \ GDLIB_CFLAGS="-I/tmp/gdwin32/include" \ GDLIB_LIBS="-L/tmp/gdwin32/lib -lbgd" $ make $ make check $ make install This will install a native version of mscgen and the accompanying bgd.dll file into the cygwin directories. If you wish to install elsewhere, either use the --prefix option to 'configure', or manually copy mscgen.exe and the DLL. The DLL dependencies of the mscgen.exe can be checked using cygcheck: $ cygcheck.exe mscgen.exe Found: C:\cygwin\bin\mscgen.exe C:\cygwin\bin\mscgen.exe C:\cygwin\bin\bgd.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\MSVCRT.dll Win32 - Cygwin -------------- You will need Cygwin (from http://www.cygwin.com) and the following packages installed via the Cygwin setup program: - gcc - make - flex - bison - binutils - libgd2 - libgd-devel - pkg-config From the top level directory, run the configure script and then make: $ ./configure $ make $ make check $ make install Other Unix-like Platforms ------------------------- You will need: - flex, bison, gcc and pkg-config installed - GD >= 2.0.22 libs installed (libgd-devel) - GD's dependencies, which are dependent on how it was configured, but will typically be a subset of the following: libpng libz libfreetype libm - GNU make GD can be obtained from http://www.libgd.org/ and will need to be downloaded and installed, or a package, such as an RPM maybe used instead. For RedHat and SuSE, the package gd-devel should be installed, which will normally cause any dependent libraries to also be installed. From the top level directory, run the configure script and then make: $ ./configure $ make $ make check $ sudo make install Syntax Highlighting =================== A lang file for GtkSourceView based editors is included with mscgen. The mscgen.lang file, normally installed with mscgen to /usr/share/doc/mscgen but needs copying to one of two locations for GtkSourceView: /usr/share/gtksourceview-2.0/language-specs - System wide installation ~/.local/share/gtksourceview-2.0/language-specs - User specific installation This then allows mscgen input files to be displayed with syntax highlighting in applications such a gedit and Anjuta. The language spec associates itself with .msc files. Bugs ==== An issue tracker is available at the following location: http://code.google.com/p/mscgen/issues/list You may also email me directly at [email protected]. Updates ======= A release announcement mailing list for new releases is available at the following location: http://groups.google.com/group/mscgen-announce LICENCE ======= Mscgen, Copyright (C) 2010 Michael C McTernan, [email protected] Mscgen comes with ABSOLUTELY NO WARRANTY. Mscgen is free software, and you are welcome to redistribute it under certain conditions; see the COPYING file for details. PNG rendering support is provided by libgd, www.libgd.org; see the COPYING.gd file for full credits. END OF FILE
What steps will reproduce the problem?
Make a box with a \n special character to create a two-line output.
What is the expected output? What do you see instead?
Expect box to expand over the second line, but it doesn't. It only starts
expanding on 3+ lines
What version of the product are you using? On what operating system?
Mscgen version 0.17, Copyright (C) 2007 Michael C McTernan,
[email protected]
Mscgen comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions; type `mscgen -l' for
details.
Please provide any additional information below, including sample input
file:
msc {
App1, App2, App3;
|||;
App2 box App2 [ label = "line1\nline2"];
|||;
App2 rbox App2 [ label = "\nline2"];
|||;
App2 abox App2 [ label = "line1\n "];
|||;
App2 box App2 [ label = "line1"];
|||;
App2 box App2 [ label = "line1\nline2\nline3"];
|||;
}
Original issue reported on code.google.com by [email protected]
on 16 Apr 2010 at 9:14
What steps will reproduce the problem?
Output of the following MSC's
Issue1:
msc {
a, b, c;
a => b [label="line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10"], b=>c [arcskip=1];
a => c;
}
Issue2:
msc {
a, b;
a => b [arcskip=1];
}
What is the expected output? What do you see instead?
Issue1:
"b => c" arc should meet "a => c" at the arrow tip. Instead arcskip is using a
constant vertical shift.
Issue2:
Unexpectedly output is clipped vertically.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 10:58
It would be nice to have some way to tell mscgen to generate multiple pages
documents for printing.
When a MSC gets too long, is very hard to print it, because, even if you
split the output yourself in multiple pages, the "header" (entities for
which each timeline is) is not repeated, making very hard to follow the
diagram.
If multi-page output is too hard, at least it should be a way to manually
repeat the "headers". Something like
msc {
a, b, c;
a -> b;
b -> c;
a, b, c; // or hhh, or anything else to ask for the headers
c -> a;
c -> b;
}
Original issue reported on code.google.com by [email protected]
on 18 Nov 2009 at 4:03
In the grammar file[1] I noticed the following:
| 'id'URL
It looks like a mistake.
[1] http://www.mcternan.me.uk/mscgen/grammar.txt
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 1:42
Add relops that produce bi-directional arcs (with arrows on both ends):
These would produce the same line and arrowhead styles as the current
uni-directional arc types, but with arrowheads on both ends:
a<>b
a<->b
a<=>b
a<<=>>b
a<<>>b
a<:>
and then relops that produce non-directional arcs (same line style as the
corresponding direction arcs, but with no arrowheads):
a.b
a-b
a=b
a:b
What version of the product are you using? On what operating system?
0.16, Fedora 10
Original issue reported on code.google.com by xmlscott
on 28 Aug 2009 at 9:04
It would be nice if there was an ability to make a left and/or right
aligned column to include some annotations that don't fit nicely onto the
diagram.
For example, say I have access to timestamp information for each action, I
might like to be able to see the timestamp of each action in a column off
to the left of the main diagram without it cluttering up the diagram
itself.
example syntax:
A->B [ label="hello", leftannotate="Timestamp: 10:00:01" ]
A->B [ label="hello", leftannotate="Sent: 10:00:01",
rightannotate="Arrived: 10:01:05" ]
Original issue reported on code.google.com by [email protected]
on 7 Aug 2009 at 11:35
I'm attaching a patch that removes the hooks in example/Makefile.am, which
should reduce future
issues due to changes in hooking and such.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2009 at 2:09
Attachments:
Hi
I made a patch for stripping input-files of their ".msc" extension, so it
will be replaced by the "type", when -o is not given. So instead of
"file.msc.png" it will now produce "file.png", when running:
mscgen -Tpng "file.msc"
I have introduced str.c and str.h that contains "strcaseequals()", which
uses strcasecmp to do its job. For platforms without strcasecmp, an
emulation is inserted. Feel free to merge this code into another file, I
just couldn't figure out a good spot to place it. configure.ac includes
check for this function and for "_strcasecmp" (Windows/Cygwin tends to
"prefix" functions with _ - not sure if strcasecmp was one of them).
While testing this I noticed that the implicit "-i" flag "eats" the two
first characters of the input-file name (it believes that the "input file"
argument is actually "-i$name" instead of just "$name"). The patch also
fixes this. I have modified the test to not use the "-i" flag to catch
regressions. It does however still use the -o flag (or else the output ends
in the source dir rather than the build dir!). Other modifications to the
test includes looping through "types" and usage of the "-T<type>" instead
of "-T <type>" to check for regressions here.
Last but not least, when building out of "dir", the "included" libgd was
not detected - the patch also fixes this.
The patch was made based on revision 71. I can split the patch into
separate patches, if desired.
~Niels
Original issue reported on code.google.com by [email protected]
on 25 Jul 2009 at 5:03
Attachments:
What steps will reproduce the problem?
Set the following two variables:
CFLAGS="-Wall -Wextra"
CXXFLAGS="-Wall -Wextra"
and then run make
What is the expected output? What do you see instead?
Fewer warnings (ignoring the ones from null_out.c)
What version of the product are you using? On what operating system?
I used mscgen-0.14 on a debian/lenny
Other info.
I have created a patch that fixes most of the issues. For most parts these
warnings were different signedness in comparisons (which I have removed by
typecasting or changing the signedness of some of the variables). Two
issues remain though:
* I did not know how to deal with the missing return statement in
renderer/gd_out.c's getColorRef(). Someone with knowledge about how it is
expected to behave needs to deal with that.
* "unistd.h" is not a standard header (namely I am pretty sure Windows
does not have it), so in renderer/main.c I put it in a cpp conditional. It
uses the same syntax as autoconf uses in its "config.h". If your Makefile
has some way of determining the availability of header-files, you can use
-DHAVE_UNISTD_H to get the file included. Alternatively, if there is
interest for it, I can setup an autoconf build system for this.
This patch does not fix anything in null_out.c - The file name suggested
the "unused parameter" warnings were very expected. If anything, add a flag
in the Makefile to always suppress warnings from this file.
Again I expect that most of these (save for the missing return) were not
likely to cause issues, but I saw the request for getting a debian package
out of this (http://code.google.com/p/mscgen/issues/detail?id=6) and if
they are as uptight with the code as they are with their packages, you
might have heard it from a maintainer instead of me.
~Niels
Original issue reported on code.google.com by [email protected]
on 19 May 2009 at 9:38
Attachments:
I love this product. I have known about it for some time and recently
started using it. Keep up the good work.
What steps will reproduce the problem?
msc {
one,two,three;
|||;
one->three [label = "this\nlabel\nhas\nseveral\nlines" ];
|||;
|||;
|||;
|||;
|||;
}
What is the expected output? What do you see instead?
I expect the line to be masked when multi-line labels overlap the line.
What version of the product are you using? On what operating system?
0.14, winxp sp3
Original issue reported on code.google.com by [email protected]
on 22 Apr 2009 at 9:08
What steps will reproduce the problem?
The following msc
msc {
arcgradient=40;
A, B;
A box B [label="Text inside box"];
}
What is the expected output? What do you see instead?
If arcgradient option is specified, text inside box is unexpectedly shifted
vertically downwards introducing white space above the text.
What version of the product are you using? On what operating system?
0.18, Any OS
Please provide any additional information below, including sample input
file:
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 1:05
What steps will reproduce the problem?
msc {
a, b;
a box b [label="This is very very long line of text that does not wrap within the box but instead goes in a straight line and even clipping at the ends"];
}
What is the expected output? What do you see instead?
Text to lie within box, but it is out of box and even clipped. It is difficult
for the user to split the line manually as the width of the box and width of
text are unknown and it needs to be done every time if the text changes.
Proposed solution:
The wrapping of text needs to be done automatically. Also a newline character
within the string shall not cause the line to break (like it is done in
doxygen). Only \n escape should break the line. This is to allow user to break
lines in doxygen without breaking lines in actual view. Multi-space/newline
between words may be converted to single space in view. This is to allow user
to indent text in doxygen as given below.
msc {
a, b;
a box b [label="This is very very long line of text that
automatically wraps within the box"];
}
In code all this can be done as part of lex tokenization of string.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 10:28
Often I would like to have a sequence diagram with entities that don't exist at
the beginning of the sequence. For example, if a process spawns a worker thread
at some point, it would be nice for the lifeline for that thread to only begin
at that point.
Ideally to do this we would be able to introduce a new entity at any point in
the sequence, and conversely destroy an entity. For example:
msc {
M [label="Main"], P [label="Thread pool"];
...;
M => P [label="requestThread"];
t [label="worker"];
P :> t [label="<<create>>"];
M << P;
M => t [label="doWork"];
...;
M << t;
M => P [label="releaseThread"];
P :> t [label="<<destory>>"];
~t;
M << P;
...;
}
Which would generate something like the attached image.
Original issue reported on code.google.com by [email protected]
on 22 Jun 2010 at 11:59
Attachments:
What steps will reproduce the problem?
Run "mscgen -T png -o <somefile>" with the following input:
msc {
monitord, reporter;
monitor->reporter [ label = "Hello Segfault "];
}
Note that the variable it called "monitord", but is misspelled without the
d later.
What version of the product are you using? On what operating system?
0.15 (pulled from SVN)
As far as I call tell, it does not happen if you swap "monitor" and
"reporter" in the sample about - that is: "reporter->monitor" produces a
"unknown entity"-error instead of segaulting.
Compiling with "-g" and using valgrind I get the following stack-trace(s):
Invalid read of size 4
at 0x804F688: MscGetEntAttrib (msc.c:597)
by 0x804B0D7: main (main.c:1248)
Address 0x4 is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x4
at 0x804F688: MscGetEntAttrib (msc.c:597)
by 0x804B0D7: main (main.c:1248)
~Niels
Original issue reported on code.google.com by [email protected]
on 19 Jun 2009 at 1:39
What steps will reproduce the problem?
Attempt to create a graph of the second sample listed on the website (as png).
What is the expected output? What do you see instead?
A graph - I get "mscgen: main.c:340: arrowR: Assertion `0' failed."
I have not traced the reason for this, so all I can say for now is that the
function "arrowR" gets a wrong type as argument.
What version of the product are you using? On what operating system?
Debian/Linux, using mscgen 0.15 and trunk revision 31.
Please provide any additional information below, including sample input
file:
# Example MSC using boxes
msc {
# The entities
A, B, C;
# The relations
|||;
# Next three on same line due to ','
A box A [label="box"],
B rbox B [label="rbox"],
C abox C [label="abox"],
|||;
A abox B [label="abox"];
|||;
B rbox C [label="rbox"];
|||;
}
NB: The first sample is generated without issues (only checked png version
though).
Original issue reported on code.google.com by [email protected]
on 2 Jul 2009 at 7:58
What steps will reproduce the problem?
Difference between the two MSC's below (Note the change in order of the arcs in
the following MSC's).
msc {
a, b;
a => b [label="Single line"];
a => b [label="Two\nline"];
}
msc {
a, b;
a => b [label="Two\nline"];
a => b [label="Single line"];
}
What is the expected output? What do you see instead?
It is expected that spacing between arcs is consistent, but it is not. There is
space between arcs in first msc and no space in second msc. Also single line of
text is NOT centered vertically, whereas multi-line text is centered vertically.
Analysis:
Initially mscgen was designed to have constant arc height. But later when
multi-line text issue is fixed, arc height became variable, subjected to a
minimum height. This minimum height (arc spacing parameter in code) was
probably a requirement to retain the legacy view and spacing of msc's. It is
the source of the current issue.
Possible solution:
One way to fix the problem is to have a consistent/constant spacing between
variable-height arcs. By default we can have a non-zero spacing between arcs.
Remove the minimum height parameter in code and introduce the
SpacingBetweenArcs parameter. This spacing between arcs parameter shall be
controlled through as an msc attribute.
Using ||| is not a solution, because it is explicitly needed between every
multi-line arc or needed whereever there is a box and also spacing is still
inconsistent and NOT controllable.
With SpacingBetweenArcs parameter introduced, |||, ... can add more space
between arcs i.e. they serve as additional space arc. This additional space
amount introduced by ||| and ... can also be an attribute.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 9:38
It would be nice to have some way to tell mscgen to generate multiple pages
documents for printing.
When a MSC gets too long, is very hard to print it, because, even if you
split the output yourself in multiple pages, the "header" (entities for
which each timeline is) is not repeated, making very hard to follow the
diagram.
If multi-page output is too hard, at least it should be a way to manually
repeat the "headers". Something like
msc {
a, b, c;
a -> b;
b -> c;
a, b, c; // or hhh, or anything else to ask for the headers
c -> a;
c -> b;
}
Original issue reported on code.google.com by [email protected]
on 18 Nov 2009 at 4:02
It would be very nice to have a DEBIAN package for mscgen: the Universe
package `msc` does not integrate with Doxygen.
Original issue reported on code.google.com by [email protected]
on 28 Apr 2009 at 1:23
mscgen from revision fails to builds graphs with type as "png" or "ismap";
giving the error:
Error: gdoTextHeight: Could not find/open font (GDFONTPATH=(null))
"svg" and "eps" images builds fine though.
I have tried to replace the value of the FONT macro in gd_out.c to a couple
of different fonts without luck. I cannot however figure out why it cannot
find these fonts.
On a related note, you may want to add "ifndef FONT", so it can be defined
from command-line (without it being redefined).
~Niels
Original issue reported on code.google.com by [email protected]
on 10 Jul 2009 at 1:37
Hi
Since mscgen only uses libgd for png support, it should not require this
library, when png support is disabled.
I have added a patch to the build system based on revision 75 that enables
"--with-png/--without-png" switches to enable/disable png support
(respectively) - defaulting to "--with-png".
When --without-png is used, configure will not check for gd and the build
system will not link against it either. This allowed me to discover that
svg_out.c requires -lm (for sin or cos), so in this patch mscgen always
links directly against said library instead of relying on libgd linking
against it.
Other changes in this patch: I also added "--with-libgd=$DIR" as a
short-cut for adding "-I$DIR/include" and "-L$DIR/lib", except configure
will bail if either dir does not exist - also if given, configure will
never fall back to using the convenience library[1]. This is a convenience
switch for people, who have libgd installed in a non-standard dir. It does
however not add an "RPATH" flag, so unless this is manually given in
LDFLAGS, mscgen will need to be run with LD_LIBRARY_PATH/RUNPATH/etc. set
correctly.
Also, I moved the macro functions to acinclude.m4 (which is automatically
checked by aclocal) - I felt it made configure.ac more readable. It should
noted however that autoconf/autoreconf is unable to spot if macros are
spelled wrong (by default at least), when they are placed in acinclude.m4,
in case more macro functions are added in the future.
~Niels
[1] Odds are, that if the user bothered to tell us where libgd is
installed, he/she does not want to use the convenience library.
Original issue reported on code.google.com by [email protected]
on 27 Jul 2009 at 7:35
Attachments:
What steps will reproduce the problem?
The following msc will reproduce the problem
msc {
A, B, C, D;
|||;
A box B [label="Single Line Text"],
C box D [label="Multiple\nLines\nof\nText\nof\nparallel\narc"];
|||;
A box C [label="Box at incorrect vertical position"];
|||;
}
What is the expected output? What do you see instead?
Resizing of arc according to text inside works only for the first arc in a
parallel set of arcs. Second and subsequent parallel arcs takes the vertical
size of first arc.
What version of the product are you using? On what operating system?
0.18, Any OS
Please provide any additional information below, including sample input
file:
In code, setting of ymax around lines 592 and 1465 should not be based on
addLines flag. Instead it should be set to maximum of all ymax calculations as
below. The fix below is not tested and is just pointing out the problem. Some
other changes may be required to correct the issue.
if (addLines)
{
ymin = ymax = nextYmin;
}
temp = ymin + gOpts.arcSpacing;
if(arcLabelLines > 1)
{
temp += (arcLabelLines - 2) * drw.textHeight(&drw);
}
/* Use temp instead of ymax in the ... code below */
...
...
if (temp > ymax) ymax = temp;
addLines = TRUE;
nextYmin = ymax + 1;
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 3:15
Attachments:
This issue requests an enhancement to the way attributes/options are specified
for msc. Currently it is specified immediately following "msc {" as in "msc {
opt1=value,opt2=value". Change required is to specify through "msc {
[attr=value, ...]", similar to arc attributes.
This is just a preference which I believe has some advantages.
(1) Parser can give meaningful error message if the attribute is mistyped,
since parser knows that it is an attribute which is mistyped and will not take
it as an entity name.
(2) Old version of mscgen can possibly ignore any unknown attribute after
giving a warning message and continue generating msc.
(3) Visual clue in msc language that they are options.
Without '[]', the 3 options currently available in mscgen shall continue to
work for backward compatibility.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 7:40
Since there are hardly any issues left, I figured I would dig out some good
ideas for things that could be implemented. I have been digging around on a
"certain website"[1] and looking at what their users have suggested.
One idea is "conditionals" (based on this suggestion[2]):
While the original commenter's idea probably not the best choice (at least
implementation-wise), it made me remember that doxygen allows for
"conditional sections" (particularly the "internal" section). With this in
mind, here is my suggestion:
Extend the language to include (very) simple if/else statements, so you can
have an "internal" and a "external" representation of the same system based
on the same graph. Something like this
if INTERNAL
/* Last week this involved a coffee break, but the "suits" decided a
dressingroom was better... 10 bugs says we have to change it again next
week. */
T->dressingroom [ label="Dress up for the Iberian Dance" ]
dressingroom->"Iberian Dance Task" [label="IbFandangoReq", URL="\ref
IbFandangoReq"];
else
/* The user does not need to know about the dressing room - the external
API is stable, which sadly cannot be said about the internal API. */
T->"Iberian Dance Task" [label="IbFandangoReq", URL="\ref IbFandangoReq"];
endif
Also:
if implemented
mscgen->doxygen [ label="Notify of new awesome feature" ];
doxygen->doxygen [ label="New release supporting new awesome feature" ];
endif
These "variables" would be given as a command line argument (e.g. using
-D<variable> like most C-compilers) or alternatively via an environment
variable. Personally I think that both approaches should be supported for
now. If cmd-line arguments are present, the environment will be ignored -
otherwise the environment would be used.
The reason for this is simple: It would allow a new version of doxygen to
pass these values on to mscgen without knowing if it supports it (using the
environment). This way doxygen developer(s) do not have to worry about
"breaking" old setups where mscgen has not been upgraded and can (some what
easily) be able to provide this new feature.
Of course, judging from the default "Doxyfile" they might just implement a
"MSCGEN_ARGS" or a "MSCGEN_SUPPORTS_CONDITIONALS" variable instead...[3]
To be honest, I am not sure how doxygen handles "if"s inside "msc" sections
- it may already be a feature when using doxygen. Nevertheless, I suggest
that the syntax would be identical, since if doxygen is actually already
parsing ifs inside "msc" sections, then we do not confuse doxygen - and if
it isn't, at least the user needs to learn one less "if-syntax".
Disadvantages: The parser/scanner may require substantial changes, since we
are no longer dealing with an "arclist" but an "arctree". The rest of the
code may not require (a lot of) change(s) - if the tree is flattened into a
list (discarding the unreachable branches) directly after the parser is done.
~Niels
[1] Shame on me: http://www.websequencediagrams.com/
[2]
http://websequencediagrams.uservoice.com/pages/9445-general/suggestions/251525-j
oin-command
[3] No ill intention ... They just have a lot of options in that file!
Original issue reported on code.google.com by [email protected]
on 18 Jul 2009 at 11:06
Hi
This is merely a reminder of misc./small things that should be fixed before
or at next release. I felt it was a bit much to open a separate issue these
things.
Before next release:
* Deal with license for test/testinput9.msc.
At next release:
* Update home page (under "The Software") - The library has been removed, etc.
~Niels
Original issue reported on code.google.com by [email protected]
on 27 Jul 2009 at 10:46
Hi
I noticed that renderer/bool.h and parser/bool.h have the exact same
contents but are two separate files. Since the renderer already needs some
header files from the parser folder I figured it might as well just look
for bool.h there as well.
~Niels
PS: The autotools branch looks good, I will give it a spin as soon as I can
get my SVN tools working.
Original issue reported on code.google.com by [email protected]
on 28 Jun 2009 at 10:00
What steps will reproduce the problem?
1. autoreconf -vfi (or the provided script autogen.sh)
2. ./configure
3. make
What is the expected output? What do you see instead?
Expected a configure, build
What version of the product are you using? On what operating system?
SVN rev 89 on CentOS-5.3 (linux-2.6.18, glibc-2.5, gcc-4.1.2)
Please provide any additional information below, including sample input
file:
The following patch resolves the issues: I found that autoconf-2.59 is
sufficient if C99-specific
semantics are not required. I found that a simple SEARCH_LIBS had the effect
of adding it to the
link line (or not if it's unnecessary), and swapping dist_doc_DATA to
dist_data_DATA works to fix
the automake error.
Patch is attached as "svn diff"'; please consider.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2009 at 1:19
Attachments:
What steps will reproduce the problem?
msc {
one,two,three;
|||;
one rbox one [label = "this is\nthe first\n entity" ];
|||;
|||;
}
What is the expected output? What do you see instead?
I expect the box to resize vertically to accommodate the multi-line text.
What version of the product are you using? On what operating system?
0.14, winxp sp3
Original issue reported on code.google.com by [email protected]
on 22 Apr 2009 at 9:19
Attachments:
When compiling with USE_FREETYPE, the font is hard-coded at compile time. I
have written a patch off revision 75, that allows a user to run-time select
the font for mscgen for PNG-images, either by giving a new argument[1] or
if not present, by setting the "MSCGEN_FONT" environment variable[2].
Neither way, it does not check if the output type is PNG, so no
error/warning is given in case the font ends up ignored.
If neither are given, mscgen will fall back to the value of the "FONT" macro.
This modifies the ADrawOpen() API (to accept the font name), but only the
GdoInit was modified to receive the font[3]. Nevertheless, it provides a
way to send the fonts to the other output formats, requiring only changes
to that output format (and the internals of ADrawOpen).
I hope you will consider it.
~Niels
[1] -F was arbitrarily selected.
[2] Taken out of the blue sky - just like [1].
[3] I was particularly unsure of how to implement this for svg and ps
output - given their current implementation.
Original issue reported on code.google.com by [email protected]
on 26 Jul 2009 at 5:01
Attachments:
mscgen is a very useful program, but the generated diagrams are just a
little... "boring".
It's possible to implement a couple of more colorful styles? something like
http://websequencediagrams.com
Original issue reported on code.google.com by [email protected]
on 25 Apr 2009 at 5:06
Hi
I just tried to rebuild mscgen-0.17 (the source package from the website)
and it installs the documentation in /usr/share/doc rather than
/usr/share/doc/mscgen
user@host: find .
[...]
./mscgen/usr/share/doc
./mscgen/usr/share/doc/examples
./mscgen/usr/share/doc/examples/msg_types.msc
./mscgen/usr/share/doc/examples/boxes_example.msc
./mscgen/usr/share/doc/examples/colour_sample.msc
./mscgen/usr/share/doc/examples/simple_prog_desc.msc
./mscgen/usr/share/doc/README
./mscgen/usr/share/doc/COPYING
./mscgen/usr/share/doc/ChangeLog
I believe the docdir variable set in configure.ac should have been
"'${datadir}/doc/mscgen'" [1].
~Niels
[1]
http://code.google.com/p/mscgen/source/diff?spec=svn95&r=95&format=side&path=/tr
unk/configure.ac
Original issue reported on code.google.com by [email protected]
on 31 Aug 2009 at 7:50
Hi
Recently there started a discussion about translated man-pages on one of
the Debian mailing lists and how to ensure that the user knew if they out
of date.
One of the debaters noted that the first "line" in a man-page[1] is:
.TH title section date source manual
mscgen.1 only fills out "title" and "section".
~Niels
[1] man 7 man-pages
http://www.kernel.org/doc/man-pages/online/pages/man7/man-pages.7.html
Original issue reported on code.google.com by [email protected]
on 17 Aug 2009 at 7:13
gcc reports
| inlined from 'main' at main.c:1055:
| /usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk
might overflow destination buffer
which is caused by
| strncat(gOutputFile, ".", sizeof(gOutputFile));
| strncat(gOutputFile, gOutType, sizeof(gOutputFile));
This code does not work as expected (the 'len' in 'strncpy(dst,src,len)'
applies to 'src', not to 'dst' so that up to 'strlen(dst) + len' bytes can
be copied). You want strlcat() but this is not commonly available. See
example 1b + 1c in http://www.gratisoft.us/todd/papers/strlcpy.html for
details.
What version of the product are you using? On what operating system?
r103
Original issue reported on code.google.com by [email protected]
on 30 Nov 2009 at 10:50
Severity: low
What steps will reproduce the problem?
Have mscgen process a file using "\r\n" (Windows/network) newlines and pipe
it to a program that displays "\r" entries (e.g. less or hexdump). A good
sample file is testinput09.msc from the tests folder.
Using "fromdos" can remove this problem from an input file and todos can be
used to (re-)introduce it.
NB: This is not limited to "\r" only. Any symbol not accounted for in the
flex will also be "echo"'ed. e.g. a file containing ".." (and not "...")
will also print the ".." to stdout. While the parser will notice this as an
invalid symbol and fail, the ".." will still be printed (after the error
message) causing the prompt to be "indented".
What is the expected output? What do you see instead?
Expected: "nothing what so ever".
Seen: a lot of "\r" ("less" displays it as "^M", "hexdump" shows the byte
code "0d").
What version of the product are you using? On what operating system?
mscgen from trunk revision 32.
Please provide any additional information below, including sample input
file:
testinput09.msc
I believe the newline part can be fixed by changing the lex rule:
\n lex_linenum++;
into this:
[\r\n]|[\r][\n] lex_linenum++;
To avoid echo'ing of "other symbols" I suggest a "catch all" rule for them.
flex's "-s" switch may be useful in the "endeavor" since it disables the
"default rule" and aborts on unmatched symbols.
~Niels
Original issue reported on code.google.com by [email protected]
on 3 Jul 2009 at 11:34
What steps will reproduce the problem?
Write a label with non-ASCII (UTF-8 encoded) characters in it
What is the expected output? What do you see instead?
The label correctly rendered is expected, weird characters are redered
instead, where non-ASCII characters are.
What version of the product are you using? On what operating system?
0.14, Linux
Please provide any additional information below, including sample input
file:
Input (and output) test is attached.
Original issue reported on code.google.com by [email protected]
on 15 May 2009 at 6:40
Attachments:
SVG output does not honour xml escapes. Please find the attached patch that
includes a testinput to demonstrate the issue and code to fix it.
Regards, Jens
Original issue reported on code.google.com by [email protected]
on 20 Apr 2009 at 9:24
Attachments:
What steps will reproduce the problem?
1.open cygwin
2.run ./autogen.sh
3.run ./configure CFLAGS=-mno-cygwin as described in the README
What is the expected output? What do you see instead?
configure fails:
./configure: line 4318: syntax error near unexpected token `GDLIB,'
./configure: line 4318: ` PKG_CHECK_MODULES(GDLIB, gdlib)'
What version of the product are you using? On what operating system?
Windows Vista Enterprise 32 bit, SP 2
Cygwin DLL 1.7.6-1
Please provide any additional information below, including sample input
file:
All required packages are installed as described in README.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 6:44
When using "\n" in labels, sometimes the results are not the best.
For example this file:
msc {
a, b;
--- [ label = "a\nb" ];
}
It's rendered with 2 horizontal dotted lines instead of one, that would be
what one expect. Other arrows (like ->) with multiple lines are rendered
fine (one line only) but the text hides the line.
Original issue reported on code.google.com by [email protected]
on 16 Oct 2009 at 7:11
What steps will reproduce the problem?
"make test"
The script files in src/test do not have their executable bit set causing
"permission denied".
When fixing that and rerunning make test, it now fails with:
(cd test && ./parsercheck.sh)
testinput0.msc
./parsercheck.sh: line 5: ../parser/parsertest: No such file or directory
make: *** [test] Error 127
Running make test in src/parser and then make test in src/ fixes this
problem. I assume the make rule is missing a dependency.
Original issue reported on code.google.com by [email protected]
on 25 May 2009 at 12:50
Hi. I'm working with your Mscgen and found an issue, maybe it isn't an issue.
I have two times and an transmission_time. So my idea was, to put the
transmission_time into a box, but a box with white lines, because they are
invisible.
What is the expected output? What do you see instead?
The expected output is a line, with a Sent_time and an operation_type. The
transmission_time should be in an invisible box. But the Diagram shows me
the box, it doesn't include the color. See below for a screen.
What version of the product are you using? On what operating system?
Version 0.17 on Ubuntu 9.04 (jaunty)
Please provide any additional information below, including sample input
file:
And here the code, what should be:
msc {
hscale = "3";
aranea_api,aranea_core;
aranea_api => aranea_core [label = "SENT: 2009/10/06 17:06:38.816
tigr.user::login"];
|||;
aranea_core rbox aranea_core [label="Transmission_Time: 1ms ",
linecolour="white"],
aranea_core => aranea_api [label = " tigr.user::login_reply SENT:
2009/10/06 17:06:38.908"];
|||;
aranea_core rbox aranea_core [label="Transmission_Time: 1ms ",
linecolour="white"],
aranea_core => aranea_api [label = " tigr.user::login_reply SENT:
2009/10/06 17:06:38.908"];
|||;
aranea_core rbox aranea_core [label="Transmission_Time: 1ms ",
linecolour="white"],
aranea_core => aranea_api [label = " tigr.user::login_reply SENT:
2009/10/06 17:06:38.908"];
|||;
aranea_core rbox aranea_core [label="Transmission_Time: 1ms ",
linecolor="white", textcolor="red", arclinecolor="red"],
aranea_core => aranea_api [label = " tigr.user::login_reply SENT:
2009/10/06 17:06:38.908"];
|||;
}
Original issue reported on code.google.com by [email protected]
on 11 Dec 2009 at 9:44
Attachments:
Hi
I noticed some issues with the "font determination" code (in src/main.c)
First, it only displays the "Not compiled with USE_FREETYPE" when it is
actually compiled with said macro.
Secondly, fonts from MSCGEN_FONT is always overwritten due to:
if(envFont && !"room enough in buffer")
{
fail();
}
else
{
"use default font"
}
construct.
I have attached a patch against r103 to fix this.
~Niels
Original issue reported on code.google.com by [email protected]
on 12 Dec 2009 at 10:23
Attachments:
What steps will reproduce the problem?
1. Copy paste the example code 2 (second) given in the msc web page.
2. run the same to generate png
3.
What is the expected output? What do you see instead?
As mentioned in the example all three boxes should appear on the same line.
What version of the product are you using? On what operating system?
Mscgen version 0.14
Please provide any additional information below, including sample input
file:
Original issue reported on code.google.com by [email protected]
on 2 Jul 2009 at 12:17
Suggestion:
Have box around optional sequences. With dotted lines it is possible to
separate optional sequences but it is not easy to see where one optional part
starts and ends. See examples.
example.png shows optional sequences "" and "b" closed between dotted lines
example_mod.png shows optional sequences closed with dotted line boxes
Original issue reported on code.google.com by [email protected]
on 31 Aug 2010 at 7:54
Attachments:
What steps will reproduce the problem?
1. create an msc file with linecolour specified for an arc
2. generate the png or svg
What is the expected output? What do you see instead?
expected = coloured arcs.
instead = non-coloured arcs.
It seems to only enable colouring on arcs if a textcolour is also
specified. Here's a sample that illustrates this. I would expect both lines
to be coloured, but only the first one is.
msc
{
a,b;
a->b [ label="hello" , textcolour="#ff0000", linecolour="#ff0000"];
b=>a [ label="hello" , linecolour="#ff0000"];
}
What version of the product are you using? On what operating system?
Mscgen version 0.16 on Windows XP
Please provide any additional information below, including sample input
file:
sample inputs and outputs are attached.
Original issue reported on code.google.com by [email protected]
on 7 Aug 2009 at 11:27
Attachments:
Another patch to reduce the maintenance in examples/Makefile.am:
Index: examples/Makefile.am
===========================================================
========
--- examples/Makefile.am (revision 91)
+++ examples/Makefile.am (working copy)
@@ -20,8 +20,4 @@
CLEANFILES = $(BUILT_SOURCES)
-EXTRA_DIST = msg_types.mscin \
- boxes_example.mscin \
- colour_sample.mscin \
- simple_prog_desc.mscin
-
+EXTRA_DIST = $(patsubst %.msc,%.mscin,$(BUILT_SOURCES))
Original issue reported on code.google.com by [email protected]
on 24 Aug 2009 at 8:29
Disagreement - the website states (under "Description of Mscgen Language" -
first table):
"Lines starting with # or // are ignored, as a C-style comments wrapped in
/* and */"
However mscgen (0.16) chokes on "/*".
Out of date (under "Description of Mscgen Language" - first table):
It mentions width and what it does, but the sample does not use width but
hscale.
~Niels
Original issue reported on code.google.com by [email protected]
on 14 Jul 2009 at 8:22
What steps will reproduce the problem?
msc {
one,two,three;
one rbox one [label = "this is the first entity" ];
two rbox two [label = "this is the second entity" ];
three rbox three [label = "this is the third entity" ];
}
What is the expected output? What do you see instead?
I would like to have an option to cause the boxes to all align
horizontally. Perhaps an inverse of the ||| command? For example:
msc {
one,two,three;
one rbox one [label = "this is the first entity" ];
---;
two rbox two [label = "this is the second entity" ];
---;
three rbox three [label = "this is the third entity" ];
}
What version of the product are you using? On what operating system?
0.14, winxp sp3
Original issue reported on code.google.com by [email protected]
on 22 Apr 2009 at 9:15
Attachments:
What steps will reproduce the problem?
1. generate any msc file as SVG using the -T svg switch
2. embed the object in a html page
3. try to scale it using html
What is the expected output?
svg can be scaled arbitrarily in HTML
What do you see instead?
svg cannot be scaled properly
What version of the product are you using? On what operating system?
0.17, Windows XP
Please provide any additional information below, including sample input
file:
There are 2 problems actually.
The first is the one in the title that the mixed case "viewBox" attribute is
incorrectly generated as lowercase "viewbox". This causes rendering problems in
both firefox and chrome browsers.
The second is that in addition to the viewBox, the svg also has a fixed width
and height. these should be removed or made 100%. This causes problems in
chrome browser.
Actually that second one you might want to make optional because if you open
the SVG standalone in firefox (not in a html page), then having the fixed width
and height attributes is arguably better.
I've attached a test.html file and associated svgs, so you can see what I mean
if you use those browsers to view the html file and the svg files.
Original issue reported on code.google.com by [email protected]
on 30 Jul 2010 at 9:42
Attachments:
What steps will reproduce the problem?
1. Input more than 1308 Arcs in MSC file
2. Open cmd prompt and run "mscgen.exe -T png test.msc"
3.
What is the expected output? What do you see instead?
Expected mscgen to return to command prompt and png file to be created
Observe that mscgen doesnt return back to cmd prompt.
What version of the product are you using? On what operating system?
0.17 W32
Please provide any additional information below, including sample input
file:
LIBGD calls to draw Lines etc take int instead of unsigned int as input.
So if the y value is exceeding 32767, calls into LIBGD dont return.
Original issue reported on code.google.com by [email protected]
on 19 Oct 2009 at 1:26
Attachments:
What steps will reproduce the problem?
msc {
one,two,three;
|||;
one rbox one [label = "this is the\n first entity" ];
|||;
|||;
}
What is the expected output? What do you see instead?
I expect the box to resize vertically to accommodate the multi-line text.
It works for 3 or more lines, but not for two. The second text line is
crossed by the bottom line of the box.
What version of the product are you using? On what operating system?
0.17, Windows XP SP2
Please provide any additional information below, including sample input
file:
Original issue reported on code.google.com by [email protected]
on 2 Nov 2009 at 8:55
Attachments:
The tests assumed that the installed version of mscgen (in /usr/bin/mscgen)
is 0.17 (or compatible) - This leads to two separate failures.
First off, 0.16 does not support the #! approach.
Secondly, test 8 has been modified to catch regressions on the C-style
comments that 0.16 does not support.
Also requiring "backwards compatibility" on a binary output level might
come back to hunt mscgen later. You may want to make the binary comparison
a "maintainer" test (e.g. checking for a env-variable or so before
reporting a failure for a binary mismatch).
I have included a patch that
A) tests mscgen from path (in case mscgen was not installed in
/usr/bin/mscgen)
B) Works around mscgen 0.16's lack of features (and hopefully also earlier
versions) - This includes explicitly skipping "comparison" on test 8.
and can be applied with
patch -d test -p1 < $PATCH_FILE
This introduces grep, cut, cat and sed as requirements (but can be
rewritten to work without sed) - type, echo and test are (as I recall)
shell built-ins.
~Niels
Original issue reported on code.google.com by [email protected]
on 18 Jul 2009 at 8:01
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.