Suggestion for visualisation of geometry (from Rogers):

The MiceModules are a bunch of maps from string to <type> with some file format associated with them (that shouldn't really worry you). Basically it's how we manipulate and store configuration information (geometry, fields, etc). Available <type>s are string, Hep3Vector, double, int (I think that's it).

The conversion from configuration to geant4 geometry is done in

${MAUS_ROOT_DIR}/src/common/EngModel/MiceModToG4Solid.*

• If we could browse the MiceModule information associated with a particular geometry object that would be very nice. There is a function call like
  

  template <typename T>
  std::map<std::string, T> getListOfProperties()
  

  
  where T is one of the types listed above. That could be used to fill a menu.
• One might then want to add a new step, like a MiceModToShape and then ShapeToG4Solid, ShapeToVisualisation. I'm nervous that with all the string lookups in MiceModToG4Solid, it's easy to not keep MiceModToG4Solid in step with MiceModToVisTool.

If we are wanting to move away from 'handdrawn'-level geometries, then how hard is it to just render the geometry once from some supercomplicated format? These are graphics cards that run Quake (or whatever people play: call of duty 4?).

So: Hey, Matt. If we wanted to hand you a geometry in some format, what is the easiest for you to import? Can you import random objects in what types of formats? Geant4 does the following:

http://geant4.cern.ch/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/Visualization/visdrivers.html

and we could probably just spit out a static geometry whenever needed.

I think the important thing is to pick a format we can stick with. I can train the code to read the geometry in whatever format; but if we can avoid doing so multiple times, that's good. vrml seems reasonable, as it consists of a full 3d description in an xml-like format. But I'm not all that fussy. With vrml I might be able to use the freewrl library to help.

I want this program to work on computers with mediocre, or even bad, graphics cards. But we can perhaps fall back on wire-frame on slower ones.
Also, I want it to be as responsive as possible. These are things that I can work on later. I think I should just start from the vrml file or whatever and see how it performs.

Matt.

Is there a simple way of launching the geant4 geometry viewer in MAUS?
I have a successful build of maus so I could have a go at generating the vrml file myself.

It's #356

Basically I have to move some code over from old G4MICE.

I think you are suggesting writing a VRML viewer, then using G4 as a VRML writer, which seems a sensible approach.

Wow, that's really nice! I'll get back to you when I sit down and properly think about deliverables on this.

Quick and good work though.

Do either of you chaps have bzr instructions so I can check it in. Is is the same repository James used for the Tracker DAq software?
I'd like to make sure I put it in a sensible place and don't make a mess.

Cheers.

Try this:
http://micewww.pp.rl.ac.uk/projects/maus/wiki/Bzr_usage

Let me know if you find bugs...

Looking at the opengl documentation, I've found a mechanism to find out which shape is to be found at given 2d screen coordinates.
So it seems we shall be able to display information on a spacepoint or whatever when the user clicks on it in the 3d display.
Despite what I said when Chris suggested this feature before, I've tried this on the tracks and it seems reliable and consistent.
This is not a big leap forward, but since Chris asked for this feature before and I implied I wasn't going to include it, I thought I should mention the u-turn.

Matt, is this going anywhere? I am still waiting for this to be cleaned up and commented as per the style guide etc so I can move it to the trunk.

It's still incomplete. I have been waiting for months now for the vrml file from the simulation and a proper sample data file so that I can finish it off.
The commenting is a simple matter, but if you need it to be done first for some reason, I guess I can do that.

Matt.

I would like to push it to the trunk... I thought that you are independent of the VRML file (i.e. you can read in anything that comes out of G4). I would rather push it with the datastructure you have and then iterate. But that means cleaning up the code and thinking of a testing procedure (probably a test script for human to go through). Is that okay?

Will do.
We have discussed before the plan, such as it is, for testing.
I should allow a command line option to test parsing of json files followed by an exit.
A human testing procedure is probably premature at this point there is only 1 track in the sample data file I have so there's not much to check.
I also need to put in doxygen style comments.
Was there anything else?

Okay, once you've done that can you assign the tracker onto me so's I can check the code then merge with trunk?

ps: make sure it passes cpplint guide. Which you'll hate (it's a pain in the ass, but better than the alternative).

'Bootiful'

I've done a couple of screen-shots and fly-by's.
http://www.hep.shef.ac.uk/tmp/eventviewer

Wow nice. Just taking a peak. Can you upload them to this site so we know we keep them around for talks etc.?

I did try.
It was rejected.

Matt.

Thanks. Must be just me.

ps: did you see the schema at src/common_py/SpillSchema.py? Intended to contain definition of what the data structure looks like (and eventually should be used as source for documentation also). Not so useful - it's missing the Hit data. But eventually this is where it should go.

I've added the json reading test, which will run without a window server.

I tested it on the good (if simple) json file from Chris. Which passed, and on a deliberately broken version of that file, which failed as it should.

[robinson@mattbook ~/code/edam]$ ./edam --test ~/Desktop/maus.json
Test reading of json file /Users/robinson/Desktop/maus.json... Okay
[robinson@mattbook ~/code/edam]$ ./edam --test ~/Desktop/test.json
Test reading of json file /Users/robinson/Desktop/test.json... this does not look like a json file
Failed

I shall move on to "proper" commenting.
Is there a good example I can work from?

Try maybe

http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/common_cpp/Simulation/MAUSGeant4Manager.hh

(That's my fault, so if anything isn't clear there then let me know). Remember we have many developers who are not very experienced, perhaps they would like to dip into your code.

• Move version number out of the file name - that's bzr's/rogers's job
• Use scons not make. Please use the global SConstruct file in MAUS_ROOT_DIR, making changes if necessary so your code compiles
• Filenames should come from configuration file, not hard coded - try instantiating MICERun singleton and getting the jsonConfiguration - http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/legacy/Interface/MICERun.hh
• Source code moves to src/common_cpp/EventViewer
• Make a reduce driver in src/reduce/ReduceCppEventViewer. Three methods:
  birth() does constructor stuff
  death() does destructor stuff
  process(x,y) takes a spill and adds it to the event display.
• You won't like this but: Testing should be a bit more thorough - for example, it's easy to read in a hit and accidentally do a typo whoops I put "y" into the "x" variable. Leads to some poor shifter spending hours crying over their coffee in the control room because they think their lovely detector doesn't work. The way to catch this stuff is to make some cross-checks i.e. unit tests. I realise you can't test the GUI - see previous conversation - but you can certainly test the interfaces. There's probably quite a lot of stuff you can check like this. (These unit tests go in tests/cpp_unit/)

NB: your development branch is quite out of date. Try updating by doing command like "bzr merge lp:maus" which will pull across changes from the maus trunk to your development branch.

Having said that, it works now on SUSE 11.2/64 bit now thanks to your recent changes.

Move version number out of the file name - that's bzr's/rogers's job

The version number is not in the file name.

Use scons not make. Please use the global SConstruct file in MAUS_ROOT_DIR, making changes if necessary so your code compiles

Really. The make file works very well. Can't we get SConstruct to envoke make.

Filenames should come from configuration file, not hard coded - try instantiating MICERun singleton and getting the jsonConfiguration - http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/legacy/Interface/MICERun.hh

There aren't any hard-coded filenames

Source code moves to src/common_cpp/EventViewer

No problem.

Make a reduce driver in src/reduce/ReduceCppEventViewer. Three methods:
birth() does constructor stuff
death() does destructor stuff
process(x,y) takes a spill and adds it to the event display.

I'll look at it. Birth and death will probably be empty. Surely each new event calls for a new window. In which case the event viewer can be activated just by invoking "edam eventfile.json", or posible "edam eventfile.json event_number".

You won't like this but: Testing should be a bit more thorough - for example, it's easy to read in a hit and accidentally do a typo whoops I put "y" into the "x" variable. Leads to some poor shifter spending hours crying over their coffee in the control room because they think their lovely detector doesn't work. The way to catch this stuff is to make some cross-checks i.e. unit tests. I realise you can't test the GUI - see previous conversation - but you can certainly test the interfaces. There's probably quite a lot of stuff you can check like this. (These unit tests go in tests/cpp_unit/)

Don't entirely follow this, we should discuss it. I didn't anticipate hits being entered manually by users. I thought that they would come from the automatically generated json files. Not sure what "interfaces" means.

NB: your development branch is quite out of date. Try updating by doing command like "bzr merge lp:maus" which will pull across changes from the maus trunk to your development branch.

Righto.

Having said that, it works now on SUSE 11.2/64 bit now thanks to your recent changes.

Good to know. Thanks for testing.

I really want this to continue to work stand-alone. For example many computers to not have scons but do have make. Also unnecessary dependencies seem unwise to me.
I think we need to consider carefully what parts of normal maus standards should be applied to a graphical event viewer with these things in mind.

Robinson, Matthew wrote:

Move version number out of the file name - that's bzr's/rogers's job

The version number is not in the file name.

What is the significance of "4" in e.g. edam.4.cc and edam.4.hh? I thought it was version number.

Use scons not make. Please use the global SConstruct file in MAUS_ROOT_DIR, making changes if necessary so your code compiles

Really. The make file works very well. Can't we get SConstruct to envoke make.

No. We only maintain one make file. We decided to use scons, so that's what we use. I don't want everyone to have their own make file, it makes maintenance a pain. Every installation of MAUS gets scons.

Filenames should come from configuration file, not hard coded - try instantiating MICERun singleton and getting the jsonConfiguration - http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/legacy/Interface/MICERun.hh

There aren't any hard-coded filenames

Fair enough - you have this:

#else
  //in /usr/share or $HOME/share or /usr/local/share, next the exe on Linux
  QString filename=qApp->applicationDirPath()+QString("/../share/edam.wrl");
#endif
  //if the user has set the environment variable EDAM_WRL
  if (getenv("EDAM_VRML"))
    //assume that this variable points to the location of the vrml file
    filename=QString(getenv("EDAM_VRML"));

Source code moves to src/common_cpp/EventViewer

No problem.

Make a reduce driver in src/reduce/ReduceCppEventViewer. Three methods:
birth() does constructor stuff
death() does destructor stuff
process(x,y) takes a spill and adds it to the event display.

I'll look at it. Birth and death will probably be empty. Surely each new event calls for a new window. In which case the event viewer can be activated just by invoking "edam eventfile.json", or posible "edam eventfile.json event_number".

Fair enough.

You won't like this but: Testing should be a bit more thorough - for example, it's easy to read in a hit and accidentally do a typo whoops I put "y" into the "x" variable. Leads to some poor shifter spending hours crying over their coffee in the control room because they think their lovely detector doesn't work. The way to catch this stuff is to make some cross-checks i.e. unit tests. I realise you can't test the GUI - see previous conversation - but you can certainly test the interfaces. There's probably quite a lot of stuff you can check like this. (These unit tests go in tests/cpp_unit/)

Don't entirely follow this, we should discuss it. I didn't anticipate hits being entered manually by users. I thought that they would come from the automatically generated json files. Not sure what "interfaces" means.

Feel free to ring - 01235 44 6983

What I'm getting at is this: you leave MICE to find the Higgs. Some moron like me wants to change the file structure, goes in to hack around in your code and accidentally cuts and pastes an "x" into a "y" somewhere. We want to catch this sort of thing before it hits the control room. So we make a script to check that the code that loads the data does it right.

I really want this to continue to work stand-alone. For example many computers to not have scons but do have make. Also unnecessary dependencies seem unwise to me.
I think we need to consider carefully what parts of normal maus standards should be applied to a graphical event viewer with these things in mind.

It should be integrated with the rest of MAUS. Every time you add an extra special case (e.g. using makefiles to build, using environment variables to specify file locations), you double my workload. So I fight to make sure everything is consistent and uses the common infrastructure, and we don't have special cases. That's just my job I'm afraid.

(I say feel free to ring, but I'm going home in 5 minutes so will have to wait until tomorrow)

The "hard coded" filenames you point out are relative to the location of the executable so I didn't think of them as hard. Still you make a good point. I'n

The 4 indicates that it's designed to build against qt4. If qt3 is detected, a script runs to convert the source to qt3 compatible generating .3.hh and .3.cc. This only requires minor tweaks, but they are necessary. Since Linux is in transition between qt3 and qt4 (centos 5 uses qt3, ubuntu uses either, other distributions are based around 4) this is important. I'm not sure how to handle it with scons.

There's no reason why there can't be a makefile in there which maus ignores.
On the other hand, if you look at the makefile, it's quite sophisticated. Can scons handle it?

Are you sure that you want to break compatibility with windows and mac and non-maus linux machines for the sake of standards compliance? Would it not be as well to consult on the matter.

I'm reluctant to sacrifice real world usability for the sake of standards compliance, but you're the boss. Standards are good, but their purpose is to serve real usability.
I guess in principle I could fork the project and make a stand-alone version, not identical to the maus version.

I've been thinking about sconstruct. If we could add qt4 as one of the standard build_all libraries in maus, then we could guarantee it's presence on the host system. We could also add the necessary environment variable to select qt4 in the env.sh script generated by configure.
In which case building the event viewer using sconstruct would be pretty simple as it would be content with standard g++ commands.
Is this an option? qt4 takes a while to build, but if the makefile cannot be used....

What are the use cases for the visualization? Just thinking if we want it as a standalone application... helps MAUS avoid feature bloat.

I had assumed that the use case was as described in the opening to this issue
"make a nice gui to use in control room (or at home) to interrogate persistency stream using 3D interface"
I interpreted the "persistency stream" as the json files.

The code as it is now, with it's rather complicated makefile, will build and run on any kind of linux with either qt3 or qt4 development libraries. In order to simplify the build for sconstruct, we would probably need to control the version of qt. This would not be my first choice by I accept that I should fit in with the rules and regulations of maus as far as I can.
Perhaps somebody moe familiar with sconstruct could look at the makefile and judge whether a full port to sconstruct is practical.

I'm honestly not trying to cause trouble here, but the use case seems in conflict with the maus standards. And the "tests" the code is required to implement seem crafted for analysis and simulation modules rather than portable graphical programs.

I'm content to maintain it as an independent application if you decide that's best.

I also have binary installers for any version of windows >=xp and any version of mac os >=10.4 on either mac cpu type.

Maybe we can discuss on the phonecall first thing tomorrow so I can participate. Here's the issue (and why we have the rules): we have to maintain this until 2018 and probably none of us will be around then. Scons is actually much easier than make and allows for much more complicated things. I can't look at what you've done until I get back from Geneva (Aug. 8th).

We should find a way to try to incorporate it into MAUS if we can find a way to test it since having yet another thing for people to install with be a pain since the number of support emails scales as the number of things to install. We just need some tests to make sure that it built properly and to answer the question that we get asked by MICE "are you sure this will work in the control room?".

It's a fairly standard practice in industry if, for instance, this were a display that showed that a plane was level instead of crashing. We just should probably look at the code and figure out 'how do we test this?' and 'can we mold MAUS around it to make things simpler?'

You almost certainly want MAUS to handle the logic of passing you the JSON spills because it may be simple now but soon MAUS will be doing a lot of DB transactions to get JSON from some time range.

Actually... maybe this just should be standalone (but still tested!) since you may want to do things like specify time ranges you want to flip through spills during. Humm... let's talk about it on the phonecall tomorrow?

I'd like to participate in such a call. Is this something that's already been arranged? Or are we just agreeing to talk?

Standards are important in a large and long project, as you say. I don't dispute this.

It should indeed be tested, but I'm not sure that it is possible or helpful to try to test it using the tests for maus simulation and analysis modules.

I'm losing track in the terminology here. Is there a case for the event viewer to receive event data in some form other than a json file passed on the command line?

As to whether including the event viewer in maus does more good or harm, I'm not sure. I was expecting to have to do some work to fit it into the maus framework, but I wasn't expecting it to be necessary to break the ability of the event viewer to run in the absence of maus.

I always intended to make the event viewer available in binary form for any and all platforms in common use in the collaboration. This I assumed to include centos/redhat/sl/slc 5 (i386 and x86_64), windows, the last several versions of mac os and various other linux distributions in common use e.g. ubuntu and opensuse. This work is mostly done, but depends on the sophisticated makefile and its supporting scripts. Our users shouldn't have to be sys admins or experienced programmers, certainly not just to use the event viewer.

I sent you the email on the call.

The event viewer in the control room will not be run from the command line per particle. It will take a live stream in the control room off a socket.

Here's the spec:

receive (or query if standalone) a JSON file every second that is one spill. Display that event. Keep updating as long as a box is ticked that says update automatically. If that isn't clicked, be able to go back in the history of spills within a run (about an hour worth of data) and view them for a while. Then recheck the update now box when you want to see the live stream again.

Let's say we do it standalone. couch DB (our intended DB) can fetch JSON files by HTTP requests. You'd have to use:

http://stackoverflow.com/questions/3583457/c-library-or-wrapper-for-couchdb
http://code.google.com/p/couchdbpp/

to do queries. So the use case is either query a COUCHDB database for the JSON OR be passed a file to display.

We weren't talking about testing it tying into analysis modules. But I want to run a million muons through it in auto update mode that come from the simulation and feed into a couch DB database (like the data) and verify it doesn't crash. That's a high level test. It would also be nice to know that when that fails where it fails. If you can make tests (functional tests) that make sure components work, that would be useful. Lastly unit tests to make sure when a function changes it doesn't break. Regardless of if it is standalone or part of MAUS, we'll need something like this because otherwise when it breaks (which it will in a few years time) people will just chuck it into the bin if they can't quickly find where the bug is.

receive (or query if standalone) a JSON file every second that is one spill. Display that event. Keep updating as long as a box is ticked that says update automatically. If that isn't clicked, be able to go back in the history of spills within a run (about an hour worth of data) and view them for a while. Then recheck the update now box when you want to see the live stream again.

This is not a problem. Fetching the json from an http server is not significant different from reading it from a file.

But I want to run a million muons through it in auto update mode that come from the simulation and feed into a couch DB database (like the data) and verify it doesn't crash.

This shouldn't be a problem, but it's a bit early to say since I have have to work with is one very simple json file. But this test will surely involve running the gui and therefore an X server. Is there a more complex json file/stream available for me to test with?

This all seems quite different from what Chris and I have been discussing today. Perhaps that's me misunderstanding things. If this is the testing regime, it seems quite proper and practical.

If that's all there is to it, and what I need to do for maus inclusion is add qt4 to build all and make sconstruct build the thing, it's all starting to sound pretty straightforward.

Chris runs the project, Linda will be using it, and I'll be doing what feeds into it. We all should talk on the phone to make sure we're on the same page. I may be saying something different and vice versa. We need to chat together to make sure everybody's ideas get heard and we do this right.

We just have other standalone stuff (unpacker, config DB, online monitoring). Though from what I've scanned above I really do agree with him on high standards since pain now is less pain later.

... pain now is less pain later.

Not always. We're rapidly approaching the point where the standards compliance takes longer than writing the thing. So having someone re-write it from scratch every few years would actually be more efficient.

Asking for a test to make sure it works in the control room is not unreasonable. Good tests may take longer than writing the thing.

If it breaks in the control room, it's a major problem: we waste our infrequent ISIS time, we delay our schedule, we waste three shifters time, and we do bad physics. We need things in the control room to work -- think of airplane analogy -- and the hard part is proving it works.

Little history? Our last event display crashed a ton, nobody could run it outside of the control room, I don't think it works now, and seriously hurt our physics program.

Testing is essential and should be thorough. I've never questioned this for a moment. That's not the same thing as rigid standards.

Style/Standards:
This is a pain the first time. But you get used to it pretty quickly. I guess it'll take a day to go through all your code and fix style violations, but I expect it took quite a bit longer to write the code in the first place. And it gets easier as you learn the sort of things style guide wants. But we can test the assertion - try fixing one class and see how long it takes.

Specification:
Just to be clear, Tunnell's specification is for a standalone application. If you put it in as a reduce interfaced properly with maus, then we handle the code that talks to couch db (or whatever). In the case of a reduce object you just get a std::string containing the spill json document. We don't particularly want to pass things as text files because we end up with a lot of file i/o that is inefficient.

Linda needs to decide exactly how it should manage multiple spills and stuff (i.e. do we accumulate multiple spills in the same picture, do we sample every 1/10 spills, what's the UI for that, etc). But so long as it can read a spill document, the interface is clear (caveat we might want to input from a std::string rather than a file, but that's a small change - esp if we use std::stringstream).

• we replace ~5000 lines of makefiles with 500 lines of python
• it's python, which means devs don't have to learn a new language
• improved functionality (automatic checking for existence of 3rd party libs)
  I understand your pain:
• it's non-standard so it requires learning by experienced devs
• it's another 3rd party app, which we need to install

The first point is a pain, we just have to clench buttocks and learn the new tech. Most of our developers have little/no prior development experience anyway, so choosing an easier tool is sensible.

The second point - well we have got a fairly good build script that seems to work okay on all the platforms for which we need it - that is CENT OS and SL. We can also run on all major linux platforms I think, sometimes with a bit of hacking. It's a shame we can't work in OS/X. I don't know of anyone attempting to build under windows (presumably cygwin), we would need to make changes in many places to do that (we don't enforce os.path.join, so many path names are wrong). scons is not the problem here.

• I was going to poke the detector devs to define the spill schema for their bit, so you know what the interface looks like.
• It really is nice to see an event display working!

Hi Chris,

It really does work in OSX. It just doesn't pass all the tests. It's not clear to me why. Probably a compiler issue. I had planned to get back to it. Mainly I need to learn what the specific tests are testing for.

I'm not averse to learning new things. I've already hacked at the sconstruct for the mac modifications and it seems reasonably straightforward. As I said, there should be no problem building with sconstruct if we control the qt version by including it in the third_party tools.

My concern is that you seem to want the event viewer built as a plug-in to the maus framework for the sake of standards compliance. Despite the fact that this will mean that anyone wanting to use the event viewer will have to do the full maus install; and will not only have a long complex install procedure for a tool which doesn't need one, but will also be confined to the maus supported operating systems.
That seems to me like it contradicts the original use case and what my instincts are for how people will want to use the event viewer.

Let's say user X wants to look at events from home:

In the model I have envisaged, they would download an appropriate binary for the event viewer, and be up and running in about 1 minute. The event viewer would be able to take advantage the 3d capabilities of the GPU and would remain highly responsive even on old hardware.

In the full-on-maus model I suspect that you're advocating, they would download VirtualBox, install an approved version of Linux, spend a couple of hours building maus and its dependencies, then run the event viewer from maus without access to the GPU and most likely find it painfully slow.

I understand you're reluctant to bend the maus rules, but surely a 3d event viewer

We need to discuss this in the meeting, but:

1. everybody who would run the event viewer would also have a MAUS install.
2. we really want your code. But we spent a lot of time thinking of these rules and debating them each commit, so this is what we're doing with the project and we'd rather keep the philosophy of the project and potentially lose out on some people's features than compromise. We've fought this fight with each developer. And there code always ended up better at the end because code is read more than written.

my few cents

1. everybody who would run the event viewer would also have a MAUS install.

Surely not? I've been using it without maus. Paul H has been. Chris Booth has expressed an interest. As has Ed. None of them have touched maus.

2. we really want your code. But we spent a lot of time thinking of these rules and debating them each commit, so this is what we're doing with the project and we'd rather keep the philosophy of the project and potentially lose out on some people's features than compromise. We've fought this fight with each developer. And there code always ended up better at the end because code is read more than written.

Sorry to cause trouble, but I stand by the points I have made. It seems folly to me to go out of our way to prevent the event viewer from functioning outside maus.
My solution of using maus resources when they are there and not even compiling the non maus sections in that case. But including code, which is not even compiled when we build against maus, to allow the viewer to function outside mice seems to me to satisfy both requirements.
If the standards of maus are so strict that they forbid this, I think that's far too strict and I'm going to really struggle to function as a maus developer.

I will put in as much time and effort as it takes to comply with maus standards, but must I really make the event viewer worse or less useful in the name of philosophy.

relax...

Following todays meeting it seems to me that we have resolved this matter. The plan is as follows
1. The event viewer will be built with scons, and qt4 will be added to the set of third party libraries built in support of mice, so that we can control the version of qt and thereby simplify the build
2. The event viewer will follow maus coding and commenting standards and be tested through Jenkins.
3. The event viewer will not use the birth() -> process() -> death api but will instead be user driven
4. When built against maus, the event viewer will use the libraries provided therein for reading the persistency stream, but is not forbidden from reading using built in methods when built stand-alone

I shall start by applying the coding and commenting standards, then add qt4 to the build system and modify SConstruct to build maus, before submitting my development branch for merging.

Does that sound okay to everyone?

I'm struggling with scons and I'd appreciate some guidance.
As far as I can see, the one SConstruct file is responsible for building everything.

qt builds usually break up into 2 stages:
Stage 1 is to run the program moc, over the headers which define graphical objects. These are *.4.hh in my source. This produces extra source (.cc) files.
Stage 2 is to compile all source files with fairly standard g++ commands, then link as normal. Can sconstruct manage this? If so, where would I add these commands?

Resorting to google... this one looks useful:

http://www.scons.org/wiki/Qt4Tool

some sort of manual and on the scons.org website, which is encouraging... but I haven't dipped too deep. Have you tried it?

ps: update #53 seems a good summary of the discussion on Friday.

Thanks.
What I do with make is run "moc" with the right arguments to get it to spit out all the -I's and -L's etc etc.
Then run moc over the headers, then compile. All it really takes is getting the g++ commands right, as moc doesn't really need any arguments.
What is the equivalent thing to do in SConstruct. Am I allowed custom compiler flags? Am I allowed to envoke "moc"?
I'm pretty lost here.

From:

http://www.scons.org/wiki/Qt4Tool?action=AttachFile&do=view&target=manual.html#suggested_boilerplate

4. MOC it up

For the basic support of automocing, nothing needs to be done by the user. The tool usually detects the Q_OBJECT macro and calls the “moc” executable accordingly.

If you don't want this, you can switch off the automocing by a

env['QT4_AUTOSCAN'] = 0

in your SConscript file. Then, you have to moc your files explicitly, using the Moc4 builder.

You can also switch to an extended automoc strategy with

env['QT4_AUTOSCAN_STRATEGY'] = 1

Please read the description of the QT4_AUTOSCAN_STRATEGY variable in the Reference manual for details.

For debugging purposes, you can set the variable QT4_DEBUG with

env['QT4_DEBUG'] = 1

which outputs a lot of messages during automocing.

I could invent something, but it looks like someone who knows about QT4 has done it already... or is there something broken here that a QT noob like me doesn't realise?

ps: off home in a minute, so will pick it up tomorrow...

Okay. So sconstruct decides on the build commands once it has the qt4 support loaded. That will probably work.
One more thing. Can I get scons to build just the event viewer using some command line flags, or does it always build everything?

The stuff where it does the build is in SConstruct lines 498-577:

if env['USE_G4'] and env['USE_ROOT']:
...
env.Alias('install', ['%s/build' % maus_root_dir])

where 577 is the eof

There is an open issue #188 to clean up SConstruct file - at the moment it's pretty impenetrable. The nice thing is, it's just python code so we can break it up into subfunctions etc - make it into proper code. We haven't done that, and the file is a mess... but so much to do so little time.

scons is now building the event viewer.
But scons is adding the various compile and link flags to everything it builds. This is not right and will probably break something else. Is there a way to prevent this?

It seems to me that there is glob in sconstruct which pulls in all code in common_cpp and compiles it in the same manner. So if I'm to apply different rules to the event viewer it would probably have to live outside common_cpp. Is this acceptable to everyone? Where should it go in this case?

In the absence of instructions to the contrary, I have moved the event viewer to the root of the src directory and added fully independent build instructions for it to SConstruct.
I have committed my development branch to bzr again if anyone wants to look at it.
I still have to tidy up the code, mostly the doxygen commenting, but at least the build is working.

been at a summer school and conference for the past month. I'll peek next week. Sounds great!

That sounds fine.

It appears that the jenkins system is missing the opengl libraries or headers. Is this something that could be added?

I asked Simon to do it - I guess we will also need to add this to the installation instructions for MAUS...

ps: Matt, can you add exactly which packages you need to #626

The event viewer should, in my view, be installed somewhere in $PATH by sconstruct.
I know how to do that now. I would appreciate guidance on where it should go. Also, the wrl file containing the detector geometry should go in some standard location, though this could be anywhere within the maus directory tree.

Make a directory $MAUS_ROOT_DIR/bin/utilities/ I would say.

Does it really have to be in $PATH? we don't do that for any of the other executables...

It seems to me that users will want to type a command and have the event viewer appear.
Is there a better way to achieve that?

We can add stuff to PATH; see ./configure. Just do it some way and I'll try to look at it soon (trying to catch up on email). Use your best judgement.

Adding to PATH in ./configure is fine also.

Sorry for interjecting without reading the thread :) We have gotten too good at writing things down.

