Jean B a écrit 740 commentaires

Un worker est un thread indépendant.
Quand tu l'initialize tu lui passe l'URL d'un fichier Javascript et il se charge de le télécharger et l'executer. Il n'est pas possible de l'initializer avec une fonction.

Ensuite le seul moyen de communiquer avec lui c'est de lui envoyer des messages. Ces messages seront copiés, donc non il n'y a pas moyen de partager des variables entre workers.

Autrement dit il n'y a aucune mémoire partagé entre les différents thread (le principal et le/les Worker). Donc tu ne peut pas tomber dans les pièges classiques des applications multithreads. De plus il faut comprendre que ça implique que les workers ne peuvent pas directement modifier le DOM.

Àmha, la seule application pratique des workers c'est de passer des taches CPU intensives en arrière plan. Bref c'est franchement pas pour tout le monde.

Est-ce qu'il est possible d'utiliser les « green threads » ET les pthreads ?

Pas vraiment. En fait la bibliothèque standard de ruby expose simplement une class Thread sans préciser d'implémentation. Le fait que ce soit implémenté avec des green thread, ou des pthreads et un GIL dépend de quelle implementation tu utilise. YARV (implémentation "de référence" de Ruby >= 1.9) à fait ce choix. JRuby par exemple implémente ça avec des trhead Java sans GIL ce qui n'est pas sans poser des problèmes avec les librairies non "thread-safe"

Pour ce qui est du reste de ta question je dois avouer que je ne suis pas suffisamment calé en threads pour te répondre avec certitude. Mais ce dont tu parles me rappelle les Fiber: http://www.ruby-doc.org/core-2.0/Fiber.html

Oui c'est exactement ça. D'ailleurs en Ruby

"My String".to_sym

Est un alias de

"My String".intern

Oulà attention ! Les Symbol ne sont pas que des String immuables.

Les Symbol sont également des "singletons". Il t'es garanti qu'une seule instance d'un même symbol existe. Si tu crée deux symboles identiques la seconde instantiation te renverra en fait la première instance.

Jusque là rien de grave. Par contre ça implique que les Symbol ne sont jamais déalloués par le GC. Autrement dit il ne faut jamais créer un symbol à partir d'une entrée utilisateur sans quoi tu t'exposes à un déni de service.

Oui et non. Le global lock est tout de même libéré lors des IO. Donc s'il n'est toujours pas envisageable de faire du calcul intensif sur plusieurs coeurs (sauf à utiliser une autre implémentation), les thread permettent tout de même de paralléliser les IO ce qui est loin d'être négligeable.

C'est moi ou tu pense vraiment que tous les autres développeurs sont des débiles profonds ?

Je n'ai jamais rencontré qui que ce soit qui utilisait une API privée sans s'en rendre compte.

C'est quand même assez limité lorsqu'on veut un peu optimiser les choses

Effectivement sur des implémentations un peu naïves de javascript c'est pas forcément très performant. J'ai plus trop le temps de chercher le lien là, mais il me semble que maintenant certaines VM arrivent tout de même à optimizer ça pas mal.

Et puis pour travailler sur une très grosse application Backbone.js en ce moment, pour être honnête quand il y a un problème de performance et que je sort le profiler, ce qui resort comme étant lent c'est principalement les accès au DOM, la seule fois ou Javascript lui même était en cause c'était de ma faute, je m'était bêtement retrouvé avec un algo en O(n!). Et même ça m'a pris un peu de temps pour m'en rendre compte car V8 faisait extrêmement bien (trop bien ?) son taf.

on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal

Non ce n'est pas mal. Il m'arrive assez souvent de faire des choses similaires. Il faut simplement connaitre le bénéfice / risque et l'assumer. Ce qui signifie en général de ne le faire qu'en cas d'absolue nécessité.

Oui mais ça c'est le problème du rigolo pas le mien.

Si son code plante et qu'il me fait un rapport de bug avec une stack trace, je verrai rapidement qu'il utilise directement une API privée et que du coup mon support il peut se le carer ou je pense.

Je développe principalement dans des langages dynamique sans notion de private (Python, Javascript) ou bien où elle est très facilement contournable (Ruby), et crois moi ton "9 fois sur 10" c'est absolument pas ce que je constate.

Et tu vas faire quoi contre ton collègue qui n'en a rien à foutre et qui va aller directement passer la méthode en public dans le source ? Tu reste derrière lui à regarder au dessus de son épaule toute la journée pour l'en empêcher ?

Ça me rappelle une citation:
"We are all consenting adults here" - Guido

Mouarf.

Il n'est pas nécessaire que le language fournisse un mécanisme de public/private pour faire de l'encapsulation. Tu peux parfaitement le faire par convention, comme par exemple préfixer tes attributes privés avec un underscore.

