Back Midas Rome Roody Rootana
  Root Analyzer Framework, Page 2 of 4  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Topic Subjectdown
  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: "
  31   18 Jan 2021 Isaac Labrie BoulayForumWarning: the time for this bank is more than 10 sec older than current time.
Hi all,

I get this warning when I run anaDisplay.exe (analyzer display mode) of the old 
Rootana analyzer. It seems to be because the analyzer cannot keep up with the data 
gathered by my frontend. The same issue seems to happen when I run the newer 
"manalyzer_example_root_graphic.exe" in graphical mode (-g). Is my computer cpu 
just not powerful enough to run both the data acquisition and the graphical 
analyzer simultaneously? Both the frontend and analyzer run on the same PC.

As always, thanks for the help!

Isaac the intern
  32   21 Jan 2021 Thomas LindnerForumWarning: the time for this bank is more than 10 sec older than current time.
> Hi all,
> 
> I get this warning when I run anaDisplay.exe (analyzer display mode) of the old 
> Rootana analyzer. It seems to be because the analyzer cannot keep up with the data 
> gathered by my frontend. The same issue seems to happen when I run the newer 
> "manalyzer_example_root_graphic.exe" in graphical mode (-g). Is my computer cpu 
> just not powerful enough to run both the data acquisition and the graphical 
> analyzer simultaneously? Both the frontend and analyzer run on the same PC.
> 
> As always, thanks for the help!
> 
> Isaac the intern

Hi Isaac,

It is certainly possible that your analyzer cannot keep up with the data taking.  It will depend (at least partly) on what you are trying to do in your analyzer.  Suppose you are taking 1000Hz of events from some waveform digitizer.  If you are trying to do something simple (like count how many bytes are in each data packet) then your analyzer will probably be able to keep up with the data taking.  But if you are trying to do some very complicated maximum likelihood fit to each waveform, then it is possible that your computer (or any computer) would not be able to keep up with the data taking.  In that case maybe your analyzer is only able to process 100Hz of data or 10% of the events (for example).

But it is not always a problem if your analyzer can't keep up.  The goal of the online analyzer is to allow you to check data in real time.  If you wanted to calculate the pulse height distribution of hits in your waveforms, then it is probably fine that you are only able to process 10% of the events online.  It might take you a little longer to accumulate your statistics for your online plots, but your online analyzer data is still useful.

On the other hand, there is other types of online analysis where it is important to process every event.  For instance, suppose you are trying to calculate online the rate of a certain type of event that involves making cuts in your online analysig. In that case you will want to be analyzing every event; missing 10% or 90% of events will bias your online analysis.

So that message is a warning; if you are doing an online analysis where it is critical that you process every event, then you have a problem if you see that message.  In that case you need to figure out how to speed up your online analysis.  You will need to use a profiler or some other tool to optimize your code.

It should be noted that the display itself can often be a limiting part of the online analyzer.  You might be able to process 1000Hz of waveform data, but you certainly can't update your plots at 1000Hz; so you need to take care with the updating and display of your plots if you really care about speed.
  33   21 Jan 2021 Isaac Labrie BoulayForumWarning: the time for this bank is more than 10 sec older than current time.
> > Hi all,
> > 
> > I get this warning when I run anaDisplay.exe (analyzer display mode) of the old 
> > Rootana analyzer. It seems to be because the analyzer cannot keep up with the data 
> > gathered by my frontend. The same issue seems to happen when I run the newer 
> > "manalyzer_example_root_graphic.exe" in graphical mode (-g). Is my computer cpu 
> > just not powerful enough to run both the data acquisition and the graphical 
> > analyzer simultaneously? Both the frontend and analyzer run on the same PC.
> > 
> > As always, thanks for the help!
> > 
> > Isaac the intern
> 
> Hi Isaac,
> 
> It is certainly possible that your analyzer cannot keep up with the data taking.  It will depend (at least partly) on what you are trying to do in your analyzer.  Suppose you are taking 1000Hz of events from some waveform digitizer.  If you are trying to do something simple (like count how many bytes are in each data packet) then your analyzer will probably be able to keep up with the data taking.  But if you are trying to do some very complicated maximum likelihood fit to each waveform, then it is possible that your computer (or any computer) would not be able to keep up with the data taking.  In that case maybe your analyzer is only able to process 100Hz of data or 10% of the events (for example).
> 
> But it is not always a problem if your analyzer can't keep up.  The goal of the online analyzer is to allow you to check data in real time.  If you wanted to calculate the pulse height distribution of hits in your waveforms, then it is probably fine that you are only able to process 10% of the events online.  It might take you a little longer to accumulate your statistics for your online plots, but your online analyzer data is still useful.
> 
> On the other hand, there is other types of online analysis where it is important to process every event.  For instance, suppose you are trying to calculate online the rate of a certain type of event that involves making cuts in your online analysig. In that case you will want to be analyzing every event; missing 10% or 90% of events will bias your online analysis.
> 
> So that message is a warning; if you are doing an online analysis where it is critical that you process every event, then you have a problem if you see that message.  In that case you need to figure out how to speed up your online analysis.  You will need to use a profiler or some other tool to optimize your code.
> 
> It should be noted that the display itself can often be a limiting part of the online analyzer.  You might be able to process 1000Hz of waveform data, but you certainly can't update your plots at 1000Hz; so you need to take care with the updating and display of your plots if you really care about speed.

