oct-general Mailing List for OcT (Ocaml Timetable)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hey friend, 

I've just seeen  something  very nice, it's so exciting,  you  have to take  a look <http://behumila.unabashedmedia.com/e6fsi>

Take care, YOY...@or...

Bonjour,

Je viens de  trouver de  nouvelles méthodes pour résoudre le problème que  vous faites  face, lire plus ici <http://proposal.compagniedassurance.com/xotrjef>

yoyo

Hey,

Ce truc est vraiment fou, vous devez surement le voir, jetez juste un coup d'œil ici <http://nguthingopre.collegefgl.com/xoephgvu>

Je t'embrasse, yoy...@or...
<b><span style="font-size: 20pt;">
<a  alt="2ja28gixy6bwwyf0y1l
jidc047wvnayk7fdyqqe
wgawkm9a8aepgq4y9jah"
id="kz591ugpta8de7r4ud4
70ygfuenu23odk7ol3cj"
href="twj7eb5sg3i54x.v9n.me/sc_...@li.../eexb
mkkbhr5vjnaankreta_ViewMsg" >
Click here to see the attached video</a>

Bonjour à tous,

Je tiens à prévenir que je viens d'effectuer une grosse copie de nos
traveaux dans le tronc commun.

Les versions améliorées du moteur de grisement et de l'exportation XHTML
sont désormais ajoutés à trunk

En espérant ne pas avoir fait de connerie en remplaçant les fichiers.

Cordialment,

-- 
Anthony LY

Bonjour,

Les soutenance de 2e session devraient avoir lieu le 26 juin. Dites moi si ça 
vous convient sinon on peut décaler. Pour les gens concernés, pouvez-vous me 
confirmer que la date vous convient (et que vous avez reçu ce mail vu que la 
dernière fois il est arrivé un peu aléatoirement...) ?

Cordialement,
Vincent Balat

Bonjour a tous, 
je viens de poster un nouveau Makefile

la liste des changements:
    - reecriture des regles
    - la 1ere regle a pour nom celui du programme (regle par defaut)
    - la regle xhtml est exclue de la 1ere regle
    - possibilité de compiler juste la partie sur laquelle en travail (base/moteur/gui)
    - par default make n'affiche plus rien a l'ecran - sauf pour le cas de xhtml
    - netoyage de xhtml passe de clean a clean_deep

premiere utilisation:
    - si update d'une ancienne version, ex apres un svn up > 669,  faire  "make clean_deep; make all"
    - si premiere utilisation, ex apres un svn co, faier "make all"

utilisation:
    - la regle par defaut est le nom du programme, par defaut "oct"
      donc "make" = "make oct"
    - pour une compilation partielle faire "make" + la partie concernée [lexer, parser, base, moteur, gui]
    - pour afficher les commandes faire "make show" + la regle,  ex: "make show oct"
    - en cas de probleme de compilation faire dabord un "make clean_deep"

voila a+

      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
C'est bon, j'ai modifié le fichier vue.ml. Il n'utilise plus la fonction
liste_salle.

Le 25 mai 2008 20:44, Anthony LY <ly....@gm...> a écrit :

> Re !
>
> Bon etant donne qu'il s'agit d'un probleme d'argument, j'ai essaye de
> modifier le moteur en consequence. Il y a aussi un soucis avec la valeur de
> retour.
>
> Utilisee dans vue.ml, il faut une liste de OCTsyntax.salle mais la
> fonction d'origine retourne une liste d'ensemble de label (string)
> En particulier : le nom, le type et le label "salle"
>
> A la base, ca a l'air d'etre fait pour la gestion interne du moteur.
> J'aurai besoin de savoir qu'est ce qu'il faut exactement au niveau de la
> vue, pour savoir si je cree une fonction qui renvoi effectivement la liste
> des salles (OCTsyntax.salle list) ou si je peux filtrer directement les
> informations souhaitees.
>
> Cordialement,
>
> Anthony.
>
> Le 25 mai 2008 17:05, Anthony LY <ly....@gm...> a écrit :
>
> Salut,
>>
>> Ce mail s'adresse surtout à ceux qui gère la GUI :
>>
>> On s'est apperçu d'une mauvaise utilisation de la fonction list_salle du
>> moteur dans le fichier vue.ml (ligne 68)
>> Cela vient d'une erreur de notre part lorsque nous avont modifié le
>> fichier moteur.mli dans trunk.
>> N'ayant pas vu que cette fonction était utilisée dans vue.ml, nous
>> l'avons effacé du mli donc le compilateur ne renvoi aucune erreur.
>>
>> Dans branch, nous avons l'ancienne version du moteur.mli et là le
>> compilateur rale à cause d'un mauvais typage. (alors qu'il s'agit de la même
>> fonction)
>>
>> File "gui/vue.ml", line 68, characters 34-37:
>> This expression has type OCTsyntax.planning but is here used with type
>>   OCTsyntax.pla list
>>
>> Après vérification, c'est bien un OCTsyntax.pla list qu'attend la fonction
>> list_salle
>>
>> On n'a pas encore remodifié le fichier moteur.mli présent dans trunc
>> histoire que ça ne fasse pas foirer la compilation globale.
>>
>> Tennez nous au couant, si vous pensez avoir trouvé comment modifier
>> vue.ml
>>
>> Désolé pour l'annonce tardive.
>> --
>> Anthony LY
>
>
>
>
> --
> Anthony LY
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Oct-general mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/oct-general
>
>

Re !

Bon etant donne qu'il s'agit d'un probleme d'argument, j'ai essaye de
modifier le moteur en consequence. Il y a aussi un soucis avec la valeur de
retour.

Utilisee dans vue.ml, il faut une liste de OCTsyntax.salle mais la fonction
d'origine retourne une liste d'ensemble de label (string)
En particulier : le nom, le type et le label "salle"

A la base, ca a l'air d'etre fait pour la gestion interne du moteur.
J'aurai besoin de savoir qu'est ce qu'il faut exactement au niveau de la
vue, pour savoir si je cree une fonction qui renvoi effectivement la liste
des salles (OCTsyntax.salle list) ou si je peux filtrer directement les
informations souhaitees.

Cordialement,

Anthony.

Le 25 mai 2008 17:05, Anthony LY <ly....@gm...> a écrit :

> Salut,
>
> Ce mail s'adresse surtout à ceux qui gère la GUI :
>
> On s'est apperçu d'une mauvaise utilisation de la fonction list_salle du
> moteur dans le fichier vue.ml (ligne 68)
> Cela vient d'une erreur de notre part lorsque nous avont modifié le fichier
> moteur.mli dans trunk.
> N'ayant pas vu que cette fonction était utilisée dans vue.ml, nous l'avons
> effacé du mli donc le compilateur ne renvoi aucune erreur.
>
> Dans branch, nous avons l'ancienne version du moteur.mli et là le
> compilateur rale à cause d'un mauvais typage. (alors qu'il s'agit de la même
> fonction)
>
> File "gui/vue.ml", line 68, characters 34-37:
> This expression has type OCTsyntax.planning but is here used with type
>   OCTsyntax.pla list
>
> Après vérification, c'est bien un OCTsyntax.pla list qu'attend la fonction
> list_salle
>
> On n'a pas encore remodifié le fichier moteur.mli présent dans trunc
> histoire que ça ne fasse pas foirer la compilation globale.
>
> Tennez nous au couant, si vous pensez avoir trouvé comment modifier vue.ml
>
> Désolé pour l'annonce tardive.
> --
> Anthony LY

-- 
Anthony LY

Salut,

Ce mail s'adresse surtout à ceux qui gère la GUI :

On s'est apperçu d'une mauvaise utilisation de la fonction list_salle du
moteur dans le fichier vue.ml (ligne 68)
Cela vient d'une erreur de notre part lorsque nous avont modifié le fichier
moteur.mli dans trunk.
N'ayant pas vu que cette fonction était utilisée dans vue.ml, nous l'avons
effacé du mli donc le compilateur ne renvoi aucune erreur.

Dans branch, nous avons l'ancienne version du moteur.mli et là le
compilateur rale à cause d'un mauvais typage. (alors qu'il s'agit de la même
fonction)

File "gui/vue.ml", line 68, characters 34-37:
This expression has type OCTsyntax.planning but is here used with type
  OCTsyntax.pla list

Après vérification, c'est bien un OCTsyntax.pla list qu'attend la fonction
list_salle

On n'a pas encore remodifié le fichier moteur.mli présent dans trunc
histoire que ça ne fasse pas foirer la compilation globale.

Tennez nous au couant, si vous pensez avoir trouvé comment modifier vue.ml

Désolé pour l'annonce tardive.
-- 
Anthony LY

Bonjour à tous,

J'espère que le travail sur Oct progresse bien. Je suis un peu surpris de ne 
voir aucun trafic sur cette liste... Nous serons plus exigeants lors de cette 
deuxième soutenance donc il faut que vous ayiez du contenu à présenter. 
Est-ce que vous avez une version utilisable et ergonomique de l'interface gtk 
par exemple ? Pensez à prévoir plusieurs jours pour le débogage et les 
dernières améliorations.

Je vous rappelle que nous avons fixé la date du mercredi 28 pour les 
soutenances. Pour simplifier je fixe des horaires, s'ils ne vous conviennent 
pas, échanger entre vous. Il n'est pas possible de retarder la soutenance à 
cause du jury de M1.

 - 10h00 Baptiste Stéphane
 - 10h30 Adrien Martin
 - 11h00 Hervé Anthony
 - 11h30 Riad Mohamed

La soutenance aura lieu devant Daniele Varacca, Giulio Manzonetto et moi-même. 
Donc préparez un petit exposé (15 min) du projet et de votre travail pour des 
personnes qui ne le connaissent pas, avec une démonstration.

Je vous demande d'écrire un court rapport détaillant précisément votre 
contribution individuellement (qui a fait quoi, de manière très détaillée).

Si vous avez des difficultés pour avancer, n'hésitez pas à écrire sur la liste 
ou à moi même ou même prendre rdv avec moi. Ne restez pas bloqués.

À mercredi,
Vincent Balat

L'erreur vient d'une modification faite dans le fichier utils.ml (j'ai
rajouté un champs "salle" dans le type config, ça me permet de savoir
rapidement si une salle a déjà été définie pour le cours sur lequel on
clique). Copie le dans ton répertoire, ça devrais compiler.

2008/4/15, Anthony LY <ly....@gm...>:
>
> Salut à tous !
>
> Avec Hervé, on pense avoir fini la fonction de grisaillement. Cependant
> après un make clean, la GUI propose une nouvelle fois une erreur :
>
> ocamlc -c -I BASE/ -I GUI/ -I MOTEUR/ -I `ocamlfind query lablgtk2`
> moteur.cmo GUI/utils.cmo GUI/tree.cmo GUI/vue.ml
> File "GUI/vue.ml", line 731, characters 48-60:
> Unbound record field label salle
> make: *** [all] Erreur 2
> [4]+  Done                    emacs GUI/vue.ml
>
> J'ai copié via svn les derniers fichiers de trunk vers notre répertoire
> de travail sous branche.
> Par contre, on utilise encore l'ancien Makefile et la casse majuscule,
> vu que le nouveau Makefile n'a pas l'air fini.
>
> Voilà, on comprend pas grand chose à la GUI, ça concerne un certain
> "config.salle" mais on ne voit pas à quoi cela correspond.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Oct-general mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/oct-general
>

