Bug in vergil.tree.PTree

[Kevin Ruland]

Hi all,

Found a simple bugger at line 113 in vergil.tree.PTree.  Seems the test
for if the path is null appears after its use in another condition. 
Here's a little patch:

Index: ptolemy/vergil/tree/PTree.java
===
RCS file: /home/cvs/cvsanon/ptII/ptolemy/vergil/tree/PTree.java,v
retrieving revision 1.33
diff -w -r1.33 PTree.java
113,116d112
< if (path.getLastPathComponent() instanceof
EntityLibrary) {
< //this prevents a user from dragging a folder.
< return;
< }
121a118,121
> if (path.getLastPathComponent() instanceof
EntityLibrary) {
> //this prevents a user from dragging a folder.
> return;
> }


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Actor attributeChanged() methods and validating mutliple changes.

[Kevin Ruland]

Efrat,

That's what would end up happening now - except the user could be 
presented with some ugly intermediate states.


Kevin

Efrat Frank wrote:

Hi Kevin,

We tried to address this issue several times in the past, both for the 
WebService and OpenDBConnection actors, but still there doesn't seem 
to be a solution.


In the org.geon.OpenDBConnection actor, I populate the schema 
parameter per attributes changes to be able to use it with the query 
builder prior to the workflow execution. For the mean time, I overcome 
this problem by trying to connect to the database and extract the 
schema per each attribute change (and the final change will be once 
the user commits). Perhaps the same solution may work for you?


- Efrat





Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Actor attributeChanged() methods and validating mutliple changes.

[Kevin Ruland]

Then would I also override NamedObject.executeChangeRequests() or would 
I have to have the actor implement ChangeListener then register this as 
a change listener on this?


class MyActor extends Source implements ChangeListener {

 public MyActor( CompositeEntity container, String name ) {
   super(container, name);
   addChangeListener(this);
 }

 public void changeExecuted( ChangeRequest change ) {
   // Do extra validation & d/l, etc.
 }

 public void changeFailed( ChangeRequest change ) {
  // nothing?
  return;
 }

}

I think I saw the NamedObj uses a list of WeakReferences for the 
listeners so I don't have to unregister in a finalizer, right?


How would this work when reading in a moml which contains one of these 
actors already configured?  Would it still get only one change request, 
or would it receive multiples?


Kevin

Edward A. Lee wrote:


As I recall, the current dialog pane issues the change request for a 
parameter
change when the parameter's editing widget loses the focus.  I believe 
the

reason for this was that there was because there are several ways that a
dialog might get closed, and Swing is not rigorous about notifications
(or, perhaps more likely, I found the documentation incomprehensible and
couldn't get it to work).

I'm open to a change in the dialog box that would issue the change
request only when an Apply or OK button is pressed...  This would 
probably

solve the problem...

Edward

At 09:36 AM 2/16/2006, Kevin Ruland wrote:

To make matters worse, the output ports available depend on the 
contents of this metadata.  So the only way for the user to construct 
the workflow would be to configure, run & wait for failure, then 
construct the relationships and run again.


If I write my own parameter dialog pane would I have notification of 
"commit"?


Kevin


Edward A. Lee wrote:

At 07:24 AM 2/16/2006, Kevin Ruland wrote:
Is there any way for the actor be notified when the user decides 
all the changes are complete?


Not really... I'm not sure how one could do that...
You could check the parameters in preinitialize().

Edward




Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal



Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal 




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Actor attributeChanged() methods and validating mutliple changes.

[Kevin Ruland]

To make matters worse, the output ports available depend on the contents 
of this metadata.  So the only way for the user to construct the 
workflow would be to configure, run & wait for failure, then construct 
the relationships and run again.


If I write my own parameter dialog pane would I have notification of 
"commit"?


Kevin


Edward A. Lee wrote:

At 07:24 AM 2/16/2006, Kevin Ruland wrote:
Is there any way for the actor be notified when the user decides all 
the changes are complete?


Not really... I'm not sure how one could do that...
You could check the parameters in preinitialize().

Edward




Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal 




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Actor attributeChanged() methods and validating mutliple changes.

[Kevin Ruland]

I over simplified the example.  In my particular case, there is no 
mathematical formula to use.  I have an actor which loads metadata from 
local or remote sources.  One way to specify the metadata location is to 
use a simple URL (file://, http://, or ftp://), the other is to specify 
a web service endpoint and a string parameter.  There are two ways to 
hold this information:


1)  Use a String for the w/s parameter, and a single String to hold 
either the URL or the endpoint (which is a url).


2) Use a String for the w/s parameter, a String for the endpoint, and a 
String for the URL.


In the first case, it will be difficult to distinguish if the URL String 
represents a simple http request or an http end point.   In the second 
case, it would be possible to have all three fields populated and not be 
able to distinguish if the user wants to use the URL or the Web Service.


Since neither of these work, I'd like to have a simple drop down or 
check box to have the user specify which mechanism they want.  That 
pretty much solves all the confusion.  However, validation is still a 
problem particularly if I'd like to check if the URL location or web 
service parameters are valid.  The user could start with the URL 
location parameter as empty string, then change the selector to use a 
location.


Is there any way for the actor be notified when the user decides all the 
changes are complete?


Kevin

Edward A. Lee wrote:


Why not set the parameter values as follows:

This looks to me like a rather non-orthogonal design.

Why not have:
  a1 = something
  a3 = 0 or 1   ortrue or false(depending on semantics)

then calculate what you now call a2:
  a2 = 2*a1 + a3

Edward


At 10:36 AM 2/15/2006, Kevin Ruland wrote:

Hi all,

We have a number of actors which require certain conditions to be 
satisfied by attributes as a collection.  For sake of example, 
suppose we have two attributes a1, a2 which are integers.  And the 
following conditions must hold:


a1 = 1 <=> a2 = 1, 2
a1 = 2 <=> a2 = 3, 4

You get the idea.

Now suppose the user selects configure actor and sees:

a1:  1
a2:  2

And wants to configure the actor to be:

a1: 2
a2: 4

If I do all the validation in the attributeChanged method such as this:

   public void attributeChanged(Attribute attribute) throws 
IllegalActionException {

   int a1val;
   int a2val;
   if ( attribute.equals(_a1) || attribute.equals(_a2) ) {
   try {
   a1val = Integer.parseInt( _a1.getExpression() );
   a2val = Integer.parseInt( _a2.getExpression() );
   } catch (NumberFormatException e ) {
   throw new IllegalActionException("Invalid Number");
   }

   switch (a1val) {
   case 1:
   if ( a2val != 1 && a2val != 2 ) {
   throw new IllegalActionException("invalid values");
   }
   break;
   case 2:
   if ( a2val != 3 && a2val != 4 ) {
   throw new IllegalActionException("invalid values");
   }
   break;
   default:
   throw new IllegalActionException("invalid values");
   }

   }
   super.attributeChanged(attribute);
   }


With this code in place I was actually able to convince the actor to 
move to the proper state but only by judiciously "ok"-ing the error 
dialog.  In fact, by abusing the error dialog I was even able to move 
the actor into a completely invalid configuration.


Is there a better place to do this validation -- I'm hoping for 
notification from the "commit" button instead of in 
preinitialize/initialize.  For this simple example, I could perhaps 
change the


Thanks for the help.

Kevin

 


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]



Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal 




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Actor attributeChanged() methods and validating mutliple changes.

[Kevin Ruland]

Hi all,

We have a number of actors which require certain conditions to be 
satisfied by attributes as a collection.  For sake of example, suppose 
we have two attributes a1, a2 which are integers.  And the following 
conditions must hold:


a1 = 1 <=> a2 = 1, 2
a1 = 2 <=> a2 = 3, 4

You get the idea.

Now suppose the user selects configure actor and sees:

a1:  1
a2:  2

And wants to configure the actor to be:

a1: 2
a2: 4

If I do all the validation in the attributeChanged method such as this:

   public void attributeChanged(Attribute attribute) throws 
IllegalActionException {

   int a1val;
   int a2val;
   if ( attribute.equals(_a1) || attribute.equals(_a2) ) {
   try {
   a1val = Integer.parseInt( _a1.getExpression() );
   a2val = Integer.parseInt( _a2.getExpression() );
   } catch (NumberFormatException e ) {
   throw new IllegalActionException("Invalid Number");
   }
  
   switch (a1val) {

   case 1:
   if ( a2val != 1 && a2val != 2 ) {
   throw new IllegalActionException("invalid values");
   }
   break;
   case 2:
   if ( a2val != 3 && a2val != 4 ) {
   throw new IllegalActionException("invalid values");
   }
   break;
   default:
   throw new IllegalActionException("invalid values");
   }
  
   }

   super.attributeChanged(attribute);
   }


With this code in place I was actually able to convince the actor to 
move to the proper state but only by judiciously "ok"-ing the error 
dialog.  In fact, by abusing the error dialog I was even able to move 
the actor into a completely invalid configuration.


Is there a better place to do this validation -- I'm hoping for 
notification from the "commit" button instead of in 
preinitialize/initialize.  For this simple example, I could perhaps 
change the


Thanks for the help.

Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Failure to find ptII.properties

[Kevin Ruland]

BTW - when Vergil or Kepler is run from an installer as an application
then standard out and standard error will be eaten because there is no
standard out.  We do have a certain amount of verbiage going on
though.  It should all go in to a log file somewhere.

  


Christopher,

This is true.  Where it was really causing me troubles is in the nightly 
workflow tests.  This executes as ptexecute and we have a scraper which 
checks stderr/out for the magic string "Exception".  Essentially all the 
workflow tests were being flagged as failed even though a couple were ok 
(ya, I have other work to do).  I can easily change our script to ignore 
this specific error so it isn't really a big deal.


Thanks

Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Failure to find ptII.properties

[Kevin Ruland]

Hi all.

I'm curious about the ptII.properties file loaded from $CLASSPATH/lib/.  
I looked at the one generated for my laptop and it is a bunch of paths 
to various system things.  The problems its causing me is on startup if 
it cannot be found, I'm notified with:


java.io.IOException: Could not find $CLASSPATH/lib/ptII.properties

