Experimental Physics and
Industrial Control System

<[email protected]> · Wed, 18 Dec 2013 07:52:56 +0000

From: [email protected] [mailto:[email protected]] On Behalf Of Emmanuel Mayssat
> To complicate things a little, let me just say that there is a
> mental model (intuitive model) that both implementations 
> should (maybe) conform to.

> caget on a waveform should return NORD elements

That's the current cothread behaviour with a 3.14.12 server, and I'm now proposing to keep this behaviour.

> caput $waveformPV $value should return an error
> (wrong syntax) or set the waveform to a size 1 array

Pretty sure that's what it does now, by default.

> caget(waveformPV,count=N,fill_value=-1.234) returns
> N elements where the first few are from the waveform
> (NORD elements) and the rest is filled with fill_value.
> Count can be greater than NELM, if count is -1, then returns
> NELM elements.

Aha.  Hmm.  Cute idea.  Somebody can write a wrapper ;)

Makes me realise that there's currently no easy way to get at the underlying element count of a PV ... well, not entirely true, you can always do 'connect(pv, cainfo=True).count', but that's pretty clunky.  I wonder if I need a .count attribute on pvs?

> *About changing behavior and upgrading software*
> I occasionally read that people are afraid to change the
> behavior of their software because "they are going to break
> their accelerator". Personally, when I upgrade, I do major QA.
> Additionally I allow for partial/progressive deployment .
> In an upgrade, I expect (minor) issues and am ready to rollback
> the upgrade if required.
>
> In my view, changes are perfectly acceptable if you get closer
> to the mental model, i.e. make you software more intuitive and
> programmer-friendly. What may not be acceptable is when core
> developers of "collaborative" software stops their improvements
> because they are told that the intended changes would break
> their accelerator. As a result, the entire collaboration is
> held hostage. 
> Obviously it helps if the changes are documented in the release file.

This is quite a challenging topic in my view.  The appropriate attitude towards compatibility breaking changes has to depend a great deal on the scope of the system being changed, but I have to say that there are, in my opinion, too many projects where the question of backwards compatibility isn't taken seriously enough.

At one end of the scale we have an internal project or an internal API.  We can change this API to our heart's content, not only do we get to keep the pieces when we break things, we also get to fix them, and all is well.  However even here we can go too far: I've just completely rewritten an EPICS device (no problem there) and none of its old PVs even exist anymore (still no problem, part of the project was to change associated scripts) ... but the blasted archiver doesn't know about it anymore: damn!

At the other end of the scale we have shared projects and environments where we have no control over the users, and in this case I think we need to take backwards compatibility very seriously indeed.  At the extreme end of this are examples like the CA wire protocol (very difficult to change), the Linux kernel, and the C library.  Even at this end there's plenty of room for argument.  Personally I applaud Linus as loudly as I can when I hear him dressing down kernel contributors for not taking compatibility seriously, his slogan seems to be: if it breaks userspace it's a kernel bug [https://lkml.org/lkml/2012/12/23/75].  Hear hear!  On the other hand, the C library folk broke Flash some years ago by rewriting memcpy so it didn't behave like memmove anymore [http://lwn.net/Articles/414467], and they were unrepentant [http://sourceware.org/bugzilla/show_bug.cgi?id=12518#c4].  And then we all the other Linux building blocks, and don't get me started (Gnome, eww, springs to mind!
 ).

So, I aspire to take compatibility seriously (haha, if I had the exposure of Linux!) and I wish more developers did so.

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System