Philippe F a écrit 2214 commentaires

Moui enfin les 2 logiciels libre multiplateformes les plus connus sont: OpenOffice et Mozilla.
Ils sont aussi célebre pour être des monstres gourmands, la question est donc: est-ce lié?
J'aurais tendance à penser que ce n'est pas obligatoire car Opéra bien que multi-plateforme est légé, mais le risque existe..

Et justement, opera utilise Qt, tout comme KDE.

Ce portage vers windows ne fait pas l'unanimité dans la communauté KDE. Mais bon, je vois mal les développeurs KDE interdire à qq'un de faire le portage. Pour un soft en LGPL/BSD, ce serait un comble.

Par contre; je ne sais pas où tu as rêvé que ce portage coûtait du temps ou de l'argent à Qt ou KDE. Qt tourne sous windows depuis la version 1.0 donc pas d'impact de ce côté-là. Concernant KDE, ce ne sont pas les gens qui dévelppaient auparavant sur KDE qui font le portage windows, ce sont des gens qui n'interviennent que sur cet aspect-là. Il n'y a donc pas de gachis ou de perte, simplement des contributeurs supplémentaires qui travaillent sur un aspect du projet qui n'avait pas encore été exploré.

En revanche, visiblement, David Faure a accès à un MacOs X et patch régulièrement pour cette plate-forme.

En tout cas, le projet KDE n'a pas dit "on va porter KDE sur windows parce que c'est une plateforme stratégique". C'est une bande de contributeurs indépendants qui font le travail, qui a d'ailleurs longtemp été héberge sur sourceforge, en tant que projet indépendant de KDE. Ils n'ont pas reçu d'interdiction de KDE de faire ce boulot.

Je ne suis pas d'accord avec toi. Unifier une API, ce n'est pas nécéssairement l'alourdir. Cf mon message plus bas avec kio comme exemple. Kio n'alourdit pas le protocole html ou le protocole ssh, il se contente de l'utiliser en fournissant une interface uniforme pour les applications KDE.

D'un point de vue programmation, phonon rajoute une couche, mais d'un point de vue fonctionnel, phonon est complètement transparent.

Finalement, la plus grosse nouveaute dans ce projet, c'est le nom : Phonon. C'est quand meme plus joli que kdemm .

Quelque part ça me semble évident. Si arTs propose les fonctionnalités A, B et C et que ESD propose B, C et D, pour être parfaitement interopérable, Phonon doit supporter B et C.

Ou bien phonon fournira une emulation de A. Ou bien les applications qui necessitent D auront la possibilite de demander si la fonctionnalite est disponible et si ce n'est pas le cas, de dire a l'utilisateur "Pour s'executer, ce programme necessite la fonctionnalite D dans le backend multimedia mais cette fonctionnalite n'est pas disponible sur votre backend".

A noter que ce type de comportement est deja utilise dans plein d'application ou de technologies. Par exemple, la surveillance de la mise a jour des repertoires (un nouveau fichier est-il arrive ?) se fait via une bibliotheque (dont j'ai oublie le nom) qui par defaut va faire du polling sur le repertoire, mais qui si l'option qu'il faut est dans le noyau et que le filesystem le supporte, va utiliser un mecanisme du file system pour etre informe des modifications du repertoire.

Prenons un autre exemple: kio. C'est la facon standard sous KDE d'acceder a un fichier. kio offre des backend pour:
- local filesystem
- http
- ftp
- ssh
- samba
- nfs
- pda

Tu peux dire que kio n'offre qu'un sous-ensemble de tous les protocoles cites et c'est vrai. Je doute que tu puisses executer une commande ssh avec redirection de port via kio. Mais est-ce un probleme ? kio repond a une problematique, acceder a ses fichiers a distance de facon transparente pour toutes les applications KDE. Si tu veux faire de la redirection de port ssh, il semble plus correct d'utiliser directement ssh. Mais dans ce cas, tu changes la problematique, tu n'es plus en train d'acceder a tes fichiers a distance, tu es en train de faire un truc specifique a ssh.

De meme, la problematique de phonon n'est pas de tierer partie du moteur xine ou gstreamer pour faire du mixage video ou que sais-je, mais de fournir des fonctionnalites de base a l'utilisateur (cf la page web):
- faire en sorte que toutes les applications KDE puissent "faire du bruit" de facon simple sans se soucier du backend
- faire en sorte que KDE n'impose pas un moteur multimedia a l'utilisateur vu qu'il y en a pour tous les gouts et les couleurs
- pouvoir regler le son de facon simple sous KDE sous toutes les applications
- faire facilement de la capture de son


Le probleme pendant longtemp sous Linux a ete l'absence de moteur multimedia. Les differentes solutions developpees pallient cette absence, mais ont globalement un jeu de fonctionnalite tres similaire. Donc cette unification est plutot la pour gerer la diversite des moteurs multimedia et pas pour faire un meta-moteur.

L'avantage de la structure actuelle, c'est qu'il y a tres peu de programmation en jeu. Notammnent, il n'y a aucune programmation graphique. Sur tu regardes les sources, tu verras des scripts bash et des .desktop, rien de plus.

On peut dire que Bram protege precieusement vim pour qu'il reste tres stable. C'est un peu ce qui nous a oblige a demarrer yzis. Un pour rajouter une configuration en ligne de commande qui n'etait pas utilisee par vim de toute facon (uniquement kvim), ca nous a calme.

En terme de sauvegarde, ESC : w est la suite de touche que je tape des que j'entre en mode "normal". C'est devenu un pur reflexe et je n'ai jamais besoin de compter sur vim pour me restaurer mes fichiers.

Pour faire court sur le choix lua vs python, disons que lua, en deux jours t'as un truc fonctionnel et utilisable.

En python, apres 2 semaines de bataille avec boost ou l'api C de python, t'as un truc qui marche a peu pres mais qui compile pas systematiquement sous toutes les plateformes (notamment sous windows, je m'arrache les cheveux).

En tant que fan de python, je suis pour python qui a plus de potentiel mais clairement, lua marche beaucoup mieux aujourd'hui et pour longtemp et remplit 95% du besoin.

J'ai un convertisseur vim -> lua qui marche pas mal sur des scripts pas trop complexes. Ca m'interesse d'avoir des scripts vim qui des gens utilisent pour pouvoir tester le convertisseur de facon un plus poussee et valider qu'on a bien toutes les interfaces qu'il faut dans yzis.

Interessant.

Pida marche parce que vim utilise une fenetre gtk par defaut et que pida est en gtk et gtk dispose d'un mecanisme pour incruster ses propres fenetres. Faire l'integration de vim gtk dans un widget Qt est beaucoup beaucoup plus complique puisqu'on dependait d'une fonctionnalite, XEmbed, qui avait ete incompletement implementee et peu testee par Trolltech et Gtk.

J'ai pas essaye, mais je pense qu'il reste des limitations. Le protocole de communication vim-server vim-client est plutot leger et ne permet par de faire un certain nombre de chose. Notamment, si on envoit une commande via ce canal, on ne peut pas savoir si la commande a reussi ou pas.

Bonjour,

Un point interessant a noter dans les fonctionnalites les plus demandees :
http://www.vim.org/sponsor/vote_results.php

L'integration dans un autre GUI. Nous, les auteurs de kvim avions fait ce travail et avons finalement renonce a cause de la trop grande difficulte de travailler sur la base de code de vim, et le manque de volonte de Bram de modifier Vim dans ce sens.

Donc la 3e fonctionnalite la plus demandee n'est pas prete d'arriver.

En revanche, nous avons demarre un autre projet, yzis, qui est un clone de vim sans les ``limitations'' imposees par l'architecture de vim. Quelques choix techniques :
- dev en C++
- scripting en lua
- moteur de syntaxe de kate
- gui en Qt, KDE et ncurses pour l'instant (sans limitations d'autres possibilites)
- utilisation de libyzis comme moteur vi independant (facon scintilla)
etc.

Plus de details sur :
http://linuxfr.org/2005/02/16/18311.html
http://www.yzis.org

Le developpement a un peu ralenti ces derniers mois mais repart, avec notamment le portage complet a Qt4 qui nous permettra d'avoir un yzis Windows, MacOs et Linux sous GPL tres facilement.

On est pas au niveau de vim question fonctionnalite et stabilite, mais on s'en approche a grand pas. Et c'est vraiment facile de participer grace a l'architecture propre en C++ (l'architecture de vim et a s'arracher les cheveux).

Un exemple de solution (pas de moi) :

#define FOR(i,n) for(int i=0; i<(n); i++)
typedef vector VI;
 
struct CrazySwitches {
int minimumActions(vector  s) {
  int n = s.size();
  int N = (1<<n);
  VI v(N * n, 999999); // idx = N * room + on bits
  v[1] = 0;
  queue q;
  q.push(1);
  while (!q.empty()) {
    int t = q.front(); q.pop();
    int on = t % N, r = t / N;
    FOR(i, n) {
      if (s[i] == r && i != r) { // can switch
        int tt = t ^ (1<<i);
        if (v[tt] > v[t]) v[tt] = v[t], q.push(tt);
      }
    }
    FOR(i, n) if (i != r) {
      if ((on & (1<<i)) == 0) continue; // cannot move to this room
      int tt = on + i * N;
      if (v[tt] > v[t] + 1) v[tt] = v[t] + 1, q.push(tt);
    }
  }
  int ret = v[(n-1) * N + (1 << (n-1))];
  return ret == 999999 ? -1 : ret;
}
};

Les programmes doivent etre rapides a ecrire et rapide a executer. Python et ruby sont bons au moins dans la premiere categorie.

Le C++ est populaire a mon avis parce qu'il n'y a aucune penalite a l'exeuction. Sur un probleme, un type a fait un analyse et la verification des depassements de tableaux fait que le C# ou le java sont plutot lent sur un tableau a 3 index par exemple. En C++, tu es sur d'eviter ce genre de probleme.

