From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA06214 for caml-redistribution; Fri, 16 Oct 1998 13:34:06 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA00015; Thu, 15 Oct 1998 19:40:47 +0200 (MET DST) Message-ID: <19981015194047.55109@pauillac.inria.fr> Date: Thu, 15 Oct 1998 19:40:47 +0200 From: Xavier Leroy To: Emmanuel.Dorlet@cea.fr, Liste-Caml Subject: Re: =?iso-8859-1?Q?Connection_à_une_IHM_en_IlogViews?= References: <3621C6E2.DEF69281@soleil.serma.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.89.1 In-Reply-To: <3621C6E2.DEF69281@soleil.serma.cea.fr>; from Emmanuel Dorlet on Mon, Oct 12, 1998 at 11:07:46AM +0200 Sender: weis > [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