This is a little unsightly especially since ptexecute and vergil (from 
Kepler's configuration) still appear to work correctly.


Is it possible that kepler does not need these properties set at all, 
and if not, is there a way for us to quite down the startup.


Thanks much.

Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: [kepler-dev] [Fwd: Re: kepler/src/util URLToLocalFile.java]

[Kevin Ruland]

Well,  it seems I cannot reproduce the problem Efrat was having.  Maybe 
that was a data problem.  However, even with the test workflow, and the 
previous revision of URLToLocalFile, I cannot reproduce the problem.


Kevin


Dan,

I was talking to Efrat a while ago, and I think this fix actually 
covers up a bug in ptII's ptolemy.util.FileUtilities.nameToURL() which 
appears to add an extra "/" to the string, which then makes the name 
look like this:  "http:///www";.  What this really indicates to Java 
when converted to a URL, is protocol = http, host = null (localhost), 
file = "/www", then if this URL is converted back into a string you 
get this:  "http:/www" because of the null host.


I've cc'd the ptolemy-hackers list because they might should look at 
this.  The bug was introduced in r1.28 of that file.


Kevin

Daniel Higgins wrote:

  +
  +// jan2706: fix the "http:/www..." problem:
  +try {
  +String fixedUrlAsString =   +
url.toString().replaceFirst("(https?:)//?", "$1//" );

  +url = new URL( fixedUrlAsString );
  +} catch( Exception e ) {
  +System.out.println( "Badly formed url exception: " + e );
  +}
  +
  +//System.out.println( "URLToLocalFile2: 
url.toString()="+url.toString() );
  





___
Kepler-dev mailing list
[EMAIL PROTECTED]
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
  




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re:kepler/src/util URLToLocalFile.java

[Kevin Ruland]

Dan,

I was talking to Efrat a while ago, and I think this fix actually covers 
up a bug in ptII's ptolemy.util.FileUtilities.nameToURL() which appears 
to add an extra "/" to the string, which then makes the name look like 
this:  "http:///www";.  What this really indicates to Java when converted 
to a URL, is protocol = http, host = null (localhost), file = "/www", 
then if this URL is converted back into a string you get this:  
"http:/www" because of the null host.


I've cc'd the ptolemy-hackers list because they might should look at 
this.  The bug was introduced in r1.28 of that file.


Kevin

Daniel Higgins wrote:

  +
  +// jan2706: fix the "http:/www..." problem:
  +try {
  +String fixedUrlAsString = 
  +url.toString().replaceFirst("(https?:)//?", "$1//" );

  +url = new URL( fixedUrlAsString );
  +} catch( Exception e ) {
  +System.out.println( "Badly formed url exception: " + e );
  +}
  +
  +//System.out.println( "URLToLocalFile2: url.toString()="+url.toString() );
  




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: [kepler-dev] Can "stop" interrupt "initialize()"

[Kevin Ruland]

Edward A. Lee wrote:

At 11:22 AM 2/1/2006 -0600, Kevin Ruland wrote:

1) Should CompositeActor release the read-lock prior to making the open
call to the director's preinitialize()?


This would have to be done very carefully.
If you don't hold a read lock, then the structure of the model
can change at any time.  If you are iterating through a list of actors
to preinitialize them, for example, and the list of actors changes
while you are iterating through it, you could get into trouble.

The "right" way to mutate the model is by queueing a ChangeRequest.

Edward




Edward,

I think I'm in a big pickle right now.  In my local copy of 
CompositeActor, I moved the getDirector().preinitialize() to outside the 
finally block which releases the read lock.  This did not fix the issue 
I'm having so I suspect the problem is much deeper.  So looking back up 
the call stack, I see that Manager.initialize() also gets the Read 
Lock.  Since Workspace's read lock is reentrant that isn't a problem -- 
it just indicates to me there is something catastrophically wrong with 
the actor I have in hand.


So, I'm going down the ChangeRequest route.  The interface is pretty 
straight forward especially since I can just use anonymous 
implementations.  My big question is what changes need to be through a 
ChangeRequest and if there are any exceptions, e.g. When I'm in an 
attributeChanged() method, do I need to queue a ChangeRequest?  Feel 
free to just point me to the documentation.


I just tried it - and it completely fixed the problem!

Thanks much for your time.

Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Hi all,

I was happily working through the issues I was having with stop and 
intialize().  The answer I ended up with was this in ititialize():


try {
sychronized( _entityCountDown ) {
  while ( _entityCountDown.currentCount() > 0 && 
!getDirector.isStopRequested() ) {

_entityCountDown.wait();
  }
}
}
catch ( InterruptedException e ) {
 throw new IllegalActionException("Downloads not complete");
}

if ( getDirector().isStopRequested() ) {
 throw new IllegalActionException("Execution interrupted");
}

and:

public void stop() {
 synchronized( _entityCountDown ) {
   _entityCountDown.notifyAll();
 }
}

This seems to work fine (except it raises an exception when interrupted, 
I think I should just return here).  But I've ended up with some crazy 
deadlock situation due to locking of the Workspace.


If I follow this use case:  Open workflow with numerous long running 
downloads, press "play" button.  The execution blocks in one of these 
objects in the initialize method waiting for _entityCountDown to be 
reduced to 0.  The problem is, the call back mechanism, which is 
executing in the download thread, makes calls to this object and 
attempts to reset some ports.  It seems the action of setting the ports 
attempts to write-lock the workspace.  But I guess the initialize thread 
has already locked the workspace.


It really doesn't make any sense to reconfigure output ports in a 
running workflow and I would expect that if the download completion 
needed to change the ports (say, the user build the workflow with one 
set of ports but they didn't match those specified by the downloaded 
data...) this would result in some workflow exception.


I tried moving the blocking action into preinitialize but that also 
resulted in a dead lock.


After a little effort with the debugger, I think I found where the 
deadlock is occurring, but I don't know what the corrective action is:


Looking in CompositeActor.preinitialize(), I see that it obtains read 
access to the workspace (_workspace.getReadAccess()) prior to calling 
getDirector().preinitialize().  This read access lock conflicts with the 
desire of the other download thread to mutate the output ports of the actor.


1) Should CompositeActor release the read-lock prior to making the open 
call to the director's preinitialize()?


2) Should I rewrite these data download actors so they do not attempt to 
modify the output ports during execution?


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Edward A. Lee wrote:

At 01:49 PM 1/30/2006 -0600, Kevin Ruland wrote:


Every Director has a method isStopRequested().
A long running initialize() method should just call this method
and abort if it returns true...


I think I can use this in some kind of spin wait.  What's the easiest 
way for an actor get a handle to it's director?


 Call getDirector().
 I wouldn't do this as a spin wait, though. Instead,
 in the long running thread, periodically call isStopRequested() at
 points where it would be safe to abort.  This is much safer than
 calling interrupt() on a thread, which can leave objects in an
 undefined state.



Unfortunately, the long running process is a soap download and there 
aren't any convenient places to insert the tests (ie it's all messy axis 
generated code).  Currently my only synchronization mechanism is a 
CountDown (from oswego) on which I can block until it becomes 0.  So 
really I need to poll both the CountDown and the isStopRequested() - or 
I need to hang on to a reference to the thread blocking on the 
CountDown, then interrupt it in the actor stop() method.