Pour les macros, meme si tout le monde en utilises quelques unes, ca reste du "sucre syntaxique", c'est a dire que t'economises quelques caracteres mais ca ne va pas plus loin (genre #define ALL(v) (v).begin(), (v).end() ).

Ce qui fait la difference, c'est vraiment la capacite a comprendre rapidement l'algorithme a utiliser et a le coder rapidement. Sur les problemes faciles et moyens, si ton programme fait plus de 50 lignes, c'est que tu n'as pas su simplifier le probleme suffisamment. Sur le probleme dur, je dirai que les 2/3 des solutions font aussi moins de 50 lignes de toute facon. Par contre, il faut s'accrocher pour les comprendre :-)

J'ai essaye mais il ne semble pas possible de livrer les sujets sans s'inscrire. Et a la fin de chaque probleme, il y a un gros copyright.

Je peux quand meme parler des types de problemes. L'avant dernier jeu de problemes etait pas mal:

pb facile:
Soit:
- A tq 10 <= A <= 100000
- B tq A <= B <= 100000
- A-B <= 1000
- trouver le nombre d'entiers entre A et B tq si v est un nb qu'on cherche, il n'y a aucun nombre premier entre v-10 et v+10 inclus

Rappel: temps d'execution en moins de deux secondes.

Exemple :

97001

97691

Returns: 89

La bonne methode, c'est de faire un crible d'Eratosthene. Sinon, meme en y allant bourrin, ca marche. Genre tu iteres sur tous les nombres entre A et B, et pour chacun de ces nombres tu vas de nombre-10 a nombre+10 et pour chacun de ces sous-nombres, tu verifies s'il est premier. J"ai gagne des points en cassant une solution qui faisait (A-B)*20 verifications de nombre premier, sans optimiser ou cacher la recherche de nombre premier en java et qui au final prenait plus de 2 secondes. Des que tu optimises un minimum (cache facon Eratosthene) ou tentative de division par tous les nombre jusqu'a sqrt(n), ca passe en 2 secondes.

Ca parait choquant d'etre bourrin, mais le but, c'est de coder ca en moins de 10 minutes.

Probleme moyen:
Tu plies un carre en 2 jusqu'a obtenir un triangle faisant 1/8 de ton carre original (le dernier pli est en diagonal). Tu fais des trous sur ce triangle, et il faut generer le carre deplie avec les trous.

L'entree est un vector qui represente le triangle avec des * pour les trous et des . pour les non-trous.

Exemple :

{"*",
"..",
".*.",
".**.",
".*.**"}

Returns:
{"**.*..*.**",
"*.**..**.*",
".*.*..*.*.",
"***....***",
"....**....",
"....**....",
"***....***",
".*.*..*.*.",
"*.**..**.*",
"**.*..*.**" }


C'etait plutot facile, il suffit de faire des symetries dans tous les sens.


Probleme difficile:

Tu as une suite de chambres. Chaque piece contient un interrupteur qui controle la lumiere dans une autre piece. Tu commences avec la premiere piece allumee. Tu peux aller a tout moment dans n'importe quelle piece du moment que la lumiere est deja allumee et tu ne peux pas eteindre la lumiere dans ta propre piece. Tu veux fnir avec la lumiere allumee dans la derniere piece uniquement. Retourner le nombre minimal de deplacement necessaires, ou -1 si c'est pas possible.

Maximum 16 pieces.

Exemple:
{7, 11, 1, 12, 6, 3, 0, 2, 6, 0, 0, 5, 9}
Returns: 15

Celui-la etait coton. Mais j'avais deja vu un probleme dans le meme style. Chaque etat global de tes pieces peut etre represente sous forme d'un entier, avec un bit par piece + une valeur entre 0 et 15 pour ta position. Tu veux partir de l'etat 1e piece allumee, present dans la premiere piece, jusqu'a l'etat derniere piece allumee, present dans la derniere piece. C'est donc un graphe dans lequel tu cherches le chemin le plus court. Pour un etat donne, il est facile de trouver tous les etats que tu peux rejoindre : le meme etat avec l'interrupteur qui a bascule (cout 0) ou bien le meme etat mais present dans une autre piece allumee (cout 1). Un petit coup de djikstra et tu trouves le chemin le plus court.


A coder en une heure, je peux te dire que tu n'a pas le temps de respirer.

J'ai pas precise mais en fait, tu codes dans une application java qui compile et execute le code sur leur serveur. Au final, tu livres un bout de code source donc c'est vraiment topcoder qui impose le langage.

Leur business model est d'aider des grosses boites a trouver des bons programmeurs. Ils prennent donc des langages populaires dans l'industrie, d'ou l'absence de langage un peu moins conventionnels, mais qui conviendraient tres bien aux types de problemes proposes (lisp, ocaml, haskell, scheme ou python, ruby).

> la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle.

Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.

Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.

Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.

Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.

Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.

C'est un fait connu que gcc n'est pas un excellent compilateur dans tous les domaines. C'est pas facile de compiler tous les langages de la terre sur toutes les architectures de l'espace et d'etre meilleur que tout le monde. Ce qu'il faut juger, c'est la distance. 20%, ca me parait acceptable tout en restant a ameliorer. Au dela, c'est qu'il y un truc qui ne va pas.

En general, gcc se fait battre par des compilos optimises pour des architectures specifiques, qui ont beaucoup moins de contraintes globales que gcc.

En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version.

Des projets comme KDE galerent parce que la gestion du code virtuel dans les classes n'est pas optimal. De ce que j'en comprends, le support C++ evolue tres lentement ce qui ralentit parfois de facon notable des gros projets C++. KDE etant probablement le plus gros projet Open Sourc en C++ qui utilise gcc.

Sur des archis embarques petite, je doute que gcc soit vraiment super efficace. Pour ce type d'architecture, ecrire un compilateur qui ne fait que du C et tient compte de certains caracteristiques des petits micros permet de meilleurs resultats que l'artillerie gcc.

Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.

Sinon, je travaille aussi dans l'embarque sur des micro 8bits et la facon dont tu ecris ton code a une influence certaine sur la taille du code genere par certains compilateurs. Certains vont mieux optimiser les acces aux variables globales, d'autres les acces aux variables locales. Certains n'aiment pas du tout les pointeurs (genre Keil, il aime pas du tout du tout les pointeurs au dela de 64K sur une archi 8 bits), d'autres les digerent facilement. Et chacun ont leur bugs : Codewarrior qui addresse les membres d'une structure sur un registre == pas possible d'avoir une strucutre plus grosse que 255 octets.

<< cite moi une seule plateforme, un seul framework dont l'api ne bouge pas dans le temps >>

win32: tu peux encore compiler tes programmes windows 3.1 aujourd'hui, ils fonctionnent toujours. Ca doit faire dans les 15 ans de plate-forme stable. C'est d'ailleurs une des forces de windows.

Sinon, on peut citer gtk, Gnome, KDE et Qt, dont les versions sont entierement compatibles entre elles si on ne change pas le premier chiffre. On tape dans les 3-4 ans de stabilite. Et deja avec 3-4 ans, ce n'est pas suffisant, il y a pas mal d'applications qui ne sont jamais portees et sont en quelque sorte perdues. Sous windows, ca m'arrive d'utiliser des applis qui clairement ont ete ecrites pour windows 3.1 et qui fonctionnent tres bien.

Tout ca pour dire que la stabilite des APIs, ce n'est pas un truc a prendre a la legere et que les faire varier meme de facon mineures tous les 6 mois, c'est le meilleur moyen de tuer un projet.

T'as raison, les normes et les standards, ca sert vraiment a rien.

Je propose que chacun decide de lui-meme de la facon dont il orthographie les mots qu'il utilise. Il pourra proteger son orthographe personelle sous GPL ou bien sous une licence proprietaire. L'academie francaise pourrait meme se faire plein de fric avec une histoire pareille.

bon, je sors, je suis pas en forme pour faire un bon troll

Je ne connais pas les coulisses de java et .NET mais a lire pas mal d'articles sur le sujet, il semble que .NET ait une architecture de meilleure qualite que java et permette de faire des choses que java ne fait pas.

Le seul exemple que je connaisse avec precision, c'est python. Jython, l'implementation de python en java est deux fois plus lente que l'implementation de reference. Ironpython, l'implementation au dessus du CLR (la VM de .NET) est plus rapide que l'implementation de reference.

Ah, donc je ne suis pas le seul a trouver que ce chef d'oeuvre de la literature fantastique est chiant a mourir. J'ai jamais depasse les 30 pages personellement.

Par contre, des trucs comme Shanara, qualifie de literature purement commerciale par les puristes, ca passe tout seul :-)

