Project

General

Profile

Feature #359

Visualisation

Added by Rogers, Chris over 10 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Category:
-
Target version:
Start date:
01 March 2011
Due date:
15 September 2011
% Done:

0%

Estimated time:
Workflow:

Description

We need a visualisation tool. Aim is to:

  • import geometry information from MiceModules
  • import particle data from persistency stream
  • make a nice gui to use in control room (or at home) to interrogate persistency stream using 3D interface

Files

Screen_shot_2011-03-01_at_1_Mar_17.51.45.png (108 KB) Screen_shot_2011-03-01_at_1_Mar_17.51.45.png Robinson, Matthew, 01 March 2011 17:54
Screen_shot_2011-03-02_at_2_Mar_17.28.44.png (238 KB) Screen_shot_2011-03-02_at_2_Mar_17.28.44.png Robinson, Matthew, 02 March 2011 17:33
g4_03.wrl (3.04 MB) g4_03.wrl Rogers, Chris, 20 July 2011 11:36
sage1.png (4.57 MB) sage1.png wireframe snapshot Robinson, Matthew, 20 July 2011 11:49
sage2.png (4.57 MB) sage2.png solid snapshot Robinson, Matthew, 20 July 2011 11:49
edam.mp4 (22.2 MB) edam.mp4 Rogers, Chris, 20 July 2011 17:05
edam2.avi (44.5 MB) edam2.avi Rogers, Chris, 20 July 2011 17:05
edam2.mp4 (16.9 MB) edam2.mp4 Rogers, Chris, 20 July 2011 17:05
sage-0.0.11.tar.gz (481 KB) sage-0.0.11.tar.gz VRML viewer Robinson, Matthew, 21 July 2011 13:43
Screen_Shot_2011-09-02_at_2_Sep_16.40.29.png (293 KB) Screen_Shot_2011-09-02_at_2_Sep_16.40.29.png Robinson, Matthew, 02 September 2011 16:46
log (7.26 KB) log valgrind log for #131 Rogers, Chris, 03 October 2011 15:51
simulation.out (6.38 MB) simulation.out Rogers, Chris, 26 January 2012 12:09
#1

Updated by Rogers, Chris over 10 years ago

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.*

I would make a tool that mimics this functionality but converts to visualisation instead of geant4, say MiceModToVisTool.

Some comments:
  • 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.
#2

Updated by Tunnell, Christopher over 10 years ago

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.

#3

Updated by Robinson, Matthew over 10 years ago

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.

#4

Updated by Robinson, Matthew over 10 years ago

Right.
I've taught it to render vrml as a wire-frame.
I'll have a go at doing it in surfaces, but I think a wire-frame is better as it avoid cluttering the display and making the tracks harder to see.
Attached is a rendering of the DM-ICE geometry which I had to hand.

#5

Updated by Robinson, Matthew over 10 years ago

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.

#6

Updated by Rogers, Chris over 10 years ago

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.

#7

Updated by Robinson, Matthew over 10 years ago

The reading of vrml was really straightforward. It's a nice format. All I need now is the proper wrl file for the detector. But I can see that this is non-trivial and it's not urgent.

Today I've been working on the UI mostly rather than the opengl. I've put in an appropriate set of menus to allow the user to change the behaviour of the application, and choose what is displayed out of detector wireframe, detector surfaces, tracks and spacepoints.
I've also added a track list at the side, see attached. Selecting tracks from the list causes them to turn from blue to red in the viewer, so you can see which is which.

Any thoughts for additional functionality, please let me know.

#8

Updated by Tunnell, Christopher over 10 years ago

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.

#9

Updated by Robinson, Matthew over 10 years ago

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.

#10

Updated by Rogers, Chris over 10 years ago

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

Let me know if you find bugs...

#11

Updated by Robinson, Matthew over 10 years ago

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.

#12

Updated by Rogers, Chris about 10 years ago

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.

#13

Updated by Robinson, Matthew about 10 years ago

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.

#14

Updated by Rogers, Chris about 10 years ago

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?

#15

Updated by Robinson, Matthew about 10 years ago

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?

#16

Updated by Rogers, Chris about 10 years ago

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

#17

Updated by Rogers, Chris about 10 years ago

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

#18

Updated by Rogers, Chris about 10 years ago

I add a more complicated VRML file for stage 6 - welcome to have a go. I never managed to get a vrml viewer to work, so I can't check the file myself. This came from G4MICE.

#19

Updated by Robinson, Matthew about 10 years ago

Hi Chris,

That's very helpful.
I have a vrml viewer that I wrote based on the mice event viewer. This reads it fine.
The viewer is probably subject to the same problem on certain linux variants that you identified with the event viewer. But I attach the source and a couple of snapshots anyway in case it's useful to you.

Matt.

#20

Updated by Rogers, Chris about 10 years ago

'Bootiful'

#21

Updated by Robinson, Matthew about 10 years ago

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

#22

Updated by Tunnell, Christopher about 10 years ago

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

#23

Updated by Robinson, Matthew about 10 years ago

