Poster une réponse à un sujet: [Eclipse 3.2] Crash aléatoire sous Linux
Attention, ce sujet est un sujet ancien (5621 jours sans réponse)
ovh
Bon c'était bien un problème de JVM, on dirait bien que ça ne plante plus
En passant j'ai... tout réinstallé
En fait j'ai voulu mettre le plugin PDT (pour du php), et il nécessitait une version plus récente, or dans les packages ubuntu c'est encore la 3.2
Du coup j'ai tout refait de zéro, comme c'est une appli java c'est facile :
- download de la version eclipse prépackagée avec pdt dernière version stable (pdt 2.0, eclipse "ganymede" 3.4.1)
- dézippage et hop exécution et ça marche
- j'ai rajouté subclipse et pydev ensuite sans problème par la méthode classique (help > software update > ajouter une url etc.)
Et tout semble rouler
![:oh: :oh:](images/smileys/oh.gif)
En passant j'ai... tout réinstallé
![:petrus: :petrus:](images/smileys/petrus.gif)
![:kiki: :kiki:](images/smileys/kiki.gif)
Du coup j'ai tout refait de zéro, comme c'est une appli java c'est facile :
- download de la version eclipse prépackagée avec pdt dernière version stable (pdt 2.0, eclipse "ganymede" 3.4.1)
- dézippage et hop exécution et ça marche
![:dawa: :dawa:](images/smileys/dawa.gif)
- j'ai rajouté subclipse et pydev ensuite sans problème par la méthode classique (help > software update > ajouter une url etc.)
Et tout semble rouler
![:smile: :smile:](images/smileys/smile.gif)
ovh
bli> Mon but est d'utiliser Eclipse aussi parce que c'est un standard de fait auprès de beaucoup de développeurs
Donc je me "dois" de le connaître.
Pour l'instant ça a l'air stable avec la JVM de Sun, je reposte quand j'aurai eu l'occasion de le tester un peu plus intensivement que ces derniers jours.
![:spamafote: :spamafote:](images/smileys/spamafote.gif)
Pour l'instant ça a l'air stable avec la JVM de Sun, je reposte quand j'aurai eu l'occasion de le tester un peu plus intensivement que ces derniers jours.
blietaer
OVh> si c'était mon topic, je suis pas sûr que j'aimerais cette intervention, mais as-tu essayé Kdevelop ? je sais que tu es un fan de XFCE et/ou code::blocks que j'aime individuellement pour plein de raisons, mais m'étant érigé un petit envirronement KDE, bien léché, j'ai vraiment pris goût à cet IDE et je l'utilise déjà pour quelques langages C/C++, PHP/HTML, TCL/Tk... Ma connaissance en Py s'étant à la lecture du HS de LinuxMagazine (qui malheureusement est plus philosophique que didactique...pour un débutant pure)
gizmo
Bon, je n'arrive plus à retrouver l'article en question, mais je pense que j'ai trouvé où se trouvait mon erreur. Si me me souviens bien, l'article comparait les threads java avec la solution apporté avec Python 2.6 pour imiter les thread via les process (le module multiprocessing).
Mon esprit a du faire une confusion stupide parce qu'il reprennent justement l'API des thread mais appliqué aux process.
Mais du coup, ce n'est pas fair-play de comparer la consomation mémoire d'une seule VM avec n thread contre n VM avec 1 thread.
Mon esprit a du faire une confusion stupide parce qu'il reprennent justement l'API des thread mais appliqué aux process.
Mais du coup, ce n'est pas fair-play de comparer la consomation mémoire d'une seule VM avec n thread contre n VM avec 1 thread.
philfr
gizmo> n'importe quel développeur Python sait que l'utilisation des threads dans ce langage est à éviter, mais pas du tout pour la raison que tu dis (je me demande d'ailleurs où tu as entendu ça), mais parce que l'interpréteur a une "global interpreter lock" qui fait que les threads sont très limité en ce qu'ils peuvent faire en parallèle. Il vaut beacoup mieux travailer en multiprocess ou mieux encore, en asynchrone.
Alors, je suis sûr que tu es très compétent en beaucoup de choses, mais je répète que ce que tu dis sur les threads Python ne veut rien dire, ou est au mieux simplement faux...
Alors, je suis sûr que tu es très compétent en beaucoup de choses, mais je répète que ce que tu dis sur les threads Python ne veut rien dire, ou est au mieux simplement faux...
Altar
gizmo > Et la charge cpu supplémentaire apportée par la gestion de ces nombreux threads ?
![:whistle: :whistle:](images/smileys/whistle.gif)
gizmo
J'ai pas trop envie de rentrer dans le débat, mais ce que tu dis là ne veut rien dire
![:oh: :oh:](images/smileys/oh.gif)
Ok, alors pour préciser plus: Pour une même unité de business logic, l'empreinte mémoire d'une série de thread python est plus importante que leur équivalent java. Donc ce que l'on gagne avec sur l'empreinte mémoire de la VM python, on le perd par la suite si on a un programme fortement multi-thread.
rfr
Je rajouterai que Ovh a pas tort au niveau "deploiement" quand on rentre dans les applications servers du style JBoss, Weblogic,...
Bien qu'encore une fois, ça commence tout doucement à s'améliorer (EJB vs EJB3).
C'est clair que c'est verbeux, mais cet inconvénient est largement oublié quand on voit l'élégance des API disponibles (et pas besoin de se lancer dans l'IoC, l'AOP etc ...). On fait déjà beaucoup avec le jdk.
Bien qu'encore une fois, ça commence tout doucement à s'améliorer (EJB vs EJB3).
C'est clair que c'est verbeux, mais cet inconvénient est largement oublié quand on voit l'élégance des API disponibles (et pas besoin de se lancer dans l'IoC, l'AOP etc ...). On fait déjà beaucoup avec le jdk.
rfr
... et son obstination a obliger de tout caster, ce qui retire une bonne partie de l'intérêt du typage statique fort.
Extrait de "How to write unmaintainable code", une des plus belles colection d'anti-patterns:
Sauf que ce n'est plus vraiment vrai non plus
![:wink: :wink:](images/smileys/wink.gif)
Ok, il a fallu que C# arrive pour que Sun nous sorte une syntaxe "new Brol<X>()" mais si on code bien, le typecasting n'est plus obligatoire car les collections (ou tout autre classe) peuvent être paramètrisées.
Java 6 Gizmo il a dit, pas Java 1 ou 1.2 ou 1.3 ou 1.4 ou ... 5
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
zion
/me est content de coder en object pascal après tout
</pollution>
</pollution>