root -l -x -q track_keypress_in_canvas.C

int cc=0;
TH1F h1("h1","h1",800,-400,400);

void myexec()
{
   // get event information
   short event = gPad->GetEvent();
   int px    = gPad->GetEventX();
   int py    = gPad->GetEventY();

   // some magic to get the coordinates...
   /*double xd = gPad->AbsPixeltoX(px);
   double yd = gPad->AbsPixeltoY(py);
   float x = gPad->PadtoX(xd);
   float y = gPad->PadtoY(yd);*/

   //if (event==1) { // left mouse button click, if needed
      //return;
   //}
   if(event==24 && (((char)px =='n' || (char)px=='p'))) { //24 is keypress, px, and py are assigned characters
       //std::cout << (int)event << " " << (char)px << " " << (char)py << std::endl;
       if((char)px=='n') cc++;
       else cc--;
       h1.SetTitle(Form("Color:%d",cc));
       h1.SetFillColorAlpha(cc,0.4);
       gPad->Modified();
       gPad->Update();
       return;
   }
}


void track_keypress_in_canvas()
{
   gStyle->SetOptStat(0);
   h1.GetXaxis()->SetRangeUser(-5,10);
   TF1 f1("gauss",Form("%f*TMath::Exp(-(x-%f)*(x-%f)/(2*2.*2.))",1000.,2.,2.),2.-5,2.+5);
   h1.FillRandom("gauss",1000,nullptr);
   h1.SetLineWidth(2.0);
   h1.GetXaxis()->SetTitle("Hover mouse, press 'n' or 'p' to cycle colors");
   h1.Draw();
   gPad->Modified();
   gPad->Update();

   // add exec
   gPad->AddExec("myexec","myexec()");
}

Basics:

• tolua and tolua++ are present in Linux repositories, in my Ubuntu 22.04LTS installing tolua++ was simple as

  sudo apt install libtolua++5.1-dev
  

• tolua and tolua++ require a package file that has definitions of the requisite class features that need to be exposed. In what’s below, I’ll stick to tolua++5.1 and C++ classes alone, since these are most relevant for ROOT.

Action:

• The following file root1.pkgexposes all the features that I plan to use from ROOT’s class hierarchy : the TH1F to be filled, the TCanvas and TApplication for live updation within a loop. Note that I’ve also included all the classes that the exposed member functions require. Lua already knows about the standard C/C++ types. It is also important to note the $ sign before all the #include lines.

$#include <TH1F.h>
$#include <TCanvas.h>
$#include <TVirtualPad.h>
$#include <TApplication.h>
$#include <TObject.h>

class TH1F {
public:
    TH1F(const char* name, const char* title, int nbinsx, double xlow, double xhigh);
    void Fill(double x);
    void Draw();
};

class TCanvas {
public:
    TCanvas(const char* name, const char* title, int wpx, int wpy, int ww, int hh);
    void SaveAs(const char* filename = "", const char* option = "") const;
    TVirtualPad* cd(int sub=0);
    TObject* WaitPrimitive(const char* pname="",const char *emode="");
    void Update();
    void Modified();
};

class TApplication {
    TApplication(const char* name, int* argc, char** argv, void* options=nullptr, int numoptions=0);
};

• tolua++5.1 can help us convert the above pkg file into a pair of C++ header/source files, that can be used to compile a custom lua5.1 interpreter that ‘knows of’ the extra classes exposed by root1.pkg, in addition to all the capabilities/definitions a regular lua5.1 interpreter brings (such as os and io, and other capabilities). This is accomplished by running in bash the following line. The output file names are arbitrary chosen as hstub.cpp and hstub.hpp keeping with the demo example link.

tolua++5.1 -H hstub.hpp -o hstub.cpp root1.pkg

• If all goes well, the above step promptly creates the two files. Now, we prepare a lua5.1 interpreter by creating the following main.cpp file and compiling it. I have smoothed out the use of extern C via the more elegant syntax of including lua.hpp that comes with all modern versions of lua in package managers. The only additional step here is the inclusion of hstub.hpp and the function tolua_root1_open() defined in hstub.cpp, to load all the additional definitions for use with the lua interpreter. Refer to the tolua manual for details on these.

