Ptolemy II 6.0.2 Limitations

The Ptolemy II 6.0.2 Release notes list limitations. The Vergil welcome window has a link to a similar list.

If you find bugs, check the limitations page inside Vergil, then check this page, and then send email to ptolemy at eecs berkeley edu.

In your email, please be sure to list

  • What operating system you are operating under (Windows XP sp1? Solaris 8?)
  • What version of Java you are running. (Run java -version, or use our Java Version Applet )
  • Whether the problem occurs in
  • Vergil
  • The local version of the web pages
  • The PtolemyII 6.0.2 website version of the web pages
  • The Web Start version
  • Ptolemy II Bugzilla links

    Places to go

  • Online Applet Demonstrations and Documentation
  • Ptolemy II Design Document
  • Know Limitations

    See the Ptolemy Bugzilla page for other bugs. Note:
    Ptolemy II 6.0.2 will not compile with Java 1.6, you must use Java 1.4 or 1.5, see 07-Apr-2008 Re: Error installing Ptolemy on ubuntu.

    Windows Installer Limitations

    We switched from InstallAnywhere, which was bought by Macrovision, because we feel we are an open source project and should use open source software instead of commercial, closed source software from a copy protection vendor. We are using IzPack, which is open source and written in Java. There are a few issues:
  • We don't like the first window that pops up, it is rather blank and seems unnecessary. However, if we don't have that first window pop up, then the html pane that is rendered in the second window is sometimes the wrong size. We think this is an event thread issue, but we have not checked.
  • We ship the sources in a jar file. we wrote an extension that unjars the file. This extension gets run in the Processing panel. It could be confusing. The reason to ship the sources as a jar is because creating the install is _much_ faster when the sources are a jar file instead of 8000 individual files. We could get rid of the Processing Panel.
  • How the JRE is handled is broken. Currently, we ship with a jre, which is used if it the jre has the highest version number. Thus, if you have a JRE that is later than 1.5.0_08, then that more recent JRE will be used. This is a problem because we would like Ptolemy II to use the JRE we ship, which contains extensions like Java 3D etc. Also, we would like Ptolemy II to be runnable over many years, even if more recent versions of the JRE are present
  • Other Limitations

  • The Matlab interface is not very stable under Windows Try running the Matlab demos by compiling Ptolemy II from source and then running vergil -jni.
  • See the Ptolemy II 6.0.2 Release notes for known limitations.
  • The Applet code generator seems to have problems including ptsupport.jar
  • The Higher Order Components ModelReference demo does not work under Web Start.
  • The PSDF Blind Communication demo does not run under Web Start, the message is:
    ptolemy.kernel.util.IllegalActionException: The number of elements in the
    input ArrayToken (2047) is not the same as the arrayLength parameter (2048).
  • If an icon file is not present, then a Vergil applet might try to download the icon file multiple times. Ptolemy II uses XML files to store icons. For example $PTII/ptolemy/actor/lib/BooleanSwitchIcon.xml is an icon for $PTII/ptolemy/actor/lib/
    The problem is that if an actor does not have an icon file, then the applet may go back to the server multiple times looking for the icon.
  • Plot windows don't resize when control panel is resized
    If a model with plotters is executed using the run button on the toolbar, and then re-executed using the run control panel accessed through the View menu, then resizing the run control panel does not cause the plots to resize to fit.
    Workaround: Close the model and re-open it, and then run first using the run control panel.
  • Printing a model that contains transparent objects can result in problems when printing to Encapsulated Postscript (EPS).
    If a model has transparent objects, then when it is printed to EPS, the resulting file is a bitmap instead of a Postscript description of the graphics. You can tell by the file size (several Meg vs. several K) and by opening it in Illustrator, where in theory you should be able to ungroup and select and edit individual components.
    The way Java prints EPS is that there is an implementation of Graphics2D that literally translates each graphics2D call into a Postscript snippet. If Java detects any transparent colors or images, then the literal translation of each element independently doesn't work, so the printing code reverts to writing everything to an image and then sending the image, encapsulated in Postscript to the printer.
    Solution 1: Use one of these pdf writing programs to generate pdf-1.4 compliant pdf files, which have extensions to support transparency that Postscript lacks, and then print them to eps, which would use the distill implementation of the above algorithm. Or alternatively, we could switch to using pdftex instead of latex->dvips->distill which should embed pdf for figures directly at the expense of less robust latex support.
    Solution 2: Use the undocumented flag -Dsun.java2d.print.pipeline=pdl on the command line to force the printing to use the postscript path, ignoring transparency. Under Cygwin:
    export JAVAFLAGS=-Dsun.java2d.print.pipeline=pdl
    Then edit the file by hand in Illustrator to add the transparency back in.
  • 1/8/07: The Datagram actors do not work very well. The tests sometimes fail. See
  • 1/8/07: GNU Make 3.81 no longer supports Windows style path names with colons in them. The affects the Copernicus code generator because $PTII needs to be set to a pathname with a colon in it like c:/Ptolemy/ptII6.0.2. A path name like /cygdrive/c/Ptolemy/ptII6.0.2 will not work with Java.

    For example, if you run copernicus and copernicus runs make, you may see

    makefile:360: *** target pattern contains no `%'.  Stop.
    This is because a makefile variable uses the windows style pathnames with colons in them. One solution is to edit the file to use pathnames with /cygdrive. Another solution is to download a working version from

    For details, see

  • From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
  • To: cygwin-announce at cygwin dot com
  • Date: Sun, 9 Jul 2006 18:13:29 -0400

    I've made a new version of 'make' available for download. This updates the package to the latest version available from I've included the relevant portions of the NEWS file and the Fedora ChangeLog at the end of this message.

    For a brief description of this package, see

    Note that the --win32 command line option and "MAKE_MODE" environment variable are no longer supported in Cygwin's make. If you need to use a Makefile which contains MS-DOS path names, then please use a MinGW version of make.

    See: for details on downloading a version of make which understands MS-DOS path names. Please! direct any questions about the MinGW version of make to the appropriate MinGW mailing list.

  • I have no idea what prompted this change, it seems really lame. The code worked fine under Cygwin for many years. It seems like breaking an important tool such as make only hurts the GNU tools.

    For further updates, see

    4/26/07: Wile compiling in $PTII/jni/test, I was getting

    Process_begin: CreateProcess((null), /usr/bin/gcc -shared
    -Wl,--add-stdcall-alias -o testDeux.dll testDeux.c, ...) failed.
    The problem was I was running a broken version of make and updating to helped.
  • 2/8/07: In HyVisual, the HSIF translater is merely a prototype, it is not a full implementation of a HSIF translator.
  • 2/8/07: If a parameter name end with an underscore and a number, then cutting and pasting drops the underscore and number.
  • 2/8/07:On the Mac the Tcl test suite does not actually test anything. ptjacl starts up, but the files are not read?
  • The Applet code generator seems to have problems including ptsupport.jar