Hi Thomas,

Thank you for the thorough answer. I can now see how this feature is important. Also, I was getting turtle speeds for my analysis rate. 
I found out that it was because I was 'drawing/updating' my histograms for every event. I'm new to ROOT and I didn't realize how badly these 
functions slow down your system.

Cheers.

Isaac
  25   07 Dec 2020 Isaac Labrie BoulayForumThe FIXED format.
Hi folks,

I am thinking of using the FIXED format event to avoid the overhead of the bank 
structure. The Wiki says under "FIXED Format Event" that the standard MIDAS 
analyzer cannot work with this format. What exactly is meant by this? Is it saying 
that the specific ROOTANA analyzer template will not work with the event format? 

Thanks for helping me out!

Isaac
  28   16 Dec 2020 Konstantin OlchanskiForumThe FIXED format.
> I am thinking of using the FIXED format event to avoid the overhead of the bank 
> structure. The Wiki says under "FIXED Format Event" that the standard MIDAS 
> analyzer cannot work with this format. What exactly is meant by this? Is it saying 
> that the specific ROOTANA analyzer template will not work with the event format? 

I am not sure if current code can deal with anything other than MIDAS data that uses 
the bank format. (even bk_init32a() support is incomplete in ROOTANA!).

I am curious why you have a problem with the bank format.

For bank overhead, there are several solutions:

a) if you have 1000 banks, 1 data word in each bank, you can create 1 MIDAS bank, store 
your data inside using your own optimized data format. (MIDAS overhead reduces from 
4000 words to 4 words, overhead from your custom data format goes from 0 to ???, so you 
may not gain much).

b) if you have 1000 data events, 1 data word in each event. Overhead is crazy: many 
words of event header, many words of bank header, etc. I would solve this storing
all your events inside one single midas event (say, 1000 data events per 1 midas 
event). Each data event can be stored in a midas bank (it is okey to have 1000 banks 
named "AAAA"), or you use solution (a). The m-analyzer is especially suitable for 
working with such "super events". In the unpacking module, AnalyzeEvent() would unpack 
each data event into a FlowEvent, in all the other modules, your FlowEvent-encapsulated 
data events will show up in the AnalyzeFlowEvent() method.

Next time I work on the midasio library and the TMEvent class I should check that it 
works with and that is usable with non-midas-bank data.

K.O.
  30   16 Dec 2020 Isaac Labrie BoulayForumThe FIXED format.
> > I am thinking of using the FIXED format event to avoid the overhead of the bank 
> > structure. The Wiki says under "FIXED Format Event" that the standard MIDAS 
> > analyzer cannot work with this format. What exactly is meant by this? Is it saying 
> > that the specific ROOTANA analyzer template will not work with the event format? 
> 
> I am not sure if current code can deal with anything other than MIDAS data that uses 
> the bank format. (even bk_init32a() support is incomplete in ROOTANA!).
> 
> I am curious why you have a problem with the bank format.
> 
> For bank overhead, there are several solutions:
> 
> a) if you have 1000 banks, 1 data word in each bank, you can create 1 MIDAS bank, store 
> your data inside using your own optimized data format. (MIDAS overhead reduces from 
> 4000 words to 4 words, overhead from your custom data format goes from 0 to ???, so you 
> may not gain much).
> 
> b) if you have 1000 data events, 1 data word in each event. Overhead is crazy: many 
> words of event header, many words of bank header, etc. I would solve this storing
> all your events inside one single midas event (say, 1000 data events per 1 midas 
> event). Each data event can be stored in a midas bank (it is okey to have 1000 banks 
> named "AAAA"), or you use solution (a). The m-analyzer is especially suitable for 
> working with such "super events". In the unpacking module, AnalyzeEvent() would unpack 
> each data event into a FlowEvent, in all the other modules, your FlowEvent-encapsulated 
> data events will show up in the AnalyzeFlowEvent() method.
> 
> Next time I work on the midasio library and the TMEvent class I should check that it 
> works with and that is usable with non-midas-bank data.
> 
> K.O.

Hey,

Yeah I had not yet really dove into the Event Structure documentation at the time that I 
wrote this email. The BANK format and I get along now. No problem there anymore.

Thanks for getting back to me sir.

Isaac
  45   25 Apr 2022 Marius KoeppelSuggestionSupport for THttpServer Options
Dear all,

I would like to have the possibility to add different options when I create a THttpServer. At the moment the manalyzer.cxx only adds the port:

2840: sprintf(str, "http:127.0.0.1:%d?cors", httpPort);

But there are more options which one can use https://github.com/root-project/jsroot/blob/master/docs/HttpServer.md.

Best regards,
Marius
  46   27 Apr 2022 Konstantin OlchanskiSuggestionSupport for THttpServer Options
> I would like to have the possibility to add different options when I create a THttpServer.

I would like to know your "use case". What different options do you want to use in addition to what's already there?

I must ask because some options are insecure (i.e. exposing the webserver to external connections) and
while I have no problem with others shooting themselves in the foot, I think they should be warned
before they do it and I do not want to read it in the news that they did it using a gun I built.

TLDR follows:

> At the moment the manalyzer.cxx only adds the port:
> 2840: sprintf(str, "http:127.0.0.1:%d?cors", httpPort);

this is by design. it is only safe to bind thttpserver to localhost, exposing to external connections is not safe. (until somebody
can review the security situation with the version of civetweb, an antique clone of mongoose, inside ROOT).

same situation with mhttpd, it is not safe to expose it to external connections, it should always live
behind a password protected https proxy.

> But there are more options which one can use https://github.com/root-project/jsroot/blob/master/docs/HttpServer.md.

yes, I see there is more options now that there used to be before.

which ones do you want to use? and which ones you think are generally useful in what we do?

- threads - I am not sure what the latest thread-safe situation is on ROOT. is it useful to increase number of threads beyond 10?
- top=name - yes, useful, but I think jsroot overrides that.
- auth_file, auth_domain - digest authentication .htdigest file stores passwords effectively as plain text, if you steal the .htdigest file, you 
can login into the web server (as opposed to stealing /etc/passwd, you cannot login anywhere with it, not until you crack the hashes).
- loopback - this is what I want to enforce
- debug - could be useful, but is it?
- websocket - does this do anything useful for us?
- cors=domain - same as in midas mhttpd, I think we respond with CORS "*", is some other reponse useful?
- readonly - (is the default?)
- readwrite - I think should be *our* default
- global - (is the default, I agree)
- noglobal - any use case where we may want this?
- anything else?

For general use, I want maximum security configuration: bind to localhost, cors enabled, user can specify tcp port number, plus anything else from 
the list above?

For maximum flexibility we should probably have "--insecure-thttpd" to specify
the complete THttpServer() constructor argument. But it would be silly to force everybody
to use that just to set the "debug" option.

K.O.
  47   04 Apr 2023 Marius KoeppelSuggestionSupport for THttpServer Options
Hi Konstantin,

sorry I did not set the mail notification on on this elog. So I never got the info that you replayed to this topic.
Maybe its also time to have a elog for manalyzer since rootana is not really used anymore.

Following our e-mail conversion I would start with this topic first:

Mail from me: >  Supporting more function of the root browser
Mail from you: > yes, I would like to add/have more code to interact with jsroot. basically jsroot specifies/implements a simple RPC and we should have support for it in manalyzer. (unless your "the root browser" is something else).

> I would like to know your "use case". What different options do you want to use in addition to what's already there?
So the main problem I have in short is that the readwrite flag is not the default in manalyzer. If its set to rw one can simply get histos on custom page via:

