From: caremoli Date: Tue, 28 Sep 2010 15:12:46 +0000 (+0000) Subject: CCAR: update with V5_1_main (28/09) X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=3f556e65570f03a5ed3d4782db65a67db962f2b3;p=modules%2Fkernel.git CCAR: update with V5_1_main (28/09) --- diff --git a/Makefile.am b/Makefile.am index 2dd472d1e..ef7642aaa 100644 --- a/Makefile.am +++ b/Makefile.am @@ -26,7 +26,7 @@ # $Header$ # include $(top_srcdir)/salome_adm/unix/make_common_starter.am - +# if CORBA_GEN IDLDIR = idl endif diff --git a/bin/killSalomeWithPort.py b/bin/killSalomeWithPort.py index 4e1cbbd4f..38e0cf710 100755 --- a/bin/killSalomeWithPort.py +++ b/bin/killSalomeWithPort.py @@ -146,7 +146,12 @@ def killMyPort(port): fpid = open(filedict, 'r') # from salome_utils import generateFileName - fpidomniNames = generateFileName(os.path.join('/tmp/logs', os.getenv('USER')), + if sys.platform == "win32": + username = os.getenv( "USERNAME" ) + else: + username = os.getenv('USER') + path = os.path.join('/tmp/logs', username) + fpidomniNames = generateFileName(path, prefix="", suffix="Pid_omniNames", extension="log", diff --git a/bin/runSalome.py b/bin/runSalome.py index f0bed272d..13e507638 100755 --- a/bin/runSalome.py +++ b/bin/runSalome.py @@ -33,6 +33,11 @@ from server import * from launchConfigureParser import verbose from server import process_id +if sys.platform == "win32": + SEP = ";" +else: + SEP = ":" + # ----------------------------------------------------------------------------- from killSalome import killAllPorts @@ -104,13 +109,43 @@ class InterpServer(Server): # --- +def get_cata_path(list_modules,modules_root_dir): + """Build a list of catalog paths (cata_path) to initialize the ModuleCatalog server + """ + modules_cata={} + cata_path=[] + + for module in list_modules: + if modules_root_dir.has_key(module): + module_root_dir=modules_root_dir[module] + module_cata=module+"Catalog.xml" + cata_file=os.path.join(module_root_dir, "share",setenv.salome_subdir, "resources",module.lower(), module_cata) + + if os.path.exists(cata_file): + cata_path.append(cata_file) + modules_cata[module]=cata_file + else: + cata_file=os.path.join(module_root_dir, "share",setenv.salome_subdir, "resources", module_cata) + if os.path.exists(cata_file): + cata_path.append(cata_file) + modules_cata[module]=cata_file + + for path in os.getenv("SALOME_CATALOGS_PATH","").split(SEP): + if os.path.exists(path): + for cata_file in glob.glob(os.path.join(path,"*Catalog.xml")): + module_name= os.path.basename(cata_file)[:-11] + if not modules_cata.has_key(module_name): + cata_path.append(cata_file) + modules_cata[module_name]=cata_file + + return cata_path + + + class CatalogServer(Server): def __init__(self,args): self.args=args self.initArgs() - #if sys.platform == "win32": - # self.SCMD1=[os.environ["KERNEL_ROOT_DIR"] + "/win32/" + os.environ["BIN_ENV"] + "/" + 'SALOME_ModuleCatalog_Server' + ".exe",'-common'] - #else: self.SCMD1=['SALOME_ModuleCatalog_Server','-common'] self.SCMD2=[] home_dir=os.getenv('HOME') @@ -118,37 +153,16 @@ class CatalogServer(Server): self.SCMD2=['-personal',os.path.join(home_dir,'Salome/resources/CatalogModulePersonnel.xml')] def setpath(self,modules_list,modules_root_dir): - cata_path=[] list_modules = modules_list[:] list_modules.reverse() if self.args["gui"] : list_modules = ["KERNEL", "GUI"] + list_modules else : list_modules = ["KERNEL"] + list_modules - for module in list_modules: - if modules_root_dir.has_key(module): - module_root_dir=modules_root_dir[module] - module_cata=module+"Catalog.xml" - #print " ", module_cata - if os.path.exists(os.path.join(module_root_dir, - "share",setenv.salome_subdir, - "resources",module.lower(), - module_cata)): - cata_path.extend( - glob.glob(os.path.join(module_root_dir, - "share",setenv.salome_subdir, - "resources",module.lower(), - module_cata))) - else: - cata_path.extend( - glob.glob(os.path.join(module_root_dir, - "share",setenv.salome_subdir, - "resources", - module_cata))) - pass - pass - #self.CMD=self.SCMD1 + ['\"']+[string.join(cata_path,'\"::\"')] + ['\"'] + self.SCMD2 - self.CMD=self.SCMD1 + ['\"' + string.join(cata_path,'\"::\"') + '\"'] + self.SCMD2 + + cata_path=get_cata_path(list_modules,modules_root_dir) + + self.CMD=self.SCMD1 + ['"' + string.join(cata_path,'"::"') + '"'] + self.SCMD2 # --- @@ -271,35 +285,18 @@ class SessionServer(Server): self.SCMD2+=['--pyscript=%s'%(",".join(self.args['pyscript']))] def setpath(self,modules_list,modules_root_dir): - cata_path=[] list_modules = modules_list[:] list_modules.reverse() if self.args["gui"] : list_modules = ["KERNEL", "GUI"] + list_modules else : list_modules = ["KERNEL"] + list_modules - for module in list_modules: - module_root_dir=modules_root_dir[module] - module_cata=module+"Catalog.xml" - #print " ", module_cata - if os.path.exists(os.path.join(module_root_dir, - "share",setenv.salome_subdir, - "resources",module.lower(), - module_cata)): - cata_path.extend( - glob.glob(os.path.join(module_root_dir,"share", - setenv.salome_subdir,"resources", - module.lower(),module_cata))) - else: - cata_path.extend( - glob.glob(os.path.join(module_root_dir,"share", - setenv.salome_subdir,"resources", - module_cata))) - pass + + cata_path=get_cata_path(list_modules,modules_root_dir) + if (self.args["gui"]) & ('moduleCatalog' in self.args['embedded']): #Use '::' instead ":" because drive path with "D:\" is invalid on windows platform - #self.CMD=self.SCMD1 + ['\"']+[string.join(cata_path,'\"::\"')] + ['\"'] + self.SCMD2 - self.CMD=self.SCMD1 + ['\"' + string.join(cata_path,'\"::\"') + '\"'] + self.SCMD2 + self.CMD=self.SCMD1 + ['"' + string.join(cata_path,'"::"') + '"'] + self.SCMD2 else: self.CMD=self.SCMD1 + self.SCMD2 if self.args.has_key('test'): @@ -352,35 +349,20 @@ class LauncherServer(Server): self.SCMD2+=['--with','SALOMEDS','(',')'] if 'cppContainer' in self.args['embedded']: self.SCMD2+=['--with','Container','(','FactoryServer',')'] - + def setpath(self,modules_list,modules_root_dir): - cata_path=[] list_modules = modules_list[:] list_modules.reverse() if self.args["gui"] : - list_modules = ["GUI"] + list_modules - for module in ["KERNEL"] + list_modules: - if modules_root_dir.has_key(module): - module_root_dir=modules_root_dir[module] - module_cata=module+"Catalog.xml" - #print " ", module_cata - if os.path.exists(os.path.join(module_root_dir, - "share",setenv.salome_subdir, - "resources",module.lower(), - module_cata)): - cata_path.extend( - glob.glob(os.path.join(module_root_dir,"share", - setenv.salome_subdir,"resources", - module.lower(),module_cata))) - else: - cata_path.extend( - glob.glob(os.path.join(module_root_dir,"share", - setenv.salome_subdir,"resources", - module_cata))) - pass - pass + list_modules = ["KERNEL", "GUI"] + list_modules + else : + list_modules = ["KERNEL"] + list_modules + + cata_path=get_cata_path(list_modules,modules_root_dir) + if (self.args["gui"]) & ('moduleCatalog' in self.args['embedded']): - self.CMD=self.SCMD1 + [string.join(cata_path,':')] + self.SCMD2 + #Use '::' instead ":" because drive path with "D:\" is invalid on windows platform + self.CMD=self.SCMD1 + ['"' + string.join(cata_path,'"::"') + '"'] + self.SCMD2 else: self.CMD=self.SCMD1 + self.SCMD2 @@ -688,26 +670,47 @@ def useSalome(args, modules_list, modules_root_dir): if args.has_key('gui') and args.has_key('session_gui'): if not args['gui'] or not args['session_gui']: toimport = args['pyscript'] - i = 0 - while i < len( toimport ) : - if toimport[ i ] == 'killall': + + for srcname in toimport : + if srcname == 'killall': clt.showNS() killAllPorts() sys.exit(0) else: - scrname = toimport[ i ] - if len(scrname) > 2 and (len(scrname) - string.rfind(scrname, ".py") == 3): - print 'executing',scrname - sys.path.insert( 0, os.path.dirname(scrname)) - execfile(scrname,globals()) - del sys.path[0] + if os.path.isabs(srcname): + if os.path.exists(srcname): + execScript(srcname) + elif os.path.exists(srcname+".py"): + execScript(srcname+".py") + else: + print "Can't execute file %s" % srcname + pass else: - print 'importing',scrname - doimport = 'import ' + scrname - exec doimport - i = i + 1 - + found = False + for path in [os.getcwd()] + sys.path: + if os.path.exists(os.path.join(path,srcname)): + execScript(os.path.join(path,srcname)) + found = True + break + elif os.path.exists(os.path.join(path,srcname+".py")): + execScript(os.path.join(path,srcname+".py")) + found = True + break + pass + if not found: + print "Can't execute file %s" % srcname + pass + pass + pass + pass + pass return clt + +def execScript(script_path): + print 'executing', script_path + sys.path.insert(0, os.path.dirname(script_path)) + execfile(script_path,globals()) + del sys.path[0] # ----------------------------------------------------------------------------- diff --git a/bin/virtual_salome.py b/bin/virtual_salome.py index dfe2d5948..f20685a43 100644 --- a/bin/virtual_salome.py +++ b/bin/virtual_salome.py @@ -205,9 +205,17 @@ def link_module(options): if not os.path.exists(module_lib_py_dir): print "Python directory %s does not exist" % module_lib_py_dir else: + # __GBO__ specific action for the package salome + module_lib_pypkg_dir=os.path.join(module_lib_py_dir,"salome") + lib_pypkg_dir=os.path.join(lib_py_dir,"salome") + mkdir(lib_pypkg_dir) + # __GBO__ mkdir(lib_py_shared_dir) for fn in os.listdir(module_lib_py_dir): if fn == "shared_modules": continue + # __GBO__ + if fn == "salome": continue + # __GBO__ symlink(os.path.join(module_lib_py_dir, fn), os.path.join(lib_py_dir, fn)) pass if os.path.exists(module_lib_py_shared_dir): @@ -215,6 +223,13 @@ def link_module(options): symlink(os.path.join(module_lib_py_shared_dir, fn), os.path.join(lib_py_shared_dir, fn)) pass pass + # __GBO__ + if os.path.exists(module_lib_pypkg_dir): + for fn in os.listdir(module_lib_pypkg_dir): + symlink(os.path.join(module_lib_pypkg_dir, fn), os.path.join(lib_pypkg_dir, fn)) + pass + pass + # __GBO__ else: if verbose: print module_lib_py_shared_dir, " doesn't exist" diff --git a/configure.ac b/configure.ac index 1439a7db4..b7d89075e 100644 --- a/configure.ac +++ b/configure.ac @@ -134,6 +134,10 @@ AC_ENABLE_DEBUG(no) AC_ENABLE_PRODUCTION(no) AC_ENABLE_MPI_SEQ_CONTAINER(no) +# _GBO_SALOME_PYTHON_PACKAGING_ +PYLOGLEVEL=DEBUG +AC_SUBST(PYLOGLEVEL) + echo echo --------------------------------------------- echo testing libtool @@ -171,8 +175,6 @@ AC_CHECK_LIB(rt,nanosleep) dnl add library libm : AC_CHECK_LIB(m,ceil) -# _CS_gbo We should add all dependent libraries - AC_CXX_USE_STD_IOSTREAM AC_CXX_HAVE_SSTREAM @@ -210,8 +212,9 @@ echo testing swig echo --------------------------------------------- echo -dnl _CS_gbo We should use here a variable given from the CHECK_PYTHON -AM_PATH_PYTHON(2.3) +# _GBO_ This definition is required. Without this definition, the pythondir +# would not be defined. The version doesn't matter. +AM_PATH_PYTHON(2.4) CHECK_SWIG echo @@ -384,6 +387,13 @@ CHECK_HTML_GENERATORS # Additional conditional to avoid compilation of non-portable code AM_CONDITIONAL(WINDOWS, [ test ]) +echo +echo --------------------------------------------- +echo testing sphinx +echo --------------------------------------------- +echo +CHECK_SPHINX + echo echo ============================================================ echo Summary @@ -464,7 +474,7 @@ if test x$libbatch_ok = xno; then echo fi -htmldoc_products="doxygen_ok graphviz_ok rst2html_ok" +htmldoc_products="doxygen_ok graphviz_ok rst2html_ok sphinx_ok" echo --- Html documentation products: only required for doc production summary $htmldoc_products @@ -521,6 +531,7 @@ AC_OUTPUT([ \ doc/salome/gui/Makefile \ doc/salome/gui/doxyfile \ doc/salome/gui/static/header.html \ + doc/docutils/Makefile \ idl/Makefile \ idl/Calcium_Ports.idl \ resources/Makefile \ @@ -549,6 +560,8 @@ AC_OUTPUT([ \ src/GenericObj/Makefile \ src/HDFPersist/Makefile \ src/KERNEL_PY/Makefile \ + src/KERNEL_PY/kernel/Makefile \ + src/KERNEL_PY/kernel/logconfig.py \ src/Launcher/Makefile \ src/LifeCycleCORBA/Makefile \ src/LifeCycleCORBA/Test/Makefile \ @@ -583,3 +596,4 @@ AC_OUTPUT([ \ src/Utils/Test/Makefile \ ]) +AC_HACK_LIBTOOL diff --git a/doc/INSTALL.txt b/doc/INSTALL.txt deleted file mode 100644 index 7c01e348c..000000000 --- a/doc/INSTALL.txt +++ /dev/null @@ -1,394 +0,0 @@ -================================================================= -Installation instructions, up to date for 3.0 version -================================================================= - -*html version of this document is produced with docutils*:: - - rst2html < doc.txt > doc.html - -*This document corresponds to SALOME2 2.2.9.* -*IT IS NOT UP TO DATE with 3.2.0* - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -You'll find here generic instructions for installing the SALOME2 platform. - -Summary -------- - -`1. Quick Overview`_ - -`2. System configuration`_ - -`3. Third-party dependencies`_ - -`4. Preparing the shell environment`_ - -`5. Installing the KERNEL component`_ - -`6. Installing the SALOME components`_ - -`7. Runtime`_ - -`8. Suggestions and advices`_ - - -1. Quick Overview ------------------ - -First of all, you have to check (or install if needed) the dependant -software programs on your system. These programs are: - -- common development tools as gcc, automake, autoconf and libtools. -- third party softwares used in SALOME building or runtime process - (python, OCC, VTK, ...) - -Further details can be found in sections [2] and [3]. - -If the dependencies are installed on your system, then you have to set -your shell environment to get access to the software components -(cf. [4]. "Preparing the shell environment"). - -The next step is to install the KERNEL (cf. [5] "Installing KERNEL"): - -:: - -$ mkdir -$ mkdir -$ cd -$ ./build_configure -$ cd -$ /configure --prefix= -$ make -$ make install - -Then, the SALOME components GEOM, MED, VISU, ... can be installed -with a similar procedure (cf. [6]). - -Eventually, the platform can be run by executing the shell script -runSalome (cf. [7]). Here, somme additionnal variables have to be set -to describe the SALOME runtime configuration (_ROOT_DIR, -OMNIORB_CONFIG) - -The following provides you with specific instructions for each step. - - -2. System configuration ------------------------ - -SALOME is compiled and tested on differents platforms with native packages: -- Debian sarge -- Mandrake 10.1 -- ... - -If you have another platform, we suggest the following configuration -for building process: - -- gcc-3.3.x or 3.4.x -- automake-1.7 or more (only aclocal is used) -- autoconf-2.59 -- libtool-1.5.6 - -remarks: - -- This is the minimum level of automake, autoconf and libtool, if you need - to compile all the third party softwares (included OpenCascade 5.2.x). - -3. Third-party dependencies ---------------------------- - -The SALOME platform relies on a set of third-party softwares. The -current version depends on the following list -(versions given here are from Debian Sarge, except OpenCascade, VTK and MED, -which are not Debian packages): - -CAS-5.2.4 OpenCascade (try binaries,a source patch is needed) -VTK-4.2.6 VTK 3D-viewer -PyQt-3.13 Python-Qt Wrapper -Python-2.3.5 Python interpreter -SWIG-1.3.24 SWIG library -boost-1_32_0 C++ library (only include templates are used) -hdf5-1.6.2 Files Database library -med-2.2.2 MED Data Format support for file records -omniORB-4.0.5 ORB used in SALOME -qt-x11-free-3.3.3 Qt library -qwt-4.2 Graph components for Qt -sip4-4.1.1 langage binding software - -And, in order to build the documentation: - -doxygen-1.4.2 -graphviz-2.2.1 - - -Additionnal software may be installed for optional features: - -netgen4.3 + patch -tix8.1.4 -openpbs-2.3.16 -lsf-??? - - - -3.1 To Do -~~~~~~~~~ -- Instructions for installing these software programs can be found in a - special note doc/configuration_examples/install-prerequis. -- Installation shell scripts are also provided. - These scripts have to be adapted to your own configuration. - -- See doc/configuration_examples/* - -In the following, we assume that all the third-party softwares are -installed in the same root directory, named /prerequis. -Then, your file system should probably look like:: - - /prerequis/Python-2.2.2 - /prerequis/omniORB-3.0.5 - /prerequis/qt-x11-free-3.0.5 - ... - - -4. Preparing the shell environment ----------------------------------- - -Some variables have to be set to get acces to third-party software -components (include files, executable, library, ...) during building -process and runtime. - -The shell file prerequis.sh, embedded in the KERNEL source package, -provides a template for setting those variables. In this example, all the -softwares are supposed to be installed in the same root directory, -named here INSTALLROOT. - -Copy the prerequis.sh in a working directory and adjust the settings -to your own configuration. To get the shell prepared, just -execute the following command in the building shell: - -$ source prerequis.sh - -(we assume here a ksh or bash mode) - - -5. Installing the KERNEL component ----------------------------------- - -We use here the notation to specify the source directory -of the KERNEL component. The shell environment is supposed to have -been set (cf. 4). - -Installing the KERNEL from a source package needs three directories: - -- the source directory, denoted here by . - -- the build directory, denoted by in the following. This - directory can't be the same directory as . - -- the install directory, denoted by in the following. This - directory can't be the same directory as or - . - -The installing process is: - -STEP 1: - preparing directories - - create the and the directories:: - - $ mkdir - $ mkdir - -STEP 2: - build configure script - - go to directory and generate the "configure" script:: - - $ cd - $ ./build_configure - - If it doesn't work, check your system automake tools as specified in - section [2]. - -STEP 3: - configure the building process - go to the build directory and execute the configuration process:: - - $ cd - $ /configure --prefix= - - Note that must be an absolute path. - - When the configure process is complete, check the status of - third-party softwares detection. You should have a status like:: - - --------------------------------------------- - Summary - --------------------------------------------- - Configure - cc : yes - boost : yes - lex_yacc : yes - python : yes - swig : yes - threads : yes - OpenGL : yes - qt : yes - vtk : yes - hdf5 : yes - med2 : yes - omniORB : yes - occ : yes - sip : yes - pyqt : yes - qwt : yes - doxygen : yes - graphviz : no - openpbs : no - lsf : no - Default ORB : omniORB - ---------------------------------------------- - -If a software get a status "no", then it's not "seen" in the system: - -- the software is not installed, or -- the shell environment is not set correctly. - -In this example, the software programs graphviz, openpbs and lsf are not -installed (optional for most usages). - - -STEP 4 : - Building the binary files - - Execute make in the directory:: - - $ make - - -STEP 5: - Installing binary files, scripts and documentation - - Execute install target in the directory:: - - $ make install - - -6. Installing the SALOME components ------------------------------------ - -TInstalling a component is done by following the same -instructions as given for the KERNEL, replacing KERNEL by - (build_configure, configure, make, make install). - -You just have to be aware of the dependencies between components: - -- MED depends on KERNEL -- GEOM depends on KERNEL -- SMESH depends on KERNEL, MED, GEOM -- VISU depends on KERNEL, MED -- SUPERV depends on KERNEL - -For example, installing the component SMESH needs the previous -installation of the KERNEL component, and then the GEOM and MED components. - -The building process uses the variables _ROOT_DIR to -localize the dependant components. The variables must be set to the -install path directory of the components (ex: -KERNEL_ROOT_DIR=). - -In the above example, the three variables KERNEL_ROOT_DIR, -GEOM_ROOT_DIR and MED_ROOT_DIR have to be set before configuring the -building process of the SMESH component (STEP 3). - - -7. Runtime ----------- - -See SALOME_Application_ to define your own configuration of SALOME and run it -on one or several computers. This is the recommended way of configuration. - -.. _SALOME_Application: ./SALOME_Application.html - -The following explains the general principles. - -To run the SALOME platform, the procedure is: - -- set the shell environment to get acces to third-party softwares:: - - $ source prerequis.sh - -- define the SALOME configuration by setting the whole set of - variables _ROOT_DIR. Here, you just have to set the - kernel and the components you need:: - - $ export KERNEL_ROOT_DIR= - $ export MED_ROOT_DIR= - $ ... - -- define the CORBA configuration file by setting the variable - OMNIORB_CONFIG. This variable must be set to a writable file - path. The file may be arbitrary chosen and doesn't need to exist - before running. We suggest:: - - $ export OMNIORB_CONFIG=$HOME/.omniORB.cfg - -- run the SALOME platform by executing the script runSalome:: - - $KERNEL_ROOT_DIR/bin/salome/runSalome - - -8. Suggestions and advices --------------------------- - -For convenience or customization, we suggest the following organisation: - -- chose and create a root directory for the SALOME platform, say - . - -- install the third-party softwares in a sub-directory "prerequis" - -- install the SALOME components in a sub-directory "SALOME2" - -- make personnal copies of the files prerequis.sh and runSalome in - :: - - $ cp /prerequis.sh /. - $ cp /bin/salome/runSalome /. - - Edit the file prerequis.sh and adjust it to your own configuration. - -- define the SALOME2 configuration - - This step consists in setting the KERNEL_ROOT_DIR, the whole set of - variables _ROOT_DIR you need, and the OMNIORB_CONFIG - variable. - - We suggest to create a shell file envSalome.sh containing those - settings. Then the configuration consists in loading envSalome.sh in - the runtime shell:: - - $ source envSalome.sh - -- When installed with this file organisation, running SALOME is done - with the following shell commands:: - - $ source /prerequis.sh - $ source /envSalome.sh - $ ./runSalome - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/KERNEL_Services.txt b/doc/KERNEL_Services.txt deleted file mode 100644 index c848838ee..000000000 --- a/doc/KERNEL_Services.txt +++ /dev/null @@ -1,305 +0,0 @@ -================================================================= -KERNEL Services for end user (Python interface) -================================================================= - -*html version of this document is produced with docutils*:: - - rst2html < doc.txt > doc.html - -This document corresponds to SALOME2 3.2.0 - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -In a SALOME application, distributed components, servers and clients use -the CORBA middleware for comunication. CORBA interfaces are defined via idl -files. All the different CORBA interfaces are available for users in Python, -see CORBA interfaces below. - -For some general purpose services, CORBA interfaces have been encapsulated -in order to provide a simple interface (encapsulation is generally done in -C++ classes, and a Python SWIG interface is also generated from C++, to -ensure a consistent behavior between C++ modules and Python modules or user -script). - -General purpose services -======================== - -SALOME services access from a Python shell ------------------------------------------- -See SALOME_Application_ for detailed instructions to launch a Python -interpreter with full acces to the SALOME environment and services. - -.. _SALOME_Application: ./SALOME_Application.txt - -You can use the embedded Python interpreter in Grahic User Interface, or an -external interpreter, with:: - - ./runSession - python - -In either cases, SALOME services access is done with:: - - import salome - salome.salome_init() - -In the embedded interpreter, it is already done, but there is no problem to -do it several times, so it is preferable to add these instructions -systematically in your scripts, to allow them to work in all configurations. - -Container and component instanciation -------------------------------------- - -See LifeCycleCORBA_ for the C++ interface (Python interface obtained with SWIG -is very similar). - -.. _LifeCycleCORBA: ./tui/KERNEL/classSALOME__LifeCycleCORBA.html - - -In the following example, a test component provided in KERNEL is launched -in the local container, "FactoryServer", created when SALOME starts:: - - import salome - salome.salome_init() - - import LifeCycleCORBA - lcc = LifeCycleCORBA.LifeCycleCORBA() - obj=lcc.FindOrLoad_Component("FactoryServer","SalomeTestComponent") - - import Engines - comp=obj._narrow(Engines.TestComponent) - - comp.Coucou(1) - -The answer is something like:: - - 'TestComponent_i : L = 1' - -The _narrow() instruction is not always mandatory in Python, but sometimes -useful to be sure you have got the right type of object. Here, Testcomponent_ -interface is defined in CORBA module Engines. With this example, it works also -without the _narrow() instruction:: - - obj.Coucou(1) - -.. _Testcomponent: ./tui/KERNEL/interfaceEngines_1_1TestComponent.html - - -In the next example, a component instance is created in a specific Container -defined by it's computer hostname and it's name. Here we use the local -computer. Note that in Utils_Identity_, getShortHostName() gives the short -hostname of the computer, without domain suffixes, which is used in SALOME. -The container process is created here if it does not exists, and a new -component instance is created:: - - import salome - salome.salome_init() - import LifeCycleCORBA - lcc = LifeCycleCORBA.LifeCycleCORBA() - - import Utils_Identity - host = Utils_Identity.getShortHostName() - - import Engines - params={} - params['hostname']=host - params['container_name']='myContainer' - comp=lcc.LoadComponent(params,'SalomeTestComponent') - comp.Coucou(1) - -.. _Utils_Identity: ./tui/KERNEL/namespaceUtils__Identity.html - -If you want to get a list of containers and component instances, client object -from orbmodule_ provides a list:: - - import orbmodule - clt=orbmodule.client() - clt.showNS() - -.. _orbmodule: ./tui/KERNEL/classorbmodule_1_1client.html - -The list looks like:: - - Logger. - ContainerManager.object - Containers.dir - cli70ac.dir - FactoryServerPy.object - SuperVisionContainer.object - FactoryServer.object - FactoryServer.dir - SalomeTestComponent_inst_1.object - myContainer.object - myContainer.dir - SalomeTestComponent_inst_1.object - SalomeTestComponent_inst_2.object - Registry.object - Kernel.dir - ModulCatalog.object - Session.object - Study.dir - Study2.object - extStudy_1.object - extStudy_2.object - extStudy_3.object - myStudyManager.object - SalomeAppEngine.object - - -File transfer service ---------------------- - -See FileTransferCORBA_ for the C++ interface (Python interface obtained with -SWIG is very similar). - -.. _FileTransferCORBA: ./tui/KERNEL/classSALOME__FileTransferCORBA.html - -The following example shows how to tranfer a file from a remote host to the -client computer. Remote hostname is 'cli76cc', we would like to copy -'tkcvs_8_0_3.tar.gz' from remote to local computer. A full pathname is -required. A container is created on remote computer if it does not exist, -to handle the file transfer:: - - import salome - salome.salome_init() - - import LifeCycleCORBA - remotefile="/home/prascle/tkcvs_8_0_3.tar.gz" - aFileTransfer=LifeCycleCORBA.SALOME_FileTransferCORBA('cli76cc',remotefile) - localFile=aFileTransfer.getLocalFile() - - -CORBA Naming service access ---------------------------- - -See SALOME_NamingService_ for the C++ interface. The Python interface -SALOME_NamingServicePy_ is not yet derived from the C++ interface and offers -only the most useful functions. - -.. _SALOME_NamingService: ./tui/KERNEL/classSALOME__NamingService.html -.. _SALOME_NamingServicePy: ./tui/KERNEL/classSALOME__NamingServicePy_1_1SALOME__NamingServicePy__i.html - -Batch services --------------- - -See Batch_ documentation (in french only). - -.. _Batch: ./Batch.html/index.html - -All IDL Interfaces -================== - -Containers and component life cycle, File transfer service ----------------------------------------------------------- - -+-----------------------------+-----------------------------------------------+ -| Engines_ | Engines CORBA module. | -+=============================+===============================================+ -| Component_ | Generic component interface. | -| | All SALOME components inherit this interface | -+-----------------------------+-----------------------------------------------+ -| Container_ | Container: host for C++ and Python components | -| | components instances | -+-----------------------------+-----------------------------------------------+ -| FileTransfer_ | Agent for file transfer created by a container| -| | copy a local file to a distent client | -+-----------------------------+-----------------------------------------------+ -| FileRef_ | Reference to a file, used by a container for | -| | file transfers | -+-----------------------------+-----------------------------------------------+ -| ContainerManager_ | Unique instance, in charge of container | -| | creation on remote computers | -+-----------------------------+-----------------------------------------------+ -| MPIContainer_ | An exemple of parallel implementation for | -| | containers and components | -+-----------------------------+-----------------------------------------------+ -| MPIObject_ | | -+-----------------------------+-----------------------------------------------+ - -Study management ----------------- - -+-----------------------------+-----------------------------------------------+ -| SALOMEDS_ | SALOMEDS CORBA module | -+=============================+===============================================+ -| SALOMEDSidl_ | | -+-----------------------------+-----------------------------------------------+ -| SALOMEDS_Attributes_ | | -+-----------------------------+-----------------------------------------------+ - -High speed transfer, object life cycle, exceptions, GUI interface... --------------------------------------------------------------------- - -+-----------------------------+-----------------------------------------------+ -| SALOME_ | SALOME CORBA module | -+=============================+===============================================+ -| SALOME_Comm_ | | -+-----------------------------+-----------------------------------------------+ -| SALOME_GenericObj_ | | -+-----------------------------+-----------------------------------------------+ -| SALOME_Exception_ | | -+-----------------------------+-----------------------------------------------+ -| SALOME_Session_ | | -+-----------------------------+-----------------------------------------------+ - -Miscelleanous -------------- -+-----------------------------+-----------------------------------------------+ -| | other CORBA modules | -+=============================+===============================================+ -| SALOME_ModuleCatalog_ | | -+-----------------------------+-----------------------------------------------+ -| SALOME_RessourcesCatalog_ | | -+-----------------------------+-----------------------------------------------+ -| SALOME_Registry_ | | -+-----------------------------+-----------------------------------------------+ -| Logger_ | | -+-----------------------------+-----------------------------------------------+ - -**Other idl for test purposes** -nstest.idl -SALOME_TestComponent.idl -SALOME_TestModuleCatalog.idl -SALOME_TestMPIComponent.idl -TestNotif.idl - -.. _Engines: ./tui/KERNEL/namespaceEngines.html -.. _Component: ./tui/KERNEL/interfaceEngines_1_1Component.html -.. _Container: ./tui/KERNEL/interfaceEngines_1_1Container.html -.. _fileTransfer: ./tui/KERNEL/interfaceEngines_1_1fileTransfer.html -.. _fileRef: ./tui/KERNEL/interfaceEngines_1_1fileRef.html -.. _ContainerManager: ./tui/KERNEL/interfaceEngines_1_1ContainerManager.html -.. _MPIContainer: ./tui/KERNEL/interfaceEngines_1_1MPIContainer.html -.. _MPIObject: ./tui/KERNEL/interfaceEngines_1_1MPIObject.html -.. _SALOME: ./tui/KERNEL/namespaceSALOME.html -.. _SALOMEDS: ./tui/KERNEL/namespaceSALOMEDS.html -.. _SALOME_Component: ./tui/KERNEL/SALOME__Component_8idl.html -.. _SALOME_ContainerManager: ./tui/KERNEL/SALOME__ContainerManager_8idl.html -.. _SALOMEDSidl: ./tui/KERNEL/SALOMEDS_8idl.html -.. _SALOMEDS_Attributes: ./tui/KERNEL/SALOMEDS__Attributes_8idl.html -.. _SALOME_ModuleCatalog: ./tui/KERNEL/SALOME__ModuleCatalog_8idl.html -.. _SALOME_RessourcesCatalog: ./tui/KERNEL/SALOME__RessourcesCatalog_8idl.html -.. _SALOME_Registry: ./tui/KERNEL/SALOME__Registry_8idl.html -.. _Logger: ./tui/KERNEL/Logger_8idl.html -.. _SALOME_Comm: ./tui/KERNEL/SALOME__Comm_8idl.html -.. _SALOME_GenericObj: ./tui/KERNEL/SALOME__GenericObj_8idl.html -.. _SALOME_Exception: ./tui/KERNEL/SALOME__Exception_8idl.html -.. _SALOME_Session: ./tui/KERNEL/SALOME__Session_8idl.html -.. _SALOME_MPIContainer: ./tui/KERNEL/SALOME__MPIContainer_8idl.html -.. _SALOME_MPIObject: ./tui/KERNEL/SALOME__MPIObject_8idl.html - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/Makefile.am b/doc/Makefile.am index fbcc8b5ed..91eeee484 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -27,7 +27,7 @@ # include $(top_srcdir)/salome_adm/unix/make_common_starter.am -SUBDIRS = salome +SUBDIRS = salome docutils docs: usr_docs diff --git a/doc/SALOME_Application.txt b/doc/SALOME_Application.txt deleted file mode 100644 index 0abcaed1e..000000000 --- a/doc/SALOME_Application.txt +++ /dev/null @@ -1,353 +0,0 @@ -====================================================================== -SALOME Application Concept. Configuration for one or more computers -====================================================================== - -*html version of this document is produced with docutils*:: - - rst2html doc.txt > doc.html - -This document corresponds to SALOME2 3.2.0 - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -The following explains how to configure your own application with your list of -modules, how to define and run this application on one or more computers. - -General principles ------------------- - -A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...). - -A SALOME User can define several SALOME Applications. These applications are -runnable from the same user account. These applications may share the same -KERNEL and modules. Thus, the application configuration is independant of -KERNEL and must not be put in KERNEL_ROOT_DIR. - -Furthermore, prerequisites may not be the same on all the applications. - -A SALOME Session can run on a several computers. - -Binary modules and prerequisites are installed on the different computers. -There is no need to have all the modules on each computer (the minimum is -KERNEL). - -There is no need of standardization or centralised information on the details -of configuration on each computer (PATH, LD_LIBRARY_PATH, environment -variables) provided the application modules are version - compatible. Details -of configuration stay private to the computer, and are held by scripts on each -computer. - -There is no hierarchy between the computers (for example only one master -computer used to launch application). - -The SALOME user has an account on all the computers. Access between -account@computer is via rsh or ssh and must be configured for use without -password (key exchange for ssh). Account may be different on each -computer. - -Application Directory ---------------------- - -Two ways for creation of an application directory -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -First way - references to different module directories -'''''''''''''''''''''''''''''''''''''''''''''''''''''' - -The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an -application directory with the given path in parameter. ${APPLI} is a path -relative to ${HOME}. - -The directory is only a skeleton, the user has to edit several files to -configure his own application. These files are described after, the list is: - -- env.d/atFirst.sh -- env.d/envProducts.sh -- env.d/envSalome.sh -- CatalogResources.xml -- SalomeApp.xml - -Second and easiest way - one single virtual install directory -''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -The user must create a SALOME application configuration file by modifying a -copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml. -The file describes the list of SALOME modules used in the application, with -their respective installation path. The configuration file also defines the -path of an existing script which sets the SALOME prerequisites, -and optionnaly, the path of samples directory (SAMPLES_SRC). -The following command:: - - python /bin/salome/appli_gen.py --prefix= --config= - -creates a virtual installation of SALOME in the application directory ${APPLI} -(bin, lib, doc, share...), with, for each file (executable, script, data, -library, resources...), symbolic links to the actual file. - -Providing an existing an existing script for SALOME prerequisites (the same one -used for modules compilation, or given with the modules installation), the -installation works without further modification for a single computer (unless -some modules needs a special environment not defined in the above script). -For a distributed application (several computers), one must copy and adapt -CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below). - -General rules -------------- - -Directory ${APPLI} must be created on each computer of the application. -The easiest way is to use the same relative path (to ${HOME}) on each computer. -(Sometimes it is not possible to use the same path everywhere, for instance -when ${HOME} is shared with NFS, so it is possible to define different path -following the computers). - -The ${APPLI} directory contains scripts for environment and runs. Environment -scripts must be configured (by the user) on each computer. All the environment -scripts are in the ${APPLI}/env.d directory. - -The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d -in alphanumeric order (after edition, think to remove backup files). the envd -script is used by run scripts. - - -env.d scripts -~~~~~~~~~~~~~ -With the first way of installation, each user **must define** his own -configuration for these scripts, following the above rules. -With the virtual installation (second way, above), env.d -scripts are built automatically. - - **The following is only an example proposed by createAppli.sh, (first way of installation) not working as it is**. - -atFirst.sh - Sets the computer configuration not directly related to SALOME, - like useful tools, default PATH. - -envProducts.sh - Sets the SALOME prerequisites. - -envSALOME.sh - Sets all the MODULE_ROOT_DIR that can be used in the SALOME application. - - SalomeAppConfig is also defined by:: - - export SalomeAppConfig=${HOME}/${APPLI} - - where SalomeAppConfig designates the directory containing SalomeApp.xml. - Note that ${APPLI} is already defined by the calling scripts when - env.d/envSalome.sh is sourced. - -User run scripts -~~~~~~~~~~~~~~~~ - -The SALOME user can use 4 scripts: - -runAppli - Launches a SALOME Session - (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different - name to avoid confusions). - -runSession - Launches a shell script in the SALOME application environment, with access - to the current (last launched) SALOME session (naming service), if any. - Without arguments, the script is interactive. With arguments, the script - executes the command in the SALOME application environment. - -runConsole - Gives a python console connected to the current SALOME Session. - It is also possible to use runSession, then python. - -runTests - Similar to runSession, used for unit testing. runSession tries to use an - already existing naming service definition from a running session (hostname - and port number), runTests defines a new configuration for naming service - (new port number). - -SALOME internal run scripts -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -envd - Sets SALOME application environment, envd is sourced by other scripts. - -For remote calls, SALOME uses one script. - -runRemote.sh - This script is mainly used to launch containers. The first 2 arguments - define the hostname and port userd for naming service, the remaining - arguments define the command to execute. - -Other configuration files -~~~~~~~~~~~~~~~~~~~~~~~~~ - -SalomeApp.xml - This file is similar to the default given - in ${GUI_ROOT_DIR}/share/salome/resources/gui - - -CatalogRessources.xml - This files describes all the computers the application can use. The given - example is minimal and suppose ${APPLI} is the same relative path - to ${HOME}, on all the computers. A different directory can be set on a - particular computer with a line:: - - appliPath="my/specific/path/on/this/computer" - - -Examples of use ---------------- - -Launch a SALOME session with a GUI interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Launch is done with a command like:: - - ./runAppli --logger - -The --logger option means here : collect all the traces from the all the -distributed process, via CORBA, in a single file : logger.log. - -There are a lot of options, a complete list is given by:: - - ./runAppli --help - -Note that, without argument, runAppli is a non interactive Python application, -and, with arguments, runAppli is an interactive Python interpreter. - -Several options are already defined by default in SalomeApp.xml files. Optional -arguments given in the command override the SalomeApp.xml configuration. - -Several sessions can run simultaneously, each session use a different port for -CORBA naming service, so the sessions are totally separated from each other. - -When the GUI is closed, the different SALOME servers are still running. - -Close a SALOME session, kill all the servers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Inside the interactive python interpreter you get when you use runAppli -with arguments, you can kill all the servers of your session with:: - - >>> killLocalPort() - -or the servers of all the sessions with:: - - >>> killAllPorts() - -If you have no active Python interpreter connected to your session, you can -kill all the SALOME servers of **all the sessions** on a given computer:: - - ./runSession killSalome.py - -Remember! it's the same idea in *Windows (R) operating system* [#]_ : -use the start menu to stop... - -When you use only one session at a time, you don't need more. - -To kill a given session (when several session are running), one needs -the naming service port number:: - - ./runSession killSalomeWithPort 2810 - -Note that the port number of the last launched session can be found on Linux, -in the prompt, within a runSession shell (see below). - -It is also possible to get the Naming Service host and port number of -the last launched session with:: - - ./runSession NSparam.py - -.. [#] Microsoft and Windows are either registered trademarks or trademarks of - Microsoft Corporation in the United States and/or other countries. - -Launch a SALOME session without GUI interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This is used to launch a SALOME Python script without GUI -(no GUI server = SALOME_session_server) - -Example of script (test_session_geom.py):: - - import salome_session - salome_session.startSession(modules=["GEOM"]) - import GEOM_usinggeom - raw_input("Press a key and the servers will be killed ...") - -This script is run in a non interactive way with:: - - ./runSession python test_session_geom.py - -All the process are automatically killed when Python is closed -(with salome_session delete). - -Add an external Python interpretor to a running session -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It's often easier to develop and try Python scripts outside the GUI embedded -Python interpreter. Imagine, for instance, you are writing a script involving -geometry and mesh modules. -first, launch a SALOME session with gui, then, on another terminal:: - - ./runSession - python - -Import salome module. salome_init() without arguments creates a new study -in the running session (note: salome_init(n) attachs to a running session whose -studyId is n):: - - import salome - salome.salome_init() - -An example of script given with SMESH:: - - import ex01_cube2build - -It is possible to connect the GUI interface to the study created in the above -script with the file/connect menu, then browse study and display objects. -Further modifications on study can be done either with GUI or external script -(use refresh popup in GUI object browser to see study modifications generated -by the external script). **AVOID modifications with GUI when a Python script -is running**. Not all the modules are protected against concurrent actions... - - -Different uses of the runSession shell interpreter -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -runSession invoked without arguments gives an interactive shell with the full -environment of SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables). -If there are running sessions of the same SALOME application, runSession -connects to the last launched session (i.e. gets the naming service references -of the session: hostname and port) - -On Linux, the shell prompt (bash) gives information on naming service -references, hostname and port:: - - [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$ - -If there is no running session, prompt looks like:: - - [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$ - -runSession is useful to launch any script or program which needs the complete -SALOME environment, with or without a session already running. -For instance, to launch the ddd debugger interface on the gui server, first -launch a SALOME session with gui, then, on another terminal:: - - ./runSession ddd - -Then attach to the running SALOME_Session_Server process. - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/UnitTests.txt b/doc/UnitTests.txt deleted file mode 100644 index 987db0ec1..000000000 --- a/doc/UnitTests.txt +++ /dev/null @@ -1,217 +0,0 @@ -================================================================= -Source code structuration and Unit Tests -================================================================= - -*html version of this document is produced with docutils*:: - - rst2html < doc.txt > doc.html - -*This document corresponds to SALOME2 3.2.0* - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -You will find here general information on code directories structure, -unit tests associated to the different kind of classes, and how to run -the unit tests. - -SALOME KERNEL source code structuration -======================================= - -General structure of KERNEL_SRC -------------------------------- - -KERNEL_SRC - Some README files and configuration tools for build - -KERNEL_SRC/adm_local - Part of the configuration files, other modules have a directory with the - same name. Not used in KERNEL. - -KERNEL_SRC/bin - Python and shell scripts used at run time. - Kit to install a SALOME Application. - -KERNEL_SRC/doc - Kit for KERNEL end user documentation production: - public interfaces, Python, CORBA. - Integrator and Developper documentation. - -KERNEL_SRC/idl - All CORBA interfaces from KERNEL are regrouped here. - -KERNEL_SRC/resources - Configuration files for servers (examples). - Interfaces definitions for KERNEL test components. - -KERNEL_SRC/salome_adm - Configuration files used by autotools (M4 macros & co.) - -KERNEL_SRC/src - The source code (C++ and Python) - - -Directory src: C++ and Python source code ------------------------------------------ - -Basic services non related to CORBA -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Basics - A set of general purpose C++ services, not related to CORBA. - Some general purpose services that are in Utils directory (CORBA related), - are progressivley moved here, as they are not related to CORBA. - - -SALOMELocalTrace - A multithread trace system that allows message tracing on standard error - or a file. - -CASCatch - Exceptions and signal handler. - -HDFPersist - A C++ interface to HDF. - -Basic CORBA services -~~~~~~~~~~~~~~~~~~~~ - -Logger - A CORBA server that collects the trace messages from differents CORBA - process. - -SALOMETraceCollector - A multithread trace system derived from SALOMELocalTrace, that sends messages - to Logger server via CORBA. - -Utils - A set of general purpose services related to CORBA, such as basic CORBA - exception system. See also Basics directory above. - -NamingService - C++ and Python interfaces to name, store and retrieve CORBA objects - -GenericObj - A generic CORBA interface for CORBA objects, to count distributed references, - and to allow destruction by client. - -Miscellaneous CORBA servers -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Registry - Implements SALOME_registry.idl. - Provides a CORBA server library and a separate server program. - -ModuleCatalog - Implements SALOME_moduleCatalog.idl. - Provide a CORBA server library and separate server and client programs. - -ModuleGenerator - Tool to generate a module catalog from CORBA idl - -ResourcesManager - library included in container server - -Notification - library included in differents servers (container) - -NOTIFICATION_SWIG - - -CORBA Containers for SALOME Modules -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Container - -TestContainer - -LifeCycleCORBA - -LifeCycleCORBA_SWIG - -STUDY server and related interfaces and tools -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -SALOMEDSClient - -TOOLSDS - -SALOMEDSImpl - -SALOMEDS - -Python interface to SALOME -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -KERNEL_PY - -Efficient CORBA transfer services -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Communication - -Communication_SWIG - -A Parallel container with MPI -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -MPIContainer - -TestMPIContainer - -Batch interface library -~~~~~~~~~~~~~~~~~~~~~~~ - -Batch - -Batch_SWIG - -Unit tests -~~~~~~~~~~ - -UnitTests - - -Tools and principles used for Unit testing -========================================== - -**TO BE COMPLETED** - -Unit Testing rely on cppunit package for C++ testing, and on unittest module -for Python. See these products for general principles of unit testing. - -The cppunit package is optional. When the prerequisite is detected, the unit -tests are compiled. - -Unit Tests sources are in directories Test under the src/directories -containing the classes to test. - -Test are ordered following the order of directories given above. - -Tests can be run as a whole, or for a particular directory. In this case, only -a partial test is run (the classes to test, and the classes used, i.e. the -preceding test directories). - - -Today, only some tests are written as an example. There are not yet python -scripts in KERNEL_SRC, but it's a matter of days, there are working scripts -to test LifeCycleCORBA_SWIG interface. - - - - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/Makefile.am b/doc/docutils/Makefile.am new file mode 100644 index 000000000..1168cba51 --- /dev/null +++ b/doc/docutils/Makefile.am @@ -0,0 +1,93 @@ +# -*- coding: iso-8859-1 -*- +# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +# +# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, +# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS +# +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License. +# +# This library 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 +# Lesser General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# +# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com + +include $(top_srcdir)/salome_adm/unix/make_common_starter.am + +pydocdir = $(docdir)/tui/KERNEL/docutils + +.PHONY : latex + +if SPHINX_IS_OK + +pydoc_DATA=html/index.html +html/index.html:$(RSTFILES) + make htm + +endif + +EXTRA_DIST= html + +SPHINXOPTS = +SOURCEDIR = $(srcdir) +SPHINXBUILD = sphinx-build +PAPEROPT_a4 = -D latex_paper_size=a4 +ALLSPHINXOPTS = -d doctrees $(PAPEROPT_a4) $(SPHINXOPTS) $(SOURCEDIR) + +SPHINX_PYTHONPATH = $(prefix)/lib/python$(PYTHON_VERSION)/site-packages/salome:$(KERNEL_ROOT_DIR)/bin/salome:$(OMNIORB_ROOT)/lib/python$(PYTHON_VERSION)/site-packages + +SPHINX_LD_LIBRARY_PATH = $(OMNIORB_ROOT)/lib + +htm: + mkdir -p html doctrees + PYTHONPATH=$(SPHINX_PYTHONPATH):${PYTHONPATH}; \ + LD_LIBRARY_PATH=$(SPHINX_LD_LIBRARY_PATH):${LD_LIBRARY_PATH}; \ + $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) html + @echo + @echo "Build finished. The HTML pages are in html." + +latex: + mkdir -p latex doctrees + PYTHONPATH=$(SPHINX_PYTHONPATH):${PYTHONPATH}; \ + LD_LIBRARY_PATH=$(SPHINX_LD_LIBRARY_PATH):${LD_LIBRARY_PATH}; \ + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) latex + @echo + @echo "Build finished; the LaTeX files are in latex." + @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \ + "run these through (pdf)latex." + +html: + mkdir -p $@ + +RSTFILES= \ + index.rst \ + overview.rst \ + docapi.rst \ + salomepypkg.rst + +EXTRA_DIST+= $(RSTFILES) + +EXTRA_DIST+= \ + conf.py + +install-data-local: + $(INSTALL) -d $(pydocdir) + if test -d "html"; then b=; else b="$(srcdir)/"; fi; \ + cp -rf $$b"html"/* $(pydocdir) ; \ + if test -f $$b"latex"/kernelpy.pdf; then cp -f $$b"latex"/kernelpy.pdf $(pydocdir) ; fi; + +uninstall-local: + chmod -R +w $(pydocdir) + rm -rf $(pydocdir)/* + +clean-local: + -rm -rf html latex doctrees + if test -d "html"; then rm -rf html ; fi diff --git a/doc/docutils/archives/INSTALL.txt b/doc/docutils/archives/INSTALL.txt new file mode 100644 index 000000000..7c01e348c --- /dev/null +++ b/doc/docutils/archives/INSTALL.txt @@ -0,0 +1,394 @@ +================================================================= +Installation instructions, up to date for 3.0 version +================================================================= + +*html version of this document is produced with docutils*:: + + rst2html < doc.txt > doc.html + +*This document corresponds to SALOME2 2.2.9.* +*IT IS NOT UP TO DATE with 3.2.0* + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +You'll find here generic instructions for installing the SALOME2 platform. + +Summary +------- + +`1. Quick Overview`_ + +`2. System configuration`_ + +`3. Third-party dependencies`_ + +`4. Preparing the shell environment`_ + +`5. Installing the KERNEL component`_ + +`6. Installing the SALOME components`_ + +`7. Runtime`_ + +`8. Suggestions and advices`_ + + +1. Quick Overview +----------------- + +First of all, you have to check (or install if needed) the dependant +software programs on your system. These programs are: + +- common development tools as gcc, automake, autoconf and libtools. +- third party softwares used in SALOME building or runtime process + (python, OCC, VTK, ...) + +Further details can be found in sections [2] and [3]. + +If the dependencies are installed on your system, then you have to set +your shell environment to get access to the software components +(cf. [4]. "Preparing the shell environment"). + +The next step is to install the KERNEL (cf. [5] "Installing KERNEL"): + +:: + +$ mkdir +$ mkdir +$ cd +$ ./build_configure +$ cd +$ /configure --prefix= +$ make +$ make install + +Then, the SALOME components GEOM, MED, VISU, ... can be installed +with a similar procedure (cf. [6]). + +Eventually, the platform can be run by executing the shell script +runSalome (cf. [7]). Here, somme additionnal variables have to be set +to describe the SALOME runtime configuration (_ROOT_DIR, +OMNIORB_CONFIG) + +The following provides you with specific instructions for each step. + + +2. System configuration +----------------------- + +SALOME is compiled and tested on differents platforms with native packages: +- Debian sarge +- Mandrake 10.1 +- ... + +If you have another platform, we suggest the following configuration +for building process: + +- gcc-3.3.x or 3.4.x +- automake-1.7 or more (only aclocal is used) +- autoconf-2.59 +- libtool-1.5.6 + +remarks: + +- This is the minimum level of automake, autoconf and libtool, if you need + to compile all the third party softwares (included OpenCascade 5.2.x). + +3. Third-party dependencies +--------------------------- + +The SALOME platform relies on a set of third-party softwares. The +current version depends on the following list +(versions given here are from Debian Sarge, except OpenCascade, VTK and MED, +which are not Debian packages): + +CAS-5.2.4 OpenCascade (try binaries,a source patch is needed) +VTK-4.2.6 VTK 3D-viewer +PyQt-3.13 Python-Qt Wrapper +Python-2.3.5 Python interpreter +SWIG-1.3.24 SWIG library +boost-1_32_0 C++ library (only include templates are used) +hdf5-1.6.2 Files Database library +med-2.2.2 MED Data Format support for file records +omniORB-4.0.5 ORB used in SALOME +qt-x11-free-3.3.3 Qt library +qwt-4.2 Graph components for Qt +sip4-4.1.1 langage binding software + +And, in order to build the documentation: + +doxygen-1.4.2 +graphviz-2.2.1 + + +Additionnal software may be installed for optional features: + +netgen4.3 + patch +tix8.1.4 +openpbs-2.3.16 +lsf-??? + + + +3.1 To Do +~~~~~~~~~ +- Instructions for installing these software programs can be found in a + special note doc/configuration_examples/install-prerequis. +- Installation shell scripts are also provided. + These scripts have to be adapted to your own configuration. + +- See doc/configuration_examples/* + +In the following, we assume that all the third-party softwares are +installed in the same root directory, named /prerequis. +Then, your file system should probably look like:: + + /prerequis/Python-2.2.2 + /prerequis/omniORB-3.0.5 + /prerequis/qt-x11-free-3.0.5 + ... + + +4. Preparing the shell environment +---------------------------------- + +Some variables have to be set to get acces to third-party software +components (include files, executable, library, ...) during building +process and runtime. + +The shell file prerequis.sh, embedded in the KERNEL source package, +provides a template for setting those variables. In this example, all the +softwares are supposed to be installed in the same root directory, +named here INSTALLROOT. + +Copy the prerequis.sh in a working directory and adjust the settings +to your own configuration. To get the shell prepared, just +execute the following command in the building shell: + +$ source prerequis.sh + +(we assume here a ksh or bash mode) + + +5. Installing the KERNEL component +---------------------------------- + +We use here the notation to specify the source directory +of the KERNEL component. The shell environment is supposed to have +been set (cf. 4). + +Installing the KERNEL from a source package needs three directories: + +- the source directory, denoted here by . + +- the build directory, denoted by in the following. This + directory can't be the same directory as . + +- the install directory, denoted by in the following. This + directory can't be the same directory as or + . + +The installing process is: + +STEP 1: + preparing directories + + create the and the directories:: + + $ mkdir + $ mkdir + +STEP 2: + build configure script + + go to directory and generate the "configure" script:: + + $ cd + $ ./build_configure + + If it doesn't work, check your system automake tools as specified in + section [2]. + +STEP 3: + configure the building process + go to the build directory and execute the configuration process:: + + $ cd + $ /configure --prefix= + + Note that must be an absolute path. + + When the configure process is complete, check the status of + third-party softwares detection. You should have a status like:: + + --------------------------------------------- + Summary + --------------------------------------------- + Configure + cc : yes + boost : yes + lex_yacc : yes + python : yes + swig : yes + threads : yes + OpenGL : yes + qt : yes + vtk : yes + hdf5 : yes + med2 : yes + omniORB : yes + occ : yes + sip : yes + pyqt : yes + qwt : yes + doxygen : yes + graphviz : no + openpbs : no + lsf : no + Default ORB : omniORB + ---------------------------------------------- + +If a software get a status "no", then it's not "seen" in the system: + +- the software is not installed, or +- the shell environment is not set correctly. + +In this example, the software programs graphviz, openpbs and lsf are not +installed (optional for most usages). + + +STEP 4 : + Building the binary files + + Execute make in the directory:: + + $ make + + +STEP 5: + Installing binary files, scripts and documentation + + Execute install target in the directory:: + + $ make install + + +6. Installing the SALOME components +----------------------------------- + +TInstalling a component is done by following the same +instructions as given for the KERNEL, replacing KERNEL by + (build_configure, configure, make, make install). + +You just have to be aware of the dependencies between components: + +- MED depends on KERNEL +- GEOM depends on KERNEL +- SMESH depends on KERNEL, MED, GEOM +- VISU depends on KERNEL, MED +- SUPERV depends on KERNEL + +For example, installing the component SMESH needs the previous +installation of the KERNEL component, and then the GEOM and MED components. + +The building process uses the variables _ROOT_DIR to +localize the dependant components. The variables must be set to the +install path directory of the components (ex: +KERNEL_ROOT_DIR=). + +In the above example, the three variables KERNEL_ROOT_DIR, +GEOM_ROOT_DIR and MED_ROOT_DIR have to be set before configuring the +building process of the SMESH component (STEP 3). + + +7. Runtime +---------- + +See SALOME_Application_ to define your own configuration of SALOME and run it +on one or several computers. This is the recommended way of configuration. + +.. _SALOME_Application: ./SALOME_Application.html + +The following explains the general principles. + +To run the SALOME platform, the procedure is: + +- set the shell environment to get acces to third-party softwares:: + + $ source prerequis.sh + +- define the SALOME configuration by setting the whole set of + variables _ROOT_DIR. Here, you just have to set the + kernel and the components you need:: + + $ export KERNEL_ROOT_DIR= + $ export MED_ROOT_DIR= + $ ... + +- define the CORBA configuration file by setting the variable + OMNIORB_CONFIG. This variable must be set to a writable file + path. The file may be arbitrary chosen and doesn't need to exist + before running. We suggest:: + + $ export OMNIORB_CONFIG=$HOME/.omniORB.cfg + +- run the SALOME platform by executing the script runSalome:: + + $KERNEL_ROOT_DIR/bin/salome/runSalome + + +8. Suggestions and advices +-------------------------- + +For convenience or customization, we suggest the following organisation: + +- chose and create a root directory for the SALOME platform, say + . + +- install the third-party softwares in a sub-directory "prerequis" + +- install the SALOME components in a sub-directory "SALOME2" + +- make personnal copies of the files prerequis.sh and runSalome in + :: + + $ cp /prerequis.sh /. + $ cp /bin/salome/runSalome /. + + Edit the file prerequis.sh and adjust it to your own configuration. + +- define the SALOME2 configuration + + This step consists in setting the KERNEL_ROOT_DIR, the whole set of + variables _ROOT_DIR you need, and the OMNIORB_CONFIG + variable. + + We suggest to create a shell file envSalome.sh containing those + settings. Then the configuration consists in loading envSalome.sh in + the runtime shell:: + + $ source envSalome.sh + +- When installed with this file organisation, running SALOME is done + with the following shell commands:: + + $ source /prerequis.sh + $ source /envSalome.sh + $ ./runSalome + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/KERNEL_Services.txt b/doc/docutils/archives/KERNEL_Services.txt new file mode 100644 index 000000000..c848838ee --- /dev/null +++ b/doc/docutils/archives/KERNEL_Services.txt @@ -0,0 +1,305 @@ +================================================================= +KERNEL Services for end user (Python interface) +================================================================= + +*html version of this document is produced with docutils*:: + + rst2html < doc.txt > doc.html + +This document corresponds to SALOME2 3.2.0 + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +In a SALOME application, distributed components, servers and clients use +the CORBA middleware for comunication. CORBA interfaces are defined via idl +files. All the different CORBA interfaces are available for users in Python, +see CORBA interfaces below. + +For some general purpose services, CORBA interfaces have been encapsulated +in order to provide a simple interface (encapsulation is generally done in +C++ classes, and a Python SWIG interface is also generated from C++, to +ensure a consistent behavior between C++ modules and Python modules or user +script). + +General purpose services +======================== + +SALOME services access from a Python shell +------------------------------------------ +See SALOME_Application_ for detailed instructions to launch a Python +interpreter with full acces to the SALOME environment and services. + +.. _SALOME_Application: ./SALOME_Application.txt + +You can use the embedded Python interpreter in Grahic User Interface, or an +external interpreter, with:: + + ./runSession + python + +In either cases, SALOME services access is done with:: + + import salome + salome.salome_init() + +In the embedded interpreter, it is already done, but there is no problem to +do it several times, so it is preferable to add these instructions +systematically in your scripts, to allow them to work in all configurations. + +Container and component instanciation +------------------------------------- + +See LifeCycleCORBA_ for the C++ interface (Python interface obtained with SWIG +is very similar). + +.. _LifeCycleCORBA: ./tui/KERNEL/classSALOME__LifeCycleCORBA.html + + +In the following example, a test component provided in KERNEL is launched +in the local container, "FactoryServer", created when SALOME starts:: + + import salome + salome.salome_init() + + import LifeCycleCORBA + lcc = LifeCycleCORBA.LifeCycleCORBA() + obj=lcc.FindOrLoad_Component("FactoryServer","SalomeTestComponent") + + import Engines + comp=obj._narrow(Engines.TestComponent) + + comp.Coucou(1) + +The answer is something like:: + + 'TestComponent_i : L = 1' + +The _narrow() instruction is not always mandatory in Python, but sometimes +useful to be sure you have got the right type of object. Here, Testcomponent_ +interface is defined in CORBA module Engines. With this example, it works also +without the _narrow() instruction:: + + obj.Coucou(1) + +.. _Testcomponent: ./tui/KERNEL/interfaceEngines_1_1TestComponent.html + + +In the next example, a component instance is created in a specific Container +defined by it's computer hostname and it's name. Here we use the local +computer. Note that in Utils_Identity_, getShortHostName() gives the short +hostname of the computer, without domain suffixes, which is used in SALOME. +The container process is created here if it does not exists, and a new +component instance is created:: + + import salome + salome.salome_init() + import LifeCycleCORBA + lcc = LifeCycleCORBA.LifeCycleCORBA() + + import Utils_Identity + host = Utils_Identity.getShortHostName() + + import Engines + params={} + params['hostname']=host + params['container_name']='myContainer' + comp=lcc.LoadComponent(params,'SalomeTestComponent') + comp.Coucou(1) + +.. _Utils_Identity: ./tui/KERNEL/namespaceUtils__Identity.html + +If you want to get a list of containers and component instances, client object +from orbmodule_ provides a list:: + + import orbmodule + clt=orbmodule.client() + clt.showNS() + +.. _orbmodule: ./tui/KERNEL/classorbmodule_1_1client.html + +The list looks like:: + + Logger. + ContainerManager.object + Containers.dir + cli70ac.dir + FactoryServerPy.object + SuperVisionContainer.object + FactoryServer.object + FactoryServer.dir + SalomeTestComponent_inst_1.object + myContainer.object + myContainer.dir + SalomeTestComponent_inst_1.object + SalomeTestComponent_inst_2.object + Registry.object + Kernel.dir + ModulCatalog.object + Session.object + Study.dir + Study2.object + extStudy_1.object + extStudy_2.object + extStudy_3.object + myStudyManager.object + SalomeAppEngine.object + + +File transfer service +--------------------- + +See FileTransferCORBA_ for the C++ interface (Python interface obtained with +SWIG is very similar). + +.. _FileTransferCORBA: ./tui/KERNEL/classSALOME__FileTransferCORBA.html + +The following example shows how to tranfer a file from a remote host to the +client computer. Remote hostname is 'cli76cc', we would like to copy +'tkcvs_8_0_3.tar.gz' from remote to local computer. A full pathname is +required. A container is created on remote computer if it does not exist, +to handle the file transfer:: + + import salome + salome.salome_init() + + import LifeCycleCORBA + remotefile="/home/prascle/tkcvs_8_0_3.tar.gz" + aFileTransfer=LifeCycleCORBA.SALOME_FileTransferCORBA('cli76cc',remotefile) + localFile=aFileTransfer.getLocalFile() + + +CORBA Naming service access +--------------------------- + +See SALOME_NamingService_ for the C++ interface. The Python interface +SALOME_NamingServicePy_ is not yet derived from the C++ interface and offers +only the most useful functions. + +.. _SALOME_NamingService: ./tui/KERNEL/classSALOME__NamingService.html +.. _SALOME_NamingServicePy: ./tui/KERNEL/classSALOME__NamingServicePy_1_1SALOME__NamingServicePy__i.html + +Batch services +-------------- + +See Batch_ documentation (in french only). + +.. _Batch: ./Batch.html/index.html + +All IDL Interfaces +================== + +Containers and component life cycle, File transfer service +---------------------------------------------------------- + ++-----------------------------+-----------------------------------------------+ +| Engines_ | Engines CORBA module. | ++=============================+===============================================+ +| Component_ | Generic component interface. | +| | All SALOME components inherit this interface | ++-----------------------------+-----------------------------------------------+ +| Container_ | Container: host for C++ and Python components | +| | components instances | ++-----------------------------+-----------------------------------------------+ +| FileTransfer_ | Agent for file transfer created by a container| +| | copy a local file to a distent client | ++-----------------------------+-----------------------------------------------+ +| FileRef_ | Reference to a file, used by a container for | +| | file transfers | ++-----------------------------+-----------------------------------------------+ +| ContainerManager_ | Unique instance, in charge of container | +| | creation on remote computers | ++-----------------------------+-----------------------------------------------+ +| MPIContainer_ | An exemple of parallel implementation for | +| | containers and components | ++-----------------------------+-----------------------------------------------+ +| MPIObject_ | | ++-----------------------------+-----------------------------------------------+ + +Study management +---------------- + ++-----------------------------+-----------------------------------------------+ +| SALOMEDS_ | SALOMEDS CORBA module | ++=============================+===============================================+ +| SALOMEDSidl_ | | ++-----------------------------+-----------------------------------------------+ +| SALOMEDS_Attributes_ | | ++-----------------------------+-----------------------------------------------+ + +High speed transfer, object life cycle, exceptions, GUI interface... +-------------------------------------------------------------------- + ++-----------------------------+-----------------------------------------------+ +| SALOME_ | SALOME CORBA module | ++=============================+===============================================+ +| SALOME_Comm_ | | ++-----------------------------+-----------------------------------------------+ +| SALOME_GenericObj_ | | ++-----------------------------+-----------------------------------------------+ +| SALOME_Exception_ | | ++-----------------------------+-----------------------------------------------+ +| SALOME_Session_ | | ++-----------------------------+-----------------------------------------------+ + +Miscelleanous +------------- ++-----------------------------+-----------------------------------------------+ +| | other CORBA modules | ++=============================+===============================================+ +| SALOME_ModuleCatalog_ | | ++-----------------------------+-----------------------------------------------+ +| SALOME_RessourcesCatalog_ | | ++-----------------------------+-----------------------------------------------+ +| SALOME_Registry_ | | ++-----------------------------+-----------------------------------------------+ +| Logger_ | | ++-----------------------------+-----------------------------------------------+ + +**Other idl for test purposes** +nstest.idl +SALOME_TestComponent.idl +SALOME_TestModuleCatalog.idl +SALOME_TestMPIComponent.idl +TestNotif.idl + +.. _Engines: ./tui/KERNEL/namespaceEngines.html +.. _Component: ./tui/KERNEL/interfaceEngines_1_1Component.html +.. _Container: ./tui/KERNEL/interfaceEngines_1_1Container.html +.. _fileTransfer: ./tui/KERNEL/interfaceEngines_1_1fileTransfer.html +.. _fileRef: ./tui/KERNEL/interfaceEngines_1_1fileRef.html +.. _ContainerManager: ./tui/KERNEL/interfaceEngines_1_1ContainerManager.html +.. _MPIContainer: ./tui/KERNEL/interfaceEngines_1_1MPIContainer.html +.. _MPIObject: ./tui/KERNEL/interfaceEngines_1_1MPIObject.html +.. _SALOME: ./tui/KERNEL/namespaceSALOME.html +.. _SALOMEDS: ./tui/KERNEL/namespaceSALOMEDS.html +.. _SALOME_Component: ./tui/KERNEL/SALOME__Component_8idl.html +.. _SALOME_ContainerManager: ./tui/KERNEL/SALOME__ContainerManager_8idl.html +.. _SALOMEDSidl: ./tui/KERNEL/SALOMEDS_8idl.html +.. _SALOMEDS_Attributes: ./tui/KERNEL/SALOMEDS__Attributes_8idl.html +.. _SALOME_ModuleCatalog: ./tui/KERNEL/SALOME__ModuleCatalog_8idl.html +.. _SALOME_RessourcesCatalog: ./tui/KERNEL/SALOME__RessourcesCatalog_8idl.html +.. _SALOME_Registry: ./tui/KERNEL/SALOME__Registry_8idl.html +.. _Logger: ./tui/KERNEL/Logger_8idl.html +.. _SALOME_Comm: ./tui/KERNEL/SALOME__Comm_8idl.html +.. _SALOME_GenericObj: ./tui/KERNEL/SALOME__GenericObj_8idl.html +.. _SALOME_Exception: ./tui/KERNEL/SALOME__Exception_8idl.html +.. _SALOME_Session: ./tui/KERNEL/SALOME__Session_8idl.html +.. _SALOME_MPIContainer: ./tui/KERNEL/SALOME__MPIContainer_8idl.html +.. _SALOME_MPIObject: ./tui/KERNEL/SALOME__MPIObject_8idl.html + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/SALOME_Application.txt b/doc/docutils/archives/SALOME_Application.txt new file mode 100644 index 000000000..0abcaed1e --- /dev/null +++ b/doc/docutils/archives/SALOME_Application.txt @@ -0,0 +1,353 @@ +====================================================================== +SALOME Application Concept. Configuration for one or more computers +====================================================================== + +*html version of this document is produced with docutils*:: + + rst2html doc.txt > doc.html + +This document corresponds to SALOME2 3.2.0 + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +The following explains how to configure your own application with your list of +modules, how to define and run this application on one or more computers. + +General principles +------------------ + +A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...). + +A SALOME User can define several SALOME Applications. These applications are +runnable from the same user account. These applications may share the same +KERNEL and modules. Thus, the application configuration is independant of +KERNEL and must not be put in KERNEL_ROOT_DIR. + +Furthermore, prerequisites may not be the same on all the applications. + +A SALOME Session can run on a several computers. + +Binary modules and prerequisites are installed on the different computers. +There is no need to have all the modules on each computer (the minimum is +KERNEL). + +There is no need of standardization or centralised information on the details +of configuration on each computer (PATH, LD_LIBRARY_PATH, environment +variables) provided the application modules are version - compatible. Details +of configuration stay private to the computer, and are held by scripts on each +computer. + +There is no hierarchy between the computers (for example only one master +computer used to launch application). + +The SALOME user has an account on all the computers. Access between +account@computer is via rsh or ssh and must be configured for use without +password (key exchange for ssh). Account may be different on each +computer. + +Application Directory +--------------------- + +Two ways for creation of an application directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First way - references to different module directories +'''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an +application directory with the given path in parameter. ${APPLI} is a path +relative to ${HOME}. + +The directory is only a skeleton, the user has to edit several files to +configure his own application. These files are described after, the list is: + +- env.d/atFirst.sh +- env.d/envProducts.sh +- env.d/envSalome.sh +- CatalogResources.xml +- SalomeApp.xml + +Second and easiest way - one single virtual install directory +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The user must create a SALOME application configuration file by modifying a +copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml. +The file describes the list of SALOME modules used in the application, with +their respective installation path. The configuration file also defines the +path of an existing script which sets the SALOME prerequisites, +and optionnaly, the path of samples directory (SAMPLES_SRC). +The following command:: + + python /bin/salome/appli_gen.py --prefix= --config= + +creates a virtual installation of SALOME in the application directory ${APPLI} +(bin, lib, doc, share...), with, for each file (executable, script, data, +library, resources...), symbolic links to the actual file. + +Providing an existing an existing script for SALOME prerequisites (the same one +used for modules compilation, or given with the modules installation), the +installation works without further modification for a single computer (unless +some modules needs a special environment not defined in the above script). +For a distributed application (several computers), one must copy and adapt +CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below). + +General rules +------------- + +Directory ${APPLI} must be created on each computer of the application. +The easiest way is to use the same relative path (to ${HOME}) on each computer. +(Sometimes it is not possible to use the same path everywhere, for instance +when ${HOME} is shared with NFS, so it is possible to define different path +following the computers). + +The ${APPLI} directory contains scripts for environment and runs. Environment +scripts must be configured (by the user) on each computer. All the environment +scripts are in the ${APPLI}/env.d directory. + +The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d +in alphanumeric order (after edition, think to remove backup files). the envd +script is used by run scripts. + + +env.d scripts +~~~~~~~~~~~~~ +With the first way of installation, each user **must define** his own +configuration for these scripts, following the above rules. +With the virtual installation (second way, above), env.d +scripts are built automatically. + + **The following is only an example proposed by createAppli.sh, (first way of installation) not working as it is**. + +atFirst.sh + Sets the computer configuration not directly related to SALOME, + like useful tools, default PATH. + +envProducts.sh + Sets the SALOME prerequisites. + +envSALOME.sh + Sets all the MODULE_ROOT_DIR that can be used in the SALOME application. + + SalomeAppConfig is also defined by:: + + export SalomeAppConfig=${HOME}/${APPLI} + + where SalomeAppConfig designates the directory containing SalomeApp.xml. + Note that ${APPLI} is already defined by the calling scripts when + env.d/envSalome.sh is sourced. + +User run scripts +~~~~~~~~~~~~~~~~ + +The SALOME user can use 4 scripts: + +runAppli + Launches a SALOME Session + (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different + name to avoid confusions). + +runSession + Launches a shell script in the SALOME application environment, with access + to the current (last launched) SALOME session (naming service), if any. + Without arguments, the script is interactive. With arguments, the script + executes the command in the SALOME application environment. + +runConsole + Gives a python console connected to the current SALOME Session. + It is also possible to use runSession, then python. + +runTests + Similar to runSession, used for unit testing. runSession tries to use an + already existing naming service definition from a running session (hostname + and port number), runTests defines a new configuration for naming service + (new port number). + +SALOME internal run scripts +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +envd + Sets SALOME application environment, envd is sourced by other scripts. + +For remote calls, SALOME uses one script. + +runRemote.sh + This script is mainly used to launch containers. The first 2 arguments + define the hostname and port userd for naming service, the remaining + arguments define the command to execute. + +Other configuration files +~~~~~~~~~~~~~~~~~~~~~~~~~ + +SalomeApp.xml + This file is similar to the default given + in ${GUI_ROOT_DIR}/share/salome/resources/gui + + +CatalogRessources.xml + This files describes all the computers the application can use. The given + example is minimal and suppose ${APPLI} is the same relative path + to ${HOME}, on all the computers. A different directory can be set on a + particular computer with a line:: + + appliPath="my/specific/path/on/this/computer" + + +Examples of use +--------------- + +Launch a SALOME session with a GUI interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Launch is done with a command like:: + + ./runAppli --logger + +The --logger option means here : collect all the traces from the all the +distributed process, via CORBA, in a single file : logger.log. + +There are a lot of options, a complete list is given by:: + + ./runAppli --help + +Note that, without argument, runAppli is a non interactive Python application, +and, with arguments, runAppli is an interactive Python interpreter. + +Several options are already defined by default in SalomeApp.xml files. Optional +arguments given in the command override the SalomeApp.xml configuration. + +Several sessions can run simultaneously, each session use a different port for +CORBA naming service, so the sessions are totally separated from each other. + +When the GUI is closed, the different SALOME servers are still running. + +Close a SALOME session, kill all the servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Inside the interactive python interpreter you get when you use runAppli +with arguments, you can kill all the servers of your session with:: + + >>> killLocalPort() + +or the servers of all the sessions with:: + + >>> killAllPorts() + +If you have no active Python interpreter connected to your session, you can +kill all the SALOME servers of **all the sessions** on a given computer:: + + ./runSession killSalome.py + +Remember! it's the same idea in *Windows (R) operating system* [#]_ : +use the start menu to stop... + +When you use only one session at a time, you don't need more. + +To kill a given session (when several session are running), one needs +the naming service port number:: + + ./runSession killSalomeWithPort 2810 + +Note that the port number of the last launched session can be found on Linux, +in the prompt, within a runSession shell (see below). + +It is also possible to get the Naming Service host and port number of +the last launched session with:: + + ./runSession NSparam.py + +.. [#] Microsoft and Windows are either registered trademarks or trademarks of + Microsoft Corporation in the United States and/or other countries. + +Launch a SALOME session without GUI interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This is used to launch a SALOME Python script without GUI +(no GUI server = SALOME_session_server) + +Example of script (test_session_geom.py):: + + import salome_session + salome_session.startSession(modules=["GEOM"]) + import GEOM_usinggeom + raw_input("Press a key and the servers will be killed ...") + +This script is run in a non interactive way with:: + + ./runSession python test_session_geom.py + +All the process are automatically killed when Python is closed +(with salome_session delete). + +Add an external Python interpretor to a running session +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's often easier to develop and try Python scripts outside the GUI embedded +Python interpreter. Imagine, for instance, you are writing a script involving +geometry and mesh modules. +first, launch a SALOME session with gui, then, on another terminal:: + + ./runSession + python + +Import salome module. salome_init() without arguments creates a new study +in the running session (note: salome_init(n) attachs to a running session whose +studyId is n):: + + import salome + salome.salome_init() + +An example of script given with SMESH:: + + import ex01_cube2build + +It is possible to connect the GUI interface to the study created in the above +script with the file/connect menu, then browse study and display objects. +Further modifications on study can be done either with GUI or external script +(use refresh popup in GUI object browser to see study modifications generated +by the external script). **AVOID modifications with GUI when a Python script +is running**. Not all the modules are protected against concurrent actions... + + +Different uses of the runSession shell interpreter +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +runSession invoked without arguments gives an interactive shell with the full +environment of SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables). +If there are running sessions of the same SALOME application, runSession +connects to the last launched session (i.e. gets the naming service references +of the session: hostname and port) + +On Linux, the shell prompt (bash) gives information on naming service +references, hostname and port:: + + [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$ + +If there is no running session, prompt looks like:: + + [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$ + +runSession is useful to launch any script or program which needs the complete +SALOME environment, with or without a session already running. +For instance, to launch the ddd debugger interface on the gui server, first +launch a SALOME session with gui, then, on another terminal:: + + ./runSession ddd + +Then attach to the running SALOME_Session_Server process. + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/UnitTests.txt b/doc/docutils/archives/UnitTests.txt new file mode 100644 index 000000000..987db0ec1 --- /dev/null +++ b/doc/docutils/archives/UnitTests.txt @@ -0,0 +1,217 @@ +================================================================= +Source code structuration and Unit Tests +================================================================= + +*html version of this document is produced with docutils*:: + + rst2html < doc.txt > doc.html + +*This document corresponds to SALOME2 3.2.0* + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +You will find here general information on code directories structure, +unit tests associated to the different kind of classes, and how to run +the unit tests. + +SALOME KERNEL source code structuration +======================================= + +General structure of KERNEL_SRC +------------------------------- + +KERNEL_SRC + Some README files and configuration tools for build + +KERNEL_SRC/adm_local + Part of the configuration files, other modules have a directory with the + same name. Not used in KERNEL. + +KERNEL_SRC/bin + Python and shell scripts used at run time. + Kit to install a SALOME Application. + +KERNEL_SRC/doc + Kit for KERNEL end user documentation production: + public interfaces, Python, CORBA. + Integrator and Developper documentation. + +KERNEL_SRC/idl + All CORBA interfaces from KERNEL are regrouped here. + +KERNEL_SRC/resources + Configuration files for servers (examples). + Interfaces definitions for KERNEL test components. + +KERNEL_SRC/salome_adm + Configuration files used by autotools (M4 macros & co.) + +KERNEL_SRC/src + The source code (C++ and Python) + + +Directory src: C++ and Python source code +----------------------------------------- + +Basic services non related to CORBA +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Basics + A set of general purpose C++ services, not related to CORBA. + Some general purpose services that are in Utils directory (CORBA related), + are progressivley moved here, as they are not related to CORBA. + + +SALOMELocalTrace + A multithread trace system that allows message tracing on standard error + or a file. + +CASCatch + Exceptions and signal handler. + +HDFPersist + A C++ interface to HDF. + +Basic CORBA services +~~~~~~~~~~~~~~~~~~~~ + +Logger + A CORBA server that collects the trace messages from differents CORBA + process. + +SALOMETraceCollector + A multithread trace system derived from SALOMELocalTrace, that sends messages + to Logger server via CORBA. + +Utils + A set of general purpose services related to CORBA, such as basic CORBA + exception system. See also Basics directory above. + +NamingService + C++ and Python interfaces to name, store and retrieve CORBA objects + +GenericObj + A generic CORBA interface for CORBA objects, to count distributed references, + and to allow destruction by client. + +Miscellaneous CORBA servers +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Registry + Implements SALOME_registry.idl. + Provides a CORBA server library and a separate server program. + +ModuleCatalog + Implements SALOME_moduleCatalog.idl. + Provide a CORBA server library and separate server and client programs. + +ModuleGenerator + Tool to generate a module catalog from CORBA idl + +ResourcesManager + library included in container server + +Notification + library included in differents servers (container) + +NOTIFICATION_SWIG + + +CORBA Containers for SALOME Modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Container + +TestContainer + +LifeCycleCORBA + +LifeCycleCORBA_SWIG + +STUDY server and related interfaces and tools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +SALOMEDSClient + +TOOLSDS + +SALOMEDSImpl + +SALOMEDS + +Python interface to SALOME +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +KERNEL_PY + +Efficient CORBA transfer services +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Communication + +Communication_SWIG + +A Parallel container with MPI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MPIContainer + +TestMPIContainer + +Batch interface library +~~~~~~~~~~~~~~~~~~~~~~~ + +Batch + +Batch_SWIG + +Unit tests +~~~~~~~~~~ + +UnitTests + + +Tools and principles used for Unit testing +========================================== + +**TO BE COMPLETED** + +Unit Testing rely on cppunit package for C++ testing, and on unittest module +for Python. See these products for general principles of unit testing. + +The cppunit package is optional. When the prerequisite is detected, the unit +tests are compiled. + +Unit Tests sources are in directories Test under the src/directories +containing the classes to test. + +Test are ordered following the order of directories given above. + +Tests can be run as a whole, or for a particular directory. In this case, only +a partial test is run (the classes to test, and the classes used, i.e. the +preceding test directories). + + +Today, only some tests are written as an example. There are not yet python +scripts in KERNEL_SRC, but it's a matter of days, there are working scripts +to test LifeCycleCORBA_SWIG interface. + + + + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/index.txt b/doc/docutils/archives/index.txt new file mode 100644 index 000000000..0120b1d9c --- /dev/null +++ b/doc/docutils/archives/index.txt @@ -0,0 +1,113 @@ +================================================================= +KERNEL common Services +================================================================= + +*html version of this document is produced with docutils*:: + + rst2html < doc.txt > doc.html + +*This document corresponds to SALOME2 3.2.0* + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +**General information, for users, integrators and developers** + +**Users, integrators and developers, which documentation ?** + +Following your kind of usage of SALOME, you will find some specific +introductory documentation, listed below. + +End user +======== + +How to configure a SALOME application +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The end user may have to configure his own SALOME application by selection of a +subset of availables SALOME modules. He also may want to install his +application on several computers. + +See SALOME_Application_ to define your own configuration of SALOME and run it +on one or several computers. This is the recommended way of configuration. + +.. _SALOME_Application: ./SALOME_Application.html + + +How to launch SALOME in a SALOME application +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See SALOME_Application_. + +How to use KERNEL services in Python scripts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The SALOME KERNEL offers offers a list of services available in Python. + +See KERNEL_Services_. + +.. _KERNEL_Services: ./KERNEL_Services.html + +Application Integrator +====================== + +Applications integrators are in charge of configuration and installation of +specific SALOME applications over a local network. Application Integrators +built SALOME modules binaries from sources tarballs. + +How to install SALOME +~~~~~~~~~~~~~~~~~~~~~ + +See INSTALL_ for general information on required configuration and +prerequisites, compilation procedure, setting environment principles. + +.. _INSTALL: ./INSTALL.html + +How to configure a SALOME application +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See SALOME_Application_ to define your own configuration of SALOME and run it +on one or several computers. This is the recommended way of configuration. + +.. _SALOME_Application: ./SALOME_Application.html + + +Module maintainer +================= + +Module maintainers are in charge of the development and debug of the SALOME +modules. Each SALOME module is stored in a CVS base. CVS bases are organised +in separate branches for developments and debug. All official or development +releases are identified by a CVS tag. + +Source code structuration and Unit Tests +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See UnitTests_ for general information on code directories structure, +unit tests associated to the different kind of classes, and how to run +the unit tests. + +.. _UnitTests: ./UnitTests.html + +Some development utilities +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See kernel_resources_ for information on basic utilities for C++ and Python +development, like trace and debug, exceptions, singleton. + +.. _kernel_resources: ./kernel_resources.html + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/kernel_resources.txt b/doc/docutils/archives/kernel_resources.txt new file mode 100644 index 000000000..0bc9700da --- /dev/null +++ b/doc/docutils/archives/kernel_resources.txt @@ -0,0 +1,507 @@ +====================================================================== +SALOME Kernel resources for developer +====================================================================== + +*html version of this document is produced with docutils*:: + + rst2html doc.txt > doc.html + +*This document corresponds to SALOME2 3.2.0* + +:Authors: + Antoine Yessayan, + Paul Rascle + +:Version: 0.3 - february 17, 2006 + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +**Abstract** + +This document describes the development environment for +C++ and Python. Makefiles generation and usage are +introduced in another document: "using the SALOME +configuration and building system environment". +Development environment is intended here as: trace and +debug macros usage; SALOME exceptions usage, in C++ and +Python; user CORBA exceptions usage, in C++ and Python, +with and without Graphical User Interface; some general +purpose services such as singleton, used for CORBA +connection and disconnection. + +.. contents:: +.. sectnum:: + +------------------------------------------------------------------------------- + +Trace and debug Utilities +========================= + +During the development process, an execution log is +useful to identify problems. This log contains +messages, variables values, source files names and line +numbers. It is recommended to verify assertions on +variables values and if necessary, to stop the +execution at debug time, in order to validate all parts +of code. + +Two modes: debug and release +---------------------------- + +The goal of debug mode is to check as many features as +possible during the early stages of the development +process. The purpose of the utilities provided in +SALOME is to help the developer to add detailed traces +and check variables values, without writing a lot of code. + +When the code is assumed to be valid, the release mode +optimizes execution, in terms of speed, memory, and +display only user level messages. + +But, some informations must always be displayed in both +modes: especially messages concerning environment or +internal errors, with version identification. When an +end user is confronted to such a message, he may refer +to a configuration documentation or send the message to +the people in charge of SALOME installation, or to the +development team, following the kind of error. + +C++ Macros for trace and debug +------------------------------ + +SALOME provides C++ macros for trace and debug. These +macros are in:: + + KERNEL_SRC/src/SALOMELocalTrace/utilities.h + +This file must be included in C++ source. Some +macros are activated only in debug mode, others are +always activated. To activate the debug mode, ``_DEBUG_`` +must be defined, which is the case when SALOME +Makefiles are generated from configure, without +options. When ``_DEBUG_`` is undefined (release mode: +``configure --disable-debug --enable-production``), the +debug mode macros are defined empty (they do nothing). +So, when switching from debug to release, it is +possible (and recommended) to let the macro calls +unchanged in the source. + +All the macros generate trace messages, stored in a +circular buffer pool. A separate thread reads the +messages in the buffer pool, and, depending on options +given at SALOME start, writes the messages on the +standard output, a file, or send them via CORBA, in +case of a multi machine configuration. + +Three informations are systematically added in front of +the information displayed: + +* the thread number from which the message come from; + +* the name of the source file in which the macros is set; + +* the line number of the source file at which the macro + is set. + +Macros defined in debug and release modes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**INFOS_COMPILATION** + The C++ macro INFOS_COMPILATION writes on the trace + buffer pool informations about the compiling process: + + * the name of the compiler : g++, KCC, CC, pgCC; + + * the date and the time of the compiling processing process. + + This macro INFOS_COMPILATION does not have any + argument. Moreover, it is defined in both compiling + mode : _DEBUG_ and _RELEASE_. + + Example:: + + #include "utilities.h" + int main(int argc , char **argv) + { + INFOS_COMPILATION; + ... + } + INFOS(str) + +**INFOS** + In both compiling mode _DEBUG_ and _RELEASE_, The C++ + macro INFOS writes on the trace buffer pool the string + which has been passed in argument by the user. + + Example:: + + #include "utilities.h" + int main(int argc , char **argv) + { + ... + INFOS("NORMAL END OF THE PROCESS"); + return 0; + } + + displays:: + + main.cxx [5] : NORMAL END OF THE PROCESS + + +**INTERRUPTION(str)** + In both compiling mode _DEBUG_ and _RELEASE_, The C++ + macro INTERRUPTION writes on the trace buffer pool the + string, with a special ABORT type. When the thread in + charge of collecting messages finds this message, it + terminates the application, after message treatment. + +**IMMEDIATE_ABORT(str)** + In both compiling mode _DEBUG_ and _RELEASE_, The C++ + macro IMMEDIATE_ABORT writes the message str immediately on + standard error and exits the application. Remaining + messages not treated by the message collector thread + are lost. + +Macros defined only in debug mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**MESSAGE(str)** + In _DEBUG_ compiling mode only, the C++ macro MESSAGE + writes on the trace buffer pool the string which has + been passed in argument by the user. In _RELEASE_ + compiling mode, this macro is blank. + + Example:: + + #include "utilities.h" + #include + + using namespace std; + + int main(int argc , char **argv) + { + ... + const char *str = "Salome"; + MESSAGE(str); + ... const string st; + st = "Aster"; + MESSAGE(c_str(st+" and CASTEM")); + return 0; + } + + displays:: + + - Trace main.cxx [8] : Salome + - Trace main.cxx [12] : Aster and CASTEM + +**BEGIN_OF(func_name)** + In _DEBUG_ compiling mode, The C++ macro BEGIN_OF + appends the string "Begin of " to the one passed in + argument by the user and displays the result on the + trace buffer pool. In _RELEASE_ compiling mode, this + macro is blank. + + Example:: + + #include "utilities.h" + int main(int argc , char **argv) + { + BEGIN_OF(argv[0]); + return 0; + } + + displays:: + + - Trace main.cxx [3] : Begin of a.out + + +**END_OF(func_name)** + In _DEBUG_ compiling mode, The C++ macro END_OF appends + the string "Normal end of " to the one passed in + argument by the user and displays the result on the + trace buffer pool. In _RELEASE_ compiling mode, this + macro is blank. + + Example:: + + #include "utilities.h" + int main(int argc , char **argv) + { + END_OF(argv[0]); + return 0; + } + + displays:: + + - Trace main.cxx [4] : Normal end of a.out + +**SCRUTE(var)** + In _DEBUG_ compiling mode, The C++ macro SCRUTE + displays its argument which is an application variable + followed by the value of the variable. In _RELEASE_ + compiling mode, this macro is blank. + + Example:: + + #include "utilities.h" + int main(int argc , char **argv) + { + const int i=999; + if( i > 0 ) SCRUTE(i) ; i=i+1; + return 0; + } + + displays:: + + - Trace main.cxx [5] : i=999 + +**ASSERT(condition)** + In _DEBUG_ compiling mode only, The C++ macro ASSERT + checks the expression passed in argument to be not + NULL. If it is NULL the condition is written with the + macro INTERRUPTION (see above). The process exits after + trace of this last message. In _RELEASE_ compiling + mode, this macro is blank. N.B. : if ASSERT is already + defined, this macro is ignored. + + Example:: + + #include "utilities.h" + ... + const char *ptrS = fonc(); + ASSERT(ptrS!=NULL); + cout << strlen(ptrS); + float table[10]; + int k; + ... + ASSERT(k<10); + cout << table[k]; + +Exceptions +========== + +C++ exceptions: class SALOME_Exception +-------------------------------------- + +definition +~~~~~~~~~~ + +The class SALOME_Exception provides a generic method to +send a message, with optional source file name and line +number. This class is intended to serve as a base class +for all kinds of exceptions SALOME code. All the +exceptions derived from SALOME_Exception could be +handled in a single catch, in which the message +associated to the exception is displayed, or sent to a +log file. + +The class SALOME_Exception inherits its behavior from +the STL class exception. + +usage +~~~~~ + +The header SALOME/src/utils/utils_SALOME_Exception.hxx +must be included in the C++ source, when raised or trapped:: + + #include "utils_SALOME_Exception.hxx" + +The SALOME_Exception constructor is:: + + SALOME_Exception( const char *text, + const char *fileName=0, + const unsigned int lineNumber=0 ); + +The exception is raised like this:: + + throw SALOME_Exception("my pertinent message"); + +or like this:: + + throw SALOME_Exception(LOCALIZED("my pertinent message")); + +where LOCALIZED is a macro provided with +``utils_SALOME_Exception.hxx`` which gives file name and +line number. + +The exception is handled like this:: + + try + { + ... + } + catch (const SALOME_Exception &ex) + { + cerr << ex.what() <::Instance() ; + assert(ptrPoint!=NULL) ; + +No need to delete ptrPoint. Deletion is achieved +automatically at exit. If the user tries to create more +than one singleton by using the class method +SINGLETON_::Instance(), the pointer is returned +with the same value even if this is done in different +functions (threads ?):: + + POINT *p1=SINGLETON_::Instance() ; + ... + POINT *p2=SINGLETON_::Instance() ; + + assert(p1==p2) + +Design description +~~~~~~~~~~~~~~~~~~ + +Here are the principles features of the singleton +design: + +* the user creates an object of class TYPE by using the + class method ``SINGLETON_::Instance()`` which + returns a pointer to the single object ; + +* to create an object, ``SINGLETON_::Instance()`` + uses the default constructor of class TYPE ; + +* at the same time, this class method creates a + destructor object which is added to the generic list + of destructor objects to be executed at the end of + the application (atexit) ; + +* at the end of the application process all the + deletions are performed by the ``Nettoyage()`` C function + which executes the destruction objects end then + deletes the destructions objects themselves ; + +* the ``Nettoyage()`` C function using ``atexit()`` C function + is embedded in a static single object ``ATEXIT_()``. + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/archives/rst.css b/doc/docutils/archives/rst.css new file mode 100644 index 000000000..38bd7dcab --- /dev/null +++ b/doc/docutils/archives/rst.css @@ -0,0 +1,288 @@ +/* +:Authors: David Goodger, David Abrahams +:Contact: goodger@users.sourceforge.net, dave@boost-consulting.com +:date: $Date$ +:version: $Revision$ +:copyright: This stylesheet has been placed in the public domain. + +This stylesheet is for the use of ReStructuredText in a Boost context. +It is basically an agglomeration of boost.css and the default.css that +comes from docutils. + + */ + +.first { + margin-top: 0 } + +.last { + margin-bottom: 0 } + +a.toc-backref { + text-decoration: none ; + color: #00008B } + +dd { + margin-bottom: 0.5em } + +div.abstract { + margin: 2em 5em } + +div.abstract p.topic-title { + font-weight: bold ; + text-align: center } + +div.attention, div.caution, div.danger, div.error, div.hint, +div.important, div.note, div.tip, div.warning, div.admonition { + margin: 2em ; + border: medium outset ; + padding: 1em } + +div.attention p.admonition-title, div.caution p.admonition-title, +div.danger p.admonition-title, div.error p.admonition-title, +div.warning p.admonition-title { + color: red ; + font-weight: bold ; + font-family: sans-serif } + +div.hint p.admonition-title, div.important p.admonition-title, +div.note p.admonition-title, div.tip p.admonition-title, +div.admonition p.admonition-title { + font-weight: bold ; + font-family: sans-serif } + +div.dedication { + margin: 2em 5em ; + text-align: center ; + font-style: italic } + +div.dedication p.topic-title { + font-weight: bold ; + font-style: normal } + +div.figure { + margin-left: 2em } + +div.footer, div.header { + font-size: smaller } + +div.sidebar { + margin-left: 1em ; + border: medium outset ; + padding: 0em 1em ; + background-color: #ffffee ; + width: 40% ; + float: right ; + clear: right } + +div.sidebar p.rubric { + font-family: sans-serif ; + font-size: medium } + +div.system-messages { + margin: 5em } + +div.system-messages h1 { + color: red } + +div.system-message { + border: medium outset ; + padding: 1em } + +div.system-message p.system-message-title { + color: red ; + font-weight: bold } + +div.topic { + margin: 2em } + +H1.title +{ + FONT-SIZE: 150%; + COLOR: #00008B; + text-align: center +} +H1 +{ + FONT-SIZE: 125%; +} +H2 +{ + FONT-SIZE: 108%; +} +h2.subtitle { + text-align: center } +H3 +{ + FONT-SIZE: 100%; +} +BODY +{ + FONT-SIZE: 100%; + BACKGROUND-COLOR: #ffffff; +} +PRE +{ + MARGIN-LEFT: 2em; + FONT-FAMILY: Courier; +} +CODE +{ + FONT-FAMILY: Courier; + white-space: pre; +} +.pre +{ + FONT-FAMILY: Courier; + white-space: pre; +} +.index +{ + TEXT-ALIGN: left; +} +.page-index +{ + TEXT-ALIGN: left; +} +.definition +{ + TEXT-ALIGN: left; +} +.footnote +{ + FONT-SIZE: 66%; + VERTICAL-ALIGN: super; + TEXT-DECORATION: none; +} +.function-semantics +{ + CLEAR: left; +} + +hr { + width: 75% } + +ol.simple, ul.simple { + margin-bottom: 1em } + +ol.arabic { + list-style: decimal } + +ol.loweralpha { + list-style: lower-alpha } + +ol.upperalpha { + list-style: upper-alpha } + +ol.lowerroman { + list-style: lower-roman } + +ol.upperroman { + list-style: upper-roman } + +p.attribution { + text-align: right ; + margin-left: 50% } + +p.caption { + font-style: italic } + +p.credits { + font-style: italic ; + font-size: smaller } + +p.label { + white-space: nowrap } + +p.rubric { + font-weight: bold ; + font-size: larger ; + color: maroon ; + text-align: center } + +p.sidebar-title { + font-family: sans-serif ; + font-weight: bold ; + font-size: larger } + +p.sidebar-subtitle { + font-family: sans-serif ; + font-weight: bold } + +p.topic-title { + font-weight: bold } + +pre.address { + margin-bottom: 0 ; + margin-top: 0 ; + font-family: serif ; + font-size: 100% } + +pre.line-block { + font-family: serif ; + font-size: 100% } + +pre.literal-block, pre.doctest-block { + margin-left: 2em ; + margin-right: 2em ; + font-size: 80%; + border: solid thin gray ; + background-color: #eeeeee } + +span.classifier { + font-family: sans-serif ; + font-style: oblique } + +span.classifier-delimiter { + font-family: sans-serif ; + font-weight: bold } + +span.interpreted { + font-family: sans-serif } + +span.option { + white-space: nowrap } + +span.option-argument { + font-style: italic } + +span.pre { + white-space: pre } + +span.problematic { + color: red } + +table { + margin-top: 0.5em ; + margin-bottom: 0.5em } + +table.citation { + border-left: solid thin gray ; + padding-left: 0.5ex } + +table.docinfo { + margin: 2em 4em } + +table.footnote { + border-left: solid thin black ; + padding-left: 0.5ex } + +td, th { + padding-left: 0.5em ; + padding-right: 0.5em ; + vertical-align: top } + +th.docinfo-name, th.field-name { + font-weight: bold ; + text-align: left ; + white-space: nowrap } + +/* + dwa 2003/7/29 -- commented out so that it wouldn't override earlier + styles from boost.css + +h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt { + font-size: 100% } +*/ + +ul.auto-toc { + list-style-type: none } diff --git a/doc/docutils/archives/txt2html.sh b/doc/docutils/archives/txt2html.sh new file mode 100755 index 000000000..16b6c3628 --- /dev/null +++ b/doc/docutils/archives/txt2html.sh @@ -0,0 +1,55 @@ +#!/bin/sh +# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +# +# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, +# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS +# +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License. +# +# This library 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 +# Lesser General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# +# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +# + +# =================================================================== +# This shell script is provided for generating the html files +# from the txt files (restructured text) in the source directory. +# Usage: just execute the script where it stands in the source +# directory. The file list has to be updated manually when adding +# a new restructured text file. +# Note that the building process executes a target rstdoc that +# generates the html documentation without need of this script. +# The autoconficuration (check_htmlgen.m4) set the correct generator +# rst2html by replacing the @RST2HTML@ tag. +# =================================================================== +# (CSSI - gboulant - 25/10/05) +# This must be updated manually in this script (for source usage only) +# +RST2HTML=rst2html + +FILELIST="index + UnitTests + SALOME_Application + INSTALL + kernel_resources + userguide" + +STYLESHEET=rst.css +RSTOPTS="--output-encoding=latin1 --stylesheet=$STYLESHEET" + +for file in $FILELIST; do + bfn=`basename $file .txt` + echo "Generating ${bfn}.html from ${bfn}.txt ..." + $RST2HTML $RSTOPTS ${bfn}.txt ${bfn}.html +done + diff --git a/doc/docutils/archives/userguide.txt b/doc/docutils/archives/userguide.txt new file mode 100644 index 000000000..b7134e840 --- /dev/null +++ b/doc/docutils/archives/userguide.txt @@ -0,0 +1,146 @@ +================================================================= +User's guide, for developpers and users +================================================================= + +*html version of this document is produced with docutils*:: + + rst2html < doc.txt > doc.html + +*This document corresponds to SALOME2 3.1.0* +*NOT UP TO DATE with 3.2.0* + +.. contents:: +.. sectnum:: + ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + +------------------------------------------------------------------------------- + +This guide provides you with some basic concepts for developing and +using the SALOME platform. You will find some information on the +general technical architecture ... + +Introduction +============ + +General information +------------------- + +This document has been initialized by collecting and updating an existing +documentation. The restructured text format has been selected for +writing. This format can be read with a basic editor except for +pictures and some hypertext links. You can build the html pages using +the docutils scripts provided with python packages on most platform. + +Definitions +----------- + +``WORK IN PROGRESS`` + +Module + definition of a module and/or link to the definition + +Container + definition of a container + + +General concepts +================ +modules et dépendances (s'inspirer de PYHELLO) + + +Filesystem organisation +======================== + +Voir doc de JR "Organisation de la plate-forme" + +A typical source working directory +---------------------------------- +organisation type des sources d'un module standard (spécifications techniques) + +A typical installation directory +-------------------------------- +organisation type des produits installés + + +Building process +================ +Procédures de compilation (renvoie au install.sh) + + +Developer's guide - basic concepts +========================================= + +Guide du développeur: éléments de conception + - zoom sur certains éléments techniques bons à connaitre pour faire + évoluer le KERNEL sans tout casser. + - les ressources du kernel: + - trace, debug, exception (cf. kernel_ressources.tex) + - classes batch (présentation puis renvoi à la doc d'Ivan) + - développement de tests unitaires + +Developer's guide - managing the development space +================================================== + +- Guide du développeur: gestion de l'espace de développement + - principe de mise en oeuvre (rôle des étapes: build_configure, ...) + - description des fichiers m4 et du principe de mise en oeuvre + - les Makefile.in, ... (cf. doc guide du développeur). + - évolution des procédures de construction + - personalisation des procédures de construction + +Developer' guide - integration tools +==================================== +- Guide de l'intégrateur (développeur de nouveaux modules) +(on lui montre ici le principe de construction et les ressources à +disposition pour faire le travail) + - création d'un modules + - intégration code boîte noire (perfect, solver) + - intégration bibliothèque de fonctions (hxx2salome, voir avec + N.Crouzet) + - intégration de modèles de données (xdata) + + +End user's guide +================ +- Guide de l'utilisateur + - concept d'application (renvoie doc Paul) + - commandes avancées (showNS, exemple de contact de la + session, d'un engine, utilisation du lifeCycle, du module salome, + des modules geompy et smesh) + - utilisation en mode distribué (doc de B. Sechet) + - GUI and TUI documentation + + + + + + + + + + + + + + + +RST Exemples +============ + +See INSTALL_ for general information on required configuration and +prerequisites, compilation procedure, setting environment principles. + +.. _INSTALL: ./INSTALL.html + + +------------------------------------------------------------------------------- + ++----------------------------------+------------------------------------------+ +| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | ++----------------------------------+------------------------------------------+ + +.. _`General KERNEL documentation`: ./index.html +.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/docutils/conf.py b/doc/docutils/conf.py new file mode 100644 index 000000000..a193dd95e --- /dev/null +++ b/doc/docutils/conf.py @@ -0,0 +1,200 @@ +# -*- coding: iso-8859-1 -*- +# +# yacs documentation build configuration file, created by +# sphinx-quickstart on Fri Aug 29 09:57:25 2008. +# +# This file is execfile()d with the current directory set to its containing dir. +# +# The contents of this file are pickled, so don't put values in the namespace +# that aren't pickleable (module imports are okay, they're removed automatically). +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +import sys, os + +# If your extensions are in another directory, add it here. If the directory +# is relative to the documentation root, use os.path.abspath to make it +# absolute, like shown here. +#sys.path.append(os.path.abspath('.')) + +# General configuration +# --------------------- + +# Add any Sphinx extension module names here, as strings. They can be extensions +# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. +extensions = ['sphinx.ext.autodoc'] + +# Uncomment the following line to build the links with Python documentation +# (you might need to set http_proxy environment variable for this to work) +#extensions += ['sphinx.ext.intersphinx'] + +# Intersphinx mapping to add links to modules and objects in the Python +# standard library documentation +intersphinx_mapping = {'http://docs.python.org': None} + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix of source filenames. +source_suffix = '.rst' + +# The encoding of source files. +source_encoding = 'utf-8' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = 'KERNEL python packages' +copyright = '2010 EDF R&D' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = '5.1.4' +# The full version, including alpha/beta/rc tags. +release = '5.1.4' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +language = 'en' + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +#today = '' +# Else, today_fmt is used as the format for a strftime call. +#today_fmt = '%B %d, %Y' + +# List of documents that shouldn't be included in the build. +#unused_docs = [] + +# List of directories, relative to source directory, that shouldn't be searched +# for source files. +exclude_trees = ['.build','ref','images','CVS','.svn'] + +# The reST default role (used for this markup: `text`) to use for all documents. +#default_role = None + +# If true, '()' will be appended to :func: etc. cross-reference text. +#add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +#add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +#show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + + +# Options for HTML output +# ----------------------- + +# The theme to use for HTML and HTML Help pages. Major themes that come with +# Sphinx are currently 'default' and 'sphinxdoc'. +html_theme = 'default' +#html_theme = 'nature' +#html_theme = 'agogo' +#html_theme = 'sphinxdoc' +#html_theme = 'omadoc' + +# Add any paths that contain custom themes here, relative to this directory. +#html_theme_path = ['themes'] + +# The name for this set of Sphinx documents. If None, it defaults to +# " v documentation". +#html_title = None + +# A shorter title for the navigation bar. Default is the same as html_title. +#html_short_title = None + +# The name of an image file (relative to this directory) to place at the top +# of the sidebar. +#html_logo = None + +# The name of an image file (within the static path) to use as favicon of the +# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# pixels large. +#html_favicon = None + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +#html_static_path = ['_static'] + +# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, +# using the given strftime format. +#html_last_updated_fmt = '%b %d, %Y' + +# If true, SmartyPants will be used to convert quotes and dashes to +# typographically correct entities. +#html_use_smartypants = True + +# Custom sidebar templates, maps document names to template names. +#html_sidebars = {} + +# Additional templates that should be rendered to pages, maps page names to +# template names. +#html_additional_pages = {} + +# If false, no module index is generated. +html_use_modindex = False + +# If false, no index is generated. +#html_use_index = True + +# If true, the index is split into individual pages for each letter. +#html_split_index = False + +# If true, the reST sources are included in the HTML build as _sources/. +html_copy_source = True + +# If true, an OpenSearch description file will be output, and all pages will +# contain a tag referring to it. The value of this option must be the +# base URL from which the finished HTML is served. +#html_use_opensearch = '' + +# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml"). +#html_file_suffix = '' + +# Output file base name for HTML help builder. +htmlhelp_basename = 'kernelpydoc' + + +# Options for LaTeX output +# ------------------------ + +# The paper size ('letter' or 'a4'). +latex_paper_size = 'a4' + +# The font size ('10pt', '11pt' or '12pt'). +latex_font_size = '10pt' + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, author, document class [howto/manual]). +latex_documents = [ + ('index', 'kernelpy.tex', 'Documentation of the KERNEL python packages', 'EDF R\&D', 'manual') +] + +# The name of an image file (relative to this directory) to place at the top of +# the title page. +latex_logo = '../salome/tui/images/head.png' + +# For "manual" documents, if this is true, then toplevel headings are parts, +# not chapters. +#latex_use_parts = True + +# Additional stuff for the LaTeX preamble. +#latex_preamble = '' + +# Documents to append as an appendix to all manuals. +#latex_appendices = [] + +# If false, no module index is generated. +latex_use_modindex = False diff --git a/doc/docutils/docapi.rst b/doc/docutils/docapi.rst new file mode 100644 index 000000000..56ee65286 --- /dev/null +++ b/doc/docutils/docapi.rst @@ -0,0 +1,46 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + Documentation of the programming interface (API) +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +This section describes the python packages and modules of the +``salome.kernel`` python package. The main part is generated from the +code documentation included in source python files. + +:mod:`salome.kernel` -- Package containing the KERNEL python utilities +====================================================================== + +:mod:`deprecation` -- Indication of deprecated modules and functions +-------------------------------------------------------------------- + +.. automodule:: salome.kernel.deprecation + :members: + + +:mod:`termcolor` -- Display colored text in terminal +---------------------------------------------------- + +.. automodule:: salome.kernel.termcolor + :members: + :exclude-members: TEST_termcolor + + +:mod:`logger` -- Logging utility +-------------------------------- + +.. automodule:: salome.kernel.logger + +.. autoclass:: Logger + :members: + :show-inheritance: + +.. autoclass:: ExtLogger + :members: + :show-inheritance: + + +:mod:`studyedit` -- Study editor +-------------------------------- + +.. automodule:: salome.kernel.studyedit + :members: diff --git a/doc/docutils/index.rst b/doc/docutils/index.rst new file mode 100644 index 000000000..a0b8c3a32 --- /dev/null +++ b/doc/docutils/index.rst @@ -0,0 +1,22 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + Documentation of the KERNEL python packages +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +Main documentation +================== + +.. toctree:: + :maxdepth: 3 + + overview.rst + docapi.rst + + +Additional documentation +======================== + +.. toctree:: + :maxdepth: 3 + + salomepypkg.rst diff --git a/doc/docutils/overview.rst b/doc/docutils/overview.rst new file mode 100644 index 000000000..341e9b652 --- /dev/null +++ b/doc/docutils/overview.rst @@ -0,0 +1,54 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +General presentation of the KERNEL python package +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +The KERNEL python package essentially contains: + +* Helper functions to manipulate KERNEL objects from python. For + example, the ``studyedit.py`` module makes you ease with the + manipulation of the SALOME study, its ``SComponent`` and + ``SObject``. +* General purpose functions for logging, threading, and other recurent + stuff in python programming. These function has no dependancy with + SALOME and could be used from any python interpreter + +Note that these functions either encapsulate the python programming +interface of KERNEL core (the CORBA or SWIG interfaces for example) or +extend existing utilities as the ``salome*.py`` modules. + +The functions are distributed in the python package +``salome.kernel``. For example, the usage of the study editor to +manipulate some objects can be done with a set of instructions as: + +.. code-block:: python + + import salome + salome.salome_init() + salomeStudyId = salome.myStudyId + + from salome.kernel import studyedit + studyEditor = studyedit.getStudyEditor(salomeStudyId) + + myStudyComponent = studyEditor.findOrCreateComponent( + componentName, + componentLabel, + componentIcon, + engineName) + + myStudyItem = studyEditor.createItem( + myStudyComponent, + itemName, + itemComment, + itemType, + itemIcon) + +The specification of the programming interface of this package is +detailled in the part :doc:`Documentation of the programming interface +(API)` of this documentation. + +.. note:: + The main package ``salome`` contains other sub-packages that are + distributed with the other SALOME modules. For example, the GEOM + module provides the python package ``salome.geom`` and SMESH the + package ``salome.smesh``. diff --git a/doc/docutils/salomepypkg.rst b/doc/docutils/salomepypkg.rst new file mode 100644 index 000000000..c46063eb2 --- /dev/null +++ b/doc/docutils/salomepypkg.rst @@ -0,0 +1,270 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Complement A: Organizing the SALOME python functions in a packaged structure +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +This chapter contains the instruction notes to organise the python +files of SALOME in a packaged python structure. This is the first step +of the development process, whose goal is to validate the principles +and show a possible way. + +:Contacts: Guillaume Boulant, Christian Caremoli, Renaud Barate + +Objectives +========== + +The main idea is to import SALOME python functions by doing: + +.. code-block:: python + + from salome.kernel. import + +instead of: + +.. code-block:: python + + from import + +as it must be done up to now because of the flat organisation of +python files in the installation folders of SALOME modules. + +To reach this target, the files ``.py`` have to be +organised in a packaged python structure where the main package is +named ``salome``, and then sub-packages could be created for each +SALOME module: + +* ``salome.kernel``: for kernel python functions, embedded in the + KERNEL module +* ``salome.gui``: for gui python functions, embedded in the GUI module +* ``salome.geom``: for geom python functions, embedded in the GEOM + module +* and so on ... + +The motivations of this objective are twice: + +* Definitively prevent the risk of naming conflict between python + modules coming from different SALOME modules. Today, the developper + of a module has to take care of the names used in other modules to + choose a name. +* Integrate in SALOME some python modules initialy developed in the + context of domain specific SALOME applications (SALOME-MECA, + SALOME-CFD, OPENTURN, PANTHERE) and whose source files are organized + in a packaged python structure. + +The starting point then is a python library named ``nepal`` that +provides SALOME helper functions classified by modules +(KERNEL,GEOM,...) and organized in a packaged python structure: + +* ``salome.kernel``: helper functions for manipulating the SALOME + study and its components (SComponents and SObject). This provides + also general purpose utilities for logging and threading. +* ``salome.gui``: helper functions to manipulate the graphical + representation of studies and the general behavior of the graphical + interface. This provides also generic templates for implementing + dialog box with the MVC pattern. +* ``salome.geom``: essentially contains a function called + "visualization of structural elements". This is used by mechanical + ingeneers to create the 3D geometrical object corresponding to the + numerical model of a given structural element. +* ``salome.smesh``: to manipulated smesh data handled from the SObject + in the SALOME study. + +The target point is to have the ``salome.kernel`` part in the KERNEL +module, the ``salome.geom`` part in the GEOM module, and so on. And +with **no impact on SALOME scripts** that already exists (import salome, +and all other stuff should be imported and work as before). + + +Problems +======== + +To reach this target, we have to face two problems: + +* A naming conflict with the instruction ``import salome``. The result + is unpredictible because of the existance in the ``sys.path`` of + both a file ``salome.py`` and a package ``salome``. +* The dispatching of ``salome.*`` sub-packages in the different SALOME + modules. + +Naming conflict between ``salome.py`` module and ``salome`` package +------------------------------------------------------------------- + +The problem is solved by installing the ``salome.py`` file under the +name ``__init__.py`` in a folder named ``${salomepythondir}/salome``. + +By this operation, the ``${salomepythondir}/salome`` directory is +transformed in a python package and the instruction ``import salome`` +do the same things as before this modification, without any +modification of the ``sys.path``. + +Dispatching of ``salome.*`` sub-packages in different SALOME modules +-------------------------------------------------------------------- + +When we use a SALOME virtual application, the problem is naturally +solved by the fact that every sub-packages are virtually installed in +the same directory, the directory ``${salomepythondir}/salome`` +containing the file ``__init__.py``. + +Nevertheless, some people doesn't use the virtual application. To get +a robust configuration in any case, one can use the python namespace +pattern. This consists in creating a virtual python package that +aggregates all the sub-packages. + +Technically speaking, this consists in implementing in the file +``${salomepythondir}/salome/__init__.py`` (new version of +``salome.py``) a function that automatically extend the ``__path__`` +variable with sub-packages that can be found in SALOME modules +installation paths. The code looks something like that: + +.. code-block:: python + + import os, sys + + MATCH_ENDING_PATTERN="site-packages/salome" + + def extend_path(pname): + for dir in sys.path: + if not isinstance(dir, basestring) or not os.path.isdir(dir) or not dir.endswith(MATCH_ENDING_PATTERN): + continue + subdir = os.path.join(dir, pname) + # WARN: This may still add duplicate entries to path on + # case-insensitive filesystems + if os.path.isdir(subdir) and subdir not in __path__: + print "INFO - The directory %s is appended to sys.path" % subdir + __path__.append(subdir) + + extend_path(ROOT_PYTHONPACKAGE_NAME) + + +Adaptation of the ``apply_gen`` utility +---------------------------------------- + +Due to the specific above choices, the ``apply_gen`` utility must be +modified so that the sub-folder ``salome`` in ``${salomepythondir}`` +is not generated as a symbolic link any longer but as a real folder +containing symbolic links towards the module specific python +sub-packages (``kernel``, ``geom``, ``smesh``, ...) and to the single +file ``__init__.py`` provided by the KERNEL module. + +This adaptation can be done in the ``virtual_salome.py`` script. + + +What to do with already existing python files? +---------------------------------------------- + +Do nothing at this step, it works fine because the files are installed +in a path included in the ``sys.path``. + +In a future version, it should be nice to reverse all the python files +of the KERNEL library in this packaged structure. But this can't be +done without impact on existing python user scripts. + +Instructions +============ + +Instructions for creating the python packages +--------------------------------------------- + +Considering the elements described above, a procedure that works to +get the packaged python structure is: + +* Rename the file ``salome.py`` in ``__init__.py`` (and adapt the + Makefile.am). This is located in the source directory + ``src/KERNEL_PY``. +* Copy the sources files of the kernel part in the source directory + ``src/KERNEL_PY`` starting with a stage named ``kernel`` including + its own packaged structure (only python files and a file + ``__init__.py`` for now) +* Copy the sources files of the geom part in the source directory + ``src/GEOM_PY`` (to be created) of the GEOM module. In this case, we + copy the python files directly in the directory (no stage named + ``geom``, it's not required for source organisation, and will be + created only for installation by makefile). +* Apply the same procedure for every other SALOME modules (it concerns + only SMESH up to now). +* Apply the "namespace pattern" by implementing and invoking the + ``extend_path`` function in the newly created file ``__init__.py`` +* Adapt the ``apply_gen`` utility to take into account the finer + folder hierarchy in ``site-packages``. + +The naming convention for source folder is here the convention in +place in the KERNEL module: the source code of the python packages of +a SALOME module is located in the source directory +``/src/_PY``. + +Note also that all python files that were existing in the KERNEL +module are leaft untouched but the file ``salome.py``. + +Instructions for the associated documentation +--------------------------------------------- + +One special point for the documentation: + +* The documentation of the python package API is writen in rst + (restructured text) and generated form the source code with sphinx. +* The rst source files are located in the directory + ``/doc/docutils``. +* The html generated files are installed in the directory + ``/share/doc/salome/docutils`` but are not connected to + the in-line documentation of the SALOME associated module (menu help + of the SALOME application). + +Any suggestion on this point would be appreciated. + +TODO (by someone): + +* Move all files ``*.txt`` from the ``/doc`` folder to the + ``/doc/docutils`` folder and analyse what is still to date + and usefull. +* Integrate in this part the reference documentation of the ``salome`` + utility and all documentation associated to the launching process + (in particular virtual application) +* Connect this part of the documentation to the main part (doxygen + part). + + +Synthesis +--------- + +Finaly, here is a synthesis of modifications in source files. + +Files modified: + +* See the CVS patch files KERNEL.patch, GEOM.patch and SMESH.patch + (the only SALOME modules modified today). + +Files to be added: + +* KERNEL: file ``src/KERNEL_PY/__init__.py`` (``salome.py`` renamed) +* KERNEL: directory ``src/KERNEL_PY/kernel`` +* KERNEL: directory ``doc/docutils`` +* KERNEL: file ``salome_adm/unix/config_files/check_sphinx.m4`` +* GEOM : directory ``src/GEOM_PY`` +* GEOM : directory ``doc/docutils`` +* SMESH : directory ``src/SMESH_PY`` +* SMESH : directory ``doc/docutils`` + +Files to be delete: + +* file ``src/KERNEL_PY/salome.py`` + + +Tests and usage +=============== + +The instructions above provides you with a SALOME application whose +modules embed there dedicated python packages. This installation can +can be tested using some test use cases. For example, the +visualisation of structural elements (provided by the package +``salome.geom`` can be tested by: + +.. code-block:: python + + from salome.geom.structelem import TEST_StructuralElement + TEST_StructuralElement() + +This can be enter in the GUI python console or in a python interpreter +executed in a SALOME session. + +For more details, read the API documentation in +``/share/doc/salome/docutils``. diff --git a/doc/index.txt b/doc/index.txt deleted file mode 100644 index 0120b1d9c..000000000 --- a/doc/index.txt +++ /dev/null @@ -1,113 +0,0 @@ -================================================================= -KERNEL common Services -================================================================= - -*html version of this document is produced with docutils*:: - - rst2html < doc.txt > doc.html - -*This document corresponds to SALOME2 3.2.0* - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -**General information, for users, integrators and developers** - -**Users, integrators and developers, which documentation ?** - -Following your kind of usage of SALOME, you will find some specific -introductory documentation, listed below. - -End user -======== - -How to configure a SALOME application -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The end user may have to configure his own SALOME application by selection of a -subset of availables SALOME modules. He also may want to install his -application on several computers. - -See SALOME_Application_ to define your own configuration of SALOME and run it -on one or several computers. This is the recommended way of configuration. - -.. _SALOME_Application: ./SALOME_Application.html - - -How to launch SALOME in a SALOME application -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See SALOME_Application_. - -How to use KERNEL services in Python scripts -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The SALOME KERNEL offers offers a list of services available in Python. - -See KERNEL_Services_. - -.. _KERNEL_Services: ./KERNEL_Services.html - -Application Integrator -====================== - -Applications integrators are in charge of configuration and installation of -specific SALOME applications over a local network. Application Integrators -built SALOME modules binaries from sources tarballs. - -How to install SALOME -~~~~~~~~~~~~~~~~~~~~~ - -See INSTALL_ for general information on required configuration and -prerequisites, compilation procedure, setting environment principles. - -.. _INSTALL: ./INSTALL.html - -How to configure a SALOME application -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See SALOME_Application_ to define your own configuration of SALOME and run it -on one or several computers. This is the recommended way of configuration. - -.. _SALOME_Application: ./SALOME_Application.html - - -Module maintainer -================= - -Module maintainers are in charge of the development and debug of the SALOME -modules. Each SALOME module is stored in a CVS base. CVS bases are organised -in separate branches for developments and debug. All official or development -releases are identified by a CVS tag. - -Source code structuration and Unit Tests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See UnitTests_ for general information on code directories structure, -unit tests associated to the different kind of classes, and how to run -the unit tests. - -.. _UnitTests: ./UnitTests.html - -Some development utilities -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See kernel_resources_ for information on basic utilities for C++ and Python -development, like trace and debug, exceptions, singleton. - -.. _kernel_resources: ./kernel_resources.html - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/kernel_resources.txt b/doc/kernel_resources.txt deleted file mode 100644 index 0bc9700da..000000000 --- a/doc/kernel_resources.txt +++ /dev/null @@ -1,507 +0,0 @@ -====================================================================== -SALOME Kernel resources for developer -====================================================================== - -*html version of this document is produced with docutils*:: - - rst2html doc.txt > doc.html - -*This document corresponds to SALOME2 3.2.0* - -:Authors: - Antoine Yessayan, - Paul Rascle - -:Version: 0.3 - february 17, 2006 - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -**Abstract** - -This document describes the development environment for -C++ and Python. Makefiles generation and usage are -introduced in another document: "using the SALOME -configuration and building system environment". -Development environment is intended here as: trace and -debug macros usage; SALOME exceptions usage, in C++ and -Python; user CORBA exceptions usage, in C++ and Python, -with and without Graphical User Interface; some general -purpose services such as singleton, used for CORBA -connection and disconnection. - -.. contents:: -.. sectnum:: - -------------------------------------------------------------------------------- - -Trace and debug Utilities -========================= - -During the development process, an execution log is -useful to identify problems. This log contains -messages, variables values, source files names and line -numbers. It is recommended to verify assertions on -variables values and if necessary, to stop the -execution at debug time, in order to validate all parts -of code. - -Two modes: debug and release ----------------------------- - -The goal of debug mode is to check as many features as -possible during the early stages of the development -process. The purpose of the utilities provided in -SALOME is to help the developer to add detailed traces -and check variables values, without writing a lot of code. - -When the code is assumed to be valid, the release mode -optimizes execution, in terms of speed, memory, and -display only user level messages. - -But, some informations must always be displayed in both -modes: especially messages concerning environment or -internal errors, with version identification. When an -end user is confronted to such a message, he may refer -to a configuration documentation or send the message to -the people in charge of SALOME installation, or to the -development team, following the kind of error. - -C++ Macros for trace and debug ------------------------------- - -SALOME provides C++ macros for trace and debug. These -macros are in:: - - KERNEL_SRC/src/SALOMELocalTrace/utilities.h - -This file must be included in C++ source. Some -macros are activated only in debug mode, others are -always activated. To activate the debug mode, ``_DEBUG_`` -must be defined, which is the case when SALOME -Makefiles are generated from configure, without -options. When ``_DEBUG_`` is undefined (release mode: -``configure --disable-debug --enable-production``), the -debug mode macros are defined empty (they do nothing). -So, when switching from debug to release, it is -possible (and recommended) to let the macro calls -unchanged in the source. - -All the macros generate trace messages, stored in a -circular buffer pool. A separate thread reads the -messages in the buffer pool, and, depending on options -given at SALOME start, writes the messages on the -standard output, a file, or send them via CORBA, in -case of a multi machine configuration. - -Three informations are systematically added in front of -the information displayed: - -* the thread number from which the message come from; - -* the name of the source file in which the macros is set; - -* the line number of the source file at which the macro - is set. - -Macros defined in debug and release modes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**INFOS_COMPILATION** - The C++ macro INFOS_COMPILATION writes on the trace - buffer pool informations about the compiling process: - - * the name of the compiler : g++, KCC, CC, pgCC; - - * the date and the time of the compiling processing process. - - This macro INFOS_COMPILATION does not have any - argument. Moreover, it is defined in both compiling - mode : _DEBUG_ and _RELEASE_. - - Example:: - - #include "utilities.h" - int main(int argc , char **argv) - { - INFOS_COMPILATION; - ... - } - INFOS(str) - -**INFOS** - In both compiling mode _DEBUG_ and _RELEASE_, The C++ - macro INFOS writes on the trace buffer pool the string - which has been passed in argument by the user. - - Example:: - - #include "utilities.h" - int main(int argc , char **argv) - { - ... - INFOS("NORMAL END OF THE PROCESS"); - return 0; - } - - displays:: - - main.cxx [5] : NORMAL END OF THE PROCESS - - -**INTERRUPTION(str)** - In both compiling mode _DEBUG_ and _RELEASE_, The C++ - macro INTERRUPTION writes on the trace buffer pool the - string, with a special ABORT type. When the thread in - charge of collecting messages finds this message, it - terminates the application, after message treatment. - -**IMMEDIATE_ABORT(str)** - In both compiling mode _DEBUG_ and _RELEASE_, The C++ - macro IMMEDIATE_ABORT writes the message str immediately on - standard error and exits the application. Remaining - messages not treated by the message collector thread - are lost. - -Macros defined only in debug mode -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -**MESSAGE(str)** - In _DEBUG_ compiling mode only, the C++ macro MESSAGE - writes on the trace buffer pool the string which has - been passed in argument by the user. In _RELEASE_ - compiling mode, this macro is blank. - - Example:: - - #include "utilities.h" - #include - - using namespace std; - - int main(int argc , char **argv) - { - ... - const char *str = "Salome"; - MESSAGE(str); - ... const string st; - st = "Aster"; - MESSAGE(c_str(st+" and CASTEM")); - return 0; - } - - displays:: - - - Trace main.cxx [8] : Salome - - Trace main.cxx [12] : Aster and CASTEM - -**BEGIN_OF(func_name)** - In _DEBUG_ compiling mode, The C++ macro BEGIN_OF - appends the string "Begin of " to the one passed in - argument by the user and displays the result on the - trace buffer pool. In _RELEASE_ compiling mode, this - macro is blank. - - Example:: - - #include "utilities.h" - int main(int argc , char **argv) - { - BEGIN_OF(argv[0]); - return 0; - } - - displays:: - - - Trace main.cxx [3] : Begin of a.out - - -**END_OF(func_name)** - In _DEBUG_ compiling mode, The C++ macro END_OF appends - the string "Normal end of " to the one passed in - argument by the user and displays the result on the - trace buffer pool. In _RELEASE_ compiling mode, this - macro is blank. - - Example:: - - #include "utilities.h" - int main(int argc , char **argv) - { - END_OF(argv[0]); - return 0; - } - - displays:: - - - Trace main.cxx [4] : Normal end of a.out - -**SCRUTE(var)** - In _DEBUG_ compiling mode, The C++ macro SCRUTE - displays its argument which is an application variable - followed by the value of the variable. In _RELEASE_ - compiling mode, this macro is blank. - - Example:: - - #include "utilities.h" - int main(int argc , char **argv) - { - const int i=999; - if( i > 0 ) SCRUTE(i) ; i=i+1; - return 0; - } - - displays:: - - - Trace main.cxx [5] : i=999 - -**ASSERT(condition)** - In _DEBUG_ compiling mode only, The C++ macro ASSERT - checks the expression passed in argument to be not - NULL. If it is NULL the condition is written with the - macro INTERRUPTION (see above). The process exits after - trace of this last message. In _RELEASE_ compiling - mode, this macro is blank. N.B. : if ASSERT is already - defined, this macro is ignored. - - Example:: - - #include "utilities.h" - ... - const char *ptrS = fonc(); - ASSERT(ptrS!=NULL); - cout << strlen(ptrS); - float table[10]; - int k; - ... - ASSERT(k<10); - cout << table[k]; - -Exceptions -========== - -C++ exceptions: class SALOME_Exception --------------------------------------- - -definition -~~~~~~~~~~ - -The class SALOME_Exception provides a generic method to -send a message, with optional source file name and line -number. This class is intended to serve as a base class -for all kinds of exceptions SALOME code. All the -exceptions derived from SALOME_Exception could be -handled in a single catch, in which the message -associated to the exception is displayed, or sent to a -log file. - -The class SALOME_Exception inherits its behavior from -the STL class exception. - -usage -~~~~~ - -The header SALOME/src/utils/utils_SALOME_Exception.hxx -must be included in the C++ source, when raised or trapped:: - - #include "utils_SALOME_Exception.hxx" - -The SALOME_Exception constructor is:: - - SALOME_Exception( const char *text, - const char *fileName=0, - const unsigned int lineNumber=0 ); - -The exception is raised like this:: - - throw SALOME_Exception("my pertinent message"); - -or like this:: - - throw SALOME_Exception(LOCALIZED("my pertinent message")); - -where LOCALIZED is a macro provided with -``utils_SALOME_Exception.hxx`` which gives file name and -line number. - -The exception is handled like this:: - - try - { - ... - } - catch (const SALOME_Exception &ex) - { - cerr << ex.what() <::Instance() ; - assert(ptrPoint!=NULL) ; - -No need to delete ptrPoint. Deletion is achieved -automatically at exit. If the user tries to create more -than one singleton by using the class method -SINGLETON_::Instance(), the pointer is returned -with the same value even if this is done in different -functions (threads ?):: - - POINT *p1=SINGLETON_::Instance() ; - ... - POINT *p2=SINGLETON_::Instance() ; - - assert(p1==p2) - -Design description -~~~~~~~~~~~~~~~~~~ - -Here are the principles features of the singleton -design: - -* the user creates an object of class TYPE by using the - class method ``SINGLETON_::Instance()`` which - returns a pointer to the single object ; - -* to create an object, ``SINGLETON_::Instance()`` - uses the default constructor of class TYPE ; - -* at the same time, this class method creates a - destructor object which is added to the generic list - of destructor objects to be executed at the end of - the application (atexit) ; - -* at the end of the application process all the - deletions are performed by the ``Nettoyage()`` C function - which executes the destruction objects end then - deletes the destructions objects themselves ; - -* the ``Nettoyage()`` C function using ``atexit()`` C function - is embedded in a static single object ``ATEXIT_()``. - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/doc/rst.css b/doc/rst.css deleted file mode 100644 index 38bd7dcab..000000000 --- a/doc/rst.css +++ /dev/null @@ -1,288 +0,0 @@ -/* -:Authors: David Goodger, David Abrahams -:Contact: goodger@users.sourceforge.net, dave@boost-consulting.com -:date: $Date$ -:version: $Revision$ -:copyright: This stylesheet has been placed in the public domain. - -This stylesheet is for the use of ReStructuredText in a Boost context. -It is basically an agglomeration of boost.css and the default.css that -comes from docutils. - - */ - -.first { - margin-top: 0 } - -.last { - margin-bottom: 0 } - -a.toc-backref { - text-decoration: none ; - color: #00008B } - -dd { - margin-bottom: 0.5em } - -div.abstract { - margin: 2em 5em } - -div.abstract p.topic-title { - font-weight: bold ; - text-align: center } - -div.attention, div.caution, div.danger, div.error, div.hint, -div.important, div.note, div.tip, div.warning, div.admonition { - margin: 2em ; - border: medium outset ; - padding: 1em } - -div.attention p.admonition-title, div.caution p.admonition-title, -div.danger p.admonition-title, div.error p.admonition-title, -div.warning p.admonition-title { - color: red ; - font-weight: bold ; - font-family: sans-serif } - -div.hint p.admonition-title, div.important p.admonition-title, -div.note p.admonition-title, div.tip p.admonition-title, -div.admonition p.admonition-title { - font-weight: bold ; - font-family: sans-serif } - -div.dedication { - margin: 2em 5em ; - text-align: center ; - font-style: italic } - -div.dedication p.topic-title { - font-weight: bold ; - font-style: normal } - -div.figure { - margin-left: 2em } - -div.footer, div.header { - font-size: smaller } - -div.sidebar { - margin-left: 1em ; - border: medium outset ; - padding: 0em 1em ; - background-color: #ffffee ; - width: 40% ; - float: right ; - clear: right } - -div.sidebar p.rubric { - font-family: sans-serif ; - font-size: medium } - -div.system-messages { - margin: 5em } - -div.system-messages h1 { - color: red } - -div.system-message { - border: medium outset ; - padding: 1em } - -div.system-message p.system-message-title { - color: red ; - font-weight: bold } - -div.topic { - margin: 2em } - -H1.title -{ - FONT-SIZE: 150%; - COLOR: #00008B; - text-align: center -} -H1 -{ - FONT-SIZE: 125%; -} -H2 -{ - FONT-SIZE: 108%; -} -h2.subtitle { - text-align: center } -H3 -{ - FONT-SIZE: 100%; -} -BODY -{ - FONT-SIZE: 100%; - BACKGROUND-COLOR: #ffffff; -} -PRE -{ - MARGIN-LEFT: 2em; - FONT-FAMILY: Courier; -} -CODE -{ - FONT-FAMILY: Courier; - white-space: pre; -} -.pre -{ - FONT-FAMILY: Courier; - white-space: pre; -} -.index -{ - TEXT-ALIGN: left; -} -.page-index -{ - TEXT-ALIGN: left; -} -.definition -{ - TEXT-ALIGN: left; -} -.footnote -{ - FONT-SIZE: 66%; - VERTICAL-ALIGN: super; - TEXT-DECORATION: none; -} -.function-semantics -{ - CLEAR: left; -} - -hr { - width: 75% } - -ol.simple, ul.simple { - margin-bottom: 1em } - -ol.arabic { - list-style: decimal } - -ol.loweralpha { - list-style: lower-alpha } - -ol.upperalpha { - list-style: upper-alpha } - -ol.lowerroman { - list-style: lower-roman } - -ol.upperroman { - list-style: upper-roman } - -p.attribution { - text-align: right ; - margin-left: 50% } - -p.caption { - font-style: italic } - -p.credits { - font-style: italic ; - font-size: smaller } - -p.label { - white-space: nowrap } - -p.rubric { - font-weight: bold ; - font-size: larger ; - color: maroon ; - text-align: center } - -p.sidebar-title { - font-family: sans-serif ; - font-weight: bold ; - font-size: larger } - -p.sidebar-subtitle { - font-family: sans-serif ; - font-weight: bold } - -p.topic-title { - font-weight: bold } - -pre.address { - margin-bottom: 0 ; - margin-top: 0 ; - font-family: serif ; - font-size: 100% } - -pre.line-block { - font-family: serif ; - font-size: 100% } - -pre.literal-block, pre.doctest-block { - margin-left: 2em ; - margin-right: 2em ; - font-size: 80%; - border: solid thin gray ; - background-color: #eeeeee } - -span.classifier { - font-family: sans-serif ; - font-style: oblique } - -span.classifier-delimiter { - font-family: sans-serif ; - font-weight: bold } - -span.interpreted { - font-family: sans-serif } - -span.option { - white-space: nowrap } - -span.option-argument { - font-style: italic } - -span.pre { - white-space: pre } - -span.problematic { - color: red } - -table { - margin-top: 0.5em ; - margin-bottom: 0.5em } - -table.citation { - border-left: solid thin gray ; - padding-left: 0.5ex } - -table.docinfo { - margin: 2em 4em } - -table.footnote { - border-left: solid thin black ; - padding-left: 0.5ex } - -td, th { - padding-left: 0.5em ; - padding-right: 0.5em ; - vertical-align: top } - -th.docinfo-name, th.field-name { - font-weight: bold ; - text-align: left ; - white-space: nowrap } - -/* - dwa 2003/7/29 -- commented out so that it wouldn't override earlier - styles from boost.css - -h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt { - font-size: 100% } -*/ - -ul.auto-toc { - list-style-type: none } diff --git a/doc/salome/kernelpypkg.dox b/doc/salome/kernelpypkg.dox new file mode 100644 index 000000000..0b38f0445 --- /dev/null +++ b/doc/salome/kernelpypkg.dox @@ -0,0 +1,14 @@ +/*! + +\page kernelpypkg_page Programming Interface of the KERNEL python package + +Sorry, but the documentation is not available yet in doxygen format. + +Fortunately, a documentation exists in restructured format and then +can be generated here using sphinx, in the expectative of the doxygen +version. + +Please refer to this +documentation of the KERNEL python packages. + +*/ diff --git a/doc/salome/main.dox b/doc/salome/main.dox index 34311ed4f..34774389d 100644 --- a/doc/salome/main.dox +++ b/doc/salome/main.dox @@ -55,6 +55,7 @@ - \subpage kernel_salome - \subpage dsc_page : DSC documentation page. - \subpage salome_file_page : Salome_file documentation page. + - \subpage kernelpypkg_page : Documentation of the KERNEL python packages */ diff --git a/doc/txt2html.sh b/doc/txt2html.sh deleted file mode 100755 index 16b6c3628..000000000 --- a/doc/txt2html.sh +++ /dev/null @@ -1,55 +0,0 @@ -#!/bin/sh -# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE -# -# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, -# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS -# -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 2.1 of the License. -# -# This library 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 -# Lesser General Public License for more details. -# -# You should have received a copy of the GNU Lesser General Public -# License along with this library; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -# -# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com -# - -# =================================================================== -# This shell script is provided for generating the html files -# from the txt files (restructured text) in the source directory. -# Usage: just execute the script where it stands in the source -# directory. The file list has to be updated manually when adding -# a new restructured text file. -# Note that the building process executes a target rstdoc that -# generates the html documentation without need of this script. -# The autoconficuration (check_htmlgen.m4) set the correct generator -# rst2html by replacing the @RST2HTML@ tag. -# =================================================================== -# (CSSI - gboulant - 25/10/05) -# This must be updated manually in this script (for source usage only) -# -RST2HTML=rst2html - -FILELIST="index - UnitTests - SALOME_Application - INSTALL - kernel_resources - userguide" - -STYLESHEET=rst.css -RSTOPTS="--output-encoding=latin1 --stylesheet=$STYLESHEET" - -for file in $FILELIST; do - bfn=`basename $file .txt` - echo "Generating ${bfn}.html from ${bfn}.txt ..." - $RST2HTML $RSTOPTS ${bfn}.txt ${bfn}.html -done - diff --git a/doc/userguide.txt b/doc/userguide.txt deleted file mode 100644 index b7134e840..000000000 --- a/doc/userguide.txt +++ /dev/null @@ -1,146 +0,0 @@ -================================================================= -User's guide, for developpers and users -================================================================= - -*html version of this document is produced with docutils*:: - - rst2html < doc.txt > doc.html - -*This document corresponds to SALOME2 3.1.0* -*NOT UP TO DATE with 3.2.0* - -.. contents:: -.. sectnum:: - -+-------------------------------------------+ -| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | -+-------------------------------------------+ - -------------------------------------------------------------------------------- - -This guide provides you with some basic concepts for developing and -using the SALOME platform. You will find some information on the -general technical architecture ... - -Introduction -============ - -General information -------------------- - -This document has been initialized by collecting and updating an existing -documentation. The restructured text format has been selected for -writing. This format can be read with a basic editor except for -pictures and some hypertext links. You can build the html pages using -the docutils scripts provided with python packages on most platform. - -Definitions ------------ - -``WORK IN PROGRESS`` - -Module - definition of a module and/or link to the definition - -Container - definition of a container - - -General concepts -================ -modules et dépendances (s'inspirer de PYHELLO) - - -Filesystem organisation -======================== - -Voir doc de JR "Organisation de la plate-forme" - -A typical source working directory ----------------------------------- -organisation type des sources d'un module standard (spécifications techniques) - -A typical installation directory --------------------------------- -organisation type des produits installés - - -Building process -================ -Procédures de compilation (renvoie au install.sh) - - -Developer's guide - basic concepts -========================================= - -Guide du développeur: éléments de conception - - zoom sur certains éléments techniques bons à connaitre pour faire - évoluer le KERNEL sans tout casser. - - les ressources du kernel: - - trace, debug, exception (cf. kernel_ressources.tex) - - classes batch (présentation puis renvoi à la doc d'Ivan) - - développement de tests unitaires - -Developer's guide - managing the development space -================================================== - -- Guide du développeur: gestion de l'espace de développement - - principe de mise en oeuvre (rôle des étapes: build_configure, ...) - - description des fichiers m4 et du principe de mise en oeuvre - - les Makefile.in, ... (cf. doc guide du développeur). - - évolution des procédures de construction - - personalisation des procédures de construction - -Developer' guide - integration tools -==================================== -- Guide de l'intégrateur (développeur de nouveaux modules) -(on lui montre ici le principe de construction et les ressources à -disposition pour faire le travail) - - création d'un modules - - intégration code boîte noire (perfect, solver) - - intégration bibliothèque de fonctions (hxx2salome, voir avec - N.Crouzet) - - intégration de modèles de données (xdata) - - -End user's guide -================ -- Guide de l'utilisateur - - concept d'application (renvoie doc Paul) - - commandes avancées (showNS, exemple de contact de la - session, d'un engine, utilisation du lifeCycle, du module salome, - des modules geompy et smesh) - - utilisation en mode distribué (doc de B. Sechet) - - GUI and TUI documentation - - - - - - - - - - - - - - - -RST Exemples -============ - -See INSTALL_ for general information on required configuration and -prerequisites, compilation procedure, setting environment principles. - -.. _INSTALL: ./INSTALL.html - - -------------------------------------------------------------------------------- - -+----------------------------------+------------------------------------------+ -| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ | -+----------------------------------+------------------------------------------+ - -.. _`General KERNEL documentation`: ./index.html -.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html diff --git a/idl/Makefile.am b/idl/Makefile.am index 29090407f..3469930a3 100644 --- a/idl/Makefile.am +++ b/idl/Makefile.am @@ -42,6 +42,7 @@ BASEIDL_FILES = \ SALOME_Registry.idl \ Logger.idl \ SALOME_GenericObj.idl \ + SALOME_Types.idl \ SALOME_Session.idl \ SALOME_TestModuleCatalog.idl \ nstest.idl \ @@ -93,6 +94,7 @@ BASEIDL_SOURCES =\ SALOME_RegistrySK.cc \ LoggerSK.cc \ SALOME_GenericObjSK.cc \ + SALOME_TypesSK.cc \ SALOME_SessionSK.cc \ SALOME_TestModuleCatalogSK.cc \ nstestSK.cc \ @@ -109,7 +111,7 @@ DYNIDL_SRCS = \ SALOME_PortsDynSK.cc Calcium_PortsDynSK.cc SALOME_ContainerManagerDynSK.cc \ SALOME_CommDynSK.cc SALOME_RegistryDynSK.cc SALOME_ModuleCatalogDynSK.cc \ SALOMEDSDynSK.cc SALOME_SessionDynSK.cc SALOME_RessourcesCatalogDynSK.cc \ - DSC_EnginesDynSK.cc SALOME_ComponentDynSK.cc SALOME_GenericObjDynSK.cc \ + DSC_EnginesDynSK.cc SALOME_ComponentDynSK.cc SALOME_GenericObjDynSK.cc SALOME_TypesDynSK.cc \ Palm_PortsDynSK.cc SALOME_ExceptionDynSK.cc SALOMEDS_AttributesDynSK.cc \ LoggerDynSK.cc SALOME_PACOExtensionDynSK.cc SALOME_ParamPortsDynSK.cc SALOME_PyNodeDynSK.cc SALOME_ObserverDynSK.cc diff --git a/idl/SALOMEDS.idl b/idl/SALOMEDS.idl index 0699b8985..d2a927d4f 100644 --- a/idl/SALOMEDS.idl +++ b/idl/SALOMEDS.idl @@ -816,7 +816,6 @@ Searches for a definite %SObject with a definite GUID and returns True if it fin \param theValue The value to be set to the IOR attribute. */ void SetIOR(in SObject theSO, in string theValue) raises (LockProtection); - }; //========================================================================== diff --git a/idl/SALOME_ContainerManager.idl b/idl/SALOME_ContainerManager.idl index ed5c9796e..88385755b 100644 --- a/idl/SALOME_ContainerManager.idl +++ b/idl/SALOME_ContainerManager.idl @@ -216,7 +216,7 @@ interface ContainerManager //! GiveContainer - use mode parameter of ContainerParameters to configure //! how this method works //! Currently: get, start, getorstart, findorstart, find - Container GiveContainer(in ContainerParameters params); + Container GiveContainer(in ContainerParameters params) raises (SALOME::SALOME_Exception); //! Shutdown all containers that have been launched by the container manager void ShutdownContainers(); diff --git a/idl/SALOME_Types.idl b/idl/SALOME_Types.idl new file mode 100644 index 000000000..c0b8a05ac --- /dev/null +++ b/idl/SALOME_Types.idl @@ -0,0 +1,31 @@ +// Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +// +// This library is free software; you can redistribute it and/or +// modify it under the terms of the GNU Lesser General Public +// License as published by the Free Software Foundation; either +// version 2.1 of the License. +// +// This library 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 +// Lesser General Public License for more details. +// +// You should have received a copy of the GNU Lesser General Public +// License along with this library; if not, write to the Free Software +// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +// +// See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +// + +#ifndef __SALOME_TYPES_IDL__ +#define __SALOME_TYPES_IDL__ + +module SALOME_TYPES +{ + typedef sequence ListOfLong; + typedef sequence ListOfDouble; + typedef sequence ListOfString; + typedef sequence ListOfDouble2; +}; + +#endif diff --git a/salome_adm/cmake_files/FindMPI.cmake b/salome_adm/cmake_files/FindMPI.cmake index 548b01b77..29155aab6 100644 --- a/salome_adm/cmake_files/FindMPI.cmake +++ b/salome_adm/cmake_files/FindMPI.cmake @@ -80,6 +80,7 @@ IF(MPI_STATUS) MESSAGE(STATUS "MPI include ${MPI_INCLUDE_TO_FIND} found in ${MPI_INCLUDES}") + SET(MPI_INCLUDE_DIR ${MPI_INCLUDES}) SET(MPI_INCLUDES -I${MPI_INCLUDES}) # ------ @@ -91,9 +92,13 @@ IF(MPI_STATUS) FOREACH(lib mpi_cxx mpi mpich) FIND_LIBRARY(MPI_LIB ${lib} ${MPI_ROOT}/lib) IF(MPI_LIB) + IF(lib STREQUAL mpi_cxx) + SET(MPI_INCLUDES ${MPI_INCLUDES} -DOMPI_IGNORE_CXX_SEEK) + ENDIF(lib STREQUAL mpi_cxx) IF(lib STREQUAL mpich) SET(MPI_INCLUDES ${MPI_INCLUDES} -DMPICH_IGNORE_CXX_SEEK) ENDIF(lib STREQUAL mpich) + BREAK() ENDIF(MPI_LIB) ENDFOREACH(lib mpi_cxx mpi mpich) IF(NOT MPI_LIB) @@ -110,6 +115,18 @@ ENDIF(MPI_STATUS) # ------ +IF(MPI_STATUS) + include(CheckSymbolExists) + SET(CMAKE_REQUIRED_LIBRARIES ${MPI_LIBS}) + CHECK_SYMBOL_EXISTS(MPI_Publish_name ${MPI_INCLUDE_DIR}/mpi.h MPI2_IS_OK) + IF(MPI2_IS_OK) + MESSAGE(STATUS "Your mpi implemtentation is compatible with mpi2 ... adding -DHAVE_MPI2") + SET(MPI_INCLUDES ${MPI_INCLUDES} -DHAVE_MPI2) + ENDIF(MPI2_IS_OK) +ENDIF(MPI_STATUS) + +# ------ + IF(MPI_STATUS) SET(MPI_IS_OK ON) ELSE(MPI_STATUS) diff --git a/salome_adm/cmake_files/FindPLATFORM.cmake b/salome_adm/cmake_files/FindPLATFORM.cmake index f467aae1a..5feb823ad 100644 --- a/salome_adm/cmake_files/FindPLATFORM.cmake +++ b/salome_adm/cmake_files/FindPLATFORM.cmake @@ -66,6 +66,7 @@ IF(WINDOWS) SET(PLATFORM_LIBADD ${PLATFORM_LIBADD} Ws2_32.lib) SET(PLATFORM_LIBADD ${PLATFORM_LIBADD} Userenv.lib) # At least for GEOM suit ELSE(WINDOWS) + SET(PLATFORM_CPPFLAGS ${PLATFORM_CPPFLAGS} -Wall) SET(PLATFORM_LIBADD ${PLATFORM_LIBADD} -ldl) ENDIF(WINDOWS) diff --git a/salome_adm/cmake_files/am2cmake.py b/salome_adm/cmake_files/am2cmake.py index b2c757193..5ee9e8e0f 100644 --- a/salome_adm/cmake_files/am2cmake.py +++ b/salome_adm/cmake_files/am2cmake.py @@ -438,6 +438,10 @@ class CMakeFile(object): ENDIF(COMMAND cmake_policy) """) # -- + newlines.append(""" + ENABLE_TESTING() + """) + # -- if self.module == "kernel": newlines.append(""" INCLUDE(${CMAKE_SOURCE_DIR}/salome_adm/cmake_files/FindPLATFORM.cmake) @@ -1255,6 +1259,43 @@ class CMakeFile(object): ENDFOREACH(input ${SIP_FILES}) ''') pass + + # -- + # For make check + # -- + for key in ["TESTS"]: + if self.__thedict__.has_key(key): + newlines.append(''' + SET(UNIT_TEST_PROG ${%s}) + '''%(key)) + self.__thedict__["UNIT_TEST_PROG"] = self.__thedict__[key] + pass + pass + key = "UNIT_TEST_PROG" + if self.__thedict__.has_key(key): + newlines.append(''' + FOREACH(input ${UNIT_TEST_PROG}) + GET_FILENAME_COMPONENT(ext ${input} EXT) + IF(ext STREQUAL .py) + SET(test ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/${input}) + ELSE(ext STREQUAL .py) + IF(WINDOWS) + SET(test ${CMAKE_CURRENT_BINARY_DIR}/${input}_exe.exe) + ELSE() + SET(test ${CMAKE_CURRENT_BINARY_DIR}/${input}_exe) + ENDIF() + ENDIF(ext STREQUAL .py) + ADD_TEST(${input} ${test}) + SET(fail_regex "KO") + SET_PROPERTY(TEST ${input} PROPERTY FAIL_REGULAR_EXPRESSION "${fail_regex}") + # IF(NOT WINDOWS) + # ADD_TEST(${input}_valgrind valgrind ${test}) + # SET_PROPERTY(TEST ${input}_valgrind PROPERTY FAIL_REGULAR_EXPRESSION "${fail_regex}") + # SET_PROPERTY(TEST ${input}_valgrind PROPERTY PASS_REGULAR_EXPRESSION "no leaks are possible") + # ENDIF() + ENDFOREACH(input ${UNIT_TEST_PROG}) + ''') + pass # -- # Treat the install targets diff --git a/salome_adm/unix/config_files/Makefile.am b/salome_adm/unix/config_files/Makefile.am index 6cffbfca4..71cef5843 100644 --- a/salome_adm/unix/config_files/Makefile.am +++ b/salome_adm/unix/config_files/Makefile.am @@ -64,6 +64,7 @@ check_f77.m4 \ check_calcium.m4 \ check_hdf5.m4 \ check_htmlgen.m4 \ +check_sphinx.m4 \ check_lam.m4 \ check_libbatch.m4 \ check_mpi.m4 \ @@ -80,7 +81,8 @@ pyembed.m4 \ python.m4 \ check_libxml.m4 \ check_paco++.m4 \ -local_install.m4 +local_install.m4 \ +hack_libtool.m4 dist_salome4depr_DATA=\ $(DEPRECATED_FILES) diff --git a/salome_adm/unix/config_files/check_mpi.m4 b/salome_adm/unix/config_files/check_mpi.m4 index 4f9886cb4..d85f67727 100644 --- a/salome_adm/unix/config_files/check_mpi.m4 +++ b/salome_adm/unix/config_files/check_mpi.m4 @@ -82,6 +82,12 @@ if test x"$MPIREQUESTED" = xyes; then mpi_ok=no fi + if test "$WITHMPI2" = "yes";then + mpi2_ok=yes + else + mpi2_ok=no + fi + fi if test "$WITHMPI" = no; then @@ -127,5 +133,8 @@ AC_SUBST(WITHMPI) AC_SUBST(MPI_INCLUDES) AC_SUBST(MPI_LIBS) AC_SUBST(mpi_ok) +AC_SUBST(mpi2_ok) AM_CONDITIONAL(MPI_IS_OK, [test x"$mpi_ok" = xyes]) +AM_CONDITIONAL(MPI2_IS_OK, [test x"$mpi2_ok" = xyes]) + ])dnl diff --git a/salome_adm/unix/config_files/check_openmpi.m4 b/salome_adm/unix/config_files/check_openmpi.m4 index e2ae5b36c..419fdd4ed 100644 --- a/salome_adm/unix/config_files/check_openmpi.m4 +++ b/salome_adm/unix/config_files/check_openmpi.m4 @@ -52,11 +52,13 @@ if test "$WITHOPENMPI" = yes; then AC_MSG_CHECKING(for openmpi) if test "$WITHOPENMPI" = "yes";then mpi_ok=yes + mpi2_ok=$WITHMPI2 WITHMPI=yes CPPFLAGS="-DOMPI_IGNORE_CXX_SEEK -DWITHOPENMPI $CPPFLAGS" AC_MSG_RESULT(yes) else mpi_ok=no + mpi2_ok=no WITHMPI=no AC_MSG_RESULT(no) fi diff --git a/salome_adm/unix/config_files/check_swig.m4 b/salome_adm/unix/config_files/check_swig.m4 index 4d4f9df78..9d3717cf0 100644 --- a/salome_adm/unix/config_files/check_swig.m4 +++ b/salome_adm/unix/config_files/check_swig.m4 @@ -62,6 +62,7 @@ numpydir=`$PYTHON -c "import numpy;print numpy.get_include()" 2>/dev/null` if test -d "$numpydir"; then numpy_ok=yes PYTHON_INCLUDES="$PYTHON_INCLUDES -I$numpydir" + SWIG_FLAGS="$SWIG_FLAGS -DWITH_NUMPY=WITH_NUMPY " AC_DEFINE([WITH_NUMPY], [], [Python has numpy extension]) fi diff --git a/salome_adm/unix/config_files/hack_libtool.m4 b/salome_adm/unix/config_files/hack_libtool.m4 new file mode 100644 index 000000000..4ad515aab --- /dev/null +++ b/salome_adm/unix/config_files/hack_libtool.m4 @@ -0,0 +1,41 @@ +dnl Copyright (C) 2010 CEA/DEN, EDF R&D, OPEN CASCADE +dnl +dnl This library is free software; you can redistribute it and/or +dnl modify it under the terms of the GNU Lesser General Public +dnl License as published by the Free Software Foundation; either +dnl version 2.1 of the License. +dnl +dnl This library is distributed in the hope that it will be useful, +dnl but WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +dnl Lesser General Public License for more details. +dnl +dnl You should have received a copy of the GNU Lesser General Public +dnl License along with this library; if not, write to the Free Software +dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +dnl +dnl See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +dnl + +dnl --- +dnl File : hack_libtool.m4 +dnl Author : Vadim SANDLER, Open CASCADE S.A.S. (vadim.sandler@opencascade.com) +dnl --- +dnl +dnl The purpose of below autoconf macro is to workaround very annoying problem +dnl of the GNU libtool program. The problem leads to the incorrect linking +dnl to the native libraries (installed in /usr/lib[64]) instead of those supplied +dnl with specific -Ldir options. + +AC_DEFUN([AC_HACK_LIBTOOL],[ +sed -i "s%^CC=\"\(.*\)\"%function hack_libtool { \n\ + if test \"\$(echo \$[@] | grep -E '\\\-L/usr/lib(/../lib)?(64)? ')\" == \"\" \n\ + then\n\ + cmd=\"\1 \$[@]\"\n\ + else\n\ + cmd=\"\1 \"\`echo \$[@] | sed -r -e 's|(.*)-L/usr/lib(/../lib)?(64)? (.*)|\\\1\\\4 -L/usr/lib\\\3|g'\`\n\ + fi\n\ + \$cmd\n\ +}\n\ +CC=\"hack_libtool\"%g" libtool +]) diff --git a/salome_adm/unix/make_common_starter.am b/salome_adm/unix/make_common_starter.am index 198595381..d1ebd26cd 100644 --- a/salome_adm/unix/make_common_starter.am +++ b/salome_adm/unix/make_common_starter.am @@ -44,9 +44,17 @@ salomeincludedir = $(includedir)/salome libdir = $(prefix)/lib@LIB_LOCATION_SUFFIX@/salome bindir = $(prefix)/bin/salome salomescriptdir = $(bindir) +# _GBO_SALOME_PYTHON_PACKAGING_ +# Maybe we could try to suppress on stage in this folder path, for +# example by installing by default the python files in site-packages +# folder. Then, python packages could be installed in the +# site-packages/salome folder (main package containing the root +# __init__.py file). This could be done by replacing salomepythondir +# and salomepyexecdir by pythondir and pyexecdir respectively (TO BE +# DONE) salomepythondir = $(pythondir)/salome salomepyexecdir = $(pyexecdir)/salome - +salomepypkgdir = $(salomepythondir)/salome # Directory for installing idl files salomeidldir = $(prefix)/idl/salome diff --git a/src/KERNEL_PY/Makefile.am b/src/KERNEL_PY/Makefile.am index 8ec0e4f73..177977feb 100755 --- a/src/KERNEL_PY/Makefile.am +++ b/src/KERNEL_PY/Makefile.am @@ -36,7 +36,6 @@ if CORBA_GEN salomepython_PYTHON += \ Help.py \ PyInterp.py \ - salome.py \ batchmode_salome.py \ salome_test.py \ salome_kernel.py \ @@ -50,4 +49,11 @@ if CORBA_GEN salome_genericobj.py endif +# _GBO_SALOME_PYTHON_PACKAGING_ +# Note that the salome.py should not be installed any more +# Special extention to create a python packaging +SUBDIRS= kernel +salomepypkg_PYTHON= \ + __init__.py + sharedpkgpython_PYTHON = kernel_shared_modules.py diff --git a/src/KERNEL_PY/__init__.py b/src/KERNEL_PY/__init__.py new file mode 100644 index 000000000..2c8755ecd --- /dev/null +++ b/src/KERNEL_PY/__init__.py @@ -0,0 +1,218 @@ +# -*- coding: iso-8859-1 -*- +# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +# +# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, +# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS +# +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License. +# +# This library 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 +# Lesser General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# +# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +# + +# File : salome.py renamed as __init__.py for python packaging (gboulant) +# Author : Paul RASCLE, EDF +# Module : SALOME +# $Header$ +# +""" +Module salome gives access to Salome ressources. + +variables: + + - salome.orb : CORBA + - salome.naming_service : instance of naming Service class + - methods: + - Resolve(name) : find a CORBA object (ior) by its pathname + - Register(name) : register a CORBA object under a pathname + + - salome.lcc : instance of lifeCycleCORBA class + - methods: + - FindOrLoadComponent(server,name) : + obtain an Engine (CORBA object) + or launch the Engine if not found, + with a Server name and an Engine name + + - salome.sg : salome object to communicate with the graphical user interface (if any) + - methods: + - updateObjBrowser(bool): + - getActiveStudyId(): + - getActiveStudyName(): + + - SelectedCount(): returns number of selected objects + - getSelected(i): returns entry of selected object number i + - getAllSelected(): returns list of entry of selected objects + - AddIObject(Entry): select an existing Interactive object + - RemoveIObject(Entry): remove object from selection + - ClearIObjects(): clear selection + + - Display(*Entry): + - DisplayOnly(Entry): + - Erase(Entry): + - DisplayAll(): + - EraseAll(): + + - IDToObject(Entry): returns CORBA reference from entry + + - salome.myStudyName : active Study Name + - salome.myStudyId : active Study Id + - salome.myStudy : the active Study itself (CORBA ior) + - methods : defined in SALOMEDS.idl + +""" +## @package salome +# Module salome gives access to Salome ressources. +# +# \param salome.orb : CORBA orb object +# \param salome.naming_service : instance of naming Service class (SALOME_NamingServicePy::SALOME_NamingServicePy_i) +# \param salome.lcc : instance of lifeCycleCORBA class (SALOME_LifeCycleCORBA) +# \param salome.sg : Salome object to communicate with the graphical user interface, if running (see interface in salome_iapp::SalomeOutsideGUI) +# \param salome.myStudyName : active Study Name +# \param salome.myStudyId : active Study Id +# \param salome.myStudy : the active Study (interface SALOMEDS::Study) + +# +# ========================================================================== +# +# The function extend_path is used here to aggregate in a single +# virtual python package all the python sub-packages embedded in each +# SALOME modules (python "namespace" pattern). +# +ROOT_PYTHONPACKAGE_NAME="salome" +# +# This root package name is expected to be found as a directory in +# some paths of the sys.path variable, especially the paths +# /lib/pythonX.Y/site-packages/salome where are +# installed the python files. These paths are theorically appended by +# the SALOME main runner and should be in the sys.path at this point +# of the application. The extend_path is looking then for directories +# of the type: +# +# /lib/pythonX.Y/site-packages/salome/ +# +# And append them to the sys.path. These directories are supposed to +# be the pieces to be aggregated as a single virtual python package. +# +import os, sys +MATCH_ENDING_PATTERN="site-packages/salome" +def extend_path(pname): + for dir in sys.path: + if not isinstance(dir, basestring) or not os.path.isdir(dir) or not dir.endswith(MATCH_ENDING_PATTERN): + continue + subdir = os.path.join(dir, pname) + # XXX This may still add duplicate entries to path on + # case-insensitive filesystems + if os.path.isdir(subdir) and subdir not in __path__: + print "INFO - The directory %s is appended to sys.path" % subdir + __path__.append(subdir) + +extend_path(ROOT_PYTHONPACKAGE_NAME) +# ========================================================================== +# + +from salome_kernel import * +from salome_study import * +from salome_iapp import * + +# +# The next block is workaround for the problem of shared symbols loading for the extension modules (e.g. SWIG-generated) +# that causes RTTI unavailable in some cases. To solve this problem, sys.setdlopenflags() function is used. +# Depending on the Python version and platform, the dlopen flags can be defined in the dl, DLFUN or ctypes module. +# +import sys +flags = None +if not flags: + try: + # dl module can be unavailable + import dl + flags = dl.RTLD_NOW | dl.RTLD_GLOBAL + except: + pass + pass +if not flags: + try: + # DLFCN module can be unavailable + import DLFCN + flags = DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL + except: + pass + pass +if not flags: + try: + # ctypes module can be unavailable + import ctypes + flags = ctypes.RTLD_GLOBAL + except: + pass + pass + +if flags: + sys.setdlopenflags(flags) + pass + +orb, lcc, naming_service, cm,sg=None,None,None,None,None +myStudyManager, myStudyId, myStudy, myStudyName=None,None,None,None + +salome_initial=1 +def salome_init(theStudyId=0,embedded=0): + """ + Performs only once SALOME general purpose intialisation for scripts. + optional argument : theStudyId + When in embedded interpreter inside IAPP, theStudyId is not used + When used without GUI (external interpreter) + 0 : create a new study (default). + n (>0) : try connection to study with Id = n, or create a new one + if study not found. + If study creation, its Id may be different from theStudyId ! + Provides: + orb reference to CORBA + lcc a LifeCycleCorba instance + naming_service a naming service instance + cm reference to the container manager + sg access to SALOME GUI (when linked with IAPP GUI) + myStudyManager the study manager + myStudyId active study identifier + myStudy active study itself (CORBA reference) + myStudyName active study name + """ + global salome_initial + global orb, lcc, naming_service, cm + global sg + global myStudyManager, myStudyId, myStudy, myStudyName + + try: + if salome_initial: + salome_initial=0 + sg = salome_iapp_init(embedded) + orb, lcc, naming_service, cm = salome_kernel_init() + myStudyManager, myStudyId, myStudy, myStudyName =salome_study_init(theStudyId) + pass + pass + except RuntimeError, inst: + # wait a little to avoid trace mix + import time + time.sleep(0.2) + x = inst + print "salome.salome_init():", x + print """ + ============================================ + May be there is no running SALOME session + salome.salome_init() is intented to be used + within an already running session + ============================================ + """ + raise + +#to expose all objects to pydoc +__all__=dir() diff --git a/src/KERNEL_PY/kernel/Makefile.am b/src/KERNEL_PY/kernel/Makefile.am new file mode 100644 index 000000000..9152084da --- /dev/null +++ b/src/KERNEL_PY/kernel/Makefile.am @@ -0,0 +1,11 @@ +include $(top_srcdir)/salome_adm/unix/make_common_starter.am + +mypkgpythondir =$(salomepypkgdir)/kernel + +mypkgpython_PYTHON = \ + __init__.py \ + deprecation.py \ + logger.py \ + studyedit.py \ + termcolor.py \ + logconfig.py diff --git a/src/KERNEL_PY/kernel/__init__.py b/src/KERNEL_PY/kernel/__init__.py new file mode 100644 index 000000000..7527b3e7b --- /dev/null +++ b/src/KERNEL_PY/kernel/__init__.py @@ -0,0 +1,2 @@ +# -*- coding: iso-8859-1 -*- +__all__ = [ "deprecation", "logger", "termcolor", "studyedit", "logconfig" ] diff --git a/src/KERNEL_PY/kernel/deprecation.py b/src/KERNEL_PY/kernel/deprecation.py new file mode 100644 index 000000000..a99b2713a --- /dev/null +++ b/src/KERNEL_PY/kernel/deprecation.py @@ -0,0 +1,116 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2007-2009 EDF R&D +# +# This file is part of PAL_SRC. +# +# PAL_SRC 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 2 of the License, or +# (at your option) any later version. +# +# PAL_SRC 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 PAL_SRC; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# +""" +This module provides several functions to indicate the deprecation of a +module, a method or a function. This is a temporary module to be used only +during PAL refactoring. +""" + +import sys +import warnings +import inspect +import os + +from salome.kernel import termcolor + +msg_seedoc = "See PAL refactoring documentation for possible replacements." + +def __deprecated_with_msg(func, msg): + + def new_func(*args, **kwargs): + if len(inspect.stack()) > 1: + callingfunc = inspect.stack()[1][3] + else: + callingfunc = "CORBA middleware" + warnings.warn( + ("Call to deprecated function %(funcname)s of module " + + "%(modname)s (called from %(callingfunc)s).\n %(msg)s") % { + 'funcname': func.__name__, + 'modname': func.__module__, + 'callingfunc': callingfunc, + 'msg': msg, + }, + category = DeprecationWarning, + stacklevel = 2 + ) + return func(*args, **kwargs) + return new_func + +def deprecated(msg = msg_seedoc): + """ + This is a decorator which can be used to mark functions + as deprecated. It will result in a warning being emitted + when the function is used. The message in parameter will + be displayed and should indicate how this function can be + replaced. If the terminal can display colors, the warning + messages will appear in blue. + """ + def make_dep(f): + if is_called_by_sphinx(): + return f + else: + g = __deprecated_with_msg(f, msg) + g.__name__ = f.__name__ + g.__doc__ = f.__doc__ + g.__dict__.update(f.__dict__) + return g + return make_dep + +def deprecated_module(msg = msg_seedoc): + """ + This function can be used to mark a module as deprecated. + It must be called explicitly at the beginning of the deprecated + module. It will result in a warning being emitted. The message + in parameter will be displayed and should indicate how this + module can be replaced. If the terminal can display colors, + the warning messages will appear in blue. + """ + if not is_called_by_sphinx(): + warnings.warn( + "Importation of deprecated module %(modname)s.\n %(msg)s" % { + 'modname': inspect.getmodulename(inspect.stack()[1][1]), + 'msg': msg, + }, + category = DeprecationWarning, + stacklevel = 5 + ) + +def is_called_by_sphinx(): + """ + Determine if the calling code is ultimately called by sphinx to generate + documentation. The result can be used to conditionally inhibit the + decorators or some Salome-related imports that fail when called outside + Salome. + """ + calling_file = inspect.stack()[len(inspect.stack())-1][1] + basename = os.path.basename(calling_file) + return (basename == "sphinx-build") + + +def __show_colored_warning(message, category, filename, + lineno, file = sys.stderr): + str = warnings.formatwarning(message, category, filename, lineno) + if category == DeprecationWarning and termcolor.canDisplayColor(file): + file.write(termcolor.makeColoredMessage(str, termcolor.BLUE)) + else: + file.write(str) + +warnings.showwarning = __show_colored_warning diff --git a/src/KERNEL_PY/kernel/logconfig.py.in b/src/KERNEL_PY/kernel/logconfig.py.in new file mode 100755 index 000000000..5f3a9d0a8 --- /dev/null +++ b/src/KERNEL_PY/kernel/logconfig.py.in @@ -0,0 +1,27 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2007-2009 EDF R&D +# +# This file is part of PAL_SRC. +# +# PAL_SRC 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 2 of the License, or +# (at your option) any later version. +# +# PAL_SRC 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 PAL_SRC; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# +""" +This module defines a variable to indicate which traces should be logged. +""" + +import logging + +loggingLevel = logging.@PYLOGLEVEL@ diff --git a/src/KERNEL_PY/kernel/logger.py b/src/KERNEL_PY/kernel/logger.py new file mode 100644 index 000000000..d2e42f56d --- /dev/null +++ b/src/KERNEL_PY/kernel/logger.py @@ -0,0 +1,220 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2007-2009 EDF R&D +# +# This file is part of PAL_SRC. +# +# PAL_SRC 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 2 of the License, or +# (at your option) any later version. +# +# PAL_SRC 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 PAL_SRC; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# + +#============================================================================= +# Author : Guillaume Boulant (CSSI) +# Rewritten by Renaud Barate (EDF R&D) +# Project : SALOME +# Copyright : EDF 2001-2009 +# $Header$ +#============================================================================= +""" +This module defines a class which provides logging facility in Salome: +""" + +import sys, os +import logging + +from salome.kernel import termcolor +import salome.kernel.logconfig + +class Logger(logging.Logger): + """ + This class formats and displays log messages in Salome environment. It + inherits :class:`Logger` class defined in :mod:`logging` + module from Python library, so all methods from :class:`logging.Logger` + can be used here. The format of the traces is: + + LEVEL [keyword] : Message + + where `LEVEL` is the level of the message (`DEBUG`, `INFO`, etc.), + `keyword` is the name of the logger, and `Message` is the message to log. + + When creating a new Logger object, the parameter `keyword` defines the + name of the logger, `level` defines the logging level (default is + :const:`logging.WARNING` if PAL module is configured with --disable-debug + option or :const:`logging.DEBUG` otherwise), and `color` defines the color + of the log messages for this logger (log messages will appear in color + only when displayed on color-capable ASCII terminals). See module + :mod:`salome.kernel.termcolor` for the color constants. + + By default, log messages will be displayed only on standard output. They + can also be recorded in a file (see method :meth:`setLogFile`). For now, + the CORBA-based logging facility can not be used through this class. + + A source filename `sourceFileName` can be defined. If this argument is + specified, then the `keyword` is modified to the basename of the `sourceFileName` + + Basic usage:: + + from salome.kernel.logger import Logger + log = Logger("Test") + log.debug("Debug message") + log.info("Information message") + log.warning("Warning message") + log.error("Error message") + log.critical("Fatal error message") + + """ + + def __init__(self, keyword = "KEY", level = salome.kernel.logconfig.loggingLevel, + color = None, sourceFileName=None): + + if sourceFileName is not None: + keyword = os.path.basename(sourceFileName).split('.')[0] + logging.Logger.__init__(self, keyword, level) + self._baseFormatString = "%(levelname)-8s [%(name)s] : %(message)s" + self._baseFormatter = logging.Formatter(self._baseFormatString) + if hasattr(sys.stdout, "flush"): + self._stdoutStream = sys.stdout + else: + self._stdoutStream = _UnFlushableLogStream(sys.stdout) + self._stdoutHandler = logging.StreamHandler(self._stdoutStream) + self._stdoutHandler.setLevel(logging.DEBUG) + self.setColor(color) + self.addHandler(self._stdoutHandler) + self._fileHandler = None + + def showDebug(self): + """ + Log all messages, including DEBUG level messages (equivalent to + ``setLevel(logging.DEBUG)``). + """ + self.setLevel(logging.DEBUG) + + def setLogFile(self, logFilename): + """ + Define a log file to record the log messages (in addition to the + standard output). + """ + self.closeLogFile() + self._fileHandler = logging.FileHandler(logFilename, 'w') + self._fileHandler.setLevel(logging.DEBUG) + self._fileHandler.setFormatter(self._baseFormatter) + self.addHandler(self._fileHandler) + + def setColor(self, color): + """ + Set the color of log messages on color-capable terminals. If `color` + is :const:`None`, the default color will be used. + """ + if color is None or not termcolor.canDisplayColor(self._stdoutStream): + stdoutFormatter = self._baseFormatter + else: + format = ("%s%s%s" % + (termcolor.getControlSequence(color), + self._baseFormatString, + termcolor.getControlSequence(termcolor.DEFAULT))) + stdoutFormatter = logging.Formatter(format) + self._stdoutHandler.setFormatter(stdoutFormatter) + + def closeLogFile(self): + """Close the log file.""" + if self._fileHandler is not None: + self.removeHandler(self._fileHandler) + self._fileHandler.close() + self._fileHandler = None + + def hideDebug(self): + """ + Hide DEBUG level messages (equivalent to ``setLevel(logging.INFO)``). + """ + self.setLevel(logging.INFO) + + def fatal(self, message): + """ + Log a message with CRITICAL level. This method only exists for + backward compatibility and is equivalent to ``critical(message)``. + """ + self.critical(message) + + +class _UnFlushableLogStream: + """ + This utility class allows to log messages to a stream with no `flush` + method. This is useful to send log messages to `PyOut` objects. + """ + + def __init__(self, stream): + self._stream = stream + + def write(self, msg): + self._stream.write(msg) + + def flush(self): + pass + + +class ExtLogger(Logger): + """ + This class extends :class:`Logger` class and adds exception information + when DEBUG messages are recorded. It exists mainly for backward + compatibility, as the same thing can be done by calling + ``Logger.debug(message, exc_info = True)``. + """ + + def debug( self, message ): + """ + Log a DEBUG message with exception information (equivalent to + ``Logger.debug(message, exc_info = True)``). + """ + Logger.debug(self, message, exc_info = True) + + +def TEST_Logger(): + """Test function for logger module""" + log = Logger("TST") + + # Base methods + log.info("Information message") + log.debug("Debug message") + log.fatal("Fatal error message") + + # Message building + data = 12 + log.info("This message displays data = " + str(data)) + + data = {} + data["KERNEL"] = "V1" + data["GEOM"] = "V2" + log.info("This message displays data = " + str(data)) + + # Test with a non-string parameter + log.info(data) + + # Test with a default instance + log = Logger() + log.info("Default logger") + + # Test showDebug method + log.setLogFile("test.log") + log.debug("Debug trace") + log.hideDebug() + log.debug("This trace should NOT be displayed") + log.showDebug() + log.debug("This trace should be displayed") + log.closeLogFile() + log.info("After closing the log file") + + +# Main function only used to test the module +if __name__ == "__main__": + TEST_Logger() diff --git a/src/KERNEL_PY/kernel/studyedit.py b/src/KERNEL_PY/kernel/studyedit.py new file mode 100644 index 000000000..d009e3fbd --- /dev/null +++ b/src/KERNEL_PY/kernel/studyedit.py @@ -0,0 +1,479 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2007-2009 EDF R&D +# +# This file is part of PAL_SRC. +# +# PAL_SRC 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 2 of the License, or +# (at your option) any later version. +# +# PAL_SRC 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 PAL_SRC; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# +""" +This module provides a new class :class:`StudyEditor` to complement +:class:`Study` and :class:`StudyBuilder` classes. +""" + +import re + +import salome +from salome.kernel.logger import Logger +from salome.kernel import termcolor +logger = Logger("salome.kernel.studyedit", color = termcolor.PURPLE) + +_editors = {} +_DEFAULT_CONTAINER = "FactoryServer" + +def getActiveStudyId(): + """ + Return the ID of the active study. In GUI mode, this function is equivalent + to ``salome.sg.getActiveStudyId()``. Outside GUI, it returns + ``salome.myStudyId`` variable. + """ + salome.salome_init() + if salome.hasDesktop(): + return salome.sg.getActiveStudyId() + else: + return salome.myStudyId + +def getStudyEditor(studyId = None): + """ + Return a :class:`StudyEditor` instance to edit the study with ID + `studyId`. If `studyId` is :const:`None`, return an editor for the current + study. + """ + if studyId is None: + studyId = getActiveStudyId() + if not _editors.has_key(studyId): + _editors[studyId] = StudyEditor(studyId) + return _editors[studyId] + + +class StudyEditor: + """ + This class provides utility methods to complement :class:`Study` and + :class:`StudyBuilder` classes. Those methods may be moved in those classes + in the future. The parameter `studyId` defines the ID of the study to + edit. If it is :const:`None`, the edited study will be the current study. + The preferred way to get a StudyEditor object is through the method + :meth:`getStudyEditor` which allows to reuse existing instances. + + .. attribute:: studyId + + This instance attribute contains the ID of the edited study. This + attribute should not be modified. + + .. attribute:: study + + This instance attribute contains the underlying :class:`Study` object. + It can be used to access the study but the attribute itself should not + be modified. + + .. attribute:: builder + + This instance attribute contains the underlying :class:`StudyBuilder` + object. It can be used to edit the study but the attribute itself + should not be modified. + + """ + def __init__(self, studyId = None): + salome.salome_init() + if studyId is None: + studyId = getActiveStudyId() + self.studyId = studyId + self.study = salome.myStudyManager.GetStudyByID(studyId) + if self.study is None: + raise Exception("Can't create StudyEditor object: " + "Study %d doesn't exist" % studyId) + self.builder = self.study.NewBuilder() + + def findOrCreateComponent(self, componentName, componentLabel=None, icon=None, + loadEngine = True, engineName = None, + containerName = _DEFAULT_CONTAINER): + """ + Find a component corresponding to the specified name `componentName` in the + study, or create it if none is found. Then eventually load the + corresponding engine and the CORBA objects of this component. + + :type componentName: string + :param componentName: name of the new component if created. The name is + a string used to identify the study component. + Generally, it corresponds to the name of the SALOME + module to be associated to this component. + + :type componentLabel: string + :param componentLabel: label of the new component if created. The label + is the string used in the object browser. + (attribute "AttributeName") + + :type icon: string + :param icon: icon for the new component (attribute "AttributePixMap"). + + :type loadEngine: boolean + :param loadEngine: If :const:`True`, find or load the corresponding + engine and associate it with the component. Default + is True. + + :type engineName: string + :param engineName: name of the engine to be associated to the component. + If :const:`None`, use `componentName` instead because + in most of the SALOME modules, the names are identical. + + :type containerName: string + :param containerName: name of the container in which the engine should be + loaded. + + :return: the SComponent found or created. + + """ + sComponent = self.study.FindComponent(componentName) + if sComponent is None: + sComponent = self.builder.NewComponent(componentName) + # Note that the NewComponent method set the "comment" attribute to the + # value of its argument (componentName here) + self.builder.SetName(sComponent, componentLabel) + if icon is not None: + # _MEM_ : This will be effective if and only if the componentName + # corresponds to the module name (as specified in the SalomeApp.xml) + self.setIcon(sComponent, icon) + + if engineName is None: + engineName = componentName + + engine = salome.lcc.FindOrLoadComponent(containerName,engineName) + self.builder.DefineComponentInstance(sComponent, engine) + + # An internal convention (in this class) is to store the name of the + # associated engine in the parameter attribute of the scomponent (so that + # it could be retrieved in a future usage of this scomponent, for example, + # for the need of the function loadComponentEngine). The comment attribute + # SHOULD NOT be used for this purpose because it's used by the SALOME + # resources manager to identify the SALOME module and then localized + # the resource files + attr = self.builder.FindOrCreateAttribute( sComponent, "AttributeParameter" ) + attr.SetString( "ENGINE_NAME", engineName ) + + if loadEngine: + self.loadComponentEngine(sComponent, containerName) + + return sComponent + + def loadComponentEngine(self, sComponent, + containerName = _DEFAULT_CONTAINER): + """ + Load the engine corresponding to `sComponent` in the container + `containerName`, associate the engine with the component and load the + CORBA objects of this component in the study. + """ + attr = self.builder.FindOrCreateAttribute( sComponent, "AttributeParameter" ) + engineName = attr.GetString( "ENGINE_NAME" ) + engine = salome.lcc.FindOrLoadComponent(containerName, + engineName) + self.builder.LoadWith(sComponent, engine) + + def getOrLoadObject(self, item): + """ + Get the CORBA object associated with the SObject `item`, eventually by + first loading it with the corresponding engine. + """ + object = item.GetObject() + if object is None: # the engine has not been loaded yet + sComponent = item.GetFatherComponent() + self.loadComponentEngine(sComponent) + object = item.GetObject() + return object + + def findOrCreateItem(self, fatherItem, name, fileType = None, + fileName = None, comment = None, icon = None, + IOR = None, typeId = None): + """ + Find an object under `fatherItem` in the study with the given + attributes. Return the first one found if at least one exists, + otherwise create a new one with the given attributes and return it. + + See :meth:`setItem` for the description of the parameters. + """ + sObject = self.findItem(fatherItem, name, fileType, fileName, comment, + icon, IOR, typeId) + if sObject is None: + sObject = self.createItem(fatherItem, name, fileType, fileName, + comment, icon, IOR, typeId) + return sObject + + def findItem(self, fatherItem, name = None, fileType = None, + fileName = None, comment = None, icon = None, IOR = None, + typeId = None): + """ + Find an item with given attributes under `fatherItem` in the study. If + none is found, return :const:`None`. If several items correspond to + the parameters, only the first one is returned. The search is made + only on given parameters (i.e. not :const:`None`). To look explicitly + for an empty attribute, use an empty string in the corresponding + parameter. + + See :meth:`setItem` for the description of the parameters. + """ + foundItem = None; + childIterator = self.study.NewChildIterator(fatherItem) + while childIterator.More() and foundItem is None: + childItem = childIterator.Value() + if childItem and \ + (name is None or childItem.GetName() == name) and \ + (fileType is None or \ + self.getFileType(childItem) == fileType) and \ + (fileName is None or \ + self.getFileName(childItem) == fileName) and \ + (comment is None or childItem.GetComment() == comment) and \ + (icon is None or \ + self.getIcon(childItem) == icon) and \ + (IOR is None or childItem.GetIOR() == IOR and \ + (typeId is None or \ + self.getTypeId(childItem) == typeId)): + foundItem = childItem + childIterator.Next() + return foundItem + + def createItem(self, fatherItem, name, fileType = None, fileName = None, + comment = None, icon = None, IOR = None, typeId = None): + """ + Create a new object named `name` under `fatherItem` in the study, with + the given attributes. If an object named `name` already exists under + the father object, the new object is created with a new name `name_X` + where X is the first available index. + + :type fatherItem: SObject + :param fatherItem: item under which the new item will be added. + + :return: new SObject created in the study + + See :meth:`setItem` for the description of the other parameters. + """ + aSObject = self.builder.NewObject(fatherItem) + + aChildIterator = self.study.NewChildIterator(fatherItem) + aMaxId = -1 + aLength = len(name) + aDelim = "_" + anIdRE = re.compile("^" + aDelim + "[0-9]+") + aNameRE = re.compile("^" + name) + while aChildIterator.More(): + aSObj = aChildIterator.Value() + aChildIterator.Next() + aName = aSObj.GetName() + if re.match(aNameRE,aName): + aTmp = aName[aLength:] + if re.match(anIdRE,aTmp): + import string + anId = string.atol(aTmp[1:]) + if aMaxId < anId: + aMaxId = anId + pass + pass + elif aMaxId < 0: + aMaxId = 0 + pass + pass + pass + + aMaxId = aMaxId + 1 + aName = name + if aMaxId > 0: + aName = aName + aDelim + str(aMaxId) + pass + + self.setItem(aSObject, aName, fileType, fileName, comment, icon, + IOR, typeId) + + return aSObject + + def setItem(self, item, name = None, fileType = None, fileName = None, + comment = None, icon = None, IOR = None, typeId = None): + """ + Modify the attributes of an item in the study. Unspecified attributes + (i.e. those set to :const:`None`) are left unchanged. + + :type item: SObject + :param item: item to modify. + + :type name: string + :param name: item name (attribute 'AttributeName'). + + :type fileType: string + :param fileType: item file type (attribute 'AttributeFileType'). + + :type fileName: string + :param fileName: item file name (attribute + 'AttributeExternalFileDef'). + + :type comment: string + :param comment: item comment (attribute 'AttributeComment'). Note that + this attribute will appear in the 'Value' column in + the object browser. + + :type icon: string + :param icon: item icon name (attribute 'AttributePixMap'). + + :type IOR: string + :param IOR: IOR of a CORBA object associated with the item + (attribute 'AttributeIOR'). + + :type typeId: integer + :param typeId: item type (attribute 'AttributeLocalID'). + """ + logger.debug("setItem (ID=%s): name=%s, fileType=%s, fileName=%s, " + "comment=%s, icon=%s, IOR=%s" % + (item.GetID(), name, fileType, fileName, comment, + icon, IOR)) + # Explicit cast is necessary for unicode to string conversion + if name is not None: + self.builder.SetName(item, str(name)) + if fileType is not None: + self.setFileType(item, fileType) + if fileName is not None: + self.setFileName(item, fileName) + if comment is not None: + self.builder.SetComment(item, str(comment)) + if icon is not None: + self.setIcon(item, icon) + if IOR is not None: + self.builder.SetIOR(item, str(IOR)) + if typeId is not None: + self.setTypeId(item, typeId) + + def removeItem(self, item, withChildren = False ): + """ + Remove the given item from the study (the item still is in + the study after the removal) + @param item: the browser object to be removed + @param withChildren: remove children if True + """ + ok = False + try: + if withChildren: + self.builder.RemoveObjectWithChildren(item) + else: + self.builder.RemoveObject(item) + ok = True + except: + ok = False + + return ok + + def setItemAtTag(self, fatherItem, tag, name = None, fileType = None, + fileName = None, comment = None, icon = None, IOR = None, + typeId = None): + """ + Find an item tagged `tag` under `fatherItem` in the study tree or + create it if there is none, then set its attributes. + + :type fatherItem: SObject + :param fatherItem: item under which the tagged item will be looked for + and eventually created. + + :type tag: integer + :param tag: tag of the item to look for. + + :return: the SObject at `tag` if found or created successfully, or + :const:`None` if an error happened. + + See :meth:`setItem` for the description of the other parameters. + """ + found, sObj = fatherItem.FindSubObject(tag) + if not found: + sObj = self.builder.NewObjectToTag(fatherItem, tag) + self.setItem(sObj, name, fileType, fileName, comment, icon, + IOR, typeId) + return sObj + + def getAttributeValue(self, sObject, attributeName, default = None): + """ + Return the value of the attribute named `attributeName` on the object + `sObject`, or `default` if the attribute doesn't exist. + """ + value = default + found, attr = self.builder.FindAttribute(sObject, attributeName) + if found: + value = attr.Value() + return value + + def setAttributeValue(self, sObject, attributeName, attributeValue): + """ + Set the value of the attribute named `attributeName` on the object + `sObject` to the value `attributeValue`. + """ + attr = self.builder.FindOrCreateAttribute(sObject, attributeName) + attr.SetValue(attributeValue) + + def getTypeId(self, sObject): + """ + Return the value of the attribute "AttributeLocalID" of the object + `sObject`, or :const:`None` if it is not set. + """ + return self.getAttributeValue(sObject, "AttributeLocalID") + + def setTypeId(self, sObject, value): + """ + Set the attribute "AttributeLocalID" of the object `sObject` to the + value `value`. + """ + self.setAttributeValue(sObject, "AttributeLocalID", value) + + def getFileType(self, sObject): + """ + Return the value of the attribute "AttributeFileType" of the object + `sObject`, or an empty string if it is not set. + """ + return self.getAttributeValue(sObject, "AttributeFileType", "") + + def setFileType(self, sObject, value): + """ + Set the attribute "AttributeFileType" of the object `sObject` to the + value `value`. + """ + # Explicit cast is necessary for unicode to string conversion + self.setAttributeValue(sObject, "AttributeFileType", str(value)) + + def getFileName(self, sObject): + """ + Return the value of the attribute "AttributeExternalFileDef" of the + object `sObject`, or an empty string if it is not set. + """ + return self.getAttributeValue(sObject, "AttributeExternalFileDef", "") + + def setFileName(self, sObject, value): + """ + Set the attribute "AttributeExternalFileDef" of the object `sObject` + to the value `value`. + """ + # Explicit cast is necessary for unicode to string conversion + self.setAttributeValue(sObject, "AttributeExternalFileDef", + str(value)) + + def getIcon(self, sObject): + """ + Return the value of the attribute "AttributePixMap" of the object + `sObject`, or an empty string if it is not set. + """ + value = "" + found, attr = self.builder.FindAttribute(sObject, "AttributePixMap") + if found and attr.HasPixMap(): + value = attr.GetPixMap() + return value + + def setIcon(self, sObject, value): + """ + Set the attribute "AttributePixMap" of the object `sObject` to the + value `value`. + """ + attr = self.builder.FindOrCreateAttribute(sObject, "AttributePixMap") + # Explicit cast is necessary for unicode to string conversion + attr.SetPixMap(str(value)) diff --git a/src/KERNEL_PY/kernel/termcolor.py b/src/KERNEL_PY/kernel/termcolor.py new file mode 100644 index 000000000..9d584afc8 --- /dev/null +++ b/src/KERNEL_PY/kernel/termcolor.py @@ -0,0 +1,150 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2007-2009 EDF R&D +# +# This file is part of PAL_SRC. +# +# PAL_SRC 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 2 of the License, or +# (at your option) any later version. +# +# PAL_SRC 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 PAL_SRC; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +# +# Author : Renaud Barate (EDF R&D) +# Date : August 2009 +# +""" +This module provides utility functions to display colored text in the +terminal. It is based on ISO 6429 standard that defines control codes to +change characters representation in color-capable ASCII terminals. + +In this module, colors are represented as lists of codes, so they can be added +to obtain special effects (e.g. RED + GREEN_BG to display red text on green +background). Several constants are defined for the most usual codes to +facilitate the use of colors, but it is also possible to define colors +directly from the corresponding code from ISO 6429 standard. In fact it is +even necessary for less usual codes that don't have an associated constant +(e.g. PURPLE + ['09'] can be used to display a crossed-out purple text). + +Example:: + + import sys + from pal import termcolor + if termcolor.canDisplayColor(sys.stdout): + print termcolor.makeColoredMessage("Hello world!", termcolor.BLUE) + else: + print "Hello world!" + +""" + +# Constants for color codes +DEFAULT = ['00'] +"""Default color for the terminal""" +BOLD = ['01'] +"""Bold text and brighter colors""" +UNDERLINED = ['04'] +"""Underlined text""" +BLACK_FG = ['30'] +"""Black foreground""" +RED_FG = ['31'] +"""Red foreground""" +GREEN_FG = ['32'] +"""Green foreground""" +YELLOW_FG = ['33'] +"""Yellow foreground""" +BLUE_FG = ['34'] +"""Blue foreground""" +PURPLE_FG = ['35'] +"""Purple foreground""" +CYAN_FG = ['36'] +"""Cyan foreground""" +WHITE_FG = ['37'] +"""White foreground""" +BLACK_BG = ['40'] +"""Black background""" +RED_BG = ['41'] +"""Red background""" +GREEN_BG = ['42'] +"""Green background""" +YELLOW_BG = ['43'] +"""Yellow background""" +BLUE_BG = ['44'] +"""Blue background""" +PURPLE_BG = ['45'] +"""Purple background""" +CYAN_BG = ['46'] +"""Cyan background""" +WHITE_BG = ['47'] +"""White background""" + +# Constants for common colored text +BLACK = BLACK_FG +"""Black text (equivalent to BLACK_FG)""" +RED = BOLD + RED_FG +"""Red text (equivalent to BOLD + RED_FG)""" +GREEN = BOLD + GREEN_FG +"""Green text (equivalent to BOLD + GREEN_FG)""" +YELLOW = BOLD + YELLOW_FG +"""Yellow text (equivalent to BOLD + YELLOW_FG)""" +BLUE = BOLD + BLUE_FG +"""Blue text (equivalent to BOLD + BLUE_FG)""" +PURPLE = BOLD + PURPLE_FG +"""Purple text (equivalent to BOLD + PURPLE_FG)""" +CYAN = BOLD + CYAN_FG +"""Cyan text (equivalent to BOLD + CYAN_FG)""" +WHITE = WHITE_FG +"""White text (equivalent to WHITE_FG)""" + + +def canDisplayColor(stream): + """ + Return True if the stream can display colored text, False otherwise. + """ + return hasattr(stream, "isatty") and stream.isatty() + +def getControlSequence(color): + """ + Return the control sequence for the color in parameter, i.e. the string + telling the terminal to display the following text in the given color. + """ + seq = "\x1b[" + for i in range(len(color)): + seq += color[i] + if i < len(color)-1: + seq += ";" + seq += "m" + return seq + +def makeColoredMessage(message, color): + """ + Return a string that can be used to display the message in parameter with + the given color. + """ + return (getControlSequence(color) + + str(message) + + getControlSequence(DEFAULT)) + +def TEST_termcolor(): + """Test function for termcolor module.""" + import sys + if not canDisplayColor(sys.stdout): + print "Standard output does not support colors." + return + print makeColoredMessage("This message must appear in blue.", BLUE) + print makeColoredMessage("This message must appear in red on green " + + "background.", RED + GREEN_BG) + print makeColoredMessage("This message must appear in magenta and " + + "crossed-out.", PURPLE + ['09']) + + +# Main function only used to test the module +if __name__ == "__main__": + TEST_termcolor() diff --git a/src/KERNEL_PY/salome.py b/src/KERNEL_PY/salome.py index 2ffceb179..8fca332b5 100755 --- a/src/KERNEL_PY/salome.py +++ b/src/KERNEL_PY/salome.py @@ -21,6 +21,14 @@ # See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com # +# ================================================================================ +# WARNING: this file is deprecated and should not be used any more. It has been +# replaced by the file __init__.py of the python package named "salome". +# To prevent any error, a warning is raised in the case where this file is imported +raise RuntimeError("WRN - the file salome.py is deprecated. It should NOT be used any more.") +# ================================================================================ + + # File : salome.py # Author : Paul RASCLE, EDF # Module : SALOME @@ -82,7 +90,7 @@ variables: # \param salome.myStudyId : active Study Id # \param salome.myStudy : the active Study (interface SALOMEDS::Study) - +# from salome_kernel import * from salome_study import * from salome_iapp import * diff --git a/src/Launcher/Launcher.cxx b/src/Launcher/Launcher.cxx index e5d8e9dc8..03c74cdab 100644 --- a/src/Launcher/Launcher.cxx +++ b/src/Launcher/Launcher.cxx @@ -421,7 +421,9 @@ Launcher_cpp::FactoryBatchManager(ParserResourcesType& params) throw LauncherException("Cannot find batch manager factory"); } LAUNCHER_MESSAGE("Instanciation of batch manager of type: " << bmType); - return (*fact)(hostname.c_str(), protocol, mpi.c_str(), nb_proc_per_node); + Batch::BatchManager_eClient * batch_client = (*fact)(hostname.c_str(), protocol, mpi.c_str(), nb_proc_per_node); + batch_client->setUsername(params.UserName); + return batch_client; } //---------------------------------------------------------- diff --git a/src/ResourcesManager/ResourcesManager.cxx b/src/ResourcesManager/ResourcesManager.cxx index a265e9f25..868ac8cb8 100644 --- a/src/ResourcesManager/ResourcesManager.cxx +++ b/src/ResourcesManager/ResourcesManager.cxx @@ -455,21 +455,21 @@ void ResourcesManager_cpp::KeepOnlyResourcesWithComponent(std::vector& resources, const std::vector& componentList) { + std::vector kept_resources; + std::vector::iterator iter = resources.begin(); for (; iter != resources.end(); iter++) { - MapOfParserResourcesType::const_iterator it = _resourcesList.find(*iter); - const std::vector& mapOfComponentsOfCurrentHost = (*it).second.ComponentsList; + const std::vector& mapOfComponentsOfCurrentHost = _resourcesList[*iter].ComponentsList; bool erasedHost = false; if( mapOfComponentsOfCurrentHost.size() > 0 ) { for(unsigned int i=0; i::const_iterator itt = find(mapOfComponentsOfCurrentHost.begin(), - mapOfComponentsOfCurrentHost.end(), - compoi); + mapOfComponentsOfCurrentHost.end(), + componentList[i]); if (itt == mapOfComponentsOfCurrentHost.end()) { erasedHost = true; @@ -477,9 +477,10 @@ ResourcesManager_cpp::KeepOnlyResourcesWithComponent(std::vector& r } } } - if(erasedHost) - resources.erase(iter); + if(!erasedHost) + kept_resources.push_back(*iter); } + resources=kept_resources; } diff --git a/src/ResourcesManager/SALOME_ResourcesCatalog_Handler.cxx b/src/ResourcesManager/SALOME_ResourcesCatalog_Handler.cxx index ac6341bb6..20851ed2a 100755 --- a/src/ResourcesManager/SALOME_ResourcesCatalog_Handler.cxx +++ b/src/ResourcesManager/SALOME_ResourcesCatalog_Handler.cxx @@ -130,11 +130,6 @@ void SALOME_ResourcesCatalog_Handler::ProcessXmlDocument(xmlDocPtr theDoc) if(_resource.HostName == "localhost") { _resource.HostName = Kernel_Utils::GetHostname(); - if (_resource.Name == "localhost") - { - _resource.Name = Kernel_Utils::GetHostname(); - _resource.DataForSort._Name = Kernel_Utils::GetHostname(); - } } std::map::const_iterator iter = _resources_list.find(_resource.Name); if (iter != _resources_list.end())