jeberger a écrit 134 commentaires

Quant au non-sens qu'est la barre de défilement GTK3, je cherche encore le coupable.

Heureusement, il y a des thèmes qui rétablissent une barre de défilement potable (par ex. BlueMenta). Maintenant s'il pouvait y avoir quelque chose de similaire pour le sélecteur de fichiers…

C'est d'ailleurs plus ou moins confirmé quand on regarde les arguments avancés par ceux qui expliquent pourquoi ils ont choisi Git ou Mercurial.

Raisons généralement avancées pour choisir Git plutôt que Mercurial :

• GitHub est meilleur que Bitbucket (possible, mais ne dit rien sur git vs mercurial),
• Tout le monde utilise git (+github), donc il sera plus facile de trouver des contributeurs en utilisant git (raison invoquée pour CPython).

Raisons généralement avancées pour choisir Mercurial plutôt que Git :

• Mercurial est supérieur techniquement (cf. par ex. pourquoi Facebook a choisi Mercurial alors qu'ils avaient un a priori favorable pour Git qu'ils connaissaient mieux).

PS : le Trolldi, c'est permis ;)

ce n'est pas la désallocation qui prendra énormément de temps si ce sont des structures à durée de vie longue, donc chipoter sur le temps de désallocation, je ne comprends pas bien.

Je compare ce qui est comparable, donc le temps passé dans la désallocation par rapport au temps passé dans le GC. Le reste du temps de traitement sera le même que tu utilises où non un GC.

Python n'utilise pas de garbage collector mais un compteur de référence

D'une part un compteur de référence est une forme de garbage collector (*), d'autre part Python a un « vrai » GC pour gérer les cycles, qui peut être contrôlé avec le module gc :

import gc
# Empêcher le GC de se déclencher automatiquement :
gc.disable()
# Déclencher manuellement un cycle de collecte :
gc.collect()
# Ré-activer le GC :
gc.enable()

(*) Un garbage collector est un mécanisme qui libère automatiquement la mémoire quand elle n'est plus utilisée, selon cette définition un compteur de références est un garbage collector.

un GC a un coût, en terme de performance,

Inexact. En fonction de la façon dont ton application alloue et désalloue la mémoire, un GC peut s'avérer plus performant qu'une gestion manuelle. En particulier si tu as des structures profondes (arbres ou listes) que tu modifies peu au cours de leur vie (i.e tu les alloues, tu les utilises sans les modifier, puis tu les désalloues). Dans ce cas, un bon GC pourra tout désallouer d'un coup alors qu'une gestion manuelle t'obligera à désallouer chaque nœud de ta structure.

en terme de ressources ( 2x à 8x la quantité de mémoire ),

Vrai, du moins tant que ton appli n'a pas de fuites mémoire. C'est pour cette raison que les langages à GC ne perceront jamais dans l'embarqué (je parle ici du vrai embarqué, celui où les ressources sont limitées, pas des ordiphones qui sont plus puissants que le PC que j'avais il y a cinq ans).

en terme de déterminisme, en terme de latence.

Faux. Il existe des GC temps réel (donc qui garantissent une latence max). Bien sur, on n'a rien sans rien et ces GC sont généralement encore plus gourmands en mémoire que les autres. Note que de toutes façons ceux qui développent des systèmes vraiment critiques en termes de performances (jeux, par ex.) évitent les allocations dans la partie critique (aussi bien avec un GC, qu'avec malloc) car ni l'un ni l'autre n'ont de performances garanties.

Les GC ne sont pas la panacée mais ils ont leur utilité, en particulier :

• lorsque réduire le temps de développement est plus important que d'économiser quelques cycles CPU ou quelques MB de RAM (un développeur coûte beaucoup plus cher que d'acheter une machine plus puissante ou de répartir la charge entre plusieurs machines),

• lorsque de toutes façons le système est tellement critique qu'aucune allocation n'est faite dans la boucle principale. Dans ce cas rien n'empêche d'utiliser un GC pour les allocations qui, par définition, auront lieu en dehors de la partie critique.

Euh, darktable utilise gtk…

Tu veux dire comme « View → Layout → Vertical view » ?

L'extension Tree-style tab semble fonctionner avec Palemoon, mais il faut récupérer une vieille version (0.14.2014051101.1)

En fait, c'est presque le contraire : une fois publiée une invention n'est plus brevetable en Europe, quel que soit le pays ou la langue de publication et quelle que soit la personne qui voudrait déposer (article L611-11 du code de la propriété intellectuelle). Aux USA, une invention reste brevetable pendant un an après la publication, mais seule la personne qui l'a publié peut déposer un brevet (titre 35, chapitre 10, section 102 du code des États-Unis)

Tu as oublié Progressive. Si tu veux faire de la compression avec pertes avec FLIF, il suffit de couper la fin du fichier à partir de l'endroit qui correspond à la taille que tu veux et comme le format est progressif, tu obtiendras une image avec pertes. Voir le paragraphe « Lossy compression » sur cette page.

Reste à voir ce que ça donne en termes de qualité par rapport aux formats qui ont nativement des pertes (et pour le mode sans pertes, il faudrait aussi comparer avec JLS)…

Erreur 404…

Sinon tu rentres manuellement 2 cellules, et ensuite tu sélectionnes les deux et tu étends avec le petit carré.

« le monde autour d’eux répète à l’envie » → « le monde autour d’eux répète à l’envi, » dans ce cas précis, « envi » ne prend pas de « e »

Alors un grand MERCI aux admins/dev/… pour le fantastique boulot que vous faite pour faire tourner le site.

l'appel au Boycott est interdit en France

Pas exactement, l'appel au boycott en raison de la race, de la nationalité ou de la religion est interdit (par l'article 24 de la loi du 29 juillet 1881 qui interdit l'appel à la discrimination, précisé par l'article 225-2 du code pénal qui précise que « entraver l'exercice normal d'une activité économique » constitue bien une discrimination). En revanche, le boycott pour un autre motif reste autorisé.

Ou vers /…

2001 n'était pas vraiment l'époque de ce genre de produit

Quoique…

Tu peux ajouter :

• les brevets sont évalués par des gens qui n'y connaissent rien en technique et sont complètement incapables (*) d'avoir une appréciation réaliste de l'originalité du brevet. D'ailleurs, quand on voit le premier jet rédigé par un juriste qui a pourtant discuté face à face avec l'inventeur et pu poser toutes les questions qu'il voulait avant et pendant la rédaction, on se demande comment l'examinateur pourrait y comprendre quelque chose en n'ayant accès qu'au texte déposé,
• les brevets sont censés favoriser la diffusion de l'information en encourageant la publication, mais en pratique le texte de la plupart des brevets est incompréhensible pour un ingénieur moyen et donc complètement inexploitable, et les quelques inventions intéressantes sont noyées dans la masse des brevets triviaux. Par conséquent, les brevets échouent lamentablement à leur objectif premier.

Le problème principal concerne les politiques. Pour eux, le nombre de brevet déposé est un indicateur d'innovation ! On peut déposer un brevet, ou des dizaines pour la même chose (il y aurait 150 brevets sur la manière d'attachée le teflon sur un poêle Tefal).

Tant que les politiques seront autant ignare en science, on n'en sortira pas. Je croyais que la France était un pays d'ingénieur, mais c'est faux. La technique, c'est sale pour les élites. Les meilleurs vont dans la finance, ou les postes de direction.

Hélas !

(*) Comme dit dans un message précédent, ce n'est pas une question d'intelligence mais juste de formation et d'expérience. Quand le principe des brevets a été imaginé pour la première fois, un intellectuel avait de solides bases dans tous les domaines et donc en particulier un juriste avait de bonnes notions de technique. Aujourd'hui tous les domaines sont devenus si complexes que nous sommes tous beaucoup plus spécialisés et que les juristes ne peuvent pas être assez pointus dans tous les domaines techniques. L'Île mystérieuse de Jules Verne ne pourrait plus marcher maintenant.

Je ne vais pas t'indiquer tout de suite les limites que j'y vois, peut-être en as-tu une idée ? (avec une jurisprudence, des exemples concrets plutôt qu'imaginés, cela serait plus facile d'argumenter)

Malheureusement les exemples concrets que j'ai se sont réglés à l'amiable donc je n'ai pas de jurisprudence ni de documents publics, mais ni nos avocats ni ceux de nos adversaires n'ont jamais utilisé le fait qu'un brevet concerne du logiciel pour tenter de l'invalider.

la contrefaçon concerne le droit d'auteur, il n'y a pas de lien de cause à effet entre brevet et droit d'auteur, ce ne serait pas de la contrefaçon, éventuellement un non respect du brevet (complètement hypothétique pour du logiciel seul).

Le terme légal pour « violation d'un brevet » c'est « contrefaçon ». Cf le dictionnaire juridique

non, le logiciel demeure non brevetable. La partie technique est éventuellement brevetable, comme auparavant […], c'est le non-logiciel qui est breveté àmha.

Que ce soit le logiciel lui même ou le procédé technique qui est breveté, au final le résultat est le même : le détenteur du brevet peut exiger des royalties ou t'interdire de distribuer ton logiciel qui implémente le procédé breveté.

(mais bon, s'exécuter sur un processeur est le propre d'un algorithme : que ce soit sur papier, sur machine de Turing, dans un processeur ARM, dans un processeur CISC ou RISC…)

C'est là qu'il y a une distinction importante : quand c'est « sur papier, » ce n'est pas sur une machine et donc ce n'est pas couvert par le droit des brevets, car alors on parle du logiciel « en tant que tel. » Dès que c'est sur une machine, on parle de la combinaison du logiciel et de la machine donc ce n'est plus du logiciel « en tant que tel » et c'est brevetable.

Ce n'est pas la même chose que de voter pour une directive qui les interdise explicitement

ce qui n'est pas restreint explicitement reste permis ;-) les brevets logiciels sont donc bien illégaux en Europe

Euh, non justement : les brevets logiciels ne sont pas restreints explicitement (à condition que le brevet ne concerne pas le logiciel seul) et donc ils sont permis.

je suis en désaccord avec ta conclusion (que je cite) en pratique et dans les faits le brevet logiciel se porte très bien en Europe : si encore tu avais précisé, "pour une entreprise cherchant à exporter là où les brevets logiciels s'appliquent en dépit du bon sens

Non, je parle de mon expérience personnelle, dans mon entreprise et en France. Les brevets logiciels ont pesé exactement le même poids que les autres dans les négociations. Bien sur, les brevets en question sont rédigés pour inclure « une machine qui exécute un programme mettant en œuvre le procédé » mais au final le résultat est le même : les caractéristiques revendiquées sont purement logicielles mais comme le brevet précise que le brevet couvre une machine, il est valable.

Note au passage que les brevets s'appliquent sur tout le cycle de vie du produit, pas uniquement là où il est vendu. Par conséquent le droit du pays dans lequel tu fabriques est tout aussi important que le droit du pays où tu vends

cela ne veut pas dire qu'ils sont idiots, ils font avec les textes de loi qu'on leur a pondu. En tant qu'humains, ils se rendent bien compte de la vaste fumisterie que pourraient représenter les brevets logiciels, ils ont aussi un cerveau tout comme toi et moi

Je n'ai jamais dit ni pensé que les juristes sont idiots. En revanche, je pense pas qu'il se rendent compte de la fumisterie que représentent les brevets logiciels. Ça n'a rien à voir avec l'intelligence, c'est juste une question de domaine de compétence et d'expérience. Toi et moi on se rend compte que les brevets logiciels sont une fumisterie (1) parce qu'on connaît bien le logiciel de façon concrète, qu'on en a écrit, et qu'on se rend compte des tenants et aboutissants. Pour un juriste, c'est beaucoup plus abstrait parce qu'il voit le logiciel de l'extérieur sans vraiment savoir comment il marche et sans référence pour évaluer si quelque chose est difficile ou pas.

(1) En fait, il y a quelques années je pensais comme toi que le brevet logiciel est une fumisterie. Aujourd'hui et compte tenu de ce que j'ai vu dans les négociations auxquelles j'ai participé, je pense que le système des brevets est une fumisterie quel que soit le domaine d'application.

L’ensemble du logiciel ne sera souvent pas breveté. Seule l’invention technique découlant du logiciel pourra être couverte. Autrement dit, ce seront uniquement les éléments techniques utilisés par ce logiciel qui seront brevetés.

Là tu coupes les cheveux en quatre. Effectivement, légalement ce n'est pas le logiciel lui-même qui est breveté mais le procédé technique mis en œuvre par le logiciel, mais au final en pratique ça revient au même : si quelqu'un utilise une machine qui met en œuvre le procédé technique, alors cette personne est contrefactrice donc attaquable. Si quelqu'un distribue un logiciel qui met en œuvre le procédé, alors cette personne est complice de contrefaçon donc attaquable, sauf si elle peut démontrer clairement que le logiciel n'est pas destiné à être mis en œuvre : il est donc légal de publier un article académique contenant une implémentation du procédé et des commentaires sur son fonctionnement mais pas de distribuer une implémentation sous forme de programme exécutable.

Note d'ailleurs que si tu suis le lien vers l'article de loi, tu constateras qu'il est aussi dit : « Ne sont pas considérées comme des inventions […] Les plans, […] ainsi que les programmes d’ordinateurs » Par conséquent, les plans sont mis sur le même niveau que les logiciels mais personne ne prétend que la mise en œuvre de ces plans n'est pas couverte.