I'll try runniing this tomorrow (spent all day fixing bugs)

There's a bug: in the configure script you forgot the EOF so I actually can't get it to run. Can you fix that then let us know when it's fixed so I can retry?

http://bazaar.launchpad.net/~m-robinson/maus/devel/view/head:/configure

Thanks. I've put in the eof.

I get this from scons:

scons: *** (<class 'qt4.QtdirNotFound'>, 'Could not detect Qt 4 installation') Stop.

but when I run:

itchy:maus-trunk$ moc -v
Qt Meta Object Compiler version 62 (Qt 4.6.4)

So I think it's searching for moc in the wrong path....

The qt-devel package puts a set-up script in /etc/profile.d called qt.sh
This, among other things, add the qt bin directory to $PATH. If moc is not in $PATH, either qt-devel is not installed or jenkins is not setting up the shell properly.

Okay.
Of course it already works.
The question is over maus standards.
I've been looking at the style guide. It's very, very long and detailed.
Could you tell advise me what's most important. What styling aspected to I need to change in my code?

Right. It's making sure that the code works and continues to work in the future - setting up tests and all the boring stuff.

For cpplint, just make sure it passes cpplint.py

Something like

python -m cpplint some_file.cc

Takes a bit of getting used to.

ps: There is some more stuff in the style guide - I don't think we can effectively enforce it given manpower constraints. Doesn't mean it's not worth doing.

