CrEv a écrit 4577 commentaires

je n'ai jamais touché aux polices sous java. Mais j'ai travaillé quelques temps sur un soft qui lui devait gérer les polices (une sorte de moteur de rendu de texte "vectoriel" - car c'est pas exactement ça - avec des transformations, rotations et tout le bordèl qui va avec)
Et y'a pas à dire, une bonne gestion de polices c'est très très compliqué.
Entre les différents formats, les polices parfois incorrectes et pas mal de problèmes liés aux calculs des emplacements de lettres, c'est vraiment bordélique (il suffit de regarder comment est fait freetype pour avoir une idée)
Si on rajoute les problèmes d'interligne, de lettrines, ...
d'ailleurs il est assez intéressant de tapper un même texte, même paramétrage, même police, même taille, ... sur plusieurs logiciels (prendre quark et indesign pour ceux qui ont, et rajouter scribus) et de regarder les différences. C'est parfois énorme !

D'ailleurs, pour ceux qui ont un vieux firefox par exemple (avant cairo je dirais, mais sans grande conviction), très souvent en sélectionnant une portion d'une ligne de texte contenant plus d'un style on arrive à faire bouger les lettres (quelques unes vont se décaler d'un px par exemple, c'est peu mais ça se voit). Tout ça à cause de la manière dont était calculés les emplacements des lettres.

M'enfin, tout ça pour souhaiter un bon courage aux développeurs qui vont s'en charger (c'est galère mais tout de même intéressant, sans compter les gruges pour les écrans tft, et tout plein d'autres bonnes choses ;-) )

l'intérêt est justement mécanique et surtout pas visuel.
Il est très courant d'utiliser des résines chargées (mélange de résine et de particules de métaux, de céramique, ...)
Les particules viennent en général apporter des propriétés que les matériaux de base n'ont pas, souvent du point de vue rigidité.

Il est par exemple courant de réaliser des moules par procédés de prototypage rapide, en employant des résines chargées de métal. On arrive donc à avoir des pièces suffisament solides, ne se déformant pas / peu à la chaleur pour pouvoir être moulées ensuite.

Exemple tiré de http://fr.wikipedia.org/wiki/St%C3%A9r%C3%A9olithographie :

Les objets tels quels sont inutilisables de par leur faible résistance mécanique : ils sont employés pour former des moules.

Une dérive de cette méthode est l'insertion de poudres céramiques (alumine, zircone, hydroxyapatite...) à l'intérieur du mélange. La suspension une fois insolée forme un réseau polymère emprisonnant les particules minérales. Un traitement thermique de l'objet permet d'obtenir une céramique dense.

Application : Les propriétés des céramiques obtenues par cette technique sont équivalentes aux procédés traditionnels (coulage, pressage...), les objets sont donc employables tels quels. Modèles de fonderie, prototypes pour validation des formes, prothèses médicales, petites séries de formes très complexes pour tout type d'industries ...

