source: Sophya/trunk/SophyaLib/Manual/modifs.tex@ 2716

\documentclass[twoside,11pt,A4]{article}
\usepackage[french]{babel}

% \usepackage[T1]{fontenc}
\usepackage[applemac]{inputenc}
\usepackage{palatino}
% \usepackage{times}
% package pour ecrire DRAFT en fond de page 
% \usepackage[light,all,draft]{draftcopy}

% \usepackage{epsfig}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{amssymb}

\setlength{\textwidth}{16cm}
\setlength{\textheight}{23 cm}
\setlength{\topmargin}{0.5cm}
\setlength{\oddsidemargin}{0.cm}
\setlength{\evensidemargin}{0.cm}
\setlength{\unitlength}{1mm}

\newcommand{\rond}{$\bullet \ $}
\newcommand{\etoile}{$\star \ $}
\newcommand{\cercle}{$\circ \ $}
\newcommand{\carre}{$\Box \ $}

\begin{document}
\begin{titlepage}
\begin{center}
{\Large \bf Liste de modifications de SOPHYA } \\[5mm]
{ \large (fait ou ˆ faire ) } \\
{\large Janvier 2003 - Mai 2005 } \\[25mm]
Liste des tags et dates : \\[5mm]
{\large 
\begin{tabular}{lcl}
V = 0.727 &   \hspace{10mm}  & Octobre 1999 \\
V = 0.8  &   \hspace{10mm}  &  FŽvrier 2000 \\
V = 1.1  &   \hspace{10mm}  &  FŽvrier 2001 \\
V = 1.2  &   \hspace{10mm}  &  Juillet 2001 \\
V = 1.3  &   \hspace{10mm}  &  Novembre  2001 \\
V = 1.5  &   \hspace{10mm}  &   DŽcembre  2002 \\
V = 1.7  &   \hspace{10mm}  &   Septembre 2003 \\
\end{tabular}
}
\end{center}
\end{titlepage}

\newpage
\tableofcontents
\newpage

