The online macros work which means you can always do analysis as blast.
The online macros is the work of many, and help is appreciated.
Expanding software is a typical thing that may occur on shift. As said
many times, we currently can not support a fully tagged version and as
chris and chi (or others) will point out we have made this a priority.
It is a lot of work. It is not finished. It is regrettable that people
that attend to this also have to receive blame.
We discuss these issues weekly. As far as I know there are no "customers"
here, so customer satisfaction is an abstract point. If there is a problem
let's be specific. As said many times, if the problem is with the online
account, i.e. something does not run as blast, I am the first person to
contact. If it is a deeper issue I should be able to revert to a previous
version and or get help from other experts. If the problem is with your
account, it will be helped as time allows. This means everybody will be
able to do analysis by either taking a snapshot of the blast account or by
doing analysis as blast.
Analysis evolves day to day which requires following the development constantly.
If something is out of sync I expect people to be able to fix it or ask for help.
It will at least force people to understand how things work.
Everything else is a waste of time or maybe just an amusement.
-- ________________________________________________________________________________ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^On Tue, 3 Jun 2003, Adrian T Sindile wrote:
> Thank you, Chris! > I will try v2_15. Meanwhile, I want to say something that has been on my > mind for a while, please READ ON... others have been saying it too, maybe > not too loud (see Chi's email about lrn freezing two days ago: > > > 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.) > > On Tue, 3 Jun 2003, Chris Crawford wrote: > > hi, adrian > > sounds like something tancredi added, w/o checking the mc. i'll fix > > it before tagging the new version v2_20 today. for the meantime, you > > can try v2_18, or v2_15 (if 18 doesn't work.) > ------------------------------------------------------------------------ > > I have been signaling that lots of macros that are tampered with become > full of bugs etc. (not to mention that some were written so they give > you 20 errors from the start, probably with the hope that others will fix > them). The official advice I got one time was that "I have permission to > fix them" - I consider this arrogant at least. > > I think it is time we get serious about shooting ourselves in the foot, so > people who obviously do not understand programming should keep away from > the common codes in the blast area. It is not a shame not to be a software > guru, and nobody knows everything, so why try hard to mess up common code? > It would be a great help for everybody... > > Adrian > > > > > >Hi! > > >Can anyone tell me what versions (branches, tags etc.) should I use in MC > > >and BlastLib2 in order to have compatible codes? > > > > > >I do not know if this is related to the update error in v2 made a while > > >ago (mentioned by Tancredi on May 28th), but I cannot make any version of > > >reconstruction (using lrn.C) to work with either MC v3 or MC v2 - I get > > >complains about both .coda files. A sample following: > > > > > >root -l lrn.C -m +nw -n 1000 -pid > > >root [0] > > >Processing lrn.C... > > >Electronics map is for Monte Carlo data. > > >Calibration file: > > >/home/blast/adrian/physics/RECON/Blast_Params/blast.sc_mc > > >Counting multiples of 100 events. > > >_________________________ > > > > > >Opening data file: event.coda > > >Unknown event type! > > >rawData: (0x41cd4008) > > > 0000001C 00000000 12345678 00000000 > > > 00000018 00000001 00000009 00000011 > > > 00000019 00000021 00000029 00000031 > > > 00000039 00000041 00000049 00000051 > > > 00000059 00000061 00000069 00000071 > > > here 1000 > > > > > > 1 Error: Can't call TBLRaw::GetSHtgtstate1() in current scope > > >FILE:lrn.C LINE:285 > > >Possible candidates are... > > >filename line:size busy function type and name (in TBLRaw) > > >Error: Symbol raw is not defined in current scope FILE:lrn.C LINE:285 > > >Error: Failed to evaluate raw.GetSHtgtstate1()Possible candidates are... > > >filename line:size busy function type and name > > >*** Interpreter error recovered *** > > > > > > > > >For other cases, the errors were different (depending on what version I > > >was using, I tried both cvs up rv2 and rb2_18 for BlastLib2). > > > > > >Thanks! > > > > > >Adrian > > > > > >------------------------------- > > >Adrian Sindile > > >Research Assistant > > >Nuclear Physics Group > > >University of New Hampshire > > >phone: (603)862-1691 > > >FAX: (603)862-2998 > > >email: asindile@alberti.unh.edu > > >http://einstein.unh.edu/~adrian/ > > > > > > > > > > >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST