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
>