Salut à tous !

Avec Hervé, on pense avoir fini la fonction de grisaillement. Cependant 
après un make clean, la GUI propose une nouvelle fois une erreur :

ocamlc -c -I BASE/ -I GUI/ -I MOTEUR/ -I `ocamlfind query lablgtk2`  
moteur.cmo GUI/utils.cmo GUI/tree.cmo GUI/vue.ml
File "GUI/vue.ml", line 731, characters 48-60:
Unbound record field label salle
make: *** [all] Erreur 2
[4]+  Done                    emacs GUI/vue.ml

J'ai copié via svn les derniers fichiers de trunk vers notre répertoire 
de travail sous branche.
Par contre, on utilise encore l'ancien Makefile et la casse majuscule, 
vu que le nouveau Makefile n'a pas l'air fini.

Voilà, on comprend pas grand chose à la GUI, ça concerne un certain 
"config.salle" mais on ne voit pas à quoi cela correspond.

Aucun proble`me de mon co^te', je viendrai pour midi.

A mercredi,

Anthony

Bonjour à tous,

Mercredi après-midi je ne pourrai pas être là à 14h30 à cause d'une réunion de 
la commission de spécialistes. Je vous propose de nous retrouver vers midi 
devant la salle T. Est-ce que cela vous convient ? Si vous avez cours vous 
pouvez venir un peu plus tard mais j'aimerais bien vous voir tous avant les 
vacances.

Cordialement,

Vincent Balat

" jepense que c'est parti justement d'un manque de communication mais 
quedans ce cas pr?cis ce manque ne vient pas de moi. "

On est bien d'accord, d'ailleurs je n'ai jamais pense' ou voulu faire 
croire que cela venait de toi, sinon je t'aurai contacte' directement et 
non via la mailing.

Bonjour,

Je pense que l'incident est clos, et je ne souhaite plus voir ce genre de 
messages sur la liste, merci. Le courrier électronique n'est pas un bon moyen 
de discussion, il est trop facile de créer des malentendus. D'autre part 
n'oubliez pas que cette mailing list est publique :
http://sourceforge.net/mailarchive/forum.php?forum_name=oct-general

Pour revenir à l'important : est-ce que vous avez trouvé la bonne solution au 
problème ?

Vincent Balat

Le Sunday 13 April 2008 02:43:24 Riad KRIM, vous avez écrit :
> Salut,
>
> - "Travailler en Equipe" pour moi c'est justementpermettre au autres de
> pouvoir "Travailler" (dans ce cas "compiler"),et non pas d'en exclure qq
> uns.
>
> - je te signal qu'aux dernièresnouvelles moi aussi je travail sur
> l'interface, et qu'on est 4, donc sil'un des 4 fait un commit ca force
> obligatoirement les autres "areadapter leur modifications en cours  (non
> synchronise' sur svn)".
>
> -je n'ai mis personne sur le fait accompli, car le révision 635 dufichier
> interface.ml n'est pas un retour vers 604, mais comme je l'aideja dis c'est
> juste la fonction qui a été corrigée, alors la personnequi a ete mise sur
> le fait accompli c'est moi; c'est moi qui me suisretrouvé d'une révision a
> l'autre avec l'impossibilité de compiler.
>
> -oui ton message m'a vexé, et j'accepte t'es excuses, comme tu dis ,
> jepense que c'est parti justement d'un manque de communication mais quedans
> ce cas précis ce manque ne vient pas de moi.
>
>
> voila bonne journée
>
>
> ----------------------------------------------------------------------
>
> Date: Fri, 11 Apr 2008 21:47:45 +0200
> From: Anthony LY <ly....@gm...>
> Subject: Re: [Oct-general] Oct-general Digest, Vol 8, Issue 6
> To: oct...@li...
> Message-ID: <47F...@gm...>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Salut,
>
> on nous bassine pour la compatibilite, certes, mais on nous bassine
> aussi pour le travail d'e'quipe.
>
> Je n'avais pas lu ce commentaire de Vicent Balat car comme je l'ai dis
> le fichier interface.ml ne me concerne pas. Mais ce qui me ge`ne c'est
> le fait de prendre l'initiative de modifier un fichier sur lequels
> d'autres sont entraint de bosser et de le synchroniser en mettant ces
> personnes sur le fait accompli.
>
> A moins que tu en ai parle' avec Baptiste et Ste'phane avant, auquel cas
> je te pre'sente mes excuses de mes insinuations publiques, mais cela n'a
> pas l'air d'e^tre le cas au vu de ton "de'sole' pour le retour en
> arrie`re". Dans le cas contraire, c,a les force a` re'adapter leur
> modifications en cours (non synchronise' sur svn).
>
> Si mon message t'a vexe', j'en suis since`rement de'sole'. Ok c,a
> concerne une ligne, j'ai exage'ge' lors de mon dernier mail. Mais un peu
> plus de comminucation au lieu de mettre les gens sur le fait accompli ce
> serait mieux je pense.
> La dernie`re fois qu'il y a eu ce genre de modif sur le moteur sans
> pre'avis, on a eu de la chance que ni Herve', ni moi ne travaillions
> dans le re'pertoire trunk a` l'e'poque.
>
>
>
>
>
>
>
>      
> ___________________________________________________________________________
>__ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente
> http://mail.yahoo.fr

Salut,

- "Travailler en Equipe" pour moi c'est justementpermettre au autres de pouvoir "Travailler" (dans ce cas "compiler"),et non pas d'en exclure qq uns.

- je te signal qu'aux dernièresnouvelles moi aussi je travail sur l'interface, et qu'on est 4, donc sil'un des 4 fait un commit ca force obligatoirement les autres "areadapter leur modifications en cours  (non synchronise' sur svn)".

-je n'ai mis personne sur le fait accompli, car le révision 635 dufichier interface.ml n'est pas un retour vers 604, mais comme je l'aideja dis c'est juste la fonction qui a été corrigée, alors la personnequi a ete mise sur le fait accompli c'est moi; c'est moi qui me suisretrouvé d'une révision a l'autre avec l'impossibilité de compiler.

-oui ton message m'a vexé, et j'accepte t'es excuses, comme tu dis , jepense que c'est parti justement d'un manque de communication mais quedans ce cas précis ce manque ne vient pas de moi.

voila bonne journée

----------------------------------------------------------------------

Date: Fri, 11 Apr 2008 21:47:45 +0200
From: Anthony LY <ly....@gm...>
Subject: Re: [Oct-general] Oct-general Digest, Vol 8, Issue 6
To: oct...@li...
Message-ID: <47F...@gm...>
Content-Type: text/plain; charset=us-ascii; format=flowed

Salut,

on nous bassine pour la compatibilite, certes, mais on nous bassine 
aussi pour le travail d'e'quipe.

Je n'avais pas lu ce commentaire de Vicent Balat car comme je l'ai dis 
le fichier interface.ml ne me concerne pas. Mais ce qui me ge`ne c'est 
le fait de prendre l'initiative de modifier un fichier sur lequels 
d'autres sont entraint de bosser et de le synchroniser en mettant ces 
personnes sur le fait accompli.

A moins que tu en ai parle' avec Baptiste et Ste'phane avant, auquel cas 
je te pre'sente mes excuses de mes insinuations publiques, mais cela n'a 
pas l'air d'e^tre le cas au vu de ton "de'sole' pour le retour en 
arrie`re". Dans le cas contraire, c,a les force a` re'adapter leur 
modifications en cours (non synchronise' sur svn).

Si mon message t'a vexe', j'en suis since`rement de'sole'. Ok c,a 
concerne une ligne, j'ai exage'ge' lors de mon dernier mail. Mais un peu 
plus de comminucation au lieu de mettre les gens sur le fait accompli ce 
serait mieux je pense.
La dernie`re fois qu'il y a eu ce genre de modif sur le moteur sans 
pre'avis, on a eu de la chance que ni Herve', ni moi ne travaillions 
dans le re'pertoire trunk a` l'e'poque.

      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
Ah oui, c'est très bête ce que je propose en fait. J'ai pas l'habitude 
des table de hachage, j'ai encore un peu de mal :P
Je vais essayer d'enlever les champs, en espérant que ça n'allongera pas 
trop le temps de chargement.

Jerome VELLEINE a écrit :
>
>    
>     Le probleme avec ta modif en
>
> (int * (string * (OCTsynatx.typ_cours * OCTsynatx.pr_sal list))) Hashtbl
>
>     C'est que dans ce cas la tu va avoir enormement de doublons car 
> OCTsynatx.pr_sal caracterise entierement le prof ou la salle ou le groupe
>
>     Donc tu va repeter toutes leurs informations pour chaque typ_cours....
>
>     Imagine les repetitions....
>
>     Je ne pense pas que ca aille....
>
>     Au pire tu peux enlever les champs du typ_cours (prof et salle) si 
> ca te gene ( encore que ca peut peut-etre gener qq part..jsai pa) et 
> faire des recherches direct sur le typ pla mais la ca risque d'etre 
> long à chaque fois car il faudra tout parcourir...
>
>     Jerome
>
>
>
>     > Message du 12/04/08 15:09
>     > De : "Anthony LY"
>     > A : "Jerome VELLEINE"
>     > Copie à : "projet long oct"
>     > Objet : Re: [Oct-general] typ_cours
>     >
>     > Re,
>     >
>     > J'ai trouvé la réponse à question sur la chaine de caractère (cf
>     mon
>     > autre message ci-dessous)
>     >
>     > J'aimerais avoir vos avis sur une éventuelle petite modification
>     de la
>     > table en
>     >
>     > (int * (string * (OCTsynatx.typ_cours * OCTsynatx.pr_sal list)))
>     Hashtbl
>     > id -> ref_cours -> typ_cours -> [prof, salles, groupes]
>     >
>     > Afin d'avoir un accès direct aux profs, salles et groupes
>     correspondant
>     > à chaque id par la table.
>     > ça permettrait de ne pas stoquer plusieurs fois les informations
>     dans la
>     > structure, juste des raccourcis dans la table.
>     >
>     > Mais reste à voir si :
>     > - l'efficacité de la table ne baisse pas trop (initialisation,
>     accès)
>     > - ça règle le problème ou non (fausse bonne idée powa ?)
>     >
>     > [Message que j'ai pas envoyé à la mailling, juste à Jerome, suite à
>     > une mauvaise manipulation]
>     > Re,
>     >
>     > Merci pour ces précisions.
>     > C'est bien ce qui me semblait mais je voulais une confirmation.
>     >
>     > J'en ai parlé en TP avec Vincent, qui conseille d'éviter les
>     > doublons dans la structure pour éviter d'éventuels bug de
>     > développement.
>     >
>     > Sinon, je ne sais pas exactement à quoi correspond la chaîne de
>     > caracteres dans la table de hachage.
>     > (int * (string * OCTsynatx.typ_cours)) Hashtbl
>     >
>     > Vu qu'on a un accès direct au typ_cours grace à la table, on peut en
>     > faire un vers la liste des profs, salles et groupes qui partagent le
>     > même identifiant, non ?
>     > Un truc du genre (int * (OCTsyntax.pr_sal list *
>     > OCTsyntax.typ_cours)) Hashtbl
>     > Enfin sauf si le string permet déjà de faire ça.
>     >
>     >
>     >
>     > Jerome VELLEINE a écrit :
>     > >
>     > > Salut,
>     > >
>     > > Le typ_cours de oct c'est ce qui permet de remplir la table de
>     > > hachage....
>     > >
>     > > Apres on a mis prof et sal dedans pour eviter de reparcourir tout
>     > > le pla pour chaque recherche....
>     > >
>     > > C'est champs sont donc mis a jour ds typ_cours dans la table de
>     > > hachage!!!! puis le typ_cours de oct est mis a jour lors des
>     > > enregistrement....(en fait au prochain chargement une fois
>     enregistrer)
>     > >
>     > > J'espere que ca ta eclairé...
>     > >
>     > > Bon week end a tout le monde...
>     > >
>     > >
>     > > > Message du 12/04/08 10:54
>     > > > De : "Anthony LY"
>     > > > A : oct...@li...
>     > > > Copie à :
>     > > > Objet : [Oct-general] typ_cours
>     > > >
>     > > > Bonjour,
>     > > >
>     > > > J'aurais besoin de précisions sur le typ_cours
>     > > >
>     > > > Rappel de la définition :
>     > > > ...
>     > > > and typ_cours=
>     > > > {
>     > > > id:int;
>     > > > typ:string;
>     > > > heure_total:minute;
>     > > > duree:minute;
>     > > > prof_crs:string option;(* prof *)
>     > > > salle_crs:string list;(* salle *)
>     > > > horair:creneau_periode;(* creneau horaire *)
>     > > > }
>     > > >
>     > > > and pr_sal=Prof of prof
>     > > > |Salle of salle
>     > > > |Groupe of groupe
>     > > >
>     > > > and pla=
>     > > > {
>     > > > ref_pl:pr_sal;
>     > > > descr_pl:int list
>     > > > }
>     > > > ...
>     > > >
>     > > > typ_cours.id et pla.descr_pl repésentent les identifiants dans
>     > > la table
>     > > > de hachage.
>     > > >
>     > > > Or, je ne comprends pas pourquoi, le typ_cours possède des
>     champs
>     > > > prof_crs et salle_crs alors qu'on peut retrouver ces
>     > > informations en
>     > > > fouillant dans les listes de descripteurs du type pla.
>     > > > N'est-ce pas là une duplication des données ? Ces deux champs
>     > > sont-ils
>     > > > réellement utiles ?
>     > > >
>     > > >
>     > >
>     -------------------------------------------------------------------------
>     > > > This SF.net email is sponsored by the 2008 JavaOne(SM)
>     Conference
>     > > > Don't miss this year's exciting event. There's still time to
>     > > save $100.
>     > > > Use priority code J8TL2D2.
>     > > >
>     > >
>     http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>     > > > _______________________________________________
>     > > > Oct-general mailing list
>     > > > Oct...@li...
>     > > > https://lists.sourceforge.net/lists/listinfo/oct-general
>     > > >
>     > > >
>     > >
>     >
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>     > Don't miss this year's exciting event. There's still time to
>     save $100.
>     > Use priority code J8TL2D2.
>     >
>     http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>     > _______________________________________________
>     > Oct-general mailing list
>     > Oct...@li...
>     > https://lists.sourceforge.net/lists/listinfo/oct-general
>     >
>     >
>

    Le probleme avec ta modif en
 (int * (string * (OCTsynatx.typ_cours * OCTsynatx.pr_sal list))) Hashtbl

    C'est que dans ce cas la tu va avoir enormement de doublons car OCTsynatx.pr_sal caracterise entierement le prof ou la salle ou le groupe

    Donc tu va repeter toutes leurs informations pour chaque typ_cours....

    Imagine les repetitions....

    Je ne pense pas que ca aille....

    Au pire tu peux enlever les champs du typ_cours (prof et salle) si ca te gene ( encore que ca peut peut-etre gener qq part..jsai pa) et faire des recherches direct sur le typ pla mais la ca risque d'etre long à chaque fois car il faudra tout parcourir... 

    Jerome