Je poste juste un lien vers le blog de Zack Rusin, (le mec qui developpe EXA, la nouvelle architecture d'acceleration de X). Pour lui, Gnash n'apporte pas de solution, et est un projet du domaine public recupere par la FSF (je n'ai pas verifie ce point) en modifiant tranquillement la licence.

http://www.kdedevelopers.org/node/1736

On est loin de la tournure de la depeche, qui sous-tend que la FSF aurait aider ce projet a se developper.

A ma connaissance, la FSF n'a d'ailleurs jamais aide aucun projet a se developper. Ils ont eu un role politique important mais pas de role actif en terme de mecenat du developpement du logiciel libre. C'est peut-etre tres bien comme ca, mais quand meme, ca me surprend toujours que ce soit Caldera Linux et non la FSF qui aient inventes sourceforge.

C'est ultra classique en programmation, c'est le modele de conception "poid leger" ou pour ceux qui comme moi comprennent pas bien le francais, le design pattern flyweight. Cf le bouquin "Design Pattern", par le GoF. A lire si vous faites de la programmaton objet depuis plus d'un an.

C'est une blague belge, c'est ca ?

Moi j'ai d'autres soucis qui sont un peu dommage, mais pas vraiment bloquant :

- impossible d'importer une mailbox normale via les menu de thunderbird. C'est ironique qu'il soit plus facile de migrer de outlook a thunderbird que d'un autre client libre. Il faut se copier les fichiers mbox a la main et c'est pas convivial du tout.

- impossible de copier l'addresse enjolivee d'un expediteur pour la coller ailleurs. Vraiment pas pratique. Thunderbird propose bien de copier uniquement la partie mail de l'addresse mais parfois, on souhaite conserver le nom aussi.

- impossible de faire du drag'n drop avec les addresses, a partir d'un message. Typiquement, j'ai 3 messages differents auxquels je veux repondre en un seul message. Sur kmail, je fais un drag'n drop des trois addresses dans mon nouveau message. Sur thunderbird, je ne peux que faire un copie/colle des addresses mail strict et c'est un peu lourd et plus lent que le drag'n drop.

- les tnef crees par outlook ne sont pas compris.

- le systeme des filtres a 3 wagons de retards sur kmail. Par exemple, kmail propose automatiquement de filtrer sur les champs X-Mailing-List et propose des filtres intelligents a partir d'un message.

- le fait d'avoir un filtre sur chaque compte est super lourd. J'ai des gens qui peuvent m'ecrire sur 3 comptes differents, je suis obliger de creer 3 filtres differents alors que je n'ai qu'une seule mailbox.

J'ai reporte tout ca dans la base, mais comme c'est plus des problemes d'ergonomie, ca ne reagit pas tres vite.

A part ca, il marche pas mal. Ah oui, il est quand meme vraiment lent aussi.

L'essentiel des autres projets majeurs sortent des mises à jour régulièrement (genre tous les 6 à 9 mois). Debian part déjà sur le principe d'un cycle plus long. Ca me parait dommage, ca veut dire que debian va de nouveau avoir une période où seule la version instable sera interessante à utiliser parce que à jour, avec les problèmes de la version instable.