[Tsp-devel] RE: gdisp+ standalone

[DUFRENNE, Yves]

Je recommence, ayant oublié le fichier joint. Désolé pour les doublons.
######################################################################

Salut à tous. 

En fin d'année, il est toujours bon de se regarder le nombril : Si on résume
le besoin d'extension de TSP.

1) Des types + évolués.
=======================
Comme l'a dit Éric, tous les types simples du C, avec en priorité DOUBLE,
INT, et STRING, avec une gestion parallèle du signé/pas signé.
Le plus important étant de pouvoir facilement rajouter un type nouveau
OKAZOU.
En plus un type OPAQUE/RAW, qui corresponds à n BTYE, sans aucune gestion
des indiens. Il peut servir temporairement quand un nouveau type manque, le
consumer ayant par ailleurs une notion de décommutation du type, ou de
manière permanente pour des types très complexes (structures à la con et
autres).
Une notion de tableau serait intéressante, mais je ne vois pas encore bien
comment la décrire dans le protocole.
Notre Stéphane Québécois sera peut-être partant pour cette extension ?

2) Des browsers de variable sympas 
==================================
L'autre Stéphane (le basque) travaille lui sur un browser en GTK. En fichier
joints vous avez un main indépendant qui permet de plugger tout plot de
votre choix. Un grand jeux concours est lancé sur le + beau plotter, le
gagnant étant récompensé par une toque en mouflette canadienne.
Je me lance pour essayer de rajouter un plot Y=f(t) style tsp_gdisp.
Christophe P. travail va (enfin) se mettre au travail sur un couplage entre
jSynoptique (voir sourceForge) et TSP. On vous dira des que c'est chaud.
 
3) Un provider TSP sous VxWorks
==================================
La j'attends avec impatience Jérôme (parlant de libposix thread sous VxW) ou
Robert, parlant de tout et de n'importe quoi.

4) Une Gestion des commandes + Sioux
====================================
Éric a déjà travaillé pour rendre l'API de commande de TSP compatible de
plusieurs flux d'entrée, mais hélas nous restons RPC. Il faudrait un peu de
XML-RPC pour le coté Win, et du CORBA pour le coté High-Tech. On attends
toujours un volontaire, la récompense étant cette fois une soirée karaoké
avec un troupeau d'élans.

5) Une extension du protocole
====================================
La possibilité d'écrire sur des symboles serait vraiment un plus. La le KDO
reste encore mal défini mais j'attends vos propositions.

6) Et dans les goodies
====================================
Sockets secure, broadcast sur UDP, a vous de me dire ...

7) Et enfin
====================================
TSP sur des VRAIS projets.
Le SIF de pléiades est un bon partant. jSynoptique sur les PE pléiades
aussi. Enfin Éric travail aussi à le mettre au CNES. Que fait AirBus ???

Noyeux Joël et meilleurs Noeuds.