#include <tolua++.h>
#include "lua.hpp"
#include "hstub.hpp"

int main()
{
    lua_State *L = lua_open();
    luaL_openlibs(L);
    tolua_root1_open(L);

    if (luaL_dofile(L, NULL) != 0)
        fprintf(stderr, "%s\n", lua_tostring(L, -1));

    lua_close(L);
    return 0;
}

• Now to compile the above, we finally require g++, complete with all the necessary includes of both Lua and CERN ROOT, and all the libraries. The compilation/build recipe here is:

g++ -I/usr/include/lua5.1 `root-config --cflags` main.cpp hstub.cpp -ltolua++5.1 -llua5.1 `root-config --glibs` -o root1
rm hstub.*

• The above process creates the executable root1 that is our lua interpreter. I delete the hstub pair since we no longer need them. We now create a Lua5.1 script that can be sent to the interpreter, that does what we set out originally to do: make a TCanvas, fill a TH1F in a loop within it, live update it, and wait for a Ctrl+C before exiting. I’m calling the file roottest.lua, and it looks like this:

print("Calling ROOT via a lua script..\n")
app = TApplication("app",0,0)
c1 = TCanvas("c1","c1",0,0,800,600)
h1 = TH1F("test","test",100,0,1000)
c1:cd()
h1:Draw()
i=0
repeat
    h1:Fill(math.random(0,1000))
    c1:Modified()
    c1:Update()
    i=i+1
until i==1000
c1:SaveAs("test.png")
repeat 
    do end -- empty block, i.e. a 'nop'
until c1:WaitPrimitive()==0 
--only true when Ctrl+C is sent or 'Quit ROOT' is chosen on TCanvas
print("...done.\n")

• Elegant, compact, quick-to-prototype. All things Lua is good at :) Sending the above file to the executable root1 as

./root1 < roottest.lua

should promptly bring up a live-updating histogram. Nice!

• In case one now requires some other ROOT class or property to be exposed, all one needs to do is to edit root1.pkg to include the requisite header files and function declarations, re-run tolua++ to generate updated hstub.cpp+hstub.hpp files, and recompile to update root1’s knowledge. Now, roottest.lua can use the additional classes/properties.

// uncompressed.cxx
#include <cstdint>
#include <stdio.h>
#include <fcntl.h>
#include <vector>
#include <algorithm>
#include <iostream>
#include <cassert>
#include <signal.h>
#include <unistd.h>
#define MAXSIZE 32768

struct header {
  int type; int length; long long timestamp;
};

struct payload {
  int type;
  int errcode;
  int energy;
  int timestamp;
  int channel;
  double waveform[MAXSIZE];
};

bool quit=false;
void handler(int signal) {quit=true;}

int main() {
    /**
      Binary file input.dat contains data packed as header-payload-header-payload. The size of the payload is contained in the header, along with the timestamp and type information.
      We extract only type-1 data in the following, and make a vector of all the unique 'channels' present in the type1 payloads. The files can be huge, so it helps to be able to break out of
      the loop using Ctrl+C.
    */
    header head;
    char buf[32768];
    payload t1d;
    int fd = open("/path/to/input.dat",O_RDONLY);
    if(fd == -1) {
        printf("File data/input.dat not found! Exiting..\n");
        return -1;
    }
    std::vector<int> crystalids;
    int readstatus = 1;
    signal(SIGINT,handler);
    while(readstatus!=0) {
       readstatus = read(fd,(void*)&head,sizeof(head));
       if(head.type==1) {
        readstatus = read(fd,(void*)&t1d,head.length);
        if(std::find(crystalids.begin(),crystalids.end(),t1d.channel)==crystalids.end()) {
          crystalids.push_back(t1d.channel);
        }
       }
       else {
          assert(head.length < 32768);
          readstatus = read(fd,(void*)buf,head.length);
       }
       if(quit) break;
    }
    for(auto& x: crystalids) std::cout << x << " "  << std::endl;
    close(fd);
    return 0;
}

