Reprise du message précédent :

mauvais copier coller
 
edit : corriged.
 
 
Taz > non, j'ai pas parlé de python. et alors ? j'ai parlé de Java et de la synchronisation ... c'est lié au problème de very ... je vois pas le soucis.

 
no soucis hein
 

 
en fait ca etend les possibilités du prog via l utilisation de scripts, l idée a la base est sympa et ca existe sur presque tout les client irc qui se respectent; le prob c'est que je manque cruellement d'exemples et de docs alors j'ai l'impression de faire fausse route
 

 
Plus y'a acces au prog plus ca permet des choses puissantes , je precise qd meme que pour l'instant j'ai pas eu de probleme avec ... mais j'ai crée que des petits script a la con faut dire

Moi je vois 2 choses :
 
1) Tu laisse un accès total à ton prog depuis python, mais dans ce cas c'est super dangereux (qu'est ce qui l'empehe de récupérer des instances de tes objets et d'affecter n'importe quel valeur à leurs attributs, mettre tes objets dans des états anormaux, etc ...) et il va donc falloir que tu blindes ton code pour la synchronisation ET pour l'accès aux points sensibles de toute ton appli.
 
2) Tu mets en place un protocole d'intéraction entre ton prog et le script python, par exemple en laissant accès à certaines méthodes (envoyer un message, chanegrde channel, récupérer la liste des users) et en mettant en place un système évenmentiel pour que ton appli prévienne le script de nouveaux évenements (arrivée de message, d'utilisateurs, etc ...). Dans ce cas, tu as juste à blinder les méthodes accessibles de ton appli.

j'avais commencé a repondre a ton paé quand j'ai lu cette phrase (j'avais pas fait gaffe)
 

 
La je dois dire que le second degré m'a carrement échappé
 

 
 
A ben finalement, c'etait du second degré ou tu pensais vraiment que taz trollait ?
 
 
 
Very, a ta place je mettrais pe une couche entre python et ton code java (eg python n'accede pas directement a ton bins) juste pour avoir un meilleur control de ce qui se passe et que ca ne devienne pas la foire si l'utilisateur debloque
 
 

je prend note de tous ca ,merci a vous

bah tu peux faire les limitations dans python et le module cmd (ou bastion et rexec mais ils ont quelques problèmes, désactivés en 2.3)

ben nan mais là c'était en réaction à ton post. Tu me demande d'attendre ses arguments ... Comment est ce que je peux imaginer qu'il va argumenter (ce qu'il n'a pas fait d'ailleur) ???  
 

évidement que je pensais que Taz trollait (pléonasme). C'est juste que c'était dit d'une façon comic, quoi ...

ok, avec les synchronized, je n'ai pas trouvé comment faire des vérouillage récursifs, ça te va. et j'ai fait la remarque qu'il existait des API et bibliothèques dans d'autres langages bien foutues

 
Benou !
Il a mis un E a "foutues" !
Il parle donc des bibliotheques, pas des langages !
Respire !

ben je trouve ça intelligent de ne pas mettre la concurrence directement dans le langage

qu'est ce que tu appelles vérouillage récursif ?
 
je sais que tu as fait cette remarque, mais tu n'as pas expliqué ce que ca apporté de plus. C'est ca qui sertait intéressant ...
 
pour info : dans la version 1.5 de java il y aura un package java.util.concurrency pour la problématique d'application multithreadées. j'en entend bcp de bien mais je ne sais pas trop de quoi il s'agit (j'ai loupé la conf dessus à javaone   )

 
non c'est juste que quand j'ai lu ton post pour la premiere fois j'ai lu "dans d'autres langages bien foutus" j'ai eu peur que ca degenere

me fait pas le coup : je connais pas, ça n'existe pas, t'as un problème de design

et les tentatives d'acquisition avec attente ? non bloquante ?

hein ???  

ouep. en effet ca existe pas ca ... faut magouiller avec des booleans ...

euh la je vois pas comment dans le cas d'une attente ? me dit pas faire une boucle, ce n'est pas une solution, ce n'est pas équitable
 
 
au fait : y a des sémaphores en Java ?

veryfree > tu penses quoi d'assurer le contrôle directement dans jython ?

Tiens, jette un coup d'oeil à ca : ca devrait te plaire : http://gee.cs.oswego.edu/dl/concur [...] index.html
nottament java.util.concurrent.locks.Lock
 
après, comment ils ont fait, faudrait voir les sources ...

