attach 

attach 10622

To find out more about the gdb mode, try

M-x info
Then type:
m emacs

Running Debuggers Under Emacs

* Starting GUD::	How to start a debugger subprocess.
* Debugger Operation::	Connection between the \
                        debugger and source buffers.
* Commands of GUD::	Key bindings for common commands.
* GUD Customization::	Defining your own commands for GUD.

`C-c C-l'
`C-x C-a C-l'
   Display in another window the last line referred to in
   the GUD buffer (that is, the line indicated in the last
   location message).  This runs the command `gud-refresh'.

Tom points out:

I modified the "pigiRpcDebug" script so that if you define an environment variable PT_DEBUG, then that program will be used instead of just running gdb inside an xterm. I also installed a script "ptgdb" in ~ptdesign/bin that will run gdb inside emacs. So if you "setenv PT_DEBUG ptgdb" then you'll be all set.

I'm still looking at mxgdb and xxgdb, but they seem to be a bit too buggy to be useful. William Li mentioned that there is a Tk interface to gdb, but I haven't had time to look for it.

*Warning:* GDB runs your program using the shell indicated by your `SHELL' environment variable if it exists (or `/bin/sh' if not). If your `SHELL' variable names a shell that runs an initialization file--such as `.cshrc' for C-shell, or `.bashrc' for BASH--any variables you set in that file affect your program. You may wish to move setting of environment variables to files that are only run when you sign on, such as `.login' or `.profile'.

gdb and StringLists

The function printStringList looks like:

Debugging hints

The first thing we tried was recompiling the kernel with out optimization: cd $PTOLEMY/obj.$PTARCH/kernel; make clean; make OPTIMIZER= install The problem persisted.

The code looked like:

If we set a break point at line 102, then gdb would actually stop at line 101. I think the problem might have to do with having the bracket at the end of the line, rather than on a separate line. If we change:

The next weird problem was that the execution of the program seemed to jump around in a non-sequential fashion, even if the program was compiled with the optimizer off. What was happening was that we would hit

The problem here is that we are declaring an int part way through the block, and I think g++ is reordering things to that the int is actually declared at the top of the block. Personally, I prefer to see variables declared at the top of a block, rather than in the middle. Changing the code to

