Re: RE : RE : [Tsp-devel] gérer un nombre de symboles...hum...important

[Eric NOULARD]

L'idée de l'arborescence me plaît bien.
Et que chaque "dépliage" de l'arbre génère une autre request_info
c'est pas bête du tout, c'est un peu près de ce que font
les IHM du genre JTree, et ça m'a l'air bien adapté à notre problème :))
[bon aujourd'hui c'est surtout le mien mais je suis content
 que vous vous y intéressiez]

Je pense toutefois qu'un truc "du genre" select ou regexp est
souhaitable "en plus".

J'irais même jusqu'à dire que
arborescence + pattern matching ça me fait un peu
penser à XPath

http://www.w3.org/TR/xpath
http://www.zvon.org/xxl/XPathTutorial/General/examples.html

En plus on aurait "tout ce qu'il" faut en C ou Java pour utiliser
XPath.

Bien évidemment on gardera une API bien plate pour les archis
genre VxWorks où ce sera peut-être difficile dans l'immédiat
d'avoir une libxml digne de ce nom??

Encore que certains se posent la question:

http://mail.gnome.org/archives/xml/2003-October/msg00200.html
http://mail.gnome.org/archives/xml/2003-July/msg00041.html


Pis tant qu'à faire de l'XML pour les fichiers de conf
ben pourquoi pas en mettre un peu plus là où ça semble utile?

Bon la nuit porte conseil et hop dodo.

Eric

