Back Midas Rome Roody Rootana
  Rome Analyzer Framework, Page 6 of 11  Not logged in ELOG logo
ID Date Author Topic Subjectup
  112   13 Jan 2006 Ryu SawadaSuggestionQuit mode
done.
Users can specify quit mode with option -q or configuration file.
  166   24 Oct 2015 Robert PattieForumROME / Argus crashing between runs with MIDAS
I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
 In our set up there is generally a few seconds between MIDAS runs.  ROME
handles the first run just fine, but always crashes when runs are taken in quick
succession like this.  When running in a slower mode, letting ROME finish
whatever run of end task exist, the online analyzer does not have this problem.
 I've suppressed writing all output files while in the online mode and I don't
have any end of run operations in any of the tasks.  What is happening at the
end of running that is causing ROME to crash?

Thanks for any help.
  167   26 Oct 2015 Konstantin OlchanskiForumROME / Argus crashing between runs with MIDAS
> I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
>  In our set up there is generally a few seconds between MIDAS runs.  ROME
> handles the first run just fine, but always crashes when runs are taken in quick
> succession like this.  When running in a slower mode, letting ROME finish
> whatever run of end task exist, the online analyzer does not have this problem.
>  I've suppressed writing all output files while in the online mode and I don't
> have any end of run operations in any of the tasks.  What is happening at the
> end of running that is causing ROME to crash?
> 
> Thanks for any help.

You have to provide a stack trace from your crash. RTFM the gdb command "where".

K.O.
  170   29 Oct 2015 Ryu SawadaForumROME / Argus crashing between runs with MIDAS
Hello,

You can try to set <MidasOnlineCommunicationThread>to be true in your config XML file.
By doing it, the communication with the midas system will be done in a dedicated thread so it runs independently 
of analysis tasks.

Ryu

> I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
>  In our set up there is generally a few seconds between MIDAS runs.  ROME
> handles the first run just fine, but always crashes when runs are taken in quick
> succession like this.  When running in a slower mode, letting ROME finish
> whatever run of end task exist, the online analyzer does not have this problem.
>  I've suppressed writing all output files while in the online mode and I don't
> have any end of run operations in any of the tasks.  What is happening at the
> end of running that is causing ROME to crash?
> 
> Thanks for any help.
  126   29 Jun 2006 Steven SheetsForumROME analyzer crashes on reading midas file.
Hello,

So I'm stuck on this problem. The ROME based analyzer I use crashes everytime it attempts to open a midas file giving me this error:

Reading Midas-File /home/sheets4/run04750.mid.gz

*** Break *** segmentation violation
Generating stack trace...
0x00002b93efa9cd5c in gzread + 0xfc from /home/sheets4/root/lib/libCore.so
0x00000000004c47d9 in ROMEMidasDAQ::Event(long long) + 0x165 from ./danceanalyzer.exe
0x00000000004c452e in ROMEMidasDAQ::BeginOfRun() + 0x534 from ./danceanalyzer.exe
0x00000000004bf3da in ROMEDAQSystem::BeginOfRunDAQ() + 0x32 from ./danceanalyzer.exe
0x00000000004c1555 in ROMEEventLoop::DAQBeginOfRun(long long) + 0x15d from ./danceanalyzer.exe
0x00000000004c0721 in ROMEEventLoop::ExecuteTask(char const*) + 0x2d5 from ./danceanalyzer.exe
0x00000000004bb395 in ROMEAnalyzer::Start(int, char**) + 0x35d from ./danceanalyzer.exe
0x00000000005d121d in main + 0x2b1 from ./danceanalyzer.exe
0x000000363331c4bb in __libc_start_main + 0xdb from /lib64/tls/libc.so.6
0x00000000004b2e1a in TApplicationImp::ShowMembers(TMemberInspector&, char*) + 0x82 from ./danceanalyzer.exe
Aborted


I'd guess the problem is connected with ROOT but I'm not sure how to fix it.

I run ROOT v5.10.00
ROME v2.4
on a machine with Dual AMD opterons, 64 Bit with Red Hat Enterprise.

Any help would be appreciated.

thanks,
Steven
  127   04 Jul 2006 Matthias SchneebeliForumROME analyzer crashes on reading midas file.
From the error message I don't see where the problem is.
Are you sure that your midas file is ok?

You can send me the xml definition file, all source files of your project and the midas file. Then I will take a look at it.

Matthias




Steven Sheets wrote:
Hello,