> -----Original Message-----
> From: Eric NOULARD [mailto:address@hidden
> Sent: Wednesday, December 17, 2003 8:07 AM
> To: Stephane Galles
> Cc: DUFRENNE, Yves; 'GARAY Stephane'; PAGNOT, Robert
> Subject: Re: gdisp+ standalone
> 
> 
> 
> Je propose une version bio-climatique de la moto
> c'est-à-dire une qui respecterait son environnement
> à la fois au niveau sonore et au niveau pollution,
> un truc qui irait pas trop vite pour pas être dangereux.
> 
> Beuh... qui a dit un vélo??
> Bon d'accord j'ai deux gros diesel qui polluent donc je
> bio-ferme ma g....e bioclimatique.
> 
> Sinon  pour les types, après une petite discussion avec Yves
> au téléphone, je donne mon avis qui n'engage que moi bien sur.
> 
> Je pense qu'il faut "un certain nombre" de type de base 
> 'user friendly' du genre:
> 
>     byte
>     short
>     int
>     long int (hyper integer en RPC je crois)
>     double
>     string
>     char    (1 seul caracère non signe)
> 
> à voir comment on gère le côté signé ou non sur les entiers.
> et il faut absolument un type 'opaque' que l'on peut appeler
> RAW histoire de s'en sortir si ça colle pas et qu'on veut
> passer une structure, un objet ou toute autre genre de cochonnerie
> que TSP ne pourra pas connaitre et qu'effectivement seul
> les 2 bouts seront capables d'identifier.
> 
> Effectivement on pourra de ce fait lier certains provider
> à certains consumer mais ça peut être (très) utile de 
> vouloir/pouvoir le faire.
> On peut d'ailleurs imaginer une sorte de mécanisme de 'plug-ins'
> (static ou dynamique) afin de rajouter des types à la con qui 
> n'ont rien à faire dans le core TSP.
> 
> Dans tous les cas il faudrait une méthode SIMPLE pour ajouter
> la gestion d'un type de donnée dans TSP.
> 
> On pourrait aussi s'inspirer de lib de passage de message comme MPI
> qui ne comprends qu'une poignée de type de base + des fonctions
> de l'API qui permettent de 'construire des types' (MPI_TYPE_xxx)
> cf http://www-unix.mcs.anl.gov/mpi/
> ou par exemple pour la construction d'une structure:
> http://www.mpi-forum.org/docs/mpi-11-html/node55.html#Node55
> 
> Le principe est qu'on "construit" un type avec
> les fonctions "MPI_TYPE_xxx" puis on le soumet à la lib
> avec MPI_TYPE_COMMIT. On peut ensuite utiliser ce type dans
> les prochaines communications.
> 
> ET PUIS il y a un truc qui est presque aussi important que
> la gestion de type multiple c'est la gestion des TABLEAUX.
> Je souhaiterai qu'on puisse gérer les tableaux de données
> d'un même type de façon orthogonale au type.
> 
> En gros il n'y a pas de type Tableau_de_double
> il y a des doubles dont on peut faire des tableaux ou pas.
> 
> Go on Easy Typer.
> 
> Eric
> 
> Selon Stephane Galles <address@hidden>:
> 
> > OK, hum...Je me propose d'offrir une housse de casque de 
> moto en moufette.
> > Trés classe.
> > ca donne un style David Croquette, mais avec une je ne sais 
> quoi d'Easy 
> > Rider
> > (Chevauche Facile en VF).
> > Et puis c'est de la peau de moufette attendrie à coup de crosse de 
> > hockey, directement
> > sur la moufette. Généralement elle n'aime pas la moufette. 
> C'est pour cela
> > que les moufettes n'aime pas le hockey. C'est trés peu 
> connu comme fait, ça.
> > 
> > Blague à part, pour les types autres que les doubles... dés 
> idées ont 
> > elles germée
> > concernant la nécéssité d'implémenter des RAW ?
> > 
> > Je rappelle la problématique :
> > - Soit on implémente des RAW et on va lier des consumers aux
> > provider, et ca en est fini de la belle universalité des consumers
> > - Soit on n'implémente que des types user-friendly, et...et c'est
> > bien. Heu...On a vraiment besoin des RAW ?
> > 
> > Vala.
> > 
> > Je vous laisse j'ai une moufette à aller faire boucaner.
> > 
> > DUFRENNE, Yves wrote:
> > 
> > > Yo !
> > > J'hallucine que toi qui a failli te faire écraser sur ta 
> moto par un 
> > > automobiliste manifestement myope au point de te 
> confondre avec rien, 
> > > tu arrives a revenir avec un travail effectué sur TSP. 
> Ils sont trop 
> > > forts ces basques : Je propose que nous nous cotisions pour lui 
> > > racheter une moto des qu'il aura publié le code, et que nous 
> > > renommions TSP en TSPskady. Je commence, j'offre déjà 2EUR 
> (On a bon 
> > > espoir pour une ZZR 1100)
> > > Je suis preneur d'essayer pendant les vacances, de faire 
> le plotter 2D 
> > > y=f(t) à partir de TSP_GDISP. Comme cela Steph G (le 
> trappeur du grand 
> > > nord) aura + de temps pour implémenter les types != double.
> > > Y++
> > >
> > >     -----Original Message-----
> > >     *From:* GARAY Stephane [mailto:address@hidden
> > >     *Sent:* Tuesday, December 16, 2003 10:34 AM
> > >     *To:* 'Stephane Galles'; DUFRENNE, Yves
> > >     *Cc:* 'Eric NOULARD'; PAGNOT, Robert
> > >     *Subject:* gdisp+ standalone
> > >
> > >
> > >     Salut,
> > >
> > >     La version standalone de gdisp+ est presque prête.
> > >     Il me manque à hyper-commenter le code pour vous
> > >     permettre d'insérer au mieux votre plot 2D hyper
> > >     optimisé de la mort qui scrolle.
> > >
> > >     Stéphane.
> > >

gdisp+.tar
Description: Binary data

important_notice.txt
Description: Text document