> Message du 12/04/08 15:09
> De : "Anthony LY" 
> A : "Jerome VELLEINE" 
> Copie à : "projet long oct" 
> Objet : Re: [Oct-general] typ_cours
> 
> Re,
> 
> J'ai trouvé la réponse à question sur la chaine de caractère (cf mon 
> autre message ci-dessous)
> 
> J'aimerais avoir vos avis sur une éventuelle petite modification de la 
> table en
> 
> (int * (string * (OCTsynatx.typ_cours * OCTsynatx.pr_sal list))) Hashtbl
>  id  -> ref_cours -> typ_cours -> [prof, salles, groupes]
> 
> Afin d'avoir un accès direct aux profs, salles et groupes correspondant 
> à chaque id par la table.
> ça permettrait de ne pas stoquer plusieurs fois les informations dans la 
> structure, juste des raccourcis dans la table.
> 
> Mais reste à voir si :
> - l'efficacité de la table ne baisse pas trop (initialisation, accès)
> - ça règle le problème ou non (fausse bonne idée powa ?)
> 
>     [Message que j'ai pas envoyé à la mailling, juste à Jerome, suite à
>     une mauvaise manipulation]
>     Re,
> 
>     Merci pour ces précisions.
>     C'est bien ce qui me semblait mais je voulais une confirmation.
> 
>     J'en ai parlé en TP avec Vincent, qui conseille d'éviter les
>     doublons dans la structure pour éviter d'éventuels bug de
>     développement.
> 
>     Sinon, je ne sais pas exactement à quoi correspond la chaîne de
>     caracteres dans la table de hachage.
>     (int * (string * OCTsynatx.typ_cours)) Hashtbl
> 
>     Vu qu'on a un accès direct au typ_cours grace à la table, on peut en
>     faire un vers la liste des profs, salles et groupes qui partagent le
>     même identifiant, non ?
>     Un truc du genre (int * (OCTsyntax.pr_sal list *
>     OCTsyntax.typ_cours)) Hashtbl
>     Enfin sauf si le string permet déjà de faire ça.
> 
> 
> 
> Jerome VELLEINE a écrit :
> >
> > Salut,
> >
> >     Le typ_cours de oct c'est ce qui permet de remplir la table de 
> > hachage....
> >
> >     Apres on a mis prof et sal dedans pour eviter de reparcourir tout 
> > le pla pour chaque recherche....
> >
> >     C'est champs sont donc mis a jour ds typ_cours dans la table de 
> > hachage!!!! puis le typ_cours de oct est mis a jour lors des 
> > enregistrement....(en fait au prochain chargement une fois enregistrer)
> >
> >     J'espere que ca ta eclairé...
> >
> >     Bon week end a tout le monde...
> >
> >
> >     > Message du 12/04/08 10:54
> >     > De : "Anthony LY"
> >     > A : oct...@li...
> >     > Copie à :
> >     > Objet : [Oct-general] typ_cours
> >     >
> >     > Bonjour,
> >     >
> >     > J'aurais besoin de précisions sur le typ_cours
> >     >
> >     > Rappel de la définition :
> >     > ...
> >     > and typ_cours=
> >     > {
> >     > id:int;
> >     > typ:string;
> >     > heure_total:minute;
> >     > duree:minute;
> >     > prof_crs:string option;(* prof *)
> >     > salle_crs:string list;(* salle *)
> >     > horair:creneau_periode;(* creneau horaire *)
> >     > }
> >     >
> >     > and pr_sal=Prof of prof
> >     > |Salle of salle
> >     > |Groupe of groupe
> >     >
> >     > and pla=
> >     > {
> >     > ref_pl:pr_sal;
> >     > descr_pl:int list
> >     > }
> >     > ...
> >     >
> >     > typ_cours.id et pla.descr_pl repésentent les identifiants dans
> >     la table
> >     > de hachage.
> >     >
> >     > Or, je ne comprends pas pourquoi, le typ_cours possède des champs
> >     > prof_crs et salle_crs alors qu'on peut retrouver ces
> >     informations en
> >     > fouillant dans les listes de descripteurs du type pla.
> >     > N'est-ce pas là une duplication des données ? Ces deux champs
> >     sont-ils
> >     > réellement utiles ?
> >     >
> >     >
> >     -------------------------------------------------------------------------
> >     > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >     > Don't miss this year's exciting event. There's still time to
> >     save $100.
> >     > Use priority code J8TL2D2.
> >     >
> >     http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >     > _______________________________________________
> >     > Oct-general mailing list
> >     > Oct...@li...
> >     > https://lists.sourceforge.net/lists/listinfo/oct-general
> >     >
> >     >
> >
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Oct-general mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/oct-general
> 
> 

Re,

J'ai trouvé la réponse à question sur la chaine de caractère (cf mon 
autre message ci-dessous)

J'aimerais avoir vos avis sur une éventuelle petite modification de la 
table en

(int * (string * (OCTsynatx.typ_cours * OCTsynatx.pr_sal list))) Hashtbl
 id  -> ref_cours -> typ_cours -> [prof, salles, groupes]

Afin d'avoir un accès direct aux profs, salles et groupes correspondant 
à chaque id par la table.
ça permettrait de ne pas stoquer plusieurs fois les informations dans la 
structure, juste des raccourcis dans la table.

Mais reste à voir si :
- l'efficacité de la table ne baisse pas trop (initialisation, accès)
- ça règle le problème ou non (fausse bonne idée powa ?)

    [Message que j'ai pas envoyé à la mailling, juste à Jerome, suite à
    une mauvaise manipulation]
    Re,

    Merci pour ces précisions.
    C'est bien ce qui me semblait mais je voulais une confirmation.

    J'en ai parlé en TP avec Vincent, qui conseille d'éviter les
    doublons dans la structure pour éviter d'éventuels bug de
    développement.

    Sinon, je ne sais pas exactement à quoi correspond la chaîne de
    caracteres dans la table de hachage.
    (int * (string * OCTsynatx.typ_cours)) Hashtbl

    Vu qu'on a un accès direct au typ_cours grace à la table, on peut en
    faire un vers la liste des profs, salles et groupes qui partagent le
    même identifiant, non ?
    Un truc du genre (int * (OCTsyntax.pr_sal list *
    OCTsyntax.typ_cours)) Hashtbl
    Enfin sauf si le string permet déjà de faire ça.

