Hi, blast runs out of -rv2 not -rv2.18. As said earlier
<dblast07:113> diff ~/lib/libBlast.so ~/cvs_v2/BlastLib2/libBlast.so
gives no diff. All changes in v2 are checked in and we (or at least I)
always compile out of straight cvs -rv2 check out. Also
<dblast07:113> cat ~/cvs_v2/BlastLib2/CVS/Tag gives
Tv2
Maybe the pid flag is a thing to look at and if so I'll take it out
from blastrc. libBlast has not significantly changed in the past 3
weeks and I've never experienced such a freeze EXCEPT when you are
crunching data and somebody changes/saves lrn.C. Then root may just
abort or freeze. Will look into that.
This was already discussed and put in the minutes of the last software
meeting.
As far as havin a deal with satan him/herself, I'll investigate directly.
> Hi,
>
> I think I might know the reason for lrn freesing the console.
>
> blast is using v2_18 at the moment. There is a bug in particle id routines
> that generates seg-fault. it is fixed in v2 top version. Unfortunately,
> beam/target polarization info were implememted into TBLRaw v2_18 so they
> must be merged before blast can use v2 top version for analysis. I tried
> to merge but was not successful. Will try again today or tomorrow so blast
> can move on to top version.
>
> When we pipe unbuffered stream into the null device, we do not see the
> message dumped when seg-fault happened which is out put by error stream
> which is exactly unbuffered.
>
> So here is my suggestion, turn off pid when running lrn:
>
> root -@#$% lrn.C ... -pid ...
>
> Chi
>
> P.S. I also spot a strange thing about lrn.C, "scal_inhcharge" is first
> used at line 299, but declared at line 469 AND in a else if block. In
> principle, it shoudl not run and should complaine about undeclared
> variables. As it happens when Tong and I tried to run lrn.C in our own
> accounts.
>
> HOWEVER, IT RUNS IN BLAST ACCOUNT!!!! Maybe Blast had a deal with the
> Satan, Aaron?
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST