Back Midas Rome Roody Rootana
  Root Analyzer Framework, Page 2 of 3  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Topicup Subject
  35   05 Feb 2021 Konstantin OlchanskiForumana or manalyzer?
> reworking our old (MuCap inherited) mana.cpp
> To have a good start, what is advised:
> a) following the Rootana Analyzer Framework as advertised in https://midas.triumf.ca/MidasWiki/index.php/Rootana_Analyzer_Framework with the TRootanaEventLoop
> b) The manalyzer advertised in https://bitbucket.org/tmidas/rootana/src/master/manalyzer/
> Option b) with it's module support?

It depends on your experiment and your data. If your data is just a few numbers,
either analyzer would do (even the old midas mana.c analyzer would do).

But if you have complicated data, especially streaming data, where midas events
and physics events do not have a 1-to-1 connection, the old analyzers will
not cut the mustard. I have done this kind of processing in the old analyzers,
came up with a generalized structure, the "m" analyzer is the result.

Historical note: I developed rootana maybe 15 years ago to process data
from the ALPHA experiment at CERN (anti-hydrogen trap), more recently, I developed
manalyzer to process more complicated data from the ALPHA-g experiment at CERN (vertical
anti-hydrogen trap, to study gravity effects). Joseph McKenna from CERN contributed
the automatic by-module multithreading and benchmarking.

To compare:

- both rootana and manalyzer use the same TMidasOnline class for connecting to live MIDAS data
- both use the same midasio classes to read and write MIDAS files
- rootana uses the older TMidasEvent class to access MIDAS banks
- manalyzer uses the newer TMEvent class. the main improvement is that TMEvent is
a well-behaved C++ class with a usable assignment and copy-constructor operators.
- graphics and web interface uses the same ROOT graphics, ROOT web server (a derivative
of mongoose web server library) and the same JS-ROOT.
- the manalyzer has better defined control flow and C++ object lifetime rules
wrt run start and run end (this corrects problems with life time of C++ objects
in the old rootana).
- manalyzer has automatic per-module multithreading "for free" (thanks, Joseph!),
I typically see the alphag analyzer use 8-10 CPU threads without having to use
any threading or mutex gunk in the analysis code.

The current plan is to include manalyzer into MIDAS as a git submodule, with luck
it will happen for the next midas release, the hold up is with the midasio class that needs
to be updated, git-submoduled and added to midas. Also the old TMidasOnline class needs
updating.

To conclude, we use manalyzer for ALPHA-2 and ALPHA-g, people who use it seem to be
generally happy (especially with the automatic per-module multithreading), we use
it for a couple of simpler experiments at TRIUMF.

I hope this answers your questions?

K.O.
  36   05 Feb 2021 Frederik WautersForumana or manalyzer?
yes, thanks! 

" manalyzer has automatic per-module multithreading "for free"  "

does that mean that if one needs modules to run sequentially (think first clustering, then making higher level physics objects), the user needs to enforce that?