So I'm stuck on this problem. The ROME based analyzer I use crashes everytime it attempts to open a midas file giving me this error:

Reading Midas-File /home/sheets4/run04750.mid.gz

*** Break *** segmentation violation
Generating stack trace...
0x00002b93efa9cd5c in gzread + 0xfc from /home/sheets4/root/lib/libCore.so
0x00000000004c47d9 in ROMEMidasDAQ::Event(long long) + 0x165 from ./danceanalyzer.exe
0x00000000004c452e in ROMEMidasDAQ::BeginOfRun() + 0x534 from ./danceanalyzer.exe
0x00000000004bf3da in ROMEDAQSystem::BeginOfRunDAQ() + 0x32 from ./danceanalyzer.exe
0x00000000004c1555 in ROMEEventLoop::DAQBeginOfRun(long long) + 0x15d from ./danceanalyzer.exe
0x00000000004c0721 in ROMEEventLoop::ExecuteTask(char const*) + 0x2d5 from ./danceanalyzer.exe
0x00000000004bb395 in ROMEAnalyzer::Start(int, char**) + 0x35d from ./danceanalyzer.exe
0x00000000005d121d in main + 0x2b1 from ./danceanalyzer.exe
0x000000363331c4bb in __libc_start_main + 0xdb from /lib64/tls/libc.so.6
0x00000000004b2e1a in TApplicationImp::ShowMembers(TMemberInspector&, char*) + 0x82 from ./danceanalyzer.exe
Aborted


I'd guess the problem is connected with ROOT but I'm not sure how to fix it.

I run ROOT v5.10.00
ROME v2.4
on a machine with Dual AMD opterons, 64 Bit with Red Hat Enterprise.

Any help would be appreciated.

thanks,
Steven
  128   07 Jul 2006 Ryu SawadaForumROME analyzer crashes on reading midas file.
I have tested midas file reading on 64 bit CPU. And there was no problem.

My environment is

-- Wring
Linux 2.6.9 SMP pentium4 32bit
ROOT v5.11/06 32 bit
MIDAS rev.3165 32 bit
midas files was written by frontend in midas/examples/experiment

-- Reading
Linux 2.6.17 SMP x86_64 AMD dual-core Athlon 64bit
ROME rev.1223 64 bit
ROOT v5.08/00b 64 bit

midas file was compressed with gzip 1.3.3
  138   09 Jun 2015 Farrukh AzfarInfoROME examples : histoGUI
Dear Colleagues,

I have succesfully written a ROME application for monitoring MIDAS events and 
understand that the appearance of a new MIDAS event record triggers the calling 
of the event method in the Fill Histogram task.

My two questions are however about the example in $ROMESYS/example/histoGUI - 

1) In this example there is no MIDAS event nor event record - what then is 
triggering the calling of the event method 

2) Is it possible to regulate the frequency that the event method is called in 
this example ?

best wishes
Farrukh Azfar
  140   11 Jun 2015 Ryu SawadaInfoROME examples : histoGUI
Dear Farrukh

The 'histoGUI' example was prepared as an example for displaying histograms.
And the data are generated randomly in FillHisto task instead of reading from an input file.
So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is 
implemented in include/ROMENoDAQSystem.h, and it actually does nothing.

With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.

When you run the example, the frequency is not so fast because the CPU is used for updating the display.
If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through 
the task is increased because you update the display with a less frequency (thus lower CPU power is 
needed).

If you are going to use ROME for non-event based application, there are two ways to call some functions 
defined in tabs.
1) With GUI parts, like buttons, menus, sliders and so on
2) With calling a function periodically.

1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for 
operate the tab.

2) is suitable if you want to update the display without any operations.
You can see examples/argus/timer/ and examples/argus/thread as examples.

Best regards,

Ryu

> Dear Colleagues,
> 
> I have succesfully written a ROME application for monitoring MIDAS events and 
> understand that the appearance of a new MIDAS event record triggers the calling 
> of the event method in the Fill Histogram task.
> 
> My two questions are however about the example in $ROMESYS/example/histoGUI - 
> 
> 1) In this example there is no MIDAS event nor event record - what then is 
> triggering the calling of the event method 
> 
> 2) Is it possible to regulate the frequency that the event method is called in 
> this example ?
> 
> best wishes
> Farrukh Azfar
  142   11 Jun 2015 Konstantin OlchanskiInfoROME examples : histoGUI
> I have succesfully written a ROME application ...

For the record, at TRIUMF we have moved away from ROME towards the ROOTANA ROOT-based analyzer 
package which has some simple C++ classes for reading midas raw data, some simple classes and examples for 
working with midas data in ROOT, and some fairly advanced graphical example applications.

https://bitbucket.org/tmidas/rootana

K.O.
  143   11 Jun 2015 Ryu SawadaInfoROME examples : histoGUI
Dear Farrukh

If you want to control the frequency of update of all tabs, maybe, you could use the same method (namely using 'none' DAQ') for calling event methods of tasks and tabs also for non-event based
application.
You may add a task in which you only call 'sleep' function for controlling the frequency.
For allowing you to use GUI buttons also during the sleep, you need to call the sleep function like following.
ProcessEvents function allows you to use GUI parts also during the sleep.
   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

gettimeofday is defined in sys/time.h header file in UNIX-like OS.
gSystem is in TSystem.h

For controlling the frequency, in this example, I added a new steering parameter for the task, which is defined like,
     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

Best regards,

Ryu

> Dear Farrukh
>
> The 'histoGUI' example was prepared as an example for displaying histograms.
> And the data are generated randomly in FillHisto task instead of reading from an input file.
> So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is
> implemented in include/ROMENoDAQSystem.h, and it actually does nothing.
>
> With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.
>
> When you run the example, the frequency is not so fast because the CPU is used for updating the display.
> If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through
> the task is increased because you update the display with a less frequency (thus lower CPU power is
> needed).
>
> If you are going to use ROME for non-event based application, there are two ways to call some functions
> defined in tabs.
> 1) With GUI parts, like buttons, menus, sliders and so on
> 2) With calling a function periodically.
>
> 1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for
> operate the tab.
>
> 2) is suitable if you want to update the display without any operations.
> You can see examples/argus/timer/ and examples/argus/thread as examples.
>
> Best regards,
>
> Ryu
>
> > Dear Colleagues,
> >
> > I have succesfully written a ROME application for monitoring MIDAS events and
> > understand that the appearance of a new MIDAS event record triggers the calling
> > of the event method in the Fill Histogram task.
> >
> > My two questions are however about the example in $ROMESYS/example/histoGUI -
> >
> > 1) In this example there is no MIDAS event nor event record - what then is
> > triggering the calling of the event method
> >
> > 2) Is it possible to regulate the frequency that the event method is called in
> > this example ?
> >
> > best wishes
> > Farrukh Azfar
  144   13 Jun 2015 Farrukh AzfarInfoROME examples : histoGUI
Dear Ryu,

many thanks for your reply that's very useful.

For my knowledge and for the sake of understanding the basics.

1) Its the line : gSystem->ProcessEvents(); that calls all the event methods in the Fill classes and the Tabs classes yes ?

2) This way I am controlling the filling of the tabs at an interval regulated by "sleep" then what has happened to the program itself calling ProcessEvents ? Have I overriden that call by calling ProcessEvents or will it continue to be called - perhaps I just set the <UpdateFrequency> 0</UpdateFrequency> to disable the programs own calling and only use mine ?

I hope I've been clear. Thanks very much for your continued help.

-Farrukh




Ryu Sawada wrote:
Dear Farrukh

If you want to control the frequency of update of all tabs, maybe, you could use the same method (namely using 'none' DAQ') for calling event methods of tasks and tabs also for non-event based
application.
You may add a task in which you only call 'sleep' function for controlling the frequency.
For allowing you to use GUI buttons also during the sleep, you need to call the sleep function like following.
ProcessEvents function allows you to use GUI parts also during the sleep.
   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

gettimeofday is defined in sys/time.h header file in UNIX-like OS.
gSystem is in TSystem.h

For controlling the frequency, in this example, I added a new steering parameter for the task, which is defined like,
     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

Best regards,

Ryu

> Dear Farrukh
>
> The 'histoGUI' example was prepared as an example for displaying histograms.
> And the data are generated randomly in FillHisto task instead of reading from an input file.
> So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is
> implemented in include/ROMENoDAQSystem.h, and it actually does nothing.
>
> With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.
>
> When you run the example, the frequency is not so fast because the CPU is used for updating the display.
> If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through
> the task is increased because you update the display with a less frequency (thus lower CPU power is
> needed).
>
> If you are going to use ROME for non-event based application, there are two ways to call some functions
> defined in tabs.
> 1) With GUI parts, like buttons, menus, sliders and so on
> 2) With calling a function periodically.
>
> 1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for
> operate the tab.
>
> 2) is suitable if you want to update the display without any operations.
> You can see examples/argus/timer/ and examples/argus/thread as examples.
>
> Best regards,
>
> Ryu
>
> > Dear Colleagues,
> >
> > I have succesfully written a ROME application for monitoring MIDAS events and
> > understand that the appearance of a new MIDAS event record triggers the calling
> > of the event method in the Fill Histogram task.
> >
> > My two questions are however about the example in $ROMESYS/example/histoGUI -
> >
> > 1) In this example there is no MIDAS event nor event record - what then is
> > triggering the calling of the event method
> >
> > 2) Is it possible to regulate the frequency that the event method is called in
> > this example ?
> >
> > best wishes
> > Farrukh Azfar
  146   15 Jun 2015 Ryu SawadaInfoROME examples : histoGUI
