EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Sequencer 2.2.0
From: Benjamin Franksen <[email protected]>
To: <[email protected]>
Date: Wed, 17 Sep 2014 14:10:06 +0200
Hi Everyone

thanks for the quick responses so far.

I forgot to mention one ugly little detail:

The pvArrayXxx functions will not get the array size as a default 
argument as was the case with e.g. pvPutComplete() before. For instance, 
with

  int a[2];
  assign a to {};

you you'll have to say

  pvArrayPutComplete(a,2);

if you want to check whether all elements have completed their last 
asynchronous pvPut.

[The reason is, of course, that arrays are not first-class citizens in 
C: when you pass them to a function the size information is lost. I 
could make them first-class in SNL but only at the cost of completely 
breaking compatibility with existing code.]

Cheers
Ben

On Monday 15 September 2014 16:46:09 Benjamin Franksen wrote:
> Hi Folks
> 
> I am having second thoughts about one of the new features in version
> 2.2.
> 
> tl;dr: I want to go back to allowing calls to the usual built-in pv
> functions only with single channels and instead introduce new,
> differently named functions for arrays of channels ("multi-pv
> arrays"). My hope is that 2.2 is not yet widely used and so the
> damage this will do is limited.
> 
> Here is the long text.
> 
> The sequencer in version 2.2, as it stands, aims to allow calls
> built-in pv functions not only for expressions denoting a single
> channel, but also for arrays of channels, wherever this makes sense.
> Such calls were allowed previously, but (with one exception) did not
> do what you would expect: it meant that the function operated on the
> first element of the array.
> 
> The plan for 2.2 was to give a more useful semantics to such calls: do
> the action for *all* contained channels.
> 
> I won't go into the details of how to enable/disable this feature with
> an additional option here, because that is irrelevant to the
> question.
> 
> The main gripe I have with the feature is that it blocks the path to a
> future improvement: to allow users to define functions in SNL that
> can operate on channel variables just like the built-in functions. A
> beautiful side-effect of this change (plus the addition of defaults
> for function parameters) is that the built-in functions now have
> valid SNL types. This means all the code in the compiler that handles
> calls to built-in functions in a special way can be scrapped. The
> compiler initially inserts the appropriate function symbols into the
> top-level scope and all else works as it should... with one
> exception: there is no reasonable systematic way of making a type T
> and also the type T[5] (or *T) instances of the same type scheme. And
> that means I would have to re-introduce all the special handling for
> built-in functions, which would make me very unhappy.
> 
> This is why I would like to change version 2.2 so that:
> 
> * all existing built-in functions give compile-time errors when called
> with an array of channels
> 
> * new functions are introduced in those cases where operating on all
> contained elements of an array makes sense.
> 
> Please note that all this concerns only arrays where the elements are
> separately assigned to different channels. It has nothing to do with
> the channel's underlying value type, which can be an array or a
> scalar.
> 
> I have polled for opinions with regard to naming these functions
> before, but my preference has changed to adding the word 'array'
> somewhere in the name (currently I am favoring pvArrayXxx), because
> when the stuff I am working on is finished, there will be more ways
> to aggregate channel variables: you can define structs with members
> of channel type, for instance, and the functions I am proposing to
> add will only work on simple arrays. (You will be able to define you
> own function for structs that contain channels or even structs of
> arrays of structs etc...)
> 
> There is also the one function to consider that had the 'do it for all
> contained channels'-behavior in 2.1 (and even in 2.0): pvPutComplete.
> It even has a number of optional arguments to better support this. My
> current plan is to reduce this function to the simple one-channel
> variant, and add a new pvArrayPutComplete with the extended
> functionality.
> 
> I think all this can be done without introducing any incompatibilities
> to the C API. In fact, I am thinking about fixing those
> incompatibilities I already introduced, namely those concerning the
> added timeout parameter for seq_pvGet and seq_pvPut functions, by
> adding new C functions seq_pvGetTmo and seq_pvPutTmo.
> 
> Let me know what you think.
> 
> Cheers
> Ben

-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Attachment: signature.asc
Description: This is a digitally signed message part.


References:
Sequencer 2.2.0 Benjamin Franksen
Re: Sequencer 2.2.0 Benjamin Franksen

Navigate by Date:
Prev: Asyn priya tiwari
Next: RE: Asyn Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Sequencer 2.2.0 Mooney, Tim M.
Next: Caen NDT1470 support? Brown, Garth
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·