Back Midas Rome Roody Rootana
  Root Display GUI, Page 5 of 7  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries   137 Entries 
Goto page Previous  1, 2, 3, 4, 5, 6, 7   Next  All
ID Date Author Topicup Subject
  118   06 Jun 2006 Konstantin OlchanskiBug Fixminor fixes
> Minor fixes that escaped quality assurance by previous commiters:
> 2) have "make clean" remove obsolete stuff from src (src/roody, src/rootsys.h,
etc)
> 3) fix completely nonfunctional enforcement of setting ROOTSYS to the
compiled-in value: execv() should have been execvp() (my bug), actually do call
setenv("ROOTSYS","blah...") (OS_UNIX was not defined in the Makefile, bug by
previous committer).


(previous message was completely garbled by the Elog "ELCode" whatever it is)


Restored fixes (2) and (3) that were removed by a careless previous committer.

(Note this assumes windows has "setenv()", which I believe it does have, please
test compilation on Windows ASAP and let me know).

K.O.
  119   07 Jun 2006 Joe ChumaBug Fixroody 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 ChumaBug Fixroody refresh button fix (again)
The refresh button was in the wrong state the first time the user set the refresh rate for online histograms.
  121   21 Aug 2006 Konstantin OlchanskiBug FixBetter zoom & rebin controls, show TDirectory contents
I commited a series of changed to Roody:
- cleanup unused files
- show contents of TDirectory objects (this used to work before, why was it
removed? It was a 1 line fix!)
- rework and simplify controls for zooming and rebinning of TCanvas contents
K.O.
  129   04 Dec 2006 Konstantin OlchanskiBug FixAdd menu for SetOptStat
I commited the implementation for a new menu item: "OptStat". It allows setting
gStyle->SetOptStat in a user-friendly manner. K.O.
  130   16 Nov 2007 John M O'DonnellBug Fixuint32_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 ...
  131   16 Nov 2007 Konstantin OlchanskiBug Fixuint32_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.

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.
  132   19 Nov 2007 John M O'DonnellBug Fixuint32_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.
  140   17 May 2009 Randolf PohlBug Fix[PATCH] ROODY kills analyzer too!!
Hi,

I have fixed the bug:

diff roody_233/include/DataSourceTNetFolder.h roody_233_fixed/include/DataSourceTNetFolder.h
100c100
< uint32_t p = 0;
---
> uintptr_t p = 0;

(Both Exaos and I were/are using roody on 64 bit machines.)

Best regards,

Randolf
  141   23 Jul 2009 Exaos LeeBug Fix[PATCH] ROODY kills analyzer too!!

Randolf Pohl wrote:
Hi,

I have fixed the bug:

diff roody_233/include/DataSourceTNetFolder.h roody_233_fixed/include/DataSourceTNetFolder.h
100c100
< uint32_t p = 0;
---
> uintptr_t p = 0;

(Both Exaos and I were/are using roody on 64 bit machines.)

Best regards,

Randolf


Oh, GOD! From Wednesday, I have took almost one day to find the BUG and fix it. Then I found your post here. Tongue
  143   19 Oct 2010 Konstantin OlchanskiBug Fixroody update
And you thought that roody was dead? Well, here is an update - implement "reopen" for ROOT files, add 
"reopen" button to main menu, fix duplicated histogram names after "reopen" (at the cost of losing display 
of histogram titles in the tree view).
K.O.
  145   19 Oct 2010 Konstantin OlchanskiBug Fixroody update, fix open of 
> And you thought that roody was dead? Well, here is an update - implement "reopen" for ROOT files, add 
> "reopen" button to main menu, fix duplicated histogram names after "reopen" (at the cost of losing display 
> of histogram titles in the tree view).
> K.O.

Forgot to mention the main reason of this update: when looking at ROOT files, ROODY could not open any subdirectories because of some name 
changes inside ROOT. Now fixed.

ROODY svn rev 236
svn checkout https://ladd00.triumf.ca/svn/roody/trunk roody
K.O.
  152   25 May 2012 Konstantin OlchanskiBug FixFixed the "Zones" menu
The "Zones" manu has not been working right - if you have a canvas open with one 
histogram plotted and you select Zones "2x2", nothing happens. The expected 
action is to have the canvas divide itself into 4 pads (2x2) and the one 
histogram to show up in the first pad. That's how it works now.

svn rev 240.
K.O.
  62   30 Sep 2004 Matthias SchneebeliBug Reportanoncvs account not working anymore
anoncvs account is not working anymore.

Please fix that.

Thanks 

Matthias
  63   30 Sep 2004 Pierre-André AmaudruzBug Reportanoncvs account not working anymore