Le jeudi 10 mars 2005 à 13:21 -0500, Stephane GALLES a écrit :
> Bon, je vais peut etre délirer un peu là mais...
> 
> IMHO, J'ai l'impression que ni le select ni le regexp ne résoudra
> le problème fondamental de quelqu'un qui arrive sur un provider qui a 2000000
> symboles et qui veut faire un peu d'introspection.
> 
> - Si la personne ne sait pas du tout comment s'appel sont symboles, elle
> ne va pas parcourir 200000 écrans de 10 symboles pour le trouver.
> - Si la personne doit savoir que le symbole commence par une chaine
> précise, genre TEMP_, avant même d'avoir vu la liste de symboles
> je trouve cela dommage , car l'idée d'un provider est d'être auto
> descriptif
> 
> Moralité, Peut etre que c'est fondamentalement la manière dont sont
> organisés les symboles qu'il faudrait changer. Il ne faut plus une
> liste à plat. Il faut un arbre. C'est à dire avec des "répertoires
> de symboles", et tout en bas les symboles.
> 
> Avec une nomenclature genre filesystem, un symbole pourrait être affiché
> /VOITURE/MOTEUR/INJECTEUR/TEMP1
> Mais en terme d'implémentation sont nom est TEMP1 et il est contenu dans
> le "Repertoire" INJECTEUR
> 
> L'idée est de tenir compte de la structure en arbre directement au
> niveau du protocole, et que cela apparaise clairement dans l'API,
> ce qui permettra de factoriser les données sur le réseaux (les
> noms de symboles restent courts)
> 
> Je vois la résolution immédiate de deux cas d'utilisation :
> 
> 1 - Pouvoir browser sur un provider avec plein de symboles :
> Imaginez un widget type TreeView. Avec les répertoires affichés.
> au départ le GUI demande tous les repertoires et symboles de niveau /
> et à chaque fois que l'utilisateur déscend dans les répertoires
> un nouveau requestinfo est fait pour le niveau demandé
> 
> 2 - Et je me demande si cela ne permettrait pas d'implémenter toutes
> les structures de données du monde pour le même prix (tableaux,
> tableaux à plusieurs dimensions, arbres, etc...)
> Imaginons les symboles
> IMAGEBITMAP/X/1
> IMAGEBITMAP/X/2
> IMAGEBITMAP/X/3
> IMAGEBITMAP/X/4
> IMAGEBITMAP/Y/1
> IMAGEBITMAP/Y/2
> IMAGEBITMAP/Y/3
> IMAGEBITMAP/Y/4
> Ho ! Un tableau à deux dimensions !
> 
> Je divague là ?
> 
> 
> Selon address@hidden:
> 
> > Euh en fait,
> >
> > MEME pour tsp_gdisp en mode interactif c'est rédhibitoire
> > que le request_info demande TOUS les symboles.
> >
> > Dans mon petit exemple REEL (j'insiste) le provider offre:
> >
> > 1 865 896 symboles TSP !!!
> >
> > Evidemment ce nombre de symboles est "déraisonnable"
> > et provient surtout du fait que TSP ne gère pas les tableaux
> > et que le Blackboard les gère, du coup un
> > symbole Blackboard qui est un tableau de 10000
> > génère 100000 symboles TSP :))
> >
> > Mis à part ça, le fait est que le provider gère tranquillement
> > son 'presque 2 millions de symboles' vu qu'en fait
> > on ne lui demande d'en distribuer qu'une poignée (genre 50/100).
> > [hors mis la conso mémoire qui dépasse les 200Mo]
> >
> > Sauf que vu la façon dont l'API consumer gère la request info
> > effectivement il y a:
> >
> > 1) un traffic réseau du diable (100Mo++) vu qu'on trimbale en RPC
> >    comme le dit Yves beaucoup trop de donnée.
> >    Et OUI c'est l'appel RPC qui bouffe tout le temps.
> >
> > 2) A la fin de l'appel le consumer (par exemple tsp_gdisp)
> >    consomme 200Mo ++ de mémoire alors qu'il
> >    n'en demande effectivement que 50/100.
> >
> > Le mécanisme "a la SQL" de Fred est sympathique et plus
> > puissant qu'une regexp, maintenant à implémenter c'est peut-être
> > moins immédiat....
> >
> > Des volontaires ?? :))
> >
> > Eric
> >
> > -------- Message d'origine--------
> > De: address@hidden de la part de
> > TSP
> > Date:       jeu. 10/03/2005 16:38
> > À:  'address@hidden'
> > Cc:
> > Objet:      RE : [Tsp-devel] gérer un nombre de symboles...hum...important
> > Et il faudrait aussi une API pour recuperer le nombre de symboles coté
> > provider.
> > Maintenant pour gdisp en mode interactif, c'est sur que tu es obligé de
> > passer par le request info.
> >
> > Tu as essaye un coups de profiler avec gprof pour voir quelle fonction
> > prenait du temps ? C'est sans doute l'appel RPC, mais a verifier. Si oui, la
> > structure est très grosse (en + du nom on a 6 entiers, et un opaque, c'est à
> > dire que l'on double au moins la taille de la structure en moyenne, + les
> > appels à xdr_decode).
> >
> > On pourrait aussi ne recuperer que la liste des noms dans le request (+
> > infos du provider), et demander les infos pour la liste de symbole qui nous
> > interessent.
> >
> > Y++
> >
> > -----Original Message-----
> > From: Stephane Galles [mailto:address@hidden
> > Sent: Thursday, March 10, 2005 1:38 PM
> > To: address@hidden
> > Cc: address@hidden
> > Subject: Re: [Tsp-devel] gérer un nombre de symboles...hum...important
> >
> >
> >
> > Hum...A la décharge de jSynoptic, je pense qu'il suffit juste
> > d'augmenter la taille de mémoire disponible dans Java au lancement
> > (c'est une sécurité pour éviter qu'un process ne gèle une machine)
> >
> > Actuellement le lancement par 'ant jsynoptic-run' se fait avec la taille
> > par défaut. Mais dés qu'on fait des choses un peu osées, il faut la
> > modifier.
> >
> > Pas le temps là, mais je fais cela ce soir  (donc cette nuit...)
> >
> > A vu de nez, quand tu a lancé tsp_gdips+ la taille mémoire de ton PC
> > a chuté de combien ?
> >
> > Néamoins, effectivement le fichier de conf xml s'impose de plus en plus.
> >
> > Steph
> >
> >
> > address@hidden wrote:
> >
> > >Je joins à mon mail un petit screenshot
> > >d'un TSP gdisp+ qui a mis environ 1 minute à démarrer,
> > >je vous laisse chercher pourquoi...
> > >
> > >A noter qu'en voulant connecter jsynoptic à ce
> > >provider TSP OPERATIONNEL (bb_provider),
> > >il m'a gentiment explosé à la tronche--> "Out of Memory".
> > >
> > >Ce n'est pas le cas de tsp_gdisp+ qui a juste "souffert"
> > >pour démarrer.
> > >
> > >A noter que même si certain consumer ont souffert le
> > >provider lui semblait peinard :))
> > >Je resalue stéphane pour ça.
> > >
> > >Donc il faut ABSOLUMENT prévoir que:
> > >********************************************
> > >les consumers ne fasse PAS SYSTEMATIQUEMENT
> > >une requete "tsp_request_infos".
> > >********************************************
> > >
> > >je vois 2 solutions à ça,
> > >
> > >1) La première est en cours fichier de conf.
> > >   (sauf que dans le cas de jsynoptic ça marche pas
> > >    aujourd'hui parce qu'on ne sait pas créer un
> > >    fichier de conf sans se connecter à un provider
> > >    et donc envoyer l'infâme request_infos...)
> > >
> > >2) La deuxième c'est qu'on implemente une API
> > >   requests_infos_limited qui renvoie un nombre limités
> > >   de symboles qui correspondent à un pattern (regexp)
> > >   on peut/doit imaginer un moyen de les découvrir
> > >   tous mais par petit bout...
> > >
> > >Voila quand on laisse des utilisateurs mettre ...
> > >autant de symboles qui veulent ce que ça donne :))
> > >
> > >Eric
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Tsp-devel mailing list
> > >address@hidden
> > >http://lists.nongnu.org/mailman/listinfo/tsp-devel
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >
> >
> >
> >
> 
> 
> --
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>