enfin le piège java il a bon dos ; sachant que classpath est bien avancé
Et dire que j'avais cru qu'en précisant "version Sun" j'échapperais à une remarque sur Classpath... Certes, classpath avance à petits pas, mais on n'en est pas du tout au stade où on peut développer aveuglément avec le JDK de Sun et exécuter tout-pareil avec une jvm libre. C'est surtout dans l'autre sens que ça marche bien: on développe avec des outils libre et ça marche aussi avec le JRE de Sun.
Ceci étant, j'ai parlé du piège Java parce que tout le monde ici sait de quoi il s'agit, mais j'aurais aussi bien pu parler du piège Delphi ou n'importe quel langage pour lequel il n'existe pas de plateforme libre complète. Choisis celui que tu préfères.
Et puis en parlant de piège java ; tu as pense que tu exécute ton code sur un processeur non libre ?
Oui et puis osons aller plus loin: mon code génétique n'est pas libre, alors si je voulais aller jusqu'au bout de ma philosophie je devrais me flinguer tout de suite.
Plus sérieusement:
- Je peux avoir envie de modifier du code pour l'adapter à mes besoins, par contre modifier un processeur me semble nettement plus difficile, et par conséquent il m'importe moins d'avoir le droit de le faire
- Pour la programmation j'ai le choix entre des outils libres et des outils non libres, donc je peux raisonnablement choisir les outils libres. Dans le cas des processeurs, tant que le choix n'existe pas comment je pourrais choisir d'utiliser un processeur libre.
Si tu veux un argument un peu plus pertinent sur le même thème, demande moi pourquoi mon BIOS n'est pas libre...
Si tu as un flags sur les images non libres, ceux qui veulent un contenu 100% libre peuvent l'avoir
C'est bien ce que je voulais dire en soulignant la différence entre un programme reposant sur une plateforme non libre et Wikipedia: dans Wikipedia tu peux généralement enlever le contenu non libre et ça a toujours du sens, alors que dans le cas du logiciel si tu enlèves la plateforme il faut la remplacer par autre chose.
c'est tout de même bête de se priver de ce qui est disponible sous réserve que plus tard ce ne serait plus le cas
C'est cet argument qui fait la différence entre ceux qui dénoncent le "piège Java" et ceux qui s'obligent à n'utiliser que du libre. Dans un camp on dit "Java (version Sun) est disponible et utilisable gratuitement et légalement, ça serait dommage de s'en priver", et de l'autre camp on dit "oui mais ce n'est pas libre, et quelqu'un qui ne veut que du libre ne peut pas utiliser ton logiciel".
Ici le problème est similaire, avec quand même une petite différence: si on identifie les images non libres et qu'on les retire, l'encyclopédie est globalement encore utilisable. Ce qui soulève à mon avis une question:
- Si c'est utilisable sans images non libres, pourquoi y mettre des images non libres ? Est-ce que le fait d'avoir le logo Renault sur la page Renault vaut la peine de sacrifier la liberté globale de l'encyclopédie ?
- Si certaines images non libres sont nécessaires à la compréhension de l'article, est-ce qu'on peut toujours parler d'encyclopédie libre ?
Note que le "au plus" signifie "au choix de celui qui accepte la licence". Par conséquent, n'importe qui a la possibilité de faire un fork du programme "GPL 2+" en "GPL 2 seulement".
Le seul problème qui puisse survenir est que Y autorise dans sa GPL 4 à faire une version fermée du programme, et que cette possibilité soit exploitée par quelqu'un. Mais ça ne change rien aux droits qu'a X sur son programme.
Je ne trouve pas que Freeciv soit moche, c'est un bon compromis entre la quantité d'information à représenter et le fait que ces informations soient claires. Si on veut faire un truc plus "beau", il faut des images plus grosses, et dans ce cas là on peut représenter moins de surface de la carte.
Finalement c'est un peu comme les échecs, ce ne sont pas les pions les plus artistiques qui sont les plus agréables à utiliser pour jouer.
parce que Mono, ça n'a pas l'air être au niveau de classpath/gcj
Ça m'intrigue, cet acharnement (au sein de ce journal, ailleurs je ne sais pas) à descendre Mono alors que ton seul argument semble être "j'ai jamais rien vu de fini codé en Mono, mais je n'ai pas cherché".
Pour ma part je ne me suis pas penché sur la question, mais je suis déjà tombé sur quelques softs intéressants (Beagle, F-Spot, Monodevelop...) codés en C# avec Mono, et qui ont l'air de bien tourner. Comme soft compilé avec GCJ, je n'ai à ce jour rencontré qu'iRate (bon concept mais logiciel pas terrible). C'est tellement subjectif comme observation que je ne me risquerai pas à supposer que Mono est "plus avancé" que GCJ, mais je suis curieux de savoir pourquoi tu penses le contraire.
Des fois quand je joue, je lance un regard sur mon client IRC au mauvais moment, et je rate le mouvement de l'ordinateur. Ce n'est pas bien grave, mais ça pourrait être bien soit de mettre une bordure autour de la dernière case jouée, soit d'afficher un historique des coups.
Comparé à Sylpheed, je trouve que Balsa est une horreur. Je l'avais installé à ma mère parce que c'était léger et intégrer à Gnome, mais j'ai dû changer au bout de quelques mois pour diverses raisons dont les suivantes:
- impossible de convaincre ma mère de trier/archiver ses mails, et Balsa met 30 secondes à charger sa boîte de réceptions en s'ouvrant
- l'interface graphique pour visionner les pièces jointes est compliquée et illogique: il faut cliquer sur un onglet, choisir un élément d'un arbre, double-cliquer, puis choisir une action
- Balsa est incapable d'afficher les accents de certains messages, et incapable d'affiche certains autres messages si on ne choisir pas d'afficher le source du message.
Pour ma part j'utilise Evolution, j'aime bien aussi Sylpheed, mais je pense que Balsa a vraiment besoin d'une nouvelle GUI.
Et il se passe quoi quand quelqu'un installe le programme sur une machine ou LA bibliothèque qui "te plait/t'offre ce que tu veux" n'est pas présente ?
La solution choisie par la plupart des développeurs d'applications propriétaires est de compiler en statique, c'est à dire inclure le code utilisé de la bibliothèque dans l'exécutable. Comme ça, pas besoin d'avoir la bibliothèque présente sur la machine des utilisateurs, et pas de problème de compatibilité.
Ouais enfin ça tourne aussi sur mon Athlon 660 MHz avec 256 Mo de RAM, et je soupçonne que ça tournerait sur moins puissant que ça... c'est pas parce que tu as une grosse machine que ça nécessite une grosse machine.
L'intéret de la démo n'est pas tellement de faire un super jeu, mais de montrer qu'on peut intégrer du SVG dans une page web et l'animer avec du Javascript, de manière interactive.
Un truc qui te convaincra peut-être plus (ou pas): imagine que tu veuilles faire une carte du monde où les pays sont cliquables, avec avec un effet de rollover qui surligne le pays actuellement sous le pointeur. Étant donné la complexité des formes des pays, il semble assez compliqué de faire ça avec des images et du JS, comme les rollovers sont habituellement faits. En dehors de Java ou Flash, il y avait peu d'alternatives qui ne nécessitaient pas un horribe bricolage.
Avec SVG+Javascript, on peut faire ça très facilement ( http://ragondux.com/worldmap.xml(...) ). Pour l'instant Cairo (utilisé par Firefox) rame un peu, mais ça fonctionne. Et comme c'est intégré à la page, pour changer l'apparence d'un pays, il suffit d'attribuer un style (CSS) à l'élément correspondant à ce pays.
SVG/EcmaScript marche plutôt bien dans la beta 1 de Firefox Deer Park. J'ai joué un peu avec pour voir ce qu'on pouvait faire, j'avais quelques problèmes de fuites mémoire avec la version alpha mais tout semble résolu. Ça reste assez lent mais ça tourne.
Le problème étant bien sûr qu'il n'y a pas que Firefox au monde, et que je n'ai aucune idée de quand Konqueror, Safari, Opera et autres gèreront tout ça (si ce n'est pas déjà en route).
Une note positive quand même: du point de vue du développeur web, il me semble plus simple de faire une interface mixte SVG/XHTML qui soit utilisable par n'importe quel browser que faire la même chose avec Flash.
Arimaa est un jeu sympathique (bien qu'un peu long à jouer). Il y a juste un petit défaut: l'auteur du jeu a breveté son système, et impose une clause interdisant l'utilisation commerciale, ce qui empêche de faire un logiciel libre basé sur Arimaa. Je pense qu'en France on n'a pas la possibilité de breveter un système de jeu, mais visiblement aux USA c'est possible.
Il y a quelques temps, j'avais bricolé un truc en Ruby/GTK pour pouvoir jouer à Arimaa sans passer par l'horrible interface Flash du site. C'est mal codé, pas fini, on ne peut jouer qu'à deux, mais si jamais ça intéresse quelqu'un: http://software.ragondux.com/aribbaa/(...)
Le code source est libre, mais les images (et peut-être le moteur de règles) sont soumises à la licence sur le site d'Arimaa. En ce moment je ne m'occupe pas du logiciel (donc pas la peine de faire de bug reports), mais je m'y remettrai peut-être un jour.
Je ne suis pas sûr d'avoir correctement compris ton idée, mais si tu cherches un logiciel qui puisse valider tout seul un programme quelconque, c'est impossible.
on fixe plus précisément les règles d'entrée du langage (sa grammaire dans un premier temps). On a alors le cas de ce qui valide la grammaire, et de ce qui ne le valide pas, etc.
Si tu es obligé de changer la grammaire du langage compris par l'interpréteur que tu essayes de coder, alors tu te retrouves dans un cas où ton programme final sera différent de celui que tu voulais faire au départ. Par exemple si tu voulais coder un interpréteur LISP, et que ton IDE-magique t'oblige à restreindre la grammaire, à la fin tu n'auras pas un interpréteur LISP.
Plus généralement, tu ne peux pas systématiquement contourner le problème de l'utilisateur qui rentre une donnée qui fait boucler le programme. Ton IDE-magique ne peut pas toujours décider "ah mais dis donc, c'est une boucle infinie ça, il faut corriger".
si on ne peut pas tout tester, comme être fiable à 100% ?
Il y a des outils de preuves formelles de programmes, comme Coq, mais c'est très chiant à utiliser, donc ce n'est pas une solution pour ceux qui ont la flemme de tester une valeur de retour :)
Dans un premier temps, tu devrais essayer la programmation par contrat, c'est très efficace pour attraper la plupart des gros bugs, et ça demande assez peu d'effort de la part du programmeur. Par exemple en Eiffel, tu peux déclarer des prérequis sur tes fonctions ("ce paramètre là doit être compris entre 2 et 56"), une fonction peut promettre des choses aux autres ("la valeur que je retourne ne dépassera jamais 56"), et on peut aussi déclarer des invariants ("la valeur de cette variable ne sera jamais supérieure à 42"). En pratique si tu n'as pas une batterie de tests, tu ne peux pas être sûr qu'une de ces conditions ne sera pas violée, mais tu peux être sûr que si c'est le cas, tu n'auras pas de mal à trouver l'erreur.
Ton idee n'est applicable qu'a des programmes qui traitent des donnees limitees, sans quoi il peut devenir tres compliquer de les valider, ou meme de tomber aleatoirement sur un cas d'erreur si 99% des entrees possibles sont valides. La seules solution pour s'assurer que le code est tout le temps valide serait d'essayer toutes les entrees possibles.
Ce qui pose un probleme: admettons que tu veuilles ecrire un interpreteur pour un langage quelconque. Ton IDE va devoir simuler un utilisateur qui tape un script aleatoirement, mais comment va-t-il faire pour distinguer un comportement valide d'un comportement invalide ?
Admettons que le script qu'il produit soit conforme a la syntaxe du langage, l'IDE va pouvoir observer les cas suivants:
1- l'interpreteur execute le script et produit un resultat
2- l'interpreteur execute le script mais s'arrete sur une erreur
3- l'interpreteur ne s'arrete pas
Seul le cas 2 peut-etre traite efficacement: on a trouve une erreur, il faut la resoudre. Dans le cas 1, on ne sait pas si le resultat obtenu est valide, dans le cas 3, on ne sait pas si le fait que l'interpreteur ne s'arrete pas est normal ou non.
Et pourtant! je révais d'une interface graphique "interprété", souple, jolie/elegante, basée sur de standard (XML) et "portable" (un super remplacant a TCL/TK quoi).
Dans une certaine mesure, GTK+Glade+(Python|Ruby) fait ce que tu veux: tu as une description de ton interface en XML, c'est interprété, souple, et ça marche sur toutes les plateformes où GTK est porté.
Pour quelqu'un qui a déjà fait des interfaces graphiques avec SWING (par exemple), je trouve que GTK n'est pas compliqué du tout à aborder: il utilise essentiellement les mêmes concepts (qui sont quand même assez classiques).
Les "layout managers" deviennent des "containers", les "event listeners" deviennent des "signals", et voilà, on peut directement se lancer en gardant l'API sous le coude.
Par contre, c'est vrai que la documentation manque parfois, surtout sur les widgets les moins utilisés ou les plus récents/complexes.
wget klik.atekon.de/client/install -O -|sh [...] en root [ou] en user
Attention les enfants, si vous essayez ca a la maison sur l'ordinateur de vos parents, faites-le en utilisateur normal.
A ma connaissances les premiers a avoir propose ce genre de methodes d'installation, c'etait Ximian pour installer Gnome, mais ca m'a toujours fait peur de piper un truc tire du web directement dans un shell, sans meme le lire :)
en clair beagle c'est bien ; mais c'est pas la panacée non plus
Ouais enfin, personne n'a prétendu que c'était la panacée ou que ça évitait d'avoir à s'organiser, le monsieur demandait à quoi ça servait et je lui ai répondu. Ça ne sert pas à classer ses données, ça sert à faire des recherches sur le contenu des données ou des métadonnées. Effectivement, dans les exemples tu donnes on n'a ni données ni métadonnées et donc ça ne marche pas très bien.
Mais bon vais me faire moinsser par les 313373 parce que je suis pas de leurs avis.
T'as pas de chance d'être environnés de tant d'imbéciles hein ?
Ça sert à retrouver en une seule requête tout ce qui dans tes documents fait référence à la 5ième Conférence des Pingouins Velus, c'est à dire:
- le mail d'invitation que tu as reçu, et qui contient les dates et coordonnées
- le papier que tu as soumis à cette conférence
- la conversation faite via Gaim avec un des relecteurs du-dit papier
- le blog d'un des autres intervenants, qui relate ce qu'il a vu de la conférence
- les photos de la conférence
- les enregistrement des présentations, au format Ogg Vorbis ou bien en vidéos
Pour ce qui est des photos/enregistrements/papiers, il est bien sûr possible d'organiser tout ça en faisant un dossier 5e_Conference_Pingouins_Velus... ou bien en faisant un découpage Photos/Pingouins_Velus, Audio/Pingouins_Velus, etc. Mais avec un truc comme Beagle, l'avantage c'est que quelle que soit ton organisation, tu peux retrouver tout en une requête, et qu'en plus ça se met à jour dynamiquement. Un peu comme les VFolders d'Evolution, mais avec un champ d'application plus large.
Autre possibilité, en une requête, retrouver la liste des PDF que tu possèdes qui font référence à ta présentation à la Conf' des Pingouins Velus.
ça ne va pas regarder si beagle est installé, alors ça va te proposer tous les plugins possibles même si ceux-ci n'ont aucune raison de t'intéresser car tu n'as pas l'appli en question d'installée.
Mais peut-être que je ne connaissais pas Beagle, et qu'en découvrant qu'il peut indexer mes emails je vais trouver ça intéressant. Pour moi c'est une feature, de suggérer les plugins les plus populaires.
Et si je choisis d'installer le plugin beagle-evolution, ça installe beagle, donc tout va bien.
En plus, certains paquets proposés vont alors ramener 150 Mo de dépendances.
Les paquets recommandés ou suggérés ne sont pas installés d'office, ils sont tous en option. Je ne comprends pas ta remarque: quelle que soit la manière dont on suggère à l'utilisateur d'installer un truc, s'il n'a pas les dépendances il va bien falloir les installer.
D'ailleurs classpath recherche des developpeur si ca t'interesse.
Je ne fais que souligner une différence entre les deux cas évoqués, personnellement je m'en fiche de Java.
En fait, pour être plus précis, un programme développé avec Mono c'est comme un programme développé avec GCJ: peu importe que derrière ce soit C# ou Java, c'est exécutable en n'utilisant que des logiciels libres, donc ça échappe à ce que RMS appelle le "piège Java". Ceux qui prennent le risque de tomber dans le piège sont ceux qui développement avec les outils de dev de Microsoft (pour .NET) ou de Sun (pour Java) et qui pensent pouvoir faire un logiciel entièrement libre de cette manière.
Voilà, formulé comme ça, j'ai moins l'air d'agresser les pauvres développeurs de classpath ?
[^] # Re: Entre 3 et 20, suivant comment est définit un pays
Posté par Yusei (Mastodon) . En réponse au sondage Nombre de pays où je suis passé :. Évalué à 10.
[^] # Re: un grand merci
Posté par Yusei (Mastodon) . En réponse au journal Dernier jour de scrutin sur Wikipedia concernant les images en "fair use". Évalué à 4.
Et dire que j'avais cru qu'en précisant "version Sun" j'échapperais à une remarque sur Classpath... Certes, classpath avance à petits pas, mais on n'en est pas du tout au stade où on peut développer aveuglément avec le JDK de Sun et exécuter tout-pareil avec une jvm libre. C'est surtout dans l'autre sens que ça marche bien: on développe avec des outils libre et ça marche aussi avec le JRE de Sun.
Ceci étant, j'ai parlé du piège Java parce que tout le monde ici sait de quoi il s'agit, mais j'aurais aussi bien pu parler du piège Delphi ou n'importe quel langage pour lequel il n'existe pas de plateforme libre complète. Choisis celui que tu préfères.
Oui et puis osons aller plus loin: mon code génétique n'est pas libre, alors si je voulais aller jusqu'au bout de ma philosophie je devrais me flinguer tout de suite.
Plus sérieusement:
- Je peux avoir envie de modifier du code pour l'adapter à mes besoins, par contre modifier un processeur me semble nettement plus difficile, et par conséquent il m'importe moins d'avoir le droit de le faire
- Pour la programmation j'ai le choix entre des outils libres et des outils non libres, donc je peux raisonnablement choisir les outils libres. Dans le cas des processeurs, tant que le choix n'existe pas comment je pourrais choisir d'utiliser un processeur libre.
Si tu veux un argument un peu plus pertinent sur le même thème, demande moi pourquoi mon BIOS n'est pas libre...
C'est bien ce que je voulais dire en soulignant la différence entre un programme reposant sur une plateforme non libre et Wikipedia: dans Wikipedia tu peux généralement enlever le contenu non libre et ça a toujours du sens, alors que dans le cas du logiciel si tu enlèves la plateforme il faut la remplacer par autre chose.
[^] # Re: un grand merci
Posté par Yusei (Mastodon) . En réponse au journal Dernier jour de scrutin sur Wikipedia concernant les images en "fair use". Évalué à 5.
C'est cet argument qui fait la différence entre ceux qui dénoncent le "piège Java" et ceux qui s'obligent à n'utiliser que du libre. Dans un camp on dit "Java (version Sun) est disponible et utilisable gratuitement et légalement, ça serait dommage de s'en priver", et de l'autre camp on dit "oui mais ce n'est pas libre, et quelqu'un qui ne veut que du libre ne peut pas utiliser ton logiciel".
Ici le problème est similaire, avec quand même une petite différence: si on identifie les images non libres et qu'on les retire, l'encyclopédie est globalement encore utilisable. Ce qui soulève à mon avis une question:
- Si c'est utilisable sans images non libres, pourquoi y mettre des images non libres ? Est-ce que le fait d'avoir le logo Renault sur la page Renault vaut la peine de sacrifier la liberté globale de l'encyclopédie ?
- Si certaines images non libres sont nécessaires à la compréhension de l'article, est-ce qu'on peut toujours parler d'encyclopédie libre ?
[^] # Re: Une pitite question...
Posté par Yusei (Mastodon) . En réponse à la dépêche Interview de Richard Stallman. Évalué à 7.
Le seul problème qui puisse survenir est que Y autorise dans sa GPL 4 à faire une version fermée du programme, et que cette possibilité soit exploitée par quelqu'un. Mais ça ne change rien aux droits qu'a X sur son programme.
[^] # Re: Je vais finir ma partie
Posté par Yusei (Mastodon) . En réponse à la dépêche Freeciv 2.0.6. Évalué à 7.
Finalement c'est un peu comme les échecs, ce ne sont pas les pions les plus artistiques qui sont les plus agréables à utiliser pour jouer.
[^] # Re: Manque d'arguments pour Qt... Help !
Posté par Yusei (Mastodon) . En réponse au journal Manque d'arguments pour Qt... Help !. Évalué à 3.
Ça m'intrigue, cet acharnement (au sein de ce journal, ailleurs je ne sais pas) à descendre Mono alors que ton seul argument semble être "j'ai jamais rien vu de fini codé en Mono, mais je n'ai pas cherché".
Pour ma part je ne me suis pas penché sur la question, mais je suis déjà tombé sur quelques softs intéressants (Beagle, F-Spot, Monodevelop...) codés en C# avec Mono, et qui ont l'air de bien tourner. Comme soft compilé avec GCJ, je n'ai à ce jour rencontré qu'iRate (bon concept mais logiciel pas terrible). C'est tellement subjectif comme observation que je ne me risquerai pas à supposer que Mono est "plus avancé" que GCJ, mais je suis curieux de savoir pourquoi tu penses le contraire.
[^] # Re: C'est quoi ?
Posté par Yusei (Mastodon) . En réponse au journal Biloba 0.3. Évalué à 3.
# Encore une remarque
Posté par Yusei (Mastodon) . En réponse au journal Biloba 0.3. Évalué à 3.
En tout cas c'est un jeu sympa, merci
[^] # Re: Client mail
Posté par Yusei (Mastodon) . En réponse au journal Migration vers Gnome.. Évalué à 3.
- impossible de convaincre ma mère de trier/archiver ses mails, et Balsa met 30 secondes à charger sa boîte de réceptions en s'ouvrant
- l'interface graphique pour visionner les pièces jointes est compliquée et illogique: il faut cliquer sur un onglet, choisir un élément d'un arbre, double-cliquer, puis choisir une action
- Balsa est incapable d'afficher les accents de certains messages, et incapable d'affiche certains autres messages si on ne choisir pas d'afficher le source du message.
Pour ma part j'utilise Evolution, j'aime bien aussi Sylpheed, mais je pense que Balsa a vraiment besoin d'une nouvelle GUI.
[^] # Re: pouah !
Posté par Yusei (Mastodon) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 10.
La solution choisie par la plupart des développeurs d'applications propriétaires est de compiler en statique, c'est à dire inclure le code utilisé de la bibliothèque dans l'exécutable. Comme ça, pas besoin d'avoir la bibliothèque présente sur la machine des utilisateurs, et pas de problème de compatibilité.
[^] # Re: urg
Posté par Yusei (Mastodon) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 3.
Ouais enfin ça tourne aussi sur mon Athlon 660 MHz avec 256 Mo de RAM, et je soupçonne que ça tournerait sur moins puissant que ça... c'est pas parce que tu as une grosse machine que ça nécessite une grosse machine.
L'intéret de la démo n'est pas tellement de faire un super jeu, mais de montrer qu'on peut intégrer du SVG dans une page web et l'animer avec du Javascript, de manière interactive.
Un truc qui te convaincra peut-être plus (ou pas): imagine que tu veuilles faire une carte du monde où les pays sont cliquables, avec avec un effet de rollover qui surligne le pays actuellement sous le pointeur. Étant donné la complexité des formes des pays, il semble assez compliqué de faire ça avec des images et du JS, comme les rollovers sont habituellement faits. En dehors de Java ou Flash, il y avait peu d'alternatives qui ne nécessitaient pas un horribe bricolage.
Avec SVG+Javascript, on peut faire ça très facilement ( http://ragondux.com/worldmap.xml(...) ). Pour l'instant Cairo (utilisé par Firefox) rame un peu, mais ça fonctionne. Et comme c'est intégré à la page, pour changer l'apparence d'un pays, il suffit d'attribuer un style (CSS) à l'élément correspondant à ce pays.
[^] # Re: urg
Posté par Yusei (Mastodon) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 4.
Il y a quelques exemples sur http://www.croczilla.com/svg/samples/(...) et je dois dire que c'est la démo de Tetris en SVG qui m'a donné envie de m'y mettre.
Le problème étant bien sûr qu'il n'y a pas que Firefox au monde, et que je n'ai aucune idée de quand Konqueror, Safari, Opera et autres gèreront tout ça (si ce n'est pas déjà en route).
Une note positive quand même: du point de vue du développeur web, il me semble plus simple de faire une interface mixte SVG/XHTML qui soit utilisable par n'importe quel browser que faire la même chose avec Flash.
[^] # Re: Arimaa
Posté par Yusei (Mastodon) . En réponse à la dépêche Libération de Biloba, un nouveau jeu de plateau. Évalué à 4.
Il y a quelques temps, j'avais bricolé un truc en Ruby/GTK pour pouvoir jouer à Arimaa sans passer par l'horrible interface Flash du site. C'est mal codé, pas fini, on ne peut jouer qu'à deux, mais si jamais ça intéresse quelqu'un:
http://software.ragondux.com/aribbaa/(...)
Le code source est libre, mais les images (et peut-être le moteur de règles) sont soumises à la licence sur le site d'Arimaa. En ce moment je ne m'occupe pas du logiciel (donc pas la peine de faire de bug reports), mais je m'y remettrai peut-être un jour.
[^] # Re: I had a dream...
Posté par Yusei (Mastodon) . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 6.
Je ne suis pas sûr d'avoir correctement compris ton idée, mais si tu cherches un logiciel qui puisse valider tout seul un programme quelconque, c'est impossible.
Si tu es obligé de changer la grammaire du langage compris par l'interpréteur que tu essayes de coder, alors tu te retrouves dans un cas où ton programme final sera différent de celui que tu voulais faire au départ. Par exemple si tu voulais coder un interpréteur LISP, et que ton IDE-magique t'oblige à restreindre la grammaire, à la fin tu n'auras pas un interpréteur LISP.
Plus généralement, tu ne peux pas systématiquement contourner le problème de l'utilisateur qui rentre une donnée qui fait boucler le programme. Ton IDE-magique ne peut pas toujours décider "ah mais dis donc, c'est une boucle infinie ça, il faut corriger".
Il y a des outils de preuves formelles de programmes, comme Coq, mais c'est très chiant à utiliser, donc ce n'est pas une solution pour ceux qui ont la flemme de tester une valeur de retour :)
Dans un premier temps, tu devrais essayer la programmation par contrat, c'est très efficace pour attraper la plupart des gros bugs, et ça demande assez peu d'effort de la part du programmeur. Par exemple en Eiffel, tu peux déclarer des prérequis sur tes fonctions ("ce paramètre là doit être compris entre 2 et 56"), une fonction peut promettre des choses aux autres ("la valeur que je retourne ne dépassera jamais 56"), et on peut aussi déclarer des invariants ("la valeur de cette variable ne sera jamais supérieure à 42"). En pratique si tu n'as pas une batterie de tests, tu ne peux pas être sûr qu'une de ces conditions ne sera pas violée, mais tu peux être sûr que si c'est le cas, tu n'auras pas de mal à trouver l'erreur.
[^] # Re: I had a dream...
Posté par Yusei (Mastodon) . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 5.
Ce qui pose un probleme: admettons que tu veuilles ecrire un interpreteur pour un langage quelconque. Ton IDE va devoir simuler un utilisateur qui tape un script aleatoirement, mais comment va-t-il faire pour distinguer un comportement valide d'un comportement invalide ?
Admettons que le script qu'il produit soit conforme a la syntaxe du langage, l'IDE va pouvoir observer les cas suivants:
1- l'interpreteur execute le script et produit un resultat
2- l'interpreteur execute le script mais s'arrete sur une erreur
3- l'interpreteur ne s'arrete pas
Seul le cas 2 peut-etre traite efficacement: on a trouve une erreur, il faut la resoudre. Dans le cas 1, on ne sait pas si le resultat obtenu est valide, dans le cas 3, on ne sait pas si le fait que l'interpreteur ne s'arrete pas est normal ou non.
[^] # Re: XUL !
Posté par Yusei (Mastodon) . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 2.
Dans une certaine mesure, GTK+Glade+(Python|Ruby) fait ce que tu veux: tu as une description de ton interface en XML, c'est interprété, souple, et ça marche sur toutes les plateformes où GTK est porté.
[^] # Re: Mon expérience
Posté par Yusei (Mastodon) . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 4.
Les "layout managers" deviennent des "containers", les "event listeners" deviennent des "signals", et voilà, on peut directement se lancer en gardant l'API sous le coude.
Par contre, c'est vrai que la documentation manque parfois, surtout sur les widgets les moins utilisés ou les plus récents/complexes.
[^] # Re: Aaaah que c'est bon d'être LIBRE de choisir!
Posté par Yusei (Mastodon) . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 10.
ou Perl, ou Python, ou Ruby, ou Java, ou Eiffel, ou Objective Caml, ou C#, ou sûrement plein d'autres que je n'ai pas encore essayés :)
Autant GTK+ est assez lourd à utiliser en C, autant dans un langage de plus haut niveau comme Ruby, c'est très agréable.
[^] # Re: Installation
Posté par Yusei (Mastodon) . En réponse à la dépêche Envie de "kliker" ?. Évalué à 5.
Attention les enfants, si vous essayez ca a la maison sur l'ordinateur de vos parents, faites-le en utilisateur normal.
A ma connaissances les premiers a avoir propose ce genre de methodes d'installation, c'etait Ximian pour installer Gnome, mais ca m'a toujours fait peur de piper un truc tire du web directement dans un shell, sans meme le lire :)
[^] # Re: Une référence ?
Posté par Yusei (Mastodon) . En réponse au journal Appleseed. Évalué à 3.
( http://chrisix.free.fr/dotclear/(...) )
[^] # Re: Une question
Posté par Yusei (Mastodon) . En réponse à la dépêche Beagle : Un "Desktop Search" sous Linux. Évalué à 3.
Ouais enfin, personne n'a prétendu que c'était la panacée ou que ça évitait d'avoir à s'organiser, le monsieur demandait à quoi ça servait et je lui ai répondu. Ça ne sert pas à classer ses données, ça sert à faire des recherches sur le contenu des données ou des métadonnées. Effectivement, dans les exemples tu donnes on n'a ni données ni métadonnées et donc ça ne marche pas très bien.
T'as pas de chance d'être environnés de tant d'imbéciles hein ?
[^] # Re: OASIS en export
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie d'OpenOffice.org 1.1.5. Évalué à 2.
[^] # Re: Une question
Posté par Yusei (Mastodon) . En réponse à la dépêche Beagle : Un "Desktop Search" sous Linux. Évalué à 9.
- le mail d'invitation que tu as reçu, et qui contient les dates et coordonnées
- le papier que tu as soumis à cette conférence
- la conversation faite via Gaim avec un des relecteurs du-dit papier
- le blog d'un des autres intervenants, qui relate ce qu'il a vu de la conférence
- les photos de la conférence
- les enregistrement des présentations, au format Ogg Vorbis ou bien en vidéos
Pour ce qui est des photos/enregistrements/papiers, il est bien sûr possible d'organiser tout ça en faisant un dossier 5e_Conference_Pingouins_Velus... ou bien en faisant un découpage Photos/Pingouins_Velus, Audio/Pingouins_Velus, etc. Mais avec un truc comme Beagle, l'avantage c'est que quelle que soit ton organisation, tu peux retrouver tout en une requête, et qu'en plus ça se met à jour dynamiquement. Un peu comme les VFolders d'Evolution, mais avec un champ d'application plus large.
Autre possibilité, en une requête, retrouver la liste des PDF que tu possèdes qui font référence à ta présentation à la Conf' des Pingouins Velus.
[^] # Re: je crois que je vais m'en passer
Posté par Yusei (Mastodon) . En réponse à la dépêche Beagle : Un "Desktop Search" sous Linux. Évalué à 2.
Mais peut-être que je ne connaissais pas Beagle, et qu'en découvrant qu'il peut indexer mes emails je vais trouver ça intéressant. Pour moi c'est une feature, de suggérer les plugins les plus populaires.
Et si je choisis d'installer le plugin beagle-evolution, ça installe beagle, donc tout va bien.
Les paquets recommandés ou suggérés ne sont pas installés d'office, ils sont tous en option. Je ne comprends pas ta remarque: quelle que soit la manière dont on suggère à l'utilisateur d'installer un truc, s'il n'a pas les dépendances il va bien falloir les installer.
[^] # Re: Hum....
Posté par Yusei (Mastodon) . En réponse à la dépêche Beagle : Un "Desktop Search" sous Linux. Évalué à 10.
Je ne fais que souligner une différence entre les deux cas évoqués, personnellement je m'en fiche de Java.
En fait, pour être plus précis, un programme développé avec Mono c'est comme un programme développé avec GCJ: peu importe que derrière ce soit C# ou Java, c'est exécutable en n'utilisant que des logiciels libres, donc ça échappe à ce que RMS appelle le "piège Java". Ceux qui prennent le risque de tomber dans le piège sont ceux qui développement avec les outils de dev de Microsoft (pour .NET) ou de Sun (pour Java) et qui pensent pouvoir faire un logiciel entièrement libre de cette manière.
Voilà, formulé comme ça, j'ai moins l'air d'agresser les pauvres développeurs de classpath ?