I did try.
It was rejected.

Matt.

#24

Updated by Rogers, Chris about 10 years ago

Linked (presume sage?.png already linked

#25

Updated by Robinson, Matthew about 10 years ago

Thanks. Must be just me.

#26

Updated by Robinson, Matthew about 10 years ago

I'm attaching a new version of the vrml viewer with the bug affecting some linux variants corrected, I think. I've also applied the fix to the mice event viewer which had exactly the same problem and uploaded the fixed version to the bzr.

#27

Updated by Robinson, Matthew about 10 years ago

  • File deleted (sage-0.0.10.tar.gz)
#28

Updated by Rogers, Chris about 10 years ago

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.

#29

Updated by Robinson, Matthew about 10 years ago

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?

#30

Updated by Rogers, Chris about 10 years ago

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.

Looking over your stuff, few more suggestions:
  • 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.

#31

Updated by Robinson, Matthew about 10 years ago

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.

#32

Updated by Rogers, Chris about 10 years ago

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"));

and I saw ../share/edam.wrl which looks rather like a hard coded filename. I would rather that we take default from src/common_py/ConfigurationDefaults.py and then modify using Configuration.py as all the other parameters are done like that. It's a pain if sometimes we take environment variables, sometimes configuration variables... makes for confusion.

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.

#33

Updated by Rogers, Chris about 10 years ago

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

#34

Updated by Robinson, Matthew about 10 years ago

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.

#35

Updated by Robinson, Matthew about 10 years ago

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....

#36

Updated by Tunnell, Christopher about 10 years ago

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

#37

Updated by Robinson, Matthew about 10 years ago

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.

#38

Updated by Robinson, Matthew about 10 years ago

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

#39

Updated by Tunnell, Christopher about 10 years ago

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?

#40

Updated by Robinson, Matthew about 10 years ago

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.

#41

Updated by Tunnell, Christopher about 10 years ago

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.

#42

Updated by Robinson, Matthew about 10 years ago

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.

#43

Updated by Tunnell, Christopher about 10 years ago

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.

#44

Updated by Robinson, Matthew about 10 years ago

... 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.

#45

Updated by Tunnell, Christopher about 10 years ago

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.

#46

Updated by Robinson, Matthew about 10 years ago

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

#47

Updated by Rogers, Chris about 10 years ago

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).

Makefiles:
We used to have about 5000 lines of makefile code to maintain, in addition to an impenetrable perl script that generated makefiles as well. It was evil. So we agreed to use scons:-
  • 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.

#48

Updated by Rogers, Chris about 10 years ago

Two more things:
  • 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!
#49

Updated by Robinson, Matthew about 10 years ago

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

#50

Updated by Tunnell, Christopher about 10 years ago

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

#51

Updated by Robinson, Matthew about 10 years ago

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.

#52

Updated by Tunnell, Christopher about 10 years ago

relax...

#53

Updated by Robinson, Matthew about 10 years ago

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?

#54

Updated by Robinson, Matthew about 10 years ago

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?

#55

Updated by Rogers, Chris about 10 years ago

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.

#56

Updated by Robinson, Matthew about 10 years ago

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.

#57

Updated by Rogers, Chris about 10 years ago

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?

#58

Updated by Rogers, Chris about 10 years ago

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

#59

Updated by Robinson, Matthew about 10 years ago

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?

#60

Updated by Rogers, Chris about 10 years ago

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.

#61

Updated by Robinson, Matthew about 10 years ago

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?

#62

Updated by Robinson, Matthew about 10 years ago

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?

#63

Updated by Robinson, Matthew about 10 years ago

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.

#64

Updated by Tunnell, Christopher about 10 years ago

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

#65

Updated by Rogers, Chris about 10 years ago

That sounds fine.

#66

Updated by Robinson, Matthew about 10 years ago

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

#67

Updated by Rogers, Chris about 10 years ago

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

#68

Updated by Rogers, Chris about 10 years ago

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

#69

Updated by Robinson, Matthew about 10 years ago

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.

#70

Updated by Rogers, Chris about 10 years ago

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...

#71

Updated by Robinson, Matthew about 10 years ago

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?

#72

Updated by Tunnell, Christopher about 10 years ago

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.

#73

Updated by Rogers, Chris about 10 years ago

Adding to PATH in ./configure is fine also.

#74

Updated by Tunnell, Christopher about 10 years ago

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

#75

Updated by Tunnell, Christopher about 10 years ago

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

#76

Updated by Tunnell, Christopher about 10 years ago

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?

#78

Updated by Robinson, Matthew about 10 years ago

Thanks. I've put in the eof.

#79

Updated by Tunnell, Christopher about 10 years ago

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....

#80

Updated by Robinson, Matthew about 10 years ago

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.

#81

Updated by Rogers, Chris about 10 years ago

  • Target version changed from Future MAUS release to MAUS-v0.1.0

So I set target version 0.1.0 for this. I wanted to make it clear that this should be target date for getting what you have currently into the trunk. We should get that through a code review and then assess what the next step is. (0.1.0 target date is early September)

