> Actually, these two approaches are slightly different I guess:
> - the installation script you are linking manages the
> installation and the subsequent steps, but doesn't manage the dependencies: for instance on my machine, it didn't find root and so manalyzer
> is built without root support.
> Maybe this is just something to adapt?

Yes indeed. From your perspective, you probably always want ROOT with MIDAS. But at PSI here we have several installation where we do not
need ROOT. These are mainly beamline control PCs which just connect to EPICS or pump station controls replacing Labview installations. All
graphics there is handled with the new mplot graphs which is better in some case.

I therefore added a check into install.sh which tells you explicitly if ROOT is found and included or not. Then it's up to the user to choose to
install ROOT or not.

> Brew on the other hand manages root and so knows how to link these two
> together.

If you really need it, yes.

> - The nice thing I like about brew is that one can "ship bottles" aka compiled version of the code; it is great and fast for
> deployment and avoid compilation issues.
> - I like that your setup does deploy and launch all the necessary executables ! I know brew can do
> this too via brew services (see an example here: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/r/rabbitmq.rb#L83 ), maybe worth
> investigating...?

Indeed this is an advantage of brew, and I wholeheartedly support it therefore. If you decide to support this for the midas
community, I would like you to document it at 

  https://daq00.triumf.ca/MidasWiki/index.php/Installation

Please talk to Ben <bsmith@triumf.ca> who manages the documentation and can give you write access there. The downside is that you will
then become the supporter for the brew and all user requests will be forwarded to you as long as you are willing to maintain the package ;-)

> - Brew relies on code tagging to better manage the bottles, so that it uses the tag to get a well-defined version of the
> code and give a name to the version.
> I had to implement my own tags e.g. midas-mod-2025-12-a to get a release.
> I am not sure how to do in the
> case of midas where the tags are not that frequent...

Yes we always struggle with the tagging (what is a "release", when should we release, ...). Maybe it's the simplest if we tag once per month
blindly with midas-2026-02a or so. In the past KO took care of the tagging, he should reply here with his thoughts.


> Thank you for the feedback, I will make the modifications (aka naming my formula
> ``midas-mod'') so that it doesn't collide with a future official midas one.

Nope. The idea is that YOU do the future official midas realize from now on ;-)


> Concerning the MidasConfig.cmake issue, this is what I need ...

Let's take this offline not to spam others.

Best,
Stefan

