Reprise du message précédent :
Livin' in a GNU world \o/
http://pix.nofrag.com/e4/dc/c61f31 [...] 58738.jpeg

c vrai ca va vachement ameliorer ton dev et fixer les bugs ton super graphe antialisé  

je reviens de la demeure du choas
 
 
c'est assez particulier, mais dans l'ensemble plutot reussi ( si on aime le morbide et la destruction )

La maison avec des portraits de Mahmoud Ahmadinejad dedans?

http://www.amazon.fr/gp/redirect.h [...] ative=6746

entre autres  
http://www.flickr.com/photos/7818367@N06/

bon, l'affaire se présente assez mal pour me faire débannir de discu, la modération semble assez "homogène" y compris aux plus hautes instances. Lapidaire, à charge, pas de confrontation, pas d'inquisition, pas de chronologie, pas de contexte.

edit : et tout en huis-clos, biensûr.

tu avais été banni pour quel motif ?

"Cadeau de la part de l'équipe de modération."
 
J'ai plus précisément le truc en tête, j'avais dû dire un truc du style "plus on s'attend à ce qu'un mec avec un pouvoir de nuisance soit con et plus il le sera, mais l'inverse n'est pas vrai".

ça je crois :
http://forum.hardware.fr/hfr/Discu [...] #t10701286

'tain il me fait halluciner, le père Torvalds.
Faut voir le numéro que c'est: limite aggressif dans ses posts, mais faut reconnaitre qu'il a des idées intéressantes.
http://selenic.com/pipermail/mercu [...] html#start
(à propos de l'utilisation des tags dans une gestion de conf)

prems

deuz'

C'est pas mal Sunshine

ca casse pas trois patte a un canard ton 'insulte'  
 
et dire que je trouvais les modo de achat vte et jv un peu cowboy

une fois j'ai dit "bide" dans blabla, ca fait plus d'un an que je suis TT...
Comme c'etait le topic d'un modo, ca n'a pas plus et voila

Pah, si tu veux de l'aggressif faut aller voir Theo de Raadt pas Linux

Hans Reiser il est violent, pas aggressif

bonjour

Rhhhha oui, mais qq qui a une page perso comme celle-ci et qui nomme ses chats Galileo et Kepler ne peut pas être tout-à-fait mauvais.

Par contre, pour Hans Reiser, je ne savais pas que c'était un vrai malade

J'ai jamais dit qu'il était "(tout-à-fait) mauvais espèce de sale moinsmoins, j'ai dit qu'il était aggressif (sur les MLs)

Tiens question pour les élitres Java: comment vous créeriez une Stack immutable en Java?
 
add, peek et size sont faciles, mais classiquement un pop() retourne l'équivalent de peek(), donc il faudrait renvoyer un tuple (T, Stack<T> ).
 
Or Java n'a pas de tuple, donc on se retrouve à renvoyer quoi, objet spécial? Ou alors on est baisé?

tu wrappes et t'as pas le choix que de créer une interface Pair, par contre je te suggère de ne pas la génériciser. Donc fais plutôt un PopResult.

 
 
AHAHAHAHAHAH

Ok, c'est ce que je craignais

si tu veux faire du style fonctionnel, tu prends un langage où c'est l'utilisation courante.

Je me posais plus la question rapport aux avantages de l'immutable dans un contexte concurrent en fait.

sur une pile, je vois pas trop dans quel cadre.

C'est la coupe des piliers de bars de Besac ?

QUestion con: c'est quoi une pile immutable ?

ouais

edit: c'était ça  http://www.sport-evenements.com/raid/

Ah oui, évidemment. J'ai quand même un peu de mal à imaginer un cas réel d'utilisation d'un tel concept. Parce que dans un contexte concurrentiel, je vois pas bien ce que ce truc va apporter vu que si une pile est partagée, elle sert à échanger des données, il faut donc une notion de synchronisation derrière.

'tain t'as passé un bon w-e, toi !

bof, 2h de course, pour une journée complète de grillée. Sachant qu'on était 2, j'ai du transpirer une heure. Par contre je me suis fait une excellente descente en VTT, il était trop bon le parcours.

Le même que celui d'une liste chaînée, puisque c'est fondamentalement la même chose

Whut? Absolument pas, tu peux utiliser des piles pour faire communiquer tes processus/threads, mais ça ne veut pas dire que toutes tes piles serviront à ça
 
Et d'ailleurs tu utiliserais plutôt des files que des piles

Bon, après réflexion, c'est un peu confus dans ma tête, tout ça. Le seul intérêt que je vois à cela est d'éviter une synchronisation. Hors, que se passe-t'il pendant la copie de la pile ? Qu'est-ce qui empêche un thread de tenter de lire/écrire la nouvelle pile pendant la recopie ? Et puis quel est l'intérêt, parce que si c'est pour gagner en vitesse par rapport à des synchronized, alors ça veut dire qu'on va remplir la mémoire à toute allure (sinon ça n'est pas la peine). Au bout d'un moment, la recopie va coûter aussi cher qu'une synchronisation, ou alors c'est le GC qui va se mettre en route.

C'est vrai, mais si ça n'est pas pour la partager entre threads, ça sert à quoi qu'elle soit immutable ?

chais même pas ske c'est une pile
ça doit être ça la différence entre un expert

Le principe d'une pile immutable est le même que celui d'une liste chaînée, si on y ajoute un objet (en tête), on crée simplement le nouvel objet (enfin une nouvelle node/cons cell), mais on ne change pas le reste de la pile.

L'ajout d'un objet en tête d'une pile immutable se fait en O(1)

Il n'y a pas de recopie, sauf si on ajoute un élément en fin de pile.

Et un thread peut lire la pile mais pas l'écrire puisqu'elle est immutable

C'est pas une question de vitesse, c'est une question de correction. Quand on travaille uniquement avec des données immutables, il devient impossible de wedger des objets (qu'un thread A foute un objet dans un état incorrect juste au moment ou un thread B veut y accéder) et beaucoup plus difficile de créer des race conditions, l'intérêt premier n'est absolument pas les performances (mais fondamentalement ça peut marcher aussi, comme je l'ai précisé on a pas tant de copies que ça si le datatype est bien fait et qu'on l'utilise dans le cadre pour lequel il est prévu)

Pas partage, communication, tu peux partager des données sans les utiliser comme des moyens de communication, et c'est dans ce cadre là que je me posais la question (tout simplement parce que plusieurs de tes threads peuvent avoir besoin des mêmes objets pour démarrer leurs traitements)

VOS GUEULES §§§§ /FOU/
 
 
 
ah non c'est bon c'est déjà fait

ah ok merci