pps: if you can't/don't want to get something to work for good technical reason, there is a file tests/style/cpplint_exceptions.py which contains a list of exceptions. Put exceptions in here, otherwise it will break the tests.

Actually not true: the main thing at least I'm waiting for is to make sure it works out of the box.

http://test.mice.rl.ac.uk/job/MAUS_robinson/2/console

Any guesses as to what's happening?

That was meant for Matt saying that it's currently conforming to MAUS standards. The EOF things, the failed build above, etc., there are some small things to fix it seems.

On the failed build, As I said yesterday:

The qt-devel package puts a set-up script in /etc/profile.d called qt.sh
This, among other things, adds the qt bin directory to $PATH. If moc is not in $PATH, either qt-devel is not installed or the shell is not set up properly, so it ignores some or all of /etc/profile.d.

That's been done though? See #626. And the build script in third_party/bash/ with reference to qt... doesn't that do it for you? Just trying to figure out what's going on.

Because of the fact that it takes a long time to build qt, and dt devel packages are available for all Linux, I made the extra effort to allow scons to build against either qt3 or qt4, so it could use the native qt on the system.
The third party qt build script is still there, but it's not in build_all. It shouldn't be necessary to use the third_party script except on a system which for some reason doesn't have qt-devel.

I'm just saying we installed qt-devel on those machines (see linked issue). I'm trying to restart jenkins to see if it just didn't see it. Could the issue be something else?