Dear Farrukh

ProcessEvents is nothing to do with ROME.
It is a ROOT function to process events called by timer, click, sockets etc.
"event" is not MIDAS event, but for example, an event where someone clicked a button.
For example, if you click an "update" button, ROOT needs to call a function connected to the button; ProcessEvents does the job.
So if you want to use the GUI during the sleep of a task, you need to call ProcessEvents sometimes.

https://root.cern.ch/root/html604/TSystem.html#TSystem:ProcessEvents

You need not to overwrite ProcessEvents.

Best regards,

Ryu


Farrukh Azfar wrote:
Dear Ryu,

many thanks for your reply that's very useful.

For my knowledge and for the sake of understanding the basics.

1) Its the line : gSystem->ProcessEvents(); that calls all the event methods in the Fill classes and the Tabs classes yes ?

2) This way I am controlling the filling of the tabs at an interval regulated by "sleep" then what has happened to the program itself calling ProcessEvents ? Have I overriden that call by calling ProcessEvents or will it continue to be called - perhaps I just set the <UpdateFrequency> 0</UpdateFrequency> to disable the programs own calling and only use mine ?

I hope I've been clear. Thanks very much for your continued help.

-Farrukh




Ryu Sawada wrote:
Dear Farrukh

If you want to control the frequency of update of all tabs, maybe, you could use the same method (namely using 'none' DAQ') for calling event methods of tasks and tabs also for non-event based
application.
You may add a task in which you only call 'sleep' function for controlling the frequency.
For allowing you to use GUI buttons also during the sleep, you need to call the sleep function like following.
ProcessEvents function allows you to use GUI parts also during the sleep.
   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

gettimeofday is defined in sys/time.h header file in UNIX-like OS.
gSystem is in TSystem.h

For controlling the frequency, in this example, I added a new steering parameter for the task, which is defined like,
     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

Best regards,

Ryu

> Dear Farrukh
>
> The 'histoGUI' example was prepared as an example for displaying histograms.
> And the data are generated randomly in FillHisto task instead of reading from an input file.
> So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is
> implemented in include/ROMENoDAQSystem.h, and it actually does nothing.
>
> With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.
>
> When you run the example, the frequency is not so fast because the CPU is used for updating the display.
> If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through
> the task is increased because you update the display with a less frequency (thus lower CPU power is
> needed).
>
> If you are going to use ROME for non-event based application, there are two ways to call some functions
> defined in tabs.
> 1) With GUI parts, like buttons, menus, sliders and so on
> 2) With calling a function periodically.
>
> 1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for
> operate the tab.
>
> 2) is suitable if you want to update the display without any operations.
> You can see examples/argus/timer/ and examples/argus/thread as examples.
>
> Best regards,
>
> Ryu
>
> > Dear Colleagues,
> >
> > I have succesfully written a ROME application for monitoring MIDAS events and
> > understand that the appearance of a new MIDAS event record triggers the calling
> > of the event method in the Fill Histogram task.
> >
> > My two questions are however about the example in $ROMESYS/example/histoGUI -
> >
> > 1) In this example there is no MIDAS event nor event record - what then is
> > triggering the calling of the event method
> >
> > 2) Is it possible to regulate the frequency that the event method is called in
> > this example ?
> >
> > best wishes
> > Farrukh Azfar
  113   08 Feb 2006 Ryu SawadaBug ReportROMEEventLoop:Update