> > reworking our old (MuCap inherited) mana.cpp
> > To have a good start, what is advised:
> > a) following the Rootana Analyzer Framework as advertised in https://midas.triumf.ca/MidasWiki/index.php/Rootana_Analyzer_Framework with the TRootanaEventLoop
> > b) The manalyzer advertised in https://bitbucket.org/tmidas/rootana/src/master/manalyzer/
> > Option b) with it's module support?
> 
> It depends on your experiment and your data. If your data is just a few numbers,
> either analyzer would do (even the old midas mana.c analyzer would do).
> 
> But if you have complicated data, especially streaming data, where midas events
> and physics events do not have a 1-to-1 connection, the old analyzers will
> not cut the mustard. I have done this kind of processing in the old analyzers,
> came up with a generalized structure, the "m" analyzer is the result.
> 
> Historical note: I developed rootana maybe 15 years ago to process data
> from the ALPHA experiment at CERN (anti-hydrogen trap), more recently, I developed
> manalyzer to process more complicated data from the ALPHA-g experiment at CERN (vertical
> anti-hydrogen trap, to study gravity effects). Joseph McKenna from CERN contributed
> the automatic by-module multithreading and benchmarking.
> 
> To compare:
> 
> - both rootana and manalyzer use the same TMidasOnline class for connecting to live MIDAS data
> - both use the same midasio classes to read and write MIDAS files
> - rootana uses the older TMidasEvent class to access MIDAS banks
> - manalyzer uses the newer TMEvent class. the main improvement is that TMEvent is
> a well-behaved C++ class with a usable assignment and copy-constructor operators.
> - graphics and web interface uses the same ROOT graphics, ROOT web server (a derivative
> of mongoose web server library) and the same JS-ROOT.
> - the manalyzer has better defined control flow and C++ object lifetime rules
> wrt run start and run end (this corrects problems with life time of C++ objects
> in the old rootana).
> - manalyzer has automatic per-module multithreading "for free" (thanks, Joseph!),
> I typically see the alphag analyzer use 8-10 CPU threads without having to use
> any threading or mutex gunk in the analysis code.
> 
> The current plan is to include manalyzer into MIDAS as a git submodule, with luck
> it will happen for the next midas release, the hold up is with the midasio class that needs
> to be updated, git-submoduled and added to midas. Also the old TMidasOnline class needs
> updating.
> 
> To conclude, we use manalyzer for ALPHA-2 and ALPHA-g, people who use it seem to be
> generally happy (especially with the automatic per-module multithreading), we use
> it for a couple of simpler experiments at TRIUMF.
> 
> I hope this answers your questions?
> 
> K.O.
  37   06 Feb 2021 Frederik WautersForumana or manalyzer?
ok, nevermind, it's in the help

" -mt: Enable multithreaded mode. Extra multithread config settings: "
  38   22 Mar 2021 Isaac Labrie BoulayForumManalyzer - Preventing BeginRun() from getting called when I stop the run.
Hi all,

I am running an analyzer using an manalyzer templates and the analysis seems to 
lag behind the events getting stored in the buffer by my frontend. This is because 
the live histogram (-g) is very slow to update and draw. The slight delay causes a 
run object to be created after I 'stop' the acquisition. I'm guessing that this is 
because there are still MIDAS events in the ring buffer. This causes the 
BeginRun() methods of all my modules to get called again.

What is the best way to prevent this? From what I understand, PreEndRun() methods 
should only be used to clear buffered flow events. Is there maybe a way to speed 
up the histogram drawing so that I don't get this lag in the analysis?

Any help will be greatly appreciated.

Thanks so much for your time.

Isaac
  40   12 Apr 2021 Gennaro TortoneForumrootana and TAnaManager
Hi,

I'm facing with a strange problem with rootana:
I fetched and built rootana (master branch) as usual (make / make install);

If I build 'examples' and launch:

./root_server.exe -v

I got a lot of this messages:

Info in <TCling::LoadPCM>: In-memory ROOT PCM candidate /opt/root/lib/.....

and at the end:


 *** Break *** segmentation violation
 Generating stack trace...
 0x00007f9a876a7df1 in ROOT::AddClassAlternate(char const*, char const*) + 0x31 
from /opt/root/lib/root/libCore.so
 0x0000557debfea956 in <unknown> from ./root_server.exe
 0x0000557debfead72 in <unknown> from ./root_server.exe
 0x0000557debfead9b in <unknown> from ./root_server.exe
 0x0000557dec034605 in __libc_csu_init + 0x45 from ./root_server.exe
 0x00007f9a856e802a in __libc_start_main + 0x7a from /lib/x86_64-linux-
gnu/libc.so.6
 0x0000557debf759fa in _start + 0x2a from ./root_server.exe


I'm using ROOT 6.22/06 compiled from source files on Debian 10 on a virtual
machine...