Thanks Stefan!
Actually, these two approaches are slightly different I guess:
- the installation script you are linking manages the
installation and the subsequent steps, but doesn't manage the dependencies: for instance on my machine, it didn't find root and so manalyzer
is built without root support.
Maybe this is just something to adapt?
Brew on the other hand manages root and so knows how to link these two
together.
- The nice thing I like about brew is that one can "ship bottles" aka compiled version of the code; it is great and fast for
deployment and avoid compilation issues.
- I like that your setup does deploy and launch all the necessary executables ! I know brew can do
this too via brew services (see an example here: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/r/rabbitmq.rb#L83 ), maybe worth
investigating...?
- Brew relies on code tagging to better manage the bottles, so that it uses the tag to get a well-defined version of the
code and give a name to the version.
I had to implement my own tags e.g. midas-mod-2025-12-a to get a release.
I am not sure how to do in the
case of midas where the tags are not that frequent...

Thank you for the feedback, I will make the modifications (aka naming my formula
``midas-mod'') so that it doesn't collide with a future official midas one.

Concerning the MidasConfig.cmake issue, this is what I need
(note that the INTERFACE_INCLUDE_DIRECTORIES is pointing to 
/opt/homebrew/Cellar/midas/midas-mod-2025-12-a/)

set_target_properties(midas::midas PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "HAVE_CURL;HAVE_MYSQL;HAVE_SQLITE;HAVE_FTPLIB"
 INTERFACE_COMPILE_OPTIONS "-I/opt/homebrew/Cellar/mariadb/12.1.2/include/mysql;-I/opt/homebrew/Cellar/mariadb/12.1.2/include/mysql/mysql"
 INTERFACE_INCLUDE_DIRECTORIES "/opt/homebrew/Cellar/midas/midas-mod-2025-12-a/;${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "/opt/
homebrew/opt/zlib/lib/libz.dylib;-lcurl;-L/opt/homebrew/Cellar/mariadb/12.1.2/lib/ -lmariadb;/opt/homebrew/opt/sqlite/lib/libsqlite3.dylib"
)

whereas by default INTERFACE_INCLUDE_DIRECTORIES points to the source code location (in the case of brew, something like /private/<some-
hash> ).
Brew deletes the source code at the end of the installation, whereas midas seems to rely on the fact that the source code is still
present...
Does it help?
A way to fix is to search for this ``/private'' path and replace it, but this isn't ideal I guess...
This is what I
did in the midas formula:
--------
# Fix broken CMake export paths if they exist
    cmake_files = Dir["#{lib}/**/*manalyzer*.cmake"]
   cmake_files.each do |file|
      if File.read(file).match?(%r{/private/tmp/midas-[^/"]+})
        inreplace file, %r{/private/tmp/midas-
[^/"]+},
prefix.to_s
      end
      inreplace file, %r{/tmp/midas-[^/"]+}, prefix.to_s if File.read(file).match?(%r{/tmp/midas-[^/"]+})
   end
    cmake_files = Dir["#{lib}/**/*midas*.cmake"]
    cmake_files.each do |file|
      if File.read(file).match?(%r{/private/tmp/midas-
[^/"]+})
        inreplace file, %r{/private/tmp/midas-[^/"]+},
prefix.to_s
      end
      inreplace file, %r{/tmp/midas-[^/"]+},
prefix.to_s if File.read(file).match?(%r{/tmp/midas-[^/"]+})
    end
-----

I guess this code could be changed into some bash commands and
added to your script?

Thank you very much again!
Mathieu


> Hi Mathieu,
> 
> thanks for your contribution. Have you looked at the
install.sh script I developed last week:
> 
>    https://daq00.triumf.ca/MidasWiki/index.php/Install_Script
> 
> which basically does the
same, plus it modifies the environment and installs mhttpd as a service.
> 
> Actually I modeled the installation after the way Homebrew is
installed in the first place (using curl).
> 
> I wonder if the two things can kind of be integrated. Would be great to get with brew always
the newest midas version, and it would also 
> check and modify the environment. 
> 
> If you tell me exactly what is wrong
MidasConfig.cmake.in I'm happy to fix it.
> 
> Best,
> Stefan

Hi Mathieu,

thanks for your contribution. Have you looked at the install.sh script I developed last week:

   https://daq00.triumf.ca/MidasWiki/index.php/Install_Script

which basically does the same, plus it modifies the environment and installs mhttpd as a service.

Actually I modeled the installation after the way Homebrew is installed in the first place (using curl).

I wonder if the two things can kind of be integrated. Would be great to get with brew always the newest midas version, and it would also 
check and modify the environment. 

If you tell me exactly what is wrong MidasConfig.cmake.in I'm happy to fix it.

Best,
Stefan

Dear all,

For my personal convenience, I started to add an homebrew formula
for
midas (*):
https://github.com/guiguem/homebrew-tap/blob/main/Formula/
midas.rb
It
is convenient in particular to deploy as it automatically gets all
the right
dependencies; for MacOS (**), there are bottles already available.

The
installation would then be
brew tap guiguem/tap
brew install midas

I
thought I
would share it here, if this is helpful to someone else (***).
This
was tested
rather extensively, including the development of manalyzer modules
using this
bottled version as backend.
A possible upgrade (if people are
interested) would
be to develop/deploy a "mainstream" midas version (and I would
rename mine
"midas-mod").

Cheers
Mathieu
-----
Notes:
(*) The version installed
by this
formula is a very slightly modified version of midas, designed to
support more
than 100 front-ends (needed for HK).
See commits here:
https://
gitlab.in2p3.fr/
hk/clocks/midas/-/
commit/060b77afb38e38f9a3155d2606860f12d680f4de
https://
gitlab.in2p3.fr/hk/
clocks/midas/-/
commit/1da438ad1946de7ba697e849de6a6675ac45ebb8
I have the
recollection this
version might not be compatible with the main midas one. 

(**) I also have some
stuff for Ubuntu, but Ubuntu seems to do additional
linkage to curl which needs
to be handled (easy).
That being said the
installation from sources works fine!
(***) Some oddities were unraveled such as
the fact that the build_interface
pointing to the source include directory are
still appearing in the
midasConfig.cmake files (leading to issues in brew). This
was fixed by replacing
the faulty path to the final installation location. Maybe
this should be fixed ? 

Tabbed custom pages have been implemented in MIDAS. Below you see and example. The documentation 
is here:

  https://daq00.triumf.ca/MidasWiki/index.php/Custom_Page#Tabbed_Pages

Stefan

Ok thanks for the quick and clear response!

Derek

> MT_DEBUG messages are there for debugging, not logging. They only go into the SYSMSG buffer and NOT to the log file. If you want anything logged, just use MT_INFO.
> 
> Not sure if that's missing in the documentation. Anyhow, there are my original ideas (from 1995 ;-) )
> 
> MT_ERROR  
> Error message, to be displayed in red
> 
> MT_INFO    
>  Info or status message
> 
> MT_DEBUG 
> Only sent to SYSMSG buffer, not to midas.log file. Handy if you produce lots of message and don't want to flood the message file. Plus it does not change the timing of your app, since the SYSMSG buffer is much faster than writing 
> to a file.
> 
> MT_USER
> Message generated interactively by a user, like in the chat window or via the odbedit "msg" command
> 
> MT_LOG
> Messages with are only logged but not put into the SYSMSG buffer
> 
> MT_TALK
> Messages which should go through the speech synthesis in the browser and are "spoken"
> 
> MT_CALL
> Message which would be forwarded to the user via a messaging app (historically this was an actual analog telephone call via a modem ;-) )
> 
> If that is missing in the documentation, please feel free to copy/paste it to the appropriate place.
> 
> 
> Stefan

MT_DEBUG messages are there for debugging, not logging. They only go into the SYSMSG buffer and NOT to the log file. If you want anything logged, just use MT_INFO.

Not sure if that's missing in the documentation. Anyhow, there are my original ideas (from 1995 ;-) )

MT_ERROR  
Error message, to be displayed in red

MT_INFO    
 Info or status message

MT_DEBUG 
Only sent to SYSMSG buffer, not to midas.log file. Handy if you produce lots of message and don't want to flood the message file. Plus it does not change the timing of your app, since the SYSMSG buffer is much faster than writing 
to a file.

MT_USER
Message generated interactively by a user, like in the chat window or via the odbedit "msg" command

MT_LOG
Messages with are only logged but not put into the SYSMSG buffer

MT_TALK
Messages which should go through the speech synthesis in the browser and are "spoken"

MT_CALL
Message which would be forwarded to the user via a messaging app (historically this was an actual analog telephone call via a modem ;-) )

If that is missing in the documentation, please feel free to copy/paste it to the appropriate place.


Stefan

I have an application where I want to (optionally) send my own debugging messages to the midas.log file, but am having some problems with this: 

* Messages with type MT_DEBUG don't show up in midas.log or on the messages page (calling cm_msg from python)
* messages.html is missing the DEBUG filter option
* Messages sent to other log files (not midas.log) don't get message banners on the web page. Is this intentional? 

So I think either there is a bug, or I need to start MIDAS with some flag to enable debugging. Looking at the source, I don't see why these messages wouldn't get logged.

Any insight would be appreciated!

I put the documentation under

  https://daq00.triumf.ca/MidasWiki/index.php/Install_Script

Would be good if anybody could check that.

Stefan

Thanks for your feedback. I reworked the installation script, and now also called it "install.sh" since it includes also the git clone. I modeled it after 
homebrew a mit (https://brew.sh). This means you can now run the script on a prison linux system with:

  /bin/bash -c "$(curl -sS https://bitbucket.org/tmidas/midas/raw/HEAD/install.sh)"

It contains three defaults for MIDASSYS, MIDAS_DIR and MIDAS_EXPT_NAME, but when you run in, you can overwrite these
defaults interactively. The script creates all directories, clones midas, compiles and installs it, installs and runs mhttpd as a system
service, then starts the logger and the example frontend. I also added your PYTHONPATH variable. The RC file is now automatically
detected.

Yes one could add more config files, but I want to have this basic install as simple as possible. If more things are needed, they
should be added as separate scripts or .ODB files.

Please have a look and let me know what you think about. I tested it on a RaspberryPi, but not yet on other systems.

Stefan

Dear Stefan,

That’s a great idea. For a private home automation project using a Raspberry Pi Zero, I used the
following setup:

https://github.com/makoeppel/midasHome/

This server has been running for about a year now
and reports the temperature in my home. Looking at your script, I think we are conceptually doing the same
thing.

I see three parts I would do slightly differently:

1. I would create an .env file to hold the
variables:

export PATH="$HOME/midas/bin:$PATH"
export MIDASSYS="$HOME/midas"
export MIDAS_DIR="$HOME/online"

export MIDAS_EXPT_NAME="Online"


2. For odbedit -c "load midas_setup.odb" > /dev/null
I would consider making
this a bit more explicit (using odbedit) so users can change the configuration if needed—possibly by
introducing a .conf file.

3. In my project, I used the MIDAS Python bindings, which are currently missing in
your script:

export PYTHONPATH=$PYTHONPATH:$MIDASSYS/python


I also have one additional comment regarding
Docker. I think it would make sense to support a Docker image for MIDAS. This would give non-expert users an
even simpler setup. I created a related project some time ago:
https://github.com/makoeppel/midasDocker

I'd
be happy to help with this part as well.

Best regards,
Marius

Since we have no many RaspberryPi based control systems running at our lab with midas, I want to 
streamline the midas installation, such that a non-expert can install it on these devices. 

First, midas has to be cloned under "midas" in the user's home directory with

git clone https://bitbucket.org/tmidas/midas.git --recurse-submodules

For simplicity, this puts midas right into /home/<user>/midas, and not into any "packages" subdirectory 
which I believe is not necessary.

Then I wrote a setup script midas/midas_setup.sh which does the following:

- Add midas environment variables to .bashrc / .zschenv depending on the shell being used

- Compile and install midas to midas/bin

- Load an initial ODB which allows insecure http access to port 8081

- Install mhttpd as a system service and start it via systemctl

Since I'm not a linux system expert, the current file might be a bit clumsy. I know that automatic shell 
detection can be made much more elaborate, but I wanted a script which can easy be understood even by 
non-experts and adapted slightly if needed.

If you know about shell scripts and linux administration, please have a quick look at the attached script 
and give me any feedback.

Stefan

After popular demand and during some quite holidays I implemented ad-hoc history plots. To enable this 
for a certain equipment, put 

  /Equipment/<name>/Settings/History buttons = true

into the ODB. You will then see a graph button after each variable. Pressing this button reveals the history 
for this variable, see attachment.

Stefan

Hello everyone,

Stefan and I have make a few updates to mplot to clean up some of the code and make it more usable directly from Javascript. With one exception this does not change the html interface. The below describes changes up to commit cd9f85c. 

Breaking Changes:

• The idea is to have a "graph" be the overarching figure object, whereas the "plot" is the line or points associated with a single dataset.
  • Some internal variable names have been changed to reflect this while minimizing breaking changes
  • defaultParam renamed defaultGraphParam.
  • There is no longer an initialized defaultParam.plot[0], these defaults are now defaultPlotParam which is a separate global variable
  • MPlotGraph constructor signature MPlotGraph(divElement, param) changed to MPlotGraph(divElement, graphParam)
• HTML key data-bgcolor changed to data-zero-color as the former was misleading

New Features

• New addPlot() function. 
  • While the functionality of setData is preserved you can now use addPlot(plotParam) to add a new plot to the graph with minimal copying of the old defaultParam.plot[0]
  • Minimal example, from plot_example.html: given some div container with id "P6":

       let d = document.getElementById("P6"); // get div 
       d.mpg = new MPlotGraph(d, { title: { text: "Generated" }}); // make graph
       d.mpg.addPlot( { xData: [0, 1, 2, 3, 4], yData: [10, 12, 12, 14, 11] } ); // add plot to the graph

  • modifyPlot() and deletePlot() still to come
• New lines styles: none, solid, dashed, dotted
• Barplot-style category plots

> > Confirmed fixed, thanks! There are 2 small changes I made in odbxx.h, please pull.
> There was one missing enable_jsroot in manalyzer, please pull yourself.

pulled, pushed to rootana, thanks for fixing it!

K.O.

> Confirmed fixed, thanks! There are 2 small changes I made in odbxx.h, please pull.

There was one missing enable_jsroot in manalyzer, please pull yourself.

Stefan

> TFile.h -> TDirectoryFile.h -> TDirectory.h -> TNamed.h -> TString.h -> TMathBase.h -> cmath -> math.h

reading ROOT release notes, 6.38 removed TMathBase.h from TString.h, with a warning "This change may cause errors during compilation of 
ROOT-based code". Upright citizens, nice guys!

> Thanks. Are you happy for me to update the submodule commit in Midas to use this fix? I should have sufficient permission if you agree.

I am doing some last minute tests, will pull it into midas and rootana later today.

K.O.

> > BTW, it looks like we are parsing the whole JSON ODB dump (200k+) on every odbxx access. Can you parse it just once?
> You are right. I changed the code so that the dump is only parsed once. Please give it a try.

Confirmed fixed, thanks! There are 2 small changes I made in odbxx.h, please pull.

K.O.

Thanks. Are you happy for me to update the submodule commit in Midas to use this fix? I should have sufficient permission if you agree.

> > /code/midas/manalyzer/manalyzer.cxx:799:27: error: ‘pow’ was not declared in this scope
> >   799 |       bins[i] = TimeRange*pow(1.1,i)/pow(1.1,Nbins);
> 
> math.h added, pushed. nice catch.
> 
> implicit include of math.h came through TFile.h (ROOT v6.34.02), perhaps you have a newer ROOT
> and they jiggled the include files somehow.
> 
> TFile.h -> TDirectoryFile.h -> TDirectory.h -> TNamed.h -> TString.h -> TMathBase.h -> cmath -> math.h
> 
> K.O.

> BTW, it looks like we are parsing the whole JSON ODB dump (200k+) on every odbxx access. Can you parse it just once?

You are right. I changed the code so that the dump is only parsed once. Please give it a try.

Stefan