Re: [Tsp-devel] Heu...bonjour, j'ai vu de la lumière...

[NOULARD Eric]

Le dim 19/09/2004 à 00:10, Stephane Galles a écrit :
> OK, ce que tu me proposes m'intéresse beaucoup (exceptions,
> ringbuf, etc...).
> 
> Cela me ferait vraiment plaisir de pouvoir vous donner un coup
> de main là dessus, mais n'hésite pas à me dire ce qui est TRES urgent
> afin que je ne ralentisse pas quelque chose sur lequel tu préfèrerais
> mettre ton effort plus rapidement que moi.

Clairement je n'aurais pas le temps de m'attaquer à la partie
Java rapidement, je suis sur du C pour quelques semaines.
Si je m'apprête à passer sur la partie Java je te le dirais et
on fera le point.

> 
> On va dire que : je travaille sur les choses les plus urgentes tant que
> quelqu'un qui serait plus à temps plein que moi n'est pas disponible.
> Autrement dit, même si je suis en train de travailler sur quelquechose,
> si je ne vais pas assez vite, je peux passer la main.

Ok ça marche ne te préoccupes pas trop de la vitesssssssssssse
(sauf celle d'exécution du code comme d'hab :))

> 
> Ceci étant dit,  tout de suite, une petite question :
> 
> Pourquoi veut - on rester en JDK 1.3 ?

Ben parce que avec Java comme avec le reste pas de mal de système
en prod ne change pas [trop|assez] vite de version.
> 
> Je ne pousserais pas du tout pour passer au 1.4 mais je ne comprend
> pas vraiment la raison technique.
> 
> Le JDK 1.4 est maintenant trés stable, et il ammene beaucoup de
> chose en terme de perf et api depuis le JDK 1.3 (Dailleur le JDK 1.5
> va bientot sortir...une affaire de semaines ou de qqu mois).
> 
> Mais bon, j'imagine que pour des problèmes de certification en interne
> les gens veulent rester en 1.2/1.3, j'imagine que c'est cela la raison.
> 
> Dans la mesure où on peut vivre sans les exceptions chaining
> (JDK 1.4), je ne voie en effet pas pour le moment de justification forte
> pour dire qu'on doit passer au 1.4.
> 
> Si on reste en 1.3 il faudra sans doute implémenter notre propre chainage,
> mais qui ne sera plus  standard, ce qui posera quand même un problème
> aux gens qui vont utiliser l'API de TSP en chainant les exceptions façon 1.4
> au dessus d'API. La parade serait alors de proposer un Wrapper pour
> l'API dans un .jar à part pour les gens qui utilisent le JDK 1.4, afin de
> transformer notre chainage maison 1.3 en chainage standard 1.4
> 
> C'est toi qui vois, je peux m'occuper de faire les chainage + le wrapper.
> De toute manière, avant le 1.4 il fallait le faire à la main. Cela nous 
> permettra
> de garder la compatiblité 1.3 le plus longtemps possible.

Personnellement vue la sortie effectivement imminente du jdk 1.5 
je ne vois pas de raison de garder la compatibilité JdK 1.3
[l'expérience veut que + de  2 versions d'écarts c'est de l'obsolescence
 dangereuse]
J'en appelle aux utilisateurs "réels" afin qu'ils donnent leur
avis (Yves, Robert,...)

Il faut garder la compatibilité avec jsynoptic,
le plugins TSP pour jsynoptic est important à maintenir
(voir à remanier suivant l'état du code que je connais mal).
En tout cas la synergie avec jsynoptic ou tout autre outils
qui donne une face "visible" à TSP est primordiale.


Perso je vote JdK 1.4 avec exception chaining standard
+ MAJ plugins jsynoptic pour qu'il exploite correctement
les nouvelles exceptions.


Par contre j'ai oublié de dire que j'étais pour la
description ANT qui va bien pour la compilation de la partie Java
on maintient les Makefile un petit peu [pour Java]
pour voir l'adoption de ANT.


> 
> En fait je vais même aller plus loing. Si pour toi la compatibilité 1.2/1.3
> est capitale, et si on voit queles NIO sont intéressants, je veux bien 
> me charger
> de tenter de rendre plugable l'API Socket utilisés avant de faire une 
> implémentation
> NIO. Mais bon, cela pourrait être pour le futur. Pour le court terme 
> géront les
> exceptions !

Ok pour voir NIO dans un second temps.

> 
> A+
> Steph (qui va donner des nouvelles plus souvent !)

Bah je sais plus quel décalage horaire on a mais chez moi
il est bientôt 1h du mat' alors dodo.

A+

> 
> 
> 
> NOULARD Eric wrote:
> 
> >Le sam 18/09/2004 à 22:04, Stephane Galles a écrit :
> >  
> >
> >><delire>
> >>Heu...J'ai vu de la lumière alors je me suis dit que j'allais passer...
> >>
> >>...Quelle activité ici !
> >>
> >>Quand je me rend compte que j'ai connu le TSP quand il était tout petit,
> >>tout mal foutu, avec des monceaux de datapool, de vilains types
> >>qui commencent par des g_, et je ne parle pas même pas du Glu qui
> >> subit du pull, en lieu et place du push...
> >>
> >>Je me sens tout chose, tiens... Un jour ca se met à parler (ho ! juste
> >>quelques symboles au début... quelques Hz, a peine, même pas
> >>déphasés), et puis plusieurs mois aprés ça se te demande les clés de
> >>la voiture pour aller au Macumba Dazzling Joe Club avec une
> >>bande de tepos.
> >>
> >>(soupir)
> >>
> >>L'emotion m'étrain
> >>
> >>(soupir encore)
> >></delire>
> >>    
> >>
> >
> >Quel poét' notre Caribou.
> >Je me mets parfois à délirer de faire de TSP un projet
> >visible par sa simplicité et invisible tellement la perfo
> >déchire même pas quelques Flops...
> >
> >  
> >
> >><serieux>
> >>Bon, je pensais me remettre tout doucement au TSP (j'avais décroché et
> >>pour éviter le choc anaphylactique, faut y'aller tout doux), et donc je
> >>cherchais des petites piste, pas trop grosses, utiles pour vous, mais qui
> >>ne soient pas sur le chemin critique pour vous, afin que je puisse aller
> >>à mon rythme qui n'est pas trés élevé somme toute.
> >>
> >>Bon genre, on avait parlé de cela :
> >>
> >>- Replace all the 'typedef void*' object encapsulation trick by             
> >>@Caribou
> >>  a 'typedef struct TSP_mystruct_t TSP_mystruct_t' that hides
> >>  the internal struct too, but does not hide it when we try
> >>  to debug (the 'void*' stuff to hide the object was not a good
> >>  idea at all)
> >>
> >>Cela serait dans l'ordre des choses que je corrige ce truc, vu
> >>que c'est moi qui avait eu cette idée à la c... à l'époque. C'est toujours
> >>d'actualité ?
> >>    
> >>
> >
> >Pour l'instant ça m'a pas gêné car honnêtement j'ai [très] peu débuggué 
> >le TSP tellement y'a pas de bug :))
> >Sans rire c'est pas très haut sur ma liste.
> >
> >  
> >
> >>Sinon, autre question : le client Java intéresse t'il encore quelqu'un ?
> >>    
> >>
> >
> >Yes very beaucoup car mon client actuel aimerait bien ré-utiliser un tas
> >de belles IHMs en Java et parler au beaux bancs de test et produit qui
> >grace à nos efforts conjugués parle désormais TSP.
> >
> >  
> >
> >>Si oui, est ce que tu y travaille encore Eric ? 
> >>    
> >>
> >
> >En fait non, par manque de temps.
> >Je fais du TSP à fond mais en C :))
> >
> >
> >  
> >
> >>Parceque j'ai vu des choses
> >>dans le todo avec lesquelles j'irai bien jouer.
> >>    
> >>
> >
> >En java? 
> >Lesquelles.
> >
> >Mes souhaits pour la partie Java serait:
> >
> >1) remettre les exceptions d'équerre comme tu l'avais décrit
> >   et que j'ai pas eu le temps de faire
> >2) Réaliser un vrai ringbuffer et pas la cochonnerie sans limitation
> >   mémoire que j'avais pondu.
> >3) Tester effectivement les NIO (dans mon souvenir j'avais regardé
> >   mais j'avais préféré rester sur les socket tradi pour rester
> >   compatible jdk1.2 ET jdk1.3
> >4) Tester un autre lien de commande genre XML-RPC une fois
> >   qu'il est présent dans la libc provider...
> >
> >  
> >
> >>De plus veut on encore virer les Makefiles au profit de certains
> >>arthropodes ? Faut il faire évoluer ce client dans le futur pour suivre
> >>des éventuelles évolutions sur l'API publique ?
> >>Je n'ai par regardé le type de socket que tu avait utilisé, mais je
> >>commence à m'intéresser au package NIO (I\O hautes performances)
> >>et je me ne dis que cela pourrait ammener des choses.
> >>    
> >>
> >
> >Mais bon c'est comme d'hab, le mieux c'est de s'amuser
> >donc fait ce qu'il te plait.
> >
> >En revanche si tu pètes la compatibilité jdk1.2 voire jdk1.3 
> >expliques pourquoi.
> >
> >  
> >
> >>Voila, voila...
> >></serieux>
> >>    
> >>
> >
> >Sinon très heureux d'avoir de tes nouvelles.
> >A+
> >Eric
> >  
> >
> >>
> >>
> >>_______________________________________________
> >>Tsp-devel mailing list
> >>address@hidden
> >>http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >>    
> >>
-- 
Eric NOULARD
E-mail: address@hidden