Re: Using asynPrint() from motorRecord ?

[Torsten Bögershausen via Core-talk <core-talk at aps.anl.gov>]

Thanks Andrew and Michael,

Yes the ASYN_INFO was replaced by _STATE here:
<https://github.com/epics-modules/asyn/pull/67/commits/ffb84abc46679a6e1d0479674f0dd3e2e662a4cc>

And then the thing got stuck somewhat.

The discussion about .TPRO, .DDBG has not fully settled yet,
so for the moment I will continue to use the ".SPAM" field,
until a better solution is found.

I will address the other comments, thanks Andrew.

BR
/Torsten
PS: Sorry for the spam yesterday, mailman did the trick.




On 05/02/20 18:54, Andrew Johnson via Core-talk wrote:
> Hi Torsten,
>
> I'm not sure whether all the motor guys read core-talk, just saying...
>
> On 2/5/20 9:02 AM, Torsten Bögershausen via Core-talk wrote:
> > While debugging this and that, I find more and more that
> > asynPrint() is a very useful feature.
> >
> > Timestamps can be printed, file/line and/or the thread, all
> > is configurable in runtime.
> >
> > Now to my question:
> > Is it a good idea to use it during record processing ?
> >
> > Since the motorRecord does not have access to asyn directly,
> > all prints are fiddled through device support, which has
> > asyn.
> >
> > In other words, this nice print works only for asynMotors
> > (But that restriction is OK).
> This seems reasonable as long as the API added is generic and the motor 
> app doesn't become dependent on Asyn to compile, since I believe there 
> are still motor drivers that don't need Asyn. Your code seems to be fine 
> with that, but I haven't tested it. Other drivers should be free to 
> implement their own logging interface method (which is what I think this 
> API really is) to provide similar functionality if they wish.
>
> > I have done a prototype here:
> > <https://github.com/tboegi/motor/commit/9aebabdf551a24bd138d483808130af57888a9e0> 
> Specific comments on your prototype:
>
> I thought the flag name|ASYN_TRACE_INFO|was discussed and rejected 
> inAsyn#63 <https://github.com/epics-modules/asyn/pull/63>back in 
> December 2017. If I'm right introducing it through a change to the motor 
> app doesn't seem right to me.
>
> The method name|devVprintSource()|in|struct motor_dset|emphasizes more 
> how it's implemented using Asyn, not what it's used for. I would 
> recommend thinking about names more like|log_vprintf()|. I admit the 
> name is mostly used inside a wrapper function inside motorRecord.cc but 
> the name is visible to anyone writing a new motor driver.
>
> Your change in motorDevSup.c appears to be only tangentially related to 
> this topic, should it be extracted and applied separately?
>
> The non-Asyn implementation of|debugPrint()|will no longer display the 
> filename and line number of the message source, which used to be 
> explicitly listed in the|Debug()|format string arguments. I'm not saying 
> they necessarily /need/ to appear, but I'm pointing out the change for 
> those who work more closely with the motor record so they recognize and 
> can comment on it.
>
> Requiring a |__LINE__| argument to |debugPrint()| without |__FILE__| 
> looks a bit strange, I might consider using a macro to hide both 
> arguments from all those calls.
>
> HTH,
>
> - Andrew
>
> --
> Complexity comes for free, Simplicity you have to work for.