Experimental Physics and
On Fri, Sep 15, 2017 at 8:56 PM, Andrew Johnson <firstname.lastname@example.org> wrote:
I have three statements (four including me) for info items against yours for fields, that's why I kept the approach. But I do not care too much.
Did you look at making the two info items into fields instead? I don't
The info fields carry only configuration. All state in is the simpvt structure.
I will probably still need the simpvt structure to store state.
Or are you suggesting to completely remove the private structure and store everything (configuration and state) in fields?
I would like to see a comparison of the two approaches, as I'm not
I am not against adding fields. All my users said they don't need the settings to be run-time configurable, but it does not hurt if they are. I will try to avoid making them special(), as that would add more code.
If a new simmSCAN field is of type menuScan, to what do I have to set the default value (in the dbd) to detect the field not having been set?
I need this to not swap the SCAN periods if simmSCAN has not been set.
At least one change in recGbl.c seems to be undoing a link support
Sorry. I didn't check the documentation and thought I was using the new style constructs. Will fix this.
Does the SIMPVT field always point to a struct xsimm? If so the extra()
Fine. I was looking at the other ...pvt pointers and tried to be consistent. I prefer to be explicit at this point.
I'm getting a build failure on cross-building for MinGW (and this will
My RTEMS build fails in src/std/rec/test:
As I have neither RTEMS nor vxWorks available, I am copy-pasting and hoping for the best.
I think that's all for now, I haven't actually looked at or tested the
Thanks a lot for the review. I will wait for your comment on the field vs. simpvt issue and do the changes.
These will not affect the simulation mode run time behavior.
|ANJ, 21 Dec 2017||
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·