[kepler-dev] ParameterSet

Edward A. Lee eal at eecs.berkeley.edu
Thu Oct 19 21:54:17 PDT 2006


Norbert,

I think I understand your position here, but respectfully disagree...

It is my opinion that things that are most visible and most local
should take precedence over things that are less visible and less local.
This seems rather obvious to me, in fact...  It would be far more confusing
if parameter staring you in the face had no effect on execution of a model,
and instead some parameter hidden away in some file took precedence over it.

The rest of the precedence rules follow this principle of favoring locality...

Edward

At 06:40 PM 10/19/2006, Norbert Podhorszki wrote:
>Hi Edward,
>
>Good that you fixed that bug.
>Unfortunately, the current situation does not satisfy my taste.
>Currently, the on-screen parameter is in effect always. Only if it 
>is missing, is the parameter taken from the ParameterSet used.
>
>I liked the original behaviour better, namely, that the parameter in 
>the ParameterSet was in effect. This way I could develop a workflow, 
>put all parameters on-screen with a default value. Then the users 
>could execute that workflow with default values from command-line. 
>But also, they could write a config file to overwrite the default 
>values and parametrize the workflow as they wanted. And it was not a 
>problem if something was missing from the config, the workflow had a 
>default value inside the workflow's xml file.
>
>Just look at the attached screenshot. Is it not nice to have this 
>self-documenting feature of parameters within the workflow (besides 
>providing default values)?
>
>What is the advantage of the current precedence?
>
>Norbert
>
>On Tue, 17 Oct 2006, Edward A. Lee wrote:
>
>>
>>I am (finally) checking in a fix to the bug described below.
>>The bug was in the Variable class.  The problem was that if you
>>changed the name of a Variable (which is what you do when you
>>drop a Parameter on screen and then change its name), the variable
>>with a new name may now shadow some other variable (such as one
>>in a ParameterSet or ScopeExtendingAttribute).  But those now
>>shadowed variables were not getting invalidated, and hence the
>>presence of the new variable would not be noticed until you saved
>>and re-loaded the model.
>>
>>Thanks Norbert for pointing out this (rather subtle) bug.
>>
>>Edward
>
>
>      Norbert Podhorszki
>    ------------------------------------
>      University of California, Davis
>      Department of Computer Science
>      1 Shields Ave, 2236 Kemper Hall
>      Davis, CA 95616
>      (530) 754-8188
>      pnorbert at cs.ucdavis.edu
>      ----------------------------------
>
>

------------
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  



More information about the Kepler-dev mailing list