EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’
From: Mark Rivers <[email protected]>
To: "'Henrique Almeida'" <[email protected]>
Cc: "[email protected] Talk" <[email protected]>
Date: Tue, 24 Nov 2015 16:08:25 +0000

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:[email protected]]
Sent: Tuesday, November 24, 2015 8:59 AM
To: Mark Rivers
Cc: Henrique Dante de Almeida; [email protected] 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 <[email protected]>:

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: [email protected] [mailto:[email protected]] On Behalf Of Henrique Dante de Almeida
Sent: Monday, November 23, 2015 2:02 PM
To: [email protected] 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 ?

 


Replies:
RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Mooney, Tim M.
References:
error: ‘dbChannel’ has no member named ‘final_dbr_type’ Henrique Dante de Almeida
RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Mark Rivers
Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Henrique Almeida

Navigate by Date:
Prev: Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Pete Jemian
Next: Re: Successfully locked memory using mlockAll Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Pete Jemian
Next: RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·