#82

Updated by Robinson, Matthew about 10 years ago

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?

#83

Updated by Rogers, Chris about 10 years ago

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.

#84

Updated by Rogers, Chris about 10 years ago

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.

#85

Updated by Rogers, Chris about 10 years ago

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.

#86

Updated by Tunnell, Christopher about 10 years ago

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?

#87

Updated by Tunnell, Christopher about 10 years ago

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.

#88

Updated by Robinson, Matthew about 10 years ago

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.

#89

Updated by Tunnell, Christopher about 10 years ago

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.

#90

Updated by Robinson, Matthew about 10 years ago

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.

#91

Updated by Tunnell, Christopher about 10 years ago

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?

#92

Updated by Robinson, Matthew about 10 years ago

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

#93

Updated by Tunnell, Christopher about 10 years ago

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

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

#94

Updated by Robinson, Matthew about 10 years ago

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.

#95

Updated by Tunnell, Christopher about 10 years ago

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?

#96

Updated by Tunnell, Christopher about 10 years ago

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

#97

Updated by Robinson, Matthew about 10 years ago

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.

#98

Updated by Tunnell, Christopher about 10 years ago

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.

#99

Updated by Coney, Linda about 10 years ago

  • Due date set to 15 September 2011

Deadline for prototype event display is in the MICO milestones for 15 Sept 2011.

Final production version due on 1 Jan 2012.

Updated by Robinson, Matthew about 10 years ago

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.

Updated by Rogers, Chris about 10 years ago

  • Category changed from common_py to 44
Right - so prototype version means get what you have into MAUS. Maybe jury rig some cache to hard drive which visualisation then reads in (something, for example, I can do). Full version means
  • get a clear idea of at least the planned data structure (Rogers)
  • implement that (Robinson)
  • get the code to talk over the socket (Robinson)
    Is that reasonable to do by January (would be new issue)?

Then we probably need to iterate as detector groups implement their reconstruction algorithms (they will probably want to tweak data structure, etc).

I realise I should also add this to the offline software milestones that I just pushed to devs list.

Updated by Robinson, Matthew about 10 years ago

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.

Updated by Tunnell, Christopher about 10 years ago

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.

Updated by Tunnell, Christopher about 10 years ago

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.

Updated by Robinson, Matthew about 10 years ago

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

Updated by Santos, Edward about 10 years ago

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

Updated by Santos, Edward about 10 years ago

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

Updated by Robinson, Matthew about 10 years ago

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.

Updated by Robinson, Matthew about 10 years ago

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]

Updated by Robinson, Matthew about 10 years ago

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

Updated by Robinson, Matthew about 10 years ago

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.

Updated by Robinson, Matthew about 10 years ago

Got the event viewer displaying the space-points.
See attached.

The radius of the ball is proportionally to the number of photoelectrons. Initially I was going to make the volume proportional, but I think this is clearer.
I think I'll change the colour.
The centre of the ball should be at the "position" of the space-point.

The space-point list on the right has about 20 columns containing the various information on the space-points. Those column can be turned on and off to keep the clutter down. The default is the columns you see on the screen capture.

I'd appreciate any thoughts you might have that might keep me from going too far down the wrong track.

Matt.

Updated by Rogers, Chris about 10 years ago

Now ready for code review/merge with trunk?

Updated by Rogers, Chris about 10 years ago

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.

Updated by Robinson, Matthew about 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

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?

Updated by Robinson, Matthew almost 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

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...

Updated by Robinson, Matthew almost 10 years ago

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

Updated by Rogers, Chris almost 10 years ago

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/

as qt4 directory.

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?

Updated by Robinson, Matthew almost 10 years ago

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?

Updated by Rogers, Chris almost 10 years ago

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

Updated by Rogers, Chris almost 10 years ago

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.

Updated by Robinson, Matthew almost 10 years ago

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

Updated by Robinson, Matthew almost 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

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...

Updated by Robinson, Matthew almost 10 years ago

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' ?

Updated by Rogers, Chris almost 10 years ago

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)

Updated by Robinson, Matthew almost 10 years ago

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

Updated by Rogers, Chris almost 10 years ago

gdb rather unhappy with the whole MAUS setup. valgrind log attached - but doesnt reveal anything terribly useful for me. However edam does run in valgrind (i.e. sandboxed), so there probably is a genuine memory problem somewhere.

Updated by Robinson, Matthew almost 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

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.

Updated by Tunnell, Christopher almost 10 years ago

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).

Updated by Robinson, Matthew almost 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

I tried just pulling ~m-robinson/maus/evtvwr/ across and modifying
  • 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

Updated by Robinson, Matthew almost 10 years ago

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.

Updated by Rogers, Chris almost 10 years ago

  • Target version changed from MAUS-v0.1.0 to Future MAUS release

Updated by Rogers, Chris over 9 years ago

Sample data file attached

Updated by Rogers, Chris over 9 years ago

  • Status changed from Open to Rejected

Now an online group issue - raised as #964

Also available in: Atom PDF