Hi, Adrian and all:
I would like to throw in my two cents here.
We have a very limited source of man power, especially people with both
experience on physics and analysis beyond student level and at the same
time with HANDS ON experience on BLAST beyond three months level. Such
people are a very valuable asset in the collaboration. We definitely need
more but HEY we are lucky if the one we have now do not leave us.
If you look at JLAB, a well established lab in its production period, it
still has at least postdoc level personel in charge of each important
department. Such luxuary is not currently available here. We have to
rely on very few people to do very many jobs. Unfortunately this translate
to even longer time for us student to get our data.
I think one solution is to go to binary programs instead of scripts.
I alway think, A MACRO SHOULD NOT BE LONGER THAN 100 LINES. If it is
longer, it should be organized, compiled and if appropriate, integrated
into the Blast library. Compiler itself is our best friend in avoiding
stupid mistakes and people do make stupid mistakes especially after being
stressed for such a long period of time. Unfortunately, we are facing the
same man power constraint on this front. And there are couple of very
nice tools to debug binary codes. I am SORRY that I had not done more and
I am trying to integrate bits and parts of charge.C and lrn.C into BlastLib.
I know that the cvs is in a very messy state at the moment. It is
partially due to our lack of experience with maintaining a CVS
repository, and partially due to the fact that radical library
developement is going on as application codes and macros are written
at the same time. My knowledge in programming techniques is far from
adequate to keep the library such that it could easily adapt to new
requirements merged from analysis.
I apologize for the in convenience it caused everybody. I tried to provide
good "CUSTOMER CARE"s and will try harder to do so.
We are trying to make the coming v3 more flexible to the ever changing
analysis environment, and more robust. We are trying to make it available
as soon as possible. I also hope it will clear up a lot of confusion on
cvs tag/version/branch mess.
Vit says the email is already too long. So I shut up. Hope the thing
eventually works.
Chi
> 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