[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tsp-devel] TSP refactored needs TESTERS...
From: |
Eric NOULARD |
Subject: |
[Tsp-devel] TSP refactored needs TESTERS... |
Date: |
Mon, 19 Sep 2005 02:03:56 +0200 |
Salut à tous,
Le refactoring avance à grand pas, enfin j'espère.
Je me suis donc mis au travail dans la branche:
br_TSP_0_6_5_REFACTOR_DEVEL
J'ai besoin d' (au moins) un testeur pour les modifs
que j'ai fait dans vxstub, vu que j'ai pas de vxworks sous la main...
J'aimerais aussi que quelqu'un me lance les autotests dans un
environnement [t]csh car chez moi je galère... je pense que je
vais ré-écrire ces scripts de test en sh ou perl ou python
(merci de me donner votre avis).
Je pencherais pour perl car assez portable et indépendant du shell.
Donc pour tester:
cvs co -r br_TSP_0_6_5_REFACTOR_DEVEL
et puis après c'est comme d'hab.
Ce qui est fait:
------------------
i) API orienté objet pour le GLU
et modif qui en découle dans src/core/ctrl et src/core/ctrl_init
l'API générique est décrite dans src/core/ctrl/glue_sserver.h
les "méthodes par défaut" dans src/core/ctrl/glue_sserver.c
du coup l'écriture d'un GLU est (encore) plus simple,
je pense qu'on peut encore faire mieux mais là c'est déjà
sympathique.
ii) MAJ des providers:
bb_provider -> OK (dont amélioration perfo sur valid. symbol)
stub -> OK
vxstub -> A TESTER (je n'ai pas de moyen de le faire)
res_reader -> NOK reste (au moins) 1 BUG recalcitrant
qui fait un core dump...
rt_stub/bbrt_stub -> A TESTER
iii) Preparation du merge TSP_WRITE
en cours avec API OO pour le GLU.
Ce qui reste à faire: (hormis les tests provider incomplets)
---------------------
1) dégommer le bug res_reader
2) merge TSP_WRITE avec prévision tsp_async_read (déjà prévu dans ooGLU)
3) ajout d'une requête tsp_request_simple_info
cette requêtes ne renverra PAS la liste des symboles mais
seulement les infos providers (nom, fréquence) et éventuellement
le nombre de symboles.
Ceci afin d'éviter la mort réseau pour un provider à what millions
de symboles.
4) isoler le core tsp des types RPC
5) inverser la logique d'appel (ça c'est pour Yves :)) )
6...1000) pas mal d'autre trucs.
J'aimerais revenir sur le trunk après avoir fait
au pire 1) ou 2)
au mieux 3)
et je compte faire le 4) sur le trunk directement (a voir).
comme vous le verrez y'a hum... quelques modifs.
Donc si je reviens sur le trunk avec tout ça je propose
de créer un tag de branche br_0_6_x sur le trunk actuel
afin de pouvoir éventuellement faire des patches dans cette
branche pour ceux qui désireraient rester en API GLU ancienne
formule.
Une fois revenu sur le trunk je creerai une 0_7_0
qui sera notoirement incompatible (en terme d'API) avec
la branche 0_6_x.
J'attends vos retours et continue sur 1) et 2).
sauf si quelqu'un veux se taper le 1) à ma place...
Eric
- [Tsp-devel] TSP refactored needs TESTERS...,
Eric NOULARD <=