[Top][All Lists]
[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.
> >
> >---------------------------------------------------------
> >
> >
>
important_notice.txt
Description: Text document
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Tsp-devel] RE: TSP OnLine,
DUFRENNE, Yves <=