GSI Forum - RDF feed
type: channel
description: GSI Helmholtzzentrum für Schwerionenforschung
items: Abandonware
items: Re: Abandonware
items: Removed obsolete packages

Abandonware
type: item
description: I am wondering if it is the case to remove from the PandaRoot root directory all those packages which are now obsolete. These are, if I have understood well: bfield (obsolete, now field is the official one) stt1 (obsolete, now stt is the official one) stt2 (obsolete, now stt is the official one) fsc (it is now included inside emc) I think it is meaningless to continue to download and compile code that we do not use anymore. Maybe it could be the case to create an "archive" directory that is not downloaded from svn, where we can put all these obsolete packages. Comments and ideas are welcome Ste
creator: StefanoSpataro
date: 2007-08-17T10:37:23-00:00

Re: Abandonware
type: item
description: No objections from my side concerning fsc. ola
creator: Aleksandra Wronska
date: 2007-08-17T10:52:42-00:00

Re: Abandonware
type: item
description: I perfectly agree with you, Pablo
creator: Pablo Genova
date: 2007-08-21T10:23:18-00:00

Re: Abandonware
type: item
description: Dear all, I removed from the main makefile the libraries stt1 stt2 fsc and bfield, and I added stt (that was missing before) and tof. Even the Dart.sh file should be updated. I will keep them for another week, then I will delete them. Stt package was never compiled before under Dashboard, so all the deprecated warings are still there. There are 19 warnings still existing, could you please remove them? I could do it, if you agree, but there is one warning (the last one) that I could not understand. Thanks
creator: StefanoSpataro
date: 2007-08-22T15:49:22-00:00

Re: Abandonware
type: item
description: Hi Stefano, I fixed the trivial warnings due to the deprecated headers and committed to svn. Now you should see only 2 warnings, which I do not know how to fix. One is /data10/pablo/tmp/pandaroot/stt/CbmSttTrackFinderIdeal.cxx: In member function `virtual Int_t CbmSttTrackFinderIdeal::DoFind(TClonesArray*)': /data10/pablo/tmp/pandaroot/stt/CbmSttTrackFinderIdeal.cxx:202: warning: passing `Double_t' for argument 1 of `_Tp& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with _Key = Int_t, _Tp = Int_t, _Compare = std::less<Int_t>, _Alloc = std::allocator<std::pair<const Int_t, Int_t> >]' and the other is /data10/pablo/tmp/pandaroot/stt/CbmSttHelixTrackFitter.cxx: In member function `virtual Int_t CbmSttHelixTrackFitter::DoFit(CbmSttTrack*, int)': /data10/pablo/tmp/pandaroot/stt/CbmSttHelixTrackFitter.cxx:168: warning: NULL used in arithmetic due to a control like (function() !=NULL). I do not know how to fix them, I'm surprised of the latter because it is quite common that one checks if a pointer is not null, so I do not know how to keep the test but eliminate the warning. ciao, Pablo
creator: Pablo Genova
date: 2007-08-23T14:00:37-00:00

Re: Abandonware
type: item
description: Hi, I will check the first one. For the second one I think the problem is that you are not comparing a pointer, but a number. Indeed in the expression: (pTrack->GetParamLast()->GetTx()) != NULL pTrack is a pointer to a CbmSttTrack, pTrack->GetParamLast() is a pointer to a CbmTrackParam, but pTrack->GetParamLast()->GetTx() is a double so a number! Maybe you should remove GetTx or something else, to clean that condition. P.S. I removed the headers in tof code
creator: StefanoSpataro
date: 2007-08-23T14:47:12-00:00

Re: Abandonware
type: item
description: Stefano, you are perfectly right! That check was completely meaningless . Now it has been properly modified ((..)>0). Thank you very much for the remark. Pablo
creator: Pablo Genova
date: 2007-08-23T15:02:19-00:00

Re: Abandonware
type: item
description: About the first warning, this is not so clear to me. You define hitMap as: map<Int_t, map<Int_t, Int_t> > hitMap; Then: Double_t wireX = pMhit->GetX(), wireY = pMhit->GetY(); (hitMap[mcTrackIndex])[wireX * wireX + wireY * wireY]++; The map is <Int_t, Int_t> but then you give one index as [double]. I think you can (one of the two) a) correct the map putting one double inside (map<Int_t, Double_t>) b) overcast the wire id (Int_t)(wireX * wireX + wireY * wireY) Just at a first sight the first should be the correct one, in each case I am wondering how does it work with this int/double ambiguity...
creator: StefanoSpataro
date: 2007-08-23T15:04:01-00:00

Re: Abandonware
type: item
description: the map has been corrected according to method a), the plots of the standard reconstruction macros are OK. ciao, Pablo
creator: Pablo Genova
date: 2007-08-27T11:07:48-00:00

Re: Abandonware
type: item
description: Ladies and Gentlemen, I am proud to announce that for the first time in the PandaRoot life we have absolutely NO WARNING at all!! Let's hope to keep this profile as long as possible ... Bye
creator: StefanoSpataro
date: 2007-08-27T11:40:29-00:00

Removed obsolete packages
type: item
description: Hello, the obsolete packages since revision 1496 are removed from the repository. If somebody wants to retrieve the old code, he should call the revision 1495 (or below). Regards
creator: StefanoSpataro
date: 2007-09-13T12:24:40-00:00