| ID |
Date |
Author |
Topic |
Subject |
|
3024
|
02 Apr 2025 |
Konstantin Olchanski | 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
> > is better.
>
> if it came to a vote, my vote would go to Lua: it would allow to do everything needed,
> with much less external dependencies and with much less motivation to over-use the interpreter.
> The CMS experience was very teaching in this respect...
Unfortunately I am only slightly aware of Lua to say how nicve or how bad it is. And we are
not sure how well it supports the single-line-stepping that permits the nice graphical
visualization of Stefan's sequencer.
It looks like python has the single-line-stepping built-in as a standard feature
and python is a more popular and more versatile machine, so to me python looks
like a better choice compared to lua (obscure), perl ("nobody uses it anymore")
or bash (ugly syntax).
K.O. |
|
3025
|
02 Apr 2025 |
Stefan Ritt | Suggestion | Sequencer ODBSET feature requests | And there is one more argument:
We have a Python expert in our development team who wrote already the Python-to-C bindings. That means when running a Python
script, we can already start/stop runs, write/read to the ODB etc. We only have to get the single stepping going which seems feasible to
me, since there are some libraries like inspect.currentframe() and traceback.extract_stack(). For single-stepping there are debug APIs
like debugpy. With Lua we really would have to start from scratch.
Stefan |
|
3026
|
07 Apr 2025 |
Zaher Salman | Suggestion | Sequencer ODBSET feature requests |
| Lukas Gerritzen wrote: |
I also encountered a small annoyance in the current workflow of editing sequencer files in the browser:
- Load a file
- Double-click it to edit it, acknowledge the "To edit the sequence it must be opened in an editor tab" dialog
- A new tab opens
- Edit something, click "Start", acknowledge the "Save and start?" dialog (which pops up even if no changes are made)
- Run the script
- Double-click to make more changes -> another tab opens
After a while, many tabs with the same file are open. I understand this may be considered "user error", but perhaps the sequencer could avoid opening redundant tabs for the same file, or prompt before doing so?
Thanks for considering these suggestions! |
The original reason the restricting edits in the first tab is that it is used to reflect the state of the sequencer, i.e. the file that is currently loaded in the ODB.
Imagine two users are working in parallel on the same file, each preparing their own sequence. One finishes editing and starts the sequencer. How would the second person know that by now the file was changed and is running?
I am open to suggestions to minimize the number of clicks and/or other options to make the first tab editable while making it safe and visible to all other users. Maybe a lock mechanism in the ODB can help here.
Zaher |
|
3027
|
07 Apr 2025 |
Stefan Ritt | Suggestion | Sequencer ODBSET feature requests | If people are simultaneously editing scripts this is indeed an issue, which probably never can be resolved by technical means. It need communication between the users.
For the main script some ODB locking might look like:
- First person clicks on "Edit", system checks that file is not locked and sequencer is not running, then goes into edit mode
- When entering edit mode, the editor puts a lock in to the ODB, like "Scrip lock = pc1234".
- When another person clicks on "Edit", the system replies "File current being edited on pc1234"
- When the first person saves the file or closes the web browser, the lock gets removed.
- Since a browser can crash without removing a lock, we need some automatic lock recovery, like if the lock is there, the next users gets a message "file currently locked. Click "override" to "steal" the lock and edit the file".
All that is not 100% perfect, but will probably cover 99% of the cases.
There is still the problem on all other scripts. In principle we would need a lock for each file which is not so simple to implement (would need arrays of files and host names).
Another issue will arise if a user opens a file twice for editing. The second attempt will fail, but I believe this is what we want.
A hostname for the lock is the easiest we can get. Would be better to also have a user name, but since the midas API does not require a log in, we won't have a user name handy. At it would be too tedious to ask "if you want to edit this file, enter your username".
Just some thoughts.
Stefan |
|
3042
|
19 May 2025 |
Jonas A. Krieger | Suggestion | manalyzer root output file with custom filename including run number | Hi all,
Would it be possible to extend manalyzer to support custom .root file names that include the run number?
As far as I understand, the current behavior is as follows:
The default filename is ./root_output_files/output%05d.root , which can be customized by the following two command line arguments.
-Doutputdirectory: Specify output root file directory
-Ooutputfile.root: Specify output root file filename
If an output file name is specified with -O, -D is ignored, so the full path should be provided to -O.
I am aiming to write files where the filename contains sufficient information to be unique (e.g., experiment, year, and run number). However, if I specify it with -O, this would require restarting manalyzer after every run; a scenario that I would like to avoid if possible.
Please find a suggestion of how manalyzer could be extended to introduce this functionality through an additional command line argument at
https://bitbucket.org/krieger_j/manalyzer/commits/24f25bc8fe3f066ac1dc576349eabf04d174deec
Above code would allow the following call syntax: ' ./manalyzer.exe -O/data/experiment1_%06d.root --OutputNumbered '
But note that as is, it would fail if a user specifies an incompatible format such as -Ooutput%s.root .
So a safer, but less flexible option might be to instead have the user provide only a prefix, and then attach %05d.root in the code.
Thank you for considering these suggestions! |
|
3047
|
27 May 2025 |
Pavel Murat | Suggestion | handling of 2+ like-long messages | Dear MIDAS experts,
currently, the MIDAS messaging system is optimized for one-line long messages,
so the content of 2+liners shows up in the message log in the reverse order,
with the first line on the bottom of the message.
I wonder if printing the message content in the reverse order, starting from the last line,
would make sense ? - that wouldn't affect one-line long messages, but could make longer
messages more useful.
--thanks, regards, Pasha |
|