I don't know jenkins well enough to say.
Could somebody log into the machine(s) as a regular user and check the qt install. e.g. by typing 'which moc', which should return something like /usr/lib/qt-3.3/bin/moc

/usr/lib64/qt-3.3/bin/moc

hummm.... maybe there's a default path within scons that doesn't see that?

Is there anything in the SConstruct script which clears or resets $PATH.
We can't really depend qt to be in the same directory on different machines.

agreed.

Can by default it also check if it exists in path, if not then show the command you can run to install it locally, but continue as if nothing happened? And (for the moment) print the env['PATH'] to see what it says when teh test runs?

I think rebooting Jenkins may have worked... but it would be nice not to crash if moc isn't around

env['PATH'] is empty by default.
env['ENV']['PATH'] contains a basic version of PATH ignoring most of the profile.

env['ENV']['PATH']=os.environ.get('PATH') seems to fix it though it's odd to me that this is necessary. make doesn't strip out PATH in this way. It's a rather silly thing to do.

It helps you avoid grabbing random junk you may have in your own personal path. Its a good idea for simple things (g++ etc) but makes things tough here. Environmental variables are a messy way to do things but we do it out of necessity.

The prototype was distributed months ago.
Development is mostly limited by the availability of sample data to train it on.
It would be helpful to have people try it and then suggest changes.

