tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tsp-devel] RE: TSP OnLine


From: DUFRENNE, Yves
Subject: [Tsp-devel] RE: TSP OnLine
Date: Thu, 11 Dec 2003 17:11:53 +0100

Je ne sais pas si Savannah est online, mais il faudrait garder une trace de
ces messages sur la liste de diff.
Y++

> -----Original Message-----
> From: Stephane Galles [mailto:address@hidden
> Sent: Thursday, December 11, 2003 12:21 AM
> To: DUFRENNE, Yves
> Cc: GARAY Stephane; Eric NOULARD; PAGNOT Robert
> Subject: Re: TSP OnLine
> 
> 
> >
> > JE veux simplifier le plot de tsp_gdisp paskeu
> >     1) il est dur à lire et à maintenir
> >     2) il est trop complexe pour ce qu'il fait.
> >     3) Je suis convaincu que tout code qui a était trop 
> torturé entre 
> > spec et fin de codage a besoin d'un "re-thinking" comme disait un 
> > copain à moi, et être rapidement recodé avec une bonne structure.
> 
> 
> Ha, OK. Je suis absolument d'accord avec ces trois points. En fait je 
> pensais que tu voulais enlever
> toutes ces magnifique optimisation qui nous permettrons d'avoir notre 
> mur d'image de courbes
> En fait tu voulais simplement faire du REFACTORING pour utiliser le 
> terme qui va bien.
> Au fait j'ai trouvé le matos pour la prochaine démo (j'avais 
> vu ca sur 
> slashdot y'a un
> moment) : 
> http://www.9xmedia.com/pages-Build_a_system/X-Top_Expert---5_o
> ver_5.html
> 
> > Même si tu veux, je le ferais moi l'écriture du draw 2D y=f(t).
> > Tu pourrais peut-être regarder le coups du callback, et 
> voir même les 
> > types complexes (<> de double) dans TSP core ? A toi de 
> voir ce que tu 
> > as comme temps & envies.
> 
> - Pour les callback, je peux vous faire ca assez vite je pense (je ne 
> m'avance pas trop...)
> - Qui fait le refactoring de la l'affichage des courbes de 
> gdisp ? moi 
> j'imagine ?
> - Qui l'intégration dans gdips++ de ce qui a été refactoré ? Steph ?
> - Pour les types <> doubles, hum, je peux m'en occuper, mais 
> on va avoir 
> quelques échanges de mail,
> parceque je crois qu'au niveau specs ce que vous voulier était assez 
> flou. Et plus on en discutait,
> moins on voyait ce qu'il fallait faire parceque rien ne 
> semblait convenir.
> 
> Donc, va falloir brainstormer un petit peu avant. je commence :
> 
> Si je me souviens bien, on était resté sur le fait de créer 
> en plus des 
> DOUBLES et des STRINGS
> n type USER (USER_1, USER_2, etc...) opaques que seul le 
> provider et le 
> consumer du même métier sont
> capable d'encoder/décoder.
> 
> Questions :
> - Quelle doit être la longeur de ces types opaques (32 ? 64 ? on gère 
> deux classes de types ?)
> - Doit-on gérer vraiment gérer les indiens de ces types? Je 
> m'explique :
> si la spec du type opaque USER_1 (de 32 bits disons) d'un banc de
> test dit que le mot de poids fort est la température, et 
> celui de poids 
> faible la pression,
> il n'y a pas intéret à avoir chatouillé les indiens entre le 
> consumer et 
> le provider,
> car le consumer specialisé va décoder USER_1 selon la spec, 
> quelque soit 
> l'indianité des plateformes
> consumer et provider. De toute manière on voit bien que notre 
> consumer 
> spécialisé et lié à ce banc
> de test et connait son indianité pour pouvoir décoder correctement la 
> pression et le température
> qui sont sur 16 bits.
> 
> Hum... je vous laisse méditer la dessus.
> 
> Je doit aller poser des pièges à castor.
> 
> 
> >
> >  
> >  
> >  
> > -----Original Message-----
> > *From:* GARAY Stephane [mailto:address@hidden
> > *Sent:* Tuesday, December 09, 2003 12:54 PM
> > *To:* DUFRENNE, Yves
> > *Subject:* RE: Question Linux
> >
> > Je souhaite continuer.
> > Je te promets un résultat à la rentrée. Je me mets des 
> jalons, comme 
> > la pièce à musique...
> > Peux-tu voir l'histoire du callback sans argument utilisateur ?
> >
> >     -----Message d'origine-----
> >     *De:* DUFRENNE, Yves [mailto:address@hidden
> >     *Date:* mardi 9 décembre 2003 12:12
> >     *À:* GARAY Stephane
> >     *Objet:* RE: Question Linux
> >
> >      
> >     Tout est dans le chapitre 2.
> >     Si tu veux des explications, téléphone.
> >     Et pour tsp_gdisp++ mergé avec tsp_gdisp, c'est koa ta position
> >     (mail d'hier)
> >     Y++
> >
> >         -----Original Message-----
> >         *From:* GARAY Stephane [mailto:address@hidden
> >         *Sent:* Tuesday, December 09, 2003 11:22 AM
> >         *To:* DUFRENNE, Yves
> >         *Subject:* Question Linux
> >
> >
> >         J'ai une application qui est en attente de 
> réception d'une IT
> >         RTC.
> >         Lorsque l'IT est reçue, l'application écrit sur un port
> >         prédéfini et déclenche
> >         alors l'appel à la fonction* schedule* pour que d'autres
> >         applis (en attente sur
> >         un* select*) soient réveillées.
> >
> >         Peux-tu me briefer en quelques lignes sur la fonction*
> >         schedule* du scheduler Linux ?
> >
> >         S++
> >
> >         *------------------------------------------------------*
> >         *Stéphane GARAY*
> >         Avionics & Simulation products
> >         *Airbus France - EYYSIDM - B0202*
> >         +33 5 61 93 92 03* (53 92 03)*
> >         /address@hidden/
> >         *------------------------------------------------------*
> >
> >
> >-------------------------------------------------------------
> -----------
> >
> >---------------------------------------------------------
> >
> >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.
> >
> >---------------------------------------------------------
> >  
> >
> 

Attachment: important_notice.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]