let gH = await httpRequest(serverIP + '/PathToHisto/' + '/root.json', 'object');
redraw('NAME', gH, 'hist');

> I must ask because some options are insecure (i.e. exposing the webserver to external connections) and
> while I have no problem with others shooting themselves in the foot, I think they should be warned
> before they do it and I do not want to read it in the news that they did it using a gun I built.
I agree here one needs to at least warn the user what he is going to do now.

 
> > At the moment the manalyzer.cxx only adds the port:
> > 2840: sprintf(str, "http:127.0.0.1:%d?cors", httpPort);
> 
> this is by design. it is only safe to bind thttpserver to localhost, exposing to external connections is not safe. (until somebody
> can review the security situation with the version of civetweb, an antique clone of mongoose, inside ROOT).
I fully agree with having only localhost allowed. My comment was more about the different options like rw, ro etc.

> - threads - I am not sure what the latest thread-safe situation is on ROOT. is it useful to increase number of threads beyond 10?
We never had problems with the performance - but I can not tell for others so better have an option for this so the user can choose?

> - top=name - yes, useful, but I think jsroot overrides that.
Would like to have the option especially when you have multiple analyzers running in the network can get confusing. 

> - auth_file, auth_domain - digest authentication .htdigest file stores passwords effectively as plain text, if you steal the .htdigest file, you 
> can login into the web server (as opposed to stealing /etc/passwd, you cannot login anywhere with it, not until you crack the hashes).
Better not.

> - loopback - this is what I want to enforce
Yes, I agree.

> - debug - could be useful, but is it?
I had it on a couple of times while writing custom pages displaying histograms.

> - websocket - does this do anything useful for us?
I don't think so, but I also never look into it in detail.

> - cors=domain - same as in midas mhttpd, I think we respond with CORS "*", is some other reponse useful?
At the moment we have with sprintf(str, "http:127.0.0.1:%d?cors", httpPort); CORS "*" I think other responses are not super useful.

> - readonly - (is the default?)
This it default at the moment I would also like to have readwrite as default

> - readwrite - I think should be *our* default
Yes.

> - global - (is the default, I agree)
Yes should be default.

> - noglobal - any use case where we may want this?
Maybe when users run into performance issues?

That's all of my thoughts about what setting should be possible.

Best,
Marius
  14   24 Jul 2019 Paolo BaessoBug ReportROOTANA installation fails (ss_suspend_set_dispatch_ipc(NULL); not declared)

Good afternoon, I am following the instructions provided here to install ROOTANA (and MIDAS, more in general). When I try to make I get the following error

libMidasInterface/TMidasOnline.cxx: In member function ‘bool TMidasOnline::sleep(int)’: libMidasInterface/TMidasOnline.cxx:194:3: error: ‘ss_suspend_set_dispatch_ipc’ was not declared in this scope
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
libMidasInterface/TMidasOnline.cxx:194:3: note: suggested alternative: ‘ss_suspend_set_rpc_thread’
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
ss_suspend_set_rpc_thread
Makefile:339: recipe for target 'obj/TMidasOnline.o' failed make: *** [obj/TMidasOnline.o] Error 1

 

And the compilation stops. Is this a known issue?
My system is Ubuntu 18 and I am running ROOT 6.18.00

  15   08 Aug 2019 Lauren MantonBug ReportROOTANA installation fails (ss_suspend_set_dispatch_ipc(NULL); not declared)

Hi,

Thank you, commenting out the line worked and we can now compile the code. However, when we try to run ana.exe or anaDisplay.exe, we get the following errors:

Error in <TCling::RegisterModule>: cannot find dictionary module TMainDisplayWindowDict_rdict.pcm
Error in <TCling::RegisterModule>: cannot find dictionary module TRootanaDisplayDict_rdict.pcm
Error in <TCling::RegisterModule>: cannot find dictionary module TFancyHistogramCanvasDict_rdict.pcm

 

We see that the files are in /rootana/obj but we cannot find a way to point the compiler to them.

Could you please advise how to proceed,

Many thanks

Paolo Baesso wrote:

Good afternoon, I am following the instructions provided here to install ROOTANA (and MIDAS, more in general). When I try to make I get the following error