BTW - Thread.interrupt() is fine.  It's Thread.stop() which is 
deprecated because of object consistency problems.  Thread.interrupt() 
will make blocking i/o and Thread.wait() throw InterruptedExceptions, 
and otherwise it only sets a flag isInterrupted() flag on the Thread.


Thanks for the help.

Kevin



Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Edward A. Lee wrote:

At 08:41 AM 1/30/2006 -0600, Kevin Ruland wrote:
Also, if some actor somewhere does do something extremely time 
consuming in it's initialize method, there is currently no pleasant 
way to interrupt it.  The user can click on the stop button, and it 
does appear to have some effect -- that is, it's indentation changes 
when pressed -- however, it does not interrupt the processing.  This 
behavior could be considered a but itself.  Either the stop button 
needs to be disabled until it can do something useful, or it should 
stop the workflow regardless of its execution state.


Every Director has a method isStopRequested().
A long running initialize() method should just call this method
and abort if it returns true...



Edward,

I think I can use this in some kind of spin wait.  What's the easiest 
way for an actor get a handle to it's director?


I did a little digging and noticed that Manager.finish() does a 
notifyAll().  Presumably I could tap into this as well and synchronize 
on the Manager object.  Of course, I need to get my hands on the 
Manager, and there might be a different deadlock situation present.


Thanks much.

Kevin

I would be circumspect about adding additional phases.
It could significantly increase the complexity for actor writers.

Edward




Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal 




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Shawn,

I was not clear -- I was referring to the semantic type checking and the 
'manual override' would only be for those users who have some deeper 
understanding of the data and don't want to go through the effort of 
annotating them correctly.  In retrospect, I should not have spoken 
because I don't know what the desired functionality of this portion of 
the system is.


Kevin

Shawn Bowers wrote:

On Mon, 30 Jan 2006, Kevin Ruland wrote:

  

Bertram,

Things like static type checking may be optional (to the workflow) in
the sense that one could still execute a workflow without having done
the static type checking step or perhaps the workflow could be executed
if static type checking fails (user override?).



Is this really true?  I don't think so in Ptolemy -- i.e., ptolemy throws
exceptions if unexpected types are found.  In general, I'm not sure that
for standard ptolemy/kepler type workflows, it even makes sense to run
them if they are not type safe.

  




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Bertram Ludaescher wrote:

On Mon, 30 Jan 2006 08:41:50 -0600
Kevin Ruland <[EMAIL PROTECTED]> wrote: 

KR> 
KR> Bertram,
KR> 
KR> Things like static type checking may be optional (to the workflow) in 
KR> the sense that one could still execute a workflow without having done 
KR> the static type checking step or perhaps the workflow could be executed 
KR> if static type checking fails (user override?).  In this sense, data 
KR> loading is different because it is necessary to have successfully 
KR> completed data loading prior to execution.


I agree that e.g. static type checking is (typically) optional Also it
is different from data loading.  On the other hand, there are
similarities between a long-running job / actor and the data
loading. Whenever things take a very long time, a different "mode of
operation" seems necessary. This what I was arguing for (different
stages or phases) in the light of long-running data loading operations
on start-up. For example, wouldn't it be useful to have the
possibility that the user chooses which dataset is being loaded before
it is actually loaded at startup? 

  
I suppose you're thinking of something like firefox's download manager.  
That would be very nice but would be a new feature which needs to be 
approved soon in order to be included in the feature freeze at the end 
of Feb.  Bring it up next week and we can discuss its utility, in this 
context, as well as feasibility.


KR> Also, if some actor somewhere does do something extremely time consuming 
KR> in it's initialize method, there is currently no pleasant way to 
KR> interrupt it.  The user can click on the stop button, and it does appear 


Maybe we should discourage such practice, i.e., having time consuming
initializes. A rule of thumb could be: if it takes longer than a few
seconds, it should be NOT part of the initialization phase, but a
separate phase!? (obviously this needs some more thought)

  
Right.  Since initialize cannot be interrupted, I should think that it 
would be even shorter than a few seconds.  In the case of these actors, 
right now they just verify that the data load is complete.  If it isn't 
complete then they raise the IllegalActionException which can be 
interpreted as either "not ready yet" (in this case), or "improperly 
configured" (as should be the case for other actors).  My understanding 
of the initialize() method is it is supposed to verify proper configuration.


This brings me to another idea, instead of having initialize() in these 
data actors block for completion of download, it would be completely 
possible for them to block in prefire or fire.  That is, they don't wait 
until they are actually called upon to do something useful.  I will play 
with this and see if stop then does what I hope it to.


KR> to have some effect -- that is, it's indentation changes when pressed -- 
KR> however, it does not interrupt the processing.  This behavior could be 
KR> considered a but itself.  Either the stop button needs to be disabled 
KR> until it can do something useful, or it should stop the workflow 
KR> regardless of its execution state.


I guess in Ptolemy, hitting 'stop' implies that the system goes into a
"defined state" so that when hitting 'resume' (currently the same as
'play' ;-) things are consistent. A "hard interrupt" would probably
causes problems with restarting later!? 

  
It would be possible, in this case, for stop to terminate the d/l, then 
play/pause, would simply restart the d/l.
KR> I have been given no requirements for the data loading process - other 
KR> than to see if we can make ptexecute work correctly.


For the particular workflow at hand, could the dataloading be moved
from the init phase to a later phase (when 'play' has been hit)? Or is
the data loading already happing at 'play' time!? 

  


The data load actually happens before play.  The user has no control 
over its beginning or end - this is perhaps a bad thing.





Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Can "stop" interrupt "initialize()"

