Hi, Chi and Chris!
Just to make sure I was not expressing myself wrong...
You are doing a great job at providing support for BLASTLib. I only
meant that other people who do not know exactly what they are doing should
ask you before trying to improve things. That would make life easier.
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/
On Tue, 3 Jun 2003, zhangchi wrote:
>
> 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