Selon address@hidden:
Bon on arrête là les louanges...
J'attends plutôt mon PC 3 Ghz tout neuf...
Private Joke...
Pour l'autoscalling sur l'axe X, personnellement, il ne
me plaits pas. Ne me plait pas non plus le look des axes
fournis par le widget GtkRule de Gtk.
Je voudrais bien ré-implémenter tout ça pour avoir des
axes qui prennent moins de place. Faut voir ça ensemble.
Pour l'instant, pouvez-vous me dire TRES PRECISEMENT ce
qui ne va pas ?
0) Le problème le plus important [pour moi]
est un déconnage APPARENT de l'autoscaling sur ma Mdk10
ou visiblement tout autre distrib' utilisant la NPTL
(j'ai testé chez un client sur RedHat et Gentoo)
On obtient des traits discontinus hératiques pendant
"un certain temps" avant que l'autoscaling 'accroche'
et trace enfin une courbe???
Je peux pas faire de screenshot car je suis pas sur mon PC
dès que j'ai moyen d'en faire un je le fais.
Yves à constaté le pb aussi.
1) L'autoscaling en Y est capable de faire le zoom OUT
i.e. les valeurs en Y grandissent mais pas
le zoom IN quand les valeurs en Y on rediminuées et
que les dernières "grandes valeurs" ne sont plus dans
le champs des abscisses visibles.
2) Tu as raisons pour l'autoscaling en X on doit clairement
pouvoir CHOISIR:
- choisir un range de X visible manuellement
- choisir une "durée" de X quand on sait que X
a le comportement d'une variable temporelle
(strictement positive et croissante)
Autre chose : adieu le "click & click" à la Gégé. Je ne pense
pas l'implémenter tout de suite car il faut que je creuse beaucoup
plus, la faute au plot text pour lequel je ne peux pas outrepasser
la gestion du click. Click = sélection et c'est tout.
Je pense que la sauvegarde XML est plus importante (Sorry Gégé, mais
il ne le saura jamais).
Ben si il le saura je vais lui dire :))
Que tu as raison la sauvegarde est plus importante.
Pour le Drop en cours de run, je suis surpris. Certes c'est plus robuste
mais un nouveau symbole dans un plot ne sera tracé que si il l'est déjà
dans un autre plot. Car je ne re-programme pas le flux entre le provider
et gdisp+.
Ben je suis tombé sur un cas qui marche :))
Pour terminer, je commence ASAP la sauvegarde XML. D'abords l'implémentation
dans le kernel et les plots. Dois-je attendre la spec d'Eric quant au
format XML ?
La sauvegarde XML toi s'appuyer sur une lib externe aux consumer.
Genre la libpages (src/util/libpage/) de gdisp--.
J'ai un WE calme donc je vais sortir un draft de spec rapidement.
Par contre je pense que tu devrais commencer par utiliser
la libpage ACTUELLE pour une LECTURE de conf mono-provider
ou alors LECTURE d'un fichier par provider.
Comme ça tu auras un regard critique aiguisé sur la "spec" actuelle
pour critiquer ACTIVEMENT celle qui viendra.
Je dis LECTURE car je ne sais même pas si la libpage ACTUELLE permet
la sauvegarde....
L'objectif étant bien que même si tu utilises la libpage ACTUELLE
ça te coutes pas beaucoup de changements [côté gdisp+] pour passer
à une autre lib .
Esteban.
-------------
29/10/04 11:05:32, TSP <address@hidden> wrote:
La regression dont tu parles sur tsp_gdisp m'a l'air de venir depuis que
nous utilisons la MDK10.0
En effet Stephane n'a pas ce genre de problemes, mais je lui avait déja
relévé le bug de l'autoscrolling qui se décale au fur et à mesure vers la
droite.
Y++
-----Original Message-----
From: NOULARD Eric [mailto:address@hidden
Sent: Thursday, October 28, 2004 10:15 PM
To: Devel TSP
Subject: [Tsp-devel] Bravo gdisp+
Je dois tirer mon chapeau à gdisp+ ce soir
car je l'ai testé après un update -A
et:
1) il est désormais robuste au drag&drop
en cours de run
2) le drag&drop est désormais super facile
grace au X et Y en surimpression
3) Je l'ai testé avec 2 providers locaux
et fait un tracé Y_provider1 = F(X_provider2)
et ça marche !!
Bon évidemment j'ai un peu triché car j'ai lancé
2 bb_provider de même fréquence qui attaque en fait
le même Blackboard!!!
[c'est pas trop prévu pour mais ça fonctionne
sauf que les 2 bb_provider se 'partagent'
la fréquence de production de la pseudo
simulation [bb_test -s] qui
4) Encore plus fort [débile] j'ai lancé 3 provider
2 bb_provider sur le même blackboard
1 stub_server
J'ai demander à gdisp+ de tracer
bb_provider1::bb_test_Toto[1]
bb_provider2::bb_test_Toto[2]
en fonction
de stub_server::t
Et ça marche!!
J'ai des escaliers car le stub est à 100Hz et
les bb_provider des 'pseudo' 2x32Hz (64/2)
On va bientôt pouvoir faire une démo de tueur!!
Je vais m'activer pour fournir une spec de fichier de conf
pour les consumer et on aura bientôt un gdisp+ qui va
en faire pleurer plus d'un.
Toutefois gdisp+ souffre encore d'une lacune rédhibitoire qui
est un [très] mauvais auto-scaling, courbe crénelée, saut etc...
Est-ce qu'une bonne âme pourrait [aurait le temps]
s'attaquer au problème?
[perso c'est pas trop mon rayon]
Eric
--
Eric NOULARD
E-mail: address@hidden
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel
--
---
Erk
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel