| ID |
Date |
Author |
Topic |
Subject |
Text |
 |
|
3022
|
02 Apr 2025 |
Pavel Murat | Bug Report | MIDAS history system not using the event timestamps ? | > You can always include your "true" data
timestamp as the first value in your data.
|
|
|
3021
|
01 Apr 2025 |
Pavel Murat | Suggestion | Sequencer ODBSET feature requests | I once looked at using LUA for this,
> but I think basing off an full featured
programming language like python
|
|
|
3020
|
01 Apr 2025 |
Konstantin Olchanski | Bug Report | MIDAS history system not using the event timestamps ? | > I confirm that when writing out history
files corresponding to the slow control event
data,
|
|
|
3019
|
01 Apr 2025 |
Konstantin Olchanski | Suggestion | Sequencer ODBSET feature requests | > ODBSET "/Path/value[1,3,5]"
> ODBSET "/Path/value[1-5,7-9]"
|
|
|
3018
|
01 Apr 2025 |
Konstantin Olchanski | Bug Report | ODB corruption | We see ODB corruption crashes in the DS20k
vertical slice MIDAS instance.
|
|
|
3017
|
01 Apr 2025 |
Konstantin Olchanski | Bug Fix | ODB and event buffer - release semaphore before abort() and core dump | There is a long standing problem with ODB
and event buffers. If they detect an
internal data inconsistency and cannot continue |
|
|
3016
|
01 Apr 2025 |
Stefan Ritt | Suggestion | Sequencer ODBSET feature requests | The extended ODBSET[x,y1-y2,z] could make
sense to be implemented, since it then will
match the alarm system which uses the same |
|
|
3015
|
01 Apr 2025 |
Stefan Ritt | Suggestion | Sequencer ODBSET feature requests | A new sequencer which understands Python is
in the works. There you can use all features
from that language.
|
|
|
3014
|
01 Apr 2025 |
Lukas Gerritzen | Suggestion | Sequencer ODBSET feature requests | While trying to simplify the existing spaghetti
code, I encountered problems with type safety.
Compare the following:
|
|
|
3013
|
01 Apr 2025 |
Lukas Gerritzen | Suggestion | Sequencer ODBSET feature requests | I would like to request the following sequencer
features if you find the ideas as sensible
as I do:
|
|
|
3012
|
01 Apr 2025 |
Pavel Murat | Bug Report | MIDAS history system not using the event timestamps ? | Dear MIDAS experts,
I confirm that when writing out history files |
|
|
3011
|
30 Mar 2025 |
Konstantin Olchanski | Bug Fix | manalyzer improvements | updated manalyzer:
- similar to --jsroot switch, in online mode, |
|
|
3010
|
28 Mar 2025 |
Konstantin Olchanski | Bug Fix | manalyzer -R8082 --jsroot | When processing MIDAS files offline, JSROOT
did not work, -Rxxx worked, http
connection would open, but would not serve |
|
|
3009
|
28 Mar 2025 |
Konstantin Olchanski | Suggestion | improved find_package behaviour for Midas | I figured out the breakage, added a git tag
to identify where the cmake incompatible
change was made (roughly)
|
|
|
3008
|
28 Mar 2025 |
Konstantin Olchanski | Bug Fix | midas cmake update | MIDAS git tag midas-2025-01-a introduced an
incompatible change to "include midas-targets.cmake".
Instead of "midas" one now has to
|
|
|
3007
|
28 Mar 2025 |
Konstantin Olchanski | Info | mjsroot added | I need to look at histograms inside a ROOT
file, but all the old ways for doing this
no longer work. (in theory I can scp the |
|
|
3006
|
28 Mar 2025 |
Konstantin Olchanski | Forum | TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file | I do not understand what you are doing. If
you are offline, there is no TMFE singleton
instance,
|
|
|
3005
|
26 Mar 2025 |
Mark Grimes | Forum | TMFeRpcHandlerInterface::HandleEndRun when running offline on a Midas file | This was exactly the question, should I expect
it to run? There's no point in the HandleBinaryRpc
method offline, but there's an argument that |
|
|
3004
|
25 Mar 2025 |
Konstantin Olchanski | Bug Report | Default write cache size for new equipments breaks compatibility with older equipments | > > All this is kind of reasonable, as only
two settings of write cache size are useful:
0 to
|
|
|
3003
|
25 Mar 2025 |
Konstantin Olchanski | Bug Report | please fix mscb compiler warning | > I hopefully fixed the waring (narrowing
down from size_t to int). Please double check
with your compiler.
|
|