The problem seems to be less critical if I connect with SSH with -XC option
or if I set DISPLAY variable. In these case I got only TCling messages with
this warning:

Error in <TGClient::TGClient>: can't open display "0:0", switching to batch 
mode...
 In case you run from a remote ssh session, reconnect with ssh -Y

If I build manalyzer everything goes fine and it seems that problem is
related to TAnaManager in some ways...

Regards,
Gennaro
  41   15 Apr 2021 Thomas LindnerForumrootana and TAnaManager
Hi,

Hmm, unfortunately I cannot produce your seg fault.  I run the command 

./root_server.exe 

and it runs without a seg-fault.  I can run it with the following combinations:

1) Centos-7.7 with ROOT 6.18
2) Ubuntu 20.04.2 with ROOT 6.22/02

Note that I don't think 'root_server.exe -v' is a valid option.

I will try to make a ROOT 6.22/06 version sometime, but it seems surprising that that is the problem.  This ROOT 
application stuff is annoying and I will try to remove it soon.

I do get the same annoying Cling errors as you.  They are annoying, but seem to be benign.

Cheers,
Thomas



> Hi,
> 
> I'm facing with a strange problem with rootana:
> I fetched and built rootana (master branch) as usual (make / make install);
> 
> If I build 'examples' and launch:
> 
> ./root_server.exe -v
> 
> I got a lot of this messages:
> 
> Info in <TCling::LoadPCM>: In-memory ROOT PCM candidate /opt/root/lib/.....
> 
> and at the end:
> 
> 
>  *** Break *** segmentation violation
>  Generating stack trace...
>  0x00007f9a876a7df1 in ROOT::AddClassAlternate(char const*, char const*) + 0x31 
> from /opt/root/lib/root/libCore.so
>  0x0000557debfea956 in <unknown> from ./root_server.exe
>  0x0000557debfead72 in <unknown> from ./root_server.exe
>  0x0000557debfead9b in <unknown> from ./root_server.exe
>  0x0000557dec034605 in __libc_csu_init + 0x45 from ./root_server.exe
>  0x00007f9a856e802a in __libc_start_main + 0x7a from /lib/x86_64-linux-
> gnu/libc.so.6
>  0x0000557debf759fa in _start + 0x2a from ./root_server.exe
> 
> 
> I'm using ROOT 6.22/06 compiled from source files on Debian 10 on a virtual
> machine...
> 
> The problem seems to be less critical if I connect with SSH with -XC option
> or if I set DISPLAY variable. In these case I got only TCling messages with
> this warning:
> 
> Error in <TGClient::TGClient>: can't open display "0:0", switching to batch 
> mode...
>  In case you run from a remote ssh session, reconnect with ssh -Y
> 
> If I build manalyzer everything goes fine and it seems that problem is
> related to TAnaManager in some ways...
> 
> Regards,
> Gennaro
  42   15 Apr 2021 Gennaro TortoneForumrootana and TAnaManager
Hi,

thanks for your support,

I realized that this issue is related to GCC/G++ version...
it seems that GCC 8.3 has this "segmentation violation" problem;

I have replaced default Debian GCC (8.3) with testing GCC 10 and
everything works !

Now I'm using a Xubuntu 20.04 LTS (GCC 9) and also here the problem
is not present...

Regards,
Gennaro