Now, performance considerations aside, it is a pain in the neck to have to gunzip -k every input.dat.gz file just to be able to look through and do the above operation, then delete the result afterwards. Fortunately for us, using the zlib library is said to be both less messy AND better optimized execution-time-wise. To directly read from input.dat.gz and do the same operation as above, simply use

//zlibdemo.cxx
#include <zlib.h>
#include <vector>
#include <iostream>
#include <algorithm>
#include <signal.h>
#include <assert.h>
#define MAXSIZE 32768

struct header {
  int type; int length; long long timestamp;
};

struct payload {
  int type;
  int errcode;
  int energy;
  int timestamp;
  int channel;
  double waveform[MAXSIZE];
};

bool quit=false;
void handler(int signal) { quit = true; }

int main()
{
    header header;
    payload g1;
    uint16_t junk[32768];
    std::vector<int> crystalids;

    gzFile infile = (gzFile)gzopen("/path/to/input.dat.gz", "rb");
    gzrewind(infile);
    signal(SIGINT,handler);

    while(!gzeof(infile))
    {
        int len = gzread(infile, &header, sizeof(header));
        switch(header.type) {
            case 1: gzread(infile, &g1, header.length);
                    if(std::find(crystalids.begin(),crystalids.end(),g1.channel)==crystalids.end()) {
                        crystalids.push_back(g1.channel);
                    }
                    break;
            default: assert(header.length<32768);
                     gzread(infile, &junk, header.length);
        }
        if(quit) break;
    }
    for(auto& x: crystalids) std::cout << x << " "  << std::endl;
    gzclose(infile);
    return 0;
}

Of course, the files are compiled as:

g++ uncompressed.cxx -o uncompressed 

for the original file, and

g++ zlibdemo.cxx -o zlibdemo -lz

for the zlib version. Everything in the first version is contained in standard C/C++ libraries, while the second version needs us to link to zlib’s shared libraries.

Dockerfile example:

# Sample dockerfile to illustrate how to setup a self-contained myprogram install. I'm using myprogram.contourer without GUI as a demonstration.
# 1) Install docker in the system
# 2) Create a folder with all files: this Dockerfile, the <filename>.tar.gz file
# 3) From this folder, run:
#       docker build --no-cache -t rocky9,myprogram:0.1 ./
# where the name 'rocky9,myprogram:0.1' is somewhat arbitrary and can be tinkered with
# 4) Fol#
# Sample dockerfile to illustrate how to setup a self-contained myprogram install. I'm using myprogram.contourer without GUI as a demonstration.
# 1) Install docker in the system
# 2) Create a folder with 3 files: this Dockerfile, the myprogram.contourer.tar.gz file and the Minuit2-master.zip file
# 3) From this folder, run:
#       docker build --no-cache -t rocky9,myprogram:0.1 ./
# where the name 'rocky9,myprogram:0.1' is somewhat arbitrary and can be tinkered with
# 4) Following it running fully, it will show up in the list of images that can be opened as
#       docker images --digests
# 5) Attach to this container thereafter by running 
#       docker run -it rocky9,myprogram:0.1
#   and exit from the session by 'exit'
#            -Sudarsan B, 16 Nov 2023, bsudarsan92-at-gmail.com
#
FROM rockylinux:9
LABEL maintainer=sud
LABEL version=0.1
COPY placeholderprogram.tar.gz /home/
RUN dnf upgrade -y --refresh && \
 dnf group install -y "Development Tools" && \
 dnf install -y readline-devel && \
 dnf update && \
 dnf install -y epel-release && \
 dnf -y install root && \
 dnf -y install nano 
WORKDIR /home/
ENV DOCKERHOME=.

RUN ls && \
 ls /home/ && \
 cd /home/ && \
 tar -xvf placeholderprogram.tar.gz && \
 mkdir /home/placeholderprogram/AprMay2024/ && \
 cd placeholderprogram && \
 make
CMD /bin/bash

Navigate to a directory containing a Dockerfile, and run the following:

sudo docker build --no-cache -t docker.containername:0.1 .

It is nice to have a yaml file that allows one to tailor and create any maps between local and container directories, for ex. Do that by saving the following as gs_loader.yaml (say)

