fbilhaut a écrit 17 commentaires

J'ai programmé une seule fois en Java avec l'api Swing

Et donc tu te sens autorisé à faire des commentaires à l'emporte pièce sur ce langage, alors que de ton propre aveu tu ne le connais pas ou presque. Bien bien...

Le principe "classique" de publication scientifique est aussi d'avoir une revue de l'aricle par des "peers". Ça permet d'éviter de publier n'importe quoi (enfin... ça limite le n'importe quoi). C'est hélas là que beaucoup de copinage et de réglements de comptes ont lieu, d'accord.

N'oublions pas, en ce qui concerne certaines confs internationales et dites "sérieuses", que le reviewing se fait de façon anonyme. Dans ce cas il faut soumettre un papier sans les coordonnées des auteurs, et se débrouiller pour éviter d'employer la première personne quand on se cite. Après, c'est vrai que ce n'est pas toujours facile, et qu'un relecteur qui le veut vraiment peut toujours trouver un moyen d'identifier le ou les auteurs. Mais je pense qu'il ne faut tout de même pas exagérer la part du copinage dans le processus de sélection. Elle existe forcément, mais j'ose espérer que l'intégrité prend globalement le dessus...

Et c'est tellement vrai...

Je ne sais pas si tu es ironique, mais en tout cas je n'ai même pas essayé, bien-sûr. Il faut être clair : ou le format est ouvert ou il ne l'est pas, mais distribuer un schéma sous X restrictions légales + Y restrictions techniques, ça fait autant de raisons de les ignorer. Malheureusement on aura toujours intérêt à pouvoir importer des documents Word, et il faudra bien y passer...

Ce qui à mourir de rire (jaune), c'est que quand on essaie de télécharger les schémas et leur documentation, on récupère... un fichier ".exe" !!! Ca c'est de l'ouverture : "on vous autorise à lire nos schémas, mais pour extraire le contenu du paquet il faut une machine Windows". Gasp :(

> > - export PDF
> C'est un peu buggé, mais je crois bien qu'Office le fait

A priori non, pas sans une "imprimante PDF" (toutes payantes à ma connaissance). Il est bien-sûr toujours possible d'imprimer dans un fichier via un driver PostScript avant de convertir en PDF grâce aux outils du libres portés sous Windows... Pas super pratique ;o)

En premier lieu, on ne dit pas "un treetagger" mais "un tagger": TreeTagger est un tagger (ou étiqueteur morphologique) parmi d'autres. Son nom provient du fait qu'il est basé sur un arbre de décision.

Et, plus important : un étiqueteur NE FAIT PAS d'analyse syntaxique : il permet "seulement" d'attribuer à chaque mot une étiquette correspondant à sa catégorie morphosyntaxique (par exemple : "nom", "déterminant", "verbe", etc), et souvent le lemme (forme "canonique" du mot). C'est effectivement un sujet de recherche en soi, même si les étiqueteurs actuels donnent de plutôt bons résultats.

En revanche, de l'étiquetage à l'analyse syntaxique il y a un gouffre !!! Là pour le coup, ca reste encore une tâche que l'on a bien du mal à résoudre automaiquement de façon fiable. J'ajouterais que de l'analyse syntaxique à la correction grammaticale automatique, il y a encore un autre pas à franchir (surtout si on veut proposer des réécritures syntaxiquement correctes).

Et il faut aussi avoir conscience qu'un correcteur grammatical pas assez fiable est absolument inutile : on perd plus de temps sur des fausses erreurs qu'à corriger les vraies (d'ailleurs bcp de gens on rapidement abandonné celui de Word pour cette raison).

Bref : si tu peux faire un correcteur fiable en trois jours à partir d'un "simple" tagger, je te conseille de publier auprès de la communeauté TALN le plus vite possible ;o)

Ceci est configurable, au moins sous KDE. Et meme sous windows, je crois me souvenir qu'il en va de meme. Après, la configuration par défaut ne peut pas convenir à tout le monde...

Quand à Steve Jobs, c'est quand-meme quelqu'un qui a eu pas mal de bonnes idées, AMHA (lui ou ses collaborateurs). N'oublions pas que lorsque le premier Mac est sorti, il laissait loin derrière lui tous les autres ordinateurs personnels de l'époque. Et c'est tout à fait normal de recopier par la suite ce qui marche, tous les domaines progressent de cette façon, brique après brique.

Ah ? Et c'est écrit dans le ciel qu'une tab doit faire 8 "caractères" ? Apparemment c'est une religion chez toi ;o)

"A huit caractères la tabulation tu régleras."

Justement, "tab" est représenté par *un seul* caractère qui veut dire "j'indente ici". L'intérêt est que chacun est libre de l'interpréter comme il veut (i.e. lui donner la largeur qu'il veut). C'est un peu comme un tag en HTML : il sert à marquer un paragraphe, mais ne dit pas comment il doit être affiché (retrait ou non, espace avec le § précédent, etc). En gros, une tabulation est plutôt porteuse de sens que de forme.

L'intérêt est évident : chacun idente son code en *visualisant* les tabs comme il le souhaite, et les autres peuvent le relire avec la visualisation qui leur convient.

Si seulement tout le monde pouvait comprendre ça et éviter de configurer son éditeur pour transformer les tabs en espaces (donc de longueur fixe), ça aiderait bcp la relecture du code (surtout maintenant qu'on doit souvent "lire" du xml).

Est-ce que mozilla intègre vraiment bcp d'ajouts à CSS (ou d'autres normes) ? J'ai entendu parler d'une propriété pour arrondir les côtés des boîtes, mais j'ose espérer que Mozilla ne pratique pas trop ce genre de choses... On sait très bien que cela mène les gens qui ne testent que sur un seul navigateur (ou qui se foutent de l'interopérabilité) à créer des applications spécifiques. (microsoft le sait malheureusement trop bien d'ailleurs).

JEdit n'est spécifiquement dédié à XML, mais fait du très bon boulot : quand il a la DTD, il valide "à la volée", propose la completion des tags et de leurs attributs, et ferme les tags tout seul (dés que l'on tape "</"). Difficile de s'en passer quand on y a pris goût. Seul bémol : il faut une machine rapide dés qu'on utilise des grosses DTD (par ex. Docbook). Je ne crois pas qu'il sache exploiter les XSchemas, cela-dit...

http://www.jedit.org(...)

Ton discours ne me paraît pas clair... En fait les RC (Release Candidate) sont précisemment destinées aux utilisateurs finaux qui souhaitent apporter leur pierre à la chasse aux bugs, en rapportant notemment ce que l'on appelle des "show stoppers", bugs majeurs qui forceront à repousser la release.

D'ailleurs, comme tu le précises toi-même, les RCs viennent après des alphas et des betas qui elles sont plutôt réservées aux utilisateurs plus expérimentés, et qui sont éventuellement prêts à se lancer dans des séances de déboguages.

Quand on ne peut pas utiliser xinerama (par exemple quand on a deux serveurs X sur deux machine différentes), on peut toujours se rabattre sur "xmove". C'est un serveur X "virtuel" qui redirige les clients vers l'un ou l'autre des displays configurés...

Il semble que synergy + xmove forme un couple intéressant pour faire du dual head avec deux machines...

http://www.ensta.fr/internet/unix/misc/xmove.html(...)

L'article ne le mentionne pas, mais Linux est retenu face à Windows car le portage de Solaris vers Linux est vraiment plus facile (une simple recompilation ?)

Non, une recompilation ne suffit malheureusement pas (en général). La raison est simple: tout ce qui sort de l'api C de base n'est pas standardisé, et même s'il exise des normes comme Posix, il s'avère dans les faits qu'il n'y a pas deux Unix qui se comportent exactement de la même façon. C'est triste à dire, mais il existe toujours de subtiles différences, spécifiées en tout petit en bas des man pages. Quand ces différences portent sur des éléments aussi importants que les threads ou les entrées/sorties, on arrive très vite au désastre et aux bugs très bien cachés... Heureusement, c'est tout de même plus simple que le portage sur Win32...

Il n'y a pas non plus que celles de Stallmann qui sifflent !! L'offre proposée aujourd'hui par ce qu'on appelle GNU/Linux est le fruit de tous les contributeurs ayant participé aux différents projets qui le composent, et pas seulement des "stars" de la scène open-source...

On peut observer à longueur de temps, et en particulier sur linuxfr (cf. la news sur je jdk 1.4), une confusion présentant Netbeans comme une version open-source de Forte, dont Sun aurait ouvert les sources... CECI EST TOTALEMENT FAUX!!!
En fait, Forte est bien basé sur Netbeans, mais ce n'est pas Sun qui est à l'origine de ce soft, et il ne risque donc pas d'en avoir ouvert les sources puisque ce ne sont pas les siennes !!
Je crains que cette confusion fasse beaucoup de mal à Netbeans, ce qui est dommage vu la très bonne qualité de ce produit, qui ne doit rien à Sun...

En fait la plupart des tookits ne sont pas thread-safes, ou plutût l'interface graphique ne peut être panipulée que par une seule thread (cf MFC ou Java). C'est à mon avis assez cohérent, puisque tous les tookits sont basés sur une boucle d'événements, ce qui impose une gestion particulière des threads. Et bien souvent, il ne suffit pas de faire de l'exclusion mutuelle à la main puisque justement on ne maîtrise pas la boucle d'événements et que l'on ne peut donc pas se placer en exclusion mutuelle avec elle.

D'ailleurs cela ne pose pas de problème en général, et c'est même tout à fait logique. Les GUI sont de toute façon dirigées par l'utilisateur, et le plus souvent il n'y a pas lieu de la manipuler de façon parallèle.

Et quand c'est vraiment nécessaire, il suffit de s'insérer dans la boucle d'événements. Par exemple, en Java avec Swing, il suffit d'utiliser les méthodes SwingUtilities.invokeLater() ou SwingUtilities.invokeAndWait()...

PS: que les premières lignes de ce message ne vous fassent pas croire que je considère MFC comme un framework valable...