Back Midas Rome Roody Rootana
  Midas DAQ System, Page 118 of 125  Not logged in ELOG logo
ID Date Authorup Topic Subject
  1349   08 Mar 2018 Suzannah DavielSuggestionlink to an array element displays whole array in mhttpd
A link to an array variable such as

[local:npet:Stopped]/>ls /rcparams/ControlVariables/
TRFC:PB5 (V) -> /Equipment/Beamline/Variables/Demand[56]
                                17835

displays the whole Demand array on the mhttpd ODB page (see attachment)
rather than just the one element Demand[56].
This behaviour also occurs with older versions of mhttpd.
 
Not sure if it's a bug or a feature, but my suggestion is that it
ought to display the one element only (as odbedit does) and not the whole array.

Suzannah  
Attachment 1: controlvar.png
controlvar.png
  1350   09 Mar 2018 Suzannah DavielBug Reportlink to an array element displays whole array in mhttpd
Further to my last message, I see that a midas version from 2013 does indeed display
links to arrays as I would expect (see attachment). Therefore the problem in later
versions  is a bug rather than a feature.


> A link to an array variable such as
> 
> [local:npet:Stopped]/>ls /rcparams/ControlVariables/
> TRFC:PB5 (V) -> /Equipment/Beamline/Variables/Demand[56]
>                                 17835
> 
> displays the whole Demand array on the mhttpd ODB page (see attachment)
> rather than just the one element Demand[56].
> This behaviour also occurs with older versions of mhttpd.
>  
> Not sure if it's a bug or a feature, but my suggestion is that it
> ought to display the one element only (as odbedit does) and not the whole array.
> 
> Suzannah  
Attachment 1: controlvar_good.png
controlvar_good.png
  1361   23 Mar 2018 Suzannah DavielBug Reportlink to an array element displays whole array in mhttpd
> It might have worked some ~5 years ago, but it never really showed the target value of a link, just the 
> link itself. I reworked the code now to show both the link and the target of the link, so you can change 
> both in the mhttpd ODB page. Should be consistent now with odbedit. Have a look if it works for you.
> 
> Stefan

Thank you. That has solved the problem.
Suzannah 
  1460   04 Mar 2019 Suzannah DavielInfoGyrations of custom pages and ODB /Custom/Path
I see two separate issues here. 

One is restricting the custom pages to ONE directory such as 
<exptab>/resources -> /home/users/exp/resources
and its subdirectories which seems like a good solution for all the
reasons you've mentioned. 

The other issue is the use of the "Path" key in /Custom, which is used to differentiate
between the "new" way (all resources served from the Path directory) 
and the original way where all the custom keys are specified with their full directories.

Recent versions of Midas had broken the original behaviour by insisting on the presence of the
"Path" key.  Konstantin fixed this by allowing the "Path" key to take the value "".  It is true
that some experiments currently may be serving resources from more than one directory tree, but changing
to storage of all custom pages in one directory (and its subdirectories) does not necessarily mean that
the original way of serving resources must be made obsolete.
 
I actually like the original way of specifying the custom keys for the pages and resources under /Custom, which
is presently selected  without the /Custom/Path key present at all (older versions) or with the
/Custom/Path key set to "" (latest versions). I like it for debugging, and I like to be able to see 
at a glance what resource files are in use from /Custom. 

I have a suggestion:

The resources could still be served from the /Custom directory if desired, except now mhttpd will ALWAYS add the 
fixed path in front of the given paths in /Custom. This would mean a fixed path and a minimal disruption to older pages 
(the <script> and <link> statements in the HTML code to include the resources would not need to be changed).
The "/Path" key is no longer be useful, since the resource path is now fixed. Instead a key e.g. "FlagRS"  could 
be used to select the desired behaviour,  with the default being the "new" (no key present).

For example, the full directory paths in /custom
ScanParams&                     /home/users/online/custom/scan/scan_select_popup.html
mpet.css!                       /home/users/online/custom/rs/mpet.css
scanvoltages!                   /home/users/online/custom/scan/scan_voltages.js

would become subdirectory path(s)
ScanParams&                     custom/scan/scan_select_popup.html
mpet.css!                       custom/rs/mpet.css
scanvoltages!                   custom/scan/scan_voltages.js
FlagRS                          y

The pages would be served from /home/users/exp/resources/custom/...

Suzannah

 
> > Hi Stefan and Konstantin,
> > 
> > I think that this proposal sounds fairly reasonable.  I agree that we might as well move to a secure final solution at this point.  
> > 
> > One comment: since this change would break almost every experiment I have worked on for the last 4 years, it would be nice to add a command-line option to mhttpd that preserves the old /Custom/Path behavior.  This would allow experiments a transition 
> > period, so that they didn't immediately need to fix their setup.  The command-line option could be clearly marked as obsolete behaviour and could be removed within a year.
> > 
> > Cheers,
> > Thomas
> > 
> > 
> > 
> > > Parsing all URL in mhttpd to prevent /etc/passwd etc. to be returned is tricky, because people can use escape sequences etc. Therefore I think it is much better to restrict file access 
> > > on the file system level when opening a file. The only escape there one could have is "..", which can be tested easily. 
> > > 
> > > Therefore, I propose to restrict file access to two well-defined directories, which is one system directory and one user directory. The system directory should be defined via 
> > > $MIDASSYS/resources, and the user directory should be the experiment directory (as defined in exptab) followed by "resources". So if MIDASSYS equals to /usr/local/midas and the 
> > > experiment directory equals to /home/users/exp for example, we would only have these two directories (and of course the subdirectories within these) served by mhttpd:
> > > 
> > > $MIDASSYS/resource -> /usr/local/midas/resources
> > > <exptab>/resources -> /home/users/exp/resources
> > > 
> > > These directories should be hard-wired into mhttpd, and not go through and ODB entry, since otherwise one could manipulate the ODB entries (knowingly or unknowingly) and open a 
> > > back-door. 
> > > 
> > > If users need a more complex structure, they can put soft links into these directories.
> > > 
> > > The code which opens a resource file should then first evaluate $MIDASSYS, then add "/resources/", then add the requested file name, make sure that there is no ".." in the file name, 
> > > then open the file. If not existing, do the same for the <exptab>/resources/ directory.
> > > 
> > > This change will break most experiments, and forces people to move their custom pages to different directories, but I think it's the only clean solution and we just have to bite the 
> > > bullet.
> > > 
> > > Comments are welcome.
> > > 
> > > Stefan
  1536   29 May 2019 Suzannah DavielSuggestionReplacing MIDAS status page with custom status page
Replacing the MIDAS status page with a custom status page documented at

https://midas.triumf.ca/MidasWiki/index.php/Custom_Page_Features#Replace_Status_Page_by_a_Custom_page

does not appear to be supported in the current MIDAS version. 

As two of my experiments use this feature may I suggest its reinstatement?

Suzannah
  2125   05 Mar 2021 Svetlana ChesnevskayaBug ReportNew MIDAS old frontend incompatibility
Hello!

Could you help me solve the problem of compatibility between our frontend (created in 2017) and the fresh MIDAS? The old MIDAS (2017) worked well, then we did not use it.
While compiling the frontend, I get a lot of warnings and a few compilation errors.

Any help will be greatly appreciated.

Thanks in advance.
With the best regards,
Svetlana
Attachment 1: error.log
g++ -c -m64 -g -O0 -Wall -Wextra  -I. -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100 -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100/linux -L/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100/lib -Wunused-variable -DHAVE_MIDAS__  -D__HAVE_MIDAS -I./include -I./include/CP80190_80057 -DOS_LINUX -Dextname src/realEventFrontend.cc -o src/realEventFrontend.o
In file included from ./include/v1742.hh:4:0,
                 from src/realEventFrontend.cc:16:
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1336:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD event_id = 0;
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1338:18: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD n_tag = 0;
                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1343:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int hist_fh  = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1344:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int index_fh = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1345:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int def_fh   = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1346:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD base_time  = 0;
                       ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1347:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD def_offset = 0;
                       ^
