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.
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.
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.
"Francois" wrote in messageCurently 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
"Francois" <francois.lecellier@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
"Francois" wrote in messageCurently 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
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)
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)
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.]
Ce serait pas plutôt parce que tu n'as pas parfaitement codé ton interface
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.]
Ce serait pas plutôt parce que tu n'as pas parfaitement codé ton interface
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.]
Ce serait pas plutôt parce que tu n'as pas parfaitement codé ton interface
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 ?
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 ?
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 ?
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 ?).
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 ?).
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 ?).
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.
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 ?).
Comme l'a dit Erwan, c'est sans aucun doute dû au fait que l'appli fait les
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.
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 ?).
Comme l'a dit Erwan, c'est sans aucun doute dû au fait que l'appli fait les
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.
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 ?).
Comme l'a dit Erwan, c'est sans aucun doute dû au fait que l'appli fait les
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.
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é.
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.
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é.
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.
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é.
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.
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
? ;-)
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.
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
? ;-)
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.
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
? ;-)
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é.
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 !
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é.
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 !
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é.
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 !
