Connection à une IHM en IlogViews

Connection à une IHM en IlogViews

[Emmanuel Dorlet]

Français
======

Nous allons devoir réaliser dans un proche avenir des IHM à
l'application de pilotage de code couplage
de codes du CEA-DRN (ISAS).
Ilog Views a été retenu par la DRN comme le produit industriel pour
réaliser des IHM d'assez haut niveau.
Tcl-Tk n'est pas, nous semble-t-il, à un niveau suffsant pour le type
d'interface que l'on sera amené à
réalsier à terme.
Le problème risque d'être rapidement posé dans d'autres utilisation,
aussi nous faut-il trouver une réponse
générale et réutilisable.

Existe-t-il une expérience d'un tel tandem?
Quel serait à votre avis la bonne approche:
    - 1) édition de lien Ocaml/Views pour un exécutable:
            - sans Top-level (mais alors pas de moyen d'enrichir
dynamiquement l'application, ce
                qui est un besoin fort)
            - 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
    - 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
La première me semble délicate, mais aurait pour avantage de ne pas
nécessiter le développement d'un
protocole particulier à chaque développement d'IHM.
La seconde est plus simple, mais demande un nouveau protocole à chaque
application.

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)?
Ce qui a été fait avec TK est-il de même nature?

==================================================
English
======

We need to interface Ocaml with the graphic library ILOG-VIEWS.
Does some body have already study the question and could give us some
return?
Is there a idea on what is the best solution: a direct link Ocaml/Views
(but we need to keep
an Ocaml Top-Level) or separate process with a specific protocol for
each developement.
Does a close implementation of Ilog Views (with some access to Views
class and primitives in the style
of what has be done with TK) is possible?


-----------------------------
Emmanuel Dorlet
CEA centre de Saclay
DRN/DMT/SYSCO
91191 GIF sur Yvette
email: Emmanuel.Dorlet@cea.fr
tel: (33) 01 69 08 91 17
sec: (33) 01 69 08 91 10
fax: (33) 01 69 08 96 96
-----------------------------

Re: Connection à une IHM en IlogViews

[Patrick Loiseleur]

In his message of Mon October 12, 1998, Emmanuel Dorlet writes: 
>     - 1) édition de lien Ocaml/Views pour un exécutable:
>             - sans Top-level (mais alors pas de moyen d'enrichir
> dynamiquement l'application, ce
>                 qui est un besoin fort)


Avec le module Dynlink de la librairie standard, vous pouvez charger
et lier dynamiquement des .cmo : pas besoin donc d'avoir un toplevel.

[English] You can dynamically load and link compiled module unsing the
functions of the module Dynlink in the std library

-- 
Patrick.Loiseleur@lri.fr

Re: Connection à une IHM en IlogViews

[Xavier Leroy]

> [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

Re: Connection à une IHM en IlogViews

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

>>>>> "Emmanuel" == Emmanuel Dorlet <dorlet@soleil.serma.cea.fr> writes:
>             - 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

Je ne suis pas sûr de vraiment comprendre la question et le contexte,
mais il est souvent possible dans ce genre de cas d'utiliser un `select'
sur le filedescriptor de l'entrée standard *et* sur le filedescriptor
du socket Xwindows.
Mais j'ai l'impression que ça risque de poser plus de problèmes que cela n'en
résout.


	Stefan

Re: Connection à une IHM en IlogViews

[Jacques GARRIGUE]

From: Emmanuel Dorlet <dorlet@soleil.serma.cea.fr>

> Nous allons devoir réaliser dans un proche avenir des IHM à
> l'application de pilotage de code couplage
> de codes du CEA-DRN (ISAS).
> Ilog Views a été retenu par la DRN comme le produit industriel pour
> réaliser des IHM d'assez haut niveau.
> Tcl-Tk n'est pas, nous semble-t-il, à un niveau suffsant pour le type
> d'interface que l'on sera amené à
> réalsier à terme.

J'ai regarde' moi-meme les differentes interfaces graphiques
disponibles, et je penses qu'avant de faire un choix il faut voir le
probleme dans son ensemble.

Soit, Tcl/Tk n'est pas la panacee. Il y a parfois des choses
difficiles a` exprimer. Mais il y a aussi des avantages majeurs, comme
la grande facilite' de developpement, ou la possibilite' d'utilisation
sur des systemes varies. La facilite' pour l'utilisateur de changer
l'apparence (choix des polices, etc...) ne me parait pas a` negliger.
Tout ca me semble plus difficile dans d'autres interfaces.

A remarquer aussi, Tcl/Tk est lui-meme extensible (en C), et CamlTk
(ainsi que LablTk) peut facilement tirer parti de ces extensions.

Interfacer une autre bibliotheque, en creant des stubs C, n'est pas
impossible. Je l'ai fait recemment a` grande echelle pour interfacer
completement OpenGL. Malheureusement, les interfaces graphiques
utilisent beaucoup de structures de donnees (contrairement a` OpenGL
qui n'utilise que des donnees simples), ce qui rend beaucoup plus
complexe l'interfacage.

Pour ces deux raisons, meme si ca peut paraitre un peu decourageant,
je deconseillerai de se lancer dans la creation d'une telle interface,
a` moins d'etre tres competent en OCaml. Comme le fait remarquer
Xavier Leroy, un outil de generation automatique pourrait changer cet
etat de fait, mais a` l'heure actuelle il me semble que le ratio
cout/performance est mauvais. Pire, si elle n'est pas concue avec
assez de soin, une telle interface risque d'etre tres rapidement
abandonnee.

> Quel serait à votre avis la bonne approche:
>     - 1) édition de lien Ocaml/Views pour un exécutable:
>             - sans Top-level (mais alors pas de moyen d'enrichir
> dynamiquement l'application, ce
>                 qui est un besoin fort)

Comme quelqu'un l'a deja` dit, grace au module Dynlink il est possible
d'etendre un executable sans toplevel. MMM est un exemple d'une telle
application.

>             - 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 bien sur plus convivial. Jun Furuse <Jun.Furuse@inria.fr> avait
commence' a` travailler la-dessus avec CamlTk, et obtenu de bons
resultats. L'idee etait d'utiliser les threads caml pour appeler Tk
depuis un thread, et utiliser un autre thread pour le toplevel. Il
n'est malheureusement pas alle' jusqu'au bout des problemes
techniques, mais comme l'ecrit Xavier dans son mail, ca marchait
grosso-modo parce que le changement de thread ne peut se faire
qu'apres retour a` la boucle Caml --pas de probleme de re-entrance.

> 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)?
> Ce qui a été fait avec TK est-il de même nature?

C'est un peu ce a` quoi j'ai repondu dans la premiere partie de mon
mail. Si vous voulez ecrire l'interface utilisateur en C, et la
presenter a` Caml comme un petit nombre de fonctions, c'est tres
faisable et pas tres difficile, mais je crois que CamlTk ou LablTk
donneront un resultat plus satisfaisant au niveau de l'integration.

Un mapping complet de l'API est une tache lourde qui demande a` etre
automatisee, et aussi qui pose de serieux problemes de qualite'.

Cordialement,

	Jacques Garrigue
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>