Re: Using asynPrint() from motorRecord ?

[Andrew Johnson via Core-talk <core-talk at aps.anl.gov>]

    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
      in Asyn#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.