RE : [Tsp-devel] URL + Gdisp+

[Eric.NOULARD]

Euh evidemment je prends le gdisp+ qui lave plus blanc que blanc.
Et j'attends avec impatience le patch qui suivra pour le (0,0) :))

Sinon quand tu dis il marche même sur SUN c'était quoi le bug?
Eric

-------- Message d'origine--------
De:     address@hidden de la part de TSP
Date:   mar. 16/11/2004 10:37
À:      'address@hidden'
Cc:    
Objet:  RE: [Tsp-devel] URL + Gdisp+
Pour ma part je suis plutot d'accord avec l'homme du grand nord.
Je veux bien à la limite comprendre le coté facile d'utilisation, si
l'utilisateur met //toto* , car là il explicite son coté implicite....
M'enfin comme c'est pas moi qui code cette partie....

Sinon le plot2D de tsp_gdisp+ est presque entierement fini d'être corrigé,
et il marche meme sur SUN. Vous pouvez le tester, mais je n'ai pas encore
verifié tous les cas.
Il y reste encore 1 bug ferme : Le kernel (TSP ou gdisp+) m'envoi comme
premier point {0,0) que je sais filtrer avec 1 courbe, mais pas avec
plusieurs tracé sur la meme courbe. Dans ce cas la l'autoscale n'est pas
correct en Xmin. A vous de voir si vous prenez quand meme ce nouveau gdisp+
ou attendez la correction.

Y++

> -----Original Message-----
> From: Stephane Galles [mailto:address@hidden]
> Sent: Tuesday, November 16, 2004 12:46 AM
> To: tsp-devel
> Subject: Re: [Tsp-devel] JTSP + URL = ""> >
>
> Hello,
>
> ben, non, j'ai pas d'idée précise de spec, je disais cela
> parceque je ne
> suis pas
> un adepte des comportements laxistes. Néanmoins, je me range
> à l'avis de la majorité et j'implémente ce que vous voulez coté Java.
>
> Si je comprend bien ta réponse Eric, tu préfère que
> les comportements laxistes (case insensitive, début de nom de serveur)
> soient implémentés dans la lib TSP avec possibilité de l'activer
> ou non, c'est ça ? Genre avec des options dans l'API et le client
> choisi ce qu'il veut activer ?
>
> Confirme moi cela, et pas de problèmes, je l'implémente.
>
> En tous cas, merci Robert pour tes explication sur les URL, mon
> but est quoi qu'il en soit de faire en sorte que la partie JAVA
> ait le même comportement que la partie C
>
> Au fait jsynoptic est en bonne voie d'utiliser les URL,
> j'ai pas fait de commit mais cela marche.
>
> (Pour conclure sur le sujet, Je veux juste modifier trés légèrement
> l'exemple de Robert
>
> Un serveur avec :
>
>     totoNewGen:0
>     toto:1
> On a :
>     ///toto        =>    totoNewGen:0
>     ///toto:0        =>    totoNewGen:0
>     ///toto:1        =>    toto:1
>
> Voila, je n'aime pas trop à cause de ce cas, mais je comprend
> que ce comportement puisse plaire quand même dans les cas simples)
>
> A+
>
> Steph
>
> NOULARD Eric wrote:
>
> >Bah c'est pas très joli...
> >Mais ce sera probablement & [malheureusement] apprécié des
> utilisateurs
> >ce comportement laxiste :))
> >
> >Mon avis est que c'est à l'appli consumer finale
> >(stdout, jstdout, tsp_gdisp·..) d'être tolérante
> >case insensitive, match partiel etc...
> >
> >La request handler RPC peut lui fournir le service de recherche
> >du progid "à la limite" mais pour ce qui est du nom
> >ben faudrait être plus strict.
> >
> >Ce qui m'embête dans l'histoire c'est pas tant de
> >matcher le premier provider c'est de ne pas savoir que
> >j'aurais pu en terminant l'URL autrement savoir qu'il en
> >avait 2...
> >
> >Quoiqu'il en soit si Stephane nous propose une specs
> >qui allie souplesse et strictness ben je l'accepte et je veux
> >bien le coder pour C.
> >
> >Toutefois j'admet que la recherche "intuitive" de l'URL dépend
> >du protocole donc on peut admettre que le request handler RPC
> >soit plus 'tolérant' que son homologue CORBA/XML-RPC etc...
> >
> >Et pis autant avec un service de nommage CORBA on doit
> >pouvoir découvrir TOUS les serveurs TSP autant avec RPC
> >partir à la recherche de tous les serveurs existant et qui matche
> >une URL donnée doit pouvoir durer un long moment??
> >
> >Le lun 15/11/2004 à 15:18, PAGNOT, Robert a écrit :
> > 
> >
> >>Eh ben tant pis, si l'utilisateur ne spécifie pas un
> SERVERNAME complet, il
> >>trouvera le premier qui correspond ...
> >>
> >>Par conséquent, supposons que l'on ait sur une même machine:
> >>    toto:0
> >>    totoNewGen:1   (car :0 est impossible car RPC_PROG_ID différents
> >>!!!)
> >>
> >>Alors un accès URL du style ... donnera ... :
> >>    ///toto         =>      toto:0
> >>    ///toto:0               =>      toto:0
> >>    ///toto:1               =>      totoNewGen:1
> >>    ///totoNewGen   => totoNewGen:1
> >>    ///totoNewGen:0 => erreur !!!
> >>    ///totoNewGen:1 => totoNewGen:1
> >>
> >>Je n'ai pas testé ces comportements limites, le cheminement
> chaotique de mon
> >>esprit tordu n'est pas arrivé jusque là {:o]
> >>
> >>Je mets notre bon Eric en copie au cas où il serait pas d'accord :-[
> >>
> >>A+
> >>
> >>    Robert
> >>
> >>
> >>   
> >>
> >>>-----Original Message-----
> >>>From: Stephane Galles [mailto:address@hidden]
> >>>Sent: Monday, November 15, 2004 3:07 PM
> >>>To: PAGNOT, Robert
> >>>Cc: tsp-devel
> >>>Subject: Re: [Tsp-devel] JTSP + URL = ""> > >>>
> >>>
> >>>Hello,
> >>>
> >>>OK. Pourquoi pas.
> >>>
> >>>Mais que fait - on si on a deux providers genre :
> >>>
> >>>toto
> >>>totoNewGen
> >>>
> >>>pour se connecter à toto avec :///toto
> >>>On risque d'embarquer totoNewGen...
> >>>
> >>>Ou alors il faut des wildcard.
> >>>
> >>>A+
> >>>
> >>>Steph
> >>>
> >>>PAGNOT, Robert wrote:
> >>>
> >>>     
> >>>
> >>>>Désolé, cela doit effectivement marcher comme ça, d'où
> >>>>       
> >>>>
> >>>l'utilisation de
> >>>     
> >>>
> >>>>strncmp(X,Y,strlen(X)) dans tsp_client.c. Et je devrais même
> >>>>       
> >>>>
> >>>traiter le
> >>>     
> >>>
> >>>>"Case sensitivity" pour prendre n'importe quoi en utilisant
> >>>>       
> >>>>
> >>>strncasecmp ...
> >>>     
> >>>
> >>>>C'est clair que c'est un comportement "aux limites". Je le
> >>>>       
> >>>>
> >>>rajouterai dans
> >>>     
> >>>
> >>>>les USAGEs des URLs.
> >>>>
> >>>>A+
> >>>>
> >>>>  Robert
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>       
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Stephane Galles [mailto:address@hidden]
> >>>>>Sent: Monday, November 15, 2004 2:42 PM
> >>>>>To: PAGNOT, Robert
> >>>>>Cc: tsp-devel
> >>>>>Subject: Re: [Tsp-devel] JTSP + URL = ""> > >>>>>
> >>>>>
> >>>>>Salut Robert,
> >>>>>
> >>>>>oui, je crois que j'avais bien compris le fonctionnement
> de l'URL,
> >>>>>mais il y a quand même, à mon avis, quelque chose d'étrange
> >>>>>dans l'utilisation du SERVERNAME pour la partie C.
> >>>>>
> >>>>>Apres avoir regardé de plus près, en fait c'est plus
> subtil que je
> >>>>>ne pensais :
> >>>>>
> >>>>>Lance le StubbedServer et connecte toi sous stdout avec
> >>>>>:///StubbedServer
> >>>>>Cela marche. C'est normal
> >>>>>
> >>>>>Lance le StubbedServer et connecte toi sous stdout avec
> >>>>>         
> >>>>>
> >>>:///blablabla
> >>>     
> >>>
> >>>>>Cela ne marche pas. C'est normal
> >>>>>
> >>>>>Lance le StubbedServer et connecte toi sous stdout avec :///Stu
> >>>>>Cela marche ! CE N'EST PAS NORMAL (du moins je ne crois
> >>>>>pas ou alors il faut documenter ce comportement).
> >>>>>
> >>>>>A+
> >>>>>
> >>>>>Steph
> >>>>>
> >>>>>
> >>>>>PAGNOT, Robert wrote:
> >>>>>
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>Salut Stéph,
> >>>>>>
> >>>>>>Le principe de l'utilisation de l'URL (tu peux les voir
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>d'ailleurs dans les
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>help des consumers C) consiste à :
> >>>>>>        <rpc://hostname> => trouve le premier provider
> existant sur
> >>>>>>"hostname", soit un fonctionnement identique à la pré-histoire.
> >>>>>>
> >>>>>>        + </servername:port> permet de préciser un peu
> plus à qui l'on
> >>>>>>s'adresse, en cas de multi-providers. Pour info, avec Yves,
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>on travaille sur
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>la même machine avec des providers différents, et chacun se
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>connecte avec
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>une URL du type <///myServerName> et ça marche !!!
> >>>>>>
> >>>>>>        Par conséquent, on tient compte du SERVERNAME,
> lorsqu'il est
> >>>>>>explicité. Le pb, est qu'avec RPC, on doit établir une
> connection
> >>>>>>(clnt_create) pour connaître le nom de celui qui est au bout
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>du fil ...
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>        On pourrait s'amuser à créer une table de hash pour
> >>>>>>SERVERNAME:PORTNUM et utiliser l'ID sortant du hachage comme
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>RPC_PROG_ID ?
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>Cela éviterai les tentatives de connection ...
> >>>>>>
> >>>>>>A+
> >>>>>>
> >>>>>>Robert PAGNOT
> >>>>>>ASTRIUM SAS
> >>>>>>AEA56 - Ground Systems
> >>>>>>tél.: 05 62 19 55 32
> >>>>>>fax.: 05 62 19 77 41
> >>>>>><mailto:address@hidden>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>    
> >>>>>>
> >>>>>>           
> >>>>>>
> >>>>>>>-----Original Message-----
> >>>>>>>From: Stephane Galles [mailto:address@hidden]
> >>>>>>>Sent: Sunday, November 14, 2004 10:15 PM
> >>>>>>>To: tsp-devel
> >>>>>>>Subject: [Tsp-devel] JTSP + URL = ""> > >>>>>>>
> >>>>>>>
> >>>>>>>Bonjour,
> >>>>>>>
> >>>>>>>les URL fonctionnent maintenant avec JTSP.
> >>>>>>>
> >>>>>>>Lancez ant sans arguments dans DEVBASE, et les
> >>>>>>>             
> >>>>>>>
> >>>explications suivront
> >>>     
> >>>
> >>>>>>>En fait jsynoptic et jstdout fonctionnent, mais seul
> >>>>>>>             
> >>>>>>>
> >>>jstdout utilise
> >>>     
> >>>
> >>>>>>>réellement les URL. jsynoptic continue de séparer les valeurs
> >>>>>>>dans son GUI.
> >>>>>>>Je n'ai pas regardé en détail comment était fait jsynoptic,
> >>>>>>>mais si le code
> >>>>>>>du GUI est dans le plugin, ai - je l'autorisation de modifier
> >>>>>>>le GUI pour
> >>>>>>>faire saisir une URL, et non plus des valeurs éclatée ? (je
> >>>>>>>ne sais pas si
> >>>>>>>c'est possible en fait, je ne sais pas comment est
> découpé le code
> >>>>>>>jsynoptic-plugin et jsynoptic-code)
> >>>>>>>
> >>>>>>>Sinon, en fait, sans vouloir cafter, j'ai même l'impression
> >>>>>>>que les URL
> >>>>>>>fonctionnent maintenant mieux avec JTSP qu'avec TSP, vu
> >>>>>>>             
> >>>>>>>
> >>>qu'on dirait
> >>>     
> >>>
> >>>>>>>bien que le grand frêre C ne tient pas compte du
> >>>>>>>             
> >>>>>>>
> >>>SERVERNAME pour la
> >>>     
> >>>
> >>>>>>>recherche
> >>>>>>>du provider...
> >>>>>>>
> >>>>>>>J'dis ça, j'dis rien  ;)
> >>>>>>>
> >>>>>>>Steph.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>Tsp-devel mailing list
> >>>>>>>address@hidden
> >>>>>>>http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >>>>>>> 
> >>>>>>>
> >>>>>>>------------------------------------------------------------
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>------------
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>>---------------------------------------------------------
> >>>>>>>
> >>>>>>>CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS
> >>>>>ASTRIUM SAS, NI SES FILIALES.
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>>SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI
> >>>>>FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION.
> >>>>>SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE
> >>>>>DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE
> >>>>>DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A
> >>>>>UNE TIERCE PARTIE.
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>>This email is for information only and will not bind EADS
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>Astrium SAS in any contract or obligation, nor its subsidiaries.
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>>If you have received it in error, please notify the sender
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>by return email. If you are not the addressee of this email,
> >>>>>you must not use, keep, disseminate, copy, print or otherwise
> >>>>>deal with it.
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
> >>>>>>>---------------------------------------------------------
> >>>>>>> 
> >>>>>>>
> >>>>>>>      
> >>>>>>>
> >>>>>>>             
> >>>>>>>
> >>>>>------------------------------------------------------------
> >>>>>         
> >>>>>
> >>>------------
> >>>     
> >>>
> >>>>>---------------------------------------------------------
> >>>>>
> >>>>>CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF
> >>>>>         
> >>>>>
> >>>ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS
> >>>ASTRIUM SAS, NI SES FILIALES.
> >>>     
> >>>
> >>>>>SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL
> >>>>>         
> >>>>>
> >>>DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI
> >>>FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION.
> >>>SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE
> >>>DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE
> >>>DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A
> >>>UNE TIERCE PARTIE.
> >>>     
> >>>
> >>>>>
> >>>>>This email is for information only and will not bind EADS
> >>>>>         
> >>>>>
> >>>Astrium SAS in any contract or obligation, nor its subsidiaries.
> >>>     
> >>>
> >>>>>If you have received it in error, please notify the sender
> >>>>>         
> >>>>>
> >>>by return email. If you are not the addressee of this email,
> >>>you must not use, keep, disseminate, copy, print or otherwise
> >>>deal with it.
> >>>     
> >>>
> >>>>>---------------------------------------------------------
> >>>>>  
> >>>>>
> >>>>>         
> >>>>>
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>