Jerome VELLEINE a écrit :
>
> Salut,
>
>     Le typ_cours de oct c'est ce qui permet de remplir la table de 
> hachage....
>
>     Apres on a mis prof et sal dedans pour eviter de reparcourir tout 
> le pla pour chaque recherche....
>
>     C'est champs sont donc mis a jour ds typ_cours dans la table de 
> hachage!!!! puis le typ_cours de oct est mis a jour lors des 
> enregistrement....(en fait au prochain chargement une fois enregistrer)
>
>     J'espere que ca ta eclairé...
>
>     Bon week end a tout le monde...
>
>
>     > Message du 12/04/08 10:54
>     > De : "Anthony LY"
>     > A : oct...@li...
>     > Copie à :
>     > Objet : [Oct-general] typ_cours
>     >
>     > Bonjour,
>     >
>     > J'aurais besoin de précisions sur le typ_cours
>     >
>     > Rappel de la définition :
>     > ...
>     > and typ_cours=
>     > {
>     > id:int;
>     > typ:string;
>     > heure_total:minute;
>     > duree:minute;
>     > prof_crs:string option;(* prof *)
>     > salle_crs:string list;(* salle *)
>     > horair:creneau_periode;(* creneau horaire *)
>     > }
>     >
>     > and pr_sal=Prof of prof
>     > |Salle of salle
>     > |Groupe of groupe
>     >
>     > and pla=
>     > {
>     > ref_pl:pr_sal;
>     > descr_pl:int list
>     > }
>     > ...
>     >
>     > typ_cours.id et pla.descr_pl repésentent les identifiants dans
>     la table
>     > de hachage.
>     >
>     > Or, je ne comprends pas pourquoi, le typ_cours possède des champs
>     > prof_crs et salle_crs alors qu'on peut retrouver ces
>     informations en
>     > fouillant dans les listes de descripteurs du type pla.
>     > N'est-ce pas là une duplication des données ? Ces deux champs
>     sont-ils
>     > réellement utiles ?
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>     > Don't miss this year's exciting event. There's still time to
>     save $100.
>     > Use priority code J8TL2D2.
>     >
>     http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>     > _______________________________________________
>     > Oct-general mailing list
>     > Oct...@li...
>     > https://lists.sourceforge.net/lists/listinfo/oct-general
>     >
>     >
>

