[Rivet] [Rivet-svn] r2876 - in trunk: . bin include/Rivet/Tools src/Analyses src/Core src/Tools

[Andy Buckley]

Yes, that would be sensible. I think that we should put Python-mapped
functions into the Rivet library to do the correct search behaviour, for
each data type, though, rather than having to implement an explicit
variant in every script.

I'll cover this one... sorry for recent inactivity but I've been *very*
busy with ATLAS things (and dealing with the fallout of my dead
laptop!). I hope that we can release next week -- the things remaining
on my list are

* This path searching thing in scripts (move to the first-match
fallback, except for analysis plugins) -- ANDY
* Provide merged CDF UE 2008 analysis to match final paper rather than
the two conf notes as at present. Don't remove the note versions yet. --
HENDRIK
* Address all Anton's bug reports. The one I'm aware of that remains is
setting the errors in the UA5 particle correlations analysis -- HOLGER,
you wrote it, can you deal with this, please?

Other than wishlist items which will take more time than I have
available now, I think that's all. Any more?

Andy


On 16/02/11 16:50, Frank Siegert wrote:
> Hi democrats,
> 
> Given that we decided to re-instate the old behaviour for the plotting
> case, shouldn't we do this before 1.5.0? Otherwise we'll have a change
> from 1.4.0 -> 1.5.0 and the reverse from 1.5.0 -> 2.0.0.
> 
> Cheers,
> Frank
> 
> On 07/02/11 16:55, Andy Buckley wrote:
>> On 07/02/11 15:08, Frank Siegert wrote:
>>> Hi Andy,
>>>
>>> sorry for the late reply on this.
>>>
>>> On 31/01/11 16:33, Andy Buckley wrote:
>>>> On 31/01/11 15:16, David Grellscheid wrote:
>>>>> Other than Rivet, I can't recall a tool where the env variable
>>>>> completely overrides the builtin path. The builtin always gets pushed
>>>>> back in the search queue, but doesn't get removed.
>>>>
>>>> That's what we used to do and it always caused problems because of
>>>> cases
>>>> where you wanted an analysis with the same name as an existing one, but
>>>> a different behaviour of some kind.
>>>
>>> Is that really a valid use case? If you want to write your own analysis,
>>> why should you be able to call it the same as an existing one?
>>>
>>>> We could change the search behaviour
>>>> (again!) to use that "use first match found" idiom but a) that would
>>>> require restructuring the analysis loader machinery again, and b) it
>>>> would make it easily possible to run the wrong version of an analysis
>>>> just because of search path ordering or similar errors.
>>>
>>> "Wrong version" of the stupidly named analysis from above, or is there a
>>> more valid use case for where that would happen?
>>
>> I am probably still living in the past -- we had some previous cases
>> where this was required because of nasty hacks that needed to be applied
>> for tuning, but which we couldn't put into the release. It's not a good
>> argument, and it makes more sense for these weirdo requirements to be
>> the ones that should be worked around :)
>>
>> I think there is a consensus that the "use first version found"
>> behaviour would be a good one, so I withdraw all my flimsy objections. I
>> think we should assign this as a development task for release 2.0.0 --
>> some restructuring of the analysis loader system (damn, I thought I
>> would never have to look at that again) will be needed, and I don't
>> think we should delay the physics-driven version 1.5.0 to implement this
>> feature. But if someone else wants to do it now, and quickly, please
>> do so!
>>
>> See, Rivet design can be a democracy... when it suits me :P
>>
>> Andy
>> ~BDFL
>>
> 


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.