Toujours dans l'article de loi, il est dit : « Les dispositions du 2 du présent article n’excluent la brevetabilité […] que dans la mesure ou […] le brevet ne concerne que l’un de ces éléments considéré en tant que tel. » En d'autres termes, un logiciel tout seul (« en tant que tel ») n'est pas brevetable, mais il le devient dès lors que tu l'associes à une machine qui le fait fonctionner.

Enfin concernant le vote des députés européens du 6 juillet 2005, il faut faire attention à ce sur quoi portait ce vote : les députés ont voté contre une directive qui autorisait explicitement les brevets logiciels. Ce n'est pas la même chose que de voter pour une directive qui les interdise explicitement. Ce vote est une bonne indication d'intention mais n'a malheureusement pas interdit les brevets logiciels, il s'est contenté de maintenir le statu quo.

PS : notez que je ne suis pas juriste mais que la boîte pour laquelle je travaille est régulièrement attaquée par d'autre pour des histoires de brevets et que je participe à sa défense en tant qu'expert technique. Je vois donc comment les choses se passent et je peux vous assurer que quelle que soit l'interprétation que vous ou moi pouvons faire des textes de loi, en pratique et dans les faits le brevet logiciel se porte très bien en Europe.

Note qu'attesoro n'est pas un éditeur de .properties mais un éditeur de traductions. Le fait que les traductions soient stockées dans des fichiers .properties et qu'il faille mettre des codes \uxxxx est un détail d'implémentation et ce n'est pas là que réside son intérêt. L'utilité d'attesoro tient en ce qu'il manipule l'ensemble des fichiers de traduction d'un coup.

Je ne t'apprend sans doute rien si je te dis que les traductions sont faites avec un fichier toto.properties pour la langue par défaut et des fichiers toto_xx.properties pour chaque langue (par ex. un fichier toto_fr.properties pour le français). Dans attesoro, il suffit d'ouvrir toto.properties pour qu'il ouvre aussi les autres langues. Ensuite il vérifie que tu as bien les mêmes entrées dans tous les fichiers et il te signale les incohérences. Quand tu sélectionnes un identifiant de message, il te permet d'éditer la traduction et le commentaire pour la langue en cours, mais il t'affiche aussi le message original et le commentaire associé. Il permet aussi de passer rapidement d'une langue à l'autre en restant sur le même message.

En contrepartie, il n'est pas adapté pour éditer un fichier de propriétés génériques : il n'offre aucune facilité pour gérer la hiérarchie des propriétés, ou pour sélectionner un fichier ou une image et mettre le chemin correspondant dans une propriété par exemple (aucune idée si Eclipse ou Netbeans le font, mais ça me paraît des fonctions de base pour un éditeur de propriétés).

Le pb ne vient pas de Scala, mais des fichiers .properties de Java : ceux-ci ne peuvent contenir que des caractères ASCII, et si tu veux mettre autre chose, il faut entrer le code Unicode \uxxxx. Pour simplifier la traduction, je te recommande attesoro qui gère ces problèmes de conversion pour toi.

Cet univers est bien desservi en jeu avec des graphismes, et des musiques, de belles qualités.

J'imagine que tu voulais dire : « Cet univers est bien servi en jeu… » ? Dans ce contexte, « desservir » signifie « nuire à » et n'est pas très cohérent avec la fin de la phrase. D'ailleurs, si c'est bien ce que tu voulais dire, je ne suis pas d'accord : moi je les trouve très sympas les graphiques ;)

Sinon, belle dépêche bien complète, bravo !

Pourquoi est-ce que l'article Wikipédia de Rust indique "Appeared in : 2012" ?

Probablement à cause de la première version alpha numérotée du compilateur actuel (basé sur llvm et écrit en Rust alors que le précédent était écrit en OCaml). Cette version a été publiée en janvier 2012, soit 3 mois avant la première version numérotée de go (avril 2012 d'après l'archive des anciennes versions).

C'est sans doute lié au fait que Go est apparu 3 ans avant Rust

En fait, non: Rust a commencé à être développé un an avant Go (2006 pour Rust et 2007 pour Go) et a été annoncé officiellement un peu plus de 6 mois après (novembre 2009 pour Go et juillet 2010 pour Rust).

Sources Wikipedia Go et Rust (plus Mozilla pour le mois de 2010 durant lequel s'est tenue la conférence où Rust a été annoncé).

Grrr, j'avais essayé de rajouter un espace à la fin de la ligne précédente, je croyais qu'en markdown ça revenait au même qu'une ligne vide…