Salut,

    Le typ_cours de oct c'est ce qui permet de remplir la table de hachage....

    Apres on a mis prof et sal dedans pour eviter de reparcourir tout le pla pour chaque recherche....

    C'est champs sont donc mis a jour ds typ_cours dans la table de hachage!!!! puis le typ_cours de oct est mis a jour lors des enregistrement....(en fait au prochain chargement une fois enregistrer)

    J'espere que ca ta eclairé...

    Bon week end a tout le monde...

> Message du 12/04/08 10:54
> De : "Anthony LY" 
> A : oct...@li...
> Copie à : 
> Objet : [Oct-general] typ_cours
> 
> Bonjour,
> 
> J'aurais besoin de précisions sur le typ_cours
> 
> Rappel de la définition :
> ...
> and typ_cours=
> {
>   id:int;
>   typ:string;
>   heure_total:minute;
>   duree:minute;
>   prof_crs:string option;(* prof *)
>   salle_crs:string list;(* salle *)
>   horair:creneau_periode;(* creneau horaire *)
> }
> 
> and pr_sal=Prof of prof
>        |Salle of salle
>        |Groupe of groupe
> 
> and pla=
> {
> ref_pl:pr_sal;
> descr_pl:int list
> }
> ...
> 
> typ_cours.id et pla.descr_pl repésentent les identifiants dans la table 
> de hachage.
> 
> Or, je ne comprends pas pourquoi, le typ_cours possède des champs 
> prof_crs et salle_crs alors qu'on peut retrouver ces informations en 
> fouillant dans les listes de descripteurs du type pla.
> N'est-ce pas là une duplication des données ? Ces deux champs sont-ils 
> réellement utiles ?
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Oct-general mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/oct-general
> 
> 

Bonjour,

J'aurais besoin de précisions sur le typ_cours

Rappel de la définition :
...
and typ_cours=
{
  id:int;
  typ:string;
  heure_total:minute;
  duree:minute;
  prof_crs:string option;(* prof *)
  salle_crs:string list;(* salle *)
  horair:creneau_periode;(* creneau horaire *)
}

and pr_sal=Prof of prof
       |Salle of salle
       |Groupe of groupe

and pla=
{
ref_pl:pr_sal;
descr_pl:int list
}
...

typ_cours.id et pla.descr_pl repésentent les identifiants dans la table 
de hachage.

Or, je ne comprends pas pourquoi, le typ_cours possède des champs 
prof_crs et salle_crs alors qu'on peut retrouver ces informations en 
fouillant dans les listes de descripteurs du type pla.
N'est-ce pas là une duplication des données ? Ces deux champs sont-ils 
réellement utiles ?

Salut,

on nous bassine pour la compatibilite, certes, mais on nous bassine 
aussi pour le travail d'e'quipe.