[Kevin Ruland]

Bertram,

Things like static type checking may be optional (to the workflow) in 
the sense that one could still execute a workflow without having done 
the static type checking step or perhaps the workflow could be executed 
if static type checking fails (user override?).  In this sense, data 
loading is different because it is necessary to have successfully 
completed data loading prior to execution.


Also, if some actor somewhere does do something extremely time consuming 
in it's initialize method, there is currently no pleasant way to 
interrupt it.  The user can click on the stop button, and it does appear 
to have some effect -- that is, it's indentation changes when pressed -- 
however, it does not interrupt the processing.  This behavior could be 
considered a but itself.  Either the stop button needs to be disabled 
until it can do something useful, or it should stop the workflow 
regardless of its execution state.


I have been given no requirements for the data loading process - other 
than to see if we can make ptexecute work correctly.


Kevin

Bertram Ludaescher wrote:

Kevin:

Your suggestion about changing things in the "guts" of Ptolemy scares
me a bit. Moreover, I think it's probably not needed.

We had recently an exchange (on kepler-dev) about different workflow
stages or phases, among them something that could be called "data
staging". I think it's time we recognize that we need to state the
requirements data staging, then come up with a design that extend
Ptolemy/Kepler without further overloading the native Ptolemy
capabilities.

In particular, I think the "VCR buttons" for "Play", "Pause", and
"Stop" need to be augmented with other buttons for data staging (if
necessary), static type checking (when desired) etc. Doing things
under the (Ptolemy) hood doesn't seem like a good idea.

Is there a requirements or design document for the features you've
described and that we need? If not, we should probably put this on the
agenda of the upcoming Kepler meeting..

What do you think?

cheers

Bertram




  

On Sun, 29 Jan 2006 17:51:11 -0600
Kevin Ruland <[EMAIL PROTECTED]> wrote: 

KR> 
KR> Hi.
KR> In Kepler we have some actors which download large volume of data in the 
KR> background.  They do this without any control from the director.  In 
KR> essence this is done when the actor is instantiated and should complete 
KR> prior to the user running the workflow (ie, before initialize() is called).
KR> 
KR> I was looking at the problem we're having with ptexecute where these 
KR> workflows bomb because ptexecute does not know that it needs to wait 
KR> until the data is loaded before executing the workflow.
KR> 
KR> I was thinking of two different alternatives here.  The first is to have 
KR> initialize() verify that the data download is complete and raise an 
KR> IllegalActionException if it is not complete.  This provides feedback to 
KR> a real user when they press "go" too soon, but does not fix the problem 
KR> we have with ptexecute because it will just bomb when initialize() fails.
KR> 
KR> The other alternative is to have initialize() block until the data is 
KR> downloaded.  This solves the ptexecute problem.  The problem now is with 
KR> the UI.  After a real user presses "go", the "stop" button does not 
KR> appear to do anything.  I believe that stop does not attempt to 
KR> interrupt actors stuck in initialize().
KR> 
KR> I think the best solution overall, is to have the stop button actually 
KR> interrupt the workflow thread.  The InterruptedException could be 
KR> trapped and converted into an IllegalActionException.  Unfortunately, 
KR> such a change would very likely be deep in the guts of Ptolemy, and 
KR> could potentially have other unintended consequences.  What do you think?
KR> 
KR> Kevin
KR> 
KR> 

KR> Posted to the ptolemy-hackers mailing list.  Please send administrative
KR> mail for this list to: [EMAIL PROTECTED]

  




Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Can "stop" interrupt "initialize()"

[Kevin Ruland]

Hi.

In Kepler we have some actors which download large volume of data in the 
background.  They do this without any control from the director.  In 
essence this is done when the actor is instantiated and should complete 
prior to the user running the workflow (ie, before initialize() is called).


I was looking at the problem we're having with ptexecute where these 
workflows bomb because ptexecute does not know that it needs to wait 
until the data is loaded before executing the workflow.


I was thinking of two different alternatives here.  The first is to have 
initialize() verify that the data download is complete and raise an 
IllegalActionException if it is not complete.  This provides feedback to 
a real user when they press "go" too soon, but does not fix the problem 
we have with ptexecute because it will just bomb when initialize() fails.


The other alternative is to have initialize() block until the data is 
downloaded.  This solves the ptexecute problem.  The problem now is with 
the UI.  After a real user presses "go", the "stop" button does not 
appear to do anything.  I believe that stop does not attempt to 
interrupt actors stuck in initialize().


I think the best solution overall, is to have the stop button actually 
interrupt the workflow thread.  The InterruptedException could be 
trapped and converted into an IllegalActionException.  Unfortunately, 
such a change would very likely be deep in the guts of Ptolemy, and 
could potentially have other unintended consequences.  What do you think?


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Storing XYPlotter graph as video

[Kevin Ruland]

Nandita,

Don't know about an actor, but you can take a sequence of static images 
and make them into a movie (animated gif or mpeg) using ImageMagick.


Kevin

Nandita Mangal wrote:

Hi there,
I had a question,  if there are any  actors /ways to store the results 
plotted on an XY Plotter as a video? My workflow continously plots 
data in a loop and can i store the result at some point as video? If 
not can i store graph as an image?

thanks!
nandita.


Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail. 
 





Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Startup performance

[Kevin Ruland]

Christopher,

I've run the code though demo copies of many different profile 
monitoring tools.  They all indicate a major time skew when reporting 
cpu performance.  One product described the reason which is the jvm 
instrumentation provides only wall clock miliseconds when profiling.  It 
does not provide cpu cycles (or simulated clocks in the jvm).  This same 
product did provide a button which attempted to scale this to real cpu 
time based on estimated skew.  I was not able to get this feature to 
work for me.