Sure. That's plenty of time.

I think the thing which will ultimately consume most of our attention is how the UI behaves and how the various different data in the file are represented.

I think it would be very convincing if we were able to use something like http://itupw056.itu.chalmers.se/project-xnee/ for testing. Let's get Edward to send you some new datasets.

Matt won't be able to do the socket thing; that requires knowledge of DATE.

I'm emailing Edward to ask for an example output file.

I've spent several hours on what seems to me unnecessary moving of curly brackets and inserting and removing non-functional white space from the code. Much of which makes the code harder to read in my view.
I'm down to my last few cpplint messages.
Perhaps you can tell me what to do about a copyright message.
Also, how can I include the directory for .hh files if they're in the same directory as the source files. I suppose I could put "./header.hh", but that seems silly.
I can't avoid the use of dynamic cast, nor can I get rid of the "parameters should be named" errors without breaking the Qt.
I honestly don't see why I should use int16 instead of short since they're absolutely identical, but I can change it if it makes things easier.
The "include order" thing is bogus as far as I can tell.

Unfortunately bzr is refusing to "Push" right now with the following error message. This follows a successful "commit". There's nothing wrong with the disk or the file-system. I am using an nfs share, which may be relevant.

[robinson@hep8 evtvwr]$ bzr push
bzr: ERROR: [Error 5] Input/output error

