Version française
Home     About     Download     Resources     Contact us    
Browse thread
Connection à une IHM en IlogViews
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xleroy@p...>
Subject: Re: Connection_à_une_IHM_en_IlogViews
> [Using Ilog Views with OCaml>

>     - 1) édition de lien Ocaml/Views pour un exécutable:
>             - avec Top-level, mais dans ce cas comment faire co-exister
> la boucle X et l'interprète, et où serait saisie
>                 les entréees clavier de l'utilisateur

C'est un gros problème en effet.  Je l'ai rencontré en écrivant la
version X-Windows de la biliothèque libgraph.  La solution retenue
pour libgraph est d'utiliser l'entrée standard (via une fenêtre xterm)
pour entrer des phrases au toplevel, et de traiter les événements X
dans un "signal handler" (SIGIO sur la socket X si disponible, sinon
par une interruption d'horloge qui va voir s'il y a des événements à
traiter).

Une telle approche est bien connue pour ne pas marcher en C, car le
"signal handler" peut être appelé au milieu de code C non réentrant.
En Caml, ça marche correctement car le traitement des signaux est
retardé jusqu'à ce qu'on atteigne un point "sûr" dans l'exécution du
programme.

Le plus gros problème est que SIGIO n'est pas disponible sur tous les
Unix.  Utiliser une interruption d'horloge à la place est moins
efficace: on sent un léger délai entre l'action de l'utilisateur et
son traitement.

>     - 2) lancer 2 process séparés, connectés par des "chaussettes" et
> développement d'un protocole ad-hoc pour
>         depuis l'interface, lancer des execution dans Ocaml et
> réciproquement pour, depuis Ocaml, activer des
>         fonctions de l'interface

C'est ainsi que fonctionnait la première version de CamlTk.  Cela
donne une grande indépendance entre l'IHM et le processus Caml, mais
comme vous le dites nécessite de construire un protocole adapté.
Aussi, cela peut être inefficace s'il y a de grandes quantités de
données à transmettre entre Caml et l'IHM.

> Outre ce problème d'architecture, peux-t-on envisager un mapping plus
> profond avec IlogViews
> (API des classes Views en objets Ocaml par exemple)?

C'est sans doute possible en passant par l'interface avec C de Caml et
en utilisant les possibilités d'appels C-C++ fournis par tous les
compilateurs C++.  Cependant, c'est un gros travail d'écriture de
"stub code", aussi bien du côté C++ que du côté Caml.

Une interface entre Caml et CORBA/IDL/COM/etc faciliterait beaucoup
cet interfaçage, mais nous n'en disposons pas encore.

> Ce qui a été fait avec TK est-il de même nature?

C'est un peu plus simple dans le cas de TK, car TK vient avec son
propre langage de commande, Tcl.  Il a suffi de "remonter" en Caml
quelques fonctions C de base en Tcl (TclEval, principalement).  Tout
le reste de CamlTk se compose de fonctions Caml qui construisent des
commandes Tcl et les passent à TclEval.

Cordialement,

- Xavier Leroy