Recently the place to call ROMEEventLoop:Update was moved.
Probably because of this, in MIDAS online mode, event number is always incremented even when DAQ is not running.
  114   08 Feb 2006 Ryu SawadaBug ReportROMENetFolderServer
When I run ROME analyzer in online MIDAS mode.
It stopps with making core (segmentation fault).

It seems it makes core after "return" in main.cpp, namely finishing all code.

When I comment out following line in ROMEAnalyzer.cpp, it works propery.
tnet->StartServer(gROME->GetApplication(),gROME->GetPortNumber());

Probably it is relating to ROMENetServer or thread for this.
  115   09 Feb 2006 Ryu SawadaBug ReportROMENetFolderServer
I investigated the problem.

On my machine (Scientific Linux 4.2, gcc3.3.2, glibc2.3.2, ROOT5.08.00), following simple program reproduced the problem.
There was no probelm with ROOT version4.
Is it bug of ROOT ?

When I put -lpthread at the last. This problem stopped.
Actually without this option, my analyzer workes.
I guess -lpthread is not necessary.

I will check more and if not necessary, I will remove -lpthread.

--- Makefile ---
rootlibs := $(shell $(ROOTSYS)/bin/root-config --libs)
rootcflags := $(shell  $(ROOTSYS)/bin/root-config --cflags)

test: main.cpp
	g++ $(rootcflags) -o $@ $< -lpthread $(rootlibs) -lThread
------
--- main.cpp ---
#include <Riostream.h>
#include <TThread.h>

void* TestLoop(void *arg)
{
   return NULL;
}

int main(int argc, char *argv[])
{
   TThread *thread = new TThread("TestLoop", TestLoop);

   cout<<"OK"<<endl;
   return 0;
}  
------
  76   18 Apr 2005 Pierre-Andre AmaudruzSuggestionROOTCINT path
As ROOTSYS is required for the ROME build, I would suggest to
include the code below in the builder for the application Makefile.
This will make Rome less dependent on the ROOT path.

Replace in ROMEBuilder.cpp:

buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());

by

buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
-f %sDict.cpp -c -p ",shortCut.Data());
  77   18 Apr 2005 Matthias SchneebeliSuggestionROOTCINT path
> As ROOTSYS is required for the ROME build, I would suggest to
> include the code below in the builder for the application Makefile.
> This will make Rome less dependent on the ROOT path.
> 
> Replace in ROMEBuilder.cpp:
> 
> buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());
> 
> by
> 
> buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
> -f %sDict.cpp -c -p ",shortCut.Data());

That's in the cvs now, thanks.
  80   03 May 2005 Ryu SawadaSuggestionROOTCINT path
> > As ROOTSYS is required for the ROME build, I would suggest to
> > include the code below in the builder for the application Makefile.
> > This will make Rome less dependent on the ROOT path.
> > 
> > Replace in ROMEBuilder.cpp:
> > 
> > buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());
> > 
> > by
> > 
> > buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
> > -f %sDict.cpp -c -p ",shortCut.Data());
> 
> That's in the cvs now, thanks.

LD_LIBRARY_PATH is not dedecated for ROOT. One can already have it, and overwriting it may cause error.
For instance, if he installed libstdc++ in non-standard place, he will set LD_LIBRARY_PATH there.

In case of GNU Makefile, we can use "if" statemente like,
ifdef LD_LIBRARY_PATH
LD_LIBRARY_PATH += $(ROOTSYS)/lib
else
LD_LIBRARY_PATH := $(ROOTSYS)/lib
endif
  106   18 Dec 2005 Ryu SawadaInfoRe-organization of directory structure
I and Matthias discussed about directory structure. In previous structure, files which can be overwritten and others were placed in the same directory.

We thought it would be better to separate two kinds of files clearly. So I modified directory structure like following.
|-- include
|   |-- daqs       : include files of user defined DAQs.
|   |-- databases  : include files of user defined databases.
|   |-- folders    : include files of folders come when 'ChangeableClassFile" is true.
|   |-- generated  : include files which can be overwritten by builder.
|   `-- tasks      : include files of tasks come when 'ChangeableClassFile" is true.
`-- src
    |-- daqs       : source files of user defined DAQs.
    |-- databases  : source files of user defined databases.
    |-- folders    : source files of folders come when 'ChangeableClassFile" is true.
    |-- generated  : source files which can be overwritten by builder.
    `-- tasks      : source files of tasks.         

All ROME user need to modify the place of files and also #include statement.
ELOG V3.1.4-2e1708b5