File src/common_cpp/Simulation/MAUSEventAction.hh
File src/EventViewer/world.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1: Include the directory when naming .hh files [build/include] [4]
File src/EventViewer/gui.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:1: Include the directory when naming .hh files [build/include] [4]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:178: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:206: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:288: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:289: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:306: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:307: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:318: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:320: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:1499: All parameters should be named in a function [readability/function] [3]
File tests/cpp_unit/Simulation/VirtualPlaneTest.cc
File src/EventViewer/edam.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:1: Include the directory when naming .hh files [build/include] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:49: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:72: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:84: All parameters should be named in a function [readability/function] [3]
File src/common_cpp/Simulation/MAUSTrackingAction.hh
File src/common_cpp/Simulation/MAUSSteppingAction.hh
File src/EventViewer/world.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/world.4.hh:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.hh:276: All parameters should be named in a function [readability/function] [3]
File src/common_cpp/Simulation/MAUSPrimaryGeneratorAction.cc
File src/EventViewer/gui.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:31: Include the directory when naming .hh files [build/include] [4]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:234: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:340: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:342: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:361: Weird number of spaces at line-start. Are you using a 2-space indent? [whitespace/indent] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:444: All parameters should be named in a function [readability/function] [3]
File src/EventViewer/edam.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:0: No copyright message found. See documentation for copyright message [legal/copyright] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:1: Include the directory when naming .hh files [build/include] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:3: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:4: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:5: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:7: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:9: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:13: Found C system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:31: Found C++ system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:32: Found C++ system header after other header. Should be: edam.4.hh, c system, c++ system, other. [build/include_order] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:79: Use int16/int64/etc, rather than the C type long [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:82: Use int16/int64/etc, rather than the C type long [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:107: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:140: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:141: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:149: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:150: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:159: Weird number of spaces at line-start. Are you using a 2-space indent? [whitespace/indent] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:171: All parameters should be named in a function [readability/function] [3]
File src/common_cpp/Simulation/MAUSPrimaryGeneratorAction.hh
File src/common_cpp/Simulation/VirtualPlanes.cc

From a fella used to straggle with the same problems:

- To get rid of the copyright message, you need to write

/* This file is part of MAUS: http://micewww.pp.rl.ac.uk/projects/maus * * MAUS is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * MAUS is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with MAUS. If not, see <http://www.gnu.org/licenses/&gt;. *
*/

at the top of each file you include.

- About the directory for the .hh files... you just have to include the full path, starting from "src/../../"

- you have to type bzr push lp:YOUR_BRANCH

regards,
Edward

The copyright text i pasted is all screwed up... but you can find the proper thing in every other file in MAUS.

Santos, Edward wrote:

From a fella used to struggle with the same problems:

- To get rid of the copyright message, you need to write

/* This file is part of MAUS: http://micewww.pp.rl.ac.uk/projects/maus *

• MAUS is free software: you can redistribute it and/or modify
• it under the terms of the GNU General Public License as published by
• the Free Software Foundation, either version 3 of the License, or
• (at your option) any later version. *
• MAUS is distributed in the hope that it will be useful,
• but WITHOUT ANY WARRANTY; without even the implied warranty of
• MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
• GNU General Public License for more details. *
• You should have received a copy of the GNU General Public License
• along with MAUS. If not, see <http://www.gnu.org/licenses/&gt;.
  /

at the top of each file you include.

- About the directory for the .hh files... you just have to include the full path, starting from "src/../../"

- you have to type bzr push lp:YOUR_BRANCH

regards,
Edward

From a fella used to straggle with the same problems:

Thanks very much

- To get rid of the copyright message, you need to write

/* This file is part of MAUS: http://micewww.pp.rl.ac.uk/projects/maus * * MAUS is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * MAUS is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with MAUS. If not, see <http://www.gnu.org/licenses/&gt;. *

*/

No problem. done

at the top of each file you include.

- About the directory for the .hh files... you just have to include the full path, starting from "src/../../"

That's going to break things

- you have to type bzr push lp:YOUR_BRANCH

That's what I did. I found a work around in the end by committing from a different, non-nfs file-system.

I think I've done all I can to make cpplint happy without breaking the code.
I need dynamic_cast. The weird number of spaces is standard in qt headers. Parameters should not be named in qt slots.
int16 is not a standard c++ type. There is an int16_t in the C99 standard (found in stdint.h) which I suppose you can expect to find on most modern systems. Am I supposed to use that?

File src/EventViewer/world.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1144: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1147: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1161: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1162: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1234: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1241: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/world.4.cc:1245: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
File src/EventViewer/gui.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:195: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:223: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:305: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:306: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:323: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:324: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:335: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:337: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.cc:1516: All parameters should be named in a function [readability/function] [3]
File tests/cpp_unit/Simulation/VirtualPlaneTest.cc
File src/EventViewer/edam.4.cc
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:66: Use int16/int64/etc, rather than the C type short [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:89: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.cc:101: All parameters should be named in a function [readability/function] [3]
File src/common_cpp/Simulation/MAUSTrackingAction.hh
File src/common_cpp/Simulation/MAUSSteppingAction.hh
File src/EventViewer/world.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/world.4.hh:317: All parameters should be named in a function [readability/function] [3]
File src/common_cpp/Simulation/MAUSPrimaryGeneratorAction.cc
File src/EventViewer/gui.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:250: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:356: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:358: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:380: Weird number of spaces at line-start. Are you using a 2-space indent? [whitespace/indent] [3]
/home/robinson/maus/evtvwr/src/EventViewer/gui.4.hh:463: All parameters should be named in a function [readability/function] [3]
File src/EventViewer/edam.4.hh
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:96: Use int16/int64/etc, rather than the C type long [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:99: Use int16/int64/etc, rather than the C type long [runtime/int] [4]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:124: All parameters should be named in a function [readability/function] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:157: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:158: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:166: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:167: Do not use dynamic_cast<>. If you need to cast within a class hierarchy, use static_cast<> to upcast. Google doesn't support RTTI. [runtime/rtti] [5]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:176: Weird number of spaces at line-start. Are you using a 2-space indent? [whitespace/indent] [3]
/home/robinson/maus/evtvwr/src/EventViewer/edam.4.hh:188: All parameters should be named in a function [readability/function] [3]

I've confirmed that fixing these cpplint messages will break the code.
There's no way around this.
cpplint will either need to be disabled, customised, or ignored when it comes to the event viewer

You can set up to ignore certain lines in the code

https://micewww.pp.rl.ac.uk/projects/maus/repository/entry/tests/style/cpplint_exceptions.py

Doesn't work

exceptions[os.path.join('src', 'EventViewer', 'gui.4.cc')] = [
(' connect(&mnu_windows, SIGNAL (activated(int)), this, SLOT (cb_window(int)));', 'cpplint does not understand qt signal connections', 'robinson'),
]

No effect. cpplint error persists.

Now ready for code review/merge with trunk?

Should add: looks good! but we need to chat to Linda now about these sorts of UI issues, so I would like to get it in the trunk and then sit down with Linda to get some ideas about where to go next.

Sorry. Been on holiday.
As far as merging. It should do no harm. I have a separate development version, outside maus, which I'm teaching about space-points and such from the new sample file.
I was going to ask about the proper way to do development after merging, so that I don't break the trunk.

What's the status here? I just tried to checkout and run lp:~m-robinson/maus/evtvwr and after building third_party scons failed to run. Ready by end of week?

It was passing all tests a few days ago.
Chris tunnel tells me it needs merging with the trunk to pick up changes to, I think it was python, which have since been made to the trunk.
I was planning on finishing some extra features before dealing with that, but if you prefer it can be merged at any time.

Last successful build was August 31st

http://test.mice.rl.ac.uk/job/MAUS_robinson_2/15/

Should I have a go at merging that one? I would like to get something in... even if it is just a "draft" viewer to show intention...

If you think that's best, by all means. I don't believe I've committed anything since.

I had a go at doing the merge off the latest version - couldn't get it to build. First problem was we had to update the SConstruct tool so I did a merge into the trunk to try to get the new SConstruct (and generally update stuff). Then needed to pull the qt4tool down and install it, by adding it to

third_party/install/lib/python2.7/site-packages/scons-2.1.0.alpha.20110323-py2.7.egg/scons-2.1.0.alpha.20110323/SCons/Tool/

Then tried doing the build, and at:

    EventViewer = qtenv.Program(target = 'src/EventViewer/edam', \
                         source = edam_cpp_files)
    env.Install("bin", EventViewer)

I get output like:

/usr/lib/qt3/bin/moc -DQT_GUI_LIB -DQT_CORE_LIB -DQT_QT3SUPPORT_LIB -DQT3_SUPPORT -DQT_OPENGL_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_NETWORK_LIB -DQT_SHARED -DQT3_SUPPORT -I/usr/include/QtGui -I/usr/include/QtCore -I/usr/include/Qt3Support -I/usr/include/QtNetwork -I/usr/include/QtSql -I/usr/include/QtOpenGL -I/usr/include/QtXml -o src/EventViewer/moc_edam.4.cc src/EventViewer/edam.4.hh
Qt meta object compiler
moc: Invalid argument
Usage:  moc [options] <header-file>
        -o file    Write output to file rather than stdout
        -f[file]   Force #include, optional file name
        -p path    Path prefix for included file
        -i         Do not generate an #include statement
        -k         Do not stop on errors
        -nw        Do not display warnings
        -v         Display version of moc
scons: *** [src/EventViewer/moc_edam.4.cc] Error 1
scons: building terminated because of errors.

Looks like somehow it is trying to run moc rather than gcc... started hacking around with the SConstruct file trying to do it manually (ignore qt4tool), but just not sure what the build process is for qt4. Need to run moc against all *.cc files in EventViewer then what? Or something else?

It's supposed to run moc.
It seems confused as to whether it's using qt3 or qt4. I suspect you system has both.
Could you tell me what OS you're using by the way.
The version of "moc" is clearly qt3, but the command line arguments are qt4.
Do you have my build or are you hacking at the trunk?

Started with merge of your build and trunk (because needed updated scons script to build)...

Should add some more output:

scons: qt4: Scanning 'src/EventViewer/gui.4.hh' (header of 'src/EventViewer/gui.4.cc')
scons: qt4: found Q_OBJECT macro in 'src/EventViewer/gui.4.hh', moc'ing to '['src/EventViewer/moc_gui.4.cc']'
scons: qt4: Scanning 'src/EventViewer/edam.4.hh' (header of 'src/EventViewer/edam.4.cc')
scons: qt4: found Q_OBJECT macro in 'src/EventViewer/edam.4.hh', moc'ing to '['src/EventViewer/moc_edam.4.cc']'
scons: qt4: Scanning 'src/EventViewer/world.4.hh' (header of 'src/EventViewer/world.4.cc')
scons: qt4: found Q_OBJECT macro in 'src/EventViewer/world.4.hh', moc'ing to '['src/EventViewer/moc_world.4.cc']'
scons: done reading SConscript files.
scons: Building targets ...
/usr/lib/qt3/bin/moc -DQT_GUI_LIB -DQT_CORE_LIB -DQT_QT3SUPPORT_LIB -DQT3_SUPPORT -DQT_OPENGL_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_NETWORK_LIB -DQT_SHARED -DQT3_SUPPORT -I/usr/include/QtGui -I/usr/include/QtCore -I/usr/include/Qt3Support -I/usr/include/QtNetwork -I/usr/include/QtSql -I/usr/include/QtOpenGL -I/usr/include/QtXml -o src/EventViewer/moc_edam.4.cc src/EventViewer/edam.4.hh
Qt meta object compiler
moc: Invalid argument
Usage:  moc [options] <header-file>
        -o file    Write output to file rather than stdout
        -f[file]   Force #include, optional file name
        -p path    Path prefix for included file
        -i         Do not generate an #include statement
        -k         Do not stop on errors
        -nw        Do not display warnings
        -v         Display version of moc
scons: *** [src/EventViewer/moc_edam.4.cc] Error 1
scons: building terminated because of errors.

i.e. I believe it is doing the moc'ing okay, but then for some reason calls moc executable instead of gcc executable. V3 vs V4 is a side issue.

This is openSUSE 11.4 (x86_64). I might have installed qt over the top of system defaults.

It seems like the sconstruct qt4 module is not working. If it is confuse by your qt install, that might explain it.
Could you check the result of 'which moc' and compare it with 'echo $QTDIR'.
This is what I get for SL5:

[robinson@hep8 ~]$ which moc
/usr/lib64/qt-3.3/bin/moc
[robinson@hep8 ~]$ echo $QTDIR
/usr/lib64/qt-3.3

It seems like the sconstruct qt4 module is not working. If it is confuse by your qt install, that might explain it.
Could you check the result of 'which moc' and compare it with 'echo $QTDIR'.
This is what I get for SL5:

[robinson@hep8 ~]$ which moc
/usr/lib64/qt-3.3/bin/moc
[robinson@hep8 ~]$ echo $QTDIR
/usr/lib64/qt-3.3

If qt4 is a problem, we could use your system's qt3 install perhaps, which is just a matter of setting environment variables.

Okay, I got it to build by forcing it to use only the qt version built with MAUS - forcing moc to be

cr67>  which moc
/home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/bin/moc

and putting environment variables like

cr67> printenv | grep QT
QTDIR=/home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/
QT_IM_MODULE=xim
QT_SYSTEM_DIR=/home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/share/
QT_PLUGIN_PATH=/home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/plugins/
QT_IM_SWITCHER=imsw-multi

However, now I'm back to the old chestnut of segmentation fault when I run the code...

The segmentation fault can't be the same one. It was something very specific which was fixed.
Besides, you've previous built the event viewer from source on this machine I think.

I'm not sure it's a good idea to perform the merge on a machine which we know has qt at least a little messed up.

You don't mention references to qt in LD_LIBRARY_PATH, or ldconfig; I wonder if it's picking up all the right libraries.
What do you get for 'ldd edam' ?

cr67> ldd bin/edam 
        linux-vdso.so.1 =>  (0x00007fff4a861000)
        libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007fcf162bd000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007fcf1604d000)
        libQt3Support.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQt3Support.so.4 (0x00007fcf15b4d000)
        libQtOpenGL.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtOpenGL.so.4 (0x00007fcf1587e000)
        libQtGui.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtGui.so.4 (0x00007fcf14bfc000)
        libQtSql.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtSql.so.4 (0x00007fcf149ba000)
        libQtXml.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtXml.so.4 (0x00007fcf14774000)
        libQtNetwork.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtNetwork.so.4 (0x00007fcf1444c000)
        libQtCore.so.4 => /home/cr67/G4MICE/MAUS/maus_trunk_evtvwr/third_party/install/lib/libQtCore.so.4 (0x00007fcf13fc6000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fcf13cbd000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fcf13a66000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcf13850000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fcf134e3000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcf132c6000)
        libnvidia-tls.so.270.41.06 => /usr/lib64/tls/libnvidia-tls.so.270.41.06 (0x00007fcf130c4000)
        libnvidia-glcore.so.270.41.06 => /usr/lib64/libnvidia-glcore.so.270.41.06 (0x00007fcf11477000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x00007fcf1113a000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fcf10f27000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fcf10d23000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fcf10a99000)
        libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fcf10889000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fcf1067e000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fcf10447000)
        libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007fcf10242000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fcf10039000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fcf0fd47000)
        libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007fcf0fb1d000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fcf0f905000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fcf0f6fc000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fcf0f4df000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcf165c9000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fcf0f2c2000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fcf0f098000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00007fcf0ee62000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fcf0ec5d000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fcf0ea59000)

