From owner-ptolemy-hackers Sat Feb 1 08:40:34 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id IAA14994 for ptolemy-hackers-outgoing at brahe; Sat, 1 Feb 1997 08:35:24 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA14988 for ; Sat, 1 Feb 1997 08:35:17 -0800 (PST) Received: from neal.ctd.comsat.com (exim at neal.ctd.comsat.com [134.133.40.21]) by messier eecs berkeley edu (8.8.4/8.7.3) with SMTP id IAA02679 for ; Sat, 1 Feb 1997 08:35:15 -0800 (PST) Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vqiOo-0006UH-00; Sat, 1 Feb 1997 11:34:42 -0500 To: "W.H. Buttner" Cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: BER testing in Ptolemy References: <199701301343.FAA23471 at messier eecs berkeley edu> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 01 Feb 1997 11:34:41 -0500 In-Reply-To: "W.H. Buttner"'s message of Thu, 30 Jan 1997 16:42:15 SADT Message-ID: Lines: 2 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I contributed SDFErrCnt.pl under SDF/user-contrib. This might be useful. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 3 01:59:33 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id BAA24805 for ptolemy-hackers-outgoing at brahe; Mon, 3 Feb 1997 01:52:53 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id BAA24799 for ; Mon, 3 Feb 1997 01:52:49 -0800 (PST) Received: from rc4.vub.ac.be (root at rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id BAA09133 for ; Mon, 3 Feb 1997 01:52:46 -0800 (PST) Received: from is2e.vub.ac.be (root at is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id KAA22506; Mon, 3 Feb 1997 10:52:57 +0100 Received: from pc32.iihe.ac.be by is2e.vub.ac.be (5.61/BFUCC-920211) id AA12890; Mon, 3 Feb 97 10:52:41 +0100 Message-Id: <32F5B5D7.2B7ED252 at ulb.ac.be> Date: Mon, 03 Feb 1997 10:54:31 +0100 From: Marc De Preter Organization: Universiti Libre de Bruxelles X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) Mime-Version: 1.0 To: ptolemy-hackers at messier eecs berkeley edu Subject: More than 15 minutes ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello I think this is a question destinated to those who run Ptolemy with Linux. But maybe somebody else has had the same problem. I still have the same problem (see my previous message) : i can't create the first example (Almagest v2, chap 2). I've traced the whole thing, and the problem seems to come from cc1plus : it crashes after more than 15, using all my disk and memory space (for trials : 64 Mb Ram, 110 Mb swap space, 60 Mb disk space). When it crashes, i get the following messages : Virtual memory exceeded in 'new', and RPC is not called by the client. Here is my configuration : Pentium 166, 32 Mb Ram, 110 Swap Ptolemy 0.6 with the dynamic libraries (recompiled, without problems) GCC 2.7.2.1 The cc1plus patch for GCC 2.7.0 Linux Slackware 3.0, kernel 2.0.28 All suggested links I received some usefull comments from a linux user (with a unknow address, please Arnaud give me a *valid* address :-), telling me that his DX2-66 was able to compile stars of hundreds of lines (my star is only 42 lines long, and it doesn't compile). There is thus a solution to my problem. So, Ptolemy linuxers, let me please know your configuration, especially the gcc one (version, patches, ...), since it seems that the problems come from there. We may then continue by mail only, and then post the solution on this mailing list, so to not bore everybody with comments not really related to Ptolemy. Marc "Two beer or not two beer, zat is ze question" Mr Megot, Young Spirou's Teacher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 4 08:57:24 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id IAA02630 for ptolemy-hackers-outgoing at brahe; Tue, 4 Feb 1997 08:47:35 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA02624 for ; Tue, 4 Feb 1997 08:47:13 -0800 (PST) Received: from fobos.ulpgc.es (fobos.ulpgc.es [193.145.132.5]) by messier eecs berkeley edu (8.8.4/8.7.3) with SMTP id IAA14859 for ; Tue, 4 Feb 1997 08:47:09 -0800 (PST) Received: from cma-gw.cma.ulpgc.es by fobos.ulpgc.es (5.65/Ultrix4.2-C) id AA08116; Tue, 4 Feb 1997 16:49:05 GMT Received: from mazo by cma.ulpgc.es (4.1/SMI-4.1) id AA21036; Tue, 4 Feb 97 16:14:39 GMT Date: Tue, 4 Feb 97 16:14:39 GMT From: mdhdez at cma-sv (Maria Dolores Hernandez y Fernandez) Message-Id: <9702041614.AA21036 at cma.ulpgc.es> To: ptolemy-hackers at messier eecs berkeley edu Subject: configuration Cc: mdhdez at cma.ulpgc.es Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello We'll go to install Ptolemy in a PC and we'd like to know what the configuration for our PC to Ptolemy run correctly. Thank you ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 5 01:25:30 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id BAA08566 for ptolemy-hackers-outgoing at brahe; Wed, 5 Feb 1997 01:23:07 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id BAA08560 for ; Wed, 5 Feb 1997 01:23:05 -0800 (PST) Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id BAA18080 for ; Wed, 5 Feb 1997 01:23:01 -0800 (PST) Received: from tte2006.tte.vtt.fi (tte2006.tte.vtt.fi [130.188.12.106]) by tel1.tte.vtt.fi (8.8.5/8.8.5) with SMTP id LAA06169 for ; Wed, 5 Feb 1997 11:22:25 +0200 (EET) Message-Id: <3.0.32.19970205112140.006a6f1c at tel1.tte.vtt.fi> X-Sender: simo at tel1.tte.vtt.fi X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Feb 1997 11:21:42 +0200 To: ptolemy-hackers at messier eecs berkeley edu From: Simo Veikkolainen Subject: LOG_DEL and LOG_NEW Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Is the use of LOG_DEL and LOG_NEW macros (used with operators new and delete) explained somewhere in the Ptolemy manual? I took a quick look at the on-line manual but found nothing. thanks, Simo ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 5 07:33:29 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id HAA09092 for ptolemy-hackers-outgoing at brahe; Wed, 5 Feb 1997 07:30:56 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id HAA09086 for ; Wed, 5 Feb 1997 07:30:52 -0800 (PST) Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id HAA19209 for ; Wed, 5 Feb 1997 07:30:48 -0800 (PST) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id KAA10926; Wed, 5 Feb 1997 10:30:41 -0500 (EST) To: Simo Veikkolainen cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: LOG_DEL and LOG_NEW In-reply-to: Your message of Wed, 05 Feb 1997 11:21:42 +0200 <3.0.32.19970205112140.006a6f1c at tel1.tte.vtt.fi> Date: Wed, 05 Feb 1997 10:30:40 -0500 Message-ID: <10924.855156640 at sss.pgh.pa.us> From: Tom Lane Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Simo Veikkolainen writes: > Is the use of LOG_DEL and LOG_NEW macros (used with operators > new and delete) explained somewhere in the Ptolemy manual? I believe they're obsolete, which is why the manuals don't talk about them anymore. You'll find them in old code, because no one ever bothered to go around and remove 'em, but most of the newer code in the system doesn't bother with 'em. Originally, those macros could be used to generate memory-usage-checking code --- see logNew.h and logNew.cc in $PTOLEMY/src/kernel/. I guess the Ptolemy team found some better tool for tracking memory leaks, and stopped maintaining this one. regards, tom lane ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 5 08:31:19 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id IAA09452 for ptolemy-hackers-outgoing at brahe; Wed, 5 Feb 1997 08:30:14 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA09445 for ; Wed, 5 Feb 1997 08:30:11 -0800 (PST) Received: from rc4.vub.ac.be (root at rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA19393 for ; Wed, 5 Feb 1997 08:30:00 -0800 (PST) Received: from is2e.vub.ac.be (root at is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id RAA27990; Wed, 5 Feb 1997 17:29:42 +0100 Received: from pc32.iihe.ac.be by is2e.vub.ac.be (5.61/BFUCC-920211) id AA16931; Wed, 5 Feb 97 17:29:21 +0100 Message-Id: <32F8B5C9.353E19A4 at ulb.ac.be> Date: Wed, 05 Feb 1997 17:31:05 +0100 From: Marc De Preter Organization: Universiti Libre de Bruxelles X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) Mime-Version: 1.0 To: Ptolemy Hackers Subject: Still a lot of time to compile 42 lines Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello ptolemy hackers I think i see some light at the end of the tunnel (i hope it's not a coming train, but the end of my problems :-) Let's summarize the problem (see almagest v2, chap 2, section 2 for more details) : I copied SDFSin.pl in a directory, and tried to do a make-star on it. Then my compiler seemed to cycle in cc1plus, 'eating' all available space (memory+disk). So i checked everything, installed all required packages, making all required links, etc. Still not compiling. Suddenly, i had an idea : tail -f /tmp/the_file_that_eats_all_my_disk_space .... surprise, surprise, it's an error file. Here is what it says : /usr/include/_G_config.h:50: numeric constant with no digits This file has only this messages, repeated zillions of times ! But when i compile the star 'by hand' (gcc -I... SDFSin.cc), i only have problems with the linking steps (which i think is totally normal, since it needs dynamic load). So, ... what is wrong ? I think it is now a config problem (we're moving; last time i thought it was a compiler problem :-) Tell me, you gurus, where can the problem be ? Which config file must i change to avoid this problem (and finally see ptolemy making its basic example) ? I remind you that i compiled ptolemy, made all necessary changes, ... I hope someone will help me, 'cause my fellows are talking about suppressing Ptolemy from the disk :-{ Marc "Two beer or not two beer, zat is ze question" Mr Megot, Young Spirou's Teacher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 5 08:55:44 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id IAA09516 for ptolemy-hackers-outgoing at brahe; Wed, 5 Feb 1997 08:54:35 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA09510 for ; Wed, 5 Feb 1997 08:54:32 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA19460 for ; Wed, 5 Feb 1997 08:54:30 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.4/8.7.3) with ESMTP id IAA11100; Wed, 5 Feb 1997 08:54:23 -0800 (PST) From: Christopher Hylands Message-Id: <199702051654.IAA11100 at kahn. eecs berkeley edu> To: Simo Veikkolainen cc: Tom Lane , ptolemy-hackers at messier eecs berkeley edu Subject: Re: LOG_DEL and LOG_NEW In-reply-to: Your message of Wed, 05 Feb 1997 10:30:40 -0500. <10924.855156640 at sss.pgh.pa.us> Date: Wed, 05 Feb 1997 08:54:23 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Tom Lane is right, we now use PureAtria's Purify to track leaks. Purify is commercial software, but IMHO worth it. It is hard to imagine using c++ without something like Purify. LOG_DEL and LOG_NEW have not been used in some time. You could try searching the ptolemy-hackers archive and see what you come up with. I believe that there are freely available malloc's out there that have debugging ability. However, these might not work with c++. Also, I think the Sun C++ environment has some sort of purify like capability. This company called Parasoft also sells a product. -Christopher -------- Simo Veikkolainen writes: > Is the use of LOG_DEL and LOG_NEW macros (used with operators > new and delete) explained somewhere in the Ptolemy manual? I believe they're obsolete, which is why the manuals don't talk about them anymore. You'll find them in old code, because no one ever bothered to go around and remove 'em, but most of the newer code in the system doesn't bother with 'em. Originally, those macros could be used to generate memory-usage-checking code --- see logNew.h and logNew.cc in $PTOLEMY/src/kernel/. I guess the Ptolemy team found some better tool for tracking memory leaks, and stopped maintaining this one. regards, tom lane -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 5 12:59:02 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id MAA14027 for ptolemy-hackers-outgoing at brahe; Wed, 5 Feb 1997 12:48:07 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id MAA14021 for ; Wed, 5 Feb 1997 12:48:04 -0800 (PST) Received: from edison. eecs berkeley edu (edison. eecs berkeley edu [128.32.240.183]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id MAA20282 for ; Wed, 5 Feb 1997 12:48:02 -0800 (PST) Received: (from cameron at localhost) by edison. eecs berkeley edu (8.8.4/8.7.3) id MAA20382; Wed, 5 Feb 1997 12:47:56 -0800 (PST) Date: Wed, 5 Feb 1997 12:47:56 -0800 (PST) From: Mike Williamson Message-Id: <199702052047.MAA20382 at edison. eecs berkeley edu> To: mdepretr at ulb.ac.be, ptolemy-hackers at messier eecs berkeley edu Subject: Re: Still a lot of time to compile 42 lines Cc: cameron at edison. eecs berkeley edu Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk >>>>> I copied SDFSin.pl in a directory, and tried to do a make-star on it. Then my compiler seemed to cycle in cc1plus, 'eating' all available space (memory+disk). So i checked everything, installed all required packages, making all required links, etc. Still not compiling. Suddenly, i had an idea : tail -f /tmp/the_file_that_eats_all_my_disk_space .... surprise, surprise, it's an error file. Here is what it says : /usr/include/_G_config.h:50: numeric constant with no digits >>>>> Marc, Have you tried looking at the file /usr/include/_G_config.h and in particular at line 50 to see what it is referring to? Can you mail that back to the group so we can see what it is pointing to? That is an unusual include file name. I'm not sure why it would be included, let alone why it would have a numeric constant with no digits. -Mike ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 6 00:19:26 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id AAA19479 for ptolemy-hackers-outgoing at brahe; Thu, 6 Feb 1997 00:16:31 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id AAA19472 for ; Thu, 6 Feb 1997 00:16:28 -0800 (PST) Received: from rc4.vub.ac.be (root at rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id AAA22439 for ; Thu, 6 Feb 1997 00:16:23 -0800 (PST) Received: from is2e.vub.ac.be (root at is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id JAA05243; Thu, 6 Feb 1997 09:16:25 +0100 Received: from pc32.iihe.ac.be by is2e.vub.ac.be (5.61/BFUCC-920211) id AA13981; Thu, 6 Feb 97 09:16:09 +0100 Message-Id: <32F993BA.5F8FB198 at ulb.ac.be> Date: Thu, 06 Feb 1997 09:18:02 +0100 From: Marc De Preter Organization: Universiti Libre de Bruxelles X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) Mime-Version: 1.0 To: Ptolemy Hackers Subject: Re: Still a lot of time to compile 42 lines References: <199702052047.MAA20382 at edison. eecs berkeley edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Mike Williamson wrote: > Have you tried looking at the file /usr/include/_G_config.h > and in particular at line 50 to see what it is referring to? Of course, but it's quite crypted :-) It's a file included by , which is itself included in . > Can you mail that back to the group so we can see what it is > pointing to? That is an unusual include file name. I'm not > sure why it would be included, let alone why it would have > a numeric constant with no digits. Here is line 50 : typedef int _G_int8_t __attribute__((__mode__(__QI__))); This line is included if GNU version is > 2.7 But i can do a 'gcc -I ... SDFMyStar.cc' without seeing such messages (again, the only problems i have when i do this are linking problems). The file _G_config.h is thus included without problems. Marc "Two beer or not two beer, zat is ze question" Mr Megot, Young Spirou's Teacher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 6 12:05:25 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id LAA22503 for ptolemy-hackers-outgoing at brahe; Thu, 6 Feb 1997 11:56:40 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id LAA22497 for ; Thu, 6 Feb 1997 11:56:29 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id LAA28660 for ; Thu, 6 Feb 1997 11:56:28 -0800 (PST) Received: from neal.ctd.comsat.com (neal.ctd.comsat.com [134.133.40.21]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with SMTP id LAA23964 for ; Thu, 6 Feb 1997 11:56:24 -0800 Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vsZvc-00020v-00; Thu, 6 Feb 1997 14:56:16 -0500 To: ptolemy-hackers at eecs berkeley edu Subject: tkshowvalues for CGC? Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 06 Feb 1997 14:56:16 -0500 Message-ID: Lines: 1 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I need something like tkshowvalues for CGC. Any suggestion? ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 01:02:42 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id AAA24803 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 00:49:09 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id AAA24797 for ; Fri, 7 Feb 1997 00:49:06 -0800 (PST) Received: from hotblack.ee.up.ac.za (hotblack.ee.up.ac.za [137.215.31.17]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id AAA26692 for ; Fri, 7 Feb 1997 00:48:29 -0800 (PST) Message-Id: <199702070848.AAA26692 at messier eecs berkeley edu> Received: by hotblack.ee.up.ac.za (1.39.111.2/16.2) id AA017395286; Fri, 7 Feb 1997 11:48:06 +0300 From: "W.H. Buttner" Subject: dynamically load compiled-in star. To: ptolemy-hackers at messier eecs berkeley edu Date: Fri, 07 Feb 1997 11:48:05 SADT X-Mailer: Elm [revision: 111.1] Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi I again have a problem... I connected an impulse source to a tkplot signal sink in the CGC domain. On running the schematic, I get the following error message... star 'TkImpulse' is a compiled-in star of domain CGC. Cannot dynamically load a compiled-in star class. Please help thanks Werner Buttner (University of Pretoria, South Africa) ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 05:48:40 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id FAA25329 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 05:45:26 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id FAA25323 for ; Fri, 7 Feb 1997 05:45:23 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id FAA09539 for ; Fri, 7 Feb 1997 05:45:22 -0800 (PST) Received: from neal.ctd.comsat.com (neal.ctd.comsat.com [134.133.40.21]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with SMTP id FAA03140 for ; Fri, 7 Feb 1997 05:45:19 -0800 Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vsqc9-0002P2-00; Fri, 7 Feb 1997 08:45:17 -0500 From: Neal Becker To: ptolemy-hackers at eecs berkeley edu Subject: cgc questions X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P: GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<} Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII Message-Id: Date: Fri, 7 Feb 1997 08:45:17 -0500 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk A couple of questions. 1) This code in a codeblock: $ref(numPackets) += 1; $ref(Packets) = $val(numPackets); where numPackets is a state, and Packets is an output port produced: numPackets_11 += 1; Packets_1 = 0; What's going on? 2) I have a state variable, call it x. I can't say $ref(x++). What's the best alternative, $ref(x) += 1? ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 08:00:23 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id HAA25510 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 07:54:41 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id HAA25504 for ; Fri, 7 Feb 1997 07:54:38 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id HAA10216 for ; Fri, 7 Feb 1997 07:54:37 -0800 (PST) Received: from foucault. eecs berkeley edu (foucault. eecs berkeley edu [128.32.240.127]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id HAA03736 for ; Fri, 7 Feb 1997 07:54:35 -0800 Received: from localhost (sunil at localhost) by foucault. eecs berkeley edu (8.8.4/8.7.3) with SMTP id HAA16003; Fri, 7 Feb 1997 07:54:24 -0800 (PST) Date: Fri, 7 Feb 1997 07:54:23 -0800 (PST) From: Sunil Bhave To: Neal Becker cc: ptolemy-hackers at eecs berkeley edu Subject: Re: cgc questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk > 1) This code in a codeblock: > > $ref(numPackets) += 1; > $ref(Packets) = $val(numPackets); ^^^^^^ If you want Packets_1 = numPackets_11, then change $val to $ref > > where numPackets is a state, and Packets is an output port produced: > numPackets_11 += 1; > Packets_1 = 0; > > 2) I have a state variable, call it x. I can't say $ref(x++). What's > the best alternative, $ref(x) += 1? > how about $ref(x)++ ? i think that will work, Sunil. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 10:01:07 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id JAA26426 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 09:58:20 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id JAA26420 for ; Fri, 7 Feb 1997 09:58:16 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id JAA11596 for ; Fri, 7 Feb 1997 09:58:15 -0800 (PST) Received: from gateway.faroudja.com ([207.82.51.201]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id JAA05253 for ; Fri, 7 Feb 1997 09:58:08 -0800 Received: from jamesl (jamesl.faroudja.com [207.82.51.132]) by gateway.faroudja.com (8.7.1/8.7.1) with SMTP id JAA13299; Fri, 7 Feb 1997 09:56:59 -0800 Message-ID: <32FB6D02.2FEE@faroudja.com> Date: Fri, 07 Feb 1997 09:57:22 -0800 From: James Lundblad Organization: Faroudja Laboratories Inc. X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Neal Becker CC: ptolemy-hackers at eecs berkeley edu Subject: Re: cgc questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Neal Becker wrote: > 1) This code in a codeblock: > > $ref(numPackets) += 1; > $ref(Packets) = $val(numPackets); > where numPackets is a state, and Packets is an output port produced: > numPackets_11 += 1; > Packets_1 = 0; > > What's going on? The $val macro only returns the initial state of the state variable, only useful for parameters that don't change during simulation. $ref returns the variable name. I was caught by this one too. Safer to use $ref everywhere perhaps. > 2) I have a state variable, call it x. I can't say $ref(x++). What's > the best alternative, $ref(x) += 1? Hmmm, try $ref(x)++; ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 10:32:27 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id KAA26489 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 10:30:54 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id KAA26483 for ; Fri, 7 Feb 1997 10:30:51 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id KAA11967 for ; Fri, 7 Feb 1997 10:30:50 -0800 (PST) Received: from neal.ctd.comsat.com (neal.ctd.comsat.com [134.133.40.21]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with SMTP id KAA05722 for ; Fri, 7 Feb 1997 10:30:48 -0800 Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vsv4G-0002Vf-00; Fri, 7 Feb 1997 13:30:36 -0500 To: James Lundblad Cc: ptolemy-hackers at eecs berkeley edu Subject: Re: cgc questions References: <32FB6D02.2FEE@faroudja.com> Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 07 Feb 1997 13:30:36 -0500 In-Reply-To: James Lundblad's message of Fri, 07 Feb 1997 09:57:22 -0800 Message-ID: Lines: 5 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk CGC writes C, not C++. It appears to me that the best place to put state information (i.e., variables that are local to each instance of each star) is to use defstate, and then you would use $ref(). Is there any alternative way to code state variables, rather than using defstate, for variables that are not settable? ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 10:50:44 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id KAA26543 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 10:48:27 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id KAA26537 for ; Fri, 7 Feb 1997 10:48:24 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id KAA12244 for ; Fri, 7 Feb 1997 10:48:23 -0800 (PST) Received: from gateway.faroudja.com ([207.82.51.201]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id KAA05967 for ; Fri, 7 Feb 1997 10:48:15 -0800 Received: from jamesl (jamesl.faroudja.com [207.82.51.132]) by gateway.faroudja.com (8.7.1/8.7.1) with SMTP id KAA13668; Fri, 7 Feb 1997 10:47:06 -0800 Message-ID: <32FB78C1.3F47 at faroudja.com> Date: Fri, 07 Feb 1997 10:47:29 -0800 From: James Lundblad Organization: Faroudja Laboratories Inc. X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Neal Becker CC: ptolemy-hackers at eecs berkeley edu Subject: Re: cgc questions References: <32FB6D02.2FEE@faroudja.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Neal Becker wrote: > > CGC writes C, not C++. It appears to me that the best place to put > state information (i.e., variables that are local to each instance of > each star) is to use defstate, and then you would use $ref(). Is > there any alternative way to code state variables, rather than using > defstate, for variables that are not settable? There is a macro called $starSymbol(name) that returns a unique label in the star instance scope ( see 12.2.4 Macros ). You can use this macro to add declarations for local state in the initCode { } method using addDeclaration("int $starSymbol(foo);");, and then reference the variable in your codeblocks using $starSymbol(foo). Kind of messy, and perhaps just as complicated as using defstate. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 10:53:41 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id KAA26591 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 10:53:18 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id KAA26586 for ; Fri, 7 Feb 1997 10:53:16 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id KAA12457 for ; Fri, 7 Feb 1997 10:53:15 -0800 (PST) Received: from foucault. eecs berkeley edu (foucault. eecs berkeley edu [128.32.240.127]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id KAA06038 for ; Fri, 7 Feb 1997 10:53:13 -0800 Received: from localhost (sunil at localhost) by foucault. eecs berkeley edu (8.8.4/8.7.3) with SMTP id KAA17209; Fri, 7 Feb 1997 10:52:58 -0800 (PST) Date: Fri, 7 Feb 1997 10:52:58 -0800 (PST) From: Sunil Bhave Reply-To: Sunil Bhave To: Neal Becker cc: ptolemy-hackers at eecs berkeley edu Subject: Re: cgc questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Yes, there is... you could do codeblock (declarations) { int $starSymbol(x); } and then in the initCode do initCode { addDeclaration(declarations); } you will have to use $starSymbol(x) instead of $ref(x) everywhere.. I think all this is well-documented in the CG and CGC Domain chapters in the Programmer`s Manual http://ptolemy.eecs.berkeley.edu/papers/almagest/docs/prog/html/content.html Sunil. On 7 Feb 1997, Neal Becker wrote: > CGC writes C, not C++. It appears to me that the best place to put > state information (i.e., variables that are local to each instance of > each star) is to use defstate, and then you would use $ref(). Is > there any alternative way to code state variables, rather than using > defstate, for variables that are not settable? > > ---------------------------------------------------------------------------- > Posted to the ptolemy-hackers mailing list. Please send administrative > mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 7 10:55:34 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id KAA26614 for ptolemy-hackers-outgoing at brahe; Fri, 7 Feb 1997 10:55:26 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id KAA26608 for ; Fri, 7 Feb 1997 10:55:24 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.4/8.7.3) with SMTP id KAA12480 for ; Fri, 7 Feb 1997 10:55:23 -0800 (PST) Received: from edison. eecs berkeley edu (edison. eecs berkeley edu [128.32.240.183]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id KAA06053 for ; Fri, 7 Feb 1997 10:55:21 -0800 Received: (from cameron at localhost) by edison. eecs berkeley edu (8.8.4/8.7.3) id KAA02107; Fri, 7 Feb 1997 10:55:09 -0800 (PST) Date: Fri, 7 Feb 1997 10:55:09 -0800 (PST) From: Mike Williamson Message-Id: <199702071855.KAA02107 at edison. eecs berkeley edu> To: jamesl at faroudja.com, neal at ctd.comsat.com Subject: Re: cgc questions Cc: ptolemy-hackers at eecs berkeley edu Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk >>> CGC writes C, not C++. It appears to me that the best place to put state information (i.e., variables that are local to each instance of each star) is to use defstate, and then you would use $ref(). Is there any alternative way to code state variables, rather than using defstate, for variables that are not settable? >>> You've probably seen that states defined by defstate { } in all stars can have attributes attached to them. This is from CGCXgraph.pl: >>>>> defstate { name {count} type {int} default { 0 } desc {Samplecounter} attributes {A_NONSETTABLE|A_NONCONSTANT} } >>>>> The attribute A_NONSETTABLE indicates that the variable cannot be set by the user, so it should not appear when you do edit_parameters. The fact that it also has the attribute A_NONCONSTANT means that the target should allocate a state variable for it when it generates code. This is the standard way to code state variables for variables that are not settable. If you look elsewhere in CGCXgraph.pl, you'll see the initCode definition: >>>>> initCode { addDeclaration(" FILE* $starSymbol(fp);"); addInclude(""); StringList w = " if(!($starSymbol(fp) = fopen(\""; w << target()->name() << "_$starSymbol(temp)"; w << "\",\"w\")))"; addCode(w); addCode(err); } >>>>> See that the first thing is to add a declaration in the generated C code for FILE* $starSymbol(fp). The macro $starSymbol serves to make sure that different instances of the CGCXgraph star in the same graph will have their own unique name for their own file pointer. This is a variable that is local to each instance of the CGCXgraph star. Later on, the variable is used in the main code body, in the go method: >>>>> go { @ if (++$ref(count) >= $val(ignore)) @ fprintf($starSymbol(fp),"%g %g\n",$ref(index),$ref(input)); @ $ref(index) += $val(xUnits); } >>>>> The macro $starSymbol is used once again, and that will expand out to the same unique file pointer name that was created in the initCode method for the same instance of the star. So this allows you to have a file pointer variable (or any other variable which could serve to hold state for the star) which is not visible to the user and is not settable by the user. Note that this requires the star writer to do a little extra work in adding code to generate the declaration and initialization of the variable. If you used the defstate{} facility, these steps would be handled automatically. -Mike Williamson ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Sun Feb 9 22:12:57 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id WAA11667 for ptolemy-hackers-outgoing at brahe; Sun, 9 Feb 1997 22:05:57 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id WAA11661 for ; Sun, 9 Feb 1997 22:05:54 -0800 (PST) Received: from hotblack.ee.up.ac.za (hotblack.ee.up.ac.za [137.215.31.17]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id WAA07253 for ; Sun, 9 Feb 1997 22:05:28 -0800 (PST) Message-Id: <199702100605.WAA07253 at messier eecs berkeley edu> Received: by hotblack.ee.up.ac.za (1.39.111.2/16.2) id AA010674711; Mon, 10 Feb 1997 09:05:11 +0300 From: "W.H. Buttner" Subject: Archives To: ptolemy-hackers at messier eecs berkeley edu Date: Mon, 10 Feb 1997 9:05:10 SADT X-Mailer: Elm [revision: 111.1] Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi I have subscribed to the Ptolemy mailing lists, and the reply message informed me where I could get the archives. I have unfortuanately lost that specific mail message. Where can I access these archives, and is there perhaps a place, where a collection of *.pl files are kept. Thanks a lot Werner Buttner (University of Pretoria, South Africa) ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 00:00:48 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id XAA11875 for ptolemy-hackers-outgoing at brahe; Sun, 9 Feb 1997 23:56:53 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id XAA11869 for ; Sun, 9 Feb 1997 23:56:50 -0800 (PST) Received: from rc4.vub.ac.be (root at rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id XAA07545 for ; Sun, 9 Feb 1997 23:56:46 -0800 (PST) Received: from is2e.vub.ac.be (root at is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id IAA04642; Mon, 10 Feb 1997 08:56:55 +0100 Received: from pc32.iihe.ac.be by is2e.vub.ac.be (5.61/BFUCC-920211) id AA07677; Mon, 10 Feb 97 08:56:38 +0100 Message-Id: <32FED52B.29DF2C00 at ulb.ac.be> Date: Mon, 10 Feb 1997 08:58:35 +0100 From: Marc De Preter Organization: Universiti Libre de Bruxelles X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) Mime-Version: 1.0 To: ptolemy-hackers at messier eecs berkeley edu Subject: Re: Still a lot of time to compile 42 lines References: <199702072036.MAA02484 at edison. eecs berkeley edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello > From your description of the problem, including the > line from the include file, I still can't tell what's > going on. > I think I need to see the star file you are trying to > compile. > Would you please send to ptolemy-hackers: > 1. A consise description of your problem again, > including the commands you execute that > lead up to your problem Well, here comes the description : I followed the instructions given in the Almagest, vol2, chap 2, section 2 "Adding stars dynamically to Ptolemy". I copied SDFSin.pl in a new directory, and i renamed it SDFMyStar.pl. I changed the name inside (Sin -> MyStar), and then I ran pigi from that directory. Ptolemy has not been able to compile (after a 'make-star') : all my memory is eaten, as well as my disk space (there is a log file where i get the following message : /usr/include/_G_config.h:50: numeric constant with no digits). But i can compile the source from the command line (without problems, _G_config.h is oncluded correctly). The only errors are linking errors. > 2. A copy of the star you are compiling, and any > other files you create that are involved > in the compilation process (source and include > files). > The star I am compiling can be found in $PTOLEMY/src/domains/sdf/stars. I just copied and renamed it, just as mentioned in the Almagest, vol 2. After noticing the problem, I also ran 'ptlang' to create all the files to compile from the command-line. Those files are totally correct. Someone from the mailing list sent me a copy of those files (.pl, .c & .h), and they are exactly the same as mine (except for the name of the directory where those files have been created). -- Marc "Two beer or not two beer, zat is ze question" Mr Megot, Young Spirou's Teacher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 02:23:25 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id CAA12213 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 02:21:51 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id CAA12207 for ; Mon, 10 Feb 1997 02:21:48 -0800 (PST) Received: from gcsin1.gecm.com (gcsin1.gecm.com [194.128.74.2]) by messier eecs berkeley edu (8.8.4/8.7.3) with SMTP id CAA07954 for ; Mon, 10 Feb 1997 02:21:42 -0800 (PST) Received: from gcsin3.geccs.gecm.com by gcsin1.gecm.com; (5.65/1.1.8.2/13Mar95-0121PM) id AA31824; Mon, 10 Feb 1997 08:43:53 GMT Received: from gcschm.geccs.gecm.com by gcsin3.geccs.gecm.com; (5.65/1.1.8.2/13Mar95-1139AM) id AA15208; Fri, 7 Feb 1997 17:00:17 GMT Disclose-Recipients: prohibited Date: Fri, 07 Feb 1997 16:59:15 +0000 (GMT) From: Geoffrey Thorpe Subject: Re: ptolemy with linux slackware 3.1 To: Wolfgang Reimer , ptolemy-hackers at messier eecs berkeley edu Message-Id: <9515591607021997/A52797/SULLY/11B23C3B0D00*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: normal Ua-Content-Id: 11B23C3B0D00 X400-Mts-Identifier: [;9515591607021997/A52797/SULLY] Hop-Count: 2 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk On Thu, 30 Jan 1997, Wolfgang Reimer wrote: > I'd like to ask you a favor. Every day I get a lot of questions regarding Ptolemy & Linux. Could > you summarize as exactly as possible all changes you made (to Slackware 3.1 as well as to > Ptolemy 0.6) to get Ptolemy up and running. So I will be able to help all the other people who try > to install Ptolemy under Slackware 3.1. I would appreciate it if you could send these notes to > both me and the Ptolemy hackers list . > A very reasonable request. Unfortunately my records are not too good. Here's what I think happened. Both Linux and ptolemy were loaded from the InfoMagic Linux developer's resource CD,s August 96 edition. Thus the Linux version is 3.1 with kernel 2.0.0 and gcc 27.2 As the network here is mainly for Windows PCs I decided to run a stand alone Linux system and use windows for networking. (A bad decision). I created a user ptolemy and created a .bash_profile file including export PTOLEMY=/home/ptolemy export OCTTOOLS=$PTOLEMY/octtools export PTARCH=linux export PATH=$PTOLEMY/bin:$PTOLEMY/bin.${PTARCH}:$OCTTOOLS/bin.${PTARCH}:${PATH} during my first attempts to either build the system or run the binaries provied I got messages of complaining of nonexistent files in /users/ptolemy (despite the above settings) I thus created a link /users to /home. Eventually I read the manual and loaded the networking software. I appear then to have created a link libdl.so to libdl.so.1.7.14 I can't remember why but it's still there. my inital attempts used the static libraries patch. I was getting an error about an undefined reference to ACG :: ACG(unsigned long, int) in additon to those listed later. I had loaded the bianaries as well as the sources and I was not convinced make was regarding them all as out of date so I removed the entire system and reloaded source only. pt-0.6.src.tar.gz and pt-0.6.other.src.tar.gz. I then started again with the dynamic libraries patch. The errors in building the were gcc -L../../../lib.linux -Wl,-R,/home/ptolemy/lib.linux:/home/ptolemy/octtools/lib.linux:/usr/lib:/home/ ptolemy/tcltk/tcl.linux/lib/shared:/home/ptolemy/tcltk/tk.linux/lib/shared/:/ho me/ptolemy/tcltk/itcl.linux/lib/shared -Wl,-s -rdynamic attache.o command.o io.o main.o obj.o template.o update.o \ -o attache -L../../../octtools/lib.linux -loh -lvov -loptions -loct -ltr -lutility -lst -lerrtrap -luprintf -lport -lieee -lm -ldl -lcurses -ltermcap io.o: In function `IOinit': io.o(.text+0x41): undefined reference to `erasechar' io.o(.text+0x50): undefined reference to `killchar' make[2]: *** [attache] Error 1 g++ -fpic -O2 -fomit-frame-pointer -Wall -Wcast-align -Wsynth -Dlinux -DI_UNISTD -fno-for-scope -I../../src/kernel -I../../src/compat/ptolemy -c ../../src/kernel/Linker.cc In file included from ../../src/kernel/Linker.cc:113: ../../src/kernel/Linker.sysdep.h:65: dlfcn.h: No such file or directory make[2]: *** [Linker.o] Error 1 make[2]: *** No rule to make target `../../lib.linux/libptolemy.a', needed by `ptcl'. Stop. make[2]: Leaving directory `/home/ptolemy/obj.linux/ptcl' make[3]: *** No rule to make target `../../../lib.linux/libptolemy.a', needed by `tysh'. Stop. make[3]: Leaving directory `/home/ptolemy/obj.linux/tycho/tysh' make[2]: *** [install] Error 2 make[2]: *** No rule to make target `../../lib.linux/libptolemy.a', needed by `pigiRpc'. Stop. At this point I contacted Wolfgang and the record becomes clearer. (I have the correspondence) On his advice > Rename the old libcurses.* files and make symbolic links to the appropriate libncurses.* files. I renamed libcurses.so.0.1.2 and libcurses.so.1.0.0 to libcurses.so.0.1.2.orig and libcurses.so.1.0.0.orig and replaced both with links to libncurses.so.3 I have since spotted that libcurses.so.0 and libcurses.so.1 point to the .orig files but it still seems to have cured the problem. His other advice was > This means that your ld.so package is not complete. It should install the header file "dlfcn.h" in > /usr/include. > I had the same problem with original RedHat3.0.3. They made available an update of the ld.so > package which now correctly includes the above mentioned header file. > If you have ld.so.1.7.14, I can sent you the header file 'dlfcn.h' for this version. This left the problem that I had a file called ld.so which was a file, not the expected link to to a file with a version number. I did however have a file ld-linux.so.1.7.14 and Wolfgang said the two files should be the same version. They were dated the same and my ld.so matched his ld.so.1.7.14 in size, so he provided the corresponding dlfcn.h file which I put in /usr/include. #ifndef DLFCN_H #define DLFCN_H #include /* * Various defines and so forth for the dynamic linker */ /* For dlopen () */ #define RTLD_LAZY 1 #define RTLD_NOW 2 #define RTLD_GLOBAL 0x100 /* For dlsym */ #define RTLD_NEXT ((void *)-1) __BEGIN_DECLS /* The usual prototypes. We use void * instead of the actual * datatype - the user does not manipulate the handles at all. */ extern void * dlopen __P((__const char * __filename, int __flag)); extern __const char * dlerror __P((void)); extern void * dlsym __P((void *, __const char *)); extern int dlclose __P((void *)); __END_DECLS #endif The system then compiled and ran successfully. In loading ptolemy from the source I did, I got a set of files related to X windows (I nearly called them X-files). These among other things changed the windows manager used. I simply deleted these files and went back to using fvwm. I hope this may be of some assitance to others Geoff geoffrey.thorpe at gecm.com ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 09:20:06 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.4/8.7.3) id JAA13531 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 09:14:46 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.4/8.7.3) with ESMTP id JAA13525 for ; Mon, 10 Feb 1997 09:14:44 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by messier eecs berkeley edu (8.8.4/8.7.3) with ESMTP id JAA09223 for ; Mon, 10 Feb 1997 09:14:41 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.4/8.7.3) with ESMTP id JAA15587; Mon, 10 Feb 1997 09:14:25 -0800 (PST) From: Christopher Hylands Message-Id: <199702101714.JAA15587 at kahn. eecs berkeley edu> To: "W.H. Buttner" cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: Archives In-reply-to: Your message of Mon, 10 Feb 1997 09:05:10 -0300. <199702100605.WAA07253 at messier eecs berkeley edu> Date: Mon, 10 Feb 1997 09:14:25 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk The Ptolemy web page at http://ptolemy.eecs.berkeley.edu/ is where the mailing list archives are kept. The direct URL is: http://ptolemy.eecs.berkeley.edu/wais.html There is no big collection of *.pl files on that site. Neal Becker a few stars at: ftp.ctd.comsat.com:/pub/Stars.tar.gz: -rw-r--r-- 1 206 24 8563 Apr 22 1994 Stars.tar.gz -Christopher -------- Hi I have subscribed to the Ptolemy mailing lists, and the reply message infor med me where I could get the archives. I have unfortuanately lost that spec ific mail message. Where can I access these archives, and is there perhaps a place, where a collection of *.pl files are kept. Thanks a lot Werner Buttner (University of Pretoria, South Africa) --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 10:29:44 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id KAA15299 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 10:26:26 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id KAA15293 for ; Mon, 10 Feb 1997 10:26:23 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.5/8.7.3) with SMTP id KAA16604 for ; Mon, 10 Feb 1997 10:26:22 -0800 (PST) Received: from neal.ctd.comsat.com (neal.ctd.comsat.com [134.133.40.21]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with SMTP id KAA26104 for ; Mon, 10 Feb 1997 10:26:20 -0800 Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vu0Qk-0004dw-00; Mon, 10 Feb 1997 13:26:18 -0500 To: ptolemy-hackers at eecs berkeley edu Subject: CGC vs. C++ complex Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 10 Feb 1997 13:26:18 -0500 Message-ID: Lines: 6 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk It seems all but hopeless to use libg++ Complex in CGC. This is a big loss. I hope that in the future we can rename all the "complex" in CGC to something else, such as PT_complex, or CGC_complex. There is no way to work around this with defines, because you need both cgc libs (which have the name "complex" written in the binary), and libg++ complex stuff, also with the name "complex" written into the binary. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 11:11:17 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id LAA15448 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 11:03:52 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA15442 for ; Mon, 10 Feb 1997 11:03:50 -0800 (PST) Received: from tycho. eecs berkeley edu (eal at localhost) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA26164 for ; Mon, 10 Feb 1997 11:03:49 -0800 (PST) From: "Edward A. Lee" Message-Id: <199702101903.LAA26164 at tycho. eecs berkeley edu> To: ptolemy-hackers at tycho. eecs berkeley edu Subject: libg++ in CGC Date: Mon, 10 Feb 1997 11:03:49 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Neal Becker writes: > It seems all but hopeless to use libg++ Complex in CGC. This is a big > loss. I hope that in the future we can rename all the "complex" in > CGC to something else, such as PT_complex, or CGC_complex. There is > no way to work around this with defines, because you need both cgc > libs (which have the name "complex" written in the binary), and libg++ > complex stuff, also with the name "complex" written into the binary. I think the right solution here is to create a C++ code generation domain, or better yet, to improve the compile-SDF target so that it gets the same efficiency as CGC. Putting C++ code in CGC is a hack, I think. C and C++ are not the same language. Edward ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 13:43:45 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id NAA16138 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 13:42:11 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id NAA16133 for ; Mon, 10 Feb 1997 13:42:09 -0800 (PST) Received: from gateway.faroudja.com (root@[207.82.51.201]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id NAA26819 for ; Mon, 10 Feb 1997 13:41:51 -0800 (PST) Received: from jamesl (jamesl.faroudja.com [207.82.51.132]) by gateway.faroudja.com (8.8.4/8.8.4) with SMTP id NAA01062; Mon, 10 Feb 1997 13:40:01 -0800 Message-ID: <32FF95DB.6E6B@faroudja.com> Date: Mon, 10 Feb 1997 13:40:43 -0800 From: James Lundblad Organization: Faroudja Laboratories Inc. X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Edward A. Lee" CC: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702101903.LAA26164 at tycho. eecs berkeley edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Edward A. Lee wrote: > > Neal Becker writes: > > It seems all but hopeless to use libg++ Complex in CGC. This is a big > > loss. I hope that in the future we can rename all the "complex" in > > CGC to something else, such as PT_complex, or CGC_complex. There is > > no way to work around this with defines, because you need both cgc > > libs (which have the name "complex" written in the binary), and libg++ > > complex stuff, also with the name "complex" written into the binary. > > I think the right solution here is to create a C++ code generation > domain, or better yet, to improve the compile-SDF target so that > it gets the same efficiency as CGC. Putting C++ code in CGC is a hack, > I think. C and C++ are not the same language. I vote for a C++ code generation domain, since isn't compile-SDF speed limited by all the particle abstraction that makes it so flexible? James ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 14:25:11 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id OAA16214 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 14:23:57 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id OAA16208 for ; Mon, 10 Feb 1997 14:23:54 -0800 (PST) Received: from neal.ctd.comsat.com (exim at neal.ctd.comsat.com [134.133.40.21]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with SMTP id OAA26969 for ; Mon, 10 Feb 1997 14:23:53 -0800 (PST) Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vu48d-0004zy-00; Mon, 10 Feb 1997 17:23:51 -0500 To: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702101903.LAA26164 at tycho. eecs berkeley edu> <32FF95DB.6E6B@faroudja.com> Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 10 Feb 1997 17:23:50 -0500 In-Reply-To: James Lundblad's message of Mon, 10 Feb 1997 13:40:43 -0800 Message-ID: Lines: 10 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk >>>>> "James" == James Lundblad writes: Edward A. Lee wrote: >> I think the right solution here is to create a C++ code generation >> domain, or better yet, to improve the compile-SDF target so that >> it gets the same efficiency as CGC. Putting C++ code in CGC is a hack, >> I think. C and C++ are not the same language. That would be great! Is anyone working on this? Any idea of how much effort would be required? ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 14:43:54 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id OAA16270 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 14:43:36 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id OAA16264 for ; Mon, 10 Feb 1997 14:43:33 -0800 (PST) Received: from tycho. eecs berkeley edu (eal at localhost) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id OAA27081; Mon, 10 Feb 1997 14:43:06 -0800 (PST) From: "Edward A. Lee" Message-Id: <199702102243.OAA27081 at tycho. eecs berkeley edu> X-Mailer: exmh version 1.6.5 12/11/95 To: James Lundblad cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC In-reply-to: Your message of Mon, 10 Feb 1997 13:40:43 -0800. <32FF95DB.6E6B@faroudja.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 14:43:06 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk James Lundblad writes: >I vote for a C++ code generation domain, since isn't compile-SDF speed >limited by all the particle abstraction that makes it so flexible? The profile data we've seen leads me to believe that the speed is limited by the particle queueing in the Geodesics. This could be eliminated by statically allocating arrays for buffers, as done in CGC. Edward -- Edward A. Lee Professor phone: 510-642-0455 EECS Dept., Cory Hall fax: 510-642-2739 University of California email:eal at eecs.Berkeley.EDU Berkeley, CA 94720 http://www. eecs berkeley edu/~eal ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 16:49:41 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id QAA16732 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 16:46:25 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id QAA16726 for ; Mon, 10 Feb 1997 16:46:22 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id QAA27424 for ; Mon, 10 Feb 1997 16:46:21 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id QAA24535; Mon, 10 Feb 1997 16:46:16 -0800 (PST) From: Christopher Hylands Message-Id: <199702110046.QAA24535 at kahn. eecs berkeley edu> To: Neal Becker cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC In-reply-to: Your message of 10 Feb 1997 17:23:50 -0500. Date: Mon, 10 Feb 1997 16:46:16 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I don't think that we have anyone working on a C++ code generation domain. Estimating how long it would take would be tricky, but I'd guess a couple of months by someone who already knew Ptolemy. I think it would be less time to work with compile-SDF than to right a new C++ CG domain. Personally, if another language code generation domain were to be written, I'd rather see it generate Java. The benefits of Java are many over C++, I'm especially interested in threading and platform independence. We're talking about various ways to use Java. I see two ways: 1) Write yet another code generation domain, but have it generate Java. This is fairly straight forward, a similar method could be used to generate C++ 2) Redesign more of Ptolemy to use a Java kernel, and then generate Java code that would use the Java kernel. We are looking primarily at choice 2, partly because choice 1 is a 'yet another CG domain', which has been done before. Tom Parks wrote a sieve of eratosthenes PN universe in Java, which we have integrated into Tycho. Going from where we are now to being able to easily generate Java from a universe is a large task, and will take many months. BTW - It seems to me that most of the CG 'domains' are really targets with SDF semantics (There are exceptions, such as cg-ddf and cg-bdf). The main difference between CG domains such as CGC and CG56 has to do with the assumptions about the type system. A CGC domain and a CGC++ domain are really very similar. -Christopher -------- >>>>> "James" == James Lundblad writes: Edward A. Lee wrote: >> I think the right solution here is to create a C++ code generation >> domain, or better yet, to improve the compile-SDF target so that >> it gets the same efficiency as CGC. Putting C++ code in CGC is a h ack, >> I think. C and C++ are not the same language. That would be great! Is anyone working on this? Any idea of how much effort would be required? --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 17:07:01 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id RAA16782 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 17:06:34 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id RAA16776 for ; Mon, 10 Feb 1997 17:06:31 -0800 (PST) Received: from gateway.faroudja.com (root@[207.82.51.201]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id RAA27505 for ; Mon, 10 Feb 1997 17:06:27 -0800 (PST) Received: from jamesl (jamesl.faroudja.com [207.82.51.132]) by gateway.faroudja.com (8.8.4/8.8.4) with SMTP id RAA01092; Mon, 10 Feb 1997 17:04:52 -0800 Message-ID: <32FFC5DD.6DB3 at faroudja.com> Date: Mon, 10 Feb 1997 17:05:33 -0800 From: James Lundblad Organization: Faroudja Laboratories Inc. X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Edward A. Lee" CC: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702102243.OAA27081 at tycho. eecs berkeley edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Edward A. Lee wrote: > > James Lundblad writes: > >I vote for a C++ code generation domain, since isn't compile-SDF speed > >limited by all the particle abstraction that makes it so flexible? > > The profile data we've seen leads me to believe that the speed > is limited by the particle queueing in the Geodesics. This could > be eliminated by statically allocating arrays for buffers, as done > in CGC. > So that would require modifications to the Porthole class and a flag passed via the connect method that says static arrays please? I guess you'd also need a flag in the compiled-SDF target to switch on this feature. How extensive do you think the additions would be to the Porthole/Geodesic code ( ie is it a localized change, or do all the decendant classes need modifying also )? James ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 10 20:32:08 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id UAA17255 for ptolemy-hackers-outgoing at brahe; Mon, 10 Feb 1997 20:30:52 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id UAA17249 for ; Mon, 10 Feb 1997 20:30:49 -0800 (PST) Received: from tycho. eecs berkeley edu (eal at localhost) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id UAA00810; Mon, 10 Feb 1997 20:30:43 -0800 (PST) From: "Edward A. Lee" Message-Id: <199702110430.UAA00810 at tycho. eecs berkeley edu> To: James Lundblad Cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC In-reply-to: Your message of Mon, 10 Feb 1997 17:05:33 -0800. <32FFC5DD.6DB3 at faroudja.com> Date: Mon, 10 Feb 1997 20:30:43 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk James Lundblad writes: >Edward A. Lee wrote: >> >> James Lundblad writes: >> >I vote for a C++ code generation domain, since isn't compile-SDF speed >> >limited by all the particle abstraction that makes it so flexible? >> >> The profile data we've seen leads me to believe that the speed >> is limited by the particle queueing in the Geodesics. This could >> be eliminated by statically allocating arrays for buffers, as done >> in CGC. >> > >So that would require modifications to the Porthole class and a >flag passed via the connect method that says static arrays please? >I guess you'd also need a flag in the compiled-SDF target to >switch on this feature. How extensive do you think the additions >would be to the Porthole/Geodesic code ( ie is it a localized >change, or do all the decendant classes need modifying also )? Actually, my first cut approach would be an entirely new implementation of the SDFPortHole classes. One advantage of compile-SDF is that you get to choose what to link to. No need to link to existing Ptolemy classes unless you need to. I suspect this would lead to the most efficient implementation. Edward ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 04:43:19 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id EAA17830 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 04:35:59 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id EAA17824 for ; Tue, 11 Feb 1997 04:35:55 -0800 (PST) Received: from neal.ctd.comsat.com (exim at neal.ctd.comsat.com [134.133.40.21]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with SMTP id EAA05580 for ; Tue, 11 Feb 1997 04:35:53 -0800 (PST) Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vuHQY-0005Ew-00; Tue, 11 Feb 1997 07:35:14 -0500 To: Christopher Hylands Cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702110046.QAA24535 at kahn. eecs berkeley edu> Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 11 Feb 1997 07:35:14 -0500 In-Reply-To: Christopher Hylands's message of Mon, 10 Feb 1997 16:46:16 -0800 Message-ID: Lines: 4 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk On reflection, I tend to agree with you. In fact, I *am* using c++ in cgc now, and the only problem I've seen so far is the conflict caused by the name "complex". So fixing this maybe isn't that bad of a kludge. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 04:42:32 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id EAA17845 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 04:39:57 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id EAA17840 for ; Tue, 11 Feb 1997 04:39:56 -0800 (PST) Received: from neal.ctd.comsat.com (exim at neal.ctd.comsat.com [134.133.40.21]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with SMTP id EAA05590 for ; Tue, 11 Feb 1997 04:39:55 -0800 (PST) Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vuHUz-0005F4-00; Tue, 11 Feb 1997 07:39:49 -0500 To: "Edward A. Lee" Cc: James Lundblad , ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702110430.UAA00810 at tycho. eecs berkeley edu> Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 11 Feb 1997 07:39:49 -0500 In-Reply-To: "Edward A. Lee"'s message of Mon, 10 Feb 1997 20:30:43 -0800 Message-ID: Lines: 3 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk This sounds very interesting. The code that you get from compile-SDF is very nice. I'd really rather work with it than CGC. If only the porthole processing was more efficient I think this would be a winner. ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 04:42:41 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id EAA17837 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 04:37:25 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id EAA17832 for ; Tue, 11 Feb 1997 04:37:23 -0800 (PST) Received: from neal.ctd.comsat.com (exim at neal.ctd.comsat.com [134.133.40.21]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with SMTP id EAA05586 for ; Tue, 11 Feb 1997 04:37:22 -0800 (PST) Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vuHSU-0005F0-00; Tue, 11 Feb 1997 07:37:14 -0500 To: Christopher Hylands Cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702110046.QAA24535 at kahn. eecs berkeley edu> Mime-Version: 1.0 (generated by tm-edit 7.101) Content-Type: text/plain; charset=US-ASCII From: Neal Becker Date: 11 Feb 1997 07:37:14 -0500 In-Reply-To: Christopher Hylands's message of Mon, 10 Feb 1997 16:46:16 -0800 Message-ID: Lines: 12 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk >>>>> "Christopher" == Christopher Hylands writes: Christopher> Personally, if another language code generation domain were to be Christopher> written, I'd rather see it generate Java. Christopher> The benefits of Java are many over C++, I'm especially interested in Christopher> threading and platform independence. I'm interested in Java, but what about efficiency? Also, are reliable java implementations as widely available as c++? g++ is free. What about java? ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 06:26:54 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id GAA18077 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 06:22:23 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id GAA18071 for ; Tue, 11 Feb 1997 06:22:20 -0800 (PST) Received: from gcsin1.gecm.com (gcsin1.gecm.com [194.128.74.2]) by messier eecs berkeley edu (8.8.5/8.7.3) with SMTP id GAA12778 for ; Tue, 11 Feb 1997 06:18:46 -0800 (PST) Received: from gcsin3.geccs.gecm.com by gcsin1.gecm.com; (5.65/1.1.8.2/13Mar95-0121PM) id AA10620; Tue, 11 Feb 1997 14:13:49 GMT Received: from gcschm.geccs.gecm.com by gcsin3.geccs.gecm.com; (5.65/1.1.8.2/13Mar95-1139AM) id AA27724; Tue, 11 Feb 1997 14:13:10 GMT Disclose-Recipients: prohibited Date: Tue, 11 Feb 1997 14:12:10 +0000 (GMT) From: Geoffrey Thorpe Subject: RPC error running SDF universe with Linux To: ptolemy-hackers at messier eecs berkeley edu Message-Id: <2510121411021997/A02421/SULLY/11B25B8C0900*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: normal Ua-Content-Id: 11B25B8C0900 X400-Mts-Identifier: [;2510121411021997/A02421/SULLY] Hop-Count: 2 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I am running a recompiled ptolemy system in a linux system and am getting the following message in the vem window when I run SDF universes (including some HOF stars) vem> RPC Error: server: application exited without calling RPCExit Closing Application /home/ptolemy/pigiRpcShell on host PC266 Elapsed time is ... seconds. This occurs when I selcet Go from the run control panel. Has anyone seen this problem, or how can I trace it. Geoff geoffrey.thorpe at gecm.com ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 08:37:58 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA18342 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 08:34:37 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA18336 for ; Tue, 11 Feb 1997 08:34:33 -0800 (PST) Received: from gateway.faroudja.com (root@[207.82.51.201]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA05777 for ; Tue, 11 Feb 1997 08:33:12 -0800 (PST) Received: from jamesl (jamesl.faroudja.com [207.82.51.132]) by gateway.faroudja.com (8.8.4/8.8.4) with SMTP id IAA05359; Tue, 11 Feb 1997 08:31:09 -0800 Message-ID: <33009EF9.1DE2 at faroudja.com> Date: Tue, 11 Feb 1997 08:31:53 -0800 From: James Lundblad Organization: Faroudja Laboratories Inc. X-Mailer: Mozilla 2.02 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Edward A. Lee" CC: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC References: <199702110430.UAA00810 at tycho. eecs berkeley edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Edward A. Lee wrote: > > James Lundblad writes: > >Edward A. Lee wrote: > >> > >> James Lundblad writes: > >> >I vote for a C++ code generation domain, since isn't compile-SDF speed > >> >limited by all the particle abstraction that makes it so flexible? > >> > >> The profile data we've seen leads me to believe that the speed > >> is limited by the particle queueing in the Geodesics. This could > >> be eliminated by statically allocating arrays for buffers, as done > >> in CGC. > >> > > > >So that would require modifications to the Porthole class and a > >flag passed via the connect method that says static arrays please? > >I guess you'd also need a flag in the compiled-SDF target to > >switch on this feature. How extensive do you think the additions > >would be to the Porthole/Geodesic code ( ie is it a localized > >change, or do all the decendant classes need modifying also )? > > Actually, my first cut approach would be an entirely new implementation > of the SDFPortHole classes. One advantage of compile-SDF is that you > get to choose what to link to. No need to link to existing Ptolemy > classes unless you need to. I suspect this would lead to the most > efficient implementation. I looked at SDFPorthole inheritance tree, GenericPort PortHole DFPortHole SDFPortHole Would it be best to write a new SDFPortHole that replaces the plasma processing with static arrays? A great deal is inherited from the parent classes, so I'm wondering where would be best to draw the line for a static array version of the SDF library. James ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 09:04:10 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id JAA18412 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 09:02:20 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA18406 for ; Tue, 11 Feb 1997 09:02:18 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA05852 for ; Tue, 11 Feb 1997 09:02:17 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA27550; Tue, 11 Feb 1997 09:02:14 -0800 (PST) From: Christopher Hylands Message-Id: <199702111702.JAA27550 at kahn. eecs berkeley edu> To: Neal Becker cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Java in Ptolemy (Was Re: libg++ in CGC) In-reply-to: Your message of 11 Feb 1997 07:37:14 -0500. Date: Tue, 11 Feb 1997 09:02:13 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Neal writes: -------- >>>>> "Christopher" == Christopher Hylands writes: Christopher> Personally, if another language code generation Christopher> domain were to be written, I'd rather see it Christopher> generate Java. Christopher> The benefits of Java are many over C++, I'm Christopher> especially interested in Christopher> threading and platform independence. I'm interested in Java, but what about efficiency? Also, are reliable java implementations as widely available as c++? g++ is free. What about java? -------- I'd like to avoid a large scale Java vs. Tcl vs. C++ war, but here are my thoughts. I'm a Java newbie, so take this with a grain of salt: 1) Currently Java is about 10 times slower than C. Tcl is 10 times slower than Java. 2) Currently, I think the Sun Java Development Kit (JDK) is basically free. Overtime, I think that there will be more and more JDK's. Microsoft's J++ is not the answer, it is a bit of a corruption of Java. Various freely available java runtime environments are in the works. 3) Java provides garbage collection, portability and threading. C++ does not easily provide all three of these, though there are various extensions. On the downside, Java is a language with training wheels, all the cool stuff like CLOS's meta object protocol and various cool OO C++ features are not present. I guess the idea was that these features caused more trouble than they were worth. Also, Java performance is slower than C++. However, C++ is usually slower than C, which is in turn slower than assembler, which is slower than . . . Basically, you need to pick your performance point, and instrument the various solutions. If you are turning to CGC or CGC++ for performance reasons, then it would seem that a CGJava application would be slower. As Java compiler technology improves, this gap will probably narrow. However, the Java app is more likely to be portable, than the CGC/CGC++ app. If threading is involved, then the C++ app will be nasty to port, and the Java app will 'just work'. -Christopher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 09:21:44 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id JAA18970 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 09:19:43 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA18964 for ; Tue, 11 Feb 1997 09:19:40 -0800 (PST) Received: from mail.DBresearch-berlin.de (ns.DBresearch-berlin.de [193.96.24.3]) by messier eecs berkeley edu (8.8.5/8.7.3) with SMTP id JAA13387 for ; Tue, 11 Feb 1997 09:19:35 -0800 (PST) Received: by mail.DBresearch-berlin.de (/\==/\ Smail3.1.28.1) from heinz with smtp id ; Tue, 11 Feb 97 18:17 MET Message-ID: <3300A9F4.167EB0E7@DBresearch-berlin.de> Date: Tue, 11 Feb 1997 18:18:44 +0100 From: Ali Botorabi X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: ptolemy-hackers at messier eecs berkeley edu CC: vhanx at messier eecs berkeley edu Subject: A Little Prolblem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello people, since some days, I'm trying to combine the POLIS generated .pl-files with PTOLEMY as described in Usere's Manual of Polis. At first, there were some problems, which I could solve. But now, I need your help. -Every time I want to compile a .pl-file to a Star in PTOLEMY I get the error message: " Error: Error linking file/tmp/__ptlinkxxx_x.so dlopen: ld.so.1: /$PTOLEMY/bin.$ARCH/pigiRpc: fatal:relocation error: symbol not found: _vt.DEPolis:referenced in /tmp/__ptlinkxxx_x.so " -where $PTOLEMY and $ARCH depend on the envirenment and xxx_x are numbers. Maybe, you have an idea, how I can solve this problem :-). Thanks a lot -- Daimler Benz AG Forschung Systemtechnik (F3S/R) fax: +49-30-399 82 107 Seyed-Ali Botorabi phone: +49-30-399 82 293 D-10559 Berlin mailto:botorabi@DBresearch-berlin.de ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 09:54:46 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id JAA19864 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 09:53:23 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA19857 for ; Tue, 11 Feb 1997 09:53:20 -0800 (PST) Received: from tycho. eecs berkeley edu (eal at localhost) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA06099; Tue, 11 Feb 1997 09:53:14 -0800 (PST) From: "Edward A. Lee" Message-Id: <199702111753.JAA06099 at tycho. eecs berkeley edu> X-Mailer: exmh version 1.6.5 12/11/95 To: James Lundblad cc: ptolemy-hackers at tycho. eecs berkeley edu Subject: Re: libg++ in CGC In-reply-to: Your message of Tue, 11 Feb 1997 08:31:53 -0800. <33009EF9.1DE2 at faroudja.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 1997 09:53:13 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk James Lundblad writes: >I looked at SDFPorthole inheritance tree, > > GenericPort > PortHole > DFPortHole > SDFPortHole > >Would it be best to write a new SDFPortHole that replaces the >plasma processing with static arrays? A great deal is inherited from >the parent classes, so I'm wondering where would be best to draw the >line for a static array version of the SDF library. Yes, I would write a new SDFPortHole. Probably need not inherit from the other classes. Another optimization that compile-SDF needs is to minimize what gets linked in. Currently, I think KnownBlock gets pulled in, despite not being needed, and with it, most of the kernel. A smaller executable will speed things up on some platforms. Edward ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 11:08:20 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id LAA20918 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 11:06:37 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from tycho. eecs berkeley edu (tycho. eecs berkeley edu [128.32.240.250]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA20912 for ; Tue, 11 Feb 1997 11:06:34 -0800 (PST) Received: from didier.ee.gatech.edu (didier.ee.gatech.edu [130.207.230.10]) by tycho. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA06450; Tue, 11 Feb 1997 11:06:32 -0800 (PST) Received: from duchess.ee.gatech.edu (duchess.ee.gatech.edu [130.207.230.13]) by didier.ee.gatech.edu (8.8.4/8.8.4) with ESMTP id OAA10650; Tue, 11 Feb 1997 14:05:42 -0500 (EST) Received: (from vkm at localhost) by duchess.ee.gatech.edu (8.8.4/8.8.4) id OAA18124; Tue, 11 Feb 1997 14:05:41 -0500 (EST) Message-Id: <199702111905.OAA18124 at duchess.ee.gatech.edu> From: Vijay Madisetti Date: Tue, 11 Feb 1997 14:05:41 -0500 USPS: 777 Atlantic Dr, ECE-Georgia Tech, Atlanta, GA 30332-0250 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ptolemy-hackers at tycho. eecs berkeley edu, ptolemy-users at tycho. eecs berkeley edu Subject: Java-based BEEHIVE Project at Georgia Tech - Comments invited Cc: messer at eecs berkeley edu, eal at eecs berkeley edu, vkm at mail.ee.gatech.edu Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi - Your comments on a Java-based Adaptive Signal Processing enviroment, BEEHIVE, we are developing as part of US Army and DARPA funding, are welcome. The focus is on embedded systems (e.g. including Mercury boards, etc within the portable environment). You can download the PS presentation (from ICASSP 97, Munich) at http://www.ee.gatech.edu/users/215/beehive.ps Rgds, Vijay Madisetti ==================================================================== BEEHIVE: A Distributed, Adaptive, Signal Processing Environment Vijay K. Madisetti, Shahram Famorzadeh, and Thomas Egolf Center for Signal and Image Processing Georgia Tech, Atlanta, GA 30332-0250 http://www.gcatt.gatech.edu Abstract We propose an $open$ signal processing system design and implementation environment, BEEHIVE, that allows application developers to rapidly compose and debug functional specifications in a networked, distributed computing environment, and then later migrate the application (transparently) onto an embedded distributed computing hardware/software platform, with the capability to reconfigure (adaptively) the resources assigned to the application to meet the dynamic real-time requirements of the implementation. Recent developments in the area of virtual machines, broker-based distributed transportable computing, object-oriented programming methodologies, Java and its real-time extensions, reconfigurable and programmable hardware, approximate algorithms, and adaptive load and resource management algorithms are harnessed in this operating environment. This research has been sponsored in part by U.S. Army Research Laboratory under Cooperative Agreement DAAL01-96-2-0001 (1996) and in part by DARPA. -- ------------------------------------------------------------------------ V. K. Madisetti /\ Associate Professor, / \ Electrical & Computer Engineering, TECH Georgia Tech, Atlanta, GA, USA 30332-0250 | | (404)894-4696, (404)894-4641(fax) | | vkm at ee.gatech.edu, http://www.ee.gatech.edu/users/215 ==== ------------------------------------------------------------------------ ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 11 12:22:11 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id LAA21625 for ptolemy-hackers-outgoing at brahe; Tue, 11 Feb 1997 11:54:05 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA21619 for ; Tue, 11 Feb 1997 11:54:02 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA02915; Tue, 11 Feb 1997 11:53:18 -0800 (PST) From: Christopher Hylands Message-Id: <199702111953.LAA02915 at kahn. eecs berkeley edu> To: Tom C cc: ptolemy-hackers at kahn. eecs berkeley edu Subject: Re: I the Ptolemy Star atlas available anywhere via FTP? In-reply-to: Your message of Mon, 10 Feb 1997 11:44:48 -0800. <32FF7AB0.763C@ix.netcom.com> Date: Tue, 11 Feb 1997 11:53:18 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Tom C writes: It has been a long time since I have "plugged" in to this newsgroup. As far as I remember, when Ptolemy 6.0 came out the old Star atlas, which was available from some foundation in Berkeley (the name of which escapes me right now), was no longer applicable. What is the current status of the Star Atlas? ----- There is no printed star atlas for 0.6. Basically, not that many people seemed to want it, and the document was getting to be too large to easily bind. In 0.7, the ptlang command has been modified so that it no longer generates troff docs, instead it generates html documentation for the stars. In 0.7, there will be a star index browser, as well as a star/demo cross reference tool. This should make it easy to browse via a html viewer. In 0.7, we have no plans on providing a printed version of the star atlas, there are basically too many stars. -Christopher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 12 03:38:07 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id DAA23906 for ptolemy-hackers-outgoing at brahe; Wed, 12 Feb 1997 03:03:06 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id DAA23900 for ; Wed, 12 Feb 1997 03:03:04 -0800 (PST) Received: from hotblack.ee.up.ac.za (hotblack.ee.up.ac.za [137.215.31.17]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id DAA16724 for ; Wed, 12 Feb 1997 03:02:42 -0800 (PST) Message-Id: <199702121102.DAA16724 at messier eecs berkeley edu> Received: by hotblack.ee.up.ac.za (1.39.111.2/16.2) id AA034035022; Wed, 12 Feb 1997 13:57:02 +0300 From: "W.H. Buttner" Subject: Compiling Stars Problem To: Ptolemy-Hackers at messier eecs berkeley edu Date: Wed, 12 Feb 1997 13:57:01 SADT X-Mailer: Elm [revision: 111.1] Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi I am trying to write my own stars. I have already compiled some of Neal's stars (thanks), and I have had no problems. Now I tried following the example in the ptolemy manuals. It recommends copying a star from the src/domains/sdf/stars/*.pl directory, more specifically the SDFSin.pl one. It also states that it should be renamed to another name, which I have also done. It doesn't say naything about changin anything inside the code of the file. On pressing * in the init.pal window, I put in the right directories and files, but when I say go, I get the following Error message : Error: Loader: /syferkom/users/butt-wh/OwnStars/SDFMyStar.cc still doesn't exist: check the file /syferkom/users/butt-wh/OwnStars/SDFMyStar.pl I also changed the name etc in the DEFSTAR segment of the *.pl file, but this only generates other problems. I get a huge dump of all kinds of problems and header files etc if I muck around there Any help will be kindly appreciated. Thanks Werner Buttner (University of Pretoria, South Africa) ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 12 08:16:26 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA24210 for ptolemy-hackers-outgoing at brahe; Wed, 12 Feb 1997 08:11:13 -0800 (PST) Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA24204 for ; Wed, 12 Feb 1997 08:11:10 -0800 (PST) Received: from umbc7.umbc.edu (reimer at f-umbc7.umbc.edu [130.85.3.7]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA17628 for ; Wed, 12 Feb 1997 08:11:04 -0800 (PST) Received: from localhost (reimer at localhost) by umbc7.umbc.edu (8.8.5/Umbc) with SMTP id LAA10871; Wed, 12 Feb 1997 11:10:53 -0500 (EST) X-Authentication-Warning: umbc7.umbc.edu: reimer owned process doing -bs Date: Wed, 12 Feb 1997 11:10:53 -0500 (EST) From: Wolfgang Reimer To: Edjair de Souza Mota cc: Ptolemy hackers list Subject: Re: Ptolemy and Linux In-Reply-To: <199702101605.RAA16120 at ftsu25.ee.TU-Berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk On Mon, 10 Feb 1997, Edjair de Souza Mota wrote: > Dear Mr. Reimer > > Last weekend I've tried to install Ptolemy under Linux. The term "Linux" isn't unique. Linux is now available for several Hardware platforms (x86, SPARC, ALPHA, PPC, m86k, ...) and there are different distributions in different versions. In order to help you most effective I need to know your hardware platform, the name of your Linux distribution and the version number. You should also mention if you changed or upgraded something in the distribution. > At first, I've > tried installing the 0.5.2 binaries, but as soon as problems came, I've > tried to install 0.6 binaries version. As 've tried to call pigi came > the following message : > > /users/ptolemy/bin./pigiRpc does not exist or is not executable > > Well, /users/ptolemy does exist but bin. don't !! I guess that the environment variable PTARCH (ARCH in case of version 0.5.x) wasn't set properly. When pigi is called it tries to start "pigiRpc" from the architecture dependent binary directory "$PTOLEMY/bin.$PTARCH/". You should explicitly set PTARCH and the other environment variables (see file INSTALL in ftp://ftp.tu-ilmenau.de/pub/unix/ptolemy/ptolemy0.6.linux/). > > Next, I've decided to install Ptolemy from scratch, but as I've called > pigi came the same message. This time I've looked at the file make.log > and there says in some instant : > > make[2]: *** No rule to make target `../../lib.linux/libptk.a', needed by 'pigiRpc'. Stop > > make[2]: Leaving directory '/users/ptolemy/obj.linux/pigiRpc' > > > > Could you please explain me why the procedure listed in the file INSTALL > doesn't make an executable pigiRpc ? Is there any hope ? My file INSTALL is valid only for original Slackware 3.0. I mentioned this somewhere at the top of the file. I guess that you have another distribution and/or version. I know that Ptolemy 0.6 was also successfully compiled under Slackware3.1, Redhat3.0.3, Redhat4.0 (all x86) and under MkLinux DR2 (PPC) with some restrictions. But to get it compiled, each of the above mentioned distributions and versions require certain changes in the system and/or the Ptolemy source code. BTW, I intend to port Ptolemy 0.7 for RedHat4.0 Linux (x86) and MkLinux (PPC). I will try to make this stuff available as rpm package which will ease the installation procedure a lot. For the release schedule have a look at the Ptolemy home page (http://ptolemy.eecs.berkeley.edu/). > > Bye > > > Edjair Mota > Regards, Wolfgang. -- Wolfgang Reimer (Dr.-Ing.) U.S. | G E R M A N Y Univ. of Maryland Baltimore County | Technical University of Ilmenau Department of Computer Science and | Department of Information Technology Electrical Engineering | and Electrical Engineering Computational Photonics Laboratory | Institute of Communication and of the Technology Research Center | Measurement Technology e-mail: reimer at umbc.edu | e-mail: reimer at e-technik.tu-ilmenau.de phone : (+1) 410-455-3318 | phone : (+49) 3677-69-2619 fax : (+1) 410-455-6500 | fax : (+49) 3677-69-1195 ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 12 08:42:19 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA24265 for ptolemy-hackers-outgoing at brahe; Wed, 12 Feb 1997 08:40:44 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA24259 for ; Wed, 12 Feb 1997 08:40:42 -0800 (PST) Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA17715 for ; Wed, 12 Feb 1997 08:40:38 -0800 (PST) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA07179; Wed, 12 Feb 1997 11:40:16 -0500 (EST) To: "W.H. Buttner" cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: Compiling Stars Problem In-reply-to: Your message of Wed, 12 Feb 1997 13:57:01 SADT <199702121102.DAA16724 at messier eecs berkeley edu> Date: Wed, 12 Feb 1997 11:40:16 -0500 Message-ID: <7177.855765616 at sss.pgh.pa.us> From: Tom Lane Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk > It recommends copying a star from the src/domains/sdf/stars/*.pl > directory, more specifically the SDFSin.pl one. It also states that it > should be renamed to another name, which I have also done. It doesn't > say naything about changin anything inside the code of the file. That's an oversight in the documentation. The star name and domain given in the text of the file *must* be right and must agree with the actual name of the .pl file. Also, it's a good idea to follow the same directory layout used by the main Ptolemy code: .../src/.../stars/ Star source code here .../src/.../icons/ Star icon gets put here .../obj.$(PTARCH)/.../stars/ Star .o gets built here You evidently haven't done this, and perhaps some parts of the system are getting confused about what's where. (I'd say that's a bug, if so, but it's a fairly probable kind of bug considering that *all* of the development work is done in directory trees that do follow this structure.) regards, tom lane ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 12 09:01:46 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA24311 for ptolemy-hackers-outgoing at brahe; Wed, 12 Feb 1997 08:51:56 -0800 (PST) Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA24306 for ; Wed, 12 Feb 1997 08:51:55 -0800 (PST) Received: from umbc7.umbc.edu (reimer at f-umbc7.umbc.edu [130.85.3.7]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA17750 for ; Wed, 12 Feb 1997 08:51:47 -0800 (PST) Received: from localhost (reimer at localhost) by umbc7.umbc.edu (8.8.5/Umbc) with SMTP id LAA19804; Wed, 12 Feb 1997 11:51:12 -0500 (EST) X-Authentication-Warning: umbc7.umbc.edu: reimer owned process doing -bs Date: Wed, 12 Feb 1997 11:51:11 -0500 (EST) From: Wolfgang Reimer To: Tom C cc: Ptolemy hackers list Subject: Re: Is Red-hat a good platform for Ptolemy? In-Reply-To: <33011EF5.2BCA@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk On Tue, 11 Feb 1997, Tom C wrote: > Wolfgang > > It has been a while since I have contacted you. I still appreciate all > of the advice that you and Joachim gave me on my initial installation. > > My question is this: I originally loaded Ptolemy on Slackware 3.0 (about > 6 months ago). Lets face it, I have a lot of other things to do besides > configure every little thing that I use and load, as is necessary with > Slackware. So, I was thinking about loading the Latest Red-Hat release > and taking advantage of their package loader. > > Do you run Ptolemy under Red Hat? Are there problems to watch out for? Yes, we are currently running Ptolemy under RedHat3.0.3 and RedHat4.0 (x86) and yes, there were also problems to solve. We switched to RedHat because it seems to have advantages over other Linux distributions (more mature and consistent, good package tool (rpm), support of different hardware, ...). > Would you advise against it? > > I remember how long it took me to get going in the past so I really do > not want to open a new can of worms for myself. If you would advise > against it I would take your advice. > I'm fairly busy at the moment and it wouldn't be worth to create notes for Ptolemy0.6 installation under other Linux distributions because I intend to port Ptolemy0.7 for RedHat4.0 Linux (x86) and MkLinux (PPC) soon. I will try to make this stuff available as rpm package which will ease the installation procedure a lot. For the release schedule have a look at the Ptolemy home page (http://ptolemy.eecs.berkeley.edu/). > Thanks > > Tom > > tcipollo at ix.netcom.com > Regards, Wolfgang. -- Wolfgang Reimer (Dr.-Ing.) U.S. | G E R M A N Y Univ. of Maryland Baltimore County | Technical University of Ilmenau Department of Computer Science and | Department of Information Technology Electrical Engineering | and Electrical Engineering Computational Photonics Laboratory | Institute of Communication and of the Technology Research Center | Measurement Technology e-mail: reimer at umbc.edu | e-mail: reimer at e-technik.tu-ilmenau.de phone : (+1) 410-455-3318 | phone : (+49) 3677-69-2619 fax : (+1) 410-455-6500 | fax : (+49) 3677-69-1195 ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 13 05:54:01 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id FAA28412 for ptolemy-hackers-outgoing at brahe; Thu, 13 Feb 1997 05:30:52 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id FAA28406 for ; Thu, 13 Feb 1997 05:30:23 -0800 (PST) Received: from rc4.vub.ac.be (root at rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id FAA21701 for ; Thu, 13 Feb 1997 05:30:09 -0800 (PST) Received: from is2e.vub.ac.be (root at is2e [134.184.15.6]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id OAA13809; Thu, 13 Feb 1997 14:28:59 +0100 Received: from pc32.iihe.ac.be by is2e.vub.ac.be (5.61/BFUCC-920211) id AA23907; Thu, 13 Feb 97 14:28:40 +0100 Message-Id: <33031781.51F291EF@ulb.ac.be> Date: Thu, 13 Feb 1997 14:30:41 +0100 From: Marc De Preter Organization: Universiti Libre de Bruxelles X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) Mime-Version: 1.0 To: Ptolemy Hackers Subject: Ptolemy on my linux box works (at least) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello hackers Finally, i got Ptolemy running on my computer. You (maybe) all remember my problems : i can't compile a simple star on my linux computer. Now it works. In fact, i removed everything, and reinstalled the sources from InfoMagic CD Roms December 1996. The compilation process didn't succeed (i got a lot of message while compiling itcl/itk, ... and i was using 'build_ptolemy' script). The pigiRpc wasn't even created :-{ So i installed the binary version found on the CD Roms (over the previous installation), and ... chazam, it worked fine. So, i will now be able to play around with ptolemy, and check for it's unseen power. Thanx to all who have helped me during this long journey into painfull installation :-) Marc "Two beer or not two beer, zat is ze question" Mr Megot, Young Spirou's Teacher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 14 00:42:12 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id AAA02491 for ptolemy-hackers-outgoing at brahe; Fri, 14 Feb 1997 00:33:08 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id AAA02485 for ; Fri, 14 Feb 1997 00:33:05 -0800 (PST) Received: from redwood.shu.ac.uk (pp at redwood.shu.ac.uk [143.52.2.24]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id AAA25381 for ; Fri, 14 Feb 1997 00:33:06 -0800 (PST) Received: from pine.shu.ac.uk by redwood.shu.ac.uk with inbound ESMTP (PP 8.1); Fri, 14 Feb 1997 08:32:58 +0000 Received: from sh-4215-005.csv.shu.ac.uk (sh-4215-005.csv.shu.ac.uk [143.52.48.25]) by pine.shu.ac.uk (8.8.4/8.8.4) with SMTP id IAA10437 for ; Fri, 14 Feb 1997 08:32:54 GMT Date: Fri, 14 Feb 1997 08:34:47 PST From: cstang Subject: PPM modulator & Demodulator To: ptolemy-hackers at messier eecs berkeley edu Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi there!! I wonder if anyone here have any experience in monte carlo simulation of PPM signals is relation to optical wireless channels simulation using ptolemy. Can anyone show me how I may model the PPM modulator using table and the MAP detector, which I believe will require some programming in ptlang. Any advice and assistance are welcome. Thank you.............. sincerely, cstang ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Fri Feb 14 21:14:48 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id VAA12048 for ptolemy-hackers-outgoing at brahe; Fri, 14 Feb 1997 21:10:29 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id VAA12042 for ; Fri, 14 Feb 1997 21:10:26 -0800 (PST) Received: from aquila.ece.utexas.edu (root at aquila.ece.utexas.edu [128.83.59.11]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id VAA28842 for ; Fri, 14 Feb 1997 21:10:23 -0800 (PST) Received: from brando.ece.utexas.edu (root at brando.ece.utexas.edu [128.83.59.201]) by aquila.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id XAA76216; Fri, 14 Feb 1997 23:11:48 -0600 Received: from brando.ece.utexas.edu (bevans at localhost [127.0.0.1]) by brando.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id XAA01518; Fri, 14 Feb 1997 23:11:24 -0600 (CST) Message-Id: <199702150511.XAA01518 at brando.ece.utexas.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: cstang cc: bevans at ece.utexas.edu, ptolemy-hackers at messier eecs berkeley edu Subject: Re: PPM modulator & Demodulator In-reply-to: Your message of "Fri, 14 Feb 1997 08:34:47 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 1997 23:11:22 -0600 From: Brian Evans Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk > I wonder if anyone here have any experience in monte > carlo simulation of PPM signals is relation to optical > wireless channels simulation using ptolemy. Under the SDF/Communications demonstrations, there are several demos of PAM and QAM systems. There is also a demonstration of a phase-locked loop for tracking laser phaser noise. > Can anyone show me how I may model the PPM modulator > using table and the MAP detector, which I believe will > require some programming in ptlang. PPM should be easy enough. You are simply splitting a pulse period into orthogonal smaller pulses. The only detail is that you have to discretize the entire system. So, each modulated pulse would be N samples long. We already have pulse shapers (e.g. the Raised Cosine and the Square Root Raised Cosine) already built in. We also have a variety of detectors in the SDF/Communications demos. You might find the Exercises in Section 5.5 of the User's Manual particularly useful. The User's Manual is completely on-line at http://ptolemy.eecs.berkeley.edu/papers/almagest/user.html Regards, Brian -- Prof. Brian L. Evans, Dept. of ECE Voice: (512) 232-1457 Engineering Science Building Fax: (512) 471-5907 The University of Texas at Austin E-mail: bevans at ece.utexas.edu Austin, TX 78712-1084 USA Web: http://www.ece.utexas.edu/~bevans ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Sat Feb 15 11:03:07 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id KAA15030 for ptolemy-hackers-outgoing at brahe; Sat, 15 Feb 1997 10:58:09 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id KAA15024 for ; Sat, 15 Feb 1997 10:58:05 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.5/8.7.3) with SMTP id KAA24874 for ; Sat, 15 Feb 1997 10:58:04 -0800 (PST) Received: from neal.ctd.comsat.com (neal.ctd.comsat.com [134.133.40.21]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with SMTP id KAA28825 for ; Sat, 15 Feb 1997 10:58:01 -0800 Received: from neal by neal.ctd.comsat.com with local (Exim 1.58 #2) id 0vvpIx-0000vE-00; Sat, 15 Feb 1997 13:57:47 -0500 To: ptolemy-hackers at eecs berkeley edu Subject: 2 core dumps on linux Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: multipart/mixed; boundary="Multipart_Sat_Feb_15_13:57:46_1997-1" Content-Transfer-Encoding: 7bit From: Neal Becker Date: 15 Feb 1997 13:57:46 -0500 Message-ID: Lines: 300 X-Mailer: Gnus v5.2.40/XEmacs 20.0 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk --Multipart_Sat_Feb_15_13:57:46_1997-1 Content-Type: text/plain; charset=US-ASCII When trying to run a universe I got a segfault. This happened both with SDF default and with SDF-compile. I don't know if these two problems are the same or not. Here's the first: --Multipart_Sat_Feb_15_13:57:46_1997-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="dump.dat" Content-Transfer-Encoding: 7bit #0 0x407d627c in __libc_malloc (bytes=1081426600) #1 0x80 in ?? () #2 0x81427bc in ___builtin_vec_new (sz=128) #3 0x407479b9 in default_alloc (size=128) at /users/src/libg++/libio/strstream.cc:36 #4 0x4074827e in strstreambuf::init_dynamic (this=0x827103c, alloc=0, free=0, initial_size=128) at /users/src/libg++/libio/strstream.cc:136 #5 0x40747acb in istrstream::istrstream (this=0x8271038, __in_chrg=1, cp=0x8247d38 "SPS", n=3) at /users/src/libg++/libio/strstream.h:52 #6 0x811951c in Tokenizer::Tokenizer (this=0xbfffb388, buffer=0x8247d38 "SPS", spec=0x8146778 "*+-/^()!", w=0x80f79e9 "\215EÄVWPèd") at ../../src/kernel/Tokenizer.cc:105 #7 0x80f79e9 in IntState::initialize (this=0x8659718) at ../../src/kernel/IntState.cc:81 #8 0x810b089 in NamedObjList::initElements (this=0x865f7b0) at ../../src/kernel/NamedObj.cc:100 #9 0x80e12c1 in Block::initialize (this=0x865f788) at ../../src/kernel/Block.cc:156 #10 0x80f9ed2 in InterpGalaxy::initialize (this=0x865f788) at ../../src/kernel/InterpGalaxy.cc:788 #11 0x80f355c in Galaxy::initSubblocks (this=0x8665358) at ../../src/kernel/Galaxy.cc:148 #12 0x80fa09d in InterpGalaxy::initialize (this=0x8665358) - at ../../src/kernel/InterpGalaxy.cc:847 #13 0x40599c24 in SDFScheduler::prepareGalaxy (this=0x8660a28) at ../../../../src/domains/sdf/kernel/SDFScheduler.cc:184 #14 0x40599b01 in SDFScheduler::setup (this=0x8660a28) at ../../../../src/domains/sdf/kernel/SDFScheduler.cc:147 #15 0x81186d2 in Target::schedulerSetup (this=0x8275678) at ../../src/kernel/Target.cc:174 #16 0x81184a1 in Target::setup (this=0x8275678) at ../../src/kernel/Target.cc:122 #17 0x40587638 in LoopTarget::setup (this=0x8275678) at ../../../../src/domains/sdf/loopScheduler/LoopTarget.cc:80 #18 0x80e1321 in Block::initialize (this=0x8275678) at ../../src/kernel/Block.cc:159 #19 0x8119fa9 in Runnable::initTarget (this=0x86653cc) at ../../src/kernel/Universe.cc:63 #20 0x80fa3d8 in InterpUniverse::initTarget (this=0x8665358) at ../../src/kernel/InterpUniverse.cc:99 #21 0x406da0e3 in PTcl::computeSchedule (this=0x81ccd98) at ../../src/ptcl/PTcl.cc:434 #22 0x406da447 in PTcl::run (this=0x81ccd98, argc=2, argv=0xbfffb8ec) at ../../src/ptcl/PTcl.cc:516 #23 0x406dbab5 in PTcl::dispatcher (which=0x27, interp=0x81a8a38, argc=2, argv=0xbfffb8ec) at ../../src/ptcl/PTcl.cc:1248 #24 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbfffbd89 "run 100000000", cmdEnd=0xbfffbd96 "", argc=2, argv=0xbfffb8ec) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #25 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbfffbd89 "run 100000000") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #26 0x81275e3 in Tcl_EvalCmd (dummy=0x0, interp=0x81a8a38, argc=2, argv=0xbfffbd48) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdAH.c:394 #27 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x826f3b6 "eval $script\n ", cmdEnd=0x826f3c2 "\n ", argc=2, argv=0xbfffbd48) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #28 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x826f3b4 "\n\teval $script\n ") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #29 0x81281a0 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=4, argv=0xbfffc170) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:146 #30 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x821fb7c "if $ptkTimeFlag {\n\tset elapsedTime [time {\n\t eval $script\n\t} 1]\n\tset timeInSec [expr [lindex $elapsedTime 0]/1000000.0]\n\tptkMessage \"The run of [curuniverse] took $timeInSec seconds not including "..., cmdEnd=0x821fc72 "\n", argc=4, argv=0xbfffc170) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #31 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x821fb60 "\n global ptkTimeFlag\n if $ptkTimeFlag {\n\tset elapsedTime [time {\n\t eval $script\n\t} 1]\n\tset timeInSec [expr [lindex $elapsedTime 0]/1000000.0]\n\tptkMessage \"The run of [curuniverse] took $time"...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #32 0x8131f2e in TclInterpProc (clientData=0x821fb48, interp=0x81a8a38, argc=0, argv=0xbfffc660) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclProc.c:587 #33 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x8665ce8 "ptkCondTime \"run $numIter\"\n\n \t if {[info exists ptkRunFlag($name)] &&\n \t $ptkRunFlag($name) != {ABORT}} { wrapup } {\n \t # Mark an error if the system was aborted\n \t "..., cmdEnd=0x8665d02 "\n\n \t if {[info exists ptkRunFlag($name)] &&\n \t $ptkRunFlag($name) != {ABORT}} { wrapup } {\n \t # Mark an error if the system was aborted\n \t set ptkRunFlag($name) ERR"..., argc=2, argv=0xbfffc660) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #34 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x8665c2c "\n\t # default run: just run through the specified number\n\t # of iterations, finishing by invoking\n\t # wrapup if no error occurr --Multipart_Sat_Feb_15_13:57:46_1997-1 Content-Type: text/plain; charset=US-ASCII Here's the second: --Multipart_Sat_Feb_15_13:57:46_1997-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="dump2.dat" Content-Transfer-Encoding: 7bit #0 0x8114ca6 in StringList::StringList (this=0xbfffb3c0, s=0x0) at ../../src/kernel/StringList.cc:99 #1 0x403edc5d in SymbolStack::pop (this=0x824e2e8) at ../../../../src/domains/cg/kernel/SymbolList.cc:113 #2 0x403e0f72 in HLLTarget::beginIteration (this=0x824e210, repetitions=2928, depth=1) at ../../../../src/domains/cg/kernel/HLLTarget.cc:64 #3 0x4059f029 in SDFClusterBag::genCode (this=0x82920b0, t=@0x824e210, depth=1) at ../../../../src/domains/sdf/kernel/SDFCluster.cc:1229 #4 0x4059f118 in SDFBagScheduler::genCode (this=0x829de18, t=@0x824e210, depth=1) at ../../../../src/domains/sdf/kernel/SDFCluster.cc:1246 #5 0x4059f04d in SDFClusterBag::genCode (this=0x829ded0, t=@0x824e210, depth=1) at ../../../../src/domains/sdf/kernel/SDFCluster.cc:1232 #6 0x4058443e in LoopScheduler::compileRun (this=0x823a928) at ../../../../src/domains/sdf/loopScheduler/LoopScheduler.cc:131 #7 0x8087f3d in CompileTarget::run (this=0x824e210) at ../../../../src/domains/sdf/targets/CompileTarget.cc:202 #8 0x8119fdd in Runnable::run (this=0x824df54) at ../../src/kernel/Universe.cc:68 #9 0x80fa154 in InterpUniverse::run (this=0x824dee0) at ../../src/kernel/InterpUniverse.h:68 #10 0x406da487 in PTcl::run (this=0x81ccdc0, argc=2, argv=0xbfffb8ec) at ../../src/ptcl/PTcl.cc:521 #11 0x406dbab5 in PTcl::dispatcher (which=0x27, interp=0x81a8a38, argc=2, argv=0xbfffb8ec) at ../../src/ptcl/PTcl.cc:1248 #12 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbfffbd89 "run 100000", cmdEnd=0xbfffbd93 "", argc=2, argv=0xbfffb8ec) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #13 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbfffbd89 "run 100000") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #14 0x81275e3 in Tcl_EvalCmd (dummy=0x0, interp=0x81a8a38, argc=2, argv=0xbfffbd48) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdAH.c:394 #15 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x825b916 "eval $script\n ", cmdEnd=0x825b922 "\n ", argc=2, argv=0xbfffbd48) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #16 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x825b914 "\n\teval $script\n ") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #17 0x81281a0 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=4, argv=0xbfffc170) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:146 #18 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x821fba4 "if $ptkTimeFlag {\n\tset elapsedTime [time {\n\t eval $script\n\t} 1]\n\tset timeInSec [expr [lindex $elapsedTime 0]/1000000.0]\n\tptkMessage \"The run of [curuniverse] took $timeInSec seconds not including "..., cmdEnd=0x821fc9a "\n", argc=4, argv=0xbfffc170) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #19 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x821fb88 "\n global ptkTimeFlag\n if $ptkTimeFlag {\n\tset elapsedTime [time {\n\t eval $script\n\t} 1]\n\tset timeInSec [expr [lindex $elapsedTime 0]/1000000.0]\n\tptkMessage \"The run of [curuniverse] took $time"...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #20 0x8131f2e in TclInterpProc (clientData=0x821fb70, interp=0x81a8a38, argc=0, argv=0xbfffc660) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclProc.c:587 #21 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x825c090 "ptkCondTime \"run $numIter\"\n\n \t if {[info exists ptkRunFlag($name)] &&\n \t $ptkRunFlag($name) != {ABORT}} { wrapup } {\n \t # Mark an error if the system was aborted\n \t "..., cmdEnd=0x825c0aa "\n\n \t if {[info exists ptkRunFlag($name)] &&\n \t $ptkRunFlag($name) != {ABORT}} { wrapup } {\n \t # Mark an error if the system was aborted\n \t set ptkRunFlag($name) ERR"..., argc=2, argv=0xbfffc660) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #22 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x825bfd4 "\n\t # default run: just run through the specified number\n\t # of iterations, finishing by invoking\n\t # wrapup if no error occurred.\n", ' ' , "set numIter [$w.iter.entry get]\n\t ptkCondTime "...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #23 0x81281a0 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=4, argv=0xbfffca88) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:146 #24 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x825c85d "if { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have to\n\t # get the contents of the text window, and then get\n\t # the TCL interpreter to evaluate it\n\t ptkSetStrin"..., cmdEnd=0x825cb68 "\n\n # we have finished running\n\tptkClearRunFlag $name $octHandle\n ", argc=4, argv=0xbfffca88) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #25 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x825c7ee "\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have to\n\t "...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #26 0x8127446 in Tcl_CatchCmd (dummy=0x0, interp=0x81a8a38, argc=3, argv=0xbfffceac) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdAH.c:237 #27 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x825c1a4 "catch {\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have "..., cmdEnd=0x825c575 "] == 1", argc=3, argv=0xbfffceac) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #28 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x825c1a4 "catch {\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have "...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #29 0x812cf3b in ExprLex (interp=0x81a8a38, infoPtr=0xbfffd0d8, valuePtr=0xbfffd104) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclExpr.c:516 #30 0x812d22b in ExprGetValue (interp=0x81a8a38, infoPtr=0xbfffd0d8, prec=-1, valuePtr=0xbfffd104) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclExpr.c:741 #31 0x812ddda in ExprTopLevel (interp=0x81a8a38, string=0x825c1a3 "[catch {\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have"..., valuePtr=0xbfffd104) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclExpr.c:1378 #32 0x812dfbf in Tcl_ExprBoolean (interp=0x81a8a38, string=0x825c1a3 "[catch {\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we have"..., ptr=0xbfffd1e4) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclExpr.c:1485 #33 0x81280b9 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=3, argv=0xbfffd4e8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:98 #34 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x8220442 "if {[catch {\n curuniverse $name\n ptkCompile $octHandle\n set w .run_$octHandle\n\n\tglobal ptkScriptOn \n\n\tif { $ptkScriptOn($name) } {\n\t # we want to run the script. This means we "..., cmdEnd=0x822089d "\n", argc=3, argv=0xbfffd4e8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #35 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x821fd28 "\n global ptkRunFlag ptkRunEventLoop\n\n # For now, we allow only one run at a time.\n set univ [curuniverse]\n if {[info exists ptkRunFlag($univ)] && ([regexp {^ACTIVE$|^STOP_PENDING$|^ABORT$"...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #36 0x8131f2e in TclInterpProc (clientData=0x821fd10, interp=0x81a8a38, argc=0, argv=0xbfffd9d8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclProc.c:587 #37 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbfffdb34 "ptkGo testACI6 OctObj0000185b", cmdEnd=0xbfffdb51 "", argc=3, argv=0xbfffd9d8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #38 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbfffdb34 "ptkGo testACI6 OctObj0000185b") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #39 0x8127113 in Tcl_GlobalEval (interp=0x81a8a38, command=0xbfffdb34 "ptkGo testACI6 OctObj0000185b") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1675 #40 0x80d415c in TkCopyAndGlobalEval (interp=0x81a8a38, script=0x824f3c8 "ptkGo testACI6 OctObj0000185b") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkBind.c:2370 #41 0x80a2342 in InvokeButton (butPtr=0x823ed28) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkButton.c:1672 #42 0x80a1008 in ButtonWidgetCmd (clientData=0x823ed28, interp=0x81a8a38, argc=2, argv=0xbfffdf2c) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkButton.c:732 #43 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbfffe3df "::.run_OctObj0000185b.panel.gofr.go invoke", cmdEnd=0xbfffe409 "", argc=2, argv=0xbfffdf2c) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #44 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbfffe3df "::.run_OctObj0000185b.panel.gofr.go invoke") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #45 0x8131a24 in Tcl_UplevelCmd (dummy=0x0, interp=0x81a8a38, argc=3, argv=0xbfffe398) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclProc.c:257 #46 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbfffe843 "uplevel #0 [list $q invoke]\n\t", cmdEnd=0xbfffe85e "\n\t", argc=3, argv=0xbfffe398) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #47 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbfffe83d "\n\t uplevel #0 [list $q invoke]\n\t") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #48 0x81281a0 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=3, argv=0xbfffe7c0) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:146 #49 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x824d0e9 "if {($w == $tkPriv(window))\n\t\t&& ([$q cget -state] != \"disabled\")} {\n\t uplevel #0 [list $q invoke]\n\t}\n ", cmdEnd=0x824d151 "\n ", argc=3, argv=0xbfffe7c0) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #50 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x824d0a7 "\n\tset tkPriv(buttonWindow) \"\"\n\t$q config -relief $tkPriv(relief)\n\tif {($w == $tkPriv(window))\n\t\t&& ([$q cget -state] != \"disabled\")} {\n\t uplevel #0 [list $q invoke]\n\t}\n ") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #51 0x81281a0 in Tcl_IfCmd (dummy=0x0, interp=0x81a8a38, argc=3, argv=0xbfffebe8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclCmdIL.c:146 #52 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0x81ee394 "if {$w == $tkPriv(buttonWindow)} {\n\tset tkPriv(buttonWindow) \"\"\n\t$q config -relief $tkPriv(relief)\n\tif {($w == $tkPriv(window))\n\t\t&& ([$q cget -state] != \"disabled\")} {\n\t uplevel #0 [list $q invoke"..., cmdEnd=0x81ee466 "\n", argc=3, argv=0xbfffebe8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #53 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0x81ee360 "\n global tkPriv\n set q [winfo command $w]\n if {$w == $tkPriv(buttonWindow)} {\n\tset tkPriv(buttonWindow) \"\"\n\t$q config -relief $tkPriv(relief)\n\tif {($w == $tkPriv(window))\n\t\t&& ([$q cget -stat"...) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #54 0x8131f2e in TclInterpProc (clientData=0x81ee2e0, interp=0x81a8a38, argc=0, argv=0xbffff0d8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclProc.c:587 #55 0x813a539 in Itcl_EvalArgs (interp=0x81a8a38, cmdStart=0xbffff325 "tkButtonUp .run_OctObj0000185b.panel.gofr.go\n", cmdEnd=0xbffff351 "\n", argc=2, argv=0xbffff0d8) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/itcl_namesp.c:1666 #56 0x8126ca3 in Tcl_Eval (interp=0x81a8a38, cmd=0xbffff320 "\n tkButtonUp .run_OctObj0000185b.panel.gofr.go\n") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1300 #57 0x8127113 in Tcl_GlobalEval (interp=0x81a8a38, command=0xbffff320 "\n tkButtonUp .run_OctObj0000185b.panel.gofr.go\n") at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tcl7.4/tclBasic.c:1675 #58 0x80d2e3c in Tk_BindEvent (bindingTable=0x81c5020, eventPtr=0xbffff51c, tkwin=0x8242e30, numObjects=0, objectPtr=0xbffff42c) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkBind.c:1160 #59 0x8092a10 in TkBindEventProc (winPtr=0x8242e30, eventPtr=0xbffff51c) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkCmds.c:240 #60 0x80a03fc in Tk_HandleEvent (eventPtr=0xbffff51c) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkXEvent.c:655 #61 0x80a05a9 in TkXFileProc (clientData=0x81ae0a0, mask=1, flags=30) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkXEvent.c:799 #62 0x8095c51 in Tk_DoOneEvent (flags=30) at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkEvent.c:694 #63 0x80a0603 in Tk_MainLoop () at /usr/local/src/ptolemy/src/tcltk/itcl2.0/tk4.0/tkXEvent.c:864 #64 0x405dd891 in ptkMainLoop () at ../../src/pigilib/ptkTkSetup.c:192 #65 0x8082d47 in main (argc=10, argv=0xbffff604) at ../../src/pigiRpc/pigiMain.cc:77 #66 0x8082c5b in _start () --Multipart_Sat_Feb_15_13:57:46_1997-1-- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 17 06:48:54 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id GAA22128 for ptolemy-hackers-outgoing at brahe; Mon, 17 Feb 1997 06:29:07 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id GAA22122 for ; Mon, 17 Feb 1997 06:29:03 -0800 (PST) Received: from hotblack.ee.up.ac.za (hotblack.ee.up.ac.za [137.215.31.17]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id GAA07771 for ; Mon, 17 Feb 1997 06:28:57 -0800 (PST) Message-Id: <199702171428.GAA07771 at messier eecs berkeley edu> Received: by hotblack.ee.up.ac.za (1.39.111.2/16.2) id AA060089725; Mon, 17 Feb 1997 17:28:45 +0300 From: "W.H. Buttner" Subject: Compiling stars : I've had it To: ptolemy-hackers at messier eecs berkeley edu Date: Mon, 17 Feb 1997 17:28:45 SADT X-Mailer: Elm [revision: 111.1] Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi :-( I have basically had it. Any .pl file I get from other people (Thanks Neal) compiles just fine. If I change the name of the star, and edit the name in the file itself, the trouble starts. I get errors like : star not known, trying to load it. g++ errors etc. Please can someone help. It can't be that the libraries and directories are not set up correctly. Other .pl files do compile. I have killed my brain trying to puzzle out why a change in filename confuses the sh.. out of ptolemy. Thanks Werner Buttner (Department of Electronic Engineering, University of Pretoria, South Africa) ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 17 10:40:12 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id KAA24235 for ptolemy-hackers-outgoing at brahe; Mon, 17 Feb 1997 10:07:29 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id KAA24229 for ; Mon, 17 Feb 1997 10:07:26 -0800 (PST) Received: from brahe eecs berkeley edu (brahe. eecs berkeley edu [128.32.240.59]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id KAA08357 for ; Mon, 17 Feb 1997 10:07:24 -0800 (PST) Received: from localhost (sunil at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) with SMTP id KAA23748; Mon, 17 Feb 1997 10:00:47 -0800 (PST) Date: Mon, 17 Feb 1997 10:00:47 -0800 (PST) From: Sunil Bhave To: "W.H. Buttner" cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: Compiling stars : I've had it In-Reply-To: <199702171428.GAA07771 at messier eecs berkeley edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi Werner, When you rename the star, and name a new star .pl file for it, that itself wont create a new star in the palette. You have to go through the following steps: 1. create a new .pl file with the new name of the star in it. 2. edit the make.template file in the stars directory and add the name of the new star to that list. 3. do a 'make install' in the obj directory 4. then run pigi, and go to the appropiate palette that you want to put the icon for the star in. 5. then use the 'make star' (@) command to create a new icon for your new star (give the appropiate path). if you want to edit the icon for the new star,(or copy the icon from the old star), please go through the 1st and 2nd chapters of the ptolemy users manual. Hope that helps, Sunil. On Mon, 17 Feb 1997, W.H. Buttner wrote: > > Hi :-( > > I have basically had it. Any .pl file I get from other people (Thanks Neal) > compiles just fine. If I change the name of the star, and edit the name in the > file itself, the trouble starts. I get errors like : star not known, trying to > load it. g++ errors etc. > > Please can someone help. It can't be that the libraries and directories are not > set up correctly. Other .pl files do compile. > > I have killed my brain trying to puzzle out why a change in filename confuses > the sh.. out of ptolemy. > > Thanks > > Werner Buttner > > (Department of Electronic Engineering, University of Pretoria, South Africa) > > > > ---------------------------------------------------------------------------- > Posted to the ptolemy-hackers mailing list. Please send administrative > mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 17 17:29:58 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id RAA26100 for ptolemy-hackers-outgoing at brahe; Mon, 17 Feb 1997 17:24:04 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id RAA26094 for ; Mon, 17 Feb 1997 17:24:01 -0800 (PST) Received: from gw.dcs.shef.ac.uk (gw.dcs.shef.ac.uk [143.167.8.2]) by messier eecs berkeley edu (8.8.5/8.7.3) with SMTP id RAA09807 for ; Mon, 17 Feb 1997 17:23:58 -0800 (PST) Received: from ur.dcs.shef.ac.uk by gw.dcs.shef.ac.uk (4.1/DCS2.0) id AA09068; Tue, 18 Feb 97 01:23:49 GMT Received: by ur.dcs.shef.ac.uk (SMI-8.6/1.2-sol) id BAA29882; Tue, 18 Feb 1997 01:23:49 GMT Date: Tue, 18 Feb 1997 01:23:49 +0000 (GMT) From: Polychronis Tzerefos To: "W.H. Buttner" Cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: Compiling stars : I've had it In-Reply-To: <199702171428.GAA07771 at messier eecs berkeley edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk On Mon, 17 Feb 1997, W.H. Buttner wrote: > > Hi :-( > > I have basically had it. Any .pl file I get from other people (Thanks Neal) > compiles just fine. If I change the name of the star, and edit the name in the > file itself, the trouble starts. I get errors like : star not known, trying to > load it. g++ errors etc. > > Please can someone help. It can't be that the libraries and directories are not > set up correctly. Other .pl files do compile. > > I have killed my brain trying to puzzle out why a change in filename confuses > the sh.. out of ptolemy. > > Thanks > > Werner Buttner > > (Department of Electronic Engineering, University of Pretoria, South Africa) > A thing that I think you should look is to actually change the name of the file within the code of the star when renaming the file. Chronis ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Mon Feb 17 23:44:37 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id XAA29886 for ptolemy-hackers-outgoing at brahe; Mon, 17 Feb 1997 23:41:42 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id XAA29880 for ; Mon, 17 Feb 1997 23:41:39 -0800 (PST) Received: from merkur.dbft.daimlerbenz.com (firewall-user at merkur.daimlerbenz.com [53.122.1.21]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id XAA11034 for ; Mon, 17 Feb 1997 23:41:35 -0800 (PST) Received: (from uucp at localhost) by merkur.dbft.daimlerbenz.com (8.7.1/8.7.1) id IAA01341 for ; Tue, 18 Feb 1997 08:45:55 +0100 (MET) Received: from sophie-scholl.dbag.ulm.daimlerbenz.com(53.16.8.3) by merkur.dbft.daimlerbenz.com via smap (g3.0.3) id xma001332; Tue, 18 Feb 97 08:45:28 +0100 Received: from kkserver.dbag.ulm.DaimlerBenz.COM by sophie-scholl.dbag.ulm.DaimlerBenz.COM (5.x/SMI-SVR4-15.1.1997) id AA13259; Tue, 18 Feb 1997 08:41:07 +0100 Received: from frodo.kk_Gruppe by kkserver.dbag.ulm.DaimlerBenz.COM (SMI-8.6/SMI-SVR4-17.1.1997) id IAA06084; Tue, 18 Feb 1997 08:40:20 +0100 From: michael.wolf at dbag.ulm.DaimlerBenz.COM (Michael Wolf) Received: by frodo.kk_Gruppe (SMI-8.6/SMI-SVR4-10.4.1995) id IAA17340; Tue, 18 Feb 1997 08:38:07 +0100 Date: Tue, 18 Feb 1997 08:38:07 +0100 Message-Id: <199702180738.IAA17340 at frodo.kk_Gruppe> To: ptolemy-hackers at messier eecs berkeley edu Subject: mkPtolemyTree problem X-Sun-Charset: US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello Ptolemy hackers, I'm using Ptolemy under Solaris2.5 and want to create my own Ptolemy tree with mkPtolemyTree: Everything went well until the linker tried to create the shared libs while builing ptcl, PigiRPC and tycho in my customized tree. I got a whole bunch of messages like this: 0x58 /opt/SUNWspro/SC4.0/lib/libm.a(__rem_pio2m.o) 0x48 /opt/SUNWspro/SC4.0/lib/libm.a(__rem_pio2m.o) 0x18 /opt/SUNWspro/SC4.0/lib/libm.a(__tan.o) 0x14 /opt/SUNWspro/SC4.0/lib/libm.a(__tan.o) ld: fatal: relocations remain against allocatable but non-writable sections make[2]: *** [libtysh.so] Error 1 make[1]: *** [install] Error 2 make[1]: *** No rule to make target `../../lib.sol2/libptcl.so', needed by `pigiRpc'. Stop. and so on... What could be the reason for this behavior??? Many thanks Michael ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 18 09:00:46 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA00735 for ptolemy-hackers-outgoing at brahe; Tue, 18 Feb 1997 08:58:27 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA00729 for ; Tue, 18 Feb 1997 08:58:24 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA12556 for ; Tue, 18 Feb 1997 08:58:22 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA01555; Tue, 18 Feb 1997 08:58:12 -0800 (PST) From: Christopher Hylands Message-Id: <199702181658.IAA01555 at kahn. eecs berkeley edu> To: michael.wolf at dbag.ulm.DaimlerBenz.COM (Michael Wolf) cc: ptolemy-hackers at messier eecs berkeley edu Subject: Re: mkPtolemyTree problem In-reply-to: Your message of Tue, 18 Feb 1997 08:38:07 +0100. <199702180738.IAA17340 at frodo.kk_Gruppe> Date: Tue, 18 Feb 1997 08:58:12 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Michael Wolf writes: -------- I'm using Ptolemy under Solaris2.5 and want to create my own Ptolemy tree with mkPtolemyTree: Everything went well until the linker tried to create the shared libs while builing ptcl, PigiRPC and tycho in my customized tree. I got a whole bunch of messages like this: 0x58 /opt/SUNWspro/SC4.0/lib /libm.a(__rem_pio2m.o) 0x48 /opt/SUNWspro/SC4.0/lib /libm.a(__rem_pio2m.o) 0x18 /opt/SUNWspro/SC4.0/lib /libm.a(__tan.o) 0x14 /opt/SUNWspro/SC4.0/lib /libm.a(__tan.o) ld: fatal: relocations remain against allocatable but non-writable sections make[2]: *** [libtysh.so] Error 1 make[1]: *** [install] Error 2 make[1]: *** No rule to make target `../../lib.sol2/libptcl.so', needed by `pigiRpc'. Stop. ------ The binaries that we ship were built with solari2.4 gcc, not SunSoft CC. The libm library in the error message is a SunSoft CC library, so perhaps you are running SunSoft CC instead of g++? One way to tell is to pass your C++ compiler the -v option: SunSoft CC would look like: Usage: CC [ options ] files. Use 'CC -flags' for details g++: /users/ptolemy/bin.sol2/gcc -v Reading specs from /users/ptolemy/gnu/sol2/lib/gcc-lib/sparc-sun-solaris2.4/2.7.2/specs gcc version 2.7.2 If you would like to use SunSoft CC, set your PTARCH to sol2.cfront. You will also need to rebuild the libraries from scratch, as SunSoft CC libraries and GNU g++ libraries have problems interacting. You might be able to do this by using mkPtolemyTree and then doing a make clean, but you may need to just rebuild from scratch. mkPtolemyTree has several bugs, see the programmer's guide for details. If you are building with g++, then the compiler should not be looking inside the SunSoft CC directory tree, perhaps your LD_LIBRARY_PATH variable is set to include the SunSoft CC directory tree The troubleshooting guide lists some hints about how to fix missing symbol problems. The troubleshooting guide is part of Appendix A of the Ptolemy User's Manual and it is available via the web at http://ptolemy.eecs.berkeley.edu/users_man0.6.html/troubleshooting.doc1.html -Christopher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 18 13:46:59 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id NAA03174 for ptolemy-hackers-outgoing at brahe; Tue, 18 Feb 1997 13:39:06 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id NAA03168 for ; Tue, 18 Feb 1997 13:39:04 -0800 (PST) Received: from belmonte.gtts.ssr.upm.es (belmonte.gtts.ssr.upm.es [138.4.35.2]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id NAA13576 for ; Tue, 18 Feb 1997 13:38:57 -0800 (PST) Received: from lagartijo.gtts.ssr.upm.es ([138.4.35.3]) by belmonte.gtts.ssr.upm.es (Netscape Mail Server v2.02) with ESMTP id AAA26997 for ; Tue, 18 Feb 1997 22:37:56 +0100 Received: from lagartijo ([127.0.0.1]) by lagartijo.gtts.ssr.upm.es (Netscape Mail Server v2.02) with SMTP id AAA19206 for ; Tue, 18 Feb 1997 22:37:48 +0100 Message-ID: <330A2129.73AB@gtts.ssr.upm.es> Date: Tue, 18 Feb 1997 22:37:45 +0100 From: <> X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: compiling problems adress Subject: problems building my one matrix star Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Dear helpers, I want to create a matrix star with the following characteristics: I have 3 input float matrices and 1 float output matrix. I want to declare another 8 float matrices who are declared and initialized with 0 at the begining of the simulation only once. I want to create a 3 dimen- sional Array for my one star and, like the matrices, initialized it at the begining of the simulation. In the go method I want to chance the entries of the matrices with the access like a 2 dimensional array [][]. The 3 dimension array [][][] has to have accessed like an real 3 dimensional array and not emulate him to an 1 dimensional array. Well I have intended to program this, following the examples matrices in the sdf domain, but without success. Some compiler problems are: "assignment to 'FloatMatrix *' from 'double' ", when I want to initialize the FloatMatrix with 0.0 like nameofmatrix = 0.0. "invalid operands 'double' and 'double *' to binary 'operator *' ", while I intend to multiply 2 matrix entries [][]. So please, if it is possible, send me a message with your proposal. Thanks a lot and academic reguards from here (University of Madrid) <> ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 18 15:10:13 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id PAA03374 for ptolemy-hackers-outgoing at brahe; Tue, 18 Feb 1997 15:08:53 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id PAA03368 for ; Tue, 18 Feb 1997 15:08:49 -0800 (PST) Received: from aquila.ece.utexas.edu (root at aquila.ece.utexas.edu [128.83.59.11]) by mho eecs berkeley edu (8.8.5/8.7.3) with ESMTP id PAA18260 for ; Tue, 18 Feb 1997 15:08:47 -0800 (PST) Received: from brando.ece.utexas.edu (root at brando.ece.utexas.edu [128.83.59.201]) by aquila.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id RAA73872; Tue, 18 Feb 1997 17:10:19 -0600 Received: from brando.ece.utexas.edu (bevans at localhost [127.0.0.1]) by brando.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id RAA29756; Tue, 18 Feb 1997 17:09:55 -0600 (CST) Message-Id: <199702182309.RAA29756 at brando.ece.utexas.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: <> cc: bevans at ece.utexas.edu, ptolemy-hackers at mho eecs berkeley edu Subject: Re: problems building my one matrix star In-reply-to: Your message of "Tue, 18 Feb 1997 22:37:45 +0100." <330A2129.73AB@gtts.ssr.upm.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Feb 1997 17:09:53 -0600 From: Brian Evans Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk <> > I want to create a matrix star with the following characteristics: > I have 3 input float matrices and 1 float output matrix The SDFMpy_M.pl star is a great place to star. It is the directory $PTOLEMY/src/domains/sdf/matrix/stars. The SDFMpy_M star has two matrix inputs and one matrix output. One trick in the go method is to make sure that you intercept null matrices on the input ports, as done by SDFMpy_M.pl. Null matrices are produced by delays. > I want to declare another 8 float matrices who are declared and > initialized with 0 at the begining of the simulation only once. An alternate implementation is to put a delay icon on the output of the star and set the delay to be 8 (or a parameter to be more general). The delay will produce 8 empty matrices at the beginning of the simulation. > I want to create a 3 dimensional Array for my one star and, like the > matrices, initialized it at the begining of the simulation. You could allocate an array of Matrices to get the three dimensions. I would allocate the 3-D array in the setup method. The matrix class has a variety of constructors, e.g. FloatMatrix f(5,5); allocates a 5x5 array, and f = 0.0; will set all of the elements of matrix f to zero. You can see this by looking at Matrix.h and Matrix.cc in the $PTOLEMY/src/kernel directory. > Well I have intended to program this, following the examples matrices in > the sdf domain, but without success. Some compiler problems are: > "assignment to 'FloatMatrix *' from 'double' ", when I want to > initialize the FloatMatrix with 0.0 like nameofmatrix = 0.0. > "invalid operands 'double' and 'double *' to binary 'operator *' ", > while I intend to multiply 2 matrix entries [][]. Multiplication is a built into the Matrix classes. For example, FloatMatrix m1(5,5); FloatMatrix m2(5,5); FloatMatrix m3(5,5); m1 = 1; m2 = 2; m3 = m1 * m2; // slower method for computing m1 * m2 multiply(m1,m2,m3); // faster method for computing m1 * m2 should work just fine. The * operator for matrices is defined in Matrix.h and Matrix.cc in the $PTOLEMY/src/kernel directory. It would be helpful if you listed the lines of code that cause the error/warning messages with the error/warning messages. It is difficult to guess what's gone wrong. Can you post the code and messages together? Regards, Brian -- Prof. Brian L. Evans, Dept. of ECE Voice: (512) 232-1457 Engineering Science Building Fax: (512) 471-5907 The University of Texas at Austin E-mail: bevans at ece.utexas.edu Austin, TX 78712-1084 USA Web: http://www.ece.utexas.edu/~bevans ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 19 00:51:05 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id AAA06579 for ptolemy-hackers-outgoing at brahe; Wed, 19 Feb 1997 00:46:46 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id AAA06573 for ; Wed, 19 Feb 1997 00:46:43 -0800 (PST) Received: from vmprofs.estec.esa.nl (vmprofs.estec.esa.nl [131.176.7.11]) by messier eecs berkeley edu (8.8.5/8.7.3) with SMTP id AAA15576 for ; Wed, 19 Feb 1997 00:46:41 -0800 (PST) Message-Id: <199702190846.AAA15576 at messier eecs berkeley edu> Received: from ESTEC by vmprofs.estec.esa.nl (IBM VM SMTP V2R2) with BSMTP id 2799; Wed, 19 Feb 97 09:46:38 CET Comments: Converted from PROFS to RFC822 format by PUMP V2.2X Date: Wed, 19 Feb 97 09:46:37 CET From: To: ptolemy list Subject: Partitioning and DMM domain. Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk *** Resending note of 97-02-19 09:39 Hi everyone! I'm looking for a tool to do HW/SW partitioning within the Ptolemy environment ( if it exists ). I was also interested in the Design Methodology Management domain ( DMM ). I've read in a thesis work about this domain that supports Design Space Exploration but I couldn't found it in the Ptolemy 0.6 environ- ment. Could anybody help me ??? Thanks in advance, Alberto. (ESA, Spacecraft Attitude and Orbit Control Section) amedina at wk.estec.esa.nl End of Message ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 19 11:51:50 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id LAA09743 for ptolemy-hackers-outgoing at brahe; Wed, 19 Feb 1997 11:48:41 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA09738 for ; Wed, 19 Feb 1997 11:48:39 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA17742 for ; Wed, 19 Feb 1997 11:48:36 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA24868; Wed, 19 Feb 1997 11:48:17 -0800 (PST) From: Christopher Hylands Message-Id: <199702191948.LAA24868 at kahn. eecs berkeley edu> To: JMEDINA@estec.esa.nl cc: ptolemy list Subject: Re: Partitioning and DMM domain. In-reply-to: Your message of Wed, 19 Feb 1997 09:46:37 +0700. <199702190846.AAA15576 at messier eecs berkeley edu> Date: Wed, 19 Feb 1997 11:48:17 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk The Design Methodolgy Management (DMM) domain never made it into a releasable form. The SDF Design Flow Management stars provide some of the functionality in DMM. However there are only a few DFM stars and there are only a few demos. The Thor domain in Ptolemy0.5.2 did some HW/SW partitioning, however, the Thor domain is not in 0.6, 0.5.2 was the last release for Thor. The VHDL domain in 0.6 does a form of HW/SW partitioning. You might try searching the Ptolemy publications at http://ptolemy.eecs.berkeley.edu for keywords like 'codesign' -Christopher -------- *** Resending note of 97-02-19 09:39 Hi everyone! I'm looking for a tool to do HW/SW partitioning within the Ptolemy environm ent ( if it exists ). I was also interested in the Design Methodology Managemen t domain ( DMM ). I've read in a thesis work about this domain that supports Design Space Exploration but I couldn't found it in the Ptolemy 0.6 environ - ment. Could anybody help me ??? Thanks in advance, Alberto. (ESA, Spacecraft Attitude and Orbit Control Section) amedina at wk.estec.esa.nl End of Message --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Tue Feb 25 12:38:13 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id MAA16511 for ptolemy-hackers-outgoing at brahe; Tue, 25 Feb 1997 12:31:11 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from cooley. eecs berkeley edu (cooley. eecs berkeley edu [128.32.240.170]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id MAA16505 for ; Tue, 25 Feb 1997 12:31:08 -0800 (PST) Received: from localhost (bilung at localhost) by cooley. eecs berkeley edu (8.8.5/8.7.3) with SMTP id MAA21677 for ; Tue, 25 Feb 1997 12:31:06 -0800 (PST) Date: Tue, 25 Feb 1997 12:31:05 -0800 (PST) From: Bilung Lee Reply-To: Bilung Lee To: ptolemy-hackers at cooley. eecs berkeley edu Subject: Re: Info. on the FSM in Tycho In-Reply-To: <199702251843.KAA05202 at price. eecs berkeley edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk The state transition diagram editor is mainly designed for the FSM domain in Ptolemy. There is a document briefly describing how to use the editor. You can find the document at http://ptolemy.eecs.berkeley.edu/~bilung/research/FSM/fsm.html Bilung > From: Timoleon Rabazoylas > Subject: Info. on the FSM in Tycho > Date: Tue, 25 Feb 1997 13:08:56 +0200 > > Hello, > > I have seen that there is an FSM editor in Tycho but there in no > documentation on it. > > How can it be used and where I can get more info. about it? > > Thanking you in advance, > Timoleon Ravazoulas > > ------- End of Forwarded Message > > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 07:40:38 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id HAA20888 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 07:32:16 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from dewitt. eecs berkeley edu (dewitt. eecs berkeley edu [128.32.240.53]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id HAA20882 for ; Wed, 26 Feb 1997 07:32:12 -0800 (PST) Received: from elod.vein.hu (elod.vein.hu [193.6.32.101]) by dewitt. eecs berkeley edu (8.8.5/8.7.3) with SMTP id HAA17238 for ; Wed, 26 Feb 1997 07:32:02 -0800 (PST) Received: by elod.vein.hu (5.65/DEC-Ultrix/4.3) id AA08409; Wed, 26 Feb 1997 16:34:37 +0100 Received: by almos.vein.hu (5.x/SMI-SVR4) id AA29393; Wed, 26 Feb 1997 16:32:18 +0100 Date: Wed, 26 Feb 1997 16:32:17 +0100 (MET) From: Gogos Barnabas To: Ptolemy Hackers Subject: unresolved symbol Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi! I have just started to work with Ptolemy and I have some problems with some self-written stars. This is an ATM simulator and I need it very much. The simulator itself successfully recompiled and linked but after that I started the new pigi and tryed to start the simulation I got the fallowing message in the VEM window: Unknown star 'ATMSwitch4' in domain DE, trying to load it... Debug: cd /users/ptolemy/atmsim; make DEATMSwitch4.o >& /tmp/pt5e49.0001 Error: Error linking file /tmp/__ptlink24137_2.so: dlopen: Unable to resolve symbol I do not know that why it searchs the "ATMSwitch4" and other stars which have been compiled and linked in the pigiRpc and which symbol was missing from this /tmp/__ptlink24137_2.so file. Please _h_e_l_p_ me. Thank you. Regards, Barnabas Gogos [gogos at almos.vein.hu] ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 08:47:17 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA21140 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 08:42:42 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA21134 for ; Wed, 26 Feb 1997 08:42:38 -0800 (PST) Received: from aquila.ece.utexas.edu (root at aquila.ece.utexas.edu [128.83.59.11]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA16496 for ; Wed, 26 Feb 1997 08:42:33 -0800 (PST) Received: from brando.ece.utexas.edu (root at brando.ece.utexas.edu [128.83.59.201]) by aquila.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id KAA74754; Wed, 26 Feb 1997 10:44:05 -0600 Received: from brando.ece.utexas.edu (bevans at localhost [127.0.0.1]) by brando.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id KAA09856; Wed, 26 Feb 1997 10:44:00 -0600 (CST) Message-Id: <199702261644.KAA09856 at brando.ece.utexas.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: Vivek Telang cc: bevans at ece.utexas.edu, ptolemy-hackers at messier eecs berkeley edu Subject: Re: Ptolemy/MATLAB question In-reply-to: Your message of "Wed, 26 Feb 1997 09:25:46 CST." <199702261525.AA13842 at cserve1.crystal.cirrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Feb 1997 10:43:57 -0600 From: Brian Evans Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Vivek, > I've created a simulation that includes a MATLAB_M star. Unfortunately, > when I run the simulation, it fires up MATLAB, gives me the MATLAB > command terminal window, and just sits there. What's wrong? This behavior is due to a bug in the Solaris version of the Matlab external interface library in Matlab 4. The bug is that Matlab assumes that it is running attached to a terminal. It issues stty and ioctrl commands to the terminal, which causes the Solaris interface to hang (I tracked down the error using truss). I reported the bug to MathWorks about 1 1/2 years ago. I hope that it is fixed in Matlab 5. There are two workarounds: 1. Run Ptolemy in the foreground for the interface. That is, use pigi instead of pigi & OR 2. Manually start the Matlab interface using the textual 'console' interface to Ptolemy. The console interface can be started by using the -console option: pigi -console The syntax of the console window is Tcl. The console window will appear green. In the console window, type matlab start As side benefit of doing it this way is that Matlab will always remain running until you type matlab end in the console AND no demos using the Matlab interface are running. If you run a Matlab demo and leave the run control panel running, then you can run another Matlab demo and Ptolemy will not restart Matlab. The reason is that Ptolemy terminates the Matlab process if Ptolemy is no longer using it. When you close all of the run control panels of Matlab demonstrations, Ptolemy realizes that no demonstrations need the connection to Matlab and therefore terminate the connection. > Also, is there a resource that answers these types of questions? I > couldn't find anything in the user manual. We have an on-line Troubleshooting guide located on the Ptolemy Web pages at http://ptolemy.eecs.berkeley.edu/papers/almagest/appendixA.html Or click on 'Releases' on the home page and then 'Troubleshooting Guide'. We update it regularly. You can also search the Ptolemy e-mail message database from the ptolemy-hackers at ptolemy eecs berkeley edu, which also contains postings to the comp.soft-sys.ptolemy news group, at http://ptolemy.eecs.berkeley.edu/cgi-bin/ptolemy-hackers-wais.pl Or click on 'Mailing Lists' on the home page then scroll down and click on 'Indirect WAIS index of ptolemy-hackers'. There is also a Frequently Asked Questions on the Web and FTP sites. I am glad to see that Crystal Semiconductor is finding Ptolemy useful in system design. Regards, Brian P.S. If you only need the SDF and DE domains in a simulation, then you can run 'pigi -ptiny' which will only load the SDF and DE domains, thereby reducing the resources the program consumes. Another option is 'pigi -ptrim' which defines the simulation domains (except PN) and the CGC domain. -- Prof. Brian L. Evans, Dept. of ECE Voice: (512) 232-1457 Engineering Science Building Fax: (512) 471-5907 The University of Texas at Austin E-mail: bevans at ece.utexas.edu Austin, TX 78712-1084 USA Web: http://www.ece.utexas.edu/~bevans ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 09:39:36 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id JAA21945 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 09:36:34 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA21939 for ; Wed, 26 Feb 1997 09:36:31 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA27738; Wed, 26 Feb 1997 09:36:24 -0800 (PST) From: Christopher Hylands Message-Id: <199702261736.JAA27738 at kahn. eecs berkeley edu> To: Kostas Oikonomou cc: ptolemy-hackers at kahn. eecs berkeley edu Subject: Re: Restarting pigiRpc from Vem In-reply-to: Your message of Wed, 26 Feb 1997 11:57:54 -0500. <9702261657.AA02431 at spark.ho.att.com.spark> Date: Wed, 26 Feb 1997 09:36:23 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Kostas Oikonomou writes: -------- I'm working on a Ptolemy facet that keeps killing pigiRpc. I recall seeing somewhere a way to restart it from the vem window. But I can't find it any where in the manual. I tried using "pigiRpc":r in the vem window, but the ``r'' is not recognized. Vem thinks it is recover-facet or redraw-window. ----- I've heard that this can be done, but I've never actually seen it done. I poked around in the archives, but nothing obvious popped up. Has anyone on ptolemy-hackers done this? My guess is that the tricky part would be passing the proper arguments -Christopher ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 11:16:52 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id LAA23894 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 11:12:36 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA23889 for ; Wed, 26 Feb 1997 11:12:16 -0800 (PST) Received: from edison. eecs berkeley edu (edison. eecs berkeley edu [128.32.240.183]) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id LAA02439 for ; Wed, 26 Feb 1997 11:12:13 -0800 (PST) Received: (from cameron at localhost) by edison. eecs berkeley edu (8.8.5/8.7.3) id LAA01855; Wed, 26 Feb 1997 11:12:09 -0800 (PST) Date: Wed, 26 Feb 1997 11:12:09 -0800 (PST) From: Mike Williamson Message-Id: <199702261912.LAA01855 at edison. eecs berkeley edu> To: cxh at eecs berkeley edu, ko at surya.ho.att.com Subject: Re: Restarting pigiRpc from Vem Cc: ptolemy-hackers at kahn. eecs berkeley edu Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I just looked at this again for the first time in a while. I've seldom used it myself, though. I found documentation on it in the User's Manual: file:/users/ptdesign/public_html/Ptolemy/papers/almagest/user.html where I used the hypertext form with a searchable index, searching for "rpc". Under: http://ptolemy.eecs.berkeley.edu/users_man0.6.html/vem.doc10.html >>>>> 16.10 Remote application commands rpc-any r "host pathname" This command starts up a remote application which is not on the standard list of applications in the vem menu. "host" specifies the network location for the application and "path" specifies the path to the executable on "host". If the host specification is omitted, the local machine is assumed. >>>>> I also found the following two index entries, one of which is the one I showed you above, I believe: rpc-any command 2-11 rpc-any, VEM 16-22 Now here's the thing, I manually killed off pigiRpc while running on my system, and tried this command, and something unusual happened: When I type "pigiRpc":r in the VEM window, then hit return, it offers me two possible completions: recover-facet redraw-window which is what you noted in your mail. But when I go down to my schematic window, with the same characters on the VEM command line, and hit return, I am offered: re-read recover-facet redraw-window rpc-any rpc-reset rr-nc A much wider range of choices, including the one I am truly interested in. I'm not sure why this is so, but this is the first time I've noticed that command sensitivity is different in the VEM window vs. in a schematic window. Also, you might have easier use by using the accelerator in the schematic window. Under the schematic menu (), the bottom submenu is "Application", under which is "r rpc-any". So rpc-any is the command, and "r" is the accelerator key. Type "pigiRpc" (or your favorite path name) in the VEM or schematic window, then hit "r" in the schematic window (no colon between is necessary) and you get same effect as manually typing "pigiRpc":rpc-any in the schematic window. I still don't know why the VEM window doesn't recognize the rpc-any command. Anyone else have an idea about this? -Mike >>>>> Kostas Oikonomou writes: -------- I'm working on a Ptolemy facet that keeps killing pigiRpc. I recall seeing somewhere a way to restart it from the vem window. But I can't find it any where in the manual. I tried using "pigiRpc":r in the vem window, but the ``r'' is not recognized. Vem thinks it is recover-facet or redraw-window. ----- I've heard that this can be done, but I've never actually seen it done. I poked around in the archives, but nothing obvious popped up. Has anyone on ptolemy-hackers done this? My guess is that the tricky part would be passing the proper arguments -Christopher >>>>> ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 13:15:01 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id NAA24496 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 13:11:17 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id NAA24490 for ; Wed, 26 Feb 1997 13:11:14 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.5/8.7.3) with SMTP id NAA04081 for ; Wed, 26 Feb 1997 13:11:13 -0800 (PST) Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id NAA16948 for ; Wed, 26 Feb 1997 13:11:10 -0800 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id QAA19196 for ; Wed, 26 Feb 1997 16:10:24 -0500 (EST) To: ptolemy-hackers at eecs berkeley edu Subject: DEPortHole bug with repeated runs Date: Wed, 26 Feb 1997 16:10:23 -0500 Message-ID: <19193.856991423 at sss.pgh.pa.us> From: Tom Lane Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I just discovered that DE-domain portholes don't work quite right when a universe is run repeatedly without being rebuilt from scratch. (That is easy to do in ptcl; in pigi you need a run control window script to make it happen.) The problem is that a porthole's dataNew flag doesn't get reset if it was set at the end of the prior run. This can result in a star mistakenly believing that there is data on an input port during its first firing. I believe that dataNew should be reset during initialize(), not during setPort() as the code presently does. setPort is typically invoked only during star construction. Porthole initialize() is called at the right time, namely during scheduler setup for each run. I also moved the resetting of timeStamp and depth into initialize(). It seems clear that failing to reset these during a new run is also wrong (although the depth mistake would only bite you if you had changed some connections since the prior run). As far as I can see, there's no good reason for DEPortHole to override setPort at all. Considering that setPort is not virtual, trying to override it is very dangerous anyway (the wrong method will be called if one is using a generic PortHole pointer to reference the porthole). I've tested the attached patch and it seems to work properly. Note that it requires recompiling pretty much all of domain DE. regards, tom lane *** DEPortHole.h~ Thu Mar 2 23:20:58 1995 --- DEPortHole.h Wed Feb 26 14:53:11 1997 *************** *** 68,77 **** DEPortHole(); ~DEPortHole(); ! // The setPort function is redefined to set DE-specific members. ! PortHole& setPort(const char* portName, ! Block* parent, ! DataType type = FLOAT); // DEPortHole has a "timeStamp" attribute. double timeStamp; --- 68,75 ---- DEPortHole(); ~DEPortHole(); ! // The initialize function is redefined to set DE-specific members. ! void initialize(); // DEPortHole has a "timeStamp" attribute. double timeStamp; *** DEPortHole.cc~ Thu Mar 2 23:20:42 1995 --- DEPortHole.cc Wed Feb 26 14:53:27 1997 *************** *** 64,83 **** // (does nothing extra, but avoids out-of-line versions from cfront) DEPortHole :: ~DEPortHole() {} ! PortHole& DEPortHole :: setPort ( ! const char* s, ! Block* parent, ! DataType t) { // Initialize PortHole ! PortHole::setPort(s,parent,t); // Initialize the DE-specific members timeStamp = 0.0; dataNew = FALSE; depth = -1; - - return *this; } Particle& InDEPort :: get() --- 64,79 ---- // (does nothing extra, but avoids out-of-line versions from cfront) DEPortHole :: ~DEPortHole() {} ! // The initialize function is redefined to set DE-specific members. ! void DEPortHole :: initialize() { // Initialize PortHole ! PortHole::initialize(); // Initialize the DE-specific members timeStamp = 0.0; dataNew = FALSE; depth = -1; } Particle& InDEPort :: get() ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Wed Feb 26 20:49:46 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id UAA26036 for ptolemy-hackers-outgoing at brahe; Wed, 26 Feb 1997 20:48:43 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id UAA26030 for ; Wed, 26 Feb 1997 20:48:40 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.5/8.7.3) with SMTP id UAA08933 for ; Wed, 26 Feb 1997 20:48:39 -0800 (PST) Received: from hkpu04.polyu.edu.hk ([158.132.18.4]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id UAA22672 for ; Wed, 26 Feb 1997 20:48:36 -0800 Received: from 158.132.18.1.polyu.edu.hk by hkpu04.polyu.edu.hk (SMI-8.6/SMI-4.1) id MAA17227; Thu, 27 Feb 1997 12:51:37 +0800 Message-Id: <3.0.32.19970227124851.006b284c at hkpucc.polyu.edu.hk> X-Sender: 95980425R@hkpucc.polyu.edu.hk X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Feb 1997 12:48:52 +0800 To: ptolemy-hackers at eecs berkeley edu From: Gary Chu Kar Kit Subject: Create my own version! Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hi, I try to create my own version of Ptolemy with my own stars. When I try to use: make pigiRpc. I got the error messages as follow: g++ -fPIC -O2 -Wall -Wsynth -g -DPTSOL2_4 -D_REENTRANT -pipe -fno-for-scope -I. -c pigiMain.cc make: *** No rule to make target `../domains/cgc/tcltk/targets/CGCTclTkTarget.o', needed by `pigiRpc'. Stop. Whats happen on this? Thanks for your information! ********************************************** out,out,out,out* Chu Kar Kit, GARY * * Office: (852)-27666135 * * E-mail: eekkchu at ee.polyu.edu.hk * ********************************************** ('v') ('v') ('v') ('v') (( )) (( )) (( )) (( )) -/-"---"---/-"---"---/-"---"---/-"---"-- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 27 06:37:56 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id GAA27220 for ptolemy-hackers-outgoing at brahe; Thu, 27 Feb 1997 06:31:24 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id GAA27214 for ; Thu, 27 Feb 1997 06:31:20 -0800 (PST) Received: from rc4.vub.ac.be (rc4.vub.ac.be [134.184.15.4]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id GAA20808 for ; Thu, 27 Feb 1997 06:31:07 -0800 (PST) Received: from vnet3.vub.ac.be (vnet3.vub.ac.be [134.184.15.13]) by rc4.vub.ac.be (8.6.10/3.12.0.ap (rc4.test)) id PAA22631; Thu, 27 Feb 1997 15:30:42 +0100 Received: from ELECPC12 by vnet3.vub.ac.be (SMI-8.6/SMI-SVR4) id PAA26990; Thu, 27 Feb 1997 15:30:12 +0100 Date: Thu, 27 Feb 1997 15:30:12 +0100 Message-Id: <199702271430.PAA26990 at vnet3.vub.ac.be> X-Sender: esteenpu at vnet3.vub.ac.be X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ptolemy-hackers at messier eecs berkeley edu From: esteenpu at vnet3.vub.ac.be (Eli Steenput) Subject: a question on dataflow (not strictly Ptolemy) Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Hello Ptolemy hackers, I am not a Ptolemy user, but I have a question related to dataflow programs that maybe someone on the list could help me with. Please excuse me for mailing on an off topic subject. ***************************************************** I am doing some research on different evaluation schemes for dataflow systems, for use in a measurement system development environment. In a measurement environment, the user will repeatedly change some of the measurement settings and will want to view the results. We want to insure that the user will always get the result that conforms to his latest settings (data consistency). If only a few of the settings are modified each time, it is unreasonable to repeat operations that do not depend on the changed settings, because the operations in complex measurement systems can be very time-consuming. Note that I am not speaking of a dsp situation. In a conventional program, the coding to ensure consistency relies on data dependency information that changes with each program modification. It would be preferable that the measurement system development environment automatically ensures the data consistency in a structured way. This leads us to dataflow based environments. We also want to avoid redundant operations without programmer intervention. For this I study intelligent buffering of intermediate results. Suppose (somewhat artificial example): some operations | | [a]----[ ]-----[ ]--- ______ \____| | | C |----- ... /----|______| [b]----[ ]-----[ ]--- \ input objects Suppose a and b are some settings and the user has run this before. Now he wishes to change the value of a and run it again. In data-driven dataflow, object b must generate a data container too or c will never execute. So the lengthy (suppose) measurements and calculations between b and c are executed, although they produce the same value as before since the value of b did not change. Existing environments assume a single run of the dataflow program for each set of input values. In that case, data consistency is not an issue. Assume each arc has an associated buffer that stores the value of the last passing data token. The input terminal or executing node that places a data token on the arc could compare the new value with the previous one on the arc. It could add a tag to the token if the value did not change. A node that has on its input arcs only such tagged tokens, does not have to execute, just re-issue the same data token it sent out before, also with an 'unchanged' tag. I will try to render an example I worked on lately, a program to measure the tff of a device under test. (signal type) | (number samples) | ______|______ | | | | | [CREATE SIGNAL] | | | (fsample) | | __|__ | | | | | | | [SET GENERATOR] | | | [SETUP] | <-links between set nodes and measure are for | | synchronisation only (Device Under Test) | | <- this input can force new measurement | | | when the DUT is changed --------------[ MEASURE ] | | (beta) | | | | | <-some windowing parameter |---------------|---[WINDOW] | | | -----------[WINDOW] | | | (type of tff) | | | [FFT] [FFT] | | | | | | ---------------[TFF 1 or 2] <- can choose from 2 ways to calculate tff | from the fft's | (result) Note that, if for example the signal type changes, the setup does not need to be repeated. If a new device is attached, the measurement is repeated, but not the operations above. If the window parameter or the type of tff calculation change, no new measurement is necessary. Admittedly the i/o operations are conveniently grouped, and I have thus far made no attempt to apply our scheme to the actual interaction with the instrument. I have attempted to duplicate the effects of our scheme as a LabView program, by enclosing the whole thing in a loop. Comparing the inputs with the previous values drives a number of nested case structures that either calculate part of the graph or reuse the previous iterations value. This resulted in a big spaghetti. And I ('the developer') was forced to figure out a partitioning of the graph depending on dependency information that is already implicit in the dataflow. So if one really wants to do this optimisation, leaving it to the environment seems preferable. ***************************************************** I am interested in hearing from people who know of, or might be doing, similar things with dataflow. I would also appreciate any comments on the idea from people on the list! At the moment I'm trying some sort of formal analysis of the gains that could be achieved by using buffered results, and thinking of some benchmark simulations. Determining a measure for the performance increase achievable by the scheme and the overhead it generates is difficult, because these aspects will not only depend on the properties of the dataflow graphs, but also on the unpredictable sequence of user interactions. Only a very limited number of typical sample algorithms and no representative sets of user interaction profiles are available to us. Would someone have a suggestion for the performance measurement or analysis? Many thanks, Eli Steenput Vrije Universiteit Brussel (VUB) TW/ELEC Pleinlaan 2 email: esteenpu at vnet3.vub.ac.be B-1050 Brussel Phone: +(32 2) 629 28 44 Belgium Fax: +(32 2) 629 28 50 ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 27 08:11:23 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA27594 for ptolemy-hackers-outgoing at brahe; Thu, 27 Feb 1997 08:01:49 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA27588 for ; Thu, 27 Feb 1997 08:01:46 -0800 (PST) Received: from spsem02.sps.mot.com (spsem02.sps.mot.com [192.70.231.5]) by messier eecs berkeley edu (8.8.5/8.7.3) with SMTP id IAA21096 for ; Thu, 27 Feb 1997 08:01:43 -0800 (PST) Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA00750 for ptolemy-hackers at ptolemy eecs berkeley edu; Thu, 27 Feb 97 09:01:41 MST Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA10412 for ptolemy-hackers at ptolemy eecs berkeley edu; Thu, 27 Feb 97 09:01:40 MST Received: from velvet.msil.sps.mot.com (velvet [223.44.95.9]) by msil.sps.mot.com (8.8.5/8.8.0) with ESMTP id SAA04395 for ; Thu, 27 Feb 1997 18:01:46 +0200 (IST) From: Tamir Simantov Received: (from tamirs at localhost) by velvet.msil.sps.mot.com (8.8.5/8.8.3) id SAA12745 for ptolemy-hackers at ptolemy eecs berkeley edu; Thu, 27 Feb 1997 18:01:48 +0200 (GMT+0200) Date: Thu, 27 Feb 1997 18:01:48 +0200 (GMT+0200) Message-Id: <199702271601.SAA12745 at velvet.msil.sps.mot.com> To: ptolemy-hackers at messier eecs berkeley edu Content-Type: X-sun-attachment Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 10 I've been using ptolemy for some time and first of all, I wanne send you all a big compliment for the powerfull tool you've designed. I'm using the discrete event domain for simulations of communication processes. My colleagues and I have bulit, a module which simulates a part of a communication processor. I'm still improving it but I have a problem : The universe contains some galaxies (which contains galaxies) and is rather complicated. When I tries to compile the facet , ptolemy starts compling the "small" galaxies , and then compiles the higher stages. Everything goes fine till here, and I'm getting messages like : "Debug:CompileUniv:facet=...." in the vem window. When ptolemy gets to the most higher level, the facet that I tries to compile, IT JUST GET STACK THERE, AND STARTS "SWALLOWING" the memory of the station I'm working in, until it breaks down. No ERROR message is prodoced , (for example message Like "Bad Net Deleted" , or "FREE DELAY LOOP" which I can handle). I tried to work on a bigger station with enlarged memory but it didn't help. I wanne emphasis that ptolemy compiles the galaxies inside the facet with great success. I hope you will be able to help me ... ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: ptolemy.27.2.97 X-Sun-Content-Lines: 10 I've been using ptolemy for some time and first of all, I wanne send you all a big compliment for the powerfull tool you've designed. I'm using the discrete event domain for simulations of communication processes. My colleagues and I have bulit, a module which simulates a part of a communication processor. I'm still improving it but I have a problem : The universe contains some galaxies (which contains galaxies) and is rather complicated. When I tries to compile the facet , ptolemy starts compling the "small" galaxies , and then compiles the higher stages. Everything goes fine till here, and I'm getting messages like : "Debug:CompileUniv:facet=...." in the vem window. When ptolemy gets to the most higher level, the facet that I tries to compile, IT JUST GET STACK THERE, AND STARTS "SWALLOWING" the memory of the station I'm working in, until it breaks down. No ERROR message is prodoced , (for example message Like "Bad Net Deleted" , or "FREE DELAY LOOP" which I can handle). I tried to work on a bigger station with enlarged memory but it didn't help. I wanne emphasis that ptolemy compiles the galaxies inside the facet with great success. I hope you will be able to help me ... ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 27 08:23:18 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id IAA27633 for ptolemy-hackers-outgoing at brahe; Thu, 27 Feb 1997 08:16:39 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA27627 for ; Thu, 27 Feb 1997 08:16:36 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id IAA27689; Thu, 27 Feb 1997 08:16:31 -0800 (PST) From: Christopher Hylands Message-Id: <199702271616.IAA27689 at kahn. eecs berkeley edu> To: Gary Chu Kar Kit cc: ptolemy-hackers at kahn. eecs berkeley edu Subject: Re: Create my own version! In-reply-to: Your message of Thu, 27 Feb 1997 12:48:52 +0800. <3.0.32.19970227124851.006b284c at hkpucc.polyu.edu.hk> Date: Thu, 27 Feb 1997 08:16:30 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Try running make from $PTOLEMY. The problem is that CGCTclTkTarget.o has not been created, and pigiRpc needs it. Consult the troublshooting guide and the programmer's manual for details. The troubleshooting guide is part of Appendix A of the Ptolemy User's Manual and it is available via the web at http://ptolemy.eecs.berkeley.edu/users_man0.6.html/troubleshooting.doc1.html -Christopher -------- Hi, I try to create my own version of Ptolemy with my own stars. When I t ry to use: make pigiRpc. I got the error messages as follow: g++ -fPIC -O2 -Wall -Wsynth -g -DPTSOL2_4 -D_REENTRANT -pipe -fno-for-sc ope -I. -c pigiMain.cc make: *** No rule to make target `../domains/cgc/tcltk/targets/CGCTclTkTarg et.o', needed by `pigiRpc'. Stop. Whats happen on this? Thanks for your information! ********************************************** out,out,out,out* Chu Kar Kit, GARY * * Office: (852)-27666135 * * E-mail: eekkchu at ee.polyu.edu.hk * ********************************************** ('v') ('v') ('v') ('v') (( )) (( )) (( )) (( )) -/-"---"---/-"---"---/-"---"---/-"---"-- --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 27 09:25:41 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id JAA28386 for ptolemy-hackers-outgoing at brahe; Thu, 27 Feb 1997 09:14:06 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from messier eecs berkeley edu (messier. eecs berkeley edu [128.32.240.78]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA28380 for ; Thu, 27 Feb 1997 09:14:03 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by messier eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA21373 for ; Thu, 27 Feb 1997 09:14:01 -0800 (PST) Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id JAA28187; Thu, 27 Feb 1997 09:13:47 -0800 (PST) From: Christopher Hylands Message-Id: <199702271713.JAA28187 at kahn. eecs berkeley edu> To: Tamir Simantov cc: ptolemy-hackers at messier eecs berkeley edu In-reply-to: Your message of Thu, 27 Feb 1997 18:01:48 +0200. <199702271601.SAA12745 at velvet.msil.sps.mot.com> Date: Thu, 27 Feb 1997 09:13:46 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk I'm not totally sure what your problem is, but it could be that you seeing infinite recursion where a galaxy contains an instance of itself. In Ptolemy0.7, Tom Lane's recursion fixes will help with this sort of thing. You could try carefully examining your universe for such a thing. In the short term, the thing to do is to run pigiRpc under a debugger and try to see determine what pigi is doing when it consumes all the memory. See the programmer's guide for hints about using the debugger. If you can generate a ptcl file for your universe, perhaps using oct2ptcl, then you might have an easier time using the debugger on ptcl. However, it could be the case that oct2ptcl will fail to convert your universe, especially if there is a recursion problem. oct2ptcl is part of the octtools distribution, and is not shipped with the prebuilt Ptolemy binaries, you have to build it yourself. -Christopher -------- I've been using ptolemy for some time and first of all, I wanne send you all a big compliment for the powerfull tool you've designed. I'm using the discrete event domain for simulations of communication processes. My colleagues and I have bulit, a module which simulates a part of a communication processor. I'm still improving it but I have a problem : The universe contains some galaxies (which contains galaxies) and is rather complicated. When I tries to compile the facet , ptolemy starts compling the "small" galaxies , and then compiles the higher stages. Everything goes fine till here, and I'm getting messages like : "Debug:CompileUniv:facet=...." in the vem window. When ptolemy gets to the most higher level, the facet that I tries to compile, IT JUST GET STACK THERE, AND STARTS "SWALLOWING" the memory of the station I'm working in, until it breaks down. No ERROR message is prodoced , (for example message Like "Bad Net Deleted" , or "FREE DELAY LOOP" which I can handle). I tried to work on a bigger station with enlarged memory but it didn't help. I wanne emphasis that ptolemy compiles the galaxies inside the facet with great success. I hope you will be able to help me ... ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu From owner-ptolemy-hackers Thu Feb 27 20:51:31 1997 Received: (from majordom at localhost) by brahe eecs berkeley edu (8.8.5/8.7.3) id UAA05879 for ptolemy-hackers-outgoing at brahe; Thu, 27 Feb 1997 20:48:46 -0800 (PST) X-Authentication-Warning: brahe eecs berkeley edu: majordom set sender to owner-ptolemy-hackers using -f Received: from mho eecs berkeley edu (mho. eecs berkeley edu [128.32.240.171]) by brahe eecs berkeley edu (8.8.5/8.7.3) with ESMTP id UAA05873 for ; Thu, 27 Feb 1997 20:48:43 -0800 (PST) Received: from mica. eecs berkeley edu (root at mica. eecs berkeley edu [128.32.240.1]) by mho eecs berkeley edu (8.8.5/8.7.3) with SMTP id UAA24089 for ; Thu, 27 Feb 1997 20:48:42 -0800 (PST) Received: from kahn. eecs berkeley edu (kahn. eecs berkeley edu [128.32.240.252]) by mica. eecs berkeley edu (8.6.10/8.6.6.Beta11) with ESMTP id UAA05809 for ; Thu, 27 Feb 1997 20:48:40 -0800 Received: from kahn. eecs berkeley edu (cxh at localhost) by kahn. eecs berkeley edu (8.8.5/8.7.3) with ESMTP id UAA05798; Thu, 27 Feb 1997 20:45:20 -0800 (PST) From: Christopher Hylands Message-Id: <199702280445.UAA05798 at kahn. eecs berkeley edu> To: Tom Lane cc: ptolemy-hackers at eecs berkeley edu Subject: Re: DEPortHole bug with repeated runs In-reply-to: Your message of Wed, 26 Feb 1997 16:10:23 -0500. <19193.856991423 at sss.pgh.pa.us> Date: Thu, 27 Feb 1997 20:45:19 -0800 Sender: owner-ptolemy-hackersat eecs berkeley edu Precedence: bulk Looks like a good fix to me, so I added it to the development tree. Thanks! Christopher -------- I just discovered that DE-domain portholes don't work quite right when a universe is run repeatedly without being rebuilt from scratch. (That is easy to do in ptcl; in pigi you need a run control window script to make it happen.) The problem is that a porthole's dataNew flag doesn't get reset if it was set at the end of the prior run. This can result in a star mistakenly believing that there is data on an input port during its first firing. I believe that dataNew should be reset during initialize(), not during setPort() as the code presently does. setPort is typically invoked only during star construction. Porthole initialize() is called at the right time, namely during scheduler setup for each run. I also moved the resetting of timeStamp and depth into initialize(). It seems clear that failing to reset these during a new run is also wrong (although the depth mistake would only bite you if you had changed some connections since the prior run). As far as I can see, there's no good reason for DEPortHole to override setPort at all. Considering that setPort is not virtual, trying to override it is very dangerous anyway (the wrong method will be called if one is using a generic PortHole pointer to reference the porthole). I've tested the attached patch and it seems to work properly. Note that it requires recompiling pretty much all of domain DE. regards, tom lane *** DEPortHole.h~ Thu Mar 2 23:20:58 1995 --- DEPortHole.h Wed Feb 26 14:53:11 1997 *************** *** 68,77 **** DEPortHole(); ~DEPortHole(); ! // The setPort function is redefined to set DE-specific members. ! PortHole& setPort(const char* portName, ! Block* parent, ! DataType type = FLOAT); // DEPortHole has a "timeStamp" attribute. double timeStamp; --- 68,75 ---- DEPortHole(); ~DEPortHole(); ! // The initialize function is redefined to set DE-specific members. ! void initialize(); // DEPortHole has a "timeStamp" attribute. double timeStamp; *** DEPortHole.cc~ Thu Mar 2 23:20:42 1995 --- DEPortHole.cc Wed Feb 26 14:53:27 1997 *************** *** 64,83 **** // (does nothing extra, but avoids out-of-line versions from cfront) DEPortHole :: ~DEPortHole() {} ! PortHole& DEPortHole :: setPort ( ! const char* s, ! Block* parent, ! DataType t) { // Initialize PortHole ! PortHole::setPort(s,parent,t); // Initialize the DE-specific members timeStamp = 0.0; dataNew = FALSE; depth = -1; - - return *this; } Particle& InDEPort :: get() --- 64,79 ---- // (does nothing extra, but avoids out-of-line versions from cfront) DEPortHole :: ~DEPortHole() {} ! // The initialize function is redefined to set DE-specific members. ! void DEPortHole :: initialize() { // Initialize PortHole ! PortHole::initialize(); // Initialize the DE-specific members timeStamp = 0.0; dataNew = FALSE; depth = -1; } Particle& InDEPort :: get() --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request at ptolemy eecs berkeley edu