donc en quelques sortes on peut dire que « d'un autre côté le synchronized a ses limites » ?

ste repompe des pthread     Condtion, trylock, etc, tout y est

tiendre http://boost.org/libs/thread/doc/index.html
et pour les pthread, y a les man ou un petit aperçu ici http://www.llnl.gov/computing/tuto [...] /MAIN.html

oui. je pense qu'une fois que c'est expliqué et placé dans un context où la remarque a un sens, on peut tout à fait le dire

ou alors tu me prends pour plus bête que je ne le suis, non   ?
note que dès ma premiere réponse après la petite phrase, j'ai cité ces 2 bibliothèques, mais comme tu connaissais pas, ben j'ai du prendre 1-2 exemples.

tu peux voir ici que ces packages existaient déjà (donc surement implémenté en utilisant synchronized). La version du JRE 1.5 n'est qu'une standardisation de ces classes.

ben non je vois pas le rapport...
 
Je te prend pour quelqu'un qui sort des petites phrases assasines sans apporter de justification. Un trolleur quoi
 
là t'avoueras qu'il aura fallu te pousser pour que tu daignes apporter un minimum de précision ...
en plus, tu verras dans mon dernier post qu'un package qui existait déjà implémentait les mêmes fonctionnalités, et ca ne pouvait utiliser en interne que les mécanismes de base de la synchronisation en java : synchronized, wait, notify.
 
On doit certainement pouvoir trouver les sources si l'implémentation t'intéresse ...

bah moi, je connais les primitives de Java, je supposais résonnablement que tu connaissais pthread, boost. et non.

 
jprefererait effectivement
c 'est une des choses qui m a poussé vers jython justement: avoir un minimum de modification a faire dans le corp du prog java et c'est ce que j'ai fait...
 
 

non ... et alors ?
 
et depuis quand on estime ce que les autres connaissent à partir de ce qu'on connait soi.  
 
mais putin ! cette discussion ne mène nul part !!!
j'ai essayé de le transformer en quelque chose de constructif, visiblement y a pas moyen.

 
en le qualifiant de trolleur ?

nan, après ... quand je lui demandais d'expliquer et que j'apportais de mon côté des informations supplémentaires ...
 
quand a sa renommée de trolleur, il l'a mérite amplement. Va faire un tour sur les topics java auxquels il a participé

mais qu'est ce que tu racontes ? ça fait un moment que y a plus d'aggrésivité dans mes postes et toi tu prends toujours tout de travers. comme je l'ai déjà dit, après ma phrase j'ai pris en exemple 2 bibliothèques, et tu me réponds direct que je raconte n'importe quoi et n'argumentes pas. si t'avais dit "je connais pas, qu'est ce que tu veux dire ?", on en serait venu directement aux derniers messages, et j'aurais pas mis 2 pages à réaliser que tu ne savais pas de quoi je parlais. n'étant pas un programmeur java, ni ada, ni perl, ça ne m'empeche pas d'avoir une culture et de connaitre les solutions pour la programmation concurrente dans ces langages  

proverbe à la con : on ne croit plus le menteur quand il dit la vérité.

 
et l'existence du package dont je t'ai filé le lien remet un peu en cause ce que tu affirmais non ?

je ne suis pas un menteur :  je ne sais pas si tu as remarqué, mais je ne suis pas un rigolo, même si je viens t'embeter sur les trus java, il me semble que je ne parle pas pour ne rien dire. tu dis troll, je dis discussion.
 
-> pas vraiment en fait. analogie : en C et C++ (mais python aussi) je peux très bien faire des threads, etc, en interagissant directement avec les fonctionnalités bas niveau de l'API (comme syncrhonized quoi, fonctionnalité de base du langage), mais si je veux faire que choses de haut niveau et des controles fins, je passe par une bibliothèque (comme celle que tu as donnée)
(python : de thread -> threading)

au fait, si je dis pas de bétise, ca ca permet de faire de l'acquisition avec attente nan ?

ben donc je comprend pas ta remarque ... pourquoi tu dis que ca a ses limites puisque finalement on peut faire la même chose  

ça te permet d'essayer d'acquérir le mutex, et si au bout d'un temps donné ce n'ai toujours pas le cas, ça échoue

ben oui. C'était pas ca que tu voulais dire ?

oui

bon, ben donc tu vois que c'est pas si limité que ca

ben je disais que l'emploi de synchronized nu (on a jamais vu un mot clef aussi long ) est limitant. d'ou la nécessité de bibliothèques. ok?