djano a écrit 1147 commentaires

Sarkozy ne comprend rien a l'informatique est aux nouvelles technologies en général.

Cette réponse:

Le logiciel libre a l'avantage de répondre à la problématique de la maîtrise des dépenses
publiques pour les établissements. Il répond également, par sa gratuité, à notre souci de
combler les fossés numériques, notamment le fossé social qui se traduit par la différence d'accès
aux outils entre les foyers modestes et les foyers plus aisés.

Montre clairement que lui et son équipe n'ont complètement loupe tous les autre avantages du logiciel libre. Tout ce qui leur importe c'est l'aspect bas coût.

Pour Hollande, je vais rester sur ma réserve et ne vais pas sauter de joie devant des déclarations pré électorales. Je me dis qu'il devrait être mieux que Sarkozy en ce qui concerne les logiciels libres, mais je me m'attend pas a être transporté de joie vers TuxLand ou vers LiMux (ou même le BSDworld tiens).

En effet, commons est compatible JDK1.4 alors que Guava a visé directement la compatibilité avec Java 5, évitant ainsi le code legacy.

Mais ça commence a changer: commons lang 3 utilise les generics.

Pour commons collections (celui que j'utilise le plus), je me suis créé une petite classes utilitaire permettant d'utiliser les méthodes de CollectionUtils, mais avec les generics. Il y a des casts sauvages par la, mais c'est pas grave puisque le code l'utilisant ne se cogne pas ce problème mineur.

Bah, un simple string replace dans Eclipse et tu peux impacter toute ta base de code en une opération.

Cependant c'est vrai que j'aimerais bien un coccinelle pour Java. J'ai commencé a bosser dessus, mais je dois dire que ça avance pas vite!

Je ne connaissais String.isEmpty(), mais c'est vrai que ça pue pas mal quand même!
Toute méthode que utilisée régulièrement doit être nullsafe.

OK, j'avoue java pourrait faire beaucoup mieux la dessus de base.

Allez, voici pour aller dans ton sens:
http://mestachs.wordpress.com/2012/03/17/dangerous-can-be-dating-in-java-joda-to-the-rescue/

[ma vie]
Je suis moi même en train de décomposer une base de code modulaire avec plusieurs milliers de classes et du code spaghetti, et bien je compatis avec eux!
[/ma vie]

Je vais pas te mentir, je me demande comment je faisais pour coder en Java avant Apache Commons :)

Depuis tout n'est que bonheur est félicitée où je me balade à coup d'interfaces bien pensées, de prédicats et de visiteurs. Bref c'est le bonheur total puisque je ne me dit pas "et m**** je dois encore écrire une pu**** de boucle for".

Mon code est plus léger (mon cerveau aussi) et je peux me concentrer sur le problème métier au lieu d’écrire ma centième boucle for de la journée.

En un mot: Miam!!!

Référence nécessaire?

Voila:

• http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:dependency_management_and_java

• http://www.gradle.org/docs/current/userguide/dependency_management.html#ssub:multi_artifact_dependencies

Ivy peut avoir plusieurs artefacts pour une seule dépendance, et ça leur plaît beaucoup.
Je ne suis pas sur de comprendre pourquoi ça leur plaît tant, ni même en quoi ça diffère vraiment de Maven.
Je ne l'ai jamais utilisé, c'est sûrement ça le problème.

 

Gradle n'ajoute rien a Ivy. Il se repose complètement dessus.
Leur avis est qu'Ivy est supérieur a Maven pour la gestion de dépendances.

120 caractères ici. Au moins il est toujours possible de faire une comparaison de texte cote a cote sans avoir besoin d'un dual-screen :)

je trouve que les libs de base sont justement plutôt complètes, surtout si on compare à celle de java qui est plutôt, souvent, minable…

Minable? Tu veux faire quoi exactement?

La lib de base offrait lors de sa sortie un nombre de fonctions largement supérieur aux alternatives multi-plateforme.

Les libs de java sont nombreuses et variées (parfois trop! C'est justement un reproche qui lui est fait) et je les vois comme un point fort du langage.

A moins que tu veuilles que Java intègre de base toute les librairies possibles et imaginables, mais je n'en voit pas l’intérêt?

Alors de quoi parles tu exactement?

Gradle m'a l'air très prometteur et il parvenait avant même sa première version a faire des choses pour lesquelles Maven a des bugs ouverts depuis belle lurette.

Le fait d'associer la facilite de Maven pour décrire les dépendances avec la possibilité d'utiliser Groovy pour faire tout ce qui n'est pas prévue de base me semble géniale. Gradle semble faire un bras d'honneur a la préconisation pour étendre Maven: écrire un plugin.
Il y a avait un plugin Groovy pour Maven mais il n'est plus maintenu.

Une petit correction de vos propos: Gradle s'appuie a fond sur Ivy pour gérer les dépendances (plus puissant semblerait-il), pas du tout sur Maven.

Bref parfois Maven me gave, mais quand je pense a Ant je suis de nouveau amoureux de Maven.
Gradle me fait rêver. C'est vraiment a essayer.

C'est la version 2.5.0 .

Il y a un petit souci dans l'annonce:

There is one new option: -W allows to force the names from being truncated.

There is one new option: -W prevents the names from being truncated.

Le reste de l'annonce est tout bon.

Bravo pour ta réactivité!

Salut,

Bravo pour ce logiciel qui améliore le bon vieux df(1) pour nous les humains :).

