Experimental Physics and
Industrial Control System

Timo Korhonen via Core-talk <[email protected]> · Tue, 15 Jan 2019 10:50:23 +0000

Hi Tom,

From my point of view, it is definitely a plan to change - or rather to
fix - the display_t.

Why: in the specification (EPICS V4 Normative Types, Editors Draft,
16-Mar-2015), the display_t has a comment (highlighted in red):

format
A format for converting the value field to a string
"Needs work: What is display.format? What's it for and what are examples?
If it's a sprintf pattern, which syntax must it conform to - C or Java?"

Which tells to me that nobody (who has read the document) should have
taken the format (and display_t) specification for completed and fixed -
it was not even specified what it should be.
Nevertheless, there may be clients that have made assumptions about how
the format looks like.

Michael has made a proposal which sounds good to me, see :
https://github.com/epics-base/pva2pva/issues/19 and
https://github.com/epics-base/pva2pva/pull/24

In my opinion: it should still be display_t and I would not change the NT
type version numbers because of this fix.

Timo

ps: I agree with Kay concerning the priorities. We need this to be fixed
so that we can start using PVA in the control room.

On 15/01/19 10:32, "[email protected] on behalf of tom.cobb---
via Core-talk" <[email protected] on behalf of
[email protected]> wrote:

>Hi Kay,
>
>> Priority wise, replacing the display.format string with
>>display.precision and
>> display.what_to_call_it would be more important.
>
>Is there a plan to definitely change a display_t, or is this a proposal
>at this stage?
>
>If so, will it still be a display_t, or will it get a new typeid?
>
>What clients are currently using the format string?
>
>If planning to unpack the format string into its component parts, will
>there also be fields for width, justification and padding?
>
>Thanks,
>Tom
>
>
>> -----Original Message-----
>> From: [email protected] <[email protected]> On
>> Behalf Of Kasemir, Kay via Core-talk
>> Sent: 14 January 2019 17:00
>> To: Ralph Lange <[email protected]>; [email protected]
>> Subject: Re: 'Request' support in qsrv
>> 
>> >>The only problematic scenario would be a large waveform record where
>> some client solely requests the timestamp.
>> >>Always adding the complete waveform would increase the network traffic
>> compared to just the requested timestamp, but I think that's a silly
>>example.
>> >Make that a client that only wants to check the metadata of a huge
>>image
>> (e.g. to decide on the image size if it wants to read the image data
>>itself), and
>> it's not silly anymore.
>> 
>> For images sent from AreaDetector's PV plugin, all is fine.
>> This will only fetch the dimension[], no image data:
>>    pvget -vv -r dimension 13SIM1:Pva1:Image
>> 
>> Only QSRV sends the complete struct, and there's a plan to fix that.
>> We may not know by when, but it's no show stopper.
>> Priority wise, replacing the display.format string with
>>display.precision and
>> display.what_to_call_it would be more important.
>> How about a google form?
>> https://docs.google.com/forms/d/e/1FAIpQLSeYNwsym8av05h2yqjUfw5kcl
>> uv37kZ5-dVPGjaZuSI7YtaWQ/viewform?usp=sf_link
>> 
>> Thanks,
>> Kay
>> 
>
>-- 
>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