> Hi,
> 
> Hmm, unfortunately I cannot produce your seg fault.  I run the command 
> 
> ./root_server.exe 
> 
> and it runs without a seg-fault.  I can run it with the following combinations:
> 
> 1) Centos-7.7 with ROOT 6.18
> 2) Ubuntu 20.04.2 with ROOT 6.22/02
> 
> Note that I don't think 'root_server.exe -v' is a valid option.
> 
> I will try to make a ROOT 6.22/06 version sometime, but it seems surprising that that is the problem.  This ROOT 
> application stuff is annoying and I will try to remove it soon.
> 
> I do get the same annoying Cling errors as you.  They are annoying, but seem to be benign.
> 
> Cheers,
> Thomas
> 
> 
> 
> > Hi,
> > 
> > I'm facing with a strange problem with rootana:
> > I fetched and built rootana (master branch) as usual (make / make install);
> > 
> > If I build 'examples' and launch:
> > 
> > ./root_server.exe -v
> > 
> > I got a lot of this messages:
> > 
> > Info in <TCling::LoadPCM>: In-memory ROOT PCM candidate /opt/root/lib/.....
> > 
> > and at the end:
> > 
> > 
> >  *** Break *** segmentation violation
> >  Generating stack trace...
> >  0x00007f9a876a7df1 in ROOT::AddClassAlternate(char const*, char const*) + 0x31 
> > from /opt/root/lib/root/libCore.so
> >  0x0000557debfea956 in <unknown> from ./root_server.exe
> >  0x0000557debfead72 in <unknown> from ./root_server.exe
> >  0x0000557debfead9b in <unknown> from ./root_server.exe
> >  0x0000557dec034605 in __libc_csu_init + 0x45 from ./root_server.exe
> >  0x00007f9a856e802a in __libc_start_main + 0x7a from /lib/x86_64-linux-
> > gnu/libc.so.6
> >  0x0000557debf759fa in _start + 0x2a from ./root_server.exe
> > 
> > 
> > I'm using ROOT 6.22/06 compiled from source files on Debian 10 on a virtual
> > machine...
> > 
> > The problem seems to be less critical if I connect with SSH with -XC option
> > or if I set DISPLAY variable. In these case I got only TCling messages with
> > this warning:
> > 
> > Error in <TGClient::TGClient>: can't open display "0:0", switching to batch 
> > mode...
> >  In case you run from a remote ssh session, reconnect with ssh -Y
> > 
> > If I build manalyzer everything goes fine and it seems that problem is
> > related to TAnaManager in some ways...
> > 
> > Regards,
> > Gennaro
  43   20 Apr 2021 Thomas LindnerForumrootana and TAnaManager
Hi Gennaro,

Thanks for the update.  Good that you got it working, but not so good that it doesn't work on some compilers.

I will still try to remove the TApplication stuff which isn't needed for this particular program.