In file included from src/realEventFrontend.cc:18:0:
./include/CP80057.hh: In Konstruktor »CP80057::CP80057(unsigned int, MVME_INTERFACE*, HNDLE)«:
./include/CP80057.hh:20:45: Warnung: Konvertierung in Nicht-Zeiger-Typ »uint32_t {aka unsigned int}« von NULL [-Wconversion-null]
       vme_port_addr(vmeBaseAdress), port(0x0)                          {}
                                             ^
src/realEventFrontend.cc: Im globalen Gültigkeitsbereich:
src/realEventFrontend.cc:32:42: Warnung: verengende Umwandlung von »2425356288u« von »unsigned int« nach »const int« in { } ist in C++11 ungültig [-Wnarrowing]
                                0x90910000};
                                          ^
src/realEventFrontend.cc:32:42: Warnung: verengende Umwandlung von »2425421824u« von »unsigned int« nach »const int« in { } ist in C++11 ungültig [-Wnarrowing]
In file included from src/realEventFrontend.cc:48:0:
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:348:22: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    BOOL is_mserver = 0;             /*  this is an mserver server-side connection */
                      ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:349:20: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int send_sock = 0;               /*  tcp send socket         */
                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:350:20: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int recv_sock = 0;               /*  tcp receive socket      */
                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:351:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int event_sock = 0;              /*  tcp event socket        */
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:352:25: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT remote_hw_type = 0;          /*  hardware type           */
                         ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:353:27: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT watchdog_timeout = 0;        /*  in milliseconds         */
                           ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:354:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD last_activity = 0;         /*  time of last recv       */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:355:24: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT convert_flags = 0;           /*  convertion flags        */
                        ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:358:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT net_buffer_size = 0;         /*  size of TCP cache       */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:18: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:30: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                              ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:42: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:36: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:51: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                                                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:361:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    HNDLE odb_handle = 0;            /*  handle to online datab. */
                       ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:362:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    HNDLE client_handle = 0;         /*  client key handle .     */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:525:34: Fehler: Deklaration der C-Funktion »std::string cm_get_path()« steht in Konflikt mit
    std::string EXPRT cm_get_path();
                                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:524:14: Fehler: vorherige Deklaration »INT cm_get_path(char*, int)« hier
    INT EXPRT cm_get_path(char *path, int path_size);
              ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:629:31: Fehler: Deklaration der C-Funktion »std::string ss_gethostname()« steht in Konflikt mit
    std::string ss_gethostname();
                               ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:628:8: Fehler: vorherige Deklaration »INT ss_gethostname(char*, int)« hier
    INT ss_gethostname(char* buffer, int buffer_size);
        ^
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
       };  
       ^
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::driver« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::event_descrip« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::readout« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::driver« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::event_descrip« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:295:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT begin_of_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:295:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:337:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT end_of_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:337:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:351:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT pause_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:351:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:357:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT resume_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:357:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »cmd« [-Wunused-parameter]
 INT interrupt_configure(INT cmd, INT source, PTYPE adr){
     ^
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »source« [-Wunused-parameter]
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »adr« [-Wunused-parameter]
src/realEventFrontend.cc:521:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_clock_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:550:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_calibration_data_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:572:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_tdc_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:644:7: Warnung: unbenutzter Parameter »ptr« [-Wunused-parameter]
 void *updateCUSPRunNumber(void *ptr){
       ^
src/realEventFrontend.cc:658:7: Warnung: unbenutzter Parameter »ptr« [-Wunused-parameter]
 void *restartRun(void *ptr){
       ^
make: *** [src/realEventFrontend.o] Fehler 1
  904   13 Sep 2013 Thomas LindnerBug Reportmhttpd truncates string variables to 32 characters
I find that new mhttpd has strange behaviour for ODB strings.

- I create a new STRING variable in ODB through mhttpd.  It defaults to size 32.

- I then edit the STRING variable through mhttpd, writing a new string larger
than 32 characters.

- Initially everything looks fine; it seems as if the new string value has been
accepted.

- But if you reload the page, or navigate back to the page, you realize that
mhttpd has silently truncated the string back to 32 characters.

You can reproduce this problem on a test page here:

http://midptf01.triumf.ca:8081/AnnMessage

Older versions of mhttpd (I'm testing one from 2 years ago) don't have this
'feature'.  For older mhttpd the string variable would get resized when a larger
string was inputted.  That definitely seems like the right behavior to me.

I am using fresh copy of midas from bitbucket as of this morning. (How do I get
a particular tag/hash of the version of midas that I am using?)
  1054   13 May 2015 Thomas LindnerForumCheck if Client is running from Javascript

Andreas Suter wrote:
Is there currently an easy way to check from javascript if a midas client is
running? I mean an equivalent to cm_exist.

Sometimes this would be very useful in custom pages.


It is not as clean as what you asked, but I have in the past written javascript like this to check if a program is running

var req = new Array();
req[0]= "Programs/towerfe3_00/First failed";
var result = ODBMGet(req);
if(result[0] == 0){
// then program is running
}
  1072   16 Jul 2015 Thomas LindnerBug Reportjset/ODBSet using true/false for booleans
MIDAS does not seem to be consistent (or at least convenient) with how it
handles booleans in AJAX functions.

When you request an ODB value that is a boolean with AJAX call like

http://neut14.triumf.ca:8081/?cmd=jcopy&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys

then you get

{ "Hidden/last_written" : 1437065425, "Hidden" : false }

This seems correct, since the JSON convention has booleans encoded as true/false.

But this convention does not work when trying to set the boolean value. For instance

http://neut14.triumf.ca:8081/?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=true

does not set the variable to true. To make this work you need to use the
characters y/n

http://neut14.triumf.ca:8081/?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=y

I tested this with ajax/jset, but the same problem seems to occur when using the
javascript function ODBSet. The documentation doesn't say what sort of encoding
to use when using these functions, so I guess the idea is that these functions
use MIDAS encoding for booleans. But it seems to me that it would be more
convenient if jset/ODBSet allowed the option to use json/javascript encoding for
boolean values; or at least had that as a format option for jset/ODBSet.  That
way my javascript could look like

var mybool = true;
URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=" + mybool;

instead of

var mybool = true;
URI_command = ""
if(mybool){
  URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=y";
else
  URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=n";


__________________________________________________________
Cross-posting from bitbucket issue tracker:

https://bitbucket.org/tmidas/midas/issues/29/jset-odbset-using-true-false-for-booleans
  1098   20 Aug 2015 Thomas LindnerBug ReportMIDAS message page auto-size (horizontally) is annoying
New version of MIDAS has a feature where it seems to automatically resize the
message page horizontally in order to fix each MIDAS message into one line. 
Some of my MIDAS messages (in particular error messages, where I need details)
are very long.  The result is that the MIDAS page automatically becomes very
wide and I have to scroll a lot left/right in order to read my messages.  This
is annoying.

I would vote to roll-back this new feature.
  1100   21 Aug 2015 Thomas LindnerInfomhttpd HTTPS/SSL server updated
> 
> I recommend that you use "mhttpd --mg" as the alternative for running "mhttpd -p" behind an apache 
> proxy. Using "mhttpd -p" (no HTTPS/SSL) on an internet-connected machine is insecure and should not be 
> done. (private network such as 192.168.x.y addresses is okey for now, I guess).

Finally reading through your documentation in detail [1,2].  I find that I don't understand this recommendation to use secure mongoose 
instead of putting mhttpd behind an apache proxy.  I think that it is nice to have secure mhttpd with mongoose as an option, but your 
documentation seems to imply that mhttpd-mongoose is much better than mhttpd-behind-apache and that the latter solution is strongly 
deprecated.

Perhaps I am not understanding the benefits of the new system.  In reference [2] you say "If this is not possible, somewhat better security 
for HTTP is gained by using a password protected SSL (https) proxy."  This seems to imply that the security of mhttpd-mongoose is better 
than the security of mhttpd-behind-apache.  Is that correct?  I thought that they provided similar security (assuming you follow 
recommended configurations for APACHE).

Setting up apache is trivial and it seems that mhttpd-behind-apache has other advantages, like being able to put other web resources 
(ganglia, cameras, elog, etc) behind the same secure server.  Also you can start to build complicated custom pages that are served directly 
from apache and just use MIDAS AJAX calls.  I was imagining slowly moving away from using mhttpd at all and just having html/js/css 
resources served up by apache.

So, unless I'm missing something, at this point I would continue to recommend people use mhttpd-behind-apache and I'd suggest this be 
presented as an equally valid option in the documentation.

[1] https://midas.triumf.ca/MidasWiki/index.php/Mhttpd
[2] https://midas.triumf.ca/MidasWiki/index.php/Setup_MIDAS_experiment#Install_SSL_proxy
  1107   09 Sep 2015 Thomas LindnerInfomhttpd HTTPS/SSL server updated
> > 
> > I find that I don't understand this recommendation to use secure mongoose 
> > instead of putting mhttpd behind an apache proxy.
> >
> 
> This is a very valid question.
> 
> I think for a small operation that does not require root access to the host computer, mhttpd+mongoose is a good light weight solution.
> ...
> So, which one to use?
> 
> - for maximum security, use httpd apache (but remember to restrict access to mhttpd web port to be "only from the proxy")
> - for light-weight cases, or when root access is not available use built-in https in mhttpd.
> 
> The midas wiki documentation should probably be updated to explain all of this.


Thanks for the detailed explanation.  I agree with your recommendations.  I was mostly interested in having both options treated equally in the documentation.

My only small complaint is that since the default mhttpd comes with mongoose security turned on, you need to explicitly disable the mhttpd+mongoose security first before you can start setting up apache.  I guess that the motivation is 
that we should force people to disable security, rather than hoping that they will enable it.  That's a convincing argument; so all I really need is that this procedure be well documented.
  1108   09 Sep 2015 Thomas LindnerInfomhttpd/SSL error message on MacOS
On my macbook (OS X 10.10.3) I get this error message when starting mhttpd with mongoose-SSL:

[mhttpd,ERROR] [mhttpd.cxx:17092:mongoose,ERROR] mongoose web server error: set_ssl_option: 
openssl "modern cryptography" ECDH ciphers not available

mhttpd seems to start fine anyway and safari connects to the secure midas page without complaining 
about the SSL (it complains about the certificate of course).  So maybe this error message is 
relatively harmless?

I don't get this error message with Scientific Linux 6.7.
  1109   09 Sep 2015 Thomas LindnerInfoDocumentation regarding specifying custom pages
Hi,

We have recently been changing the code in mhttpd that maps custom web pages and resources to 
particular files on the server file system.  Ie, changing the code that uses the ODB keys in /Custom to 
map a web address like 

http://myhost:8081/CS/MyCustomPage 

to some file like

/home/user/resource/mypage.html

This mapping gets complicated when you use the /Custom/Path key to specify a location for web 
resources like images.  We have tried to summarize how the current system works on the wiki

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

Please provide any suggestions on how either the documentation or the actual algorithm can be 
improved.
  1159   05 Feb 2016 Thomas LindnerSuggestionreducing sleep time in mhttpd main loop (for sequencer)
There were some complaints that the MIDAS sequencer was slow.  Specifically, the
complaint was that even lines in the sequence that didn't do any (like COMMENT
commands) tooks > 100ms to execute.  These slow sequencer steps could be a
little annoying if a script had to change a large number of ODB variables before
starting.

I tested this a little using a trivial sequence; note that I did all tests using
mhttpd with mongoose enabled on a newer macbook pro.  I found that with the
mongoose server each line in a sequencer script was taking ~100ms.  This is
consistent with the loop in the main thread, which is only doing a cm_yield and
a sleep:

   while (!_abort) {
      status = ss_mutex_wait_for(request_mutex, 0);
      status = cm_yield(0);
      if (status == RPC_SHUTDOWN)
         break;
      sequencer();
      status = ss_mutex_release(request_mutex);
      ss_sleep(100);
   }

I tested reducing the sleep to 20ms.  As expected, this made the sequencer more
zippy, able to execute ~50 commands per second.

I tried to think what would be downsides to making this change.  I think that
the main web communication should not be affected, because that communication is
all handled by the separate mongoose thread.

I checked how much extra CPU was used if the sleep was reduced from 100ms to
20ms.  I found that when a sequence was not running the CPU increased from 0% to
0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
4% with my change.  4% is a little high, though I'd say still reasonable.  I
found that most of the CPU usage was occuring because every call to
'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
guess that making that call 50 times causes the somewhat heavy CPU usage.

I would argue that it would still be worth making that change, so that the
sequencer can be more zippy.
  1160   05 Feb 2016 Thomas LindnerSuggestionreducing sleep time in mhttpd main loop (for sequencer)
> There were some complaints that the MIDAS sequencer was slow.  Specifically, the
> complaint was that even lines in the sequence that didn't do any (like COMMENT
> commands) tooks > 100ms to execute.  These slow sequencer steps could be a
> little annoying if a script had to change a large number of ODB variables before
> starting.
> ...
> I checked how much extra CPU was used if the sleep was reduced from 100ms to
> 20ms.  I found that when a sequence was not running the CPU increased from 0% to
> 0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
> 4% with my change.  4% is a little high, though I'd say still reasonable.  I
> found that most of the CPU usage was occuring because every call to
> 'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
> guess that making that call 50 times causes the somewhat heavy CPU usage.

One additional point: I think that it would be reasonably simple to reduce this CPU
usage even while a sequence was going on.  I would guess that for many sequences a
lot of time was spent in a 'WAIT SECONDS' command, since you would presumably want
to wait while data was being taken or conditions stabilizing.  I think that if you
are in a 'WAIT SECONDS' command that hasn't been satisfied then there probably isn't
any reason to do the db_set_record at the end of the sequencer() method.
  1162   15 Feb 2016 Thomas LindnerSuggestionreducing sleep time in mhttpd main loop (for sequencer)
> > I checked how much extra CPU was used if the sleep was reduced from 100ms to
> > 20ms.  I found that when a sequence was not running the CPU increased from 0% to
> > 0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
> > 4% with my change.  4% is a little high, though I'd say still reasonable.  I
> > found that most of the CPU usage was occuring because every call to
> > 'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
> > guess that making that call 50 times causes the somewhat heavy CPU usage.
> > 
> > I would argue that it would still be worth making that change, so that the
> > sequencer can be more zippy.
> 
> The minimal time slice on most systems is 10 ms, and nothing prevents us from switching to
> that. The original 100 ms was more for the fact that you can see the sequencer statements
> executed one after the other (with the color bar). But this is more a "debugging" feature which 
> we not really need. 

OK, I made this change; sleep is now 10ms on main thread.  Seems to work fine on SL6 and MacOS.

> To do it "right" the sequencer would have to _return_ a sleep time. Like if it is in a wait loop (as
> most of the time), the sleep time could be close to 1 second, to correctly update the wait
> progress bar. If the sequencer executes ODB set statements, the wait time could be zero, so
> thousands of statements can be executed in one second. The problem we will then have of course
> that the sequencer will block the "request_mutex" almost always, which would prevent the
> mongoose server from serving anything. So this should be carefully tested. It could be (on most OS)
> that releasing the mutex by the main loop immediately switches to the mongoose thread, which would
> make the web server still quite responsive, but I'm not sure about that. So as a first change making
> the sleep time 10ms should be fine.

Hmm, yeah, I'm not sure about how to handle reducing the wait time to zero after ODB set commands.

But it does seem like it would be straight-forward to increase the sleep time for waits; I'll look into
a clean way of doing that.
  1169   10 Mar 2016 Thomas LindnerInfoNew rootana forum | rootana web display tools
We have started a new elog for discussions of the ROOTANA MIDAS analyzer package
[1], which is used at TRIUMF and elsewhere for quick displays of MIDAS data. 
The forum is available here

https://midas.triumf.ca/elog/Rootana

I would note that we have recently finished implementing a system in rootana for
easy web displays of MIDAS data, using ROOT's THttpServer to post histograms. 
Details on this new scheme are here

https://midas.triumf.ca/elog/Rootana/1

and

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

Please sign up for the forum if you are interested in getting ROOTANA-related
discussions.

Thomas

[1] https://midas.triumf.ca/MidasWiki/index.php/ROOTANA
  1177   11 May 2016 Thomas LindnerInfoMacOS 10.11 (El Capitan) openssl compilation errors
I recently upgraded my macbook to MacOS 10.11.  The compilation of MIDAS failed after the upgrade, 
complaining about  

gcc  -c -g -O2 -Wall <snip> src/mongoose.c
src/mongoose.c:322:10: fatal error: 'openssl/ssl.h' file not found

It seems that MacOS has now fully removed openssl header files (they were deprecated for a while).  There 
seems to be some notes on that here

http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html

Konstantin suggested installing open-source builds of openssl using MacPorts.  I did that and MIDAS 
compiled fine.  I documented the procedure here:

https://midas.triumf.ca/MidasWiki/index.php/Installation/Compilation_problems#MacOS_10.11_.28El_Capitan.2
9_openssl_errors
  1217   25 Oct 2016 Thomas LindnerBug Reportcontrol characters not sanitized by json_write - can cause JSON.parse of mhttpd result to fail
> > I've recently run into issues when using JSON.parse on ODB keys containing 
> > 8-bit data.
> 
> I am tempted to take a hard line and say that in general MIDAS TID_STRING data should be valid 
> UTF-8 encoded Unicode. In the modern mixed javascript/json/whatever environment I think
> it is impractical to handle or permit invalid UTF-8 strings.
> ....
> But in your specific case, why do you have random control characters in your TID_STRING data? 
> Maybe you are using TID_STRING as general storage instead of arrays of TID_CHAR or 
> TID_DWORD?

I'm a little confused by this report and want to make sure I understand the situation.  Konstantin points
out that the TID_STRING should be valid UTF-8.  But I think that Amy agreed that the string was valid UTF-8.
 My understanding was that Amy's contention was that the valid UTF-8 string didn't get returned as valid JSON.

But I am having trouble reproducing your behaviour Amy.  I created a ODB string variable with a tab control
control character

  sprintf(mystring,"first line \t second line");
  status = db_set_value(hDB, 0,"/test2/mystring", &mystring, size, 1, TID_STRING);

and what I tried to pull the ODB using jcopy

http://neut18:8081/?cmd=jcopy&odb=/test2/mystring&format=json

I got 

{
"mystring/key" : { "type" : 12, "item_size" : 32, "access_mode" : 7, "last_written" : 1477416322 },
"mystring" : "first line \t second line"
}

which seems to be valid JSON.  

I only tried this with tab.  Are there other control characters that you are having trouble with?  Or maybe
I misunderstand the question?





> 
> > 
> > For JSON.parse to successfully parse a string, (A) the string must be valid 
> > UTF-8, (B) several whitespace characters, control characters, and the 
> > characters " and \ must be escaped, and (C) you've got to follow the key-
> > value rules laid out in http://www.json.org/.
> > 
> > The web browser takes care of (A), and I verified that for this key Midas 
> > handled (C) correctly.  In principle, the function json_write in odb.c 
> > handles (B) - but json_write does not escape control characters.
> > 
> > To manage this problem, I modified json_write (in odb.c) to replace any 
> > control character with the more-inocuous character, 'C'.  My default case 
> > now looks like:
> > 
> > default:
> >          {
> >            // if a char is a control character,
> >            // print 'C' in its place
> >            // note that this loses data:
> >            // a more-correct method would be to print
> >            // \uXXXX, where XXXX is the character in hex
> >            if(iscntrl(*s)){
> >              (*buffer)[(*buffer_end)++] = 'C';
> >              s++;
> >            } else {
> >              (*buffer)[(*buffer_end)++] = *s++;
> >            }
> >          }
> >       
> > Where the call to iscntrl(*s) requires the addition of the ctype.h header 
> > file.
> > 
> > I'm guessing a blanket replacement of control characters with 'C' isn't 
> > something all Midas users would want to do.  Replacing the control character 
> > with its hex value seems like a good choice - but not without adding bounds 
> > checking!
> > 
> > An alternative to changing odb.c could be to add a regex to Midas response 
> > text which removes all control characters (U+0000 - U+001F): 
> > 
> > var resp_lint = req.response.replace(/[\u{0000}-\u{001F}]/gmu, '');
> > var json_obj = JSON.parse(resp_lint);
> > 
> > Unfortunately, the 'u' regex flax doesn't work on the Firefox version 
> > included in Scientific Linux 6.8.  
ELOG V3.1.4-2e1708b5