Javier Galan
Javier Galan
Yes! Perhaps those pieces of code would better find the way to settle in `detectorlib` by creating new `TRestDetectorRecoverSignalProcess` and`TRestDetectorChannelActivityProcess`, since they need the `TRestDetectorReadout`. In that sense it is...
For drawing methods I agree that we should have a common classes directly inside the framework. Then, those methods would be inherit by the existing event types. We could have...
It looks as the compilation error is related with `Bool_t` and `bool` types? Perhaps the `const` is causing problems here? ``` /builds/rest-for-physics/framework/source/framework/tools/inc/TRestReflector.h:471:84: error: invalid conversion from 'Bool_t (*)(const string&)' {aka...
BTW, `solarSeed` on the attached file should be simply `seed`. I was doing a test changing the parameter name, but it did not affect.
Ok, I understand now what it is happening. We have a condition, if the energy is above a given value, then the process will return `nullptr`. I thought this would...
However, in other processes this is done like that `if (ApplyCut()) return nullptr;`
I found a way to bypass the problem, but the issue it is still there. Why when we `return nullptr` the event processing stops instead of just skipping the event?
This PR is not yet merged?
@juanangp should this be merged together with rest-for-physics/rawlib#71?
Perhaps we could then re-organize `TRestTools` and `TRestStringHelper` and move to something like `TRestFiletools` `TRestStringTools`, `TRestFrameworkTools`m `TRestTools`, ...