[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tsp-devel] Gdisp+
|
From: |
NOULARD Eric |
|
Subject: |
Re: [Tsp-devel] Gdisp+ |
|
Date: |
Wed, 17 Nov 2004 22:37:15 +0100 |
Le gdisp+ nouveau est bien meilleur
il lui reste au moins un souci
c'est que le 'rescaling' n'a pas lieu
quand on redimmensionne la fenetre :((
Genre bouton maximize ou redimensionnement manuel.
Mais c'est déjà nettement mieux.
Merci au codeurs fous////
Eric
Le mar 16/11/2004 à 18:09, TSP a écrit :
> Euh je ne sais pas.
> J'ai updaté mais modif sur SUN, fais make clean make complet, et c'est
> OK pour le D&D.
> Mais je jure de n'avoir touche que le plot2D (qui ne sait meme pas
> qu'il existe un X ou Y ajouté au curseur) et le .h du kernel pour
> passer la fenetre gdisp de 60s à 100s.
> A suivre pour voir si le bug ne remontre pas le bout de son nez.
>
> Pour le (0,0) Stéphane pense savoir ou il est le bug, et pouvoir
> corriger bientot.
> Y++
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> Sent: Tuesday, November 16, 2004 12:04 PM
> To: address@hidden; address@hidden
> Subject: RE : [Tsp-devel] URL + Gdisp+
>
>
>
>
> 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 = OK
> >
> >
> > 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 = OK
> > >>>
> > >>>
> > >>>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 = OK
> > >>>>>
> > >>>>>
> > >>>>>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 = OK
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>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
> >
>
>
>
>
>
> ______________________________________________________________________
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
--
Eric NOULARD
E-mail: address@hidden