[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: init not called?]



Hi David,

I see what your saying. I think my issue was just with the fact that I didn't 
know that with the newest version of the HallD software in the trunk that I 
needed the newest JANA until I started getting errors when running my 
analysis software. Will the older versions of the stable-release of HallD 
behave properly with the newer JANA? are they backwards compatible? 

Cheers,
-Blake


On Wednesday 08 April 2009 06:05:22 you wrote:
> Hi Blake,
>
>     Sorry for taking so long to get back to you.
>
>     The short answer is yes. I personally like to keep my JANA files
> separate from my Hall-D files just so I can easily swap JANA versions or
> use the same JANA binaries with multiple versions of the Hall-D code.
> Nonetheless, there should be no conflict in the naming of the files that
> would prevent one from doing as you suggest.
>
>     Keep in mind though that if you do change JANA versions, you will
> almost certainly need to recompile all of the Hall-D source code. This
> is because JANA uses templates heavily so a lot of the code is 
contained
> in the headers and not in libJANA.a. So in this sense, you can't have
> one Hall-D source distribution that is simultaneously used with multiple
> JANA versions.
>
>     Just as a reminder, JANA is set up to act as a package much like
> ROOT or Xerces that is installed in some arbitrary directory and one
> sets their JANA_HOME environment variable to point to it. One just 
needs
> to recompile all of the Hall-D software if they decide to switch JANA
> versions as described above.
>
> Regards,
> -David
>
> Blake Leverington wrote:
> > Hi David,
> >
> > Just a comment from the perspective of a user more than a developer 
of
> > the software. Is it possible to have it compile JANA in HALLD_HOME 
if
> > the current version of JANA isn't up to date? I don't always have root
> > access to the shared version of JANA on the Indiana cluster so I've
> > had to download and compile it in HALLD_HOME anyway since this 
seems
> > to have solved the errors I was getting when i was trying to
> > recalibrate the BCAL with the updated svn trunk.  I imagine other
> > users will have to do the same.
> >
> > Cheers,
> > -Blake
> >
> > David Lawrence wrote:
> >> Hi All,
> >>
> >>    Here is an exchange that took place between Matt and I earlier
> >> today for those who are interested. The basic message is that the is
> >> some flaky behavior in the repository trunk right now so if you are
> >> living on the bleeding edge, be prepared to bleed.
> >>
> >> -David
> >>
> >> -------- Original Message --------
> >> Subject:     Re: init not called?
> >> Date:     Thu, 2 Apr 2009 13:06:09 -0400
> >> From:     Matthew Shepherd <mashephe@indiana.edu>
> >> To:     David Lawrence <davidl@jlab.org>
> >> References:     <AB4C8AF1-CB8A-472C-
BC36-91EBB37AF113@indiana.edu>
> >> <49D4DBE0.4080207@jlab.org>
> >>
> >>
> >>
> >> David,
> >>
> >> No problem -- thanks the note -- my solution works now.  If you feel
> >> appropriate, you might send an email to the software group?  I spun
> >> my  wheels for a while on this.  The symptom in my case was 
actually
> >> a  segfault in the event loop.  I searched all over and found it was
> >> due  to a TTree Fill() command that was being called on a null
> >> pointer (the  output tree didn't get setup in init()).
> >>
> >> -Matt
> >>
> >> On Apr 2, 2009, at 11:38 AM, David Lawrence wrote:
> >>> Hi Matt,
> >>>
> >>>   I've run into some problems with this too recently. In fact, I
> >>> just traced down an issue with it last night. It has to do with
> >>> changes in the most recent version of JANA (0.5.1). In that
> >>> release,  a somewhat significant change was made to how
> >>> initializations were  done in order to better accommodate GUIs 
which
> >>> operate in a slightly  different way.
> >>>
> >>>   The fix seems to depend on the exact version of JANA and the 
Hall-
> >>> D source code that is being used. For me, the main thing that was
> >>> needed was to make the JApplication::Init() method virtual so that
> >>> DApplication::Init() gets called properly. I'm not sure that would
> >>> resolve the issue in your case.
> >>>
> >>>   All I can say for now is that I'm seeing similar issues and I'm
> >>> trying to fix them as I come across them. I'm hoping to put out a
> >>> new JANA version (0.5.2) next week that addresses this and a new
> >>> tagged release of the Hall-D software the week after that that
> >>> meshes well with JANA 0.5.2. In the meantime, hopefully you can
> >>> limp  along with what you have.
> >>>
> >>> Sorry for the inconvenience.
> >>>
> >>> Regards,
> >>> -David
> >>>
> >>> Matthew Shepherd wrote:
> >>>> Hi David,
> >>>>
> >>>> I seem to have a processor that has an init routine that is not
> >>>> getting called.  I can't figure out why this is.  I checked other
> >>>> sample processors in the repository and the function seems to be
> >>>> defined correctly:
> >>>>
> >>>>    jerror_t init(void);                        ///< Called once at
> >>>> program start.
> >>>>
> >>>> I got around it by calling init in the constructor, but this isn't
> >>>> the best solution -- any ideas?
> >>>>
> >>>> -Matt
> >>>
> >>> --
> >>>
> >>> -----------------------------------------------------------------------
> >>>-
> >>>
> >>> David Lawrence Ph.D.
> >>> Staff Scientist                 Office: (757)269-5567    [[[  [   [
> >>> [       Jefferson Lab                   Pager:   (757)584-5567   [
> >>> [ [ [ [ [   http://www.jlab.org/~davidl     davidl@jlab.org
> >>> [[[  [[ [[ [[[
> >>> -----------------------------------------------------------------------
> >>>-

-- 
Blake D. Leverington
Department of Physics
University of Regina
Regina, SK, S4S 0A2
Email: leverinb@uregina.ca
Tel.: +1 306 585-4653