1. Verify that your $PTOLEMY is set to what you thing it is set to If you are building binaries in your private tree, be sure that $PTOLEMY is set to your private tree and not ~ptdesign.
2. Verify that your $LD_LIBRARY_PATH does not include libraries in another ptolemy tree. You could do unsetenv $LD_LIBRARY_PATH
3. gdb sources your .cshrc, so your $PTOLEMY and $LD_LIBRARY_PATH could be different. Inside gdb, use show env PTOLEMY to see what it is set to. This problem is especially common if you are running gdb inside emacs via ptgdb.
4. Verify that you are running the right binary by looking at the creation times. You may find it useful to use the -rpc option: pigi -debug -rpc $PTOLEMY/obj.$PTARCH/pigiRpc/pigiRpc.mine ~ptdesign/init.pal
5. Recompile the problem files with optimization turned off and relink your pigiRpc. You can do this with rm myfile.o; make OPTIMIZER= install Then rebuild your pigiRpc
6. Look for wierd coding styles, such as declaring variables in the middle of a block and brackets that open a function body on the same line as the function declaration: int foo(int bar){ vs int foo(int bar) {
7. Use stepi to step by instructions, rather than step.

If you are spending a lot of time debugging a problem, you may want to use ptcl instead of pigiRpc, as ptcl is smaller and starts up faster. Also, you can keep your breakpoints between invocations of ptcl, as debugging ptcl does not start up a separate emacs each time. However, ptcl cannot handle demos that use tk or hof. Here's how to use ptcl to debug.

1. Run pigiRpc on the universe, and use compile-facet to generate a ~/pigiLog.pt file. Note the number of iterations for the universe, and then exit pigiRpc
2. Copy ~/pigiLog.ptto somewhere. I suggest something like /tmp/tst.tcl. Use a short filename here since you may be typing it alot, and don't use something inside your home directory as you can't easily use ~ inside ptcl. If the file is named ~cxh/t.tcl, then I would have to type /users/cxh/t.tcl, which is a lot longer than /tmp/t.tcl
3. Edit the file and add a run XXX line and a wrapup line at the end. If the demo should run for 100 iterations, then add: run 100 wrapup to the end of the file.
4. Build a ptcl debug that has just exactly the functionality you need If your demo is sdf, then try building and using ptcl.ptiny.debug.
5. If you use emacs, then you can start up gdb on your binary with: M-x gdb Then type in the name of the binary. You may have to use the full pathname: /users/cxh/pt/obj.sol2/ptcl/ptcl.ptiny.debug You can then set breakpoints in the gdb window, then type r to start the process, and then source your demo with: source /tmp/tst.tcl If you want to recompile your demo outside of gdb and then reload it into your gdb session, use the file command inside gdb file /users/cxh/pt/obj.sol2/ptcl/ptcl.ptiny.debug Your breakpoints will be saved, which is a big time saver.

Compiling under emacs

• Add the following directories to your load-path

  /usr/sww/lib/emacs-18/lisp/elib
  /users/parks/lib/elisp
  

• If you want to have "make .o" be the default compile-command then you could add the following commands to your c-mode-hook or c++-mode-hook.

  (require 'pt-compile)
  (setq compile-command (pt-default-compile-command))
  

Class browsing under emacs

(load "pt-browse")

The TAGS file is built with a special version of the etags program, installed as etags++ on sww. It does not like some of the files in ptdesign. I think that is is possible to concatenate small TAGS files to create larger ones, so it may not be too hard to add a TAGS target to the makefiles in ptolemy.

For more documentation, view the file /usr/sww/share/lib/info/c++-browse with info or tkinfo.

See also tycho class browser docs.

Compiler Hints

1. Problems with the compiler itself
2. Problems compiling files

Problems with the compiler itself

2#include 
main()
{
  cout << "Hello, Ptolemy.\n";
}

gcc -v -H hello.cc

You can use the -save-temps gcc option to save any temporary files created in each step. Then, if necessary, you can try running each step by hand.

as vs gas

Collect

You can pass the collector arguments so that it will print out more information. Try

g++ -v -Wl,-debug hello.cc

make LINKER="g++ -v -Wl,-debug" PURELINK=

collect creates a temporary file that has the constructors and destructors in it. To get collect to save the temporary file, set the following environment variable:

setenv COLLECT_GCC_OPTIONS -save-temps		

If the collector is getting an old version of GNU nm, then you could have problems

Environment variables

setenv GCC_EXEC_PREFIX $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH/2.5.8/
setenv C_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH
setenv CPLUS_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/g++-include:$PTOLEMY/gnu/$PTARCH/$PTARCH/include
setenv LIBRARY_PATH $PTOLEMY/gnu/$PTARCH/lib

If, under gcc-2.5.8, you get warnings about 'conflict with built in declaration', and your compiler is not installed where it was built, you may need to create a link in your gcc-lib. If you compile the file with the -v option, you can see what directories it is including. You could try creating a link:

(cd $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH/2.5.8; ln -s .. $PTARCH)

Using Trace

gcc -v -save-temps

Problems Compiling files

The gcc -E and -P options are very useful in wading through include file problems. -E stops compilation after the C preprocessor runs, and outputs the resulting file. -P strips off the line numbers from the output.

1. Try using the -E option, and look at the output file. Sometimes the problem will be obvious. Note that if your -E compile args include -o filename.o, then filename.o will have cpp text output, not the usual object file. If you are within Ptolemy, you can try using the OPTIMIZER makefile flag to pass args to the compile. For instance:

   cxh@dewitt 18% make OPTIMIZER=-E Linker.o > Linker.e
   cxh@dewitt 19% ls -l Linker.e
   -rw-r--r--  1 cxh         68392 Jun 15 09:06 Linker.e
   cxh@dewitt 20% 
   

2. Use -E -P, save the output to a new file called tst.cc and compile that file.

    make OPTIMIZER="-E -P" Linker.o > tst.cc
   

   Edit tst.cc and remove the first line, which will have the gcc command in it. Make tst.o

   make OPTIMIZER="-v -H" tst.o
   

   If you are getting weird substitutions this will help.
3. Using '-E -dM' will tell you what symbols are defined by cpp at the end of the compile. See the gcc man page or the gcc info format file for more information.

Sources of information for compiler problems

~ptolemy/gnu/common/man/man1/gcc.1

The gcc man page Use emacs (M-x info) or tkinfo to view the info pages.

~ptolemy/gnu/common/info/gcc*

The gcc info pages.

/users/ptdesign/src/gnu/g++-FAQ.txt

Joe Buck's g++ info page, (Available via anonymous ftp from rtfm.mit.edu in pub/usenet/news.answers )

/usr/sww/doc/faq/c.faq
/usr/sww/doc/faq/c++.faq	
/usr/sww/doc/faq/hpux.faq
/usr/sww/doc/faq/Sun/solaris2.faq	
/usr/sww/doc/faq/Sun/solaris2_porting.faq	
/usr/sww/doc/faq/Sun/sun_sysadmin.faq	

Undefined symbols

For example, if there was an undefined symbol, called __MyMissingSymbol, during the pigiRpc link.

1. Run nm -o on the library directory:

   nm -o $PTOLEMY/lib.$PTARCH/* | grep __MyMissingSymbol
   

   If you find the missing symbol, then go to that library and try reinstalling it. That will often solve the problem.
2. If step above did not work, then you need to run 'nm -o' on all the object files used to create the binary.

   Copy the link command into a separate tmp file, edit the tmp file so that only the .o files remain, and add 'nm -o' to the beginning

   If the link command is

   g++ -L../../lib.sol2 -Xlinker -S -Xlinker -x -static pigiMain.o \
   defpalettes.o ../ptcl/PTcl.o ../../lib.sol2/sdfstars.o \
   ../domains/cgc/targets/main/CGCBDFTarget.o -L../../octtools/lib.sol2 \
   -lsdfimagestars -lImage -lsdfdspstars -lsdfstars -lLS -lsdf \
   -lsdfmatrixstars -lsdftclstars -lrpc -lpigi -lptk -lgantt -lptolemy -loh \
   -lrpc -llist -ltr -lutility -lst -lerrtrap -luprintf -lport \
   -L../../tcltk/tk.sol2/lib -ltk -lXpm -L../../tcltk/tcl.sol2/lib -ltcl \
   -L/usr/X11/lib -lX11 -lg++ -lm version.o 
   

   then edit this down to:

   nm -o \
   pigiMain.o defpalettes.o ../ptcl/PTcl.o ../../lib.sol2/sdfstars.o \
   ../domains/cgc/targets/main/CGCBDFTarget.o version.o
   

   If you have problems with line length and vi, then either use Emacs, or use backslashes to break up the line into multiple lines.

   One could write a makefile that automates this.

3. Run your tmp file:

   sh ~/nmit | grep __MyMissingSymbol
   

   Look for files that contain the undefined reference.

You may find it useful to see what steps the linker is taking. For instance, the linker might be accessing different library files than what you think. A common error is to be accessing the libg++.a file from an old version of libg++.

c++filt

Note that the name mangling scheme differs for different compilers. So you need to use a different c++filt for Cfront and GNU compilers. /usr/sww/bin/c++filt should work with GNU compilers. Be sure you are using the right c++filt with the right compiler. Locally, /usr/lang/c++filt might be in your path before /usr/sww/bin/c++filt

If your symbol has special characters, you may need to place it in quotes.

ptuser@babbage 22: echo '__$_4KUIM' | /usr/sww/bin/c++filt 
KUIM::~KUIM(void)

c++filt can be found in the GNU binutils distribution.

Passing args to ld

Under Suns running SunOS4.1.3 with GNU C and C++ (ARCH=sol2):

cd $PTOLEMY/obj.sol2/ptcl
make LINKER="g++ -v -Wl,-debug -Wl,-t" PURELINK=

cd $PTOLEMY/obj.cfront/ptcl
make ARCH=cfront LINKER="CC -qoption ld -t -v -V"

Testing

On tereza, you will have to do your testing in the ~ptolemy directory and hope for the best, as tereza is not mounting /scratch.

If you have an aniljain account, then you should work from it. On both aniljain and tereza, if you don't have your own account, you should work as ptuser, not as ptolemy. For best results, try setting the path:

set path = ($PTOLEMY/bin /usr/bin /usr/ucb /bin .)

Things to test

1. Run all the demos and be sure that they work. The run-all-demos command will fail in the following palettes:

   sdf/multirate:                  barfs on 'broken'
   sdf/signalProcessingSystems:    barfs on 'animatedLMS'
   sdf/matrix:                     barfs on MatrixTest1 (crashes pigiRpc)
   cgc/multirate:                  barfs on filterBank
   

2. Make a Purify'd version of pigiRpc and repeat 1. Eliminate any serious errors found (for example, you may have accesses to freed memory but still the demos would run OK just by luck).
3. Core dump contest. The goal in the core dump contest is to make pigi or ptcl dump core (no user-written incrementally linked stars allowed). To score, you need to report the bug in a way so that it's repeatable (e.g. a pigiLog.pt that causes a crash, or a facet on ohm somewhere that makes pigi blow up). No points if your crash is judged to be identical to someone else's previously reported crash (same basic cause, that is). The person with the most core dumps wins. Tie breaker: a core dump that the average user is more likely to encounter could be considered to be worth more.
4. Repeat 1 and 2 after fixing core dumps from 3. For any core dumps not easily fixed, we can add warnings to the documentation.
5. Dynamic linking There is an example of dynamic linking in ~cxh/c++/pt. A simpler example would be better You may want to try out the gnu compiler for dynamic linking, here are the variables:

   setenv GCC_EXEC_PREFIX $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH/2.5.8/
   setenv C_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/gcc-lib/$PTARCH
   setenv CPLUS_INCLUDE_PATH $PTOLEMY/gnu/$PTARCH/lib/g++-include:$PTOLEMY/gnu/$PTARCH/$PTARCH/include
   setenv LIBRARY_PATH $PTOLEMY/gnu/$PTARCH/lib
   

6. Look for bogus files. Untar all the tar files somewhere and look for weird files. Usually there is a copy of the untar'd distribution in /scratch/gen/ptolemy Try

   (cd ~ptolemy; gfind . -xdev -size 0 -ls)
   

   or

   (cd ~ptolemy/src; make checkjunk)
   

Documentation

Writing an Index

Star class

star

star

stars

Star:print method

Star::print()

print method

print method:in Star class

We use specialized markers to indicate the different types of indexes. The markers are renamed in the $FMHOME/fminit/usenglish/Maker.us file. If Framemaker is updated on the Software Warehouse, then you will need to build a dummy tree locally so that we can modify this file. Usually the tree is in /opt and the FMHOME variable is set to that directory. To build the tree, as root you could do something like:

Framemaker hints

Including Ptolemy Facet Images in Frame docs

1. A anchored frame that contains all of the parts of the figure. Usually the frame is anchored at the cross reference figure number in the description. Typical text would be The palette in figure 5-9 shows a collection of stars for format conversion . . . In the example above 5-9 is the cross reference, and the anchor should be just after the cross reference. Note that you have to create the figure before creating the cross reference.
2. A text frame that contains the postscript by reference. The trick here is to type in the name of the postscript file into the text frame, and then tell Frame that this is postscript.
3. A text frame that contains the figure paragraph that describes the figure. The cross reference will refer to this paragraph

1. From within Ptolemy, use the Control-P to bring up the Ptolemy print window. Then print your facet to a file. In the final results, you probably want to have each icon about 1/2 inch on a side. If you save the facet after printing it, your offsets will be saved on disk. Note that because of a bug in pigi, upon exiting you will not be prompted to save your facet, you will need to remember to save it yourself.
2. From within Frame, create an anchored frame by mousing in the framemaker window and then selecting Special->Anchored Frame
3. Place a text frame inside your anchored frame. (Use the text frame tool from the graphics tools palette).
4. To import the postscript, type the name of the Postscript file into the text frame #include /users/ptdesign/src/domains/sdf/demo/init.pal.ps
5. Then in Format->Customize layout->Customize Text frame , select the Postscript code box
6. To check your image, you can print just one page to a Postscript file, then run fixframeps and then ghostview fixframeps sdf.ps; ghostview sdf.ps If you are using a virtual window manager, then you can have frame running in one screen, pigi running in another and ghostscript running in another. In this way, you can quickly preview images without printing.
7. If you want to crop the top of the image so that the text that describes the palette is not visible in the frame document, you can grab the top of the outer frame and resize the entire frame. This is a little tricky, but once you get the hang of it, the process is fairly quick. If necessary, you may need to reprint the facet from Ptolemy with different horizontal and vertical offsets.
8. Once you are happy with the figure itself, create another text box at the bottom of the anchored frame and type in a description. The paragraph should be of the figure format.
9. Once you have a figure format description paragraph, you can create a cross reference at the top where the anchored frame is anchored.

WWW

From: Tom Parks To: ptdesign@bennett.eecs.berkeley.edu Subject: Documenting demos for the World Wide Web

If you want to document a demo for the World Wide Web (WWW), then first have a look at the demos that are already installed. Start at the Ptolemy home page

http://ptolemy.eecs.berkeley.edu/

To create your own document, create a new directory to keep all your files in. You'll need a HTML file, a screen dump of the facet, screen dumps of plots, and and sound files that are generated. Once you have it ready, let me know where to find it, and I'll install it on the FTP site.

I have installed the script "xgif" in ~ptdesign/bin. It passes any command line arguments to xwd (I suggest you read the man page for xwd) then converts the window dump into a GIF file and writes it to stdout. If you want to make a movie, talk to me and I can give you some help.

Tom's tips:

Here are some tips I have figured out in the process of preparing scanned images for my WWW home page.

When I scan an image, I adjust the resolution (dpi) so that the image will be between 500 and 1000 pixels in the larger dimension. Keep in mind that your screen is probably 1152x900, so there isn't any point in making really huge images. I save the scanned images as 24-bit color TIFF files, then use FTP to transfer them from the Macintosh to my workstation. Then I use xv to convert the file to JPEG and save it with the default quality setting of 75. JPEG offers about 30 to 1 compression with very little loss of quality. I find that the artifacts from quantizing the color map to 8-bit color for display are much more dramatic than the losses in JPEG coding. At this point I discard the original TIFF file and the JPEG file becomes my "master" copy.

Because JPEG images cannot be included inline with HTML (but they can still be used with external viewers), it is necessary to create a GIF format version of your image. The goal for inline images is to make the file as small as possible so that it won't take too long to download over the net. I suggest that you crop your image and shrink it by a factor of 4 or more, then save it as a *reduced color* GIF. The reduced color option saves space, and it doesn't really degrade the image because Mosaic only reserves a small number of colors for inline images anyway.

The URL to access the Ptolemy front page is:

http://ptolemy.eecs.berkeley.edu

file://localhost/usr/tools/etc/httpd/docs/index.html

Patches

1. grab the old source, un tar it in a place and call it old

   mkdir old
   cd old
   gzcat pt-0.5.1.src.tar.gz | tar -xf -
   cd ..
   

2. place the new source next to it, usually I make a tar, but you might be able to use links.

   mkdir new
   Untar the new stuff
   

3. Now I have a directory with old/ and new/ and under old/ and new/ is a ptolemy/ directory:

   old/ptolemy
   new/ptolemy
   

4. Then I do a diff:

   diff -c -r old new > patch3
   

When I generate a patch, I always try running it on the original source to make sure it works. Note that the ptolemy source has some links in it which means that some files end up in the patch twice (ddf/cg and tech/ptolemy are two offenders). If a file is in the patch twice, then the second time you will be asked if you want to reverse the patch. Merely edit the patch file by hand and remove the second diff.

Any version of diff should work, the key thing is to use the -c flag, which causes the lines around the line that is different to be printed. I guess I do use GNU diff, but anything should work.

Between release, we may end up producing patches to fix bugs, or provide enhancements.

The patches should be applied in order. If a user needs patch3, then they should apply patch1 and then patch2.

~ptolemy/adm/gen-0.5/makefile contains targets to produce patches. ~ptolemy/adm/gen-0.5/mkpatch is a shell script that will produce a context style patch. See the makefile for usage.

mkpatch automatically includes changes to pigiRpc/makefile that reflect the new patch number.

Before releasing a patch, you should test it out on as many platforms as possible.

1. On a scratch disk, or somewhere where there is space, grab the tar files from the ftp site.

   zcat /vol/ptolemy/pt0/ftp/pub/ptolemy/ptolemy0.5/pt-0.5.src.tar.Z | tar -xf -
   

2. If you are making changes to octtools, you will have to grab the other.src tar file

   zcat /vol/ptolemy/pt0/ftp/pub/ptolemy/ptolemy0.5/pt-0.5.other.src.tar.Z | tar -xf -
   

3. cd to the test directory

   cd ptolemy
   

4. Apply all the patches in order:

   patch < /vol/ptolemy/pt0/ftp/pub/ptolemy/ptolemy0.5/patches/patch/pt-0.5-patch1
   patch < /vol/ptolemy/pt0/ftp/pub/ptolemy/ptolemy0.5/patches/patch/pt-0.5-patch2
   

   etc . . .
5. set your PTOLEMY variable to the current directory

   setenv PTOLEMY `pwd`
   set path = ($PTOLEMY/bin.$PTARCH $PTOLEMY $path)
   

6. If you changed octtools, build that first

   make install_octtools >& oct.0421 &
   

   If you are not rebuilding octtools and tcltk, make links:

   cd $PTOLEMY/tcltk; ln -s ~ptolemy/tcltk/* .
   cd $PTOLEMY/octtools; ln -s ~ptolemy/octtools/*
   

7. Build

   make install >& in.0421 &
   

8. Test out your fixes
9. remove your test directory when you are done.

When you build a patch, you may want to rebuild the binaries and create a tar file with the new binaries. The name of the tar file should be something like pt-0.5p1.sol2.tar.Z

If at all possible, we should never replace files in a ftp tar file without changing the name to something else.

Moving Ptolemy

If you move ~ptolemy to point to the version on sww, be sure that the .forward file in the new location is the same as the .forward file in the old location. Also check that the .plan file is the same in both locations.

Some users depend on .o files in ~ptolemy/obj.sol2, so it would be nice if that directory was present in the new tree.

To move ~ptolemy you will need root permission:

1. edit /usr/cluster/etc/amd/maps/users.map. Look for the ptolemy section
2. cd ~cxh/sa/bin/doall
3. restart the automounter on all machines:

   ./doall "amd-restart" `cat ohm`
   

4. verify that the move worked:

   ./doall "cd /users/ptolemy;pwd" `cat ohm`
   more *.out | cat
   

Porting to a new architecture

$PTOLEMY/bin/ptarch

Should return the name of your arch

$PTOLEMY/mk/config-$PTARCH.mk

Needs to be set up

src/octtools/Packages/port/port.h

Lots of architecture dependencies. Note that this file gets installed in: $PTOLEMY/octtools/include/port.h and $PTOLEMY/src/octtools/include/port.h

src/compat/ptolemy/compat.h

Used in pigilib and libgantt

src/kernel/ptsignals.cc

Used in pigilib to speed up the GUI. Contains architecture dependencies for signals and interrupts.

src/thread/makefile

Used under solaris to build GNU threads for the PN domain

src/pigilib/pigiLoader.cc

Used to dynamically link stars

src/kernel/Linker.*

Used to dynamically link stars

If you are on a non GNU compiler, try looking at the cpp man page for hints about what symbols are predefined. If necessary, you can pass the compiler a symbol from your config-$PTARCH.mk file (i.e. CCFLAGS=-DMYARCH).

For SystemV architectures, adding -DUSG -DSYSV to CCFLAGS in config-$PTARCH.mk could help.

compat.h

#ifdef arch

function prototypes

(Of course, all the compat.h stuff are merely guidelines)

include files

general procedure

Then build tcltk.

Then try to build what is necessary to build a SDF and DE only ptcl (kernel, ptcl, domains/de domains/df). The try a complete build.

Eventually, we should use the GNU autoconfig tool, which would allow us to use defines like -DHAS_FOO, instead of depending on #if defined(mynewarch).

testing

Changing gcc versions

Ptk commands

Embedded Postscript (EPS) in Frame docs

If you use EPS in a Frame doc that will be part of the Ptolemy distribution, you should add rules to the appropriate makefile that will run fixPS on your Postscript file. For example, cg56.ps and cg96.ps in the users manual need to have fixPS run on them. So, ~ptdesign/doc/users_man/makefile contains the lines:

FIXPS=/users/ptdesign/bin/fixPS
fm2ps: update_book
	fmprint2ps $(DOCS)
	$(FIXPS) cg56.ps
	$(FIXPS) cg96.ps

Contributing Stars

The Ptolemy development group is interested in any stars Ptolemy users might want to contribute to the project, but we have limited resources, so here are a few guidelines for contributions:

Distributing stars We are proposing two methods of distributing stars: via ftp and via the next Ptolemy distribution. These instructions are primarily for distribution via ftp from our ftp site.

If you stars are to be distributed from our ftp site, we will put them in a contrib directory.

If we distribute your star in the next Ptolemy release, we will probably want to add the Berkeley copyright to your stars.

We have not resolved the details of where contrib stars will go, but currently we are thinking of putting stars into contrib directories next to the stars directories. So, $PTOLEMY/src/domains/sdf/contrib/stars would contain sdf .pl files that users had contributed. Stars that we find really useful, we would like to incorporate into the main stars/ directories. The primary reason for a contrib directory is that we don't have the resources to fold in all stars into the main tree.

Packaging contrib stars to be included into the next Ptolemy release is more work for everyone involved, but the stars are more likely to be used. Due to time constraints, we might not be able to get contrib stars into the 'next' Ptolemy release, but we will try.

Copyright If your stars are to be included in the Ptolemy distribution then we would like to put It makes our lives a lot easier if you put the UC Berkeley copyright on the .pl files. See any .pl file for the current UC Berkeley copyright. If you need a different copyright, then we'll have to negotiate.

What to include If you are contributing stars, please include .pl files, icons, and demos.

1) Your .pl file should have a description of the star. Be sure to include your name as the author in the .pl file.

2) The demo directory should contain a facet "init.pal" with an icon for each demo and a facet "user.pal" with icons for each star. Including a custom icon is nice. Including a demo really helps the Ptolemy group test your star. Stars with out demos are more likely to be broken.

[This step needs to be polished -cxh] 3) The init.pal and user.pal palettes, and all demos, should contain ***only*** references to the directory $PTOLEMY/src/domains/the-domain/contrib/your_hopefully_unique_dir_name. To check this latter condition, run

masters {init.pal, user.pal ...}

/usr/users/my_home/my_stars/star_name

~user_name/my_stars/starname

$PTOLEMY/src/domains/sdf/contrib/my_star/src/SDFMyStar.pl

$PTOLEMY/src/domains/sdf/contrib/my_star/demo/MyStarDemo
$PTOLEMY/src/domains/sdf/contrib/my_star/icons/MyStar
$PTOLEMY/src/domains/sdf/contrib/my_star/icons/init.pal
$PTOLEMY/src/domains/sdf/contrib/my_star/icons/user.pal

cp -R my_directory/* $PTOLEMY/src/domains/sdf/contrib/my_star
cd $PTOLEMY/src/domains/sdf/contrib/my_star/icons
remove junk
masters init.pal
...
masters user.pal
...
masters others...
cd $PTOLEMY/src/domains/sdf/contrib/my_star/demo
masters MyStarDemo
tar cvf ...
uuendcode ...

FTP

Misc.

See Also

$PTOLEMY/src/gnu/README All about GNU software

~ptdesign/adm/doc/porting.txt Notes about porting Ptolemy to different architectures

$PTOLEMY/src/octtools/README Contains discussion about vem and gcc