Nothing jumps out at me.
Could you perhaps run it through gdb and see where it crashes out.

None of the valgrind messages refer to my code. Only to the libraries on the system.

I really thing we're trying to debug several things at once here, not knowing which is at fault.

If you could try to get it working on the test server - I see that it used to compile but latest revision doesn't (because sconstruct broke). Then check that you can execute the binary on the test server and not get a segmentation fault. That would be really helpful.

There's also RAL machines. Or if you want me to try to build it on my desktop, please let me know. (in addition to test server I guess).

The binary won't execute without an X server.
I got no segmentation fault on my SL5 machines, but this was in the branch with no attempt to merge.

• the scons version
• setting random environment variables
  It's not working out for me

cr67> bzr info
Checkout (format: 2a)
Location:
       checkout root: .
  checkout of branch: bzr+ssh://bazaar.launchpad.net/~m-robinson/maus/evtvwr/

Related branches:
  submit branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/maus/

cr67> bzr status
modified:
  third_party/bash/40python_extras.bash
unknown:
  scons-2.1.0.alpha.20110323.tar.gz
  share/
  bin/edam
  src/EventViewer/edam
  src/EventViewer/moc_edam.4.cc
  src/EventViewer/moc_gui.4.cc
  src/EventViewer/moc_world.4.cc
  third_party/scons-2.1.0.alpha.20110323.tar.gz

cr67> ./bin/edam 
Segmentation fault

Just double-checked it on my SL 5 machine. No seg fault.
On SL5 I've been building it against the system qt. I just tested it against qt4 (SL5 defaults to qt3) and again, no segmentation fault.
Whilst I was doing this, I noticed that I'd forgotten to include the "site_scons" with the qt4 handler in the bzr, so I've corrected that.
I don't think it's a good idea to install qt4 from source if the qt4 headers and libraries are already installed on the system. It should work if all the environment variables are right, but it complicates things quite unnecessarily. I put in a decent amount of time teaching SConstruct to build with any currently used version of qt.