BTW - my pick for performance monitoring tool is JProfiler from 
ej-technologies.com.  I also liked AppPerfect - it looked very nice, had 
excellent integration with eclipse (but required uninstalling TPTP) and 
included load / unit testing tools.  However, it did not provide thread 
contention/monitoring facilities which is something I am very fond of.


Anyway,  I noticed that these tools did not indicate TypeLattice or 
FloydWarshallStrategy as being big consumers of time.  Since they all 
use the same underlying instrumentation provided by the jvm, I fail to 
see why TPTP indicates these routines are so expensive.


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Startup performance

[Kevin Ruland]

Christopher,

TPTP is very dogged slow on my machine too and I have a 2x Xenon 3Ghz 
warming my toes.  I've found the only way to execute it in a reasonable 
amount of time is to turn off the "per-instance" things.  This 
apparently really turns down the amount of data collected.  Also, I 
start eclipse with -Xmx1024M just so it doesn't run out of memory.  Even 
with this, I find that it gets caught thrashing quite a lot.


I've been given the go-ahead to buy a performance monitoring tool - 
provided they aren't too much money.  The three commercial ones I've 
tried so far (yourkit.com, borland's optimizeit, and quest's jprobe) all 
run considerably faster.  They all either require, or do much better, 
when you run under jdk 1.5 with the new fangled monitoring api.  Of 
course, the underlying jvm will greatly impact quite a lot of the 
performance numbers.


My initial analysis of the tools are that JProbe is the easiest to use.  
Yourkit.com is fairly nice -- though it's memory analysis isn't as 
pretty as JProbes.  And optimizeit is very ugly and on top of that, I 
can't figure out how to get descent resolution on the performance numbers.


BTW - yourkit.com and optimizeit are both reasonably priced ($135 and 
$300, resp, academic prices).


The total time numbers returned by TPTP are greatly skewed due to the 
instrumentation.  That's why I reported percentages.  Those percentages 
were of total kepler startup (to the first welcome window).  I figured 
everything was skewed the same so percents were the only thing reliable.


I don't know how to completely configure TPTP and interpret it's 
numbers.  Independent validation is really required here.


More comments inline.

Christopher Brooks wrote:


Kevin wrote:

 


I saw a commit you made to ptolemy.kernel.util.NamedObj,
specificially r1.303 where you reimplemented the
ContainedObjectsIterator to no longer use lazy initialization.  I
have seen no ill effects of this change.  However, I did notice
something else.  Since the lazy initialization has been removed, it
is much more obvious what ContainedObjectsIterator really is -
nothing more than a wrapper class around Iterator.  When profiling
(I'm giving yourkit.com profiler a try - don't like it much) I saw
that Object.() was a pretty significant time consumer.
Object.() was being called for each instantiation of new
ContainedObjectsIterator().  After making,
NamedObj.containedObjectIterator() simply return
attributeList().iterator(), the time consumption of Object.()
was reduced by 50%.

If you find no bad effects of removing the lazy initialization, then
I suggest you completely drop the ContainedObjectsIterator helper
class, and implement the containedObjectsIterator() in the more
simple manner.  It both reduces code and increases performace.
   



Yah, I was thinking about doing that.  I'm not sure why this 
code evolved this way, perhaps as for type safety or something.


 

The only way to get one of these things is through the 
NamedObj.containedObjectIterator() which returns the Iterator interface 
-- which is the right thing to do.  I suspect somebody in days past 
thought lazy initialization was the way to go so they wrapped it in an 
object to handle that.  But it both adds complexity and seems to slow 
things down.



I'll be away in the desert through the new year, so I'm loath to
make changes that could destabilize the tree.

 

Fun.  Don't change anything.  My effort is really to analyze Kepler's 
peformance and these things are pretty much a side effect.  
Unfortunately, the biggest problems with Kepler's performance cannot be 
addressed until the other developers return from holiday as well.  I do 
not understand the inner workings of that system to make wholesale 
changes without breaking things.



Below is my response to your earlier email.  I was waiting to look at
the XmlParser but did not get to it. 


Kevin wrote:
 

I ran the Kepler startup through a performance monitoring tool the other 
day and learned some things which I would like to pass along.


I used the TPTP system in Eclipse to measure the performance.  This is 
an amazing tool and I suggest you check it out sometime.  Since I'm a 
rookie with this tool, and don't really know too much about the ptolemy 
startup my observations and assessments might be completely off base.
   



Thanks for taking a look at this.  It's been far too long since
we tuned up Ptolemy - I'm sure is plenty of low hanging fruit.