\section{Mgr} 
\subsection{Variables d'environnement SOPHYAxxx (17/9/2003)  } 
Septembre 2003 (17/9/2003) :  Changement DPCDEVREP, DPCBASEREP
en SOPHYADEVREP , SOPHYABASEREP , EROSCXX en SOPHYACXX 

\subsection{Modifs Makefile - Message du 3 Mars 2004 }
\begin{verbatim}
Pour Les makefiles SOPHYA, je n'ai pas encore regarde ton makefile.h
modifie.
Voila qques propositions :
il y aura qu'une seule variable d'environnement :  (SOPHYAROOT ou
SOPHYARACINE) par exemple
$SOPHYAROOT/Include
           /Include/FitsIO/ FFTW/  (etc...) pour les .h extlibs
           /Libs
           /ShLibs
           /Exec
           /Objs
Un fichier Makefile.h ds $SOPHYAROOT/Include
contiendra
#  Section  generale
SOPHYAROOT =
SOPHYACXX=
...
#  Section compilation
CC_COMPILER  (nom du compilo cc)
CXX_COMPILER (   c++)
CPPFLAGS , (flag du preprocesseur), en particulier
les -Iincludepath  (chemin pour les includes SOPHYA
CFLAGS flag de compilation c
CXXFLAGS flags de compilation c++
#  Section Link
LIBPATH -L... -L... (chemin pour les librairies et les lib externes (cfitsio, ...)
LIBLIST -lm -lcfitsio ... (les librairies)

Ces variables doivent pouvoir etre utilise par la classe CxxCompilerLinker.
Il faut donc prevoir peut-etre un autre fichier cccpp_flags.h (ou qque chose
du meme genre) avec la syntaxe C/C++ de chaines de caracteres
pouvant etre include (par #include) ds cxxcmplnk.cc

le fichier machdefs.h ds $SOPHYAROOT/Include est genere a partir du fichier
machdefs_mkmf.h actuel (on pourra songer ulterieurement a le casser en
plusieurs morceaux si necessaire) et contiendra en entete les flags
qui modifie la generation du code

exemple
#define Linux
#define SOPHYA_DEBUG
....

Dans les fichier Makefile pour chaque module, on abandonnera
les regles (et repertoire) de compilation par defaut et on aura
donc:
INC= $SOPHYAROOT/Include
OBJ = $SOPHYAROOT/Objs
LIB=...
$(OBJ)toto.o : toto.cc $(INC)toto.h $(INC)titi.h ...
        $CXX $CXXFLAGS -c -o  $(OBJ)toto.o toto.cc
....

Il faudra voir ensuite pour le makefile de fabrication des shared-libs
\end{verbatim}

\subsection{ Modifs Makefile - Message du 8 Juillet 2004 }
\begin{verbatim}
A/ Makefile(s)  (voir aussi mon message du 3 mars 2004)
A-1/ Structures des repertoires
>> On garde la structuration avec 
+ un Makefile par module 'librairie'
+ un ensemble de modules librairies sans lib externe -> libsophya.slb
+ un ensemble de modules librairies avec lib externe -> libextsophya.slb
+ Des modules programmes (PrgUtil/ PrgMap/ ) avec un makefile par module programme
+ un Makefile de haut niveau (actuellement ds Mgr/Makefile 
  Ce Makefile de haut niveau sera aussi simplifiŽ - en particulier la partie
concernant la fabrication des shared-libs (.slb) et Makefile.slb 
+ On garde aussi la convention de generation automatique des GNUmakefile, qui sont 
ensuite renommes eventuellement en Makefile, conserves ds la base 
- Plus d'inclusion automatique du nom du system-compilo (Linux-g++ OSF1-cxx ...) 
dans les noms de repertoires
- Plus de structure ExtLibDir obligatoire (remplace par des -Ipath -Lpath pour les
compils/links
- Si besoin, on fait subir le meme sort que Makefile.h a Makefile.slb

  On aura donc :   (message du 3 mars 2004)
il y aura qu'une seule variable d'environnement :  (SOPHYAROOT ou
SOPHYARACINE) par exemple
$SOPHYAROOT/Include  
Attention le repertoire Include/  NE sera donc PLUS commun pour plusieurs
systemes-compilo. 
                              /Libs
                              /ShLibs
                              /Exec
                              /Objs
Un fichier Makefile.h ds $SOPHYAROOT/Include
contiendra les flags de compilation dŽfinis pour un systme/compilo.
A la base, on aura ds Mgr/ un fichier Makefile.h pour chaque combinaison 
compilo-compilo;
Mgr/makef_osf1_cxx.h 
Mgr/makef_linux_g++.h
Mgr/makef_linux_KCC.h
Mgr/makef_darwin_g++.h  (Mac)
Mgr/makef_sgi_CC.h
  etc ...
C'est ce fichier qui est copiŽ en Include/Makefile.h, Žventuellement 
complete/modifie

----- Fichier Makefile.h
#  Section  generale
SOPHYAROOT =
SOPHYACXX=
...
#  Section compilation
CC_COMPILER  (nom du compilo cc)
CXX_COMPILER (   c++)
CPPFLAGS , (flag du preprocesseur), en particulier
les -Iincludepath  (chemin pour les includes SOPHYA
CFLAGS flag de compilation c
CXXFLAGS flags de compilation c++
#  Section Link
LIBPATH -L... -L... (chemin pour les librairies et les lib externes (cfitsio, ...)
LIBLIST -lm -lcfitsio ... (les librairies)

Ces variables doivent pouvoir etre utilise par la classe CxxCompilerLinker.
Il faut donc prevoir peut-etre un autre fichier cccpp_flags.h (ou qque chose
du meme genre) avec la syntaxe C/C++ de chaines de caracteres
pouvant etre include (par #include) ds cxxcmplnk.cc

le fichier machdefs.h ds $SOPHYAROOT/Include est genere a partir du fichier
machdefs_mkmf.h actuel (on pourra songer ulterieurement a le casser en
plusieurs morceaux si necessaire) et contiendra en entete les flags
qui modifie la generation du code

exemple
#define Linux
#define SOPHYA_DEBUG
....

Dans les fichier Makefile pour chaque module, on abandonnera
les regles (et repertoire) de compilation par defaut et on aura
donc:
INC= $SOPHYAROOT/Include
OBJ = $SOPHYAROOT/Objs
LIB=...
$(OBJ)toto.o : toto.cc $(INC)toto.h $(INC)titi.h ...
        $CXX $CXXFLAGS -c -o  $(OBJ)toto.o toto.cc
....
  
\end{verbatim}

\section{BaseTools} 
\subsection{Namespace SOPHYA }
Septembre 2004 : 
Suppression de {\tt using namespace SOPHYA ; } ds machdefs.h - 
Ajout fichier {\tt \#include "sopnamsp.h"} dans les .cc de SOPHYA,
ainsi que lors de la gŽnŽration automatique du code (runxx, c++exec) 
 
\subsection{PPF}
\begin{itemize}
\item[\rond] Novembre 2003 (21/11/2003) - Ajout rawstream.h .cc \\
Classes RawInOutStream  ,  RawInFileStream , RawOutFileStream
\item[\rond] DŽcembre 2003 - Ajout ppfbinstream.h .cc \\
Classes PPFBinaryIOStream , PPFBinaryInputStream , PPFBinaryOutputStream
\item[\rond] DŽcembre 2003 (9/12/2003) Fin de l'ensemble des modifs pour les
PPF V3 \\
- Ecriture nombre complexes r4, r8 avec tag spŽcifique. \\
Tag de positionnement sous forme de \\
\centerline{\tt <tag (1 byte)><FilePosition (8 byte, long int)> } \\
- Ecriture PosTagTable \\
- Ecriture Statistiques en fin de fichier \\
- Voir BaseTools/ppfbinstream.h: \\
\centerline{\tt  GotoPositionTag(int\_8 pos) , } 
\centerline{\tt  GetPosTagTable(...) } 
\centerline{\tt  int\_8 WritePositionTag() PutPosTagTable(...) } 
- Ajout programme de test Tests/ppftswap.cc
\item[\rond] Avril 2005 - Ajout de wrapper de lecture/ecriture PPF pour les vecteurs de
la librairie standard (classe PPFWrapperSTLVector<T> ) fichier ppfwrapstlv.h
\item[\rond] Ajout de la classes utilitaire PPF\_TPointer\_IO$<$T$>$ 
(fichiers ppftpointer.h .cc)
\item[\rond] Amelioration de l'impression ds AnalyseTags (ppfbinstream.cc)
\item[\rond] scanppf.cc revision 1.8 (2005/04/05)
modification programme scanppf: ajout option -lh -lho pour lister les classes PP
ersist handler

\end{itemize}



\subsection{Segmented Data Block}
Mars-Avril 2005: Introduction des classes similaires aux NDataBlock, mais permettant 
de gerer des blocs de donnees segementes, pour tout type de donnees, de structures
et de classes (template pour tout type <T>).
Extrait du log CVS du 2005/04/07 
\begin{verbatim}
1/ Ajout de la classe SegDataBlock<T> (et l'interface SegDBInterface<T>)
pour la gestion de blocs de donnees segmentes (segdatablock.h) et son
gestionnaire PPF FIO_SegDataBlock<T> (fichier fiosegdb.h )
2/ Ajout de la classe SwSegDataBlock<T> (Data bloc segmente avec gestion
de swap) et la classe swapper PPF PPFDataSwapper<T> (fichiers
ppfswapper.h et swsegdb.h)
\end{verbatim}


\section{TArray}
\begin{itemize}
\item Optimisation de la multiplication matricielle (CMV) - Extrait du 
message (from CMV) du 30 Juillet 2004: \\
\begin{verbatim}
- on definit un flag d'optimisation
  Contrairement a ce qu'on avait dit, je n'ai pas ajoute
  un argument a Multiply car on ne peut pas jouer
  avec qiand on utilise l'operateur * surcharge.
  Or au vu des performance il'ma parut interessant que l'utilisateur
  meme lambda puisse choisir le niveau d'optimisation
  --> donc j'ai ajoute une methode statis dans BaseArray::
    void BaseArray::SetMatProdOpt(uint_2);
    uint_2 BaseArray::GetMatProdOpt();

- Je n'ai refait les test de rapidite que sur OSF:

1./  pour les matrices 1000x1000 (grosses)
  on arrive effectivement au meme temps pour les 4 cas
  si on copie dans le cas lent (FxC)
  ---EndMultiply FxC  CPUTime: Total= 93.1296  (Partial= 69.3806) Sec.
  devient
  ---EndMultiply FxC  CPUTime: Total= 34.9653  (Partial= 11.1829) Sec.
  exactement comme les copains:
  La copie prend de la place mais ne prend absolument
  pas de temps pour les grosses matrices

2./ pour les matrices 10x10 (1000000 multiplications par cas)
  on a bien ce que l'on attend a savoir que
  la copie faites 100000 fois finie par nous faire perdre du temps
  ---EndMultiply FxC  CPUTime: Total= 37.4152  (Partial= 12.4662) Sec.
  devient
  ---EndMultiply FxC  CPUTime: Total= 53.9978  (Partial= 28.8322) Sec.
  dans ce cas on perd un gros facteur 2 a cause de la copie
  mais rien de surprenant la dedans.

-----------------------------------------------------------------------
- ensuite j'ai implemente une prise de decision au niveau de
l'optimisation pour les petites matrices:
le test est simple mais me semble OK:
je calcule sza taille du NDataBlock de A
           szb                         B
si ((sza+szb)*sizeof(T) < 100000 ) pas d'optimisation
IDEE: on pifometre que raisonnablement il y a 100 koctets
   de disponible pour les matrices A et B dans le cache processeur
   et que dans ce cas elles sont copiees toutes les 2 dans le cache
   par l'optimiseur du compilo qui est tres malin et surtout qui
   veux absolument nous faire plaisir......

-----------------------------------------------------------------
===> Les resultats sont dans le fichier toto.calc en attached
.. En tete tu as l'explication des flags d'optimisation
...Avec les 2 sections:
    GROSSE MATRICE
       et
    PETITE MATRICE
\end{verbatim}

\item Optimisation operations diverses, en particulier \\
1) Remplacement des methodes Add/Sub/Mul/DivElt(a) par
   Add/Sub/Mul/DivElt(TArray a, TArray res) \\
2)  Operateurs += -= A+B A-B TArray et TMatrix/TVecteur modifies en consequence
\item Extrait de {\tt cvs log tarray.cc } 
{\small \begin{verbatim}
----------------------------
revision 1.38
date: 2004/07/30 13:31:39;  author: ansari;  state: Exp;  lines: +28 -24
Diverses petites optimisations ds les methodes operations/affectations de TArray - Reza 30 Juillet 2004
----------------------------
----------------------------
revision 1.36
date: 2004/07/27 11:44:23;  author: ansari;  state: Exp;  lines: +4 -1
Corrections bug apres modifs methods Add/Sub/Mul/DivCst(x,res) - Reza 27 Juillet 2004
----------------------------
revision 1.35
date: 2004/07/26 17:30:40;  author: ansari;  state: Exp;  lines: +187 -108
Remplacement methodes Add/Mul/Sub/Div(T x) par AddCst/MulCst/SubCst/DivCst(T x, TArray<T> res) ds TArray - Reza 26 Juillet 2004
----------------------------
\end{verbatim} }

\item Extrait de {\tt cvs log tarray.cc } 
{\small \begin{verbatim}
----------------------------
revision 1.27
date: 2004/07/30 10:24:12;  author: cmv;  state: Exp;  lines: +97 -32
- Intro decision auto d'optimisation produit de matrices
- Possibilite a l'utilisateur pour choisir l'optimisation
- cas FxC optimise par copie
                cmv 30/07/04
----------------------------
revision 1.26
date: 2004/07/29 12:31:16;  author: ansari;  state: Exp;  lines: +7 -5
1/ Remplacement des methodes Add/Sub/Mul/DivElt(a) par
   Add/Sub/Mul/DivElt(TArray a, TArray res)
2/ Operateurs += -= A+B A-B TArray et TMatrix/TVecteur modifies en consequence
3/ Ajout methode TArray::ScalarProduct()
4/ Methode TArray::SetT renomme en SetCst() SetT garde en alias
5/ Ajout parametre bool fzero (mise a zero) ajoute ds constructeur et
   ReSize() de TMatrix et TVecteur.
                                          Reza 29/07/2004
----------------------------
revision 1.25
date: 2004/07/29 08:40:49;  author: cmv;  state: Exp;  lines: +148 -1
Optimisation produit de matrice a la sauce cmv 29/07/04
----------------------------
\end{verbatim}  }

\end{itemize}

\section{HiStats} 
\subsection{Classe HistoErr } 
Ajout classe HistoErr (Septembre-Octobre 2004) 

\subsection{NTuple}
la classe NTuple peut maintenant avoir des colonnes float ou double.
Il y a maintenant deux methodes Fill(r\_4 *) et Fill(r\_8 *)
Les noms ne sont plus limites a 8 caracteres.


\subsection{ Les DataTable (SuperNTuple) }

\begin{verbatim}
BaseDataTable                                    
              --------  DataTable
              --------  SwPPFDataTable
\end{verbatim}
{\bf BaseDataTable} : Classe de base, avec qques methodes virtuelles
pures, implementent la presque totalite des fonctionalites, en particulier
celles de l'interface NTupleInterface.

{\bf DataTable} : Implementation concrete de BaseDataTable avec donnees en 
memoire (utilise SegDataBlock<T> pour stocker les colonnes)

{\bf SwPPFDataTable} : Implementation concrete de BaseDataTable avec donnees 
en swap sur stream PPF (POutPersist)- Utilise  (SwSegDataBlock<T> avec 
un data-swapper PPF (classe PPFDataSwapper<T> ) 

DataTable et SwPPFDataTable respecte +/- les conventions SOPHYA , 
constructeur de copie avec partage ou copie de donnees, operateur = 
Datatable : partage et copie , = : fait une copie
SwPPFDataTable : C'est toujours partage (presque par definition)
Autre point, compte tenu de la structure des streams PPF , 
les SwPPFDataTable fonctionne en ecriture OU en lecture, mais
pas les deux a la fois. 

Classe de gestion de persistence commune : \\
{\bf ObjFileIO<BaseDataTable> }

Lit et ecrit les DataTable et SwPPFDataTable
Actuellement, on ne peut les relires que dans le meme type,
cad on ne peut relire avec un SwPPFDataTable un objet 
ecrit comme DataTable - mais cette possibilite pourra 
peut-etre codee ulterieurement (d'ou l'interet en particulier 
d'un gestionnaire commun ObjFileIO<BaseDataTable>

(les operateurs habituel $<<$ et $>>$ sur PIn/OutPersist sont definies)

\begin{verbatim}
Actuellement, les colonnes peuvent etre de type 
int_4  ,  int_8  ,  r_4  ,  r_8  ,  string 
On pourra ajouter apres  les types suivants :
complex<r_4>  ,   complex<r_8>  , TimeStamp 
 
Dans BaseDataTable, il reste a remplir la methode
BaseDataTable ::FillFromASCIIFile(string const& fn)
BaseDataTable :: Print(int num, int nmax=1) const  
(on peut utiliser LineToString(sa_size_t n) const

Par contre, les merges et copie sont prevues, 
on doit en principe pouvoir ecrire par exemple:
SwPPFDataTable swdt;
PInPersist pis("swdt.ppf");
pis >> swdt;
DataTable dt;
dt = swdt;  // Pour tout charger en memoire 

On peut aussi ajouter des methodes d'acces aux variables membres pour enrichier l'interface.

PLUS IMPORTANT : il reste a ecrire la classe FITS_BaseDataTable ou FITS_DataTable 
pour I/O sur fichiers FITS - j'ai regarde FITS_XNTuple qu'on pourra simplifier enormement
et que devrait etre assez rapide. 
Il faut aussi faire une classe SwFITSDataTable, en recopiant pas mal de chose ds la classe
SwPPFDataTable - On pourrait peut-etre avoir une classe intermediaire qui regroupe
tout ce qui est commun a SwFITSDataTable et SwPPFDataTable , mais a voir.
L'element cle sera le codage de FITSDataSwapper<T> qui implemente 
les deux methodes de DataSwapperInterface<T> - le reste devrait etre du copier/coller
essentiellement. 

PIAPP : 
Cote piapp, les DataTable et SwPPFDataTable  sont pris en charge par 
NOMAdapter_DataTable (qui prend en charge tous les 'BaseDataTable' )
Il faudrait peut-etre rajouter deux commandes :
newdt ou newdatatable 
newdt ncol col1 [col2 .... ] 
avec possibilite de specifier coli sous fome de X:colname ou X = D,F,S,I,L ...
et puis dtfromascii  ...

Voir Tests/tnt.cc pour exemple d'utilisation :
DataTable dt(64);
dt.AddIntegerColumn("line");
dt.AddDoubleColumn("x");
dt.AddFloatColumn("f_sin");
MuTyV rec[10];
for(int k = 0; k<1000; k++) {
  rec[0] = k;
  double x = M_PI*k/100.;
  double fx = sin(x)*cos(x);
  rec[1] = x;
  rec[2] = sin(x);
}
 POutPersist po("dtable.ppf");
 po << dt;

Pour SwPPFDataTable, il faut juste creer un stream PPF avant, qui doit rester
ouvert tant que le SwPPFDataTable est actif 
 POutPersist po("swdtable.ppf");
 SwPPFDataTable dt(po, 64);

\end{verbatim}

\section{SkyMap , Samba }
\subsection{Tests et vŽrifications des polynomes de Legendre} 
--> CMV 

\subsection{SphereECP} 
Extrait du message du 7 Septembre 2004 
\begin{verbatim}
 J'ai mis dans la base (module SkyMap) le code de la classe
SphereECP<T> (pixelisation avec projection cylindrique) - carte partielle et complete,
+ gestionnaire PPersist + modifs adaptateur NomSkyMapAdaptor (PIext/ spiapp)

Programme test (avec appel a transforme en Alm) ds Test/tsphereecp.cc
Attention, mettre le parametere de pixelisation a -1 lors de l'appel a Generate pour eviter
le Resize de la sphereECP
ylmserver.GenerateFromCl(map, -1,  clin, 0.);

Dans piapp, c'est visualise par defaut en projection Molleweide
On peut ajouter dans les options d'affichage :
ecparray : affichage direct du tableau TArray des pixels (X:Phi, Y:Theta)
Si option ecparray, on peut preciser en plus
     - ecpscaledeg: echelle des axes en degres au lieu de pixels
     - ecpscalerad: echelle des axes en radians au lieu de pixels
Exemple:
Cmd> disp mapecp 'ecparray ecpscaledeg zoomx2 stdaxes'
\end{verbatim} 

\subsection{Bug non corrigŽ ds classe Circle} 
\begin{verbatim}
From: Laurence Perotto <perotto@cdf.in2p3.fr>
Date: Mon Jan 5, 2004  4:59:12 PM Europe/Paris
To: Reza Ansari <ansari@lal.in2p3.fr>, Christophe Magneville <cmv@hep.saclay.cea.fr>
Subject: un bug dans sophya...

    Bonjour et bonne annee a tous les deux...

    Je viens de trouver un ptit bug dans la fonction TanOnCircle de la classe Circle: Il
s'agit d'un melange entre les coordonnees (beta, lambda) de Benoit et les (theta, phi)
utilises dans Sophya. Lors du passage de l'un a l'autre, une transfo sin->cos a ete
oubliee...
    Voila...
    Bonne journee.

    Laurence.
\end{verbatim} 

\section{SysTools} 
\subsection{Classe SOPHYA::Commander (module SysTools) }

Classe d'interprŽteur de ligne de commande inspire de C-Shell,
destine a etre incluee dans des applications C/C++. \\
( Programme test Test/tcmd.cc ) 

{\bf Mini guide de l'interpreteur - Message du 19 Mars 2004 }   \

\begin{itemize}

\item[\rond] {\bf Gestion des variables } \\
 - Les variables sont non typees toutes traitees comme des chaines 
de caracteres. 
 - Acces aux variables d'environnement - 
 - Un niveau variable d'environnement application est aussi prevu
 - Toutes les variables de l'interpreteur  sont traitees comme des vecteurs.
extensibles automatiquement (difference avec le C-Shell) 

\item[\rond] {\bf Creation / initialisation de variables }  \\
\begin{verbatim}
Cmd> set sv StringValue
# Suppression d'une variable : unset ou clearvar 
Cmd> unset sv 

# Initialisation de type vecteur - Espace avant/apres ')' et avant ')' obligatoire
Cmd> set vecv ( mot1 mot2 mot3 mot4 mot5 )
#Calcul numerique : expression de type C  - Espace avant/apres '=' obligatoire
Cmd> a = 2+3*sqrt(4)
# Le signe egal peut etre utilise pour attribuer une chaine de caracteres
Cmd> a = 'Bonjour Madame'
# Un element de tableau peut etre specifie avant le signe egal 
Cmd> vecv[2] = 'coucou'
# Ou bien 
Cmd> i = 3
Cmd> vecv[i] = 'Ooohhh' 
\end{verbatim}

A droite du signe egal (membre de droite), les variables doivent etre
adressees a l'aide du signe \$.  

Une chaine peut etre cassee en mots a l'aide de la commande var2words
\begin{verbatim}
Cmd> var2words varname wordvarname [separateur]
\end{verbatim}

\item[\rond] {\bf Acces aux variables } \\
L'acces aux variables s'effectue par le signe \$  {\tt \$varname} .
Les {\tt \$xxx} sont remplaces par le contenu de la variable xxx. 
Cette substitution ne s'effectue pas entre simple quotes {\tt ' ... \$xxx '},
mais se fait entre double quotes {\tt " ... \$xxx ... "} . Les formes
{\tt \${vname} } ou {\tt \$(vname)} peuvent etre utilisees.

\begin{verbatim}
Cmd> x = 'Hello'
Cmd> echo $x
# Taille d'une variable de type vecteur $#vname
Cmd> set vx ( 111 2222 3333 444444 )
Cmd> echo $#vx 
# Acces aux elements de tableau
Cmd> echo $vx[0] $vx[1] 
#  ou bien indexe par une variable 
Cmd> i = 2
Cmd> echo $vx[i] 
# Une syntaxe particuliere: $[vname] retourne le contenu de
# la variable dont le nom est ds vname 
Cmd> zzz = 'Commander'
Cmd> xxx = 'zzz'
Cmd> echo '$[xxx]= '  $[xxx]
$[xxx]= Commander
\end{verbatim}

Variables d'environnement: L'acces aux variables d'environnement 
se fait simplement par{\tt \$varenvname}. Attention, les variables locales
de l'interpreteur sont prioritaires.

\item[\rond] {\bf Variables particulieres: } \\
{\tt \$retval} ou {\tt \$retstr}  :  chaine specifee sur la derniere commande return 
{\tt \$status} : code de retour de la derniere commande executee.
(variable existe et est rempli - mais il faudra se donner une regle 
plus claire ...)
Arguments des fichiers .pic appeles par la commande exec 
{\tt \$\# } : nombre d'arguments, a part \$0 
{\tt \$0} nom du fichier ou du script 
{\tt \$1 \$2 \$3} .... les arguments  (pour les scripts et les .pic (exec))

 
\item[\rond] {\bf Structures de controle  } \\
\begin{verbatim}
foreach f ( w1 w2 w3 ... )
  ...
  echo $f
end
\end{verbatim}

Espace avant/apres '(' et avant ')' obligatoire.

\begin{verbatim}
foreach v vecname 
  ...
  echo $v
end
\end{verbatim}

Boucle de type integer:
\begin{verbatim}
for i  startInt:endInt[:stepInt]
  ....
  echo $i 
end
\end{verbatim}

Boucle de type float
\begin{verbatim}
for f  startFloat:endFloat[:stepFloat]
  ....
  echo $f
end
\end{verbatim}

Boucle sur les lignes d'un fichier:
\begin{verbatim}
forinfile line FileName
  ...
  echo $line
end
\end{verbatim}

Instruction {\tt break} pour casser une boucle

\item[\rond] {\bf Les tests  }
\begin{verbatim}
if ( test ) then 
endif

if ( test ) then
 ....
else
 .... 
endif
\end{verbatim}

Espace avant/apres '(' et avant ')' obligatoire.

test de type {\tt a == b} OU {\tt a != b} OU {\tt a < b}  OU {\tt a > b} 
OU {\tt a <= b} OU {\tt a >= b}
les espaces avant l'operateur de comparaison sont obligatoires.
{\tt ==} et {\tt !=}  effectue une comparaison de chaines de caracteres.
{\tt < , > , <= , >=}une comparaison apres conversion en valeur flottante.

\item[\rond] {\bf Definition de script } \\
\begin{verbatim}
defscript scriptname  [description ]
   ....
endscript 
\end{verbatim}

L'appel a un script se fait simplement a l'aide
du nom de script (contrairement aux fichiers
de commande qui sont executes a l'aide de la 
commande {\tt exec} )
\begin{verbatim}
Cmd> scriptname arg1 arg2 arg3 ....
\end{verbatim}

L'instruction {\tt return} provoque l'arret (et le retour) d'execution d'un
script ou d'un fichier de commandes.
Commandes {\bf listscript }et {\bf clearscript scriptname} 
 permettet d'avoir la liste des scripts 
 definis / supprimer la definition d'un script 

\item[\rond] {\bf Autres commandes}
\begin{itemize}
\item Instruction {\bf echo } pour ecrire sur cout/stdout
\item Instruction {\bf echo2file} pour ecrire a la fin d'un fichier
\item Instruction {\bf sleep nsec} (attente de nsec seconds )
\item Instructions {\bf timingon , timingoff , traceon , traceoff } \\
%
\item Commande {\bf exec commandfilename [arg1 arg2 ... ] }
\item Commandes {\bf help et help keyword/commandname }
\item Commandes {\bf listvars , listcommands }
\item  Defintion et liste d'alias : {\bf alias aliasname 'string ' } et {\bf  listalias} 
\end{itemize} 
\end{itemize} 

\subsection{Classes CExpressionEvaluator et RPNExpressionEvaluator }
\begin{itemize}
\item[\rond]  Ajout des classes RPNExpressionEvaluator et CExpressionEvaluator 
d'Žvaluation d'expressions numŽriques en notation polonaise inverse
et avec la syntaxe C . Utilise dans la classe Commander.  
\item[\rond]   Programme test Test/tcmd.cc 
\item[\rond]  extrait de {\tt cvs log cexpre.cc }
{\small \begin{verbatim} 
----------------------------
revision 1.3
date: 2004/03/18 18:15:19;  author: ansari;  state: Exp;  lines: +10 -6
Suite (presque finie) des modifications de l'interpreteur - gestion des variables en particulier - Reste au moins un bug ds CExpressionEvaluator - Reza 18/03/2004
----------------------------
revision 1.2
date: 2004/03/16 08:47:48;  author: ansari;  state: Exp;  lines: +5 -6
suppression variables inutilisees ds cexpr.cc - Reza 16 Mars 2004
----------------------------
revision 1.1
date: 2004/03/15 22:19:43;  author: ansari;  state: Exp;
Ajout fichiers des classes RPNExpressionEvaluator et CExpressionEvaluator (expression arithmetiques) et MAJ du fichier Makefile et objlist.list - Reza 15 Mars 2003
\end{verbatim} }

\item[\rond] Extrait du message du 3 Mars 2004 
\begin{verbatim}
Le code est base sur une hierarchie de classe d'expression :
 Expr --------  NumberExp
      --------- BinExp ------ AddExp
                       ------ MulExp
                       ------ SubExp
                       ------ DivExp
    ---------  FuncExp
    ---------  CExpressionEvaluator

NumberExp  : expression elementaire de nombre, sait actuellement traduire Pi et E
                          tres facile d'ajouter d'autres constantes
BinExp: Classe d'operations binaires (deux operandes) a+b a-b a*b a/b
               avec gestion de niveau de priorite des operateurs
               On peut facilement ajouter d'autres operateurs binaires (par exemple
               puissance ^ a^b ) - et les priorites relatives seront gerees en principe.
FuncExp: classe d'expression fonctionnelle, avec n arguments f(x1,x2,...x3)
                  actuellemenent, n=0 a n=3 arguments et quelques fonctions
                  usuelles sont decodes ds cette classe (sin,cos,tan, asin, acos, atan, exp, log,
                  atan2, pow ) - voir ds le code

CExpressionEvaluator : C'est la classe de haut niveau a utiliser -
                                            la fonction de decodage de la chaine ASCII (qui utilise
                                            les fonctionalites des differentes classes est la dedans
                                            et ce n'est pas tres long.
(+ une classe d'exception specifique).
\end{verbatim}

\end{itemize}

\section{PI,PIext,piapp} 
\subsection{ Codage texte des options graphiques (11 Mars 2004)}
\begin{verbatim}
//   Methode retournant un vecteur de string a partir des options
virtual int        PIDrawer::OptionToString(vector<string> & opt) const
qui vient completer les deux methodes
virtual int        PIDrawer:: DecodeOptionString(vector<string> & opt, bool ...) et
virtual void       PIDrawer:: GetOptionsHelpInfo(string& info);
Ces methodes s'occupent de decoder les options graphiques (et l'aide
associe). La methode ajoutee permet de faire l'operation inverse, fabriquer
une serie de chaine de caracteres a partir des options graphiques.
Il y a aussi la methode
virtual int            PIWdgGen::OptionToString(vector<string> & opt) const
que j'ai ajoute (rien a faire pour le moment) - ainsi que
int PIGraphicAtt::AttToStrings(vector<string> & att) const.

Peux-tu remplir la methode PIGraphicAtt::AttToStrings(vector<string> & att) const.
L'implementation par defaut de PIDrawer::OptionToString(vector<string> & opt) const
appelle PIGraphicAtt::AttToStrings() -  a laisser donc tel quel.

par contre, pour les autres drawer (PIYfXDrawer, PIFuncDrawer, PIElDrawer,
PISurfaceDrawer, PIHisto, PIHisto2D, PINTuple ...) - lorsque
DecodeOptionString(vector<string> & opt, bool ...) est modifie,
rajouter la methode OptionToString(vector<string> & opt) et verifier le help.
Attention, il ne faut pas mettre l'argument opt a zero, mais ajouter des chaines
derriere (push_back()) afin de pouvoir cumuler les options de base  + options
specifiques.

Comment tester ?
Pour tester, tu peux utiliser  la fenetre des options texte ou j'ai ajoute le bouton
[GetOption] . Tu peux acceder a cette fenetre a partir de la fenetre des options
graphiques <Alt>O , ou directement sur un objet de gestionnaire 2D - par
<Alt>T - <Shift>Button-1 permet de selectionner le drawer actif
\end{verbatim}

\subsection{ Trace des axes (11 Mars 2004)}
    Ajouter la possibilite de specifier l'origine (le point de croisement des axes)
lorsque les axes ne sont pas de type 'box' - classes PIAxes et PIElDrawer.

\subsection{ Selection graphique (souris) du drawer actif (11 Mars 2004)}
\begin{verbatim}
J'ai ajoute la methode PIDrawer::GetDistanceToPoint(double x, double y)
// Renvoie une distance au point x,y
// 0: au(x) point(s) le(s) plus proche(s) ... 1  au bord xmin/xmax , ymin/ymax
// La methode par defaut calcule la distance normalisee au point ((xmin+xmax)/2,
(ymin+ymax)/2)
  virtual double     PIDrawer::GetDistanceToPoint(double x, double y);

ainsi que ce qu'il faut ds PIBaseWdgGen et ds PIDrawer pour exploiter cette
methode + code permettant le test ds PIScDrawWdg.
(virtual  void      PIDrawer::WdgCoord2DrwCoord(int x, int y, double& xu ...
 virtual int PIBaseWdgGen:;FindNearestDrawerId(int x, int y) ...)
Tu as a t'aoccuper de la methode  PIDrawer::GetDistanceToPoint(double x, double y)
qui doit etre redefinie si possible pour chaque drawer, afin de fournir une
distance raisonnable au point (x,y) en argument.
J'ai juste mis une implementation par defaut (ds PIDrawer) et une implementation
partielle pour PIElDrawer (qui trace les axes en particulier) - qu'il faut
completer.

Comment tester ?
J'ai mis ce qu'il faut ds le gestionnaire 2D (PIScDrawWdg) -
<Shift>Button-1 choisit le drawer le plus proche (base sur la
valeur de retour de  PIDrawer::GetDistanceToPoint(double x, double y)
comme drawer actif. Ce drawer est passe en 'highlight' pendant que
le bouton est appuye.
\end{verbatim}

\subsection{ Manipulation interactive des drawers (3 Juin 2004) }
La manipulation interactive des drawers (ˆ l'aide d'un menu) a
ŽtŽ finalisŽe pour les PIImage PIScDrawWdg PI3DWdg .

\begin{verbatim}
   o <Alt>D affiche le menu avec les differentes option
   o Move/Resize: Affichage du rectangle + rectangle milieu
   (deplacement) + coin bas-droite (deplacement) - 
   clicker ailleurs pour finir
   o Mouse Select : Le mouse select des drawers est gere
   maintenant par un PIEventHandler (comme pour Move/ReSize)
   Drawer actif affiche par le rectangle muni d'un petit coin 
   (petit carre + rond dedans, en bas a droite). 
   Click souris change eventuellement le drawer actif. 
   On termine en clickant ds le petit [carre+rond] 
\end{verbatim}

\subsection{ Traceur de bar-graph (classe PIBarGraph) (3 Juin 2004) } 
Ajout du traceur de bar-graph (classe {\bf PIBarGraph}) ds module PI/
et commande {\tt bargraph}  ds PIext/basexecut.cc .
La commande bargraph ne gere pas encore toutes les possibilites
de la classe PIBarGraph. \\
Exemple d'utilisation:
\begin{verbatim}
Cmd> bargraph ' ' -10. 15. 22. 8. 33. 7 -4. 
Cmd> bargraph 'blue ' -10. 15. 22. 8. 33. 7 -4. 
Cmd> bargraph 'blue horizontalbars' -10. 15. 22. 8. 33. 7 -4. 
Cmd> bargraph 'blue horizontalbars barvaluelabel ' -10. 15. 22. 8. 33. 7 -4. 
Cmd> bargraph 'blue verticalbars nofill barvaluelabel ' -10. 15. 22. 8. 33. 7 -4. 
Cmd> bargraph 'font=times,bold,16 blue verticalbars nofill barvaluelabel ' \
     -10. 15. 2 2. 8. 33. 7 -4. 
Cmd> bargraph 'font=times,bold,16 blue verticalbars fill barvaluelabel packfrac=0.8' \
     -10. 15. 22. 8. 33. 7 -4. 
\end{verbatim}

\subsection{ Traceur de lignes de texte (classe PITextDrawer)  (3 Juin 2004) } 

Ajout d'une classe de traceur de lignes de texte (classe {\bf PITextDrawer}) et commande 
{\tt textdrawe}r ds PIext/basexecut.cc . Mais le traceur (et sa commande) 
doivent etre completes. \\
Exemple d'utilisation:
\begin{verbatim}
# On affiche qque chose
Cmd> openppf demo.ppf
Cmd> disp h1d
Cmd> textdrawer 'frame line=solid,2 font=times,bold,16 red inset'  \
     ' Christophe ' ' Reza Ansari' ' SOPHYA ' 
\end{verbatim}

\subsection{ Gestion de re-scale-ing des  axes en 3D  (3 Juin 2004)  }

Mise en place complete (?) de la gestion de re-scale-ing des  axes en 3D 
avec gestion des options graphiques (texte) - Il est possible en particulier d'imposer
les limites de la boites 3D.
cela a ete une grosse prise de tete de tout un apres-midi.
J'ai eu ensuite mal a la tete une partie de la soiree !  \\
Exemple d'utilisation:

\begin{verbatim}

# On ouvre le fichier demo.ppf
Cmd> openppf demo.ppf
Cmd> surf mtx1 'colbr32'
Cmd> surf mtx1 'colbr32 noautoscale'
Cmd> surf mtx1 'colbr32 lim3dbox=-10,60,-10,60,-3,15 autoscale3dbox'
#  Affichage avec superposition
Cmd> nt3d nt32 x y z - - - - - 'marker=circle,7 red'
Cmd> nt3d nt32 x y z - - - - - 'same marker=cross,5 blue '
#  Ou bien : 
Cmd> nt3d nt32 x y z - - - - - 'marker=circle,7 red noautoscale'
Cmd> nt3d nt32 x y z - - - - - 'same marker=cross,5 blue '

\end{verbatim}
\subsection{piapp}
\begin{itemize}
\item Le multithreading a ŽtŽ mis en oeuvre dans piapp (janvier 2004). 
\item Il faut par contre ajouter des possibilitŽs de controle du thread
d'execution des commandes. 
\item Extrait de {\tt cvs log pistdimgapp.cc } : 
\begin{verbatim}
revision 1.71
date: 2004/09/07 07:10:18;  author: ansari;  state: Exp;  lines: +35 -0
Ajout bloc try/catch ds piacmd.cc (thread execution commandes) et ds pistdimgapp.cc (
methode process, thread boucle d'evts) - Reza 07/09/2004
----------------------------
revision 1.70
date: 2004/01/06 18:44:56;  author: ansari;  state: Exp;  lines: +11 -1
 Suite debugging gestion lock entre threads ds piapp - A l'air de
marcher sur OSF1 et Linux ...   Reza 06/01/2004
----------------------------
revision 1.69
date: 2004/01/06 17:05:25;  author: ansari;  state: Exp;  lines: +33 -7
Suite debug piapp multithread : on ne peut pas utiliser ZSync() ds un if (destructeur
 appele de suite) - Reza 06/01/2004
----------------------------
revision 1.68
date: 2004/01/04 19:02:43;  author: ansari;  state: Exp;  lines: +43 -13
Suite des modifs pour piapp multi-threads
1) Ajout Mutex de synchronisation ds ls classe NamedObjMgr
2) Suite controle de gestion d'appel aux methodes de PIStdImgApp depuis
la classe elle-meme, a travers le NamedObjMgr
3) Modification de la boucle d'evenements, avec un thread de reveil
periodique
                                    Reza, 4 Janvier 2004
\end{verbatim}
\item Extrait de {\tt cvs log pistdimgapp.cc } : 
\begin{verbatim}
----------------------------
revision 1.62
date: 2003/11/27 10:51:58;  author: ansari;  state: Exp;  lines: +45 -20
Suite modification/adaptations a la classe PIACmd qui herite maintenent de SOPHYA::Co
mmander - Reza 27/11/2003
----------------------------
revision 1.61
date: 2003/11/26 23:01:55;  author: ansari;  state: Exp;  lines: +20 -1755
Modification du code de PIACmd : La classe PIACmd herite maintenant de la classe Comm
ander (de SysTools) - Reza 26/11/2003
----------------------------
revision 1.60
date: 2003/07/21 21:13:10;  author: cmv;  state: Exp;  lines: +3 -3
- introduction notion de numero de ligne dans expression ntuple
  modif prototype PlotExprFunc NTLoopExprFunc (add _nl _nstart _nend)
  modif int_4 -> int_8_exprf (long long) pour _nl (DecodeLoopParameters,
     PrepareNTExpressionCFile, LinkExprFunc,...)
- doc pour _nl _nstart _nend et arragement repartition RegisterHelp/RegisterCommand
             (rz + cmv 21/7/2003)
----------------------------
\end{verbatim}
\end{itemize}

\section{Documentation (Manual/) } 
Documentation des classes de SysTools. \\
Extrait message du 12 Aout 2004 : \\
\begin{verbatim} 
---> Au sujet de la doc (Manual/)
       J'ai installe doxygen sur le Mac, version 1.3.8 -
       Il faut updater le fichier de config de depart (dox_sophya.conf)
       Pour ma part, j'ai du modifier mkmf (en version privee) -
      En effet, il n'y avait pas le program doxysearch - Je ne sais pas si c'est general
      ou specifique Mac.

      J'ai aussi modifie certaines options de doxygen (en version privee)
     EXTRACT_LOCAL_CLASSES  --> NO   (au lieu de YES)
     DETAILS_AT_TOP  ---> YES     (au lieu de No)
     SORT_MEMBER_DOCS  ---> NO    (au lieu de YES)

      Si on es d'accord, on peut modifier ces options ds le fichier dox_sophya.conf et
      utiliser la fonction update de doxygen (doxygen -u)
\end{verbatim}

\section{Plan de modifs pour SOPHYA V 2.0 PI/piapp V 4.0 (Septembre 2003) }
\subsection{Gestion du code (Mgr/ ) }
\begin{verbatim}

 o Chemins/variables d'environnement
   - Remplacer DPCDEVREP DPCBASEREP par SOPHYADEVREP et SOPHYABASEREP
   - Remplacer EROSCXX par SOPHYACXX (?)
 o Simplifier/rationaliser les makefiles
   - Mettre les flags de compils pour chaque compilo-systeme dans un fichier au lieu
     d'avoir tout Makefile.h
     Exemple fichier Mgr/linux_g++.flags
      CPPFLAGS = ...
      CXXFLAGS = ...
      LIBS = ...

o Mettre un script pour chercher les lib externes (c-fitsio, FFTW, ...) et creer
  eventuellement l'arborescence ExtLibs

o Inclure la definition des flags influant sur le code (comme 
   -DOSF1/Linux/Darwin/IRIX64
   SO_BOUNDCHECKING a la fin du fichier machdefs.h que l'on fabriquera a 
   partir de du machdef_mkmf.h )
   PB-> ce fichier deviendra alors dependant du systeme et de l'installation !
   Faut-il deplacer alors Include/ sous uname-$EROSCXX (Linux-g++)
    ou carrement considerer que la separation pour differents systemes doit se faire au
  niveau de SOPHYADEV/BASE/REP ?

o Abandonner (?) les regles de compilation par defaut
  Inclure dans les Makefile la ligne de commande :
  $(OBJ)toto.o : toto.cc toto.h titi.h ...
        $(COMPILECXX) -$(CPPFLAGS) $(CXXFLAGS) -c -o $(OBJ)toto.o toto.cc

o Garder les Makefile simple (eviter trop de tests et syntaxe complique)

\end{verbatim}

\subsection{Code/Librairie SOPHYA $\rightarrow$ V 2.0)}
\begin{verbatim}

o Fichiers PPersist (BaseTools) :
  - Ajouter la possibilite d'ecrire des complex(r_4> complex<r_8>
    (actuellement c'est ecrit sous forme de 2*r_4 ou 2*r_8)
  - Ajouter des tag de positionnement qui pourrait servir au cas
    ou on utiliserait le fichier PPF comme fichier de swap
    Ces tags ne peuvent pas etre les memes que les name-tag
    existant actuellement.
    Une utilisation annexe de ces tags peut etre alors un moyen
    de verifier que le fichier n'est pas corrompu
    Ce tag se presente alors sous forme de
    <tag (1 byte)><FilePosition (8 byte, long int)>
    On peut alors parcourir le fichier et verifier la coherence de
    ces tags.
  - Il faut aussi ajouter au niveau de POutPersist et PInPersist
    les services pour ecrire et lire une collection de tag de
    positionnement, afin qu'un objet puisse utiliser une liste de
    tag pour se positionner

o BaseTools/ Voir autres remarques ds fichier Manual/sophya_afaire.txt
  concernant en particulier les NDataBlock<T> DataBlock<T> ...

o Les tableaux : TArray/
  - Ajouter une classe de base abstraite GenericMatrix<T>
    avec methode d'acces aux elements, nb de lignes, nb de colonnes,
    ...
  - Introduire les TinyMatrix  (TinyMatrix<T, int L, int C>)
    avec passage de/vers TMatrix<T> (et TinyVector<T, int N>) ?

  - Introduire des matrices creuses simples SpareMatrix<T>

  - Introduire les DiagonalMatrix<T>

  Remarque: Les TMatrix TinyMatrix et  SparseMatrix heritent de GenericMatrix

o HiStats
  - Faire une classe SuperNTuple (!), facile a utiliser, sachant swaper sur les
    PPF, avec des champs de differents type

o IFFTW/
  - Passage a FFTW 3.x  ?

o Voir autres remarques pour l'ensemble des modules ds Manual/sophya_afaire.txt
\end{verbatim}

\subsection{Code/Librairie PI  ($\rightarrow$ V 4.0)}
\begin{verbatim}

o Menu contextuel pour les Drawers
  - Ajouter a PIImage, PIScrDrawWdg(2D), PIDraw3DWdg(3D) un menu obtenu
    sur <Shift><Bouton-1> par exemple, avec la liste de tous les Drawers
    permettant d'afficher la fenetre des options graphiques, ou le fenetre
    des options ou la fenetre des options texte, activer deplacement/resize
    des drawers, suppression (delete) ou detach des drawers, et en fonction
    du widgets, la fenetre des axes ou de controle d'image

o Mettre l'option auto-scale (rapport entre axes X,Y,Z) pour les Drawers3D
    verifer/debugger la definition de la boite 3D au niveau des Drawers3D

o Traceur d'histos, NTuples, ...
  Remplacer le trace des lignes par morceau fait par appel multiples
  a DrawLine a un seul appel a DrawPolygon (si les lignes sont connectes
  bien sur) --> Ca ameliore sensiblement l'aspect pour le trace en pointille

o Ajouter un traceur de Bar-chart 2D OU ApplePie (facile !)
  On donne une serie de nombres, serie de couleur, + serie de strings
  et on trace alors une sorte d'histo, avec des barres (rectangles) espaces
   Ou bien on trace un cercle divise en zones

o Ajouter un traceur de Lego-Plot

o PIImageWindow (Une fenetre avec une PIImage, un Zoom et une vue globale)
  Assemblage

o (?) Une fonction pour faire facilement une fenetre d'alerte ou d'info (?)

\end{verbatim}

\subsection{(s)piapp ($\rightarrow$ V 4.0)}
\begin{verbatim}

o Verifier l'interpreteur et introduire le type de variable vecteur
  qui peut etre detecte par exemple lors de l'initialisation par set
  set a 'Bonjour CMV' # -> variable scalaire
  set va [ 12 14 hello ... ] # variable de type vecteur $va[]

o Voir comment on pourrait "joindre" deux objets ayant l'interface NTupleInterface
  pour pouvoir plotter des objets, l'un vs l'autre

o Separer la classe PIACmd en une classe de base (CShellLikeInterpreter)
  (a mettre ds SysTools) et la classe PIACmd  a laisser ds PIext

o (???) Introduire quelque chose du style
  AddDialogue("Cmd", "dialogue-description)
  qui pourrait fabriquer automatiquement une fenetre avec des champs a remplir
  pour les commandes usuelles (???)

o Voir les autres commentaires ds Manual/spiapp_afaire.txt

\end{verbatim}


\end{document}