Je n'avais pas lu ce commentaire de Vicent Balat car comme je l'ai dis 
le fichier interface.ml ne me concerne pas. Mais ce qui me ge`ne c'est 
le fait de prendre l'initiative de modifier un fichier sur lequels 
d'autres sont entraint de bosser et de le synchroniser en mettant ces 
personnes sur le fait accompli.

A moins que tu en ai parle' avec Baptiste et Ste'phane avant, auquel cas 
je te pre'sente mes excuses de mes insinuations publiques, mais cela n'a 
pas l'air d'e^tre le cas au vu de ton "de'sole' pour le retour en 
arrie`re". Dans le cas contraire, c,a les force a` re'adapter leur 
modifications en cours (non synchronise' sur svn).

Si mon message t'a vexe', j'en suis since`rement de'sole'. Ok c,a 
concerne une ligne, j'ai exage'ge' lors de mon dernier mail. Mais un peu 
plus de comminucation au lieu de mettre les gens sur le fait accompli ce 
serait mieux je pense.
La dernie`re fois qu'il y a eu ce genre de modif sur le moteur sans 
pre'avis, on a eu de la chance que ni Herve', ni moi ne travaillions 
dans le re'pertoire trunk a` l'e'poque.

Du calme, je ne pense pas que ce soit le ton à utiliser sur cette liste...

Il y a apparemment eu un changement d'interface dans lablgtk2. Il faut se 
mettre d'accord pour utiliser la version la plus récente je pense. Si 
vraiment certains veulent rester à une vieille version, il faut permettre la 
compilation dans les deux cas... Avec un petit script "configure" qui va 
modifier le fichier comme il faut, par exemple... (c'est un peu compliqué).

Au fait, Pierre Letouzey a mis à jour OCaml sur lucien (et donc les salles S 
et T). Normalement aussi Ocsigen, pgocaml et lablgtk2... Avec des versions 
très récentes. Dites nous si vous avez des problèmes.

Le vendredi 11 avril 2008, Riad KRIM a écrit :
> bonsoir,
>
> alors pour vous situer un peu dans l'historique
> il sagit de la fonction suivante dans le fichier interface.ml:
>
> let enter_cb entry (notebook:GPack.notebook) () =
> let text = entry#text in
> let label = GMisc.label
>     ~text:entry#text () in
>     let frame = GBin.frame
>         ~label:text
>         ~width:600
>         ~height:500
>         ~border_width:10
>         ~packing:(notebook#prepend_page ~tab_label:label#coerce) ()    
> <<<<<< erreur a cette ligne
>
> alors cette fonction a ete ecrite par            "Guillaume Malbert-Colas"
> et existe depuis la révision 27 (au moins..!) sache "Anthony LY" que
> quelqu'un s'est plaint d'une erreur a la compilation pour cette ligne, ce
> quelqu'un c'est notre prof "Vincent Balat" et il a corrigé le problème à la
> révision 562 je vous laisse lire le commentaire:
>
> 562    balat    (*    ~packing:(notebook#prepend_page
> ~tab_label:label#coerce) () in *) 562    balat    (* a revoir ! Pour que ca
> compile je remplace par : *) 562    balat    ~packing:(fun gov -> ignore
> (notebook#prepend_page ~tab_label:label#coerce gov)) () in
>
> ensuite            "Baptiste Tan" à la révision 605 a enlevé les
> commentaires pour remplacer la ligne qui compilait avec celle du
> commentaire qui provoque des erreurs de compil...
>
> en rentrant ce mercredi j'ai comparer avec la version 604, la dernière
> révision qui me permettais de compiler sans problème, et j'ai donc remis la
> ligne de code de  "Vincent Balat"
>
> voila pourquoi j'ai écris ceci:
> > j'ai comparé avec la version 604, et vu le commentaire que j'ai trouvé
> > j'ai remplacé sans me poser de question
>
> comment on peux reprocher a quelqu'un le fait d'améliorer la compatibilité
> d'un programme...! sachant qu'on nous bassine depuis la première année avec
> la compatibilité, que de grande entreprises travaille carrément sur des
> machine virtuelle pour faciliter les tests de compatibilité et moi je ne
> suis "pas super sympa" parce que j'ai modifié une ligne de code..! (pour
> qu'il recompile)
>
> je n'ai pas apprécié ton message "Anthony LY"  ....!
>
>
>
>
>
> ----- Message d'origine ----
> Message: 1
> Date: Thu, 10 Apr 2008 12:53:51 +0200
> From: "Anthony LY" <ly....@gm...>
> Subject: Re: [Oct-general] Oct-general Digest, Vol 8, Issue 4
> To: oct...@li...
> Message-ID:
>     <33a...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Je viens de r?cup?rer la r?vision 634, j'ai aucun probl?me de compilation
> m?me apr?s un make clean.
> Personne d'autre ne s'est plaint depuis la 605 (? ma connaissance), es-tu
> s?r que le probl?me ne vient pas de tes paquets ?
> M?me si ?a ne me regarde pas car je ne travail pas sur interface.ml, c'est
> pas super sympa de faire un commit pour un probl?me qui n'appara?t pas sur
> les machines des autres, ni sur celles de l'ufr.
> Rien ne t'empeche de faire une modification locale et ?viter de la
> synchroniser sur le serveur, si tu ne trouve pas d'autre solution.
>
> 2008/4/9, oct...@li...
>
> > Today's Topics:
> >
> >    1. bug a la compilation interface.ml (Riad KRIM)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 9 Apr 2008 18:49:18 +0000 (GMT)
> > From: Riad KRIM <twi...@ya...>
> > Subject: [Oct-general] bug a la compilation interface.ml
> > To: OcT Mailing List <oct...@li...>
> > Message-ID: <302...@we...>
> > Content-Type: text/plain; charset="utf-8"
> >
> > bonjour,
> > alors depuis la r?vision 605 j'ai une erreur ? la compilation, voila le
> > message d'erreur pour la r?vision 634:
> >
> > ocamlc -c -I BASE/ -I GUI/ -I MOTEUR/ -I `ocamlfind query
> > lablgtk2`  GUI/interface..ml
> > File "GUI/interface.ml", line 522, characters 13-60:
> > This expression has type GObj.widget -> int but is here used with type
> >   GObj.widget -> unit
> > make: *** [all] Erreur 2
> >
> > il sagit de la fonction: - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - - -
> >
> > let enter_cb entry (notebook:GPack.notebook) () =
> >   let text = entry#text in
> >   let label = GMisc.label
> >     ~text:entry#text () in
> >   let frame = GBin.frame
> >     ~label:text
> >     ~width:600
> >     ~height:500
> >     ~border_width:10
> >   ~packing:(notebook#prepend_page ~tab_label:label#coerce) ()     <<<<<<
> > 522
> >                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >   in frame#add
> > - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - -
> > - - - - - - - - - - - - - - -
> >
> > j'ai compar? avec la version 604, et vu le commentaire que j'ai trouv?
> > j'ai remplac? sans me poser de question
> >
> > r?sultat commit 635
> > voila..! d?sol? pour le retour en arri?re...!
> >
> >
> >
> >
> >
> >      
> > _________________________________________________________________________
> >____ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente
> > http://mail.yahoo.fr
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> >
> > ------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun..com/j
> >avaone
> >
> > ------------------------------
> >
> > _______________________________________________
> > Oct-general mailing list
> > Oct...@li...
> > https://lists.sourceforge.net/lists/listinfo/oct-general
> >
> >
> > End of Oct-general Digest, Vol 8, Issue 4
> > *****************************************

2007	Jan	Feb (12)	Mar (22)	Apr (20)	May (36)	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb (11)	Mar (2)	Apr (27)	May (4)	Jun (4)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2012	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug (1)	Sep (1)	Oct	Nov (1)	Dec

oct-general Mailing List for OcT (Ocaml Timetable)

oct-general — OcT general