Quand les gens vont-ils comprendre qu'il y a une difference entre:
- le langage
- son implementation
C'est pas parceque l'implementation d'un langage n'est pas rapide que le langage en lui meme est une merde qui sera toujours lent.
Sun implemente Java en utilisant une JVM ce qui fait que ca rame (en contre parti ca apporte aussi plein d'avantages qu'un simple compilo n'a pas).
Mais rien n'empeche d'implementer le langage Java de maniere classique (un compilo qui produit du code machine) sans passer par une JVM. Et oh miracle, ca existe et ca marche !
> Communément admis par qui ?
Par moi et beacoup de gens qui programment en Java
Tu peux aussi le lire dans Thinking in Java (qui est une reference), disponible gratuite sur le site web de Bruce Eckel qui a fait parti du commite de standardisation du C++ (en gros un expert reconnue par tous pour ces competences).
> Les gens sont vraiment cons alors, pourquoi ne codent-ils pas en Java ?
Oui il y beaucoup de gens qui programment en Java, je viens de t'en donner un exemple avec les statistiques SourceForge.
> Parce que c'est lent, incompatible d'une version à l'autre et d'une plateforme à l'autre (un comble pour un langage qui à la base se veut multi-plateformes !) ?
C'est vrai que C et C++ c'est multi-plateforme et parfaitement compatible d'une version a l'autre.
Et si c'est lent c'est pas forcement uniquement de la faute du langage mais aussi de son implementation.
Comme dit avec plein de bon sens un peu plus haut:
"rien n'est 100% portable, même en java, il faut programmer "correctement" si on veut de la portabilité, et certaines choses posent toujours des prob"
> Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...
Si la majorite avait raison ca ferait longtemps que ca se serait.
En dehors de la qualite intrinseque d'un langage il y a aussi l'historique du project, les competences des developpeurs dans un langage plutot qu'un autre, les outils disponibles ect...
> heureusement que les développeurs Gnome ont un peu plus de jugeotte
Si les developpeurs Gnome avaient eu un peu de jugeotte ils se seraient pas fait chier a re-inventer la roue avec du C bas niveau et auraient utilise un autre langage plus adapte aux developpement d'applications graphiques pour le desktop AMHA
> les fanatiques du java à tout prix comme toi
Merci, je developpes actuellement a 70% en C++.
> cette bande de salopards d'Apple
Pour meriter cette appelation ils ont fait quoi ? tuer des gens, piller ta maison ? ou alors c'est parcequ'ils gagnent de l'argent avec des logiciels proprietaires ? Je rappelle qu'ils ont contribue a khtml, XFree et utilise des logiciels libres, c'est des demi-salopards alors...
> ils se mettent petit à petit à ces langages, suivant les avantages du langage pour le composant et les compétences des développeurs
C'est pourquoi je parle de binding. Mais je pense qu'un binding Java a plus d'avantages pour le developpement d'applis desktop que les autres langages, et plus que C# aussi.
> une usine à gaz propriétaire qui impose l'utilisation d'un langage unique
Rien ne t'empeche d'utiliser une implementation libre de Java.
Rien ne t'empeche d'utiliser un autre langage en meme temps que Java, c'est meme fait pour !
Tu peux utiliser d'autre langage que Java sur la JVM
Le commite qui discute de l'evolution de Java est "ouvert" (cf les templates qui sont ajoutes dans le jdk 1.5 alors que Sun n'en voulait pas)
Tu peux meme te passer de la JVM si tu trouves ca trop lourd.
Hier soir mon Mozilla 1.3 c'est mis en carafe et mon profile c'est corrompu pour la premiere fois: plus de bookmarks, plus de compte mail ect...
Je suis le seul a qui c'est arrive ?
Il est communement admis que l'on programme 50% plus vite en Java qu'en C++ avec au final un code plus propre et moins de bugs d'ou un reel interet (ne parlons meme pas du C).
Mais qu'en est-il de C# ? C'est logiquement mieux car ils ont beneficie des erreurs du passe (Java date de 1995), mais c'est mieux de "combien" par rapport a Java ?
Si ce fameux combien est de "5%" es-ce que ca vaut le coup de re-apprendre, d'abandonner ces habitudes et les outils performants ? On ne peut pas se permettre d'abandonner un langage pour un nouveau sous pretexte que celui est 5% mieux, en revanche une fois tous les 15 ans ca fait pas de mal ;)
Pour moi ca vaut pas le coup par rapport au peu d'avantages que ca procure (sans compter tous les inconvenients: faire confiance a Microsoft, peu repandu, pas encore d'outils, encore des bugs car jeune...).
Mon avis est qu'il faut mieux promouvoir des choses comme gcj plutot que Mono:
Java est promu par Sun et j'ai 10x plus confiance en Sun que Microsoft
Java est repandu, bien connu et etudie:
- il y a beaucoup de livres dessus
- les etudiants apprennent tous ce langage
- c'est tres utilise en entreprise
- on connait les avantages et les inconvenients de ce langage
Il y a deja pleins d'outils libres/proprios pour Java (Eclipse, Ant, Tomcat, Jakarta, JBoss, Xerces, gcj, JUnit, JBuilder, Together ect...)
beaucoup de logiciels libres ont ete developpe en Java
Java evolue et de nouvelles fonctionnalites sont ajoutees (templates dans jdk 1.5)
Le seul avantage a mes yeux de C# sur Java est qu'il est standardise.
Mais Microsoft va-t'il faire evoluer le standard comme ca se fait pour C++ ou au contraire va-t'il y avoir un decalage important entre le standard et le C# utilise tous les jours (celui de Microsoft) ?
Un standard n'est interessant que si les gens l'utilisent, le C# standardise est probablement un coup d'annonce pour se faire de la pub de la part de Microsoft plutot qu'une reelle volonte de s'ouvrir.
Je pense que la communaute du libre a besoin d'un langage moderne pour remplacer le C++ et encore plus le C et ce langage a plus d'avantages a etre Java que C#
Si maintenant on pouvait avoir des bindings performants, sans bugs de GNOME et KDE pour Java avec un bon compilo derriere ca serait le pied: le developpement de logiciel libre avancerait plus vite et probablement plus de personnes joindraient l'aventure.
--
Tanguy qui essaye d'utiliser le binding Java de KDE
Ca me fait furieusement penser a la programmation par contrainte.
cf http://kti.mff.cuni.cz/~bartak/CP.PDF(...) et l'exemple classique des 8 reines (regarde bien backtracking/forward checking sur l'exemple des 8 reines).
Le probleme c'est que la programmation par contraintes c'est souvent des trucs proprios en Prolog comme SciTUS. Mais rien n'empeche de le programmer toi meme dans le langage que tu veux surtout pour un exemple simple.
Le probleme c'est que Jabber ca marche pas super bien, tout au moins chez moi.
Je m'explique, j'utilise Psi et j'ai cree un compte sur jabber.org et j'utilise les plugins msn et icq sur amessage.de
Un coup c'est le serveur de jabber.org qui marche pas ou alors c'est le amessage.de, j'ai souvent des deconnexions (de moins en moins c'est vrai).
Je sais pas si c'est le serveur officiel Jabber 1.4 qui chie ou les serveurs jabber.org et amessage.de qui sont surcharges.
De toute facon que va faire un debutant ? se creer un compte Jabber sur l'un des serveurs publics les plus "visibles": jabber.org ou jabber.com
Or si meme ceux la ne fonctionnent pas correctement, difficile de recommander Jabber aux debutants...
Un autre probleme que j'ai rencontre: si je me cree un compte sur un autre serveur plus stable, comment migrer aisement ma contact list sans devoir la retaper ?
SciTE est un editeur sous licence proche de celle de Python
il est ecrit en C++ et utilise gtk comme interface graphique
il fonctionne sous UNIX et Windows (natif windows), il est tres leger et tres tres pratique.
J'ai entendu dire que Anjuta ( http://anjuta.org/(...) ) s'en servait pour la partie editeur.
je l'utilise regulierement depuis 3 ans (sous win, linux et solaris) et il est genial !
Sinon il y a en mode console l'IDE Motor http://konst.org.ua/en/konstware(...) je ne l'ai pas teste mais vu l'auteur y'a pas de probleme c'est de la haute qualite.
Il y a aussi fte en mode console mais son developpement est arrete.
je pense que la part d'Opera est tres sous-estime pour la simple et bonne raison que par defaut Opera s'identifie a MSIE !
je vois autour de moi beaucoup de personne l'utiliser
"la licence que nous utilisons est basee sur la licence du consortium X11/X (MIT) aussi appelle X11-licence.
Cette licence n'impose aucune condition sur la modification ou la redistribution du code source ou des binaires[...]"
ba voila ce qui devait arriver arriva !
ca me rappelle le project wine qui c'est fait piller, depuis ils sont passes a la LGPL.
Si XFree86 etait sous GPL il se serait passe la meme chose que pour KHTML cf la news : http://linuxfr.org/2003/01/07/10885.html(...)
c'est bien dommage. Si Apple n'est pas oblige de fournir les sources ils ne le feront pas
KHTML va avance avec l'aide d'Apple et XFree86 se contentera de se faire piller.
Bref je milite pour les licences GNU GPL/LGPL et le copyleft !
il existe des instructions SSE scalaire que Gcc préfaire mille fois à la pile x87
oui voila un point interessant.
A l'heure ou l'on programme en Java, actuellement c'est dans les applications clientes que l'on utilise ces instructions. C'est completement anachronique !
c'est le job du compilo. Tant que l'on devra se palucher le code a la mano et ben c'est de la rigolade et ca restera anecdotique.
la pile x87 dans 5 ans il en restera plus grand chose.
Il y a 20 ans y'a beaucoup de monde qui trouvait que les 8086 ne valait pas grand chose devant les 68000
et c'est toujours le cas
c'est pas toujours les meilleurs qui gagnent et la majorite n'a pas toujours raison : c'est injuste mais c'est la vie
Et moi, je te dis d'aller plus loin qu'un bouquin qui a plus de 10 ans dans un domaine qui est révolutionné tous les 4 ans...
c'est con de se discrediter comme ca
j'ai la derniere edition (3e, 15 mai 2002) et ca traite de tous les procs actuelles sur le marche et des toutes dernieres evolutions : t'as le P4 et les derniers Athlons dedans et pas juste sur une page.
et moi je te dis que dans 10 ans ton SSE2 ca fera longtemps qu'on utilisera plus.
Dans la realite il y a peu d'applications qui utilisent ces instructions, et si on fait des benchs je suis persuades que sur la majorite des softs qui les utilisent, on voit meme pas la difference.
rien que en 4 ans, il y a eu MMX, SSE, SEE2 et le truc de Motorola. meme si c'est souvent complementaire, c'est un element essentiel de marketing et les constructeurs jouent dessus. On va pas s'amuser a re-ecrire du code tous les 18 mois.
de toute facon je me te ferais pas changer d'avis et tu risques pas de me faire changer du mien.
Oui et le divx c'est sur, ca represente un gros pourcentage d'applications !
C'est ridicule parceque il faut coder specifiquement pour ces instructions or tous les proc ne les supportent pas et dans un avenir probablement plus aucun proc ne les supporteront, il n'y a aucune garantie. Tu achetes un proc pour les performances qu'ils apportent juste pour les divx ou pour toutes les applications restantes ? Libre a toi d'acheter un Pentium 4 parceque il y a SSE2 dedans et pas dans les autres procs, moi je trouve ca particulierement stupide.
Y'a un principe fondamental en architecture (et pas uniquement dans ce domaine) : optimiser le cas le plus courant et ne pas perdre de temps sur les cas qui ne le sont pas.
Or ici tu viens juste d'ecrire que c'est utile que pour quelques applications notamment le divx : bref ces instructions specifiques ne profitent qu'a un faible pourcentage.
Si on resume les instructions que tu cheries tant, elles sont :
- applicables qu'a un faible nombre de soft
- il faut re-ecrire des parties du soft pour en tirer profit
- on devient plus ou moins dependant de ces instructions et ca complique le code avec tous les problemes que ca comporte
- il y a aucune garantie de perenite
Donc oui au final c'est utile pour les divx ou les mp3, cool : mieux vaut avec que sans mais ca reste anecdotique et principalement du marketing.
En attendant HyperThreading ca ameliore la rapidite de tous les softs dans un environement multi-threade tout comme les innovations comme le risc, ooo, l'introduction du pipeline, le branch prediction etc... sans devoir bidouiller le code de ton programme.
Lis Computer Architecture A Quantitative Approach
C'est une reference dans le domaine et ensuite tu comprendras que c'est du pipo, il y a un court paragraphe dessus.
si ca termine par "ez" c'est parceque c'est justement pas un infinitif.
"excusez moi"
le verbe est a l'imperatif, ce n'est pas un infinitif
on donne un ordre a l'autre personne, on peut le reformuler par "tu dois m'excuser" et sous cette forme on voit clairement que c'est pas tres polie mais c'est desormais passe dans les moeurs et on y est habitue.
si on remplace le verbe excuser par prendre on ne dit pas "prendre moi" mais "prenez moi" ba la c'est pareil on ecrit pas "excuser moi" mais "excusez moi" (on dit aussi "prend moi" ce qui donne "excuse moi")
On ne s'excuse pas soi meme, on demande gentillement (donc sans imperatif) a la personne de nous excuser.
Donc on s'en sort tres bien si on cherche pas des erreurs la ou il y en a pas. Il faut tremper 7 fois sa plume dans son encrier avant d'ecrire une connerie.
Maintenant tu as le droit de repondre et de demander si je peux t'escuser avec une jolie phrase "je vous prie de bien vouloir m'excuser".
tient j'en rajoute une couche, on ne dit pas "je m'excuse" ni meme "excusez moi" mais "je vous pris de bien vouloir m'excuser"
pourquoi ?
parceque s'excusez soi meme tout le monde comprendra que c'est tres mal polie. de meme donnez un ordre avec un verbe a l'imperatif c'est pas mieux.
1er : le SMP, on est tous d'accord, c'est mieux au niveau performance que le SMT, c'est evident.
Mais le SMP ne te donne pas 100% de perf en plus si tu rajoutes un proco, depuis le temps je croyais que tout le monde etait au courant.
2e : le SMT c'est loin d'etre un pauv truc marketing, le MMX, SSE truc muche en revanche c'est clairement que du marketing.
d'ailleurs a l'epoque du 1er pentium MMX (le 166 et le 200MHz) ils avaient augmente la taille du cache L1 par rapport aux meme procs sans MMX alors forcement les cretins de journalistes attribuaient l'augmentation de perf aux instructions MMX.
Ici le SMT permet d'obtenir le maximum du processeur (le P4 a ete dessine pour le SMT notamment la FPU). Pour moi c'est une evolution aussi importante que l'introduction du pipeline, du out of order, du branch prediction ect... moi je trouve que c'est une reelle innovation.
Si pour l'instant c'est pas encore parfait, ca va s'ameliorer.
Et ce gain de perf on l'obtient sans rien faire, sans devoir recompiler quoi que se soit, sans foutre des bouts de code en assembleur ou re-ecrire les compilos comme pour les MMX truc merde.
Il suffit juste de faire fonctionner plusieurs threads en meme temps c'est tout : donc la meme condition que pour le SMP
Y'a pas que les perfs dans la vie, y'a aussi le prix qui compte.
Sinon tout le monde aurait des bi-procs
le rapport qualite/prix ca a son importance et celui-ci est bien plus important pour le SMT que le SMP -> au revoir SMP, c'est la loi de la nature.
le SMT a 2 balles il permet tout de meme d'avoir 30% de perf en plus dans la plupart des cas
faut que tu lises les tests, tout le monde est unanime pour dire que HyperThreading est une veritable reussite (tout comme ils etaient unanimes pour dire que le P4 1er generation c'etait de la merde)
seulement 35% des unites de calculs sont occupes en utilisation courante sur un P4 normale, HyperThreading essaye simplement de combler ce probleme. et pour cela ils utilisent seulement 5% de la surface du die, donc ca coute que dalle, surtout par rapport a du SMP.
A l'avenir Intel sortira le Prescot avec 4 processeurs logiques, 1 MB L2 et gravure 0.09µ
Si tu veux mon avis, le SMP va pratiquement disparaitre dans un avenir proche. Quel sera l'interet de payer un truc beaucoup plus cher pour peu de performance en plus ?
"MplayerXP fork de MPlayer avec support des threads" ca veut dire que c'est une version qui supporte les threads, je vois vraiment pas en quoi ca pourrait etre interprete comme "fourni les threads" (c'est vraiment tire par les cheveux) meme si le mot utilisation est clairement plus jolie
sinon c'est quoi l'interet de killer le processus a la video ? je vois vraiment pas !
L'auteur de MplayerXP veut du multithread pour pouvoir "repartir" la charge : a des moment le cpu ne fait rien alors qu'a d'autre moment sur une machine peut puissante il va devoir dropper des frames, l'idee est donc de pre-calcule des frames.
Donc c'est uniquement utile sur les petites becannes et/ou lorsque l'on fait fonctionner MplayerXP en meme temps que d'autres programmes.
Arpi a tout simplement repondu que l'on pouvait pre-decompresse des frames sans avoir recourt aux threads (il deteste apparemment) qui posent plusieurs problemes (debug et profilage plus difficile, prend plus de ressources...)
Qt pour windows, normalement on utilise le compilo Visual ou Borland
Sachant que Visual (pour Borland je sais pas) est une merde immonde pour le C++ (il gère mal les for, les templates, les namespaces, les warnings sont pitoyables ect...)
serait-il possible de faire du cross-compiling avec mingw ou cygwin et ainsi d'utiliser g++ ?
En ce moment, j'utilise gtk sous unix et windows avec mingw.
evidemment gtk en C++ c'est la lutte, mais le cross-compiling c'est vraiment que du bonheur !
si c'est possible de faire ca avec Qt ca m'interesse beaucoup !
[^] # Re: promouvoir Java plutot que C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
- le langage
- son implementation
C'est pas parceque l'implementation d'un langage n'est pas rapide que le langage en lui meme est une merde qui sera toujours lent.
Sun implemente Java en utilisant une JVM ce qui fait que ca rame (en contre parti ca apporte aussi plein d'avantages qu'un simple compilo n'a pas).
Mais rien n'empeche d'implementer le langage Java de maniere classique (un compilo qui produit du code machine) sans passer par une JVM. Et oh miracle, ca existe et ca marche !
[^] # Re: promouvoir Java plutot que C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
Par moi et beacoup de gens qui programment en Java
Tu peux aussi le lire dans Thinking in Java (qui est une reference), disponible gratuite sur le site web de Bruce Eckel qui a fait parti du commite de standardisation du C++ (en gros un expert reconnue par tous pour ces competences).
http://bruceeckel.com/(...)
[^] # Re: promouvoir Java plutot que C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 3.
Oui il y beaucoup de gens qui programment en Java, je viens de t'en donner un exemple avec les statistiques SourceForge.
> Parce que c'est lent, incompatible d'une version à l'autre et d'une plateforme à l'autre (un comble pour un langage qui à la base se veut multi-plateformes !) ?
C'est vrai que C et C++ c'est multi-plateforme et parfaitement compatible d'une version a l'autre.
Et si c'est lent c'est pas forcement uniquement de la faute du langage mais aussi de son implementation.
Comme dit avec plein de bon sens un peu plus haut:
"rien n'est 100% portable, même en java, il faut programmer "correctement" si on veut de la portabilité, et certaines choses posent toujours des prob"
> Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...
Si la majorite avait raison ca ferait longtemps que ca se serait.
En dehors de la qualite intrinseque d'un langage il y a aussi l'historique du project, les competences des developpeurs dans un langage plutot qu'un autre, les outils disponibles ect...
[^] # Re: promouvoir Java plutot que C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 6.
Si les developpeurs Gnome avaient eu un peu de jugeotte ils se seraient pas fait chier a re-inventer la roue avec du C bas niveau et auraient utilise un autre langage plus adapte aux developpement d'applications graphiques pour le desktop AMHA
> les fanatiques du java à tout prix comme toi
Merci, je developpes actuellement a 70% en C++.
> cette bande de salopards d'Apple
Pour meriter cette appelation ils ont fait quoi ? tuer des gens, piller ta maison ? ou alors c'est parcequ'ils gagnent de l'argent avec des logiciels proprietaires ? Je rappelle qu'ils ont contribue a khtml, XFree et utilise des logiciels libres, c'est des demi-salopards alors...
> ils se mettent petit à petit à ces langages, suivant les avantages du langage pour le composant et les compétences des développeurs
C'est pourquoi je parle de binding. Mais je pense qu'un binding Java a plus d'avantages pour le developpement d'applis desktop que les autres langages, et plus que C# aussi.
> une usine à gaz propriétaire qui impose l'utilisation d'un langage unique
Rien ne t'empeche d'utiliser une implementation libre de Java.
Rien ne t'empeche d'utiliser un autre langage en meme temps que Java, c'est meme fait pour !
Tu peux utiliser d'autre langage que Java sur la JVM
Le commite qui discute de l'evolution de Java est "ouvert" (cf les templates qui sont ajoutes dans le jdk 1.5 alors que Sun n'en voulait pas)
Tu peux meme te passer de la JVM si tu trouves ca trop lourd.
Enfin bon de toute facon tes trolls...
# Re: Mozilla 1.3.1 et 1.4b out
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sorties de Mozilla 1.3.1 et 1.4b. Évalué à 4.
Je suis le seul a qui c'est arrive ?
# promouvoir Java plutot que C#
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 3.
Mais qu'en est-il de C# ? C'est logiquement mieux car ils ont beneficie des erreurs du passe (Java date de 1995), mais c'est mieux de "combien" par rapport a Java ?
Si ce fameux combien est de "5%" es-ce que ca vaut le coup de re-apprendre, d'abandonner ces habitudes et les outils performants ? On ne peut pas se permettre d'abandonner un langage pour un nouveau sous pretexte que celui est 5% mieux, en revanche une fois tous les 15 ans ca fait pas de mal ;)
Pour moi ca vaut pas le coup par rapport au peu d'avantages que ca procure (sans compter tous les inconvenients: faire confiance a Microsoft, peu repandu, pas encore d'outils, encore des bugs car jeune...).
Mon avis est qu'il faut mieux promouvoir des choses comme gcj plutot que Mono:
- il y a beaucoup de livres dessus
- les etudiants apprennent tous ce langage
- c'est tres utilise en entreprise
- on connait les avantages et les inconvenients de ce langage
pour avoir un ordre d'idee il y a 8661 projects en Java sur Sourceforge (10812 en C et 10490 en C++ cf http://sourceforge.net/softwaremap/trove_list.php?form_cat=160(...) )
Le seul avantage a mes yeux de C# sur Java est qu'il est standardise.
Mais Microsoft va-t'il faire evoluer le standard comme ca se fait pour C++ ou au contraire va-t'il y avoir un decalage important entre le standard et le C# utilise tous les jours (celui de Microsoft) ?
Un standard n'est interessant que si les gens l'utilisent, le C# standardise est probablement un coup d'annonce pour se faire de la pub de la part de Microsoft plutot qu'une reelle volonte de s'ouvrir.
Je pense que la communaute du libre a besoin d'un langage moderne pour remplacer le C++ et encore plus le C et ce langage a plus d'avantages a etre Java que C#
Si maintenant on pouvait avoir des bindings performants, sans bugs de GNOME et KDE pour Java avec un bon compilo derriere ca serait le pied: le developpement de logiciel libre avancerait plus vite et probablement plus de personnes joindraient l'aventure.
--
Tanguy qui essaye d'utiliser le binding Java de KDE
[^] # Re: OO.org 1.0.3.1 en français disponible
Posté par tanguy_k (site web personnel) . En réponse à la dépêche OO.org 1.0.3.1 en français disponible. Évalué à 1.
c'est pas etonnant que le truc fasse plus de 10 millions de lignes !
# Re: Deplacement du cheval
Posté par tanguy_k (site web personnel) . En réponse au journal Deplacement du cheval. Évalué à 2.
cf http://kti.mff.cuni.cz/~bartak/CP.PDF(...) et l'exemple classique des 8 reines (regarde bien backtracking/forward checking sur l'exemple des 8 reines).
Le probleme c'est que la programmation par contraintes c'est souvent des trucs proprios en Prolog comme SciTUS. Mais rien n'empeche de le programmer toi meme dans le langage que tu veux surtout pour un exemple simple.
[^] # Re: Nouvelle version de Kopete : v0.62
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Nouvelle version de Kopete : v0.62. Évalué à 1.
Je m'explique, j'utilise Psi et j'ai cree un compte sur jabber.org et j'utilise les plugins msn et icq sur amessage.de
Un coup c'est le serveur de jabber.org qui marche pas ou alors c'est le amessage.de, j'ai souvent des deconnexions (de moins en moins c'est vrai).
Je sais pas si c'est le serveur officiel Jabber 1.4 qui chie ou les serveurs jabber.org et amessage.de qui sont surcharges.
De toute facon que va faire un debutant ? se creer un compte Jabber sur l'un des serveurs publics les plus "visibles": jabber.org ou jabber.com
Or si meme ceux la ne fonctionnent pas correctement, difficile de recommander Jabber aux debutants...
Un autre probleme que j'ai rencontre: si je me cree un compte sur un autre serveur plus stable, comment migrer aisement ma contact list sans devoir la retaper ?
[^] # Re: GEL
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Un éditeur qui gagne à être connu....... Évalué à 3.
# SciTE, un autre editeur bien sympa
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Un éditeur qui gagne à être connu....... Évalué à 10.
il est ecrit en C++ et utilise gtk comme interface graphique
il fonctionne sous UNIX et Windows (natif windows), il est tres leger et tres tres pratique.
J'ai entendu dire que Anjuta ( http://anjuta.org/(...) ) s'en servait pour la partie editeur.
le resume sourceforge : https://sourceforge.net/projects/scintilla/(...)
page principale : http://www.scintilla.org/(...)
pour telecharger SciTE (il est inclu dans toute les distributions modernes) : http://www.scintilla.org/SciTEDownload.html(...)
je l'utilise regulierement depuis 3 ans (sous win, linux et solaris) et il est genial !
Sinon il y a en mode console l'IDE Motor http://konst.org.ua/en/konstware(...) je ne l'ai pas teste mais vu l'auteur y'a pas de probleme c'est de la haute qualite.
Il y a aussi fte en mode console mais son developpement est arrete.
[^] # Re: Troisième ou deuxième ? fork ? QuickTime ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 9.
je vois autour de moi beaucoup de personne l'utiliser
# licence de XFree86 = pillage en vue
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Disponibilité d'une version bêta de X11 pour Mac OS X par Apple. Évalué à 10.
"la licence que nous utilisons est basee sur la licence du consortium X11/X (MIT) aussi appelle X11-licence.
Cette licence n'impose aucune condition sur la modification ou la redistribution du code source ou des binaires[...]"
ba voila ce qui devait arriver arriva !
ca me rappelle le project wine qui c'est fait piller, depuis ils sont passes a la LGPL.
Si XFree86 etait sous GPL il se serait passe la meme chose que pour KHTML cf la news : http://linuxfr.org/2003/01/07/10885.html(...)
c'est bien dommage. Si Apple n'est pas oblige de fournir les sources ils ne le feront pas
KHTML va avance avec l'aide d'Apple et XFree86 se contentera de se faire piller.
Bref je milite pour les licences GNU GPL/LGPL et le copyleft !
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.
oui voila un point interessant.
A l'heure ou l'on programme en Java, actuellement c'est dans les applications clientes que l'on utilise ces instructions. C'est completement anachronique !
c'est le job du compilo. Tant que l'on devra se palucher le code a la mano et ben c'est de la rigolade et ca restera anecdotique.
la pile x87 dans 5 ans il en restera plus grand chose.
Il y a 20 ans y'a beaucoup de monde qui trouvait que les 8086 ne valait pas grand chose devant les 68000
et c'est toujours le cas
c'est pas toujours les meilleurs qui gagnent et la majorite n'a pas toujours raison : c'est injuste mais c'est la vie
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
c'est con de se discrediter comme ca
j'ai la derniere edition (3e, 15 mai 2002) et ca traite de tous les procs actuelles sur le marche et des toutes dernieres evolutions : t'as le P4 et les derniers Athlons dedans et pas juste sur une page.
et moi je te dis que dans 10 ans ton SSE2 ca fera longtemps qu'on utilisera plus.
Dans la realite il y a peu d'applications qui utilisent ces instructions, et si on fait des benchs je suis persuades que sur la majorite des softs qui les utilisent, on voit meme pas la difference.
rien que en 4 ans, il y a eu MMX, SSE, SEE2 et le truc de Motorola. meme si c'est souvent complementaire, c'est un element essentiel de marketing et les constructeurs jouent dessus. On va pas s'amuser a re-ecrire du code tous les 18 mois.
de toute facon je me te ferais pas changer d'avis et tu risques pas de me faire changer du mien.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
C'est ridicule parceque il faut coder specifiquement pour ces instructions or tous les proc ne les supportent pas et dans un avenir probablement plus aucun proc ne les supporteront, il n'y a aucune garantie. Tu achetes un proc pour les performances qu'ils apportent juste pour les divx ou pour toutes les applications restantes ? Libre a toi d'acheter un Pentium 4 parceque il y a SSE2 dedans et pas dans les autres procs, moi je trouve ca particulierement stupide.
Y'a un principe fondamental en architecture (et pas uniquement dans ce domaine) : optimiser le cas le plus courant et ne pas perdre de temps sur les cas qui ne le sont pas.
Or ici tu viens juste d'ecrire que c'est utile que pour quelques applications notamment le divx : bref ces instructions specifiques ne profitent qu'a un faible pourcentage.
Si on resume les instructions que tu cheries tant, elles sont :
- applicables qu'a un faible nombre de soft
- il faut re-ecrire des parties du soft pour en tirer profit
- on devient plus ou moins dependant de ces instructions et ca complique le code avec tous les problemes que ca comporte
- il y a aucune garantie de perenite
Donc oui au final c'est utile pour les divx ou les mp3, cool : mieux vaut avec que sans mais ca reste anecdotique et principalement du marketing.
En attendant HyperThreading ca ameliore la rapidite de tous les softs dans un environement multi-threade tout comme les innovations comme le risc, ooo, l'introduction du pipeline, le branch prediction etc... sans devoir bidouiller le code de ton programme.
Lis Computer Architecture A Quantitative Approach
C'est une reference dans le domaine et ensuite tu comprendras que c'est du pipo, il y a un court paragraphe dessus.
merci d'avoir participer.
[^] # Re: document sur le développement de mplayer
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à -2.
si ca termine par "ez" c'est parceque c'est justement pas un infinitif.
"excusez moi"
le verbe est a l'imperatif, ce n'est pas un infinitif
on donne un ordre a l'autre personne, on peut le reformuler par "tu dois m'excuser" et sous cette forme on voit clairement que c'est pas tres polie mais c'est desormais passe dans les moeurs et on y est habitue.
si on remplace le verbe excuser par prendre on ne dit pas "prendre moi" mais "prenez moi" ba la c'est pareil on ecrit pas "excuser moi" mais "excusez moi" (on dit aussi "prend moi" ce qui donne "excuse moi")
On ne s'excuse pas soi meme, on demande gentillement (donc sans imperatif) a la personne de nous excuser.
Donc on s'en sort tres bien si on cherche pas des erreurs la ou il y en a pas. Il faut tremper 7 fois sa plume dans son encrier avant d'ecrire une connerie.
Maintenant tu as le droit de repondre et de demander si je peux t'escuser avec une jolie phrase "je vous prie de bien vouloir m'excuser".
[^] # Re: document sur le développement de mplayer
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 0.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
# KMPlayer
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 10.
http://www.xs4all.nl/~jjvrieze/kmplayer.html(...)
c'est un frontend pour MPlayer pour KDE et ca s'integre a Konqueror/khtml
les commentaires et votes sur apps.kde sont positifs :
http://apps.kde.com/fr/2/info/vid/8515?br=true&sid=dad585ad9dc1(...)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 10.
faut que tu lises les tests, tout le monde est unanime pour dire que HyperThreading est une veritable reussite (tout comme ils etaient unanimes pour dire que le P4 1er generation c'etait de la merde)
seulement 35% des unites de calculs sont occupes en utilisation courante sur un P4 normale, HyperThreading essaye simplement de combler ce probleme. et pour cela ils utilisent seulement 5% de la surface du die, donc ca coute que dalle, surtout par rapport a du SMP.
A l'avenir Intel sortira le Prescot avec 4 processeurs logiques, 1 MB L2 et gravure 0.09µ
Si tu veux mon avis, le SMP va pratiquement disparaitre dans un avenir proche. Quel sera l'interet de payer un truc beaucoup plus cher pour peu de performance en plus ?
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 10.
sinon c'est quoi l'interet de killer le processus a la video ? je vois vraiment pas !
L'auteur de MplayerXP veut du multithread pour pouvoir "repartir" la charge : a des moment le cpu ne fait rien alors qu'a d'autre moment sur une machine peut puissante il va devoir dropper des frames, l'idee est donc de pre-calcule des frames.
Donc c'est uniquement utile sur les petites becannes et/ou lorsque l'on fait fonctionner MplayerXP en meme temps que d'autres programmes.
Arpi a tout simplement repondu que l'on pouvait pre-decompresse des frames sans avoir recourt aux threads (il deteste apparemment) qui posent plusieurs problemes (debug et profilage plus difficile, prend plus de ressources...)
[^] # Re: Firewall Builder....
Posté par tanguy_k (site web personnel) . En réponse à la dépêche FirewallBuilder : Le GUI qui vous manquait. Évalué à 6.
un article sur guarddog dans http://dot.kde.org(...) :
http://dot.kde.org/1020374104/(...)
guarddog sur http://apps.kde.com(...) :
http://apps.kde.com/na/2/info/id/666(...)
le site web officiel de guarddog :
http://www.simonzone.com/software/guarddog/(...)
[^] # Re: GCJ
Posté par tanguy_k (site web personnel) . En réponse à la dépêche GCC 3.1.1. Évalué à -2.
le même rêve que moi... :)
# Qt et cross-compiling
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Qt contre MFC. Évalué à 2.
Sachant que Visual (pour Borland je sais pas) est une merde immonde pour le C++ (il gère mal les for, les templates, les namespaces, les warnings sont pitoyables ect...)
serait-il possible de faire du cross-compiling avec mingw ou cygwin et ainsi d'utiliser g++ ?
En ce moment, j'utilise gtk sous unix et windows avec mingw.
evidemment gtk en C++ c'est la lutte, mais le cross-compiling c'est vraiment que du bonheur !
si c'est possible de faire ca avec Qt ca m'interesse beaucoup !