TPTP seems pretty nifty, I like the integration with Eclipse.
However, it is far too slow to use on my laptop (Windows, 1.8GHz, 1Gb),
so I set it up on a desktop machine ( Windows, 2x3GHzh, 4GB) and
it still took many minutes to start Kepler up under TPTP.
TPTP also seemed to sort of hang after a few runs on my laptop, I was
probably out of memory.  Also, I found the button that will 
display the where memory is allocated to the instances though 
I did not try it.  (Run -> Profile -> Profiling -> Memory Analysis

-

Re: Startup performance

[Kevin Ruland]

Christopher,

I saw a commit you made to ptolemy.kernel.util.NamedObj, specificially
r1.303 where you reimplemented the ContainedObjectsIterator to no longer
use lazy initialization.  I have seen no ill effects of this change. 
However, I did notice something else.  Since the lazy initialization has
been removed, it is much more obvious what ContainedObjectsIterator
really is - nothing more than a wrapper class around Iterator.  When
profiling (I'm giving yourkit.com profiler a try - don't like it much) I
saw that Object.() was a pretty significant time consumer. 
Object.() was being called for each instantiation of new
ContainedObjectsIterator().  After making,
NamedObj.containedObjectIterator() simply return
attributeList().iterator(), the time consumption of Object.() was
reduced by 50%.

If you find no bad effects of removing the lazy initialization, then I
suggest you completely drop the ContainedObjectsIterator helper class,
and implement the containedObjectsIterator() in the more simple manner. 
It both reduces code and increases performace.

Kevin

Christopher Brooks wrote:

>Hi Kevin,
>Thanks for the analysis!
>
>I'll see about replicating your results and tuning the Ptolemy code.
>I'll see what I can do soonish, this week or next.
>
>_Christopher
>
>
>
>
>Hi all,
>
>I ran the Kepler startup through a performance monitoring tool the other 
>day and learned some things which I would like to pass along.
>
>I used the TPTP system in Eclipse to measure the performance.  This is 
>an amazing tool and I suggest you check it out sometime.  Since I'm a 
>rookie with this tool, and don't really know too much about the ptolemy 
>startup my observations and assessments might be completely off base.
>
>I enabled monitoring in all non-java.* packages and hence ended up with 
>performance metrics in the ptolemy code as well as the kepler code.  
>TPTP reports wall-clock time which is completely skewed because the 
>application runs much more slowly when being monitored.  However, it 
>does allow you to convert absolute time into percentage of total time so 
>I'll report those numbers here when appropriate.
>
>There were 4 places in the ptolemy code which were pretty significant.
>
>1) ptolemy.data.type.TypeLattice$TheTypeLattice.  in the call to 
>_basicLattice.isLattice().  The profiler says this is about 10% of the 
>startup time.  Since the _basicLattice is constructed by compiled in 
>statements, you should only have to verify that changes in the source 
>result in a valid lattice. What I mean is, this particular test  needs 
>only be performed once each time you update TheTypeLattice and does not 
>need to be performed with each application startup.  I suggest you 
>replace the test with an assert like this:
>   
>assert _basicLattice.isLattice() : "TheTypeLattice: The type 
>hierarchy  is not a lattice";
>   
>Then you can have a unit test run during compile or other times which 
>turns on this assertion to verify proper changes to the code.
>   
>2) NamedObject$ContainedObjectsIterator.hasNext() is called many times.  
>I noticed you are using some lazy evaluation of _attributeListIterator 
>in the methods for this inner object.  Instead of doing lazy evaluation 
>perhaps you could change it to initialize this variable in the 
>constructor.  Then the tests would not be needed in the other methods. 
>Of course this does change the semantics of the Iterator, and I cannot 
>determine if such a change would break usage of the iterator.
>   
>3) The FloydWarshallStrategy is called 2 times and accounts for 8% of 
>startup time.  I don't really know where this is being called.
>   
>4) By far the largest consumer is the XmlParser class in 
>com.microstar.xml.  It's base time is 37% of startup. (Base time is 
>amount of time spent executing code in the class itself, does not 
>include time spend in function calls).  Of these it looks like the 
>TryRead and readLiteral methods are pretty intensive.
>
>Kevin
>
>---
>   -
>Posted to the ptolemy-hackers mailing list.  Please send administrative
>mail for this list to: [EMAIL PROTECTED]
>
>  
>


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Memory leak.

[Kevin Ruland]

Edward,

I don't fully understand the situation and defer to you or Christopher 
for greater details.   Perhaps there is something in the Kepler code 
which is holding onto a MoMLParser too long.


In kepler there is this code in ActorMetadata.ActorMetadata( InputStream 
moml):


{

MoMLParser parser = new MoMLParser();
NamedObj obj = parser.parse( null, moml );

...

}

So in theory the parser should be local and go out of scope.

But in the MoMLParser.parse( URL, Reader ) method, it looks like this is 
being held onto.  parser returns a variable called _topLevel.  But there 
is code in the parse() method which assigns this (MoMLParser) to an 
attribute of _topLevel called "_parser".  I believe this is where the 
reference to the MoMLParser is being retained.


Kevin

Edward A. Lee wrote:


At 12:29 AM 12/21/2005 -0800, Christopher Brooks wrote:


Yep, this looks like a leak of some sort.

In MoMLParser, _parser is declared as:
private XmlParser _parser = new XmlParser();




I'm confused... Wouldn't the leak then actually be
in the creation of multiple instances of MoMLParser without
deleting them?





Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Re: Memory leak.

[Kevin Ruland]

Christopher,

Christopher Brooks wrote:


Hi Kevin,

Yep, this looks like a leak of some sort.

In MoMLParser, _parser is declared as:
   private XmlParser _parser = new XmlParser();

I'm not sure if setting _parser to null in 1326 of
MoMLParser.parse(URL, Reader) is safe or not.  What happens the next
time this method is called with the same MoMLParser?  _parser is null
and we will crash.  I'm not sure if there is much state in XmlParser,
so creating and destroying _parser each time could be ok.
 

I was just testing a hypothesis and didn't want to spend a whole lot of 
time fixing it correctly.  XmlParser (or it's delegate, I don't recall 
which) does allocate some stuff including a fairly sizeable char[], but 
extra work is much better than a 15M leak, imo.


I've thought of a few fixes.

One way to fix it would be to wrap the _parser member and the methods 
which use it directly in an inner class of MoMLParser.  The inner class' 
members would still have access to the containing class's private data 
so there wouldn't have to be a bunch of setters to much up the 
interface.  Then it might be easier to see where the object needs to be 
created.


Another is to allocate the _parser variable in the parse(URL,String) 
method.  Seems like a reasonable thing to do.  But it doesn't look all 
that pretty to have a member variable be allocated/deallocated all the time.


Another is to declare _parser as function local, then pass it into all 
the methods that use it.  This would result in a pretty ugly private 
api, but would certainly make the use of _parser more explicit.



It would be interesting to see if we can fix the leak, but it might be
better to use a different parser.  We are currently using Aelfred,
which is fairly old.
 



