ID |
Date |
Author |
Topic |
Subject |
640
|
06 Sep 2009 |
Exaos Lee | Suggestion | Could not create strings other than 32 characters with odbedit -c "..." command | > > Ok, I added a command
> >
> > odbedit -c "create STRING Test[8][40]"
> >
> > which works now. Please update to SVN revision 4555 of odbedit.c
> >
> > - Stefan
>
> If I want to create only one string, should I write like this:
>
> odbedit -c "create STRING Test[] [256]"
>
> OK. I need it. I will try the new odbedit.
"create STRING test[1][256]" works. |
663
|
15 Oct 2009 |
Exaos Lee | Suggestion | Building MIDAS using CMake | The attached zip file is the updated configurations for building MIDAS using CMake. It works with svn-r4604.
If you want to use it, please follow the steps here:
Quote: |
- Unzip the attachment, copy CMakeLists.txt and directory "cmake" into the midas source tree.
$ cp -rp CMakeLists.txt cmake/ <Path-to-MIDAS-tree>/ - Make a build dir, and change to it.
- Execute cmake as this
$ cmake -DCMAKE_INSTALL_PREFIX=<path-to-install> <path-to-MIDAS-tree> - Make and install
|
You may use 'cmake -G <generator-name>' to generate building files for Unix Makefiles, Eclipse CDT4, KDevelop3 or Xcode, etc. I didn't test with other platforms. It now works with Unix Makefiles under Linux system. Please feedback any bugs to me: Exaos.Lee(AT)gmail.com . |
Attachment 1: cmake4midas.zip
|
668
|
02 Nov 2009 |
Exaos Lee | Suggestion | New cmake files | Though ended with ".c", "lazylogger.c" has to be build with C++ compiler. I have
to modify my CMakeLists.txt.
Please see the attachment if you need it. It works with svn-r4616. |
Attachment 1: cmake4midas.zip
|
674
|
23 Nov 2009 |
Exaos Lee | Suggestion | Scripts for "midas-config" | Supposing you have installed MIDAS to some directory such as "/opt/MIDAS/r4621", you have to write some Makefile as the following while building some applications based on the version installed:
Quote: |
CFLAGS += -I/opt/MIDAS/r4621/include -DOS_LINUX -g -O2 -Wall -fPIC
LIBS += -lutil -lpthread -lodbc -lz
....
|
Why not use a script to record your MIDAS building options? When you want to build something based on it, just type something such as
Quote: |
M_CFLAGS := `midas-config --cflags`
M_LIBS := `midas-config --libs`
|
You needn't to check your installed options each time when you build something against it. Each time you install a new version of MIDAS, you only need to update the script called 'midas-config'. I wrote a sample script named "genconf.sh" in the first zipped attachment. The 2nd "midas-config" is a sampled generated by it. Also a diff of Makefile is included. I hope it may help. |
Attachment 1: genc.zip
|
Attachment 2: midas-config
|
#!/bin/sh
prefix=/usr/local
cflags="-I/usr/local/include -g -O2 -Wall -Wuninitialized -DINCLUDE_FTPLIB -DOS_LINUX -fPIC -Wno-unused-function -DHAVE_ODBC -DHAVE_ZLIB"
st_libs="-lutil -lpthread -lodbc -lz /usr/local/lib/libmidas.a"
dyn_libs="-lutil -lpthread -lodbc -lz -L/usr/local/lib -lmidas"
incdir=/usr/local/include
libdir=/usr/local/lib
svnver=r4621
platform=linux
drvdir=/usr/local/share/drivers
camacdir=/usr/local/share/drivers/camac
vmedir=/usr/local/share/drivers/vme
srcdir=/usr/local/share/src
exampledir=/usr/local/share/examples
out=""
while test $# -gt 0; do
case "$1" in
-*=*) optarg=/usr/local ;;
*) optarg= ;;
esac
case $1 in
--prefix)
out="$out ${prefix}"
;;
--cflags|-c)
out="$out ${cflags}"
;;
--incdir|-dI)
out="$out ${incdir}"
;;
--libdir|-dL)
out="$out ${libdir}"
;;
--libs|--static-libs|-l)
out="$out ${st_libs}"
;;
--dyn-libs)
out="$out ${dyn_libs}"
;;
--platform)
out="$out ${platform}"
;;
--drvdir|-dD)
out="$out ${drvdir}"
;;
--camacdir|-dC)
out="$out ${camacdir}"
;;
--vmedir|-dV)
out="$out ${vmedir}"
;;
--srcdir|-dS)
out="$out ${srcdir}"
;;
--exampledir|-dE)
out="$out ${exampledir}"
;;
--version|-v)
out="$out ${svnver}"
;;
--help|-h)
echo "Usage: midas-config [options]"
echo "Options:"
echo " --prefix Display the installation prefix"
echo " --cflags,-c Display C/C++ flags using for compilation"
echo " --incdir,-dI Display midas header directory installed"
echo " --libdir,-dL Display midas library directory installed"
echo " --libs, -l"
echo " --static-libs Display link flags while linking with static midas library"
echo " --dyn-libs Display link flags while linking with dynamic library"
echo " --platform Display installed platform"
echo " --drvdir,-dD Display the driver directory"
echo " --camacdir,-dC Display the directory including CAMAC APIs"
echo " --vmedir,-dV Display the directory including VME APIs"
echo " --srcdir,-dS Display the source directory"
echo " --exampledir,-dE Display the examples directory"
echo " --version, -v Show the subversion number"
echo " --help, -h Display this usage"
echo
exit 0
;;
*)
### Give an error
echo "Unknown argument \"/usr/local\"!" 1>&2
echo "${usage}" 1>&2
exit 1
;;
esac
shift
done
echo $out
|
691
|
22 Dec 2009 |
Suzannah Daviel | Suggestion | Redesign of status page links | > The custom and alias links in the standard midas status page were shown as HTML
> links so far. If there are many links with names having spaces in their names,
> it's a bit hard to distinguish between them. Therefore, they are packed now into
> individual buttons (see attachment) starting from SVN revision 4633 on. This makes
> also the look more homogeneous. If there is any problem with that, please report.
Would you consider using a different colour for the alias buttons (or background
colour)? At present it's hard to know whether a button is an alias link, a custom page
link or a user-button especially if you are not familiar with the button layout. |
692
|
11 Jan 2010 |
Stefan Ritt | Suggestion | Redesign of status page links | > > The custom and alias links in the standard midas status page were shown as HTML
> > links so far. If there are many links with names having spaces in their names,
> > it's a bit hard to distinguish between them. Therefore, they are packed now into
> > individual buttons (see attachment) starting from SVN revision 4633 on. This makes
> > also the look more homogeneous. If there is any problem with that, please report.
>
> Would you consider using a different colour for the alias buttons (or background
> colour)? At present it's hard to know whether a button is an alias link, a custom page
> link or a user-button especially if you are not familiar with the button layout.
Ok, I changed the background colors for the button rows. There are now four different
colors: Main menu buttons, Scripts, Manually triggered events, Alias & Custom pages. Hope
this is ok. Of course one could have each button in a different color, but then it gets
complicated... In that case I would recommend to make a dedicated custom page with all these
buttons, which you can then tailor exactly to your needs. |
Attachment 1: Capture.png
|
|
768
|
24 Jun 2011 |
Exaos Lee | Suggestion | Build MIDAS debian packages using autoconf/automake. | Here is my story. I deployed several Debian Linux boxes as the DAQ systems in our lab. But I feel it's boring to build and install midas and its related softwares (such as root) on each box. So I need a local debian software repository and put midas and its related packages in it. First of all, I need a midas debian package. After a week's study and searching, I finally finished the job. Hope you feel it useful.
All the work is attached as "daq-midas_deb.tar.gz". The detail is followed. I also created several debian packages. But it's too large to be uploaded. I havn't my own site accessible from internet. So, if you need the debian packages, please give me an accessible ftp or other similar service, then I can upload them to you.
First, I use autoconf/automake to rewrite the building system of MIDAS. You can check it this way:
1. Untar daq-midas_deb.tar.gz somewhere, assumming ~/Temp.
2. cd ~/Temp/daq-midas
3. svn co -r 5065 svn+ssh://svn@savannah.psi.ch/repos/meg/midas/trunk midas
4. svn co -r 68 svn+ssh://svn@savannah.psi.ch/repos/meg/mxml/trunk mxml
5. cp -rvp debian/autoconf/* ./
6. ./configure --help
7. ./configure <--options>
8. make && make install
Then, I created the debian packages based on the new building files. You need to install root-system package from http://lcg-heppkg.web.cern.ch/lcg-heppkg/debian/. You can build debs this way:
1. untar daq-midas_deb.tar.gz somewhere, assuming ~/Temp.
2. cd ~/Temp/daq-midas
3. svn co -r 5065 svn+ssh://svn@savannah.psi.ch/repos/meg/midas/trunk midas
4. svn co -r 68 svn+ssh://svn@savannah.psi.ch/repos/meg/mxml/trunk mxml
5. dpkg-buildpackage -b -us -uc
I split the package into serverals parts:
- daq-midas-doc -- The documents and references
- daq-midas-root -- the midas runtime library and utilities built with root
- daq-midas-noroot -- the midas runtime library and utilities built without root
- daq-midas-dev-root -- the midas devel files (headers, objects, drivers, examples) built with root
- daq-midas-dev-noroot -- the midas devel files (headers, objects, drivers, examples) built without root
Here are the installation:
- executalbes -- /usr/lib/daq-midas/bin
- library and objs -- /usr/lib/daq-midas/lib
- headers -- /usr/lib/daq-midas/include
- sources and drivers -- /usr/share/daq-midas/
- docs and examples -- /usr/share/doc/daq-midas
- mdaq-config -- /usr/bin/mdaq-config
I add an auto-generated shell script -- mdaq-config. It behaves just like "root-config". You can get midas build flags and link flags this way:
gcc `mdaq-config --cflags` -c -o myfe.o myfe.c
gcc `mdaq-config --libs` -o myfe myfe.o `mdaq-config --libdir`/mfe.o
Bugs and suggestions are welcomed.
P.S. Based on debian packages, I am planing to write another script, "mdaq.py":
- each midas experiment will be configured in a file named "mdaq.yaml"
- mdaq.py reads the configure file and prepare the daq environment, just like "examples/experiment/start_daq.sh"
- mdaq.py will handle "start/stop/restart/info" about the daq codes.
The attached "mdaq.py" is the old one. |
Attachment 1: daq-midas_deb.tar.gz
|
Attachment 2: mdaq.py
|
#!/usr/bin/env python
'''
Python script to handle daq sessions using MIDAS/PSI.
Auther: Exaos Lee <Exaos DOT Lee AT gmail DOT com>
Date: 2009-07-15
'''
import os, os.path
import sys, signal, time
from commands import getoutput
from ConfigParser import ConfigParser
from pprint import pprint
class mdaq:
_codes_ = { 'MSERVER':"MIDAS Server", 'MHTTPD':"MIDAS HTTPD Server",
'ODBEDIT':"ODB Editor", 'LOGGER':"Data Logger",
'PROG_FE':"Frontend", 'PROG_ANA':"Analyzer" }
_env_ = dict()
def __init__(self,**kws):
env = dict()
if kws.has_key('fname') and kws['fname'] != "":
env = self.parse_conf(kws['fname'])
self.apply_env(env)
def parse_conf(self, fname):
if not os.path.isfile(fname):
print("**WARNING** File \"%s\" does not exist!"%fname)
return None
conf = ConfigParser()
conf.read(fname)
env={'CONF_FILE':fname }
fcpath = os.path.dirname(fname)
sec = 'EXP_INFO' ## Parsing Experiment Information
env['EXP_INFO'] = [ self.safe_parse(conf,sec,'Name'),
self.safe_parse(conf,sec,'Info'), ]
msg = self.safe_parse(conf,sec,'DAQ_DIR')
if msg != "" and os.path.isdir(msg):
dpath = msg
if not os.path.isabs(msg):
dpath = os.path.join(os.path.abspath(fcpath),msg)
env['DAQ_DIR'] = os.path.normpath(dpath)
## Parsing MIDAS configuration
env['MIDASSYS'] = ["MIDAS System Path",
self.safe_parse(conf,"MIDAS","MIDASSYS")]
if env['MIDASSYS'][1]=="": env['MIDASSYS'][1] = self.get_default_msys()
## Parsing Info of programs
for key in self._codes_.keys():
code = self.parse_prog_opt(conf, key, fpath=fcpath)
if code:
env[key] = [self._codes_[key], ]
env[key].extend(code)
port = self.safe_parse(conf, "MHTTPD","PORT")
if port != "":
if not env.has_key('MHTTPD'):
env['MHTTPD'] = ["MIDAS HTTP Server",
os.path.join(env['MIDASSYS'][1],"bin/mhttpd"),
"-h localhost -D"]
if "-p %s"%port not in env['MHTTPD'][2]:
env['MHTTPD'][2] = env['MHTTPD'][2] + " -p %s"%port
return env
def parse_prog_opt(self, cnf, sec, fpath="./"):
name = self.safe_parse(cnf, sec, "NAME")
path = self.safe_parse(cnf, sec, "PATH")
fn = os.path.join(path,name)
if name == "": fn = ""
elif not os.path.isabs(fn):
fn = os.path.normpath(os.path.join(os.path.abspath(fpath),fn))
else:
fn = os.path.normpath(fn)
opts = self.safe_parse(cnf, sec, "Option")
if opts != "" or name != "":
return [fn, opts]
return None
def safe_parse(self, cnf, sec, opt):
try: return cnf.get(sec,opt)
except: return ""
def get_default_msys(self):
if os.environ.has_key('MIDASSYS'): return os.environ['MIDASSYS']
return "/opt/MIDAS.PSI/Version/Current"
def apply_env(self, daq_env=dict()):
env = daq_env
if not env:
print("** WARNING** No environment defined! Using the default values. ****")
env = {'MIDASSYS':['MIDAS System Path', ""], 'CONF_FILE':"", }
if not env.has_key('MIDASSYS'): env['MIDASSYS'] = ['MIDAS System Path',""]
if env['MIDASSYS'][1]=="": env['MIDASSYS'][1] = self.get_default_msys()
def_env = {
'MSERVER' :["MIDAS Server",
os.path.join(env['MIDASSYS'][1],"bin/mserver"),
"-D", True],
'MHTTPD' :["MIDAS HTTP Server",
os.path.join(env['MIDASSYS'][1],"bin/mhttpd"),
"-h localhost -D -p 8080", True],
'ODBEDIT' :["ODB Editor",
os.path.join(env['MIDASSYS'][1],"bin/odbedit"),
"-c clean", False],
'LOGGER' :["Data Logger",
os.path.join(env['MIDASSYS'][1],"bin/mlogger"),
"", True],
'PROG_FE' :["Frontend","", "", True],
'PROG_ANA':["Analyzer","", "", True],
'EXP_INFO':["test","The test experiment"],
'DAQ_DIR':os.path.join(os.environ['HOME'],"online/test") }
for key in def_env.keys():
if not env.has_key(key): env[key] = def_env[key]
for key in self._codes_.keys():
if env[key][1] == "": env[key][1] = def_env[key][1]
if env[key][2] == "": env[key][2] = def_env[key][2]
if not os.path.isdir(env['DAQ_DIR']):
try: os.makedirs(env['DAQ_DIR'])
except: print("ERROR to make file")
## Asign default program options
exp_opt = "-e %s"%env['EXP_INFO'][0]
for key in ['LOGGER', 'PROG_FE', 'PROG_ANA', "MHTTPD"]:
if exp_opt not in env[key][2]:
env[key][2] = exp_opt + ' ' + env[key][2]
if "-D" not in env[key][2]:
env[key][2] = env[key][2] + ' -D'
if exp_opt not in env['ODBEDIT'][2]:
env['ODBEDIT'][2] = env['ODBEDIT'][2] + ' ' + exp_opt
self._env_ = env
def print_conf(self):
print "\n================= DAQ Config ====================="
for key in self._env_.keys():
print key,": ",
pprint(self._env_[key])
def info(self): self.print_conf()
## running programs
def getpids(self, pname):
return [int(k) for k in getoutput("pidof %s"%pname).strip().split()]
def kill_prog(self,pname):
for i in self.getpids(pname): os.kill(i,signal.SIGTERM)
def run_prog(self, prog):
if len(prog)>=4 and not prog[3]: return
if len(prog)>=3 and prog[1]:
print("Starting %s: %s"%(prog[0],prog[1]))
os.system("%s %s"%(prog[1],prog[2]))
else:
print("%s: no executable exist!"%prog[0])
def get_status(self,pfile):
msg = "Not running!"
pids = self.getpids( os.path.basename(pfile) )
if pids: return 'PIDs = ' + str(pids)
return msg
def echo_status(self,pname,pfile):
print("%s:\n %s\n "%(pname,pfile)
+ self.get_status(pfile))
## Session manage: start, stop, status, restart
def status(self):
print( "\n===== Session status for experiment \"%s\" =====\n" %
self._env_['EXP_INFO'][0] )
for code in ['MSERVER','MHTTPD','LOGGER','PROG_FE','PROG_ANA']:
self.echo_status(self._env_[code][0], self._env_[code][1])
def start(self):
## Running mserver & mhttpd
ms_pids = self.getpids(os.path.basename(self._env_['MSERVER'][1]))
if not ms_pids:
self.run_prog(self._env_['MSERVER'])
print("Killing %s ...\n"%self._env_['MHTTPD'][0])
self.kill_prog(self._env_['MHTTPD'][1])
if not self.getpids(os.path.basename(self._env_['MHTTPD'][1])):
self.run_prog(self._env_['MHTTPD'])
## Running FE and Analyzer
old_path = os.getcwd()
os.chdir( self._env_['DAQ_DIR'] )
# Init ODB
print("Initializing ODB for experiment %s ..." % self._env_['EXP_INFO'][0])
self.run_prog(self._env_['ODBEDIT'])
time.sleep(1)
# First stop, then start ...
self.stop()
time.sleep(1)
# Start FE & ANA
self.run_prog(self._env_['PROG_FE'])
self.run_prog(self._env_['PROG_ANA'])
time.sleep(1)
# Start Logger
self.run_prog(self._env_['LOGGER'])
os.chdir(old_path)
def stop(self):
for key in ["LOGGER", "PROG_FE", "PROG_ANA"]:
if self._env_[key][1]:
print("Killing threads:\n %s"%self._env_[key][1])
self.kill_prog(self._env_[key][1])
def stop_all(self):
self.stop()
for key in ['MHTTPD', 'MSERVER']:
if self._env_[key][1]:
print("Killing threads:\n %s"%self._env_[key][1])
self.kill_prog(self._env_[key][1])
def restart(self): self.start()
if __name__=='__main__':
from optparse import OptionParser
usage = "usage: %prog [options] <command>"
parser = OptionParser(usage=usage, version="%prog 0.1")
parser.add_option("-c","--config", metavar="filename",
help="Read config from FILENAME")
cmds = ["start","stop","stop_all","restart","status","info"]
(opts,args) = parser.parse_args( sys.argv[1:] )
if not args or len(args)>2:
parser.print_help()
print "\nCommands:\n\t",
pprint(cmds)
exit()
fcnf = "daq.conf"
if opts.config: fcnf = opts.config
if args[0] in cmds:
daq = mdaq(fname=fcnf)
exec( "daq.%s()"%args[0] )
else:
parser.print_help()
print "\nCommands:\n\t",
pprint(cmds)
|
769
|
27 Jun 2011 |
Konstantin Olchanski | Suggestion | Build MIDAS debian packages using autoconf/automake. | > I deployed several Debian Linux boxes as the DAQ systems in our lab. But I
feel it's boring to build and install midas and its related softwares (such as
root) on each box.
Our solution at TRIUMF is to install such packages on a shared NFS filesystem
visible to all client computers. This works well for ROOT and but MIDAS we found
it nearly impossible to keep MIDAS versions in sync between different projects
and expiments, so each experiment uses it's own copy of MIDAS, usually located
in the experiment home directory ($HOME/packages/midas). Because we often need
to make local modifications to MIDAS sources (Makefile, etc), we do not
"install" MIDAS into non-user-writable /usr/local & etc.
> I use autoconf/automake
The promise (premise) of autoconf/automake is to "hide" system dependencies. The
scripts are supposed to automatically probe the build environment and construct
an appropriate Makefile.
In practice, the autotool scripts always have bugs and incorrect assumptions
about the build environment and only work well for a few standardized systems
(RHEL and Debian derivatives) where the differences are so trivial that
autotools is an overkill and a normal Makefile is adequate for the job.
In my experience, as soon as I try to build an autotool-ized package on anything
that does not look like RHEL or Debian, autotool scripts explode and have to be
debugged and kludged by hand. Anybody who has ever done that would agree with me
that one would rather hack the ugliest Makefile than any of the autotool
generated gibberish.
And of course autotools have never handled cross-compilation in any reasonable
way. Since we do cross-compile MIDAS (for VxWorks and embedded Linux, see "make
crosscompile") a Makefile is required and it so happens that the same Makefile
also works for normal Linux and MacOS, thank you very much.
> Here are the installation:
> [*] executalbes -- /usr/lib/daq-midas/bin
> [*] library and objs -- /usr/lib/daq-midas/lib
Is this in violation of the LSB (or LFS)? I though they mandate that files
controlled by package manager should be /usr/bin/odbedit, /usr/lib64/libmidas.a,
etc (/usr/bin/midas/odbedit no permitted).
> gcc `mdaq-config --cflags` -c -o myfe.o myfe.c
Please check if your config scripts correctly handle the "-m32" and "-m64" flags
- we frequently cross-compile 32-bit MIDAS executables on 64-bit machines.
K.O. |
846
|
14 Dec 2012 |
Vinzenz Bildstein | Suggestion | Midas + Elog with SSL | I've been trying to set up midas to create an automatic elog entry at the end of
each run and I've run into a problem. I've setup an elog on our server which
uses SSL and it seems that the melog provided by midas to create logbook entries
doesn't know any SSL.
My solution to this was to copy the crypt.c from the elog package to the
computer running midas and changed melog.c and the makefile to use SSL if a flag
-s is used. Does this seem like a sensible solution or did I oversee the obvious
and/or right way to do this? |
847
|
14 Dec 2012 |
Stefan Ritt | Suggestion | Midas + Elog with SSL | > I've been trying to set up midas to create an automatic elog entry at the end of
> each run and I've run into a problem. I've setup an elog on our server which
> uses SSL and it seems that the melog provided by midas to create logbook entries
> doesn't know any SSL.
>
> My solution to this was to copy the crypt.c from the elog package to the
> computer running midas and changed melog.c and the makefile to use SSL if a flag
> -s is used. Does this seem like a sensible solution or did I oversee the obvious
> and/or right way to do this?
Indeed melog.c is an old version of the elog.c utility in the elog package, which has not been maintained since a
long time. Can't you just use the recent elog.c utility from the elog package? |
848
|
17 Dec 2012 |
Vinzenz Bildstein | Suggestion | Midas + Elog with SSL | > > I've been trying to set up midas to create an automatic elog entry at the end of
> > each run and I've run into a problem. I've setup an elog on our server which
> > uses SSL and it seems that the melog provided by midas to create logbook entries
> > doesn't know any SSL.
> >
> > My solution to this was to copy the crypt.c from the elog package to the
> > computer running midas and changed melog.c and the makefile to use SSL if a flag
> > -s is used. Does this seem like a sensible solution or did I oversee the obvious
> > and/or right way to do this?
>
> Indeed melog.c is an old version of the elog.c utility in the elog package, which has not been maintained since a
> long time. Can't you just use the recent elog.c utility from the elog package?
Well, that's essentially what I did, I just didn't want to install the whole elog package on the midas server. Whether
the utility is called elog or melog doesn't really matter. I just wanted to make sure that this is the right way to do
it.
Thanks! |
851
|
04 Jan 2013 |
Nabin Poudyal | Suggestion | how to start using midas | Please, tell me how to choose a value of a "key" like DCM, pulser period,
presamples, upper thresholds to run a experiment? where can I find the related
informations? |
969
|
27 Feb 2014 |
Andreas Suter | Suggestion | runlog is "ugly" | I have a couple of questions and suggestions concerning the "new" CSS style of the mhttpd, especially related to the runlog
- If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd. Wouldn't it be beneficial to have ODB entries where to get is from? This way people could change the look and feel more freely.
- Especially the look and feel of the runlog is unsatisfactorily from my point of view. See . The old style was much more readable. I could recover the old style look and feel by slightly changing the mhttpd.cxx where I changed in show_rawfile(const char*) "dialogTable" to "runlogTable" in the table class. This way I could tinker around with the mhttpd.css by adding the following stuff there:
- adding .runlogTable in line 289 :
- adding some style information for the runlogTable :
This way the "old" runlog look and feel recovered : , which I think is much more readable.
If possible, I would love to have alternating background colors between the runs for readability reasons, but I am not sure how easy it would be to add something like this.
I not much experience with HTML/CSS yet, though a concrete implementation might be different. |
970
|
27 Feb 2014 |
Konstantin Olchanski | Suggestion | runlog is "ugly" | > If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd.
mhttpd.css is served from $MIDASSYS/resources/mhttpd.css. The actual path is reported on the mhttpd
"help" page.
(I think the internal mhttpd.css and mhttpd.js should be removed as no longer useful - nothing will work
right if the real mhttpd.js and mhttpd.css cannot be served).
> Especially the look and feel of the runlog is unsatisfactorily from my point of view.
persons in charge of implementing the CSS stuff failed to convert quite a few pages, for example, the elog
and the history editor pages were left completely broken. (mostly fixed now).
so thank you for reporting the runlog breakage, I hope Stefan & co can fix it quickly. (I cannot do - I have
have no runlog pages on any of my test experiments).
> the old style was much more readable.
I think the new style is not too bad, except for a few visual artefacts here and there, the general comment
that CSS is too complicated and hard to debug and the fact that over-subtle colouring yields inconsistent
visuals between different monitors and ambient lighting conditions. (persons who select the colours always
respond that "but to me, it looks just fine on my laptop", making it hard to resolve any issues).
> I could recover the old style look and feel by slightly changing the mhttpd.cxx
If you post the patches that fix it for you, I can commit them to midas. (git diff | mail olchansk@triumf.ca).
K.O. |
973
|
28 Feb 2014 |
Andreas Suter | Suggestion | runlog is "ugly" | Understand me right, I mostly like the new style, except the runlog as reported.
Attached you will find the diff's you were asking for. But as pointed out, I
haven't worked so far on CSS and hence this should be checked!!
I understand that the mhttpd.js needs to be the default one, however, mhttpd.css
might be left to the end-user to adopt to their specific needs. I shortly
checked in the mhttpd demon. It checks for the resources path in the ODB. If it
also would check for a CSS name, mhttpd.css could be changed/adopted by the
end-users without breaking things (at least it would then be their one business).
> > If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd.
>
> mhttpd.css is served from $MIDASSYS/resources/mhttpd.css. The actual path is
reported on the mhttpd
> "help" page.
>
> (I think the internal mhttpd.css and mhttpd.js should be removed as no longer
useful - nothing will work
> right if the real mhttpd.js and mhttpd.css cannot be served).
>
> > Especially the look and feel of the runlog is unsatisfactorily from my point
of view.
>
> persons in charge of implementing the CSS stuff failed to convert quite a few
pages, for example, the elog
> and the history editor pages were left completely broken. (mostly fixed now).
>
> so thank you for reporting the runlog breakage, I hope Stefan & co can fix it
quickly. (I cannot do - I have
> have no runlog pages on any of my test experiments).
>
> > the old style was much more readable.
>
> I think the new style is not too bad, except for a few visual artefacts here
and there, the general comment
> that CSS is too complicated and hard to debug and the fact that over-subtle
colouring yields inconsistent
> visuals between different monitors and ambient lighting conditions. (persons
who select the colours always
> respond that "but to me, it looks just fine on my laptop", making it hard to
resolve any issues).
>
> > I could recover the old style look and feel by slightly changing the mhttpd.cxx
>
> If you post the patches that fix it for you, I can commit them to midas. (git
diff | mail olchansk@triumf.ca).
>
> K.O. |
Attachment 1: mhttpd.cxx.diff
|
diff --git a/src/mhttpd.cxx b/src/mhttpd.cxx
index 7437897..3940b96 100755
--- a/src/mhttpd.cxx
+++ b/src/mhttpd.cxx
@@ -3445,7 +3445,7 @@ void show_rawfile(const char *path)
rsprintf("</table>");
//main table:
- rsprintf("<table class=\"dialogTable\">");
+ rsprintf("<table class=\"runlogTable\">");
/*---- menu buttons ----*/
rsprintf("<tr><td colspan=2>\n");
rsprintf("<input type=submit name=cmd value=\"ELog\">\n");
|
Attachment 2: mhttpd.css.diff
|
diff --git a/resources/mhttpd.css b/resources/mhttpd.css
index 71c73a4..066cfe6 100644
--- a/resources/mhttpd.css
+++ b/resources/mhttpd.css
@@ -286,7 +286,7 @@ div.wrapper{
margin: 0 auto -3em;
}
-.historyConfigTable, .dialogTable, .messageBox, .genericTable, .sequencerTable{
+.historyConfigTable, .runlogTable, .dialogTable, .messageBox, .genericTable, .sequencerTable{
border-radius: 12px;
border: 2px solid #00B26B;
background-color: #EEEEEE;
@@ -304,6 +304,22 @@ table.sequencerTable td table{
margin: 0px;
}
+table.genericTable tr:nth-child(even){
+ background: #EEEEEE;
+}
+table.genericTable tr:nth-child(odd){
+ background: #FAFAFA;
+}
+
+table.runlogTable td{
+ border:none;
+ text-align: left;
+ font-family: monospace;
+}
+
+table.runlogTable pre{
+ line-height: 125%;
+}
table.dialogTable td{
border:none;
|
974
|
28 Feb 2014 |
Stefan Ritt | Suggestion | runlog is "ugly" | > If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd.
I agree that this should be removed, Unfortunately I'm away right now, so I will fix it next week. Also will put in
Andreas' diffs.
/Stefan |
977
|
07 Mar 2014 |
Stefan Ritt | Suggestion | runlog is "ugly" | I put mhttpd.css and mhttpd.js into the ODB, so every experiment can change it. I put also Andreas' modifications of the CSS file for the runlog table and
committed the changes.
/Stefan |
999
|
26 May 2014 |
Dan Melconian | Suggestion | "Edit-on-end" would be nice | We use the "Edit-on-start" and it's great. But sometimes, something breaks
during the run, or you didn't realize you forgot to plug in a cable, or
whatever. It'd be nice to have an "Edit-on-end" where you could prompt the user
to answer simple questions (like "Was this a good run? [y/n]" or "Was the data
polarized? [y/n]") and/or add a quick summary of what happened that run.
Thanks in advance,
Dan |
1000
|
26 May 2014 |
Stefan Ritt | Suggestion | "Edit-on-end" would be nice | We have similar demands, and we solve it in the following:
We use a run database. In the simplest case, this can be a text file which gets written at the end of the file. The
mlogger has a built in SQL interface, so one can keep that table even inside a SQL interface. The per-run-
information then contains the run number, start/stop time, number of events, some run parameters and a "junk"
flag. So if a run has a problem, one can set the junk flag by accessing the database (or text file) and setting this
flag. In many cases you see that a run had a problem not at the end of the run, but a bit later. You mayby realize
that the last two or three runs had the problem. With the run database approach, you can flag any run as "junk"
later, which we need often, An edit-on-end would not make this possible.
So technically putting and edit-on-end is not a problem, but your life might be much easier if you use a run
database as outlined above.
Best regards,
Stefan |
1004
|
27 May 2014 |
Scott Oser | Suggestion | Saving ODB values in a sequencer script | I have a possibly simple feature request for the MIDAS sequencer. It would be
helpful to be able to save an ODB key's value to a variable, for later use, and
would be the analogue of the ODBSET command. I had in mind an application where
a user wants to temporarily change some settings in the ODB, then restore the
ODB to its original values. Maybe something like on ODBRead command:
<ODBRead path="/Path/ODBkey">varname</ODBRead>
<ODBSet path="/Path/ODBkey">0</ODBRead>
<Wait for="events">3000</Wait>
<ODBSet path="/Path/ODBkey">$varname</ODBRead>
(In which the key's value is saved to variable varname, then later written back
to the ODB.)
I'm open to other suggestions for simple ways to do this through the sequencer.
Thanks! |
|