Moi j'utilise stow depuis des années. Le principe est très simple:
Tu installes ton programme dans /usr/local/stow/mon_program
puis, dans le répertoire '/usr/local/stow' tu lances:
$ stow mon_program
Stow va ensuite créer plein de lien symboliques pour chaque fichier dans mon_program pour faire un sorte que, du point de vue système, tout est dans /usr/local.
Donc tu n'as qu'à mettre /usr/local/bin et /usr/local/lib dans les bonnes variables d'environnement.
Si tu veux désinstaller ton programme, va dans /usr/local/stow et lance:
$ stow -D mon_program
S'il a été modifié, tu peux le réinstallé avec:
$ stow -R mon_program
Et, cerise sur le gâteau, stow vérifie s'il y a des collisions avec d'autres programmes. Comme ça, tu ne risque pas d'écraser un fichier qui existe déjà!
Franchement, OGM = Organismes Génétiquement Modifiés. Ça couvre donc TOUTE modification, y compris celles fatales pour les plantes, celles produisant des produits chimiques non natifs, ... Alors on utilise déjà les OGM pour produire certains antibiotiques, alors pourquoi pas des produits nocifs (qui a dit que les antibiotiques étaient nocifs?).
Franchement, une telle non-nouvelle ... merci ! Le problème avec la suite du raisonnement, c'est que c'est tout aussi vrai avec les moyens classiques de transformation. Si tu croises deux plantes proches, donc une seule est comestible, comment être sûr que le résultat soit comestible? Encore pire: on verse des quantités invraisemblable de produits chimiques toxiques sur les plantes qu'on mange tous les jours ... comment être sûr que le nouveau produit ne va pas pénétrer la peau des légumes et nous empoisonné ?
À ce rythme, c'est simple: ne mange plus, mais alors vraiment, plus rien! Parce que tu ne seras jamais sûr que ta bouffe est pas empoisonnée ... (triste mais vrai).
Bah oui, j'utilises beaucoup d'applis web, mais elles ne sont utilisables quand si les flux de données sont faibles. Éditer une petite image sur le web, pourquoi pas, mais si l'image fait plus de 4 Go, bah c'est pas possible. Par ailleurs, si l'objectif de l'application c'est du rendu (2D ou 3D) et bien c'est pareil, par le réseau, c'est beaucoup trop lent, parce qu'il y a un gros flux de données (cette fois de l'appli vers la machine).
Dans mon cas, j'aime bien utiliser les applis web qui, de toute façon, sont basées sur l'utilisation d'Internet (messagerie instantanée ou non, RSS, twitter, travaux collaboratifs). Par contre, les applications de type 'bureau' sont typiquement largement inférieur dans leur version web: les temps de réponse sont moins bon, y a moins de fonctionnalités parce que c'est beaucoup plus difficile à développer, et y a plus de bugs (bugs d'applis + bug de navigateurs), on peut pas les utiliser sans être connecté (i.e. train). Et je parle même pas des applis scientifiques, qui demandent beaucoup trop de ressources (I/O, processeur, mémoire, vidéo).
Donc bon, en conclusion, je pense qu'à terme, les deux types d'applis existeront, et tant mieux, mais je ne vois certainement pas les applis natives disparaître aux profits des applis web.
On va dire que c'est parce que les brevets sur le noyau Linux n'existent pas ? Soyons sérieux un instant: s'ils existaient, Microsoft aurait attaqué deux ou trois distributions Linux, montrer les brevets et détruit la confiance des entreprises en Linux. Mais non, ils existaient pas, donc c'est beaucoup plus drôle d'en parler sans jamais les montrer.
Alors on reprends: les brevets portent sur des implémentations, pas des idées ou des concepts (en tout cas en Europe, or Python est européen). Il est bien plus difficile de réimplémenter un langage (i.e. mono) sans réutiliser l'implémentation originale (même si on ne le fait pas sciemment).
Du coup tu vois, Python est hors de danger, il repose sur des principes différents, l'implémentation est à coup sûr (ou presque sûr) différente. Par contre, mono réimplémente exactement .net et présente donc un risque beaucoup plus important face à des brevets.
En passant, ton argument sur les brevets qui datent d'avant le moment ou Microsoft a commencé à travailler sur C# sont risibles. Pour déposer un brevet, il faut travailler sur le projet ... Du coup les brevets datent presque sûrement du début des années 2000.
Maintenant, reprenons ton exemple vlc/ffmpeg/... Et bien oui, il y a des problèmes. Heureusement, les brevets qu'ils violent (parce qu'ils en violent) ne sont pas valide en Europe, et ce sont des projets européens. Par contre, si l'Europe passe des lois pro-brevets, et bien ... de toute façon y a rien à faire ! Alors on aura eu des lecteurs multimédia, et puis la loi empêchera d'en faire des gratuits de toute façon.
Par contre, on remarquera encore ta mauvaise foi dans la comparaison. Si un langage de programmation devient inutilisable, c'est, potentiellement bien plus embettant qu'une application. Par exemple, si Python devenais inutilisable, de nombreux scripts et applications qui sont au cœurs de nos systèmes seraient à réécrire. Ça prendrait beaucoup de temps et de ressources, et les entreprises deviendraient beaucoup plus prudentes quant à leur utilisation de GNU/Linux (et puis tout réécrire en Perl, ... ;) ).
En gros, tant que mono n'est utilisé que pour des applications secondaires, il n'y a pas trop de risque. Mais si le nombre d'application dépendant de mono devient important, ou pire si de telles applications se glissent au cœur du système, à ce moment, Microsoft détient une bombe permettant de causer à Linux un tort important, qui risque même de l'empêcher d'exister tout court.
Personnellement, je préfère changer de métaphore :
Si, sur une autoroute circule 98% de voiture volées, faut-il fermer l'autoroute ? Moi je pense que non.
Au moins ça donne une image clair et précise ! Notamment parce que, si tu fermes l'autoroute, les voitures repasseront pas la nationale comme elles faisaient avant ;)
j'ai eu à obtenir un visa de travail Canadien alors que j'étais en Angleterre ... ce que j'ai fait est de demander le visa en me faisant domicilier chez mes parents. Comme tout est faisable par courrier, tout s'est bien passé ... Après, je sais pas si c'est trop long ou non ...
Et bien à ma grande surprise, g++-4.2 génère un code largement plus rapide que Visual C++ 8.0 !!! J'ai récemment eu l'occasion de porter du code Linux sous Windows ... et j'ai commencé par MinGW (car plus facile) mais je l'ai aussi porté sous Visual C++ 8.0, justement parce que je me disais que ce serait plus rapide comme ça. Et bien non ! Avec g++-4.2 j'ai un gain de performances de l'ordre de 15% par rapport à Visual C++ 8.0. Bien sûr, le test a été fait après fignolage des options de compil des deux côtés. Le plus étonnant est que mon code tourne toujours 5% plus vite sous Linux que sous windows, même avec le même compilo O_o
Comme quoi l'équipe de GCC a fait des prouesses avec la version 4.2 !!! Reste plus qu'à optimiser le compilo lui-même (l'objectif de la version 5 si je me souviens bien).
Mouai ... pour dire que je l'ai fait marcher sans pb sur mon portable (un IBM T43) mais que je suis vite revenu au mot de passe car c'est bcp trop lent !!!
Ça passe pour le login ... sous windows comme de toute façon par défaut t'es admin, t'as jamais besoin de ton mot de passe après donc ça passe, mais sous Linux (ou UNIX), c'est vraiment trop lent ! Et ça m'a énervé rapidement. Ou alors faut configurer ça mieux pour le faire au démarrage mais pas ailleurs (et oui, je sais c'est possible avec PAM, j'y ai juste pas passé le temps).
Mes deux sous ... (parce que je suis au Canada et que je le vaux bien :P )
Donc non, en effet, epita ne délivre pas de diplome d'ingénieur vu que ça n'existe pas.
Avant de dire des conneries plus grosse que toi, renseigne-toi ! Si le diplôme d'ingénieur n'existe pas, à quoi sert les sections du journal officiel qui, chaque année, donne la liste des diplômés des différentes écoles d'ingénieurs reconnues par l'état français ?
Par exemple, pour la promotion de l'année dernière de Télécom Paris :
Pour ceux qui ont un vrai OS, le caractère : 汽 me semble tout à fait japonais ou chinois et est bien rendu par Firefox, konqueror, et probablement par le serveur X en fait ... Donc quand tu fais une blague comme ça, plutôt qu'utiliser un caractère qui est rendu chez toi par une boite, vaudrait mieux prendre le caractère boîte ... ça risque de mieux marcher, genre :
⊞ ou ⊡ ou ⌑ ou ▢ ou □ ou ... Enfin bon, y en a plein quoi !
Le problème principal est : DocBook est-il capable de générer, au final, un document PDF ou PS sans SVG dedans ?
Si la réponse est : OUI, alors pas de pb !
Si la réponse est : NON, alors ça ne résout rien !
De toute façon, il faut savoir que LaTeX ne gère pas les images mais délègue cette gestion à d'autres utilitaires ... C'est comme ça que ça marche bien avec tout un tas de formats ;)
Bon, 10% c'était à titre indicatif ... mais jette un oeil aux moteurs 3D. Tous ceux que je connais (bon ça fait 2 ou 3 seulement) utilisent des systèmes complexe d'actions et de visiteurs pour au final recréer en C++ ou en Java les multi-méthodes.
De mon côté j'ai déjà eu plusieurs cas où une multi-méthode aurait permis une factorisation élégante de mon code ! A la place ... bah je suis obligé de dupliquer ...
Bon, déjà sur la traduction : ndr : en anglais inheritance signifie généalogie, terme que je préfère au moins approprié français "héritage"
Alors 1 - c'est faux, selon le Merriam-Webster, inheritance signifie "l'action d'hérité de biens, la réception de traits généalogiques, ..." donc c'est bien "héritage" qui est le plus proche. 2 - je trouve perso que "héritage" est bien plus pertinent que généalogie. Un héritage met l'accent sur ce que le descendant a acquis de son parent et c'est exactement ça qu'on veut dire pour les langages OO ...
Sur la discussion maintenant ... la première impression que j'ai est qu'ils ont tous les deux une vision étriquée de ce qu'on peut faire avec un langage moderne ! Le paradigm courant est le plus répandu est l'objet et l'envoie de message. C'est tout de même un paradigme qui s'est montré efficace et qui m'a l'air de fonctionner dans au moins 90% des cas. Par exemple, dire que les seules relations sont 'is_a' et 'has_a' montre plus les limites des rédacteurs que du concept ... ou alors il faut qu'il nomme des concepts qui ne soient pas réductible à ces deux là ! Pour l'instant, je n'en ai pas rencontré ... en gros, il ne faut pas confondre limitation du paradigme et limitation de l'imagination de celui qui l'utilise !!!
Sinon, mon avis est que le concept le plus limitant aujourd'hui est celui de l'envoie de message ! Certes il est très simple à comprendre et fonctionne dans 90% des cas, mais il reste ces 10% où les gens imaginent des convonlutions invraisemblables pour combler le manque de multi-méthode (i.e. de méthodes résolues sur plusieurs arguments et non un seul). Et à ma connaissance, seul LISP dans les langages répandus permet la création de multi-méthodes.
Ensuite, je trouve qu'il est préférable de séparer structure de donnée et définitions des fonctions qui s'appliquent dessus. Ça permet de faire des logiciels plus extensibles et mieux découpés. Encore une fois, c'est ce que propose LISP, mais pas seulement !
Par exemple, Ruby *permet* cette approche (c'est encore mieux que de la forcer je trouve) !
Et puiss chaque niveau d'abstraction est plus complexe que le précédent à comprendre et à utiliser ! Il a fallu une dizaine d'année (au moins ?) pour que le concept d'objet soit correctement utilisé par une majorité de programmeurs et il faudra encore du temps pour qu'une majorité d'informaticien utilise la programmation OO à bon escient !
Enfin, si un nouveau paradigme apparaît je suis prêt à parier à 1 contre 100 que ça ne viendra jamais de ces gentils agitateurs de mains ! Ce qu'il faut pour ce genre d'innovation c'est un concept complètement nouveau, qui soit implémentable facilement dans les langages actuels (comme l'a été le concept d'objet) et qui vienne d'un programmeur car on dira ce qu'on veut mais seul un programmeur comprend un programmeur ;)
franchement ton article est aussi obscure que possible pour un texte aussi court ....
Déjà il aurait été mille fois plus intéressant de montrer comment faire une classe Python à partir d'une structure C ! Et donc montrer rapidement comment enregistrer le destructeur et le constructeur (ou plutôt l'initialisateur ...).
Ensuite, le GC (garbage collector) n'a absolument rien à faire dans ton exemple ! Pour les objets "simple" (comprendre : qui ne risquent pas de provoquer des cycles de références) Python fonctionne par comptage de référence ... parler du GC ici est une complication inutile.
De plus, celui qui ne libère pas la mémoire n'est pas Python mais SWIG ... Python a probablement libéré la mémoire nécessaire pour stoquer sa structure à lui !
- C# connu ? Apprendre Java.
- Java connu ? Apprendre C#.
Franchement, argumente parce que là je vois pas l'intérêt ! Si tu veux apprendre un langage tu as tout intérêt à choisir un langage différent de ce que tu connais, et si tu ne connais pas le C++, ça me semble une bonne chose de l'apprendre. Certe le langage a des défauts (mais quel langage n'en a pas ?) et il est réputé difficile. Pourtant c'est un langage qui a l'avantage d'offrir plusieurs niveaux de programmation et tu n'es pas obligé de te frotter aux difficultés dès le début !
Et puis le plus gros pb du C++ c'est que très peu de gens savent vraiment l'utiliser ! Y a qu'à voir le nombre de bibliothèques "haut niveaux" qui proposent encore de travailler directement sur des pointeurs ...
D'ailleurs, pour Qt designer, une très bonne chose est que tu ne touches jamais au code généré (c'est fait pour), au contraire des générateurs de code à la Visual C++ ...
Si tu l'utilises, tu es censé dériver des classes générées pour implémenter ce qui manque. Ainsi tu peux très facilement revenir à l'outil de génération, sans risques d'interférences dans aucun sens ! Et puis t'as pas à te farcir du code généré, ce qui n'est pas toujours très pratique ...
la probabilité que 2 fichiers différents produise le même hachage MD5 est très faible
Non ! Le principe du hash de fichier n'est pas là !
Le but est d'obtenir une fonction pour laquelle :
1 - toutes les valeurs sont équiprobables
2 - le hash de deux fichiers peu différents impliquent des valeurs très différentes
Mais rien n'est dis dans le cas où les fichiers sont très différents, tout simplement parce qu'on essaie de résumer des centaines de Mo en qq octets, et il est illusoire de dire qu'il n'existe pas (ou même qu'il n'y a pas bcp) de fichiers ayant le même hash.
Du coup, les attaques sont à rechercher dans les fichiers très différents ...
Alors, d'une part les styles ne résolvent pas les problèmes de différence d'affichage entre ordinateur (voir même sur le même entre deux ouvertures). Mais bon, c'est un bug de word pas du principe.
Par contre, moi aussi j'ai eu, dans une boîte, un modèle de document super bien fait avec tout qui marche bien, tu tapes ton texte au km, à chaque nouvelle page, les logos et les entêtes/pieds de pages s'insèrent correctement et tout et tout. Et puis j'ai quitté la boite ... et puis j'ai voulu faire un document pareil dans une autre boite (parce qu'on me demandait du Word aussi) mais là y avait pas le super modèle. Bon, je fais quoi ? J'ai pris le modèle: mais on le modifie comment ? Tout ce que j'ai essayé a foiré ! Moralité j'ai eu un document pourri à la fin (comme tous les documents que j'ai réussi à obtenir avec Word depuis que j'ai arrété de l'utiliser régulièrement)
Maintenant, même histoire avec LaTeX ! Enfin presque, plutôt: "Tiens il est bien ton document, y a des trucs qui m'intéressent, tu m'envoies le source ?" Et hop je peux lire le source, le récupérer, apprendre comme il fonctionne ... ça c'est une des plus grosses différences entre les deux !
Et puis le plus gros défaut du Wysiwig (et c'est encore pire avec les soft de crosoft parce qu'ils changent les interfaces régulièrement): tu sais faire qqch ? t'as fait un super document ? et bien pratique TOUS LES JOURS ! Sinon tu oublieras et tu n'auras AUCUN MOYEN de retrouver ce que tu avais fais à partir du document que tu as fait !
Et enfin, avec les Wysiwyg actuels on est encore à des années lumières de l'automatisation et de l'abstraction que propose LaTeX !!!
# STOW
Posté par harbort1 . En réponse au journal Réinventer la roue est parfois plus simple que de réutiliser l'existant .... Évalué à 8.
Tu installes ton programme dans /usr/local/stow/mon_program
puis, dans le répertoire '/usr/local/stow' tu lances:
$ stow mon_program
Stow va ensuite créer plein de lien symboliques pour chaque fichier dans mon_program pour faire un sorte que, du point de vue système, tout est dans /usr/local.
Donc tu n'as qu'à mettre /usr/local/bin et /usr/local/lib dans les bonnes variables d'environnement.
Si tu veux désinstaller ton programme, va dans /usr/local/stow et lance:
$ stow -D mon_program
S'il a été modifié, tu peux le réinstallé avec:
$ stow -R mon_program
Et, cerise sur le gâteau, stow vérifie s'il y a des collisions avec d'autres programmes. Comme ça, tu ne risque pas d'écraser un fichier qui existe déjà!
# Et ça vous étonne ???
Posté par harbort1 . En réponse au journal Certains OGM prouvés nocifs. Évalué à 5.
Franchement, une telle non-nouvelle ... merci ! Le problème avec la suite du raisonnement, c'est que c'est tout aussi vrai avec les moyens classiques de transformation. Si tu croises deux plantes proches, donc une seule est comestible, comment être sûr que le résultat soit comestible? Encore pire: on verse des quantités invraisemblable de produits chimiques toxiques sur les plantes qu'on mange tous les jours ... comment être sûr que le nouveau produit ne va pas pénétrer la peau des légumes et nous empoisonné ?
À ce rythme, c'est simple: ne mange plus, mais alors vraiment, plus rien! Parce que tu ne seras jamais sûr que ta bouffe est pas empoisonnée ... (triste mais vrai).
# C'est pas demain que les applis natives disparaîtront
Posté par harbort1 . En réponse au journal Vous êtes plutôt applications web ou applications desktop/native ?. Évalué à 6.
Dans mon cas, j'aime bien utiliser les applis web qui, de toute façon, sont basées sur l'utilisation d'Internet (messagerie instantanée ou non, RSS, twitter, travaux collaboratifs). Par contre, les applications de type 'bureau' sont typiquement largement inférieur dans leur version web: les temps de réponse sont moins bon, y a moins de fonctionnalités parce que c'est beaucoup plus difficile à développer, et y a plus de bugs (bugs d'applis + bug de navigateurs), on peut pas les utiliser sans être connecté (i.e. train). Et je parle même pas des applis scientifiques, qui demandent beaucoup trop de ressources (I/O, processeur, mémoire, vidéo).
Donc bon, en conclusion, je pense qu'à terme, les deux types d'applis existeront, et tant mieux, mais je ne vois certainement pas les applis natives disparaître aux profits des applis web.
[^] # Re: danger
Posté par harbort1 . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.
[^] # Re: danger
Posté par harbort1 . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.
Du coup tu vois, Python est hors de danger, il repose sur des principes différents, l'implémentation est à coup sûr (ou presque sûr) différente. Par contre, mono réimplémente exactement .net et présente donc un risque beaucoup plus important face à des brevets.
En passant, ton argument sur les brevets qui datent d'avant le moment ou Microsoft a commencé à travailler sur C# sont risibles. Pour déposer un brevet, il faut travailler sur le projet ... Du coup les brevets datent presque sûrement du début des années 2000.
Maintenant, reprenons ton exemple vlc/ffmpeg/... Et bien oui, il y a des problèmes. Heureusement, les brevets qu'ils violent (parce qu'ils en violent) ne sont pas valide en Europe, et ce sont des projets européens. Par contre, si l'Europe passe des lois pro-brevets, et bien ... de toute façon y a rien à faire ! Alors on aura eu des lecteurs multimédia, et puis la loi empêchera d'en faire des gratuits de toute façon.
Par contre, on remarquera encore ta mauvaise foi dans la comparaison. Si un langage de programmation devient inutilisable, c'est, potentiellement bien plus embettant qu'une application. Par exemple, si Python devenais inutilisable, de nombreux scripts et applications qui sont au cœurs de nos systèmes seraient à réécrire. Ça prendrait beaucoup de temps et de ressources, et les entreprises deviendraient beaucoup plus prudentes quant à leur utilisation de GNU/Linux (et puis tout réécrire en Perl, ... ;) ).
En gros, tant que mono n'est utilisé que pour des applications secondaires, il n'y a pas trop de risque. Mais si le nombre d'application dépendant de mono devient important, ou pire si de telles applications se glissent au cœur du système, à ce moment, Microsoft détient une bombe permettant de causer à Linux un tort important, qui risque même de l'empêcher d'exister tout court.
[^] # Re: Pour pas être en reste ...
Posté par harbort1 . En réponse au journal Hahaha. Évalué à -5.
[^] # Pour pas être en reste ...
Posté par harbort1 . En réponse au journal Hahaha. Évalué à -5.
[^] # Re: 98% de connerie
Posté par harbort1 . En réponse au journal Le SNEP et ses arguments. Évalué à 8.
Si, sur une autoroute circule 98% de voiture volées, faut-il fermer l'autoroute ? Moi je pense que non.
Au moins ça donne une image clair et précise ! Notamment parce que, si tu fermes l'autoroute, les voitures repasseront pas la nationale comme elles faisaient avant ;)
# Juste pour le VISA ...
Posté par harbort1 . En réponse au journal \begin{mavie}. Évalué à 2.
[^] # Re: Le meilleur ?
Posté par harbort1 . En réponse au journal mingw passe à gcc 4.2.1 (enfin presque). Évalué à 10.
Comme quoi l'équipe de GCC a fait des prouesses avec la version 4.2 !!! Reste plus qu'à optimiser le compilo lui-même (l'objectif de la version 5 si je me souviens bien).
[^] # Re: Superbe !
Posté par harbort1 . En réponse au journal login par empreinte digitale sous Linux. Évalué à 3.
Ça passe pour le login ... sous windows comme de toute façon par défaut t'es admin, t'as jamais besoin de ton mot de passe après donc ça passe, mais sous Linux (ou UNIX), c'est vraiment trop lent ! Et ça m'a énervé rapidement. Ou alors faut configurer ça mieux pour le faire au démarrage mais pas ailleurs (et oui, je sais c'est possible avec PAM, j'y ai juste pas passé le temps).
Mes deux sous ... (parce que je suis au Canada et que je le vaux bien :P )
[^] # Re: Pareceque
Posté par harbort1 . En réponse au journal Pourquoi aimez-vous coder ?. Évalué à 4.
Avant de dire des conneries plus grosse que toi, renseigne-toi ! Si le diplôme d'ingénieur n'existe pas, à quoi sert les sections du journal officiel qui, chaque année, donne la liste des diplômés des différentes écoles d'ingénieurs reconnues par l'état français ?
Par exemple, pour la promotion de l'année dernière de Télécom Paris :
http://www.admi.net/jo/20060319/INDI0606892A.html
Pour les mines de Paris :
http://www.admi.net/jo/20060319/INDI0607049A.html
Alors, oui le diplôme d'ingénieur existe, oui il est reconnu, et délivré, par l'état et par personne d'autre !
[^] # Re: Pas tout compris là
Posté par harbort1 . En réponse au journal this != '|'. Évalué à 10.
⊞ ou ⊡ ou ⌑ ou ▢ ou □ ou ... Enfin bon, y en a plein quoi !
[^] # Re: même problème avec vim
Posté par harbort1 . En réponse au journal Emacs ma tuer. Évalué à 1.
De fait, il est aisé de les repérés ... à moins que la config de vim ait été modifiée !
[^] # Re: GNU/HURD?
Posté par harbort1 . En réponse à la dépêche un nouveau Minix. Évalué à 2.
ah ? ça y est ? ils l'ont la compatibilité POSIX ? jusqu'à présent il me semble que Minix n'implémentait qu'une partie de POSIX ...
[^] # Re: DocBook ?
Posté par harbort1 . En réponse au journal Outils de dessins techniques/scientifiques vectoriels. Évalué à 1.
Si la réponse est : OUI, alors pas de pb !
Si la réponse est : NON, alors ça ne résout rien !
De toute façon, il faut savoir que LaTeX ne gère pas les images mais délègue cette gestion à d'autres utilitaires ... C'est comme ça que ça marche bien avec tout un tas de formats ;)
# Regrets injustifiés ...
Posté par harbort1 . En réponse au journal Google débauche encore.... Évalué à 5.
il est embauché pour permettre l'ouverture de google talk aux autres logiciels ... dont Gaim !!!
Donc c'est cool non ? :)
[^] # Re: Mes deux centimes ...
Posté par harbort1 . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 2.
De mon côté j'ai déjà eu plusieurs cas où une multi-méthode aurait permis une factorisation élégante de mon code ! A la place ... bah je suis obligé de dupliquer ...
# Mes deux centimes ...
Posté par harbort1 . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 6.
ndr : en anglais inheritance signifie généalogie, terme que je préfère au moins approprié français "héritage"
Alors 1 - c'est faux, selon le Merriam-Webster, inheritance signifie "l'action d'hérité de biens, la réception de traits généalogiques, ..." donc c'est bien "héritage" qui est le plus proche. 2 - je trouve perso que "héritage" est bien plus pertinent que généalogie. Un héritage met l'accent sur ce que le descendant a acquis de son parent et c'est exactement ça qu'on veut dire pour les langages OO ...
Sur la discussion maintenant ... la première impression que j'ai est qu'ils ont tous les deux une vision étriquée de ce qu'on peut faire avec un langage moderne ! Le paradigm courant est le plus répandu est l'objet et l'envoie de message. C'est tout de même un paradigme qui s'est montré efficace et qui m'a l'air de fonctionner dans au moins 90% des cas. Par exemple, dire que les seules relations sont 'is_a' et 'has_a' montre plus les limites des rédacteurs que du concept ... ou alors il faut qu'il nomme des concepts qui ne soient pas réductible à ces deux là ! Pour l'instant, je n'en ai pas rencontré ... en gros, il ne faut pas confondre limitation du paradigme et limitation de l'imagination de celui qui l'utilise !!!
Sinon, mon avis est que le concept le plus limitant aujourd'hui est celui de l'envoie de message ! Certes il est très simple à comprendre et fonctionne dans 90% des cas, mais il reste ces 10% où les gens imaginent des convonlutions invraisemblables pour combler le manque de multi-méthode (i.e. de méthodes résolues sur plusieurs arguments et non un seul). Et à ma connaissance, seul LISP dans les langages répandus permet la création de multi-méthodes.
Ensuite, je trouve qu'il est préférable de séparer structure de donnée et définitions des fonctions qui s'appliquent dessus. Ça permet de faire des logiciels plus extensibles et mieux découpés. Encore une fois, c'est ce que propose LISP, mais pas seulement !
Par exemple, Ruby *permet* cette approche (c'est encore mieux que de la forcer je trouve) !
Et puiss chaque niveau d'abstraction est plus complexe que le précédent à comprendre et à utiliser ! Il a fallu une dizaine d'année (au moins ?) pour que le concept d'objet soit correctement utilisé par une majorité de programmeurs et il faudra encore du temps pour qu'une majorité d'informaticien utilise la programmation OO à bon escient !
Enfin, si un nouveau paradigme apparaît je suis prêt à parier à 1 contre 100 que ça ne viendra jamais de ces gentils agitateurs de mains ! Ce qu'il faut pour ce genre d'innovation c'est un concept complètement nouveau, qui soit implémentable facilement dans les langages actuels (comme l'a été le concept d'objet) et qui vienne d'un programmeur car on dira ce qu'on veut mais seul un programmeur comprend un programmeur ;)
# J'ai rien compris ...
Posté par harbort1 . En réponse au journal Python et SWIG. Évalué à 2.
Déjà il aurait été mille fois plus intéressant de montrer comment faire une classe Python à partir d'une structure C ! Et donc montrer rapidement comment enregistrer le destructeur et le constructeur (ou plutôt l'initialisateur ...).
Ensuite, le GC (garbage collector) n'a absolument rien à faire dans ton exemple ! Pour les objets "simple" (comprendre : qui ne risquent pas de provoquer des cycles de références) Python fonctionne par comptage de référence ... parler du GC ici est une complication inutile.
De plus, celui qui ne libère pas la mémoire n'est pas Python mais SWIG ... Python a probablement libéré la mémoire nécessaire pour stoquer sa structure à lui !
[^] # Re: Langage
Posté par harbort1 . En réponse au journal Manque d'arguments pour Qt... Help !. Évalué à 1.
- Java connu ? Apprendre C#.
Franchement, argumente parce que là je vois pas l'intérêt ! Si tu veux apprendre un langage tu as tout intérêt à choisir un langage différent de ce que tu connais, et si tu ne connais pas le C++, ça me semble une bonne chose de l'apprendre. Certe le langage a des défauts (mais quel langage n'en a pas ?) et il est réputé difficile. Pourtant c'est un langage qui a l'avantage d'offrir plusieurs niveaux de programmation et tu n'es pas obligé de te frotter aux difficultés dès le début !
Et puis le plus gros pb du C++ c'est que très peu de gens savent vraiment l'utiliser ! Y a qu'à voir le nombre de bibliothèques "haut niveaux" qui proposent encore de travailler directement sur des pointeurs ...
[^] # Re: :)
Posté par harbort1 . En réponse au journal Manque d'arguments pour Qt... Help !. Évalué à 5.
Si tu l'utilises, tu es censé dériver des classes générées pour implémenter ce qui manque. Ainsi tu peux très facilement revenir à l'outil de génération, sans risques d'interférences dans aucun sens ! Et puis t'as pas à te farcir du code généré, ce qui n'est pas toujours très pratique ...
Bref: le meilleur des deux mondes :)
[^] # Re: idée amusante mais...
Posté par harbort1 . En réponse au journal md5 (encore) mis à mal. Évalué à 6.
Non ! Le principe du hash de fichier n'est pas là !
Le but est d'obtenir une fonction pour laquelle :
1 - toutes les valeurs sont équiprobables
2 - le hash de deux fichiers peu différents impliquent des valeurs très différentes
Mais rien n'est dis dans le cas où les fichiers sont très différents, tout simplement parce qu'on essaie de résumer des centaines de Mo en qq octets, et il est illusoire de dire qu'il n'existe pas (ou même qu'il n'y a pas bcp) de fichiers ayant le même hash.
Du coup, les attaques sont à rechercher dans les fichiers très différents ...
# C'est pas mal ...
Posté par harbort1 . En réponse au journal article sur la déviation du copyright. Évalué à 1.
Je trouve que ça nuit à la lecture ...
Aussi, il y a beaucoup de longueurs ... mais le fond est bon !
[^] # Re: oui en effet
Posté par harbort1 . En réponse au journal Est-ce que je suis trop Linuxien?. Évalué à 4.
Par contre, moi aussi j'ai eu, dans une boîte, un modèle de document super bien fait avec tout qui marche bien, tu tapes ton texte au km, à chaque nouvelle page, les logos et les entêtes/pieds de pages s'insèrent correctement et tout et tout. Et puis j'ai quitté la boite ... et puis j'ai voulu faire un document pareil dans une autre boite (parce qu'on me demandait du Word aussi) mais là y avait pas le super modèle. Bon, je fais quoi ? J'ai pris le modèle: mais on le modifie comment ? Tout ce que j'ai essayé a foiré ! Moralité j'ai eu un document pourri à la fin (comme tous les documents que j'ai réussi à obtenir avec Word depuis que j'ai arrété de l'utiliser régulièrement)
Maintenant, même histoire avec LaTeX ! Enfin presque, plutôt: "Tiens il est bien ton document, y a des trucs qui m'intéressent, tu m'envoies le source ?" Et hop je peux lire le source, le récupérer, apprendre comme il fonctionne ... ça c'est une des plus grosses différences entre les deux !
Et puis le plus gros défaut du Wysiwig (et c'est encore pire avec les soft de crosoft parce qu'ils changent les interfaces régulièrement): tu sais faire qqch ? t'as fait un super document ? et bien pratique TOUS LES JOURS ! Sinon tu oublieras et tu n'auras AUCUN MOYEN de retrouver ce que tu avais fais à partir du document que tu as fait !
Et enfin, avec les Wysiwyg actuels on est encore à des années lumières de l'automatisation et de l'abstraction que propose LaTeX !!!