ID |
Date |
Author |
Topic |
Subject |
113
|
18 Apr 2006 |
Joe Chuma | Bug Fix | Pause/Restart Refresh button added |
A Pause/restart refresh button has been added to the Roody frame so users may quickly pause and restart online histogram refreshing. |
114
|
19 Apr 2006 |
Joe Chuma | Bug Fix | pause/restart button fixed |
The pause/restart button was not working properly, as a result of some confusion about the return value from the TString Compare method. It should now be fixed. |
115
|
05 Jun 2006 |
Joe Chuma | Bug Fix | reset histograms |
Roody should now be able to reset online histograms. Use the "reset all" menu item to reset all online histograms, or use the right click context menu on individual histograms to reset just one histogram (or a set of histograms chosen by holding down the ctrl key while selecting). The latest ROME analyzer is required for these features to be used. |
119
|
07 Jun 2006 |
Joe Chuma | Bug Fix | roody online fixes |
Roody has been modified so the resetting of individual histograms should now work. This involved a check for "//" at beginning of path to histogram and remove if it is there.
Also, the properties of the refresh button have been changed. It is enabled when there is a socket connection, and if the refresh rate = 0, button says "refresh now", but if the refresh rate > 0, button toggles refresh on/off (with appropriate labeling). |
120
|
22 Jun 2006 |
Joe Chuma | Bug Fix | roody refresh button fix (again) |
The refresh button was in the wrong state the first time the user set the refresh rate for online histograms. |
67
|
05 Oct 2004 |
John M O'Donnell | Suggestion | displaying and selecting cuts |
I have talked with Pierre-Andre and Stefan over the last few days about the need
to be able to display graphical cuts (TCutG) in Roody, and also to be able to
change them and send them back to the analyzer.
I expect to have some sample code for putting cuts into a folder sometime soon. |
78
|
20 Dec 2004 |
John M O'Donnell | Bug Fix | displaying cuts implementation |
Attached is a cvs patch to allow roody to display graphical cuts (TCutG).
Does somebody have the permissions to commit this patch to the cvs repository?
It also includes some hooks where code for updating a cut will be implmented.
Updating cuts will be done with another patch, to both roody and midas. This same
mechanism can be used for creating new cuts and sending them to the analyzer.
The final part of this project will be a change to midas to allow cuts to be booked
into (sub)folders. I have some code which I am using for testing purposes, but I
don't like where it stores the cuts for persistence between different invocations of
the analyzer. I'm thinking that cuts should be stored in last.root, and retrieved
from there.
John. |
Attachment 1: cut_display.patch
|
? MTGListTreeDict.cxx
? MTGListTreeDict.h
? RoodyDict.cxx
? RoodyDict.h
? TGTextDialogDict.cxx
? TGTextDialogDict.h
? TNetFolderDict.cxx
? TNetFolderDict.h
? TPeakFindPanelDict.cxx
? TPeakFindPanelDict.h
? TXaxisLimitsDialogDict.cxx
? TXaxisLimitsDialogDict.h
? roody
Index: Roody.cxx
===================================================================
RCS file: /usr/local/cvsroot/roody/src/Roody.cxx,v
retrieving revision 1.42
diff -r1.42 Roody.cxx
284a285
> AddSetCut();
673a675,689
> void Roody::AddSetCut()
> {
> TClassMenuItem *menuItem = new TClassMenuItem( TClassMenuItem::kPopupUserFunction,
> Roody::Class(),
> "Send to Analyzer", "SetCut", this,
> "TObject*", 0);
> TCutG::Class()->GetMenuList()->AddFirst(menuItem);
> }
>
> void Roody::SetCut(TObject *o)
> {
> TCutG *cut = static_cast<TCutG*>(o);
> cout << "SetCut callback for " << cut->GetName() << " not yet implemented" << endl;
> }
>
989a1006,1010
> else if( obj->InheritsFrom(TCutG::Class()) )
> {
> TCutG *c = static_cast<TCutG*>(obj);
> c->Draw();
> }
2354a2376,2382
> else if( type && type->Contains("TCutG") && !found )
> {
> fFileOnlineContents->AddItem( item, itemDescription.c_str(),
> (void*)new TObjString(name.c_str()),
> gClient->GetPicture("cut_t.xpm"),
> gClient->GetPicture("cut_t.xpm") );
> }
2410a2439,2443
> else if (object->InheritsFrom(TCutG::Class()) )
> {
> TCutG *cut = static_cast<TCutG*>(object);
> DrawObject( dest, cut);
> }
Index: Roody.h
===================================================================
RCS file: /usr/local/cvsroot/roody/src/Roody.h,v
retrieving revision 1.36
diff -r1.36 Roody.h
259a260
> #include "TCutG.h"
305a307
> void SetCut(TObject *cut);
464a467
> void AddSetCut();
Index: TNetFolder.cpp
===================================================================
RCS file: /usr/local/cvsroot/roody/src/TNetFolder.cpp,v
retrieving revision 1.1
diff -r1.1 TNetFolder.cpp
49,51c49,54
< TObjArray *list = (TObjArray*) m->ReadObject(m->GetClass());
< delete m;
< return list;
---
> if (m) {
> TObjArray *list = (TObjArray*) m->ReadObject(m->GetClass());
> delete m;
> return list;
> }
> return 0;
|
79
|
07 Jan 2005 |
John M O'Donnell | Bug Fix | displaying cuts implementation |
> Attached is a cvs patch to allow roody to display graphical cuts (TCutG).
>
> Does somebody have the permissions to commit this patch to the cvs repository?
>
> It also includes some hooks where code for updating a cut will be implmented.
> Updating cuts will be done with another patch, to both roody and midas. This same
> mechanism can be used for creating new cuts and sending them to the analyzer.
>
> The final part of this project will be a change to midas to allow cuts to be booked
> into (sub)folders. I have some code which I am using for testing purposes, but I
> don't like where it stores the cuts for persistence between different invocations of
> the analyzer. I'm thinking that cuts should be stored in last.root, and retrieved
> from there.
>
> John.
cvs commit made today to support display of polygons, and sending polygons an analyzer.
A patch for mana.c so that MIDAS analyzers receive polygons has been sent to Stefan.
John. |
81
|
13 Jan 2005 |
John M O'Donnell | Bug Fix | displaying cuts implementation |
I have just sent a MIDAS patch to Stefan so that:
(1) cuts should be booked using TCutG *cut_book( const char *name).
Usage is similar to h1_book etc.
(2) cuts are saved in last.root.
(3) cuts are restored from last.root.
I also fixed a bug in receiving cuts from ROODY. The search for
cuts should be made only in gManaHistosFolder, not from gROOT.
Should this also be the case for GetPointer etc.?
I believe this implements a first pass at handling TCutG for MIDAS and ROODY.
To create a cut from scratch, one declares it in the analyzer init functions
using cut_book, and saves the pointer for use in the event-by-event code.
Then in ROODY, create a polygon, name it and send it to the analyzer (right click
on the polygon).
I believe the patchs which I have made should also be applied to ROME.
John. |
130
|
16 Nov 2007 |
John M O'Donnell | Bug Fix | uint32_t or UInt_t |
I just downloaded and compiled the latest tarball.
line 98 of DataSourceTNetFolder.h complained about unit32_t. While I could have
added an include to make this work, I instead changed it to use the ROOT type
UInt_t.
Perhaps this change should be included in the distribution |
Attachment 1: DataSourceTNetFolder.h
|
//
// DataSourceTNetFolder.h
//
// $Id$
//
#include "DataSourceBase.h"
#include "TSocket.h"
#include "TFolder.h"
class DataSourceTNetFolder: public DataSourceBase
{
private:
TSocket *fSocket;
public:
DataSourceTNetFolder(TSocket* socket) // ctor
{
fName = socket->GetName();
fName += ":";
char buf[256];
sprintf(buf, "%d", socket->GetPort());
fName += buf;
fSocket = socket;
}
~DataSourceTNetFolder() // dtor
{
fSocket = NULL;
}
void Close()
{
fSocket->Close();
}
void Reopen()
{
std::string host = fSocket->GetName();
int port = fSocket->GetPort();
fSocket->Close();
delete fSocket;
fSocket = new TSocket(host.c_str(), port);
}
static TObjArray* ListRemoteObjects(TSocket* sock, const char* foldername)
{
size_t p = 0;
{
std::string str = "GetPointer ";
str += foldername;
if (!sock->Send(str.c_str()))
return NULL;
TMessage *m = NULL;
if (!sock->Recv(m))
return NULL;
if (!m)
return NULL;
*m >> p;
delete m;
m = NULL;
}
if (!sock->Send("GetListOfFolders"))
return NULL;
TMessage m(kMESS_ANY);
m.Reset();
m << p;
if (!sock->Send(m))
return NULL;
TMessage *mr = 0;
if (!sock->Recv(mr))
return NULL;
TObjArray *list = NULL;
if (mr)
{
list = (TObjArray *) mr->ReadObjectAny(mr->GetClass());
}
delete mr;
return list;
}
static TObject* ReadRemoteObject(TSocket* sock, const char* foldername, const char* objname)
{
printf("ReadRemoteObject %s from folder %s\n", objname, foldername);
UInt_t p = 0;
{
std::string str = "GetPointer ";
str += foldername;
if (!sock->Send(str.c_str()))
return NULL;
TMessage *m = NULL;
if (!sock->Recv(m))
return NULL;
if (!m)
return NULL;
*m >> p;
delete m;
m = NULL;
}
printf("Folder %s pointer %d\n", foldername, (int)p);
{
std::string str = "FindObject ";
str += objname;
if (!sock->Send(str.c_str()))
return NULL;
TMessage m(kMESS_ANY);
m.Reset();
m << p;
if (!sock->Send(m))
return NULL;
TMessage *mr = 0;
if (!sock->Recv(mr))
return NULL;
TObject *obj = NULL;
if (mr)
{
bool adddir = TH1::AddDirectoryStatus();
TH1::AddDirectory(false);
obj = (TObject*)mr->ReadObjectAny(0);
TH1::AddDirectory(adddir);
}
delete mr;
return obj;
}
}
static void ExecuteRemoteCommand(TSocket* socket, const char *line)
{
if (!socket->IsValid())
return;
// The line is executed by the CINT of the server
socket->Send("Execute");
socket->Send(line);
}
void EnumerateTFolder(ObjectList* list, TFolder* f, ObjectPath path)
{
TIterator *iterator = f->GetListOfFolders()->MakeIterator();
while (1)
{
TNamed *obj = (TNamed*)iterator->Next();
if (obj == NULL)
break;
const char* classname = obj->ClassName();
const char* name = obj->GetName();
if (strcmp(classname,"TFolder") == 0)
{
TFolder* f = (TFolder*)obj;
ObjectPath p = path;
p.push_back(name);
EnumerateTFolder(list, f, p);
}
//else if (strcmp(classname,"TDirectory") == 0)
// {
// TDirectory* d = (TDirectory*)obj;
// ObjectPath p = path;
// p.push_back(name);
// EnumerateTDirectory(list, d, p);
// }
else
{
ObjectPath p = path;
std::string s;
s += name;
//s += "(";
//s += classname;
//s += ")";
p.push_back(s);
list->push_back(p);
}
}
}
TFolder* ReadFolder(const char* foldername, ObjectPath path, const char* name)
{
TObject* obj = ReadRemoteObject(fSocket, foldername, name);
if (!obj)
return NULL;
if (obj->InheritsFrom(TFolder::Class()))
return (TFolder*)obj;
ObjectPath p = path;
p.push_back(name);
return NULL;
}
void Enumerate(ObjectList* list, const char* foldername, ObjectPath path)
{
TCollection *contents = ListRemoteObjects(fSocket, foldername);
if (!contents)
return;
TIterator *iterator = contents->MakeIterator();
while (1)
{
TNamed *obj = (TNamed*)iterator->Next();
if (obj == NULL)
break;
const char* classname = obj->ClassName();
const char* name = obj->GetName();
if (strcmp(classname,"TObjString") == 0)
{
TObject* xobj = ReadRemoteObject(fSocket, foldername, name);
if (!xobj)
continue;
if (xobj->InheritsFrom(TFolder::Class()))
{
TFolder *fff = (TFolder*)xobj;
ObjectPath p = path;
p.push_back(name);
EnumerateTFolder(list, fff, p);
continue;
}
}
ObjectPath p = path;
std::string s;
s += name;
//s += "(";
//s += classname;
//s += ")";
p.push_back(s);
list->push_back(p);
}
}
ObjectList GetList()
{
ObjectList list;
ObjectPath path;
path.push_back(fName);
char *topfolder = "histos";
path.push_back(topfolder);
Enumerate(&list, topfolder, path);
return list;
}
TObject* GetObject(const ObjectPath& path)
{
//gDirectory->pwd();
//gDirectory->ls();
const char *name = path.back().c_str();
printf("Get object %s from %s\n", name, fName.c_str());
const char *foldername = path[path.size()-2].c_str();
TObject* obj = ReadRemoteObject(fSocket, foldername, name);
return obj;
}
void ResetAll()
{
printf("ResetAll %s\n", fName.c_str());
ExecuteRemoteCommand(fSocket, "gAnalyzer->ResetAllHistos()");
}
void ResetObject(const ObjectPath& path)
{
printf("ResetObject %s\n", path.toString().c_str());
std::string name = path.back();
std::string s;
... 17 more lines ...
|
132
|
19 Nov 2007 |
John M O'Donnell | Bug Fix | uint32_t or UInt_t |
I'm using Redhat workstation with:
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
ROOT version 5.16/00
it is unlikely that UInt_t will ever be too small. If it is too small, then ROOT will
break! It is clearly intended to be 32 bits long. From Rtypes.h:
#ifdef R__INT16
typedef long Int_t; //Signed integer 4 bytes
typedef unsigned long UInt_t; //Unsigned integer 4 bytes
#else
typedef int Int_t; //Signed integer 4 bytes (int)
typedef unsigned int UInt_t; //Unsigned integer 4 bytes (unsigned int)
#endif
Of course, stdint.h is defined in a standard. However ROOT doesn't really try to follow
the standard (CINT compiles a language similar to C++, but not exactly C++), and indeed
the file stdint.h is not explicitly included in any of $ROOTSYS/include/*.h.
John.
> > I just downloaded and compiled the latest tarball.
> >
> > line 98 of DataSourceTNetFolder.h complained about unit32_t. While I could have
> > added an include to make this work, I instead changed it to use the ROOT type
> > UInt_t.
>
> Uint_t is technically incorrect. The data returned from the socket connection is a
> 32-bit pointer to an object in the remote process (how do they come up with
> communication protocols like this?!?). The type "Uint_t" is not defined to be of any
> particular size and is not necessarily big enough to hold a 32-bit unsigned integer.
>
> According to the "C99" standard, the correct C data type for 32-bit unsigned
> integers is uint32_t, defined in "#include <stdint.h>", e.g. see
> http://www.oreillynet.com/pub/a/network/2003/10/07/michael_barr.html
>
> I have now added the missing "#include <stdint.h>" statement to
> DataSourceTNetFolder.h, commited as revision 230.
>
> I am puzzled why the code compiled without this include statement, possibly on my
> SL4.3 machine with ROOT v5.16.00, some ROOT or system header file included it for
> me. I am curious what system you use where this code failed to compile?
>
> K.O. |
13
|
21 Jul 2003 |
Konstantin | | |
I created a CVS repository for the ROOT GUI project:
/dasdevpc/cvsroot/rootgui (dasdevpc:/usr/local/cvsroot/rootgui)
(should I rename it to cvsroot/miroodas?).
K.O.
|
14
|
21 Jul 2003 |
Konstantin | | CVS repository |
I created a CVS repository for the ROOT GUI project:
/dasdevpc/cvsroot/miroodas (dasdevpc:/usr/local/cvsroot/miroodas)
K.O. |
15
|
21 Jul 2003 |
Konstantin | | Account for Joe Chuma |
I created an account for Joe Chuma on the DAQ cluster. The home directory
is /send/home/chuma. Joe, please contact me to learn your password. K.O.
|
16
|
21 Jul 2003 |
Konstantin | | Account for Joe Chuma |
I created an account for Joe Chuma on the DAQ cluster. The home directory
is /send/home/chuma. Joe, please contact me to learn your password. K.O.
|
17
|
21 Jul 2003 |
Konstantin | | miroodas forum |
The URL for the MIROODAS forum is: http://daq.triumf.ca:8085/MIROODAS
K.O.
|
18
|
21 Jul 2003 |
Konstantin | | meeting this Tuesday! |
We will have our regular meeting this Tuesday at 10am in the ISAC2 2nd
floor kitchen.
Agenda:
-review of assigned homework (I did most of mine!).
-layout of our cvs repository
K.O.
|
20
|
29 Jul 2003 |
Konstantin | | test midas experiment |
I revived the test midas experiment on midtis06. We can start using it to
develop the online connection to the root gui. Here are the instructions
on running things:
- login to midtis06
- set ROOTSYS to /send/home/olchansk/daq/root
- cd /send/home/olchansk/daq/root
- ./start_daq (four xterm windows should open:
1) mhttpd (on port 8080). Point a web browser to http://midtis06:8080
2) odbedit
3) a front end
4) an analyzer)
- run ~olchansk/daq/midas/linux/bin/rmidas
enter "midtis06" in the "hostname" box.
five histogram names should appear in the list on the left: CADC00
through 03 and ADCSUM. Click on the names to see the histograms.
- start a run (from a web browser, or enter "start" in odbedit)
- the frontend window should count 100 events/sec.
- click on the rmidas "update" button, the counts should increment.
This is all done by vanilla ROOT and MIDAS.
The ROOT code to access the MIDAS histograms is in
~olchansk/daq/midas/src/rmidas.c, functions:
- ConnectServer()
- GetHistoList()
- GetHisto()
- ClearHisto()
K.O. |
21
|
29 Jul 2003 |
Konstantin | | Wednesday 10am meeting |
We will have the 10am meeting this Wednesday in the ISAC2 2nd floor kitchen.
Agenda:
- progress reports
- status of midas online connection (K.O.)
- priority of improvements to the histogram viewer (TCanvas) and tree view
(TTreeViewer). (G.K.)
K.O. |
27
|
20 Dec 2003 |
Konstantin | | remove Greg King from email list |
I removed Greg King from the MIROODAS email notification. K.O. |