Access to Roody from anonymous is restored:

cvs -e ssh -d anoncvs@midas.triumf.ca:/usr/local/cvsroot checkout roody
pwd: anoncvs
  64   30 Sep 2004 Konstantin OlchanskiBug Reportanoncvs account not working anymore
> Access to Roody from anonymous is restored:
> cvs -e ssh -d anoncvs@midas.triumf.ca:/usr/local/cvsroot checkout roody
> pwd: anoncvs

What was the fix? I do not think it was ever broken, except for the name change from "miroodas" to "roody", which I could not document until Pierre restored this Elog forum 
a few hours ago. K.O.
  101   27 Oct 2005 Stefan RittBug ReportVarious item when installing ROODY
Hi,

I tried to compile ROODY, and got following problems/issues:

- I see ROODY requires root V3.10.02, ROME requires root >=4, so I will never be able to compile the two packages together with one root installation. Is that true? Since we are already at root 5.04, it might be time to migrate ROODY to newer versions of ROOT...

- The Makefile.win is under roody/, Makefile is under roody/src, not very consistent, there is no "INSTALL" or "COPYING" file which is kind of GNU standard

- I tried to compile ROODY under windows, after having installed root 3.10, but it misses the libxml/ subtree

- For the non-expert users it would be good to supply a windows executable of roody, this way the don't have to bother with compiling

Best regards,

Stefan
  108   19 Dec 2005 Konstantin OlchanskiBug Reportreconnect after midas analyzer is restarted?
When I restart the MIDAS analyzer, it looks like ROODY detects that the connection is broken, but does not reestablish it. Can somebody look into this? K.O.
  112   16 Mar 2006 Matthias SchneebeliBug ReportCompiling under windows
Hi,

when I try to compile roody under windows I get following errors.



c:\roody>nmake -f Makefile.win

Microsoft (R) Program Maintenance Utility, Version 7.00.9466
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

cl /D "OS_WINNT" /GX /GR /Ic:\roody\include /Ic:\roody\..\mxml /IC:\ROOT\include /I. /c /Foobj/Roody.obj src/Roody.cxx
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

Roody.cxx
c:\roody\include\Roody.h(388) : error C2039: 'size_t' : is not a member of 'std'
c:\roody\include\Roody.h(391) : error C2039: 'size_t' : is not a member of 'std'
c:\roody\include\Roody.h(396) : error C2039: 'clear' : is not a member of 'basic_string<char,struct std::char_traits<char>,class std::allocator<char> >'
src/Roody.cxx(754) : error C2061: syntax error : identifier 'xml'
src/Roody.cxx(755) : error C2228: left of '.rdstate' must have class/struct/union type
src/Roody.cxx(762) : error C2296: '<<' : illegal, left operand has type 'class std::basic_ofstream<char,struct std::char_traits<char> > &(__cdecl *)(void)'
src/Roody.cxx(762) : error C2297: '<<' : illegal, right operand has type 'char [9]'
src/Roody.cxx(768) : error C2296: '<<' : illegal, left operand has type 'class std::basic_ofstream<char,struct std::char_traits<char> > &(__cdecl *)(void)'
src/Roody.cxx(768) : error C2297: '<<' : illegal, right operand has type 'char [12]'
src/Roody.cxx(769) : error C2296: '<<' : illegal, left operand has type 'class std::basic_ofstream<char,struct std::char_traits<char> > &(__cdecl *)(void)'
src/Roody.cxx(769) : error C2297: '<<' : illegal, right operand has type 'char [11]'
src/Roody.cxx(770) : error C2296: '<<' : illegal, left operand has type 'class std::basic_ofstream<char,struct std::char_traits<char> > &(__cdecl *)(void)'
src/Roody.cxx(770) : error C2297: '<<' : illegal, right operand has type 'char [11]'
src/Roody.cxx(771) : error C2296: '<<' : illegal, left operand has type 'class std::basic_ofstream<char,struct std::char_traits<char> > &(__cdecl *)(void)'
  133   18 Feb 2008 Jimmy NgaiBug ReportRoody kills MIDAS Analyzer
Hi All,

I'm running Roody with MIDAS 2.0.0 and ROOT 5.14e on Scientific Linux 4.4. 
When Roody is monitoring the online histograms on Localhost, there are two 
possibilities that Roody will kill the MIDAS Analyzer: 
1) quiting Roody
2) unzoom a histogram when auto-refresh is on

Any ideas?

Best Regards,
Jimmy
Goto page Previous  1, 2, 3, 4, 5, 6, 7   Next  All
ELOG V3.1.4-2e1708b5