Cheers,
Thomas

 
> Hi,
> 
> thanks for your support,
> 
> I realized that this issue is related to GCC/G++ version...
> it seems that GCC 8.3 has this "segmentation violation" problem;
> 
> I have replaced default Debian GCC (8.3) with testing GCC 10 and
> everything works !
> 
> Now I'm using a Xubuntu 20.04 LTS (GCC 9) and also here the problem
> is not present...
> 
> Regards,
> Gennaro
> 
> > Hi,
> > 
> > Hmm, unfortunately I cannot produce your seg fault.  I run the command 
> > 
> > ./root_server.exe 
> > 
> > and it runs without a seg-fault.  I can run it with the following combinations:
> > 
> > 1) Centos-7.7 with ROOT 6.18
> > 2) Ubuntu 20.04.2 with ROOT 6.22/02
> > 
> > Note that I don't think 'root_server.exe -v' is a valid option.
> > 
> > I will try to make a ROOT 6.22/06 version sometime, but it seems surprising that that is the problem.  This ROOT 
> > application stuff is annoying and I will try to remove it soon.
> > 
> > I do get the same annoying Cling errors as you.  They are annoying, but seem to be benign.
> > 
> > Cheers,
> > Thomas
> > 
> > 
> > 
> > > Hi,
> > > 
> > > I'm facing with a strange problem with rootana:
> > > I fetched and built rootana (master branch) as usual (make / make install);
> > > 
> > > If I build 'examples' and launch:
> > > 
> > > ./root_server.exe -v
> > > 
> > > I got a lot of this messages:
> > > 
> > > Info in <TCling::LoadPCM>: In-memory ROOT PCM candidate /opt/root/lib/.....
> > > 
> > > and at the end:
> > > 
> > > 
> > >  *** Break *** segmentation violation
> > >  Generating stack trace...
> > >  0x00007f9a876a7df1 in ROOT::AddClassAlternate(char const*, char const*) + 0x31 
> > > from /opt/root/lib/root/libCore.so
> > >  0x0000557debfea956 in <unknown> from ./root_server.exe
> > >  0x0000557debfead72 in <unknown> from ./root_server.exe
> > >  0x0000557debfead9b in <unknown> from ./root_server.exe
> > >  0x0000557dec034605 in __libc_csu_init + 0x45 from ./root_server.exe
> > >  0x00007f9a856e802a in __libc_start_main + 0x7a from /lib/x86_64-linux-
> > > gnu/libc.so.6
> > >  0x0000557debf759fa in _start + 0x2a from ./root_server.exe
> > > 
> > > 
> > > I'm using ROOT 6.22/06 compiled from source files on Debian 10 on a virtual
> > > machine...
> > > 
> > > The problem seems to be less critical if I connect with SSH with -XC option
> > > or if I set DISPLAY variable. In these case I got only TCling messages with
> > > this warning:
> > > 
> > > Error in <TGClient::TGClient>: can't open display "0:0", switching to batch 
> > > mode...
> > >  In case you run from a remote ssh session, reconnect with ssh -Y
> > > 
> > > If I build manalyzer everything goes fine and it seems that problem is
> > > related to TAnaManager in some ways...
> > > 
> > > Regards,
> > > Gennaro
  1   10 Mar 2016 Thomas LindnerInfoNew forum for rootana MIDAS analyzer
This is a new forum for discussing the rootana MIDAS analyzer.  

Code is on bitbucket:

https://bitbucket.org/tmidas/rootana

There is also an associated wiki for rootana documentation

https://midas.triumf.ca/MidasWiki/index.php/ROOTANA
  2   10 Mar 2016 Thomas LindnerInfoweb display of MIDAS data using rootana+THttpServer
I have finished a test implementation of a web display for MIDAS online
monitoring.  I have a test version of this display running here:

https://midastestdaq.triumf.ca/CS/webdisplay

(username/pwd: testdaq/testdaq)

The main features of this way of display MIDAS data are:

- An online rootana program that produces ROOT TH1 and TH2 histogram.
- A web server provided by ROOT (THttpServer) which serves up the histogram
information in JSON format.
- A bunch of crude html/javascript that grabs the JSON and plots it using a
couple of third-party javascript plotting packages.

I have written a more detailed description of this procedure (including some
known deficiencies) which is available here

https://midas.triumf.ca/MidasWiki/index.php/Rootana_javascript_displays

The html/javascript for plotting is available in rootana/examples/html.  It
should be noted that this procedure is only weakly coupled to rootana; you could
pretty easily take any program that makes ROOT histograms, add this THttpServer
and re-work my html/javascript to plot it.  Most of the hard-work is already
provided by THttpServer (which incidentally is available in newer versions of
both ROOT5 and ROOT6).

I am imagining the following scenario for using these web tools:

- we use this web-based display of online MIDAS data for a sub-set of key plots
for shift-takers and for remote experts to provide quick feed-back (when you are
on the bus, at the bar, on the ski hill).
- we continue to use some rootana GUI that provides a complete set of all the
online MIDAS plots, as well as the ability to play-back data in MIDAS files.

I can imagine a situation where we might only use the web tools, though I
haven't yet thought seriously about how to allow a play-back of MIDAS files
through web display.

Hopefully people find these tools useful.  I'm interested in all feed-back.
  3   16 Sep 2016 Konstantin OlchanskiInfoROOT v6 status
ROOT v6 has been around for a while now, finally got around to test it with ROOTANA.