libMidasInterface/TMidasOnline.cxx: In member function ‘bool TMidasOnline::sleep(int)’: libMidasInterface/TMidasOnline.cxx:194:3: error: ‘ss_suspend_set_dispatch_ipc’ was not declared in this scope
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
libMidasInterface/TMidasOnline.cxx:194:3: note: suggested alternative: ‘ss_suspend_set_rpc_thread’
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
ss_suspend_set_rpc_thread
Makefile:339: recipe for target 'obj/TMidasOnline.o' failed make: *** [obj/TMidasOnline.o] Error 1

 

And the compilation stops. Is this a known issue?
My system is Ubuntu 18 and I am running ROOT 6.18.00

 

  16   08 Aug 2019 Thomas LindnerBug ReportROOTANA installation fails (ss_suspend_set_dispatch_ipc(NULL); not declared)

Hi Lauren,

Do you see an actual problem that results from those error messages?  As I mentioned before [1] I get that error message, but it doesn't seem to actually cause a problem.  

Thomas

[1] https://midas.triumf.ca/elog/Rootana/12

Lauren Manton wrote:

Hi,

Thank you, commenting out the line worked and we can now compile the code. However, when we try to run ana.exe or anaDisplay.exe, we get the following errors:

Error in <TCling::RegisterModule>: cannot find dictionary module TMainDisplayWindowDict_rdict.pcm
Error in <TCling::RegisterModule>: cannot find dictionary module TRootanaDisplayDict_rdict.pcm
Error in <TCling::RegisterModule>: cannot find dictionary module TFancyHistogramCanvasDict_rdict.pcm

 

We see that the files are in /rootana/obj but we cannot find a way to point the compiler to them.

Could you please advise how to proceed,

Many thanks

Paolo Baesso wrote:

Good afternoon, I am following the instructions provided here to install ROOTANA (and MIDAS, more in general). When I try to make I get the following error

libMidasInterface/TMidasOnline.cxx: In member function ‘bool TMidasOnline::sleep(int)’: libMidasInterface/TMidasOnline.cxx:194:3: error: ‘ss_suspend_set_dispatch_ipc’ was not declared in this scope
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
libMidasInterface/TMidasOnline.cxx:194:3: note: suggested alternative: ‘ss_suspend_set_rpc_thread’
ss_suspend_set_dispatch_ipc(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
ss_suspend_set_rpc_thread
Makefile:339: recipe for target 'obj/TMidasOnline.o' failed make: *** [obj/TMidasOnline.o] Error 1

 

And the compilation stops. Is this a known issue?
My system is Ubuntu 18 and I am running ROOT 6.18.00

 

 

  17   14 Aug 2019 Konstantin OlchanskiBug ReportROOTANA installation fails (ss_suspend_set_dispatch_ipc(NULL); not declared)
(please send elog messages in "plain text" mode, otherwise I cannot quote your text)

The problem with missing ss_suspend_set_dispatch_ipc() is now fixed, rootana commit 
https://bitbucket.org/tmidas/rootana/commits/52fdedb5745fa9b6739a16a6faab8b9d40108045

If you run rootana online in graphical mode (or call TMidasOnline::sleep() yourself), you may re-encounter
the problem of recursive calls to the event handler, depending on which version of MIDAS you use. The
probability of this problem happening is probably reduced to zero in all 2019 MIDAS releases and it is
definitely fixed in the most recent commits to MIDAS (this will be the midas-2019-09 release, most likely).

Read more here:
https://midas.triumf.ca/elog/Midas/1663

K.O.
  26   10 Dec 2020 Isaac Labrie BoulayForumROOTANA MidasWiki
Hi folks,

I'm currently looking at the ROOTANA wiki. I will be building an online MIDAS 
analyzer and I'm wondering if the wiki still contains useful information if I want 
to use the more recent 'manalyzer' template.

Thanks!

Isaac
  29   16 Dec 2020 Konstantin OlchanskiForumROOTANA MidasWiki
> I'm currently looking at the ROOTANA wiki. I will be building an online MIDAS 
> analyzer and I'm wondering if the wiki still contains useful information if I want 
> to use the more recent 'manalyzer' template.

All the documentation for manalyzer is in it's README.md file. I am not sure if the ROOTANA wiki makes 
correct reference to this.

The big idea is to make manalyzer part of midas, as replacement to the old mana.c analyzer.

For now, I plan to make manalyzer into a git submodule in midas and rootana (same as mjson, mvodb and 
midasio).

K.O.
  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.
ELOG V3.1.4-2e1708b5