[kepler-dev] ParameterSet

[Norbert Podhorszki]

Edward,

I have only a long answer, however I try to propose a synthesis at the 
end.

I also think I understand your position here, and respectfully agree. At 
least about the locality.

The difference in our position is really in our real position in front of 
the screen. Namely, you are talking about using Ptolemy models within 
Vergil. I am talking about finished/published software used by those who 
actually do not care about if that software was written in Fortran or 
MoML.

If you do not look at the workflow graph, just use it, what is more 
visible and most local to you? The parameters in the workflow, or the 
parameters in the config file, you have just recently edited?

Some languages allow you to set default values for function/procedure 
arguments, some for object fields. If you debug the code, entering such 
procedure or create an object, do you expect the actual value to be what 
you see on screen (the default value) - which is most visible and most 
local -, or rather the arguments given in the call/constructor?

Obviously, you may defend the current status asking that what is the need
for on-screen parameters if the user never looks at it. They just should 
configure the workflow in the config file. One argument is allowing the 
workflow have default values. However, I may accept this situation if you 
make my (the developer's) life easier. I still want to use on-screen 
parameters in the workflow during the development and for nice 
screenshots. If I could "comment" them out at the end, then the current 
behaviour of Ptolemy would be OK for me. As far as I know, MoML is the 
first language without comments, at least among modern languages. Surely, 
you have some forum threads in the past about why is there no such 
feature, don't you ;-)?

What about satisfying both of us, instead? I propose the following 
behaviour:

1. Whichever exists alone in the workflow (on-screen parameter or config
    file parameter), is in effect.
2. Having both, at opening the workflow, the on-screen parameters are
    updated to the values of the config file. (defaults are overwritten).
3. If you change on-screen parameters,
    a. this becomes in effect and
    b. write the value into the config back at Save (or ask before)
4. If you have a config parameter and then you drag a parameter onto the
    screen, and rename it to the existing parameter,
    a. if you have not set its value yet, give it the existing config value
       automatically
    b. if you have set its value before renaming to an existing name,
       - either set that value to be in effect, or
       - ask what to do
5. If you have a parameter on-screen and then drag a ParameterSet and
    provide a config file including that parameter, then update the
    on-screen parameter's value.

I tend to believe, that the problem is lying in the current 
implementation, that you have actually two different entities with the 
same name and we are arguing about their precedence. If they were the same 
entity with two different methods to set its value, the above behaviour 
would be natural.

The above behaviour satisfies you when staring at Vergil, and it satisfies 
my users when running the workflow from command-line. Actually, I am not 
concerned about your acceptance the most but about poor Christopher's who 
must cry out when reading points 3b and 4... Also, problems arise for 
point 2 from the fact, that ParameterSet is just an attribute and there is 
currently no way to force to be evaluated after all other entities are 
created, or at least force to be the last entity in the MoML file.

I would not be surprised if the easiest solution were a new Ptolemy 
built-in feature for supporting config files and not forcing the use of 
attributes.

What are your opinions and work-estimate for the above?
Norbert


On Thu, 19 Oct 2006, Edward A. Lee wrote:

>
> 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


      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
      ----------------------------------