nud a écrit 906 commentaires

C'est un peu comme les poudres à lessiver, aussi.

À moins que tu ne parles de tâche ?

J'ai trouvé ceci en belgique:

http://www.gdb.be/FR/bureaux/stations-de-travail/table-assis-debout.htm
C'est une table réglable en hauteur électriquement.

Malheureusement le site en question est plutôt orienté entreprises et je n'ai pas trouvé de prix.

Déjà c'est mal parti, les référendums sont illégaux dans plusieurs pays de la zone euro, à commencer par la Belgique.

Potentiellement ces outils d'installation propres à chaque langage devraient être capable de produire directement un paquet pour chaque distribution, qui un deb, qui un rpm, etc. Il suffirait qu'un ou quelques courageux s'y colle! (Comme toujours, vous me direz!)

Oui, le problème conceptuel étant la séparation entre packaging et code. Si tu avais lu les liens du post avant, tu aurais vu que le problème réside dans le fait que "gems" est intrusif (les gens utilisent l'api gem directement dans le code) ce qui fait que le code en question ne peut plus être installé indépendamment de gems. Comme je le disais, le même problème s'est posé avec setuptools. Sans cela, pas besoin de gems, donc pas de problèmes de packaging.

L'autre problème qui fait qu'un paquet debian (ou redhat, ou arch, ou n'importe quelle autre distro) ne peut pas fournir directement un fichier gem est que les gestionnaires de paquets des distributions sont faits spécifiquement pour éviter l'installation de plusieurs versions mineures successives de la même lib car cela ne sert à rien et est contre-productif. À l'opposé, les gems obligent à l'installation de versions mineures différentes dans des dossiers différents, en fonction de ce qui est demandé par les applications.

(bon, à strictement parler, on pourrait s'amuser à travailler comme pour le noyau linux avec des paquets libfoo-ruby-2.2.3, libfoo-ruby-2.2.6, etc, mais avouez quand même que sailamert)

C'est justement tout le noeud du problème. La guéguerre qui a opposé Debian et les rubyistes, c'est un conflit entre administrateurs et développeurs.

En l'occurence, le système des gems ont été faites par des développeurs, pour des développeurs, et lesdits développeurs n'ont rien à caler du fait que d'autres non-développeurs ou d'autres non-rubyistes essaient d'utiliser le code. Ceux qui veulent utiliser un projet ruby n'ont qu'à apprendre à se servir de ruby et de son écosystème.

De l'autre côté, APT a été fait par et pour des administrateurs systèmes, qui veulent pouvoir utiliser $project sans se soucier du langage avec lequel il est programmé. Après tout c'est un détail d'implémentation, et je ne vois pas pourquoi je devrais apprendre tout ce qui a trait à ruby, gems ou whatever juste pour utiliser, par exemple, redmine ou tracks. apt-get install redmine tracks devrait suffire.

Le pire est que les deux points de vue ne sont pas forcément incompatibles: une histoire similaire a eu lieu dans le monde python avec setuptools et les "eggs", qui, comme les gems, sont très intrusifs même au niveau du code et ne sont pas "compatibles" avec une distribution des packages ala APT. Le problème a été résolu avec l'évolution vers "pip".

En fait, en lisant la page du wiki de Debian à propos de RubyGems il semblerait qu'il soit en fait possible pour les rubyistes de rendre leur code packageable avec un peu d'attention, un peu comme la dualité distutils/setuptools de python.

La teneur de ma question était donc: 'est-ce que la communauté ruby a gagné en maturité ou est-ce que ce dernier changement consiste encore à montrer le mauvais doigt aux distributions?'

Voilà qui va ravir toutes les distributions... Est-ce que les problèmes inhérents aux Gems ont été corrigés ?

En l'occurence, c'est un comportement erroné de la glibc, sauf si on considère que toutes les variables pouvant être touchées par des threads devraient être marquées comme volatile (ce qui niquerait quasi toutes les optimisations alors qu'il est plus simple de juste bloquer ces optimisations au niveau des mutex).

Ce n'est pas vraiment un effet de bord, il n'y a aucun effet sur le code appelant ou sur l'extérieur. Et la définition d'une fonction pure est respectée dans le cas de la mémoisation: la valeur retournée ne dépend que des arguments.

Oui c'est aussi pour ça que je n'ai pas cité printf dans mes exemples.

Je soupçonne que le patch de la libc a été fait automatiquement par un script quelconque et printf n'a pas vraiment d'argument callback défini, c'est dans le vararg.

Dans tous les cas je pense que quel que soit l'ordre dans lequel tu appelles la fonction sinus, le résultat sera le même. De toute façon, la seule contrainte d'après la documentation est que la fonction ne doit pas retaper dans l'unité de compilation courante pendant son exécution (c'est pourquoi cet attribut a été appliqué à toutes les fonctions de la glibc qui n'utilisent pas de callback).

Calls to external functions with this attribute must return to the current compilation unit only by return or by exception handling. In particular, leaf functions are not allowed to call callback function passed to it from the current compilation unit or directly call functions exported by the unit or longjmp into the unit. Leaf function might still call functions from other compilation units and thus they are not necessarily leaf in the sense that they contain no function calls at all.

Le problème avec les fonctions pthread étant que, justement, elles peuvent, indirectement, retaper dans l'unité de compilation courante, même sans callback.

Ça implique aussi que toutes les fonctions mathématiques sont "leaf", car elles sont "pure" (la sortie ne dépend que des arguments et il n'y a pas d'effet de bord visible, les opérations de cache interne, etc ne comptant pas). C'est aussi le cas de strlen que je citais précédemment.

Many functions have no effects except the return value and their return value depends only on the parameters and/or global variables. Such a function can be subject to common subexpression elimination and loop optimization just as an arithmetic operator would be.

Par contre, des fonctions qui ne dépendent que de leurs arguments mais qui ont un effet de bord (comme fputs et consorts) ou qui conservent un cache interne (comme strtok) sont "leaf" mais ne sont pas "pure".

Je doute qu'un jour une fonction comme sin() ou strlen() attrappe un effet de bord.

Et sans C, pas d'ObjectiveC, donc pas de *Step ;-)

On peut troquer les bisounours pour des ewoks?

Mh, j'avais mal lu, j'avais lu "les hommes dans les champs et les femmes à la cuisine", et j'aime bien le grand air.

Ah les conventions sociales... Les mêmes qui voulaient il y a pas si longtemps que les noirs soient dans les champs et les femmes à la cuisine, on parle bien de ce truc?

C'était plutôt pratique, note.

Le mathématicien nobel posthume compte?

pourquoi ne pas tout simplement revenir au session manager (gdm, kdm, xdm, lightdm, whatever) comme quand on change de session ? Ne serait-ce pas là le plus sécurisé ?

J'ai lu hier sur ce site que Steve Jobs était à l'informatique ce que l'inventeur de l'abas-jour est à la lampe. Viendrait-on de perdre Edison ?

Bha tant qu'à faire on pourrait aussi utiliser DNS, un peu à la façon de ce qu'on fait pour les numéros de téléphone avec e164.arpa. et e164.org.

Je suis pas certain que dans le contexte de code intégré dans du XML/HTML, la syntaxe du python, qui dépend des espaces, soit la plus adaptée.

tout ceux qui chètent du materiel pour leur Hifi qui a un port usb pour y brancher sa clef usb chose qu'on trouve actuellement sur les télévisions, les platines DVD, les platines BR, les autoradio (le transpondeur FM c'est pas toujours génial niveau qualité d'écoute), les chaine Hifi, …
les gens ont du matos "made for iPod" qui fonctionne très bien (et ceux qui n'ont pas le "made for iPod" alors qu'ils veulent brancher leur iPod sont une masse ridicule aussi).

C'est clair, je vais changer de bagnole pour en acheter une "made for iPod", alors que l'autoradio fonctionne très bien avec n'importe quelle clef USB ou n'importe quel player MP3 "à la con".

C'est souvent comme ça: ce sont les techniques qui font tourner la boite mais ce sont les commerciaux qui en recoivent le mérite.

davical ou sabredav ?

IE6 supporte @font-face, c'est juste que ça utilise le format EOT et que donc sailamert.

J'ai déjà fait ça en un temps où on pestait sur les autres navigateurs parce que IE6, qui venait de sortir, avait une guerre d'avance...

CSS, @font-face, tout ça.