interface between clisp and java
Francois
realise a project using CLOS and JAVA. Do you know if there is any
way to have them communicating. Expecting your answer, thank you.
Marc Battyani
"Francois" <francois....@tele2.fr> wrote in message
> Curently students at engineering school (ENSICAEN), we are trying to
> realise a project using CLOS and JAVA. Do you know if there is any
> way to have them communicating. Expecting your answer, thank you.
Ahem...dans les gourpes français (fr.*) il est d'usage de parler français ;-)
Pour Java <=> Lisp la meilleure option à mon avis c'est de faire communiquer
les 2 process par socket.
Sinon il y a des librairies genre http://www.cliki.net/LIJOS et
http://www.cliki.net/JACOL
Ou des Lisp qui tournent dans la JVM genre ABL
http://www.cliki.net/Armed%20Bear%20Lisp
Marc
TestMan
C'est le moment de rappeler l'exxxcelent lien :
http://www.robert-tolksdorf.de/vmlanguages.html
(anc. http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html)
Il liste la majorité des languages disponibles sous Java (en compilé ou
en interprété).
Un lien à envoyer aux comerciaux de Macromou qui pipotent leur client
avec des arguments du style : "Java, ça ne marche qu'avec un seul
langage ... c'est pas bien ! Par contre le pointNet, c'est bien car ya
plein de langages."
(Sans commentaires)
TM
Fabrice Popineau
> Un lien à envoyer aux comerciaux de Macromou qui pipotent leur client
> avec des arguments du style : "Java, ça ne marche qu'avec un seul
> langage ... c'est pas bien ! Par contre le pointNet, c'est bien car ya
> plein de langages." (Sans commentaires)
Oui, enfin la différence, c'est quand même que la JVM (Sun dans mon cas)
ne marche pas vraiment, en tout cas sous Windows. Alors à quoi sert de
compiler d'autres langages vers la JVM ???
[ Entre autres... il y a des problèmes avec le scheduler de la JVM qui a
l'air totalement indépendant de celui du système, ce qui induit des
temps de latence qui rendent les applis graphiques assez pénibles à
utiliser.]
--
Fabrice Popineau
------------------------
e-mail: Fabrice....@supelec.fr | The difference between theory
voice-mail: +33 (0) 387764715 | and practice, is that
surface-mail: Supelec, 2 rue E. Belin, | theoretically,
F-57070 Metz | there is no difference !
Nicolas Delsaux
j'écrivais aux mecs de fr.comp.lang.java ?"
>
> Oui, enfin la différence, c'est quand même que la JVM (Sun dans mon cas)
> ne marche pas vraiment, en tout cas sous Windows. Alors à quoi sert de
> compiler d'autres langages vers la JVM ???
Qu'est-ce que c'est encore que cette légende ?
>
> [ Entre autres... il y a des problèmes avec le scheduler de la JVM qui a
> l'air totalement indépendant de celui du système, ce qui induit des
> temps de latence qui rendent les applis graphiques assez pénibles à
> utiliser.]
>
Ce serait pas plutôt parce que tu n'as pas parfaitement codé ton interface
?
--
Nicolas Delsaux
"S'il existe deux ou plusieurs manières de faire quelque chose et que l'une
de ces manières est susceptible de se solder par une catastrophe, on peut
être certain que quelqu'un se débrouillera pour la choisir."
Edward A.Murphy Jr
Fabrice Popineau
> Qu'est-ce que c'est encore que cette légende ?
Ca n'est pas une légende, c'est d'expérience. Avant de réinstaller XP,
j'utilisais la MSJVM qui n'avait manifestement pas le même
comportement. Microsoft ne distribue plus la MSJVM, donc j'ai été obligé
de passer à celle de Sun.
>> [ Entre autres... il y a des problèmes avec le scheduler de la JVM
>> qui a l'air totalement indépendant de celui du système, ce qui induit
>> des temps de latence qui rendent les applis graphiques assez pénibles
>> à utiliser.]
>>
> Ce serait pas plutôt parce que tu n'as pas parfaitement codé ton
> interface ?
Ca n'est pas moi qui ai écrit le code, sinon j'aurais cherché à savoir
ce qui ne marchait. Je constate simplement que des étudiants qui
utilisent naïvement Swing ou Awt n'obtiennent pas un résultat
satisfaisant.
Et de toute façon cette histoire de scheduler est flagrante. Il suffit
de faire tourner une appli quelconque qui consomme 50% de temps CPU et
de la mettre en background. Ensuite de lancer une appli Swing : ca
devient quasi impossible de cliquer sur les boutons. Ce qui me conduit a
penser que la JVM implémente un système événementiel et un scheduler
dans un seul processus du système hôte et ne peut donc pas avoir un
temps de réponse raisonnable (autre explication ?).
Erwan David
> Et de toute façon cette histoire de scheduler est flagrante. Il suffit
> de faire tourner une appli quelconque qui consomme 50% de temps CPU et
> de la mettre en background. Ensuite de lancer une appli Swing : ca
> devient quasi impossible de cliquer sur les boutons. Ce qui me conduit a
> penser que la JVM implémente un système événementiel et un scheduler
> dans un seul processus du système hôte et ne peut donc pas avoir un
> temps de réponse raisonnable (autre explication ?).
Appli swing mal codée qui fait tout dans le thread de traitement des
évènement.
Nicolas Delsaux
j'écrivais aux mecs de fr.comp.lang.java ?"
>
> Ca n'est pas une légende, c'est d'expérience. Avant de réinstaller XP,
> j'utilisais la MSJVM qui n'avait manifestement pas le même
> comportement. Microsoft ne distribue plus la MSJVM, donc j'ai été obligé
> de passer à celle de Sun.
La machine virtuelle Microsoft n'a *jamais* correspondu aux standards de
conformité Java. En conséquence, une appli développée pour cette plateforme
(puisqu'apparement elle marchait mieux dessus) n'est pas une appli Java
standard et peut avoir un comportement déroutant sur un JRE conforme.
>
> Ca n'est pas moi qui ai écrit le code, sinon j'aurais cherché à savoir
> ce qui ne marchait. Je constate simplement que des étudiants qui
> utilisent naïvement Swing ou Awt n'obtiennent pas un résultat
> satisfaisant.
Etonnant, non ?
Un étudiant qui code sa première appli C aura sans doute des pertes de
mémoire flagrantes, des problèmes d'accès à des zones réservées de sa
mémoire, etc, ... Mais ça ne sera pas la faute du C. Si ce même débutant
code une appli Java toute pourrie, là, c'est la faute du langage.
>
> Et de toute façon cette histoire de scheduler est flagrante. Il suffit
> de faire tourner une appli quelconque qui consomme 50% de temps CPU et
> de la mettre en background. Ensuite de lancer une appli Swing : ca
> devient quasi impossible de cliquer sur les boutons. Ce qui me conduit a
> penser que la JVM implémente un système événementiel et un scheduler
> dans un seul processus du système hôte et ne peut donc pas avoir un
> temps de réponse raisonnable (autre explication ?).
>
Comme l'a dit Erwan, c'est sans aucun doute dû au fait que l'appli fait les
traitements dans le thread d'événements de Swing, ce qui n'est pas une idée
très raisonnable, et est d'ailleurs assez fortement déconseillé.
--
Nicolas Delsaux
"L'important n'est pas de se libérer du corps, mais de se libérer du
mental. Ce n'est pas le corps qui nous empètre mais l' esprit."
Thomas Merton - Journal d'Asie
Fabrice Popineau
> Etonnant, non ? Un étudiant qui code sa première appli C aura sans
> doute des pertes de mémoire flagrantes, des problèmes d'accès à des
> zones réservées de sa mémoire, etc, ... Mais ça ne sera pas la faute
> du C. Si ce même débutant code une appli Java toute pourrie, là, c'est
> la faute du langage.
Ca n'a rien à voir. Le langage C possède des trous dans sa définition
(genre que vaut a = ++b + b++ ) et implémente des fonctionalités qui
dépassent à peine celles d'un macro-assembleur. Il y a des erreurs qui
sont liées à la défintion du langage, d'autres qui peuvent être liées à
l'environnement d'exécution. Par exemple, en C, retourner un tableau
déclaré localement est une erreur indépendante de l'environnement
d'exécution.
En revanche quand on parle de Java, tout le monde confond toujours le
langage et l'environnement d'exécution. J'ai quelques critiques contre
le langage mais elles n'ont rien à voir avec ce dont il était
question. Ici il n'est question que de l'environnement d'exécution et de
son intégration dans le système. A la limite, je veux bien qu'on me
donne un compilateur Java vers code natif de ma machine. En revanche, je
ne vois toujours pas l'intérêt d'écrire un programme dans un langage X
pour le compiler en bytecode JVM (puisque c'était le sujet d'origine).
Tout ce qui risque d'arriver, ce sont des pertes de performances non
négligeables à l'exécution et une plus grande opacité en cas de
problèmes.
> Comme l'a dit Erwan, c'est sans aucun doute dû au fait que l'appli
> fait les traitements dans le thread d'événements de Swing, ce qui
> n'est pas une idée très raisonnable, et est d'ailleurs assez fortement
> déconseillé.
Peut-être ... Mais ce n'est pas l'apanage d'applis de débutants dans ce
cas. Je peux citer des applis du commerce qui ont aussi des défauts du
flagrants du même type ou du type consommation de 20% du cpu en
permanence. Pourquoi ce type de défaut est-il toujours lié à des applis
Java alors que ca n'arrive pas avec des applis natives ? Ne serait-ce
pas lié à cet environnment d'exécution ? ;-)
Nicolas Delsaux
j'écrivais aux mecs de fr.comp.lang.java ?"
>
> le langage et l'environnement d'exécution. J'ai quelques critiques
> contre le langage mais elles n'ont rien à voir avec ce dont
> il était question.
Bien sûr que si.
> Ici il n'est question que de l'environnement d'exécution et de
> son intégration dans le système. A la limite, je veux bien qu'on
> me donne un compilateur Java vers code natif de ma machine. En
> revanche, je ne vois toujours pas l'intérêt d'écrire un programme
> dans un langage X pour le compiler en bytecode JVM (puisque c'était
> le sujet d'origine). Tout ce qui risque d'arriver, ce sont des
> pertes de performances non négligeables à l'exécution et une plus
> grande opacité en cas de problèmes.
L'explication est simple : "write once, run anywhere".
Evidement, cette philosophie a un coût, qui est toutefois loin de ce qui
est courament constaté.
>
> Peut-être ... Mais ce n'est pas l'apanage d'applis de débutants dans
> ce cas. Je peux citer des applis du commerce qui ont aussi des
> défauts du flagrants du même type ou du type consommation de
> 20% du cpu en permanence. Pourquoi ce type de défaut est-il
> toujours lié à des applis Java alors que ca n'arrive pas avec des
> applis natives ? Ne serait-ce pas lié à cet environnment d'exécution
> ? ;-)
>
Je ne vais pas jouer le donneur de leçon, mais simplement rappeler
quelques faits : il existe un nombre considérable d'applications "du
commerce" développées par des gens qui ont tout au plus des notions
lacunaires du langage de développement utilisé. Et l'une des plus
grosses lcaunes concerne justement la manière d'optimiser une interface
graphique. Sans vouloir rentrer dans les détails, du fait de certaines
contraintes inhérentes à AWT et Swing, les applications graphiques sont
la plupart du temps monothread. Et ça implique mécaniquement que, si tu
fais une requête SQL lors de l'appui d'un bouton, ton bouton attend pour
réagir que la requête se soit terminée. Si avec ça tu arrives à
concevoir une interface réactive, bravo ! Finallement, le problème
vient, comme souvent, de la méconnaissance de la plateforme et des
outils : il est expréssément spécifié dans la javadoc de Swing qu'il
faut effectuer un minimum de travail dans le thrad Swing, faute de quoi
les performances s'effondrent, au prix que tu mentionnes.
--
Nicolas Delsaux
Les maximes du marin shadok : Dans la marine, c'est un principe : il
faut saluer tout ce qui bouge, et peindre le reste.
Fabrice Popineau
> L'explication est simple : "write once, run anywhere". Evidement,
> cette philosophie a un coût, qui est toutefois loin de ce qui est
> courament constaté.
"write once, debug everywhere" ...
> Je ne vais pas jouer le donneur de leçon, mais simplement rappeler
> quelques faits : il existe un nombre considérable d'applications "du
> commerce" développées par des gens qui ont tout au plus des notions
> lacunaires du langage de développement utilisé. Et l'une des plus
> grosses lcaunes concerne justement la manière d'optimiser une
> interface graphique. Sans vouloir rentrer dans les détails, du fait de
> certaines contraintes inhérentes à AWT et Swing, les applications
> graphiques sont la plupart du temps monothread. Et ça implique
> mécaniquement que, si tu fais une requête SQL lors de l'appui d'un
> bouton, ton bouton attend pour réagir que la requête se soit
> terminée. Si avec ça tu arrives à concevoir une interface réactive,
> bravo !
N'exagérons rien ... Ca serait stupide et ca n'a pas exactement à voir
avec les problèmes que je citais:
- l'appli en question réagissait parfaitement tant que la machine n'est
pas chargée; si c'est vraiment un problème de traitements effectués dans
la boucle de gestion des événements, la différence de temps de réponse
me parait curieuse : ça devrait être mauvais aussi même machine non
chargée;
- je connais d'autres applis (commerciales) qui a l'inverse chargent la
machine en ne faisant rien (enfin elles doivent faire du polling sur
quelque chose ...) et c'est très désagréable
D'autre part, nous avions ici un ensemble d'applis "pédagogiques"
écrites en C (type producteurs/consommateurs, threads, sémaphores, etc.)
qui ont été réécrites en Java. A cette occasion, on a pu constater des
différences de comportement flagrantes entre le mécanisme de threads de
Java et celui des threads natifs (sous windows), entre autre du point de
vue temps de réponse, et aussi des différences flagrantes entre J# et
JavaSun.
D'où ma remarque à l'origine : je ne vois pas bien le bénéfice de
compiler des langages source sur le code de la JVM plutôt que sur du
code natif. Mais chacun ses goûts ...