Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’

[Henrique Almeida <hdante.lnls@gmail.com>]

 I think there should always be a new synApps version whenever a new EPICS base version is released. This, eventually, is always true and since it's been 6 months since the latest EPICS base version was released, it looks like it's a good time for a new synApps release.

2015-11-24 16:00 GMT-02:00 Mooney, Tim M. <mooney@aps.anl.gov>:

synApps is intended to be upgraded in place between releases, and contains software (makeReleaseConsistent.pl, release.pl) to support that practice, because that has been a convenient way for us to stay current with all the disparate development efforts (base, seq, asyn, motor, autosave, etc.) on which  synApps modules depend.  The fact that a synApps release is not compatible with a version of base released two month later doesn't in my mind invalidate the entire effort to identify and assemble collections of software that work together.

When only one or a few module-version changes are needed to produce a working collection, I think it's not time for a new synApps release, because the upgrade-in-place strategy handles that well.  But when a module on which many other synApps modules depends changes, then upgrade-in-place becomes impractical, and a new synApps release is needed.

This strategy has worked pretty well, I think.  In my 20+ years of running synApps on our beamlines and labs, I have always been able to run an official synApps release, and I have also been able to make module-version changes needed by one beamline without exposing other beamlines to any risk.  In this way, the new module version gets tested at only the beamline that expects to benefit from it.  Once vetted, that module version presents less risk for inclusion in the next version of synApps.

This vetting of individual modules in older releases of synApps is important, because it's more efficient and thorough to test  software with the hardware on which it's intended to run, and we don't own that hardware.  We have no beamline at our disposal for testing.  The only way we can test with hardware is to persuade a beamline to upgrade, and we persuade them by exposing them only to the new software they've told us they want.

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Mark Rivers [rivers@cars.uchicago.edu]
Sent: Tuesday, November 24, 2015 10:08 AM
To: 'Henrique Almeida'
Cc: tech-talk@aps.anl.gov Talk
Subject: RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’

Hi Henrique,

 

Personally I don’t find the concept of synApps releases very useful.  Every official synApps release has significant bugs and build problems, and is almost instantly out of date because it lacks major new features of one or more support modules.  In my 20+ years of running synApps on our beamlines and labs I have never been able to run an official synApps release.

 

For example, in the 11 months since synApps 5-8 was released the following synApps modules have had a total of 27 new tagged releases:

 

alive: 1-0-1

areaDetector/ADCore: 2-2, 2-3, 2-4

asyn: 4-26, 4-27

autosave: 5-6-2, 5-7, 5-7-1

calc: 3-5, 3-6, 3-6-1

caputRecorder: 1-4-3, 1-5, 1-5-1

dxp: 3-5

iocStats: 3.1.14

ip: 2-10

optics: 2-10, 2-11

softGlue: 2-5, 2-6, 2-7

sscan: 2-10-2

stream: 2-6b, 2-6c

xxx: 5-8-4

 

Each of these releases either fixes significant bugs, adds significant new features, or both.  At what point should a new synApps release be made?  It will clearly be obsolete in less than 2 weeks on average, since there are 27 releases of synApps modules in less than 1 year.

 

I would find it much more helpful if rather than official synApps releases there were simply a list of known incompatibilities of the latest release of module X with the latest tagged release of module Y.

 

Mark

 

 

 

From: Henrique Almeida [mailto:hdante.lnls@gmail.com]
Sent: Tuesday, November 24, 2015 8:59 AM
To: Mark Rivers
Cc: Henrique Dante de Almeida; tech-talk@aps.anl.gov Talk
Subject: Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’

 

 

 Mark, I can confirm that replacing the caputRecorder in synApps 5.8 with the github master branch solved the problem. However, my plan was using an unmodified synApps version. You said that the latest version of each module works with the latest version of all other modules. But synApps itself is not working with the latest EPICS base version. Since EPICS base 3.15.2 was released in May, then this rule has been broken for synApps for the last 6 months. Maybe it's time to release synApps 5.9 ?

 

 

2015-11-23 18:15 GMT-02:00 Mark Rivers <rivers@cars.uchicago.edu>:

You can now find the latest versions of all the synApps modules in https://github.com/epics-modules.

There have been 3 releases of caputRecorder since synApps 5.8.

Generally the latest tagged version of each module will work with the latest tagged version of all other modules.

I am using the latest version of all synApps modules now with no problems.

Mark

-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Henrique Dante de Almeida
Sent: Monday, November 23, 2015 2:02 PM
To: tech-talk@aps.anl.gov Talk
Subject: error: ‘dbChannel’ has no member named ‘final_dbr_type’



 Hello, I'm building synApps 5.8 on a fresh Red Hat 6.6 install and I'm receiving the following error:

/usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE            -D_X86_  -DUNIX  -Dlinux     -O3 -g   -Wall      -mtune=generic     -m32 -D_FILE_OFFSET_BITS=64 -fPIC -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/Linux -I../../../include -I/usr/local/epics/base-3.15.2/include/compiler/gcc -I/usr/local/epics/base-3.15.2/include/os/Linux -I/usr/local/epics/base-3.15.2/include        -c ../caputRecorder.c
../caputRecorder.c: In function ‘myAsDataListener’:
../caputRecorder.c:283: error: ‘dbChannel’ has no member named ‘final_dbr_type’

(etc.)

 It seems that there exists a patch for this problem:

https://subversion.xor.aps.anl.gov/trac/synApps/changeset/19339

 Are there plans for merging this patch in synApps ? What about a new synApps release ?