Hi Kris, On Fri, 23 Aug 2002 15:01:58 -0500 Kris Hagel <hagel@comp.tamu.edu> wrote concerning "Re: bdst": > Hello, > I think I have written it before, but I am using the Dst classes > exclusively for the pp analysis and I can vouch for it working very well > and being very convenient (except for the fact that in reality they > should be called BrPhDS classes as decided by the BRAHMS computing > working committee sometime in 1997. I think I have written that before > also) At some point, you have to tell me what's the you understand DST and PhDS to be. > I was hoping, however, that it would be incorportated into brat so that > it could be used without having to load the library. (I used to be a > strong believer in loading whatever libraries needed, but Christian > converted me into realizing how nice it is if you have a bratroot or a > bratmain which knows about everything). Erh, did I convince of you that? Well, I didn't mean to. I _like_ loading libraries, as long as I don't have to do it too often, and too many of them (heck, I have an inteactive ROOT with all my stuff preloaded, just because I got tired of writting ".x MyLoad.C" :-). > I think that would also help in "converging toward using the same > software for analysis" Well, in principle one (Peter?) could make `bdstmain' and `bdstroot' that have the libraries preloaded. That would sort of solve the problem. That said, it basically (for batch jobs at least) boils down to having gSystem->Load("libDstData.so"); gSystem->Load("libDstModule.so"); in a configuration script. ROOT also has a `plugin' feature one could exploit. I haven't looked at it in details, so I'm just going with my impression from a 2 minut scan of some preliminary code I saw in ROOT some time ago. I _believe_ (not `know') it works more or less like this: * Suppose you have a line in your .rootrc that says: Plugin.TFile: .*\.brat BrFile BratUtil "BrFile(const char*,Option_t*,const char*,Int_t)" * and now you try to open a file named `foo.brat', like root [0] TFile* file = TFile::Open("foo.brat"); * What happens next, is that ROOT will see that there's a plugin handler for regexp ".*\.brat", and the class is `BrFile'. If that class isn't known it will try to load one of libraries `libBratUtil.so' or `BratUtil.dll' (or something). If that defines the class, then it will execute the CTOR for that class, passing the CTOR the arguments the it needs, and return a handle to the user. * What the handler can do, is to silently load all the data libraries of BRAT before trying to open the file, so that all the stuff is known. This also works for compiled code. So you see, there's loads of ways to preload libraries, even some that's not even `preloading' but handled by a plugin facility. > Also, could you clarify. In the new cvs repository, did names change > between what was in your pc_app/dst and the dst branch of the > repository. In `pc_apps/dst' the classes was named `Br...Dst...'. In the stand-alone package, they are named `Bdst....'. > And if not, are the objects themselves backward compatible > with what was in your branch in the last few months. Nope. Your best choice is to generate interfaces from the TTree (ROOT's StreamerInfo facility), which assumes that Peter & co. used automatic schema evolution all the way through the code. If they didn't you're stuck with Peter's older stuff. > That concerns me because I have a huge number of these dst files now > lying around and regenerating them to get back to where I am now > would require time/effort. Having created the interfaces, it's a simple matter to convert the data to the new classes and store that in some new files, possibly cutting away bogus stuff. > How this last statement figures into my feeling that they should be > called BrPhDS classes is something to discuss over a bottle of wine. I guess you have to fight with Peter about that :-) My, I couldn't give a ... well you know - I don't care, as long as it's consistent! Yours, ____ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 305 ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm | |
This archive was generated by hypermail 2b30 : Fri Aug 23 2002 - 16:38:22 EDT