Ptolemy 0.7.1 Release Notes

Below are some common problems that you might run across with 0.7.1.
  • 0.7 and 0.7.1 Compatbility
  • EGCS and GCC-2.8
  • Pxgraph
  • Vem
  • Known problems in 0.7.1
  • 0.7 and 0.7.1 Compatibility

  • A Ptolemy 0.7 vem will not work with a Ptolemy 0.7.1 pigiRpc. The reason is because of a fix to a long standing vem bug.
  • In theory, the Itcl2.2 binaries from Ptolemy 0.7 should work with Ptolemy 0.7.1. However, if you are upgrading the compiler, you should probably recompile Itcl.
  • The SDF Loop Scheduler library has been renamed from libLS to libls. The reason is that case sensitivity issues with Samba were causing problems with the NT port.
  • It is best if you have $PTOLEMY/bin in your path before $PTOLEMY/bin.$PTARCH. pxgraph and itkwish are scripts located in $PTOLEMY/bin that try to set your environment properly before calling executables in $PTOLEMY/bin.$PTARCH.
  • In general, .o files built under Ptolemy 0.7 will need to be recompiled for use with Ptolemy 0.7.1
  • EGCS and GCC-2.8

    Ptolemy 0.7.1 should compile with gcc-, but the default compiler we build the binaries with is egcs-1.0.2. egcs is a new compiler effort that builds on the gcc compiler. The egcs sources are made available to the gcc maintainers, so egcs changes eventually should be in egcs. It seems like egcs is much more active than gcc, and that egcs-1.0.2 is more stable than gcc-2.8.2. Under gcc-2.8.2, compiling with -O -fPIC causes an internal compiler error when compiling, so we are shipping with egcs.

    For more information about egcs, see

    EGCS has a few mailing lists, egcs-bugs is archived at:

    The most common problem with using egcs is that libg++ is no longer used, so certain include files, such as std.h are not found at compile time and certain symbols, such as ACG::ACG(unsigned int, int) are missing at link time.

    Usually, doing a make clean; make install will solve the problem.

    The way we work around this is by defining -DPT_EGCS in and then including that makefile in the config-$ file instead of

    Note that egcs does not need libg++, so the SYSLIBS makefile variable is set to not include -lg++

    To build under egcs and under Microsoft Visual C++, it was necessary to modify many files. In Ptolemy 0.7, The g++ -fno-for-scope command line argument was necessary. In Ptolemy 0.7.1, this argument is no longer necessary, even under gcc-2.7.2.


    Pxgraph has been converted to Java. See the troubleshooting guide at. $PTOLEMY/tycho/java/ptplot/doc/internals/troubleshooting.html If you don't have Java, see for pxgraph X11 binaries and sources. See $PTOLEMY/src/pxgraph/README.txt for details

    To run the Java version of pxgraph, you must do one of the following:

    1. Set the JAVAHOME environment variable to point to the directory where the Java Development Kit is installed. For example, your .cshrc might contain
      setenv JAVAHOME /opt/jdk1.1.5
    2. If you do not set JAVAHOME, then the pxgraph script will search your path for the javac binary. If javac is found, then the directory above it is used for the value of JAVAHOME
    3. You can also edit $PTOLEMY/bin/pxgraph directly and adjust the JAVADEFAULT variable.


    The vem binary shipped with Ptolemy 0.7 will not work with Ptolemy 0.7.1. The reason is that Tom Lane fixed a long standing vem bug that occured when pigiRpc and vem try to send each other commands at the same time. For example, the bug appears when the user does a 'edit paramters' or 'look inside' in a vem window while pigiRpc is compiling a facet.

    If you do not upgrade vem to the version shipped with 0.7.1, then the error message you will see is:

        vem> illegal VEM function number (4)
            RPC Error: server: bad VEM request
    The number '4' in the error message is a dead giveaway, the patch says rcpInternal.h had the following #define added:
    #define VEM_LOCKING_FUNCTION                    (long) 4
    If you get this error message, get the other.src tar file and octtools.

    Known problems in 0.7.1

    Missing features

  • PTARCH== has not been tested
  • dsp/stars/SDFNdftVarD does not have an example universe
  • General Problems

  • matlab interface does not work well with statically linked binaries, such as nt4, alpha4 or linux.static
  • parameter expressions that use tcl do not work in statically linked binaries.
  • The Almagest has not been updated, so the installation instructions in $PTOLEMY/doc/html/install are out of date.
  • ch4_a56_sVHDL_dSDF demo in vhdl/demo/cgc_s56x_vhdl/init.pal crashes pigi
  • CG56

  • Bad master:
    Examining $PTOLEMY/src/domains/cg56/demo/cgcs56x/test/modem/matchedFilter/topMatch:schematic:contents 
    	Bad master: 
    	Invalid facet(OCT): $PTOLEMY/src/domains/cg56/demo/cgcs56x/test/modem/matchedFilter/dspMatchedFilter:schematic:interface 
    	(cellPath /users/ptolemy/src/domains/cg56/demo/cgcs56x/test/modem/matchedFilter/dspMatchedFilter) 
  • The following s-56x demos fail
    echo canceling
    The code compiles and runs:
    rshCommand: cd /users/cxh/PTOLEMY_SYSTEMS/CG56;./echocanceling &
    The qdm window comes up and then disappears. The message is
    boot:  qckHostIntr: ioctl DspHost
    pIntr: Invalid argument\n
    The only one the worked was cdVolume
  • CG56 BPSK modem fails with:
    vem> Debug: CompileUniv: facet = bpskTop, CGC universe
    Error: TclTk_Target.Send_Link_2:  not supported
    CG56 QPSK fails with a similar message.
  • CG56 dtmfSpectrum starts up, but pressing the buttons does not change the plots. The CG56 Synth demo has the same problem. I think I need to cable the external box up properly
  • SDF/CG56X Wormhole demo fails with
    Error: wormHoleIO.S56XIO1.oDown: not enough output tokens at SDF
    wormhole boundary
    points(1) Error: wormHoleIO.S56XIO1.oGain: not enough output
    tokens at SDF wormhole boundary
    Error: wormHoleIO.FixToFloat1.input: Attempt to read from empty
    geodesic in PortHole::getParticle()
  • The following bug was reported concerning KDE and Ptolemy classic
    From: (Peter Gunreben)
    Subject: Ptolemy-Classic with KDE hangs at error messages
    Newsgroups: comp.soft-sys.ptolemy
    Date: 8 Aug 2002 09:16:56 -0700

    When using Ptolemy-Classic with KDE, the computer will hang for about 30 seconds if an error message occurs.

    The reason for this behavior is based in the procedure ::tycho::Dialog::wait.

    To overcome this problem you may comment out the following section in $PTOLEMY/tycho/kernel/gui/Dialog.itcl

    # if $autoraise {
        # If the user mouses in another window, raise
        # bind $instance <Button> "+raise $instance"
        # If the user moves the mouse in another window, raise
        # bind $instance <Motion> "+raise $instance"
    # }
  • (12/03) The following problem was reported by Shachindra Sharma in src/octtools/Packages/st/st.c where a particular string results in a negative hash code because of overflow.
    Ptolemy Classic does not call this function, but st.c appears in other locations, such as
    The fix is below:
    int st_strhash(string, modulus)
         register char *string;
         int modulus;
      register long val = 0;
      register int c;
      while ((c = *string++) != '\0') {
        val = val*997 + c;
      /* Shachindra Sharma writes:
           ".. will have a problem when the value variable "val" is equal
           to the maximum negative integer value (for the particular OS its being
           run on say if its 32 bit OS the value would be -2^31 = -2147483648)
           val < 0 ? -val : val will still be -val for such a case due to the
           property of maximum negative integer that -val == val.
           As an example if we have a input string to this function like
           the one given below:
           the value of the variable "val" would be -2147483648 resulting
           in a negative value being returned by the function which could result
           in problems for the user is OS was 32 bit. The hash function otherwise
           for any values of "val" larger or smaller than this value would work
           fine so the probabilty of such a situation is rather low.
      if (val == -val) {
        unsigned int newhash = -val;
        return (newhash%modulus);
      } else {
        return ((val < 0) ? -val : val)%modulus;
  • Tycho

  • For Tycho bugs, see $PTOLEMY/tycho/doc/bugs.html