En utiliser [les options longues] pour dfc le rendrait incompatible avec les df(1) des *BSD

Non: utiliser les hypothétiques options longues de dfc dans des scripts rendrait les df(1) des *BSD incompatibles avec ces scripts, mais l'inverse n'est pas vrai. Si un logiciel ABC fournit X options, mais que le logiciel DEF en fournit X + Y, alors DEF est compatible avec ABC, ou dit autrement: il n'est pas incompatible.

Par exemple, df(1) des coreutils est compatible avec les df(1) des *BSD, mais les df(1) des *BSD ne sont pas compatibles avec df(1) des coreutils. Donc df(1) des coreutils n'est pas incompatible avec les df(1) des *BSD. Je ne sais pas si je suis clair.

au même titre que ne pas en utiliser rend dfc incompatible avec df(1) des coreutils.

La on est d'accord lorsque des scripts externes appellent les dites options longues.

 

De toute façon, tu n'aimes pas les options longues alors pas besoin de parler du reste puisque tu es le mainteneur. :)

Si ton but n'est pas de remplacer df(1), alors c'est ton choix (même si je trouve ça dommage :) ).

C'est ce que le titre semble indiquer: "pistes-nordiques" comme "ski nordique" :)

Je viens de voir ce commentaire:
https://linuxfr.org/nodes/90063/comments/1335237
et le suivant:
https://linuxfr.org/nodes/90063/comments/1335245

Ouf, c'est bon pour moi aussi!

J'avoue que ce serait pas mal si tout ça était un petit peu plus intégré sur une interface web unique, quitte a rediriger vers d'autres sites, ou a mettre des iframe ou que sais je d'autre.

Ça permettrait de donner plus de visibilité a OSM et son écosystème et ainsi de le renforcer.

Je ne pense pas que cela concurrencerait des services spécialisés (meilleure qualité de service, bande passante, etc.) car ils pourraient aussi être mis plus en avant sur un tel site.

Pour moi le prochain virage qui va être révélateur du futur d'OSM est la réactivité vis à vis du changement de licence imminent : le 1er Avril toute les données des utilisateurs n'ayant pas accepté le changement de licence vont être supprimée.

Hein? Qui? Que? Quoi? Ou ça? Ou est ce que je devrais avoir reçu quelque chose? Par email? Par l'interface web d'OSM?

Il me semblait avoir accepté un truc comme ça il y longtemps, genre 2 ans, mais j'aimerais en être sur.
Comment est ce que je peux m'assurer que les données que j'ai ajouté ne vont pas être supprimées?

Je te conseille ce blog: http://blog.mozilla.com/tglek/

Regarde les tags Pork et Dehydra. Je sais, ce n'est pas du tout récent, mais il y avait de gros efforts faits la dessus a un certain moment, et Brendan Eich (l'inventeur de JavaScript) en parlait pas mal. Ensuite, Mozilla fait partie de l'initiative Coverity Scan.

Bref, il y a des choses de faites sur ce plan la, mais elles ne sont pas parvenues jusqu’à toi.

D’où l’intérêt qu'aurait eu Google a protéger la marque Android comme Mozilla a protégé la marque Firefox.

Je sais que ça n'avait pas plus a tout le monde a l’époque (surtout ici), mais au moins si tu axes ta pub sur une marque protégée, et pas quelque chose de totalement libre, et bien tu peux alors imposer des choses a ceux qui utilisent ta marque. Si c'est complètement libre, et bien ne communique pas sur la marque du tout.

Par contre je ne sais pas si Android aurait eu le même succès du coup, car dépendre de la MoFo n'est pas la même chose que dépendre de Google. Au et puis si, ça aurait sûrement puisque les petits stickers "compatible Windows" se vendent comme des petits pains, et on ne peut pas dire que dépendre de Google est pire que dépendre de Microsoft.

 

Tristan Nitot avait raison! http://standblog.org/blog/post/2011/04/13/En-vrac :

Vous avez vu ce que Google fait au code source prétendument ouvert d'Android 3.0 ? Bah ils le ferment : Do Not Anger the Alpha Android. Le prétexte : les gens (en l'occurence les constructeurs) en font ce qu'ils veulent… Ah, si les gens se mettent à faire ce qu'ils veulent quand on leur donne la liberté, où va le monde, ma brave dame ? ;-) Plus sérieusement, protéger le code (temporairement, j'espère) n'est pas la solution. Voici ce qu'en pense mon collègue Siddharth Agarwal : Openness and reputation. Google aurait du faire comme Mozilla et protéger la marque, pas le code…

 

Les enjeux a l’œuvre dans de l'open source commercial sont différents du bon vieil open source a la papa (ou a la RMS). On aime ou on n'aime pas (ça dépend du point de vue), mais au moins on est protégé efficacement si jamais il y a des choses qui merdent.

Ce serait bien que ce filtre fonctionne: passionné = bon.

Malheureusement le monde n'est pas noir ou blanc. J'ai donc un contre exemple: un gars qui codait chez lui (passionné) mais qui codait très mal avec plein de bugs. Alors peut être que le langage qu'il utilisait au boulot n'était qu'alimentaire? Dans ce cas, ça ne va pas être facile de deviner qui est bon et qui ne l'est pas.

Je t'ai pertinenté, mais tu ne répond pas a la question: La question parlait des jeux qui vont être libéré a l'issue de cet humble bundle, pas des précédents :)

Je me répond: La page suivante explique bien que la mémoire transactionnelle est limitée sur une ou plusieurs portions précises du code (transaction statements, transaction expressions, and function transactions):
http://gcc.gnu.org/wiki/TransactionalMemory

Donc oui tu pourra clairement mélanger les deux approches selon tes besoins.

Tout a fait, je suis passé un peu vite la dessus. Le SQL que j'ai posté dans un autre commentaire illustre mieux la situation (écritures concurrentes).

Bravo! Tu viens de démontrer que les verrous fonctionnent mieux si tu as des fils d’exécution qui accèdent a la même ressource :)

Sauf que la mémoire transactionnelle c'est du verrouillage optimiste, c'est a dire que si la majorité de ton code s’exécute sans conflit, alors cela te fait gagner du temps (Et ce sont des maux de tête évités au développeur). Cette technique existe déjà avec les bases de données ou lors de chaque mise a jour d'une ligne, tu vérifies sa pour être sur tu as bien travaillé avec la version la plus a jour:

UPDATE MA_TABLE
 WHERE MA_COLONNE = 'nouvelle valeur'
   AND VERSION = 3                               -- c’était la dernière version lue depuis la base de donnée

ou bien:

UPDATE MA_TABLE
 WHERE MA_COLONNE = 'nouvelle valeur'
   AND LAST_UPDATE_DATE = '23/03/2012 14:57:23'  -- c’était la date de dernière mise a jour lue depuis la base de donnée

Si ça foire, et bien tu rééxecute ta transaction, mais c'est pas un drame car ça arrive relativement peu souvent.

Quoiqu'il en soit, je préfères utiliser des algorithmes lock free lorsque c'est possible, c'est beaucoup plus sympa pour la maintenance :)

Non je ne vois pas pourquoi se serait mutuellement exclusif, sauf problème d’implémentation :).
Si les verrous sont implémentés avec des primitives noyaux, et que la mémoire transactionnelle est implémentée au niveau du programme utilisateur, alors il n'y aura pas de problème.
J’espère que les implémentations vont permettre de coder des applications en utilisant les 2 modes!

Je vais essayer d'expliquer ma pensée:
Alors que la plupart des commentaires semblent être du type "pour ou contre la mémoire transactionnelle", je vais prendre la voie du milieu (toujours la meilleure): Ça dépend des cas et de ton application. Si tu peux valider que les accès concurrents sur une ressource sont rares, alors la mémoire transactionnelle va être super. Sinon elle va te faire perdre plus de temps et les verrous sont ta solution.

De même, rien n’empêche d'imaginer une application dans laquelle il y a plusieurs composants.
Pour tous les composants sauf un, les accès concurrents a une ressource sont rares => utilisation de la mémoire transactionnelle.
Pour le composant ou les accès concurrents sont nombreux, alors l'utilisation d'un verrou sera judicieuse même si le reste de l'application utilise une mémoire transactionnelle.

Ainsi, je pense tout a fait possible de vouloir utiliser les deux.

Comme le signale Torvald Riegel, puisque le développeur se prend moins la tête a corriger des problèmes difficiles de concurrence d’accès sur les verrous, il peut passer plus de temps a optimiser son application.
Certes, c'est un effet indirect de la mémoire transactionnelle.

A choisir, je préfère largement ça plutôt que les développeurs perdent leur temps sur des problèmes complexes de multithreading. Et cela même si les dit développeurs devaient être très forts et parvenir a résoudre le problème plus rapidement que la moyenne des devs.

La programmation concurrente n'est pas facile du tout :-(