a) using root-v6-06-08
b) everything compiles and links
c) the example applications - i.e. display_example.exe - seem to run correctly
d) user applications linked against librootana.a show a problem loading the ROOTANA rdict.pcm files.

Failure to load the rdict.pcm files seems to prevent some functions, at least in the GUIs.

I do not fully understand how ROOT is supposed to find these files and I am asking for help on the ROOT forum.

In the mean time, there is a work around:
- symlink all rdict.pcm files into same place as the executable: ln -sv $ROOTANASYS/*/*.pcm .
- symlink all (many) .h files into the same place (this is a bit extreme): ln -sv $ROOTANASYS/include/* .

K.O.
  4   30 Sep 2016 Konstantin OlchanskiInfoROOT v6 status
> ROOT v6 has been around for a while now, finally got around to test it with ROOTANA.

The problems with loading rdict.pcm files and c++ .h header files is resolved, ROOTANA should be fully usable with ROOTv6:

Put this in your login file:

export ROOTANASYS=$HOME/packages/rootana
export ROOT_INCLUDE_PATH=$ROOTANASYS/include
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTANASYS/obj

Explanation:
- LD_LIBRARY_PATH is used to search for rdict.pcm files.
- ROOT_INCLUDE_PATH is used to find the c++ .h header files.

K.O.
  5   25 Jan 2017 Thomas LindnerInfoweb display of MIDAS data using rootana+THttpServer
I have added some additional features to the example webdisplay that we have for
ROOTANA data (where we are displaying rootana data through ROOT THttpServer).  

The main improvement to the display is that I added the ability to plot the data
using the JSROOT package [1].  Previously I had used different packages (dygraphs
and plot-ly) for plotting.  The JSROOT plots are not obviously superior, though they
do present data in a more familiar way (at least for me).  The rootana webdisplay
currently  allows you to switch between the two different styles.

You can see a working example of the webdisplay here:

https://midastestdaq.triumf.ca/CS/webdisplay
(username/pwd: testdaq/testdaq)

All details on setting up that example are here:

https://midas.triumf.ca/MidasWiki/index.php/Rootana_javascript_displays#Custom_web_display

I'm interested in any feedback on which plotting style people prefer (or any other
aspects of the rootana webdisplay).

[1] https://root.cern/js/
  6   26 Jan 2017 Pierre GorelInfoweb display of MIDAS data using rootana+THttpServer
> I'm interested in any feedback on which plotting style people prefer (or any other
> aspects of the rootana webdisplay).

I personally prefer the ROOT style. It seems that they are equivalent, but it is possible to
change to log scale in X, Y (and Z for 2D) by simple click right on the plot. I cannot find
this feature in plot-ly. Unfortunately, it comes back to linear at the next refresh it seems...
Also, I prefer the 1D histograms as colums, not a segments.
  7   03 May 2017 Alberto RemotoInfoweb display of MIDAS data using rootana+THttpServer
Hi Thomas,

> All details on setting up that example are here:
> 
> https://midas.triumf.ca/MidasWiki/index.php/Rootana_javascript_displays#Custom_web_display

I am trying to test the webdisplay but I am not sure which would be the path:

I start the  THttpServer with:

$ ana.exe -r9091

But on the url:

http://localhost:9091/

I find just the default browser provided by JSROOT, while nothing is found on:

http://localhost:9091/CS/webdisplay

Where am I supposed to find the custom webdisplay provided by you?

Thank you, Alberto.
  8   03 May 2017 Thomas LindnerInfoweb display of MIDAS data using rootana+THttpServer
> 
> Hi Thomas,
> 
> > All details on setting up that example are here:
> > 
> > https://midas.triumf.ca/MidasWiki/index.php/Rootana_javascript_displays#Custom_web_display
> 
> I am trying to test the webdisplay but I am not sure which would be the path:
> 
> I start the  THttpServer with:
> 
> $ ana.exe -r9091
> 
> But on the url:
> 
> http://localhost:9091/
> 
> I find just the default browser provided by JSROOT, while nothing is found on:
> 
> http://localhost:9091/CS/webdisplay
> 
> Where am I supposed to find the custom webdisplay provided by you?

Hi Alberto,

I have added some additional details to the MediaWiki page that you referenced above.  The main point is as follows:

1) You need to setup a custom MIDAS webpage to point towards the example code in 
rootana/examples/html/generic_webdisplay.html
This means you need to add new entries to the ODB directory /Custom

2) The 'same-origin policy' means that you need to setup some sort of proxying so that the custom web page can access the 
ROOT webpage.  So, let's suppose in your case that you had the following ports for web servers:

ROOT webserver: localhost:9091
MIDAS webserver: localhost:8081

so in that case you would want to setup an APACHE proxy so that

localhost -> localhost:8081 (for the MIDAS server)
localhost/rootana -> localhost:9091 (for the ROOT server)

then the custom page would be available at

localhost/CS/webdisplay

Please read my updated documentation and see if this makes any more sense.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
  9   09 May 2017 Konstantin OlchanskiInfoweb display of MIDAS data using rootana+THttpServer
> 
> 2) The 'same-origin policy' means that you need to setup some sort of proxying so that the custom web page can access the 
> ROOT webpage.  So, let's suppose in your case that you had the following ports for web servers:
> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
>

The MIDAS web server mhttpd already implements CORS, so you can access mhttpd AJAX and JSON-RPC from external web pages, no need to proxy.

Does the ROOT web server NOT implement CORS? We should file a bug report with ROOT if it does not.

K.O.
  20   10 Mar 2020 Konstantin OlchanskiInfoweb display of MIDAS data using rootana+THttpServer
> > 
> > 2) The 'same-origin policy' means ...
> > https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
> >
> 
> The MIDAS web server mhttpd already implements CORS, so you can access mhttpd AJAX and JSON-RPC from external web pages, no need to proxy.
> Does the ROOT web server NOT implement CORS? We should file a bug report with ROOT if it does not.

For the record, the web server in ROOT 6.20 does implement CORS via the "cors=" option, see
https://github.com/root-project/jsroot/blob/master/docs/HttpServer.md

K.O.
  22   22 May 2020 Konstantin OlchanskiInforootana updates
I am updating the rootana code to include all the latest developments in midas and 
elsewhere:

- mxml, mjson (and soon mvodb, midasio and manalyzer) are moving into git submodules 
(shared with midas and usable as standalone code)
- VirtualOdb is gone, use MVOdb instead
- TMidasFile is gone, use TMReader and TMWriter in midasio.h
- TMidasEvent remains, I will update it with Stefan's to the midas bank format.
- TMEvent in midasio.h will also be updated for this
- TMEvent has incomplete implementation for creating new events and adding data banks, I 
hope to fix this. This should make midasio classes useful for writing MIDAS frontends.
- I am still thinking about what to do with roody and the XmlServer, MidasServer and 
NetDirectory code. Most likely remove it all and concentrate in supporting JSROOT and the 
associated ROOT-built-in web server. Maybe update roody to use the JSROOT interface to 
get data from the analyzer.

If you do not want to see all these changes, please use the rootana-2020-03 release 
branch.

After all changes are implemented and tested, I will cut a release branch and post an 
announcement.

K.O.
  39   04 Apr 2021 Konstantin OlchanskiInfodrop support for ROOT v5?
There is problem report about failing builds against ROOT v5. https://bitbucket.org/tmidas/rootana/issues/19/make-error-rtypesimph-should-only-be

At TRIUMF, do we even still have anybody who uses ROOT v5 with ROOTANA?

My newest copy of ROOT v5 is from 2016 and I am not sure it would run on any computer we still have.

So is ROOT v5 still relevant, should we officially say ROOT v5 is not supported?

K.O.
ELOG V3.1.4-2e1708b5