services:
  rocky9.gs:
    # platform: linux/arm64,linux/amd64 
    build:
      context: .
#      additional_contexts:
#        - mysrc=${DOCKERHOME}/provisioning
#      dockerfile: ${DOCKERHOME}/DockerConfigs/GODDESS_SORT_Fedora.dockerfile
    environment:
      - DISPLAY=host.docker.internal:0
      - LANG=${LANG}
      - TERM=xterm-256color
    volumes:
      - /etc/localtime:/etc/localtime:ro
#      - ${DOCKERHOME}/AprMay2024:/home/placeholderprogram/AprMay2024
      - ./AprMay2024/:/home/placeholderprogram/AprMay2024
    stdin_open: true
    tty: true

The built docker container can be attached to by running the following:

sudo docker compose -f gs_loader.yaml run rocky9.gs

And you will be in the container, reading and writing to the host’s AprMay2024 folder

• We had a custom Makefile that worked on bash, which uses root-config to dynamically assign compiler flags and libraries
• Fix 1: Go to Project > Properties
  • Tick “This is a custom Makefile”.
  • If we don’t do this Code::Blocks will make assumptions about how to compile files. At first glance, the process seems to go by turning compile source (*.c, *.cpp etc) files to .o and trying to link all the .o’s together to an executable with the project’s name.

• Fix 2: If you now click ‘Build’, the default command that gets run would be make -f Makefile Debug or make -f Makefile Release, because Code::Blocks expects this sort of structure.
  • Sometimes, like in our case, you want some control on this behavior instead of redesigning the makefile.
  • To fix this, go to Project > Properties > Project's Build Options > "Make" Commands, and remove all mentions of $target in there. We only need make -f Makefile typically. Or, you could add whatever other ‘make’ switches/tricks you require here.

• Fix 3: Okay, let’s try compiling again after hitting “OK” as many times as needed so the settings above are saved.
  • If your Makefile has all the root-config mentions expanded out in full, things will run fine. But if you have our situation, and have the makefile literally use root-config --cflags etc as part of recipes, Code::Blocks will fail at the first mention of ‘root-config’ or ‘rootcint’ with something like bash: line 1: root-config: command not found.
  • This happens because Code::Blocks does not have all the right paths in its global $PATH variable to ‘see’ root-config and other things hidden in $ROOTSYS/bin, with $ROOTSYS typically defined in .bashrc by running source /path/to/root/bin/thisroot.sh. What do we do? Skip the next step, I just had to put it in there so I remember it.
  • I tried a few things that didn’t work, like adding ‘source ~/.bashrc’ in Project > Build Options > Pre/Post Build Steps, or doing a $PATH export there like export PATH=$PATH:/<path>/<to>/<root>/bin/. They didn’t do much as of CB version 20.03.
  • What did help, was navigating to Settings > Compiler > Toolchain Executables > Additional Paths hidden away deep, and using Add to add, in our case, /opt/root-6.28.06/bin/ which was the installation directory, containing root-config, rootcint, thisroot.sh etc. Following all this, running “Make” will do all it has to do, following the exact process make all would’ve done for us in bash, and bringing up the executable in an xterm window when we hit ‘run’.

• Parting comment: There is something to be said about the convenience of the IDE telling you all about function syntaxes as you type them, and the option of doing debug-testing while being a little spoiled. Using a custom Makefile also gives us full control over how we compile the project, which was what originally dragged me away from half-cooked IDEs.
• Parting comment #2: Settings > Compiler.. > Global Compiler Settings > Search Directories > Add can be used to include a pathname to ROOT’s include directory, such as /opt/root-6.28.06/include/, which will then turn-on the extremely helpful ‘code-completion’ toolkit that auto-suggests function templates and similar details as you type. ROOT’s default online documentation landscape can be a little cumbersome to explore, this might help save some consternation when you’re trying to remember the exact order of an obscure constructor or method.

Tested using:

- GNU Make 4.3
- gcc 11.4
- Code::Blocks 20.03
- CERN ROOT v6.28.03
- All running in Ubuntu 22.04 with a Linux-6.2 Kernel