Smalltalk par exemple n'a pas de mécanisme de méthodes privés, il n'empêche qu'il est considéré comme un des langages fondateurs de la POO. Python non plus, et pourtant n'importe quel Pythoniste peut te montrer à quel point il est bien plus orienté object que Java ou C++.
L'encapsulation c'est plus une "bonne pratique" de développement qu'autre chose.

Ensuite tu peux tout à fait faire de l'encapsulation en Javascript, il suffit de se sortir les doigts: http://javascript.crockford.com/private.html

Comme quoi quand Crockford parle de: "the world's most misunderstood programming language", il a part tord, mais visiblement on pourrait aussi parler de "the world's most misunderstood programming concept" à propos de la POO…

Rassure moi, c'est un troll ?

s/immutable/immuable/

Comme exemple j'aurais plus pensé au fait qu'il stocker la taille des tableau dans les boucles for. À priori j'aurai pensé que la différence est négligeable mais ce n'est pas tout à fait le cas, surtout sur certaines VM comme JSKit: http://jsperf.com/forloop42

Évidement rien n'empèche de faire cette optimisation systématiquement à la main en Javascript. Il faut juste être rigoureux…

Là l'article n'est pas clair il ne mentionne pas le vecteur d'entrée de ce virus.

C'est un applet Java dans une page Web.

Il demande effectivement les droits mais même si on ne lui donne pas il arrive tout de m^me à infecter la machine http://www.f-secure.com/v-descs/trojan-downloader_osx_flashback_i.shtml

Et je pense qu'il est important de préciser que c'est essentiellement une vulnérabilité de Java: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3544

Effectivement dans des languages comme C, les goto peuvent parfois être salvateurs, principalement dans la gestion des erreurs: c.f. http://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c/

Mais bon PHP est censé supporter les exceptions, qui répondent bien mieux au besoin.

Ok donc ça signfie que dans ce cas la fermeture possède une référence vers la portée qui contient i plutôt que vers i directement ? Autrement dit, les environnements des closures de python sont mutables.

On peut dire ça comme ça. Dans les langages dynamiques comme Python, JavaScript et Ruby les closure gardent un accès à la frame ou elles ont été crée.

Ce qui est confusant dans l'exemple plus haut c'est que la boucle for ne crée pas sa propre frame, mais si on réécrit un peut l'exemple:

callbacks = []

def add_callback(i):
    callbacks.append(lambda: i)

for i in range(3):
    add_callback(i)

for c in callbacks:
    print c()

Cela marche comme attendu.

les types builtins sont capturés par référence alors qu'ils sont passés par valeur aux fonctions

Non non, ils sont passés par référence, seulement ils sont immuables, c'est tout.

Si on garde la compatibilité, alors on peut être accusé de demi-mesures

Oui mais quite à casser la compatibilité ascendante, Python 3 aurait put aller beaucoup plus loin. Entendons nous bien, je suis tout à fait d'accord sur le fait que Python 3 est meilleur que Python 2.

Mais à partir du moment ou il a été décidé de casser la compatibilité, il aurait fallut en profiter pour nettoyer le langage bien plus profondeur. Faire en sorte que la bibliothèque standard respecte la PEP-8 par exemple. Ou encore fournir plus de méthodes au types de base, remplacer certaines primitives comme len() par des méthodes.

Enfin bref, pour avoir migré du code Python 2 en Python 3 récemment, le sentiment que j'en retire est que certes c'est mieux, mais je ne suis pas certain que le jeux en valait la chandelle.

Il y a un service qui fait un peu ça en inspectant les comptes Github: http://coderwall.com/defunkt

Car l'idée à la base est que si un programe proprio utilise une bibliothèque GPL, tu dois tout de même avoir le droit et la possibilité technique de modifier la partie GPL. Ce qui est impossible avec du "link statique".

Ah mais je suis totalement d'accord avec toi. Pour ce genre de petit hack maison c'est amplement suffisant.

Ce qui me gêne c'est ton argumentation:

Ah... faudra expliquer a l'équipe de Facebook que PHP n'est pas fait pour du système...

Puis tu donnes le lien de la dépêche qui parle de HipHop PHP. C'est quoi le rapport entre HipHop et le fait que Facebook utilise PHP pour des applications système ?

Il dit qu'il voit pas le rapport...

D'ailleurs Facebook qui est sans cesse utilisé comme exemple de "PHP ça marche" ne l'utilise que pour ce quoi il est conçu: un moteur de templates.

Surtout pas de programmation système: juste un peu de lecture
(entre autre hein...)

De plus pour autant que je sache une fois compilé le type exact est perdu, seul sa taille est encore déductible.

Je ne suis pas expert ès C mais vu que l'exemple donné est du code à destination du préprocesseur ( #define ) je dirais que ça ce passe avant la compilation.

Oui, si à terme l'API authorize à poster des commentaires etc, alors on pourra développer des clients natifs pour linuxfr.