The second reason I didn't want to spend a whole lot of time fixing it.  
I pointed out just a little while ago that the microstar parser was 
fingered as a possible performance problem.  BTW - that analysis was 
inconclusive, it only stated that the parser consumed a lot of time - 
but we know it's used a lot too.  I suggest before gutting it (it's a 
piece of work, I know because I tried to implement MoMLParser as a SAX 
ContentHandler and couldn't accomplish it), you actually pit two parsers 
in a simple head to head parsing task.



BTW - I looked at the start up of Kepler, and when I insert -verbose
in the command line it looks like we are loading 4267 classes.
When I start up Ptolemy II vergil, we are loading 2008 classes.
I think part of the reason for the difference is that Ptolemy II loads
actor classes lazily whereas Kepler loads everything right away.
 

I noticed this too.  Before an actor is dragged onto the canvas, all 
that's really needed is: the name, the folder, and the little icon.  
Since we have a database behind Kepler, we should be able to cache all 
this stuff in there without parsing moml at all.  It's definitely worth 
looking at, and also would greatly speed up startup.



The reason Ptolemy II does this is so that the configuration can have
actors in it that don't necessarily work on the local machine because
the local machine is missing libraries.  For example, not all machines
have Java3D installed, yet the full vergil configuration includes 
the GR domain actors, which use Java3D.  Users without Java3D only

notice a problem if they open a model that uses the GR domain actors
or if they open the branch of the actor hierarchy that has GR domain
actors.

 

Very good reason.  Matt wants Kepler to be usable as a f.e. to 
distributed workflows. 


Lazy loading also makes it easier to use WebStart and pull over only
the jar files that we need to run a particular model.

The downside of the Ptolemy lazy loading is that searching the actors
is impossible without fulling loading them.
 



Any changes which implement lazy loading of the actors will have to wait 
until Chad comes back.  That area of the code seems like a mine field.


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Memory leak.

[Kevin Ruland]

Hi guys,

As everybody else, I was concerned that Kepler's memory consumption, so 
I ran just kepler startup through -Xrunhprof and looked at the 250M 
memory report.  I terminated the application "normally" by closing the 
main window as soon as it appeared.


The answer is... Kepler  is leaking.  Yes, in java you don't have memory 
leaks you have "in advertant reference retention".


The allocation which is not released is 
com.microstar.xml.XmlParser.pushURL(XmlParser.java:3169).   This is 
accounting for 333 leaked char[] totalling 10,919,736 bytes.  This is 
15% of the allocated memory when I terminated the application.  The 
number 333 is really interesting it happens to be exactly the same as 
the number of kar files/actors in the current kepler.  I suspect 
ActorMetadata or some such is hanging onto a moml parser.


Also, there are 333 byte[] totalling 5,461,200 bytes.  Also in 
XmlParser.java:4182.  All told about 20% of leaked memory is accounted 
for by XmlParser.


I tracked this reference retention down to the ptolemy.moml.MoMLParser 
class.  It has a private member call _parser which is an XmlParser.  
However, it is not released after parsing is finished.   I added a 
'_parser = null' at line 1326, right before the return in parse( URL, 
Reader ).  That definitely plugged it, but I am uncertain the fix is 
completely safe.  I'm afraid I'll have to defer to The One True Ptolemy 
Hackers.


There are still a couple of very large allocations but they might be 
understandable.  The largest 5 allocations account for 8.5M, 17% of 
memory allocated.  This still seems large since there had been no 
workflow created.  I might be able to find some time to look into these 
tomorrow.


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Startup performance

[Kevin Ruland]

Hi all,

I ran the Kepler startup through a performance monitoring tool the other 
day and learned some things which I would like to pass along.


I used the TPTP system in Eclipse to measure the performance.  This is 
an amazing tool and I suggest you check it out sometime.  Since I'm a 
rookie with this tool, and don't really know too much about the ptolemy 
startup my observations and assessments might be completely off base.


I enabled monitoring in all non-java.* packages and hence ended up with 
performance metrics in the ptolemy code as well as the kepler code.  
TPTP reports wall-clock time which is completely skewed because the 
application runs much more slowly when being monitored.  However, it 
does allow you to convert absolute time into percentage of total time so 
I'll report those numbers here when appropriate.


There were 4 places in the ptolemy code which were pretty significant.

1) ptolemy.data.type.TypeLattice$TheTypeLattice.  in the call to 
_basicLattice.isLattice().  The profiler says this is about 10% of the 
startup time.  Since the _basicLattice is constructed by compiled in 
statements, you should only have to verify that changes in the source 
result in a valid lattice. What I mean is, this particular test  needs 
only be performed once each time you update TheTypeLattice and does not 
need to be performed with each application startup.  I suggest you 
replace the test with an assert like this:
  
   assert _basicLattice.isLattice() : "TheTypeLattice: The type 
hierarchy  is not a lattice";
  
Then you can have a unit test run during compile or other times which 
turns on this assertion to verify proper changes to the code.
  
2) NamedObject$ContainedObjectsIterator.hasNext() is called many times.  
I noticed you are using some lazy evaluation of _attributeListIterator 
in the methods for this inner object.  Instead of doing lazy evaluation 
perhaps you could change it to initialize this variable in the 
constructor.  Then the tests would not be needed in the other methods. 
Of course this does change the semantics of the Iterator, and I cannot 
determine if such a change would break usage of the iterator.
  
3) The FloydWarshallStrategy is called 2 times and accounts for 8% of 
startup time.  I don't really know where this is being called.
  
4) By far the largest consumer is the XmlParser class in 
com.microstar.xml.  It's base time is 37% of startup. (Base time is 
amount of time spent executing code in the class itself, does not 
include time spend in function calls).  Of these it looks like the 
TryRead and readLiteral methods are pretty intensive.


Kevin


Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]