En fait c'est surtout qu'il ne faut pas confondre le terme "Alsace-Lorraine" avec Alsace et Lorraine...
En réalité (voir http://fr.wikipedia.org/wiki/Alsace-Moselle pour les détails) la France et l'Allemagne se battaient l'Alsace (sauf le territoire de belfort), les 3/4 de la Moselle, 1/4 de la Meurthe et 3 cantons des Vosges.
En regardant les frontières actuelles, cela correspond simplement à l'Alsace (hors Belfort) et la Moselle car les autres territoires non occupés ont été rattachés à la Meurthe pour donner la Meurthe et Moselle.

Par contre, moi j'aimerais bien qu'on arrête de constamment mettre Allemagne et Alsace dans le même sac (oui je sais c'était probablement de l'humour mais entre ça et entendre parler de "shleu" tous les jours ça me gonfle vraiment beaucoup !)

ok, désolé, j'avais mal compris alors

Je ne félicite pas le dev d'applis non-libre, mais je ne le torpille pas : c'est débille et ça ne mène nulle part

Pas si sur...
le fait que kde ait utilisé une techno non libre à plusieurs avantages :
- qt ne serait peut-être pas releasé aujourd'hui sous gpl, et ce quelque soit la plateforme
- (le plus trollifique de tous :) gnome n'existerait peut-être pas... (un bien ou un mal, à vous de choisir ;-) )

(je savais bien que j'avais oublié un truc...)

Je parle d'acheter, déjà que l'utilisateur rechigne a acheter son OS

Merci d'arrêter de tout confondre (ou te prendre ton cas pour une généralité)

Personnellement si je suis sous linux c'est pour la liberté et le fait que je trouve ce système meilleur.
Le côté gratuit ou non ... les 5 dernières années j'ai acheté des versions boites. Non pas pour les softs proprios s'y trouvant mais pour que linux et les entreprises qui travaillent dessus en vive.

J'ai jamais fait le calcul global mais ça me reviendrait surement moins cher d'acheter un xp (qui en plus était livré avec mes machines) donc ça va l'argument fric à la con tout le temps

Et oui, s'il y avait de bons jeux portés sous linux j'en acheterai probablement (je dis probablement car bon le temps de jouer ...)

vite fait parce que bon, toujours les même arguments...

Les utilisateurs de Windows, tant que ça marche c'est bon.

On doit pas avoir les même utilisateurs alors... y'a qu'à voir le nombre de personnes qui souhaitent garder leur pc sous xp par exemple... (et me parlez pas de chiffre de vente de vista vu qu'il est presque impossible de trouver des xp sur des machines neuves...)
et c'est pas Dell (suis pu sur, ptetre hp) qui a décidé de prolonger la présence de xp ?

Windows, c'est un OS avec une API stable (un jeux Win95 bien construit tourne encore sous Vista)

Ben je dois franchement être nul car j'ai essayé de faire tourner un vieux jeux prévu pour 98 sur mon XP et il ne s'est jamais lancé... (oui oui, mode de compatibilité toussa)

D'ailleurs, s'il existe un mode de compatibilité ça ne serait justement pas parce que, de base, un vieux programme peut ne pas s'exécuter sur les nouvelles versions d'OS ?

Il manque un système de gestion de package

Ha ?

Pourtant les gars d'enemy territory y arrivent bien...
Unreal aussi...
Un programme, qui plus est commercial, bien compilé n'a pas nécessairement besoin de s'installer dans le système de package de la distro (même si ça serait mieux).
De plus, dans la plus part des cas, compilé en static pour réduire pas mal de problème, il suffit d'un .deb et d'un .rpm pour passer sur bcp de machines (il m'arrive d'installer des rpms non prévus pour ma version et ça tourne, les produits adobe par ex...)

/apps/compiz/plugins/scale/allscreens/options/initiate_edge
dans gconf

(Vu qu'on est déjà vendredi...)

Ben merde ça fout les boules de voir une ligne comme ça pour configurer un soft...

C'est un peu comme changer le comportement d'un bouton sous firefox et son about:config alors qu'une page de config avec une zolie image de souris serait 1000x mieux pour un soft soit disant grand public !



-->[] m'en retourne à mon kdeusinagaz ;-)

La ligne de commande, ce n'est pas un truc de geek. Le shell, ce n'est pas de la programmation. C'est de la fainéantise... Un bon informaticien ne fait pas la même chose deux fois.

Oui mais ces phrases c'est justement la reflexion d'un geek ou au moins d'un informaticien...
Pour ma part, j'utilise aussi bien la ligne de commande que les outils graphiques, mais pas du tout pour les même choses. Et pour tout ce qui touche l'utilisation classique d'un ordi (gérer ses fichiers, écouter de la musique, monter des médias locaux ou distants, ...) c'est je trouve normal de passer par l'interface graphique, qui offre un vrai plus en terme d'ergonomie et de facilité d'utilisation (ne serait-ce qu'en proposant des tooltips, des messages d'aides qui sont en général confinés dans man en cli...)
Par contre évidemment pour bosser, compiler, lancer mes serveurs, ... je préfère ma ligne de commande (associée à quelques instances de kdevelop tout de même... ;))

Conséquence: Impossible d'utiliser flash (en tous cas dans ses dernières versions) sur ARM (PDA, Nintendo DS, ...), MIPS ou PowerPC (Set top box), et même sur des x86 avec des architectures un peu spéciales (type AMD Geode, trouvé sur des network PC).

Même sur architecture x86-64, pourtant de plus en plus répandues, ca n'existe pas (ils y travaillent, parait-il... Ca dois pas être bien brillant, leur code, si une simple recompilation ne suffit pas).

A mon avis, c'est purement "marketing" ou "support".
Je ne pense pas qu'il y ait de si gros problème car certains téléphones commencent à intégrer flash, soit dans leur navigateur, soit pour l'interface même du téléphone (voir le lg prada dont l'interface est entièrement faite en flash par exemple).

Enfin voilà quoi, moi aussi j'aimerais bien du flash libre ou au moins qui tourne sur mon x86_64 (même si flashçapu ;) )

Moi qui ai l'habitude d'un Horde qui se connecte partout, ça m'a refroidi.

Oué enfin on peut brancher horde sur kolab parfaitement (d'ailleurs c'est expliqué en détail sur le wiki de kolab)

C'est ce que j'ai chez moi et j'utilise donc :
linux+kolab sur mes ordis @home et horde ailleurs

il y a une compatibilité totale avec horde (y compris calendrier, ...) donc aucun problème avec kolab.

Franchement, kolab est un produit magnifique je trouve, qui fonctionne bien, assez simple de configuration (surtout qu'il est déjà integré dans mandriva par exemple, donc encore plus simple)

Maintenant, que les connecteurs outlook soient proprio/payants ne me pose pas de problème, surtout que le but est bien de favoriser un outil proprio et payant... et surtout que kolab saibien !

oui, je pense que je vais me tourner vers l'écriture dans des temp (surtout que je tourne sous win et linux...)

merci pour les solutions types mmap ou ramdisk mais elles ne sont pas envisageables. Je risque déjà d'avoir des problèmes lors de l'écriture de fichiers temporaires (mon code s'exécute dans un navigateur) alors monter des fichiers en ram ou autre... même pas la peine d'y penser ;)

juste rapidement (manger, toussa ;-) )

Une liste, c'est un tableau ? hérétique ! :p

Non non, j'ai pas voulu dire ça ;-)
Simplement que je rencontre souvent du code où pour parcourir une liste un for i++ est utilisé (oui, il m'arrive de lire du mauvais code... :( )

sur le principe du each / for, je ne parlais pas forcément du plus simple à écrire/lire mais ce qu'il me semble le plus correct au niveau de la représentation qu'on peut en avoir (je sais pas trop comment dire, mais sur le fond plus que la forme quoi). Il me semble plus logique dans le cas d'un parcour d'un élement de manipuler d'abord cet élement plutôt que de sortir un artefact tout fait qui en réalité est purement inspiré de langages non objets (voir même de contraintes machines, assembleur toussa)

À mon avis, l'écriture (1..10).each bloc suggère plus une fonction curryfiée où (each 1 10) est une fonction prenant un bloc et lui appliquant l'itération, qu'un appel objet.

En fait je voyais ça comme (1..10) qui crée un tableau [1, 2, 3 ... 9, 10]
et donc le each se rapport sur l'ensemble et non une fonction prenant un bloc et donc dans ce cas c'est un appel objet. (note : je me trompe peut-être, je ne suis pas allé voir comment ça marche à l'intérieur)

Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...

/me espère pas se gourrer dans ce qui suit :

En général, on utilise for pour deux choses : soit parcourir un tableau, soit pour simplement faire une iteration

Dans le cas d'un parcour d'un tableau (une liste, un vecteur, ...) on ne devrait jamais à mon sens utiliser de for mais utiliser des constructions du type
montab.each()

Dans le cas d'itération (et donc là il y a une certaine disymétrie), écrire 1.to(10) ne me choque pas vraiment mais on peut très bien remplacer par une écriture du type : (1..10).each
Dans ce cas il n'y a aucune disymétrie. Mais pour des itérations partant de 0 (comme c'est souvent le cas en info) le mieux reste nbIter.times qui est franchement plus logique je trouve, il colle beaucoup mieux à l'esprit qu'on a des itérations.


note : sinon, dans les trucs pas logique, pourquoi certains utilisent des for(;;) ?
Mieux vaut à mon sens utiliser dans ce cas un while(true) (même si ça fait la même chose...), non ?

Et en plus, sur ma 2007 (pas .1 mais ça doit être pareil) il me demande lorsque j'ai la possibilité d'installer un driver pas libre.

Lorsqu'on configure la carte graphique par exemple, il me demande si je veux installer le driver ati/nvidia, en précisant bien que c'est un driver non libre, et dans ce cas le télécharge pour l'installer.

La possibilité est là mais ça n'installe pas par défaut.

(et avec les version totalement free il n'y a même pas besoin de se poser la question ;-))

une syntaxe ou tu appelle un membre d'un nombre pour faire un truc c'est vraiment mal

Pourquoi ?

J'y vois simplement le concept d'objet poussé un peu plus loin que dans les langages "objets" mais non complètement objets classiques (j'ai rien contre c++ hein, je l'utilise tous les jours, mais ça pue quand même ;) )

De la même manière, une chaine est aussi un objet
on doit pouvoire faire un :

"mastring".each{|char| print char, " "}

En ruby tout est objet, est c'est ce qui fait qu'il est vraiment sympa je trouve.

mais c'est sur qu'entre un :

for(uint i = 0; i < montab.size(); i++) { print montab[i]; }

et :

montab.each{|elt| print elt}

il y a une sacré différence. Un for est quelque chose que je trouve souvent horrible car il n'est relié à rien (je sais pas trop comment ça s'appel, c'est juste un mot clé qui est tout seul dans son coin). Alors que le each, le upto sont lié directement à l'objet qu'on manipule et c'est vraiment plus logique je trouve

D'ailleurs, j'aurais plutôt du comparer montab.each a une syntaxe du type :

foreach(elt in montab) { print elt; }

On voit bien que dans ce cas foreach arrive de nul part alors que le each est réellement une méthode de mon tableau (je ne compare pas les syntaxe mais vraiment la construction logique du langage)

(oui, tout ça pour dire que je trouve ça logique et que j'aime beaucoup Ruby. D'ailleurs si certains connaissent des langages objets au même point que Ruby ça m'intéresse ;-) )

oué enfin pour écrire print, join ou n'importe quel code il faut connaître l'anglais (un minimum)
et ça reste à mon sens verbeux mais concis

(mais je me doutais bien qu'on pouvais faire 'mieux' en perl (j'adore perl et ruby... ;) )

j'oublais : question lisibilité et compréhension je trouve 1.upto(MAX) largement plus lisible qu'un (1..MAX)
La première version est lisible telle quelle, la deuxième demande d'interpréter le '..'

Pour les print, il y a les versions ruby qui s'en rapprochent un peu quand même (et en étant très lisible - mais non, je parle pas de python ;) )

5.times { |i| print i, " " }
-> 0 1 2 3 4

5.upto(10) { |i| print i, " " }
-> 5 6 7 8 9 10

C'est pas aussi concis mais je trouve ça vraiment pas mal :-)

Bon, tout d'abord désolé si je t'ai un peu ennervé, ce n'était en aucun cas le but (au pire me défouler un peu, c'est vrai ;) )

Peut-être qu'on c'est pas tout a fait compris. J'aime bien les technos mozilla. Je suis en train de bosser sur un plugin pour mozilla et je trouve ça intéressant, j'ai déjà louché plusieurs fois du côté de Xul (mais mes patrons sont pas forcéments convaincus malheureusement...).

Maintenant, je regrette simplement le coût d'accès à ces technologies qui est assez important. Je sais bien que du boulôt a été fait sur devmo et c'est tant mieux car la dernière fois que j'ai essayé xul j'ai pas tout capté (mais bon, c'était aussi il y a un ans).

En gros, ce que je regrette c'est simplement qu'il n'y ait pas une volonté clair et franche de la fondation mozilla pour mettre en avant ces technologies. J'ai l'impression que beaucoup est fait pour promouvoir firefox (ce qui est très bien) et beaucoup moins sur les autres produits et encore moins sur les plateformes de dev.

Allez, histoire de rétablir la balance, il est vrai que ça n'empèche pas certaines entreprises de faire du xul (le backend de lemonde.fr, joost, wengo, ...)

Maintenant, de là a fournire de la doc, faudrait déjà que je comprenne ce que je touche avant car c'est quand même un beau monstre (ne serait-ce que par la quantité de code dans mozilla...)

oué enfin la doc des plugins c'est aussi http://developer.mozilla.org et c'est bien pour ça que je faisais cette remarque...

Si xul est bien documenté alors tant mieux, et il faudrait vraiment que je m'y mette un de ces quatres. Mais c'est pas ce que j'avais lu aux dernières nouvelles, surtout comparé à des produits comme apollo qui viennent également avec leur environnement de développement...

Pourquoi pas, c'est quelque chose de sympa dans l'absolu.

Maintenant, vu la campagne marketing de mozilla (corp. ou foundation, au choix) concernant XulRunner ça fait quand même peur (oui je sais, tout est foutu sur firefox le reste on peut l'oublier vite fait).

J'ai pas encore vraiment touché à Xul mais si la doc en est au même point que pour réaliser des plugins (npapi, npruntime) ben on est franchement mal baré pour concurrencer une techno comme apollo. C'est inimaginable comment ça peut être galère de bosser sur des technos Mozilla. C'est intéressant, ça c'est sur mais alors c'est un galère monstrueuse (impossible de trouver une doc vraiment potable, quand c'est pas une doc qui date de 5 ans avec un petit texte disant que c'est out of date. et ne parlont pas de trouver des tutos / des examples...)

A croire qu'il n'y a que les personnes de mozilla qui bosse sur du mozilla.

note : je crache pas sur les produits mozilla, les idées et ce que j'ai pu voir des produits sont bien mais le package développeur autour est franchement médiocre je trouve.

Globalement je suis d'accord avec cette "description" ou critique de javascript et je suis tout à fait conscient du fait que ce langage ne ce comporte pas comme les sacro-saints c/c++/java/...

Mais je prend ça plutôt comme une caractéristique avantageuse.

Je code en javascript (intensément, pas juste deux pauvres petits scripts) depuis plus d'un an et j'ai appris petit à petit les spécificités de ce langage, et également comment contourner les problèmes inhérents mais c'est egalement ce que je fais lorsque je code en c++ (car ça aussi c'est un langage qui suck)

Et même si javascript n'est pas forcément le meilleur langage, avec de la rigueur et en s'efforcant de coder proprement c'est un fabuleux langage, très intéressant surtout (je trouve) par l'utilisation massive de fonctions anonymes et le fonctionnement par prototype qui change un peu.
Mais bon, ensuite c'est quand même les gouts qui guident ces choix égalements (je déteste le C++ alors que j'en fait tous les jours et j'adore perl et ruby - et pas python...)

Javascript est une horreur.
Si vous ne me croyez pas sur parole, allez lire la norme. Faites-le vraiment. Et découvrez les joies des choses qui ne fonctionnent pas comme vous vous y attendiez ; de la séparation entre ECMA-262 et DOM, avec certaines fonctions dans l'un, certaines dans l'autre (comme les timers, qui ne sont pas inclus dans ECMA-262) ; surtout, découvrez avec délices un langage (presque) tout objet, à prototypes, non typé, à liaison retardée (late binding), (généralement) interprété, où tout, absolument tout, est permis. Pour le meilleur et pour le pire...
PS : j'avoue, je n'ai pas lu la norme ; la présentation détaillée qui m'en a été faite récemment m'a amplement suffit.

Donc en fait "allez lire la norme si vous ne me croyez pas, moi je l'ai pas lu mais je sais quand même ce qu'il y a dedans". C'est bien ça ?

Javascript souffre d'une très mauvaise image à cause de l'utilisation qui en est faite essentiellement.

Par contre, pourquoi à chaque fois qu'un langage est différent des classiques c/c++/java de base ("et découvrez les joies des choses qui ne fonctionnent pas comme vous vous y attendiez") c'est forcément un mauvais langage ?

Javascript est un langage intéressant, objet. Alors oui, c'est un langage à prototype et non un langage à classe. Et alors ? le fonctionnement n'est pas le même mais est assez intéressant. C'est aussi un langage utilisant beaucoup les fonctions anonymes par exemple.

M'enfin voilà, y'en a un peu marre des personnes qui jugent simplement parce que "la présentation détaillée qui m'en a été faite récemment m'a amplement suffit" mais sans être allé un peu plus loin, sans avoir testé.

Javascript en lui même est un langage très intéressant, relativement facile mais qui souffre d'une très mauvaise image, entretenue par des incompatibilité entre les différents navigateurs (ce qui en réalité ne montre en aucun cas que javascript est mauvais mais que leurs implémentations, ainsi que le support DOM - qui n'est pas javascript - sont pourraves)

note : oui il m'arrive de développer en javascript, y compris des scripts relativement gros mais j'ai également été longtemps contre javascript, jusqu'à ce que je me rende compte des qualités du langage et surtout qu'on pouvais faire de bonnes choses avec. Dire que javascript pue au vue de son support ou de ce qui est fait c'est comme dire que c++ pue simplement car MFC est une grosse merde.

sinon, ici est ce qu'il y a un forum pour la catégorie C, C++

oui, la ligne juste en dessous de celle du forum c# pour le c++ et celle juste au dessus pour c...