Re: [Tsp-devel] Question sur le type 'String'

[Stephane Galles]

OK, donc dans ma TODO list je passe en priorité :

"Comment implémenter un ringbuf qui gère des types variables ".

C'est vrai que je restais conservateur pour la taille des strings
parceque je n'avais pas envisagé de toucher de nouveau au RingBuf
(A cause du vieux precepte : "ca marche bien, et depuis longtemps;
donc t'evite de toucher avec tes gros doigts").

Mais pas de problèmes, on va voir comment modifier le RingBuf.

Par contre, je vais créer une batterie de tests unitaires qui vont
aller avec le nouveau RingBuf, et il faudra les passer sur
toutes les plateformes pour attraper tous les problèmes
d'alignement.

Je sens que cela va nécessiter un FrameWork de test un peu sérieux.
Je connais quelqu'un qui a utilisé un FrameWork de tests unitaires
il y a peu de temps. Je vais le contacter car il en était trés content.
Je crois que c'est CUnit (http://cunit.sourceforge.net/) mais il
faut que je vérifie.

Steph.

Ibou de Joie wrote:

> Et un ringbuf qui gere des types de taille variable (Une zone memoire
> commune globale, et on decale le ptr courant de la taille du dernier
> element) : Certes on ne sait pas exactement le nombre de truc que l'on
> peut y mettre, mais on connait leur occupation mémoire totale ? Ce doit
> etre un peu tricky pour les pb d'alignement, et donc sans doute moins
> efficace, mais à voir.
>
> Et je suis (comme d'hab) d'accord avec Eric, le provider doit pouvoir
> donner la taille max de chaque element à la connexion.
>
> Y++
>
>
> On Sat, 2004-01-03 at 13:13, Eric NOULARD wrote:
>  
>
> > Selon Stephane Galles <address@hidden>:
> > Euh très honnêtement je pense que 8 caractères c'est un peu
> > petit quiqui pour un Caribou de ta trempe.
> >
> > Je ne vois pas précisément le pb du ring buffer 
> > car je n'ai pas le code sous la main là ou je suis
> > mais je pensais (bêtement) qu'une string avait une taille
> > a priori illimité mais que le provider annonçait au consumer
> > une taille MAX pour la session de sampling en cours de négoce.
> > Ensuite une fois la request_sample_init, on peut plus toucher
> > à la taille max, ce qui fait que le provider doit tailler
> > son ring-buf en fonction de ça.
> >
> >
> >    
> >
> > > Bon, je me suis lancé sur le codage des autres types, int, string, etc...
> > > J'ai commencé par le coté consumer. Je pense par contre que dans
> > > un premier temps, et quitte à me contredir, je ne vais pas utiliser
> > > les structures XDR pour la couche de transport. On vera cela
> > > dans un 2eme temps.
> > >
> > > Une question concernant le type 'String' : Il y a bien une taille max ?
> > > parceque si ce n'est pas le cas, je vais etre trés ennuyé pour les stocker
> > > dans un ringbuffer coté consummer.
> > >
> > > Donc je propose 8 charatères max pour les string. Simplement parceque
> > > les plus gros types (double et long long) font au max 8 octets et que donc
> > > on ne perd pas de place dans les ringbuf à cause des strings.
> > >
> > > j'espere que le besoin 'String' ne consiste pas à essayer de faire transiter
> > > des nombres en format string, sinon 8 charactères cela va etre un peu juste.
> > >
> > > J'avais compris ce besoin plutot pour faire passer des infos textuelles
> > > comme "ON", "OFF", etc ... Am I right ?
> > >      
> > Je pense que tu as raison, mais on peut vouloir faire transiter
> > un peu plus que 8 caractères.
> >
> > En gros, en ce qui concerne la taille max d'un string peut être dynamique
> > MAIS une fois que les sample sont en route celle-ci ne change plus.
> >
> > De façon plus général, le consumer "découvre" les types des symboles 
> > (et donc leur taille) avec une request_info et/ou la premiere 
> > request_sample ensuite ces tailles ne peuvent pas changer dès que les
> > sample ont commencés à transiter du provider au consumer.
> >
> > On pourrait imaginer que suite à un arrêt/redémarrage de la MEME
> > requete de sample la taille/le type d'un symbole est changé.
> > (si on oublie 30s le problème que ça pose côté provider).
> >
> > Qu'en penses-tu?
> >    
> >
> > > Stephane.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Tsp-devel mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > >
> > >      
> > --
> > ---
> > Erk
> >
> >
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> >
> >    
>
>
>
>
>