Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Tue, 01 Oct 2013 12:19:58 -0500

On 10/1/13 9:48 AM, Benjamin Franksen wrote:
> My current plan is therefore to give a compile time error if pv
> functions are called with multi-PV arrays, as they do not properly
> support them anyway. This means the compiler helps you by pointing to
> the location in your source code where a change is needed. Either you
> append "[0]" to the variable if that is actually the intention. Or
> it's not, and as a result a few errors will be uncovered and wouldn't
> that be nice?[*]
>
> What to do with pvPutComplete? It is the only function that properly
> supports multi-PV arrays. I think I will remove this feature so that
> it behaves in manner consistent with pvGetComplete, and then add a new
> function that implements the more general behaviour. Again, this means
> you might have to slightly change your program but the compiler will
> help you in figuring out what to do.
>
> BTW, on the subject of how to name the new functions (no bike-shedding
> ensued, are you all asleep?) I am currently in favour of using pural
> form i.e. pvGets, pvPuts, pvGetsComplete, etc. I don't like pvGetArray
> since (1) the normal pvGet works perfectly fine with arrays (only
> not with multi-PV arrays) and (2) the new function will work with
> single-PV variables, too.

Hi, Ben.

I'm OK with your proposed changes, and I agree with your reasoning for
favoring the plural naming over the "array" naming.

> And now to another issue: Currently, the timeout for synchronous pvGet
> and pvPut is hard-coded to 10 seconds. Adding an extra (optional)
> argument to specify a different timout has been on my wish-list
> for a long time. This is now implemented (in the 2.2 branch) but
> again an issue of compatibility comes up, though in this case it
> does not concern SNL code proper (adding an extra DEFAULT_TIMEOUT
> argument can be done automatically by the compiler). However, escaped
> C code that calls seq_Pv{Put,Get} will have to be changed to add this
> argument. Note that here, too, the compiler (the C compiler in this
> case) poinpoints the location of the problem for you.
>
> I am in favour of making this change in version 2.2, but if it turns
> out to hurt people too much I am willing to restrict the change to the
> new pvGets and pvPuts.

I'm OK with this change being made in 2.2.  However, why couldn't
you use varargs to avoid needing to change escaped C code calls to
seq_Pv{Put,Get}?  Or are you avoiding that to keep it clean and simple?

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System