Difference: HyperDAQ (1 vs. 2)

Revision 211 Sep 2015 - EricHazen

Line: 1 to 1
 
META TOPICPARENT name="Amc13CppProductionSoftwareToDoList"
Some ideas on AMC13 HyperDAQ code structure.
Line: 7 to 7
 

Changes in existing Status class

Changed:
<
<
  • Replace SetHTML() etc with a new SetOutputMode().
>
>
  • Add new SetOutputMode() as an improvment over SetHTML() etc (keep old methods for compatibility)
 
  • Add new methods for accessing separate sections of output:
    • ReportHeader() for header information required to start output document
    • ReportStyle() for CSS or other similar information which affects rendering
    • ReportBody() for main content (with optional table specifier)
    • ReportTrailer() for trailer information required to terminate output document
Added:
>
>
    • Each of the above would have two prototypes, one outputting to a stream, the other returning a string
      • void ReportHeader( int level, std::ostream...)
      • std::string ReportHeader( int level...)
 
  • Existing Report() would use above to output a complete report
Deleted:
<
<
  • Above methods would have overloaded version to return a std::string as ReportBare() does now.
 
  • Add new methods to allow access to data using the table/row/column addressing scheme (maybe the SparseCellMatrix class already provides this?)
    • GetTableList() method to retrieve a vector of defined tables
    • GetTableRows() and GetTableColumns methods to retrieve a list of table rows/columns
Line: 26 to 28
  Could in principle be done using the existing structure by adding them as tables which don't show in the normal status display, but could be retrieved by table name. How would this work for a variable-length list? Is it worth adding this to the address table?
Added:
>
>
Eric is going to work on this.
 How to integrate Daniel's unpacker code for data display?

How to handle subdetector-specific display information?

Added:
>
>
Dan will discuss both of these with Daniel
 Do we want to provide a simple stand-alone framework to test this code without having to run HCAL xDAQ?
Changed:
<
<
Is there a sufficiently simple open-source web server we could use? In principle one can run a program using cgicc from the command line, setting the environment variables and feeding it a query on standard input. This seems rather complex. Probably easier just to use the apache server already available on linux systems and build a test executable.
>
>
Should eventually move all web display code from the xDAQ to a separate class, and build a stand-alone CGI executable for testing.
  -- EricHazen - 11 Sep 2015

Revision 111 Sep 2015 - EricHazen

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="Amc13CppProductionSoftwareToDoList"
Some ideas on AMC13 HyperDAQ code structure.

Currently have amc13::Status with Report() and set/get methods for HTML, BareHTML and LaTeX. Suggest the following:

Changes in existing Status class

  • Replace SetHTML() etc with a new SetOutputMode().
  • Add new methods for accessing separate sections of output:
    • ReportHeader() for header information required to start output document
    • ReportStyle() for CSS or other similar information which affects rendering
    • ReportBody() for main content (with optional table specifier)
    • ReportTrailer() for trailer information required to terminate output document
  • Existing Report() would use above to output a complete report
  • Above methods would have overloaded version to return a std::string as ReportBare() does now.
  • Add new methods to allow access to data using the table/row/column addressing scheme (maybe the SparseCellMatrix class already provides this?)
    • GetTableList() method to retrieve a vector of defined tables
    • GetTableRows() and GetTableColumns methods to retrieve a list of table rows/columns
    • GetCell() method to get the Cell() given table/row/column

Questions:

How to handle things like the TTC command history, L1A history, data dump etc?

Could in principle be done using the existing structure by adding them as tables which don't show in the normal status display, but could be retrieved by table name. How would this work for a variable-length list? Is it worth adding this to the address table?

How to integrate Daniel's unpacker code for data display?

How to handle subdetector-specific display information?

Do we want to provide a simple stand-alone framework to test this code without having to run HCAL xDAQ?

Is there a sufficiently simple open-source web server we could use? In principle one can run a program using cgicc from the command line, setting the environment variables and feeding it a query on standard input. This seems rather complex. Probably easier just to use the apache server already available on linux systems and build a test executable.

-- EricHazen - 11 Sep 2015

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback