Salut à tous,
Une recherche sur linuxfr pour le terme "vala" met bien en valeur la pauvreté de l'orthographe des linuxèfèriens. En effet c'est à chaque fois une orthographe douteuse du mot "voilà" qui est recensé.
Pourtant, à propose de langue, Vala est un vrai langage ! Un vrai langage, mais un langage pas comme les autres. Son but est simple et paraît pas franchement novateur au premier coup d'½il :
Vala veut donner au développeur Gnome les fonctionnalités de langages modernes sans ajouter de nouvelle dépendance à l'exécution, ni utilise une ABI différente de celle des logiciels et bibliothèque écrite en C.
Concrètement, Vala traduit un synthaxe proche du C# directement en C/GObject. La syntaxe est adaptés au spécificité du système de typage de GObject (signaux, greffons, etc.). Ou comment inventer un langage sans en créer un autre ;).
Comment utiliser une bibliothèque en C dans du Vala ? Pas besoin de passerelle à l'exécution, il suffit de fournit un définition d'API à vala pour qu'il fasse la traduction, au final, c'est toujours du C. Il existe déjà un outils vapigen qui génère automatiquement un définition d'API à partir de bibliothèque GObject. Cet outils est basé sur un outils similaire du projet Mono.
Je trouve ce langage franchement révolutionnaire pour Gnome ! C'est un fait reconnu que le C/GObject est fastidieux, mais rien de garantie mieux performance et ouverture vers les autres langages. Il n'y a même pas besoin de définir Vala comme un langage accepté dans Gnome, puisque c'est du C !
Le projet est encore à un état instable, mais on peut déjà écrire un "Salutations"¹ en Gtk+ ! La version 0.0.7 contient pas mal de test (29) qui permette de voir l'évolution du support du langage.
Courrez vite visiter http://live.gnome.org/Vala !
Étienne.
¹. J'utilise "Salutations" pour traduire "Hello world!", c'est mon choix©®™.
Journal Un langage pas comme les autres : Vala
23
mar.
2007
# La différence
Posté par Étienne BERSAC (site Web personnel) . Évalué à 2.
Étienne.
[^] # Re: La différence
Posté par Snark_Boojum . Évalué à 2.
# Vala
Posté par IsNotGood . Évalué à 10.
[^] # Re: Vala
Posté par fasthm . Évalué à 10.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# ...
Posté par M . Évalué à 2.
Et le python, ruby , (C++) ils sont ou ?
[^] # Re: ...
Posté par Étienne BERSAC (site Web personnel) . Évalué à 1.
La règle pour être intégré dans la plateform de Gnome, c'est d'être en C/GObject. Après, il y a les passerelles.
Étienne.
[^] # Re: ...
Posté par M . Évalué à 2.
Je croyais que le pb, ct que les bibliothèque était en C mais que les applis voulais des language de haut niveau.
Et puis C et performance, ca veut rien dire : si on ajoute une couche haut niveau (exception, garbage collector, ...) et ben ca a un cout.
essaie de faire une passerelle ruby->python, :).
Pourquoi faire du ruby->python ?
GTK c'est du C et je proposais des applis en python/ruby.
J'ai jamais essayé de faire de telle passerelle, mais j'ai déja vu plusieurs passerelle python/ruby -> C.
PS : j'ose meme pas imaginer débugger des programmes ecrit en vala (en tout cas avec le backend C de gdb)...
PS2 : qd on voit le succes objective C (en openstep), j'espere qu'il aura plus de succes.
[^] # Re: ...
Posté par Étienne BERSAC (site Web personnel) . Évalué à 2.
Au moins, la surcouche est à la compilation, pas à l'exécution. Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc. Rien que par le fait de mixer les types natifs (avec gint, gchar, gpointer, gboolean) et les types "haut niveau" (G_TYPE_OBJECT, G_TYPE_INTERFACE et leurs enfants).
Cordialement,
Étienne.
[^] # Re: ...
Posté par M . Évalué à 5.
A bon, parce que les fonctions de la glib on les appele pas ou parce qu'elle ne font rien ?
Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc.
Un bench serait le bienvenu.
Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire, le language (et le framework) se charge de choisir ce qui se fait de mieux (algo optimisé choisi dynamiquement en fonction de l'entrée) et eviter au developpeur d'avoir a reinventer la roue pour interfacer les différents composants (qui d'ailleurs si c'est mal fait peu etre catastrophique au niveau perf ou au niveau evolutivité).
Dire que le C est plus rapide que les langages haut niveau, c'est aussi stupide que dire que l'assembleur est plus rapide que le C :
C'est vrai si t'as des developpeurs qui sont des génies, qui connaisent toute les optimisations possibles, qui on du temps devant eux.
C'est rarement le cas dans la realité.
(Je ne crache pas sur le C, mais chaque langage a ses propriétés et ses applications).
PS: je comprend parfaitement que la majeur partie de gnome est écrite en C, et qu'ils doivent faire avec. vala peut etre une solution, mais je la considere plus comme une rustine, qu'un truc revolutionnaire.
[^] # Re: ...
Posté par Gniarf . Évalué à 3.
ah non, là tu confonds les capacités du développeur et celles du langage...
[^] # Re: ...
Posté par Thomas Douillard . Évalué à 7.
Sérieusement, tu auras beau être super doué, c'est plutôt agréable de se reposer sur un langage haut niveau pour implémenter un algo proche de ce qu'on a imaginer que de pisser de la ligne au kilomètre pour faire la même chose ... et plus rapide. Ce qui laisse du temps pour faire autre chose.
Le tout à compétence du développeur égale. Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?
[^] # Re: ...
Posté par Gniarf . Évalué à 2.
avec un raisonnement pareil, (...)
de quel raisonnement tu parles ?
Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?
j'ai dit ça ? non-non. et puis tu négliges des tas de paramètres comme la disponibilité et la maturité de ces fameux "langages haut niveau" et de tout ce qui va avec, bibliothèques, outils complémentaires, méthodes, sans même parler d'éventuels problèmes de licence.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 8.
Hum, non, un langage de haut niveau peut être plus performant que du C parce que le compilateur dispose d'informations de plus haut niveau qui peuvent lui permettre de faire de meilleurs choix qu'un compilateur C qui a une vision plus limitée du programme.
Par exemple en utilisant GObject pour faire de l'objet en C, on a des pointeurs de fonction dans tous les sens. Le C++ peut être plus efficace rien qu'en décidant d'inliner certaines fonctions quand c'est possible (recopier le code au lieu de faire des appels de fonction).
Le problème peut toujours théoriquement être contourné par le programmeur qui peut faire des choix "de haut niveau" à la place du compilateur, mais il est inenvisageable que ce soit le programmeur qui transcrive un concept de haut niveau comme l'héritage entre ses classes en code de bas niveau. Sur un petit programme c'est faisable, mais totalement impossible à maintenir après. D'où le fait que, même quand on code en C, on fait des compromis entre rapidité d'exécution et temps de développement, et on se retrouve avec du code générique plus lent que l'optimum.
[^] # Re: ...
Posté par Mildred (site Web personnel) . Évalué à 3.
[^] # Re: ...
Posté par djibb (site Web personnel) . Évalué à -6.
# Performances
Posté par patrick_g (site Web personnel) . Évalué à 10.
Si le C est la garantie de bonnes performances alors pourquoi Nautilus est-il si misérablement lent ? Pourquoi Gnome est, d'une manière générale, assez lourd à l'utilisation ?
PS : c'est un gnomiste convaincu qui pose la question.
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 1.
Bonne question. C ne veut pas dire optimisé. Mais nautilus en ruby, j'ose pas imaginer ;).
> pourquoi Nautilus est-il si misérablement lent
Gnome-VFS est super lent et foireux. Sinon, en local je trouve pas nautilus si lent.
> Pourquoi Gnome est, d'une manière générale ?
Un bout de réponse : les perfs de cairo (cf dépêche 1.4), le bugs d'optimisation, etc.
Ni Gnome, ni C ne sont parfait ! Mais j'ose pas imaginé Gnome si Gtk était écrit en ruby, cairo en C# et nautilus en C++ …
Étienne.
[^] # Re: Performances
Posté par Thomas Douillard . Évalué à 2.
Parce que les dev auraient eu moins besoin de se concentrer sur l'utilisation de trucs bas niveaux pour faire en réalité plutôt des trucs (en général) hauts niveaux ...
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 1.
[^] # Re: Performances
Posté par Thomas Douillard . Évalué à 2.
Le prends pas mal, mais j'ai un peu l'impression que tu réponds à côté, là, le propos c'était :
Ben justement, peut être que si gnome avait été pensé plus haut niveau et pas pour être implémenté en C, peut être qu'il serait plus apprécié.
(bon ok, j'ai pas beaucoup d'argument, mais toi t'en es aussi au degré zéro de l'argumentation ... qui à dit "troll" ? )
[^] # Re: Performances
Posté par IsNotGood . Évalué à 4.
T'as une autre explication ?
[^] # Re: Performances
Posté par patrick_g (site Web personnel) . Évalué à 10.
Je suis un libriste mais je suis aussi un mec rationnel qui garde les yeux ouverts. Je sais faire un comparatif à la louche entre deux logiciels...ça tombe bien car j'utilise Ubuntu chez moi et XP au boulot.
Comparons l'ouverture de deux gros répertoires.
1) Si j'essaye d'ouvrir avec l'explorateur Windows le dossier system\win32 sur le portable du travail (DD 5400rpm) cela prend environ 3s pour avoir l'affichage.
2) Si j'essaye d'ouvrir avec Nautilus le dossier /usr/bin sur le portable de la maison (DD 5400rpm) cela prend environ 74s pour avoir l'affichage !!!!!
Ceci ne me gène pas énormément car je ne vais pas souvent visiter d'énormes dossiers comme /usr/bin mais cela démontre qu'il y a un gros problème avec Nautilus.
[^] # Re: Performances
Posté par Gregory Auzanneau (site Web personnel) . Évalué à 1.
Pour avoir une idée, ça prend combien de temps pour l'explorateur de KDE d'afficher /usr/bin ?
[^] # Re: Performances
Posté par blobmaster . Évalué à 1.
C'est si rapide que j'ai pas trop compté mais je dirais autour d'une seconde en tout cas moins de deux.
Et ce quel que soit le mode d'affichage (il y en a une dizaine).
(Machine achetée en Octobre et puissante)
[^] # Re: Performances
Posté par elloco (site Web personnel) . Évalué à 1.
Et si je le rouvre directement après, 0 secondes (il est donc dans le cache)
[^] # Re: Performances
Posté par koxinga . Évalué à 2.
[^] # Re: Performances
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Performances
Posté par patrick_g (site Web personnel) . Évalué à 4.
On parle quand même d'un temps d'ouverture de répertoire multiplié par vingt-cinq !!!
Je comprends pas que les devs de Gnome ne se penchent pas sur ce problème.
[^] # Re: Performances
Posté par liberforce (site Web personnel) . Évalué à 2.
http://bugzilla.gnome.org/show_bug.cgi?id=320282
Depuis peu de choses ont changé on dirait, malheureusement. Je viens de demander des infos à ce sujet. Peut être peux tu reproduire mes tests sur ta machine, qui a un disque dur assez lent. Cela permettra peut être plus en évidence les accès I/O. Faire une trace avec sysprof est très facile (vraiment !). Contacte moi à liberforce at fr point st pour plus d'infos.
[^] # Re: Performances
Posté par IsNotGood . Évalué à -5.
Car tu n'as pas été méprisant envers Gnome ? En lançant un troll à deux sous ?
> XP au boulot.
> ...
> 1) Si j'essaye d'ouvrir avec l'explorateur Windows
T'es au boulot le samedi matin ?
> cela démontre qu'il y a un gros problème avec Nautilus.
Ça ne serait pas encore du mépris ?
Je connais mal windows et je n'utilise pas Nautilus.
Mais sous Windows les icônes sans dans le programme. Sous Gnome ce n'est pas le cas.
Sous windows pour le type du fichier, c'est l'extension qui est utilisé.
Sous GNU/Linux, ça passe par magic(5).
Autre chose, il y a beaucoup plus de fichier dans /usr/bin/ que dans system/win32.
Et que disais-tu ?
> Nautilus est-il si misérablement lent
Misérablement lent !
Ce n'est pas du mépris ça encore ?
Mon /usr/bin/ qui est light a 1330 fichier. Ça prend 73 secondes selon toi, soit 18 fichiers par seconde. C'est ça misérablement lent ?
> mais cela démontre qu'il y a un gros problème avec Nautilus.
Fais un patch. (ton intentionnellement méprisant).
[^] # Re: Performances
Posté par patrick_g (site Web personnel) . Évalué à 5.
En quoi est-ce méprisant que de signaler le fait que Nautilus est incroyablement lent quand on tente d'ouvrir /usr/bin ?
En non ce n'est pas du mépris (venant de toi cette accusation serait presque drôle), c'est juste la constatation d'un fait.
Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi. Pour ma part je constate que ce n'est pas le cas des autres explorateurs de fichiers (Konqueror ou l'explorateur Windows ou Dolphin que je viens d'essayer et qui affiche ce répertoire en 1s environ).
>>> T'es au boulot le samedi matin ?
En quoi ça te regarde ?
T'a envisagé le fait que j'avais procédé à ce test avant d'écrire ce post dans ce journal ?
[^] # Re: Performances
Posté par IsNotGood . Évalué à 0.
Oui.
> Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi.
Pour ton info, le problème (s'il y a) n'a rien à voir avec Nautilus :
$ time file /usr/bin/*
real 1m7.625s
user 0m0.360s
sys 0m0.350s
T'as combien de fichier dans /usr/bin ?
Et tu disais quoi de Nautilus. Je vais te raffraichir la mémoire :
- "Nautilus est-il si misérablement lent"
- "cela démontre qu'il y a un gros problème avec Nautilus"
Tes affirmations ne tiennent sur rien.
> Si tu est content du fait qu'un processeur cadencé à 1,86 milliards
Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache. Soit au grand grand mieux 100 / s. Nautilus fait 18 /s c'est très bien. C'est n'est pas misérablement lent.
[^] # Re: Performances
Posté par M . Évalué à 6.
$ time file /usr/bin/*
real 1m7.625s
user 0m0.360s
sys 0m0.350s
Ben si, c'est Nautilus qui a choisi d'utiliser cette méthode (lente) qui n'est pas forcement adapter a ce que veut l'utilisateur (qui d'ailleur se fou du moyen utilisé).
Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache.
Ben essaye avec d'autres programe (comme readelf -h) et tu veras...
Je ne parle meme pas de programme qui essayerais de faire des lecture asynchrone...
[^] # Re: Performances
Posté par IsNotGood . Évalué à 2.
C'est Unix qui a choisi cette méthode et elle est très bien.
> qui n'est pas forcement adapter a ce que veut l'utilisateur
l'utilisateur veut plus de 18 fichiers par seconde ?
Le problème n'est pas là. Il faudrait par exemple que nautilus mette à jours la fenêtre au fur et à mesure qu'il collecte des infos.
> Ben essaye avec d'autres programe (comme readelf -h) et tu veras...
Dans l'exemple précédent, file faisant l'affichage dans une xterm. Ce qui ralentit significativement file.
Après avoir vidé le cache :
$ time (readelf -h * > /dev/null 2>&1 )
real 0m21.763s
user 0m0.150s
sys 0m0.210s
Après avoir vidé le cache :
time (file * > /dev/null 2>&1 )
real 0m20.324s
user 0m0.360s
sys 0m0.360s
Cache plein :
$ time (readelf -h * > /dev/null 2>&1 )
real 0m0.287s
user 0m0.190s
sys 0m0.080s
Cache plein :
$ time (file * > /dev/null 2>&1 )
real 0m0.714s
user 0m0.410s
sys 0m0.250s
Et car tout ça commence à me casser les couilles, j'ai installé Nautilus.
Pour Nautilus si le cache est vidé j'ai 22 secondes, et si le cache est plein moins de 2 secondes.
Donc tout va absolument bien avec Nautilus et readelf n'est pas plus rapide que file ou Nautilus.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 2.
$ rpm -q nautilus
nautilus-2.16.2-7.fc6
[^] # Re: Performances
Posté par fmaz fmaz . Évalué à 4.
C'est clair qu'analyser 10000000000 de fichiers, ça prend du temps. Mais Nautilus n'affiche JAMAIS tous les fichiers en même temps. Donc techniquement, pour afficher la fenêtre, il lui suffit d'analyser les fichiers dont il va afficher les icones et c'est tout. Ensuite, s'il en a besoin, il peut analyser les autres fichiers.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 2.
Très juste. C'est ici qu'il faut travailler la question mais c'est loins d'être évident. Comme savoir ce qui doit être affiché avant d'avoir correcté les infos ?
C'est réalisable dans le mode liste. Chaque fichier occupe la même place dans la fenêtre. Donc si la scoll barre est à 54 % par exemple, on connait les fichiers qu'il faut examiné. Dans les autres modes, on ne sait pas.
[^] # Re: Performances
Posté par Anonyme . Évalué à 1.
Et bah on devrait. Et j'espère que les devs de gnomes en sont conscient.
[^] # Re: Performances
Posté par ola . Évalué à 0.
ouch.
si c'est reellement le cas, ya la tete d'un designer d'IHM qui devrait tomber...
'fin ce que j'en dit, un soft de ce genre qui n'est pas capable de faire une correspondance vue/modele, ya un ENORME probleme dans l'equipe..
[^] # Re: Performances
Posté par IsNotGood . Évalué à -2.
Doit faire avec le "Windows touch" (c'est-à-dire n'utilise pas magic(5)). Si tu préfères Windows, prends Windows.
[^] # Re: Performances
Posté par patrick_g (site Web personnel) . Évalué à 7.
Je te jure c'est vraiment pénible ta mauvaise foi à toute épreuve.
Est-ce que tu peux comprendre qu'il y a bien un problème spécifique à Nautilus mais que cela n'implique pas le moins du monde que je crache sur les devs de Gnome ?
Je signale le problème c'est tout.
Alors reprenons :
Machine : Laptop Pentium M 1.86 GHz avec DD 5400 rpm
OS : Ubuntu 6.10 Edgy
Répertoire de test pour l'affichage : /usr/bin (1455 éléments)
Test d'ouverture de ce répertoire (affichage en mode détails pour tous les logiciels) :
Konqueror (version 3.5.5) => Temps d'ouverture : 1s pour l'affichage (env 10s pour que les icones spécifiques des fichiers finissent d'apparaitre).
Dolphin (version 0.6.0) => Temps d'ouverture : 1s
Thunar (version 0.4.1) => Temps d'ouverture : 21s
Nautilus (version 2.16.1) => Temps d'ouverture : 76s
Commentaires :
* Dolphin est Thunar sont des logiciels non matures et en développement rapide. Pour bien faire j'aurai du utiliser les version SVN et non les paquets de ma distro qui sont déjà anciens (Thunar est actuellement en version 0.8 et Dolphin en version 0.8.2).
* Tous ces logiciels affichent des icônes spécifiques selon le type de fichier sauf dolphin qui se contente d'afficher une icône standard.
* Le problème de lenteur à l'affichage vient peut-être de GTK+ car Thunar a un temps d'ouverture assez long (mais comme c'est une version de dev très dépassée je ne connais pas la performance du Thunar actuel).
* Nautilus a clairement un gros problème avec l'affichage des répertoires contenant beaucoup de fichiers. C'est d'autant plus grave qu'il est sensé être un logiciel mature à la différence de Dolphin ou Thunar.
Screenshots des différents logiciels :
Konqueror : http://www.flickr.com/photo_zoom.gne?id=433244344&size=o
Dolphin : http://www.flickr.com/photo_zoom.gne?id=433244342&size=o
Thunar : http://www.flickr.com/photo_zoom.gne?id=433244350&size=o
Nautilus : http://www.flickr.com/photo_zoom.gne?id=433244348&size=o
Conclusion :
Est-ce que maintenant IsNotGood pourrait daigner accepter mon constat d'un problème existant dans Nautilus et cesser de crier au troll ?
[^] # Re: Performances
Posté par IsNotGood . Évalué à -4.
Pour les icons, Nautilus utilise SVG et c'est TRÈS BIEN. KDE 4 qui utilise SVG dit que ça impacte les performances. KDE 4 aura peut-être SVG, on va voir s'il est aussi rapide que Nautilus (ou selon ta terminologie aussi buggué que Nautilus).
Tu n'as avancé aucune évidence d'un gros problème ou bug alors que tu n'arrêtes pas de l'affirmer. Désolé si je suis méprisant, mais c'est tout ce que ton commentaire m'inspire.
[^] # Re: Performances
Posté par patrick_g (site Web personnel) . Évalué à 6.
Je me casse le cul à te démontrer que Nautilus met 76 putains de secondes à afficher un répertoire et toi tu continue à puer de mauvaise foi et à ne rien faire d'autre qu'écrire et cracher sur les autres.
T'a fait quoi te ton coté pour constater ce problème ?
Pour toi ce n'est pas un gros problème que de voir tourner la petite animation d'attente pendant largement plus d'une minute alors que les explorateurs sous QT mettent une seconde ?
J'arrête là ce thread. On ne peux pas discuter avec un mec comme toi.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 0.
J'ai dit que Nautilus était aussi rapide que le truc sous Windows ?
Non.
Toi tu affirmes qu'il y a un bug ou un gros problème Nautilus sans la moindre preuve.
Si tu veux dire que le mécanisme magic(5) est plus lent que d'utiliser les saloperies d'extension du nom de fichier, pas de problème, je suis d'accord, je l'ai déjà dit.
Mais sous Nautilus si je renomme "titi.jpg" en "titi.jpg.old", ça reste un fichier jpg et considéré comme tel. Si je renomme "titi.jpg" en "titi.exe" sous Nautilus ça ne se transforme pas en un programme. Sous Windows tu changes le type en changant son noom. C'est une aberration. Un fichier jpeg devient un fichier texte ou je ne sais quoi si tu le renomme *.jpg.old. Si tu double-cliques dessus Windows va lancer notepad ou je ne sais quoi mais un truc inadapté.
C'est n'est pas un gros problème ça ?
Autre truc. Sous Unix/Linux, les exécutable n'ont pas d'extension. Comme tu fais pour savoir si c'est un exécutable ? Car il n'y a pas d'extension ? C'est insuffisant. Il y a plein de fichier texte sous Unix/Linux sans extension par exemple (README, INSTALL, FAQ, NEW, etc...).
Autre problème. Il y a des fichiers avec les mêmes extensions mais qui ne sont pas du même type. Comme tu fais avec Windows ? Ben Windows affiche une boîte de dialogue pour choiser le programme qui va. Sous Nautilus ce n'est pas le cas.
Magic(5) n'est pas un problème ou un bug, magic(5) est la solution pour Unix.
Nautilus utilise ce qui est adapté pour Unix et ce n'est pas de la faute à Nautilus, ce n'est pas un gros bug Nautilus. Et te n'a en rien démontré le contraire.
Tu m'insultes de mauvaise fois (m'enfin c'est à la mode avec moi quand il n'y a plus d'argument), mais toi que fais tu ?
Tu fais des affirmations, des accusations de gros problèmes ou bugs, et ce sans la moindre preuve, sans le moindre semblant de réflexion.
> Pour toi ce n'est pas un gros problème
Je n'ai jamais dit que la lenteur de magic(5) n'était pas un problème. Quelqu'un propose une solution dans le cas de Nautilus (n'examiner que les fichiers affichés et je l'appuis à 100%). Par contre je dis et je répète que Nautilus n'a pas de gros problèmes ou bugs.
La solution de Windows a aussi des gros problèmes. Tu n'aurais pas remarqué ?
Par exemple sous Windows le type du fichier est dans le nom du fichier. Le concept est si pourri que par défaut Windows ne permet pas de changer tout le nom du fichier. Je dis que ce concept est pourri, je ne dis pas que le file manager de Windows (ou dauphin, etc...) a un bug.
> Nautilus met 76 putains de secondes à afficher un répertoire
Et dans quelles conditions ? Car tu va ouvrir /usr/bin que la majorité des gens ne vont pas ouvrir. Pour lancé un programme, c'est le menu gnome qu'il faut utiliser et qui est utilisé dans 99,9 % des cas.
Vu le temps que ça te prend, il doit y avoir 2000 fichiers dans ton /usr/bin. Es-ce un cas classique d'utilisation d'un file manager ? Les files manager sont pour $HOME à 99 %. Les cas où on va snifer /usr/bin, c'est dans 99 % des cas pour troller sur Nautilus.
> alors que les explorateurs sous QT mettent une seconde ?
Ce qui n'a rien à voir avec le toolkit graphique.
Je te laisse à tes trolls.
[^] # Re: Performances
Posté par benja . Évalué à 5.
Alors que faire un magic sur les fichiers soit lent, c'est compréhensible. Mais ce n'est pas une raison pour ne pas savoir le faire de façon asynchrone. Nautilus devrait pouvoir afficher plus rapidement le contenu de la fenêtre (24 icones dans mon cas, soit <1% du répertoire) et les redissiner au fur et à mesure que magic fasse son travaille (inutile aussi de "magicifier" les fichiers non-affichés).
Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
http://linuxfr.org/comments/815651.html#815651 (c'est de moi).
> Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...
Le C ça pue. Quel catastrophe que le C soit le language le plus utilisé dans le libre. Je n'ose imaginer comme le noyau Linux serait merveilleux s'il était codé avec un vrai language d'homme comme le C++.
Tous des tarlouse les développeurs noyaux.
[^] # Re: Performances
Posté par benja . Évalué à 3.
Merci aussi de comparer des pommes et des poires (c'est sûr qu'un noyau et un toolkit ont les mêmes impératifs...).
Si tu veux, tu peux comparer GTK à FLTK qui est très bien, parait-il (je ne l'ai jamais utilisé, le c++ c'est beurk pour moi). Où alors linux v2.2 avec BeOS.
[^] # Re: Performances
Posté par kadreg . Évalué à 4.
http://linuxfr.org/2001/08/26/4667.html
(putain, 2001, et rien a évolué. Je croyais que les logiciels libres avaient l'avantage de la réactivité ...)
[^] # Re: Performances
Posté par IsNotGood . Évalué à -1.
Non.
Et c'est toi qui troll.
Trouve un file manager qui utilise magic(5) (c'est bien) et SVG (c'est bien) qui va plus vite que Nautilus si tu veux arrêter de troller.
[^] # Re: Performances
Posté par Alex . Évalué à 3.
Donc moi je suis également assez daccord pour dire que pour un navigateur de fichier, c'est un gros problème.
[^] # Re: Performances
Posté par pingui_style . Évalué à 2.
Il y a une amélioration notable des temps d'ouverture avec cette version 0.8 (bon je n'ai pas vérifié si le cache était vide ou pas vu que j'avoue ne pas trop savoir vers où regarder), mais en tous cas ça ne prend plus 20sec comme avant.
[^] # Re: Performances
Posté par sanao . Évalué à 8.
PS : Je demande l'indulgence, on est toujours vendredi.
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 2.
Bref, C++ c'est (très) bien, mais àmha pas si on veut aussi coder en python, ruby, perl, avec la même bibliothèque.
Étienne
[^] # Re: Performances
Posté par CrEv (site Web personnel) . Évalué à 4.
Mais quand on a gouté à qt, au model objet et surtout à la cohérence de l'ensemble ben y'a pas photo, ça marche bien, vite et ça se code assez facilement, que du bonheur (note : j'ai surtout touché à qt4, le 3 je connais moins)
[^] # Re: Performances
Posté par golum . Évalué à 2.
Gtk c'est pas cette lib que l'on a wrappé avec Gtkmm pour pouvoir l'utiliser convenablement avec un vrai langage objet.
Bref une lib objet qui oblige les programmeurs à les implementer au lieu de s'appuyer sur un langage adapté.
Bon bah vaut mieux utiliser QT ou Fox alors
http://www.fox-toolkit.org/
[^] # Re: Performances
Posté par Yusei (Mastodon) . Évalué à 3.
Non, on l'a wrappée avec Gtkmm pour qu'on puisse l'utiliser avec C++. Pour l'utiliser avec de vrais langages, on l'a wrappée sur Ruby, Python, OCaml, Eiffel (un peu), ...
Et aussi sur Perl, PHP, Java, C#...
Et probablement Lisp, Ada, et tous les autres.
Bouh, que c'est mal, cette lib qu'on peut utiliser avec le langage de haut niveau de son choix. Y compris ceux qui te donnent de l'héritage, du vrai polymorphisme et qui contrôlent les types à ta place. C'est quand même très fort de réussir à présenter ça comme un défaut.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 3.
Et ces salops ils le font aussi pour libgnome, gconf, gnome-vfs, etc...
Aucune morale.
[^] # Re: Performances
Posté par golum . Évalué à 1.
Des wrapper pour Qt, tu en a dans tous les langages aussi (rubyqt, pyqt, Qt Jambi, ...)mais au moins ils ont utilisé un langage d'implémentation qui les supporte plutôt que de les réinventer.
Bref, utiliser un langage procédural pour faire de l'objet c'est à peu près aussi malin que d'utiliser un marteau pour enfoncer une vis.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
Le C++ est aussi traduit en procédural. Il n'y a pas de CPU qui font de l'objet.
Utiliser C++ c'est comme "utiliser un marteau pour enfoncer une vis" ?
[^] # Re: Performances
Posté par Thomas Douillard . Évalué à 3.
Quand tu codes en C/Gobject, tu te soucie de "comment coder de l'objet en procédural"
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
C'est gobject qui fait ça.
> Et quand tu codes en C++, tu ne te soucie pas de comment le compilo va faire son boulot.
Quand tu codes en C++ avec gtkmm, tu ne te soucie pas de comment le compilo va faire son boulot et comment c'est linker avec gobject.
C'est mignon comme type de réflexion mais ça ne va pas loins. Un programme C++ utilise la libc (c'est du procédurale), un programme Qt utilise libx11 (c'est encore du procédurale), un autre va utiliser dbus, etc...
Les trucs 100 % C++ ça n'existe pas.
[^] # Re: Performances
Posté par Thomas Douillard . Évalué à 2.
Quand tu codes en C++, tu te fiches de la libc, quand tu codes en Qt, tu te fiches de la libx11. D'ailleurs QT n'utilise pas forcément la libx11, sous windows par exemple.
Les langages objets te permettent d'utiliser la POO sans te poser trop de question. Le C c'est déjà plus tendu, plus tricky pour implémenter de l'objet. Pourquoi vala sinon ?
[^] # Re: Performances
Posté par golum . Évalué à 1.
Je lui conseille la lecture de cet excellent livre pour comprendre en quoi le lange C n'est pas adapté pour la POO
http://www.planetpdf.com/developer/article.asp?ContentID=663(...)
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
T'es gentil, je le sais. Je n'ai jamais dit de faire du C++ avec du C (t'as remarqué le quasi non sens de cette phrase ?).
Mais tu peux faire du java ou du python ou du C++ avec gtk+ qui est codé en C. Il y a des wrappers pour ça et ça marche bien.
C'est bien gentil de troller avec des "gtk c'est pas du C++" mais gtk a plein de wrappers qui marchent.
Le sénario où pour chaque fonctionnalités il faut la coder dans chaque language est une aberration (ça demande énormément de développeurs).
Il y a un wrapper de X11, libxml2, gstreamer, postgresql, etc pour C++ (par exemple Qt) et on trouve ça très bien. Et je trouve ça très bien.
Il y a la même chose pour gtk+ (et pas seulement pour le C++) et je ne vois pas pourquoi ça ne serait pas bien.
C'est tout ce que je dis. Je ne dis pas de faire du C++ avec du C.
Mais la concèption de gtk pour faire des bindings vers d'autre language est un avantage définitif et pas une faiblesse.
Gtk n'a pas essayé de faire du C++ avec C, mais de permettre facilement des binding. Et c'est bien™.
Si Gtk avec un wrapper C++ est une connerie, alors pourquoi personne n'a recodé libxml2 en C++ par exemple ?
Pourquoi il n'y a pas un libX11 en C++ mais seulement des wrappers ? Pourtant c'est tout à fait possible. Pourquoi pas de libX11 en pure python ? C'est aussi tout à fait possible.
Je trouve ça marrant ces critiques des wrappers de gtk+ alors que c'est fait pour plein de librairies.
Rappel : gtk+ n'a pas été faite pour être utilisable uniquement avec C. Les faits montrent que c'est une réussite.
[^] # Re: Performances
Posté par ham . Évalué à 3.
Faire une lib avec une interface C pour la portabilité c'est bien, vue que n'importe quel langage a une glue pour le C.
Vouloir refaire de l'objet en C pour faire un un truc aussi attractif niveau programation que gtk, c'est une perte de temp
Je pense que vala est la preuve que la maniere dont a été développé GTK a été une erreur technique. Refaire un langage haut niveau qui génére du C GObject aurait du ètre la premiere etape de GTK , pas la derniere.
Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.
le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.
Les vrais langage objet sont bien plus facile a utiliser pour faire cela et vouloir programmer un toolkit graphique directement en C est AMHA un mauvois choix technique.
Ensuite si il l'avait fait en java qui sort du C je dirais pas, mais l'efficacité du C est moins bonne, sinon on aurais encore des compilo C++ qui génerais du C , comme au début, mais plus le langage est riche, plus on peut faire d'optimisation au niveau du compilateur et se concentrer sur des truc plus utile comme le framework, les algorithme, la concurence (comme avoir un thread d'affichage, un de collecte d'info de base et un de collecte d'info avancé).
[^] # Re: Performances
Posté par Yusei (Mastodon) . Évalué à 2.
Je suppose que tu parles de GTK en C, parce qu'étendre un widget GTK en Ruby se fait de la même manière qu'en Java: tu dis de quel widget tu hérites et tu modifies les méthodes qui changent.
Par contre en C c'est pénible, c'est sûr.
[^] # Re: Performances
Posté par ham . Évalué à 1.
Le commentaire pour l'extensions des widgets est surtout orienté extensions dans la lib, i.e plus de feature dans la lib.
Par exemple un menubar++ qui permet de changer l'orientation des menus,
ou autre truc bizzares,
Si c'est vraiment utile c'est mieurx de l'avoir dans la lib que de tout recoder dans chacun des langages cibles,
mais un truc que tu peut faire en 5 min en langage haut niveau, tu risque de mettre 1 semaine a le faire en C, avec plein de bugs.
C'est la ou le choix du C en tant que langage pour faire un toolkit graphique risque de limiter les évolutions des feature du tooklits.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
Plusieurs années après la sortie de gtk2, c'est facile à dire...
M'enfin tu montres que GObject est une bonne chose.
N'hésites à recoder gtk en vala si ça te chante. Bon courage. N'oublie pas de conserver des performances correctes.
> Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.
Bizarre, eclipse utilise gtk. Dans 7 ou 8 ans je pense que tu vas faire la leçon à eclipse.
> Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java)
Pour ton info, Java (la version officielle) utilise gtk pour swing :
http://ensode.net/java_swing_mustang_screenshots_gtk.html
M'enfin, c'est encore moi qui trolle, qui suit de mauvaise fois, etc...
> le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.
Et gdk ? Et pango ?
Il y a des aspects critiques en performance dans gtk (les grosses listes, le positionnement des widgets, le calcul de la taille sur l'écran d'une chaine, l'affichage en fonction du thème, etc). Regardes java, etc, pour le toolkit il passe par gtk ou équivalent.
Un toolkit écrit uniquement en java ou python serait une catastrophe niveau performance. J'en suis à 100 % convaincu.
Coder l'utilisation d'un toolkit peu raisonnablement se faire avec un language de haut niveau type java/python/etc.
Coder le toolkit, j'y crois pas. Et d'ailleurs ça ne c'est jamais vu. Du moins je ne l'ai jamais vu.
Pour info, swing n'est pas écrit uniquement en java. Il est aussi écrit en C.
[^] # Re: Performances
Posté par ham . Évalué à 1.
Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?
Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise, je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....
Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.
Ton lien est en effet trés intéressant, les gens sont content parceque swing va avoir une apparence comme GTK.
Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.
Pango c'est pas fait pour dessiner des polices? GDK c'est pas une lib pour dessiner?
Si oui ce sont en effet des éléments d'un toolkit graphique, mais un toolkit graphique c'est plus que ca, c'est plutot des collection d'elements graphique et la maniere de les faire interagir.
mais bon, j'ai assez nourris le troll, le
me fait douter, j'ai jamais vu des gens coder l'utilisation d'une interface en C.
mes si tu est sur a 100% , que tu y croit, ou pas d'ailleur, comme tu veut mais c'est pas ce que j'appelle un argument technique.
Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).
[^] # Re: Performances
Posté par IsNotGood . Évalué à 1.
Non, c'est que de la connerie. GObject c'est une daube.
> Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?
Ça pue GObject. Une perte de temps et en plus ça fait un trou dans la couche d'ozone.
> Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise
Ouais, mais les connards derrières eclipse, java et swing sont passés à gtk.
Franchement, la planète est peuplée de connards
> je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....
Mais t'as raison, Motif roxor.
M'enfin l'humanité n'est pas encore prête et Motif est abandonné. Faut prévoir son retour au 31ième siècle quand on aura tous un QI de 400. Trop tard pour moi, c'est con.
> la preuve eclipse utilise motif
Malheureusement pas pour longtemps. C'est seulement un option pour ceux qui ont su reconnaitre l'immense supériorité de Motif sur Gtk.
Il faut en profiter un max avant que gtk pourrisse eclipse définitivement.
> Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.
Pire que ça, il va utiliser gtk par défaut. Une horreur. En trois mots : une catastrophe industrielle.
> Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.
T'as raison, swing qui utilise gtk par défaut c'est un bon de 10 ans en arrière.
> j'ai jamais vu des gens coder l'utilisation d'une interface en C.
Ça doit être une légende alors. Et je ne l'ai jamais fait (pour moi : passer à corriger mon C.V.).
$ repoquery --whatrequires --queryformat="%{NAME}\n" libgtk-x11-2.0.so.0 | sort | uniq | wc -l
578
Merde, il doit y avoir un bug dans repoquery
> Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
Swt utilise gtk il ne recode pas tout le toolkit. Ou alors c'est une légende ? Pour awt, je n'en sais rien.
> On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).
On peut. Quelle dommage que le dictateur Linus Torvalds ait choisi le C.
[^] # Re: Performances
Posté par ham . Évalué à 1.
Le dialogue d'ouverture de fichier est donc le meme, on peu editer du RTF, parser du HTML avec exactement les mem fonctionalité avec GTK?
Si tu sait coder l'utilisation d'une interface en C ca m'interesse pour mes tests, c'est super pratique pour detecter les bug d'utilisation d'interface.
Ton argument c'est que un ou plusieurs toolkit de haut niveau (SWT;Swing) utlisent GTK, donc GTK c'est bien.
Ma remarque c'est que ces toolkits haut niveau utilisent les fonctions les plus basiques des toolkits systèmes,
les fonctionalité importante du toolkit (widget, architecture et API) sont recodé au dessus et n'ont rien a voir avec le toolkit de base.
Mais bon je te conseille vraiment de corriger to CV,
parceque coder l'utilisation d'une API c'est plutot décrire comment utiliser une API,
ca ressemble a des pre-condition, post-condition, comportement de l'interface, ... etc
De plus les seuls arguments avancé c'est "je peut voir des boutons GTK avec eclipse, GTK c'est bien"
C'est pas trés convainquant pour les capacité de recherche, d'analyse et de synthèse d'un Pb.
Je ne corrige pas de CV, mon orthographe est trop lamentable pour ca.
[^] # Re: Performances
Posté par golum . Évalué à 2.
Belle argumentation technique sur les qualités de GObject.
Tu m'impressionnes chaque jour un peu plus
Sauf que le mr te repondais sur le fait que ce n'est pas parce que Eclipse utilise Gtk que c'est un gage de qualité. Motif aussi donc selon tes arguments Motif dechire forcément. Merci de demonter ton raisonnement par la dérision à sa place
Tu relis ce à quoi tu réponds des fois. que gtk ou n'import quel lib soit utilisée importe peu puisque c'est les primitives bas niveau qu sont utilisées. Les Widgets et autres layout qui dechirent sont tous réimplémentés dans SWT/JFace.
Non mais que ce soit AWT ou SWT la réutilisation est mince. Même si AWT utilise encore moins les services du tk hôte que SWT.
http://www.jguru.com/faq/view.jsp?EID=507891
Ceci aurait tendance à me conforter dans l'idée que GTK n'est pas un foudre de guerre quand on compare les perfs d'eclipse sous Win32 ett Gtk. L'appoche AWT est encore pire mais ca ne dédouane pas Gtk pour autant. On sait pourquoi ca rame alors qu'avec SWT/gtk il y a de quoi se poser la question.
[^] # Re: Performances
Posté par golum . Évalué à 3.
Eclipse utilise SWT qui n'utilise que quelques primitives graphiques d GTK.
Il y a eu un port de SWT vers Qt mais ce qui posait pb etait la license à l'époque.
D'ailleurs, en comparant les perf d'eclipse sous windows et sous Linux on se dit que GTK n'a pas de quoi pavoiser.
[^] # Re: Performances
Posté par golum . Évalué à 2.
[^] # Re: Performances
Posté par ola . Évalué à -2.
Et je valide aussi qu'eclipse linux est d'une lenteur sans non sur ma babasse perso (athlon 1600+XP/768Mo ram) alors qu'il tourne plus que decemment sur un windows sur la meme machine.
[^] # Re: Performances
Posté par ola . Évalué à 0.
Et aussi pour win32 (trou de memoire pour le nom de l'api) et aqua ('fin le machin de chez appeule)
Et il ne s'en sert effectivement que pour les primitives graphiques, toute l'ihm derriere et faite en java.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 3.
Ben gtk est le toolkit de référence sous Unix. Utilisé par Java, Gnome, eclipse, XFCE, OOo, Mozilla (firefox etc), gimp, Inkscape, etc...
Vient après Qt en popularité. Je ne dit pas que Qt est moins bien, mais le gros atout de gtk par rapport à Qt c'est ses bindings.
Dans 10 ans ça continura de troller.
[^] # Re: Performances
Posté par lezardbreton . Évalué à 3.
[^] # Re: Performances
Posté par alice . Évalué à 3.
Swing (java) et VCL (OpenOffice) utilise GTK?
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 3.
[^] # Re: Performances
Posté par Dr BG (site Web personnel) . Évalué à 4.
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 4.
T'es pas obligé d'étendre ton Widget en C, tu peux le faire dans n'importe quel langage ayant une passerelle vers C/GObject. Évidemment, ce sera plus dur d'exposer ton super nouveau Widget vers d'autre langage une fois que t'aura choisie python ou ruby.
C'est d'ailleur pour ça que j'utilise C/GObject directement pour gnome-scan, je veux un bindings python, C++, perl, ruby, … et un vapidef :)
Étienne
[^] # Re: Performances
Posté par golum . Évalué à 3.
On ne critique pas le C.
Ce qu'on t'explique c'est que coder un tk graphique qui sous-tend des concepts résolument objets avec un langage qui ne l'est pas est une mauvaise stratégie.
T'as beau invoquer Linus, libx11 et toutes les libs de bas niveau C de Linux/X11.
Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.
Peu importe qu'il y ait des bindings. Personne ne le conteste mais
le langage d'implementation par défaut conditionne le reste.
On va pas se taper toutes les libs et tous les interpréteurs de la création pour implementer la lib GTK (sinon bonjour les dépendances). On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.
Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche. Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables. Aucun doute c'est un vrai langage qui roxor sa mère.
Et c'est pareil pour les exemples avec Swt / Swing et wxWidgets
Ces libs sont bien obligées de s'appuyer sur les primitives graphiques de l'OS (GDI pur Windows et gtk pour linux) . C'est le minimum. Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet. Pareil pour wxWidget, Fox, XPToolkit, Gnustep, ... Quasiment tous les tk modernes utillisent un langage objet. Seul les viellissants Motif, GDI et OS/2 PM avaient fait ce choix maias pour combien de temps. OS/2 est mort, Motif agonisant et MS tente le virage C# mais recule devant l'ampleur des dégats.
http://www.free-soft.org/guitool/
Je vais arrêter là car tu vas encore nous ressortir les mêmes pseudo contre exemples et on va tourner en rond.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 3.
Très bien, mais j'ai dit plus 400 000 fois que la force de gtk est ses bindings.
Si pas de binding, le C++ c'est mieux.
En passant, je développe aussi en C++ et je préfère le C++ au C.
Mais le fait que je préfère le C++, que le C++ soit supérieur au C, n'est pas un raison que gtk a eu tord d'être écrit en C. Gtk n'a pas été écrit en C pour l'amour du C mais pour avoir les binding.
Alors vous pouvez continuer à dire que gtk en C c'est une connerie, mais les faits sont là : gtk a des binding, beaucoup, et ils marchent bien.
Qt a quelques bindings avec un ou deux qui marchent bien.
Si un des principaux objectifs est d'avoir des bindings, gtk a eu raison d'être écrit en C, de faire GObject, etc... Les faits le démontre.
> Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.
Tu t'emballes un peu. Certe libX11 n'est pas libXt, mais l'idée est là.
C'est Kernighan qui disait que tout bon programme C est orienté object. Du montant que tu as des structures et que tu y associés des fonctions (de façon directe ou non avec les pointeurs de fonction, en utilisant des types, etc) c'est de la programmation object. Ou dit que c'est de l'encapsulation de données si ça vexe ta haute idée de la POO.
En passant, la POO n'est pas réservée à aux languages dédiés POO. Linux est un assez bon exemple de POO. Lis les sources pour t'en convaincre.
Il y a des concepts qui s'exprime naturellement en objet et aussi en C. Le "FILE *" de la libc, c'est définitivement un object. Trouve ça horrible si tu veux (je trouve ça moche aussi à côté des facilités C++), mais c'est un object.
> Peu importe qu'il y ait des bindings.
Non. Et je ne comprend pas ce type argument qui flirt avec le ridicule. Le choix du C pour gtk c'est les bindings. Donc ne critiquez pas ce choix sans considérer les bindings, sans considéré les objectifs de gtk.
Si tu définis les objectifs de gtk alors oui gtk aurait dû peut-être être fait dans un autre language. Mais pourquoi on choisi un language ? Car on a des objectifs.
Il faut faire une interface pour une base de donnée, VB est un bon choix. Il faut faire une interface pour un automate avec des contraites temps réel, une interface très riches qui remonte beaucoup d'info, alors VB est un mauvais choix.
Ignorer les objectifs dans le choix d'un language est une aberration.
> le langage d'implementation par défaut conditionne le reste.
Tu l'as dit.
> On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.
Rires. Si C++ roxe des ours dans tous les domaines et même pour faire des bindings, pourquoi Qt en chie pour avoir des bindings ?
Tu m'expliques ça ?
Manque de popularité ?
Ça m'étonnerais, vois comme je me fais moinser pour "défendre" gtk.
KDE utilise plein de lib en C. KDE peut piocher dans les librairies C et si besoin faire un wrapper C++. KDE mais aussi python, perl, java, C#, ada, php, etc... L'inverse est rare. Tu m'expliques ça ?
Et ce n'est pas de la mauvaise fois de ma part ou du troll ou autres conneries dans ce goût dont on m'accuse, c'est un FAIT.
> Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche.
Les faits montrent que gtk a utilisé le bon outil pour la tâche d'avoir des bindings.
> Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables.
???
Il y a des objectifs, parfois le C est adapté, parfois le C++, parfois VB, parfois l'assembleur.
Mais pour les objectifs de gtk, le C++ n'est pas adapté.
> Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet.
Pourquoi pas. Et gtk le permet.
[^] # Re: Performances
Posté par golum . Évalué à 2.
Fort bien l'un des objectifs de Gtk est de fournir des bindings pour tous les langages de la création.
Seulement sa conception est basée sur l'objet.
Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet. Faire du fortran objet , quel intêret ?
Qt s'est fixé pour objectif de faire une lib bien conçue et ce qui permet d'entreprendre des changements de conception plus simplement. Les bindings vers les pricipaux langages existent aussi. Donc l'objectif est rempli également. Je ne vois pas en quoi Qt en chie comme tu dis .A la limite c'est sûr que pour des langages procéduraux la tâche est plus ardue. Rendre un hériatage multiple avec du C ne doit pas être évident par exemple.
Les bindings comme PyQt se focalisent sur le fait d'apporter des fonctionnalités supplémentaires propres au lanage hôte (comme par exemple etendre les signaux/slot en dynamique).
sauf que le seul mécanisme que tu cites est l'encapsulation et encore de façon imparfaite. Ce n'est qu'un des concepts de la POO. dès que tu la fait intervenir avec l'héritage, le C montre ces limites. Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.
Ne parlons pas du polymorphisme. Avec du C et l'utilsation intensive du void* tu peux te retrouver assez facilement avec des core dumps. Chose qu'un langage objet est capable de gérer. (Compilation impossible avec un langage statique, Exception avec
Ne parlons pas du multi-héritage, de la façon de gérer les exceptions , ... )
Sinon si tu veux parler de KDE, compare le avec Gnome et son Mono/C# pas avec Gtk.
[^] # Re: Performances
Posté par yoplait . Évalué à 3.
Les bindings, les performances, c'étaient peut-être de bonnes raisons il y a 10 ans, mais plus vraiment maintenant. Je crois qu'il y a consensus sur ce sujet.
[^] # Re: Performances
Posté par IsNotGood . Évalué à 2.
> Seulement sa conception est basée sur l'objet.
Et ?
Je ne vois pas le problème. Dans Linux il y a plein d'objets aussi. En quoi passer à C++ rendrait Linux meilleur ?
Pourtant Linus a voulu un certain temps passer à C++. Mais il a trouvé qu'il y avait des problèmes et a abandonné l'idée. Désolé, je ne connais pas les détails de l'affaire. Je les connais dans les grandes lignes mais l'expliquer ici serait long et hazardeux. Principalement des problèmes d'optimisation.
Même si un langage n'est pas adapté à la POO, pourquoi s'interdir de faire de la POO ?
Il y a ici quelque chose qui m'échate.
Comme tu veux implémenter par exemple des menus sans faire de programmation object ou seulement en utilisant un paradigme procédural ?
Voilà un menu :
struct menu {
bool sub_menu ;
void* action_or_menu ;
...
} ;
struct menu main_menu[] = { true, menu_fichier}, {false, display_about}} ;
Ok, c'est immonde, mais c'est d'idée qu'il faut suivre.
C'est de la programmation objet et c'est très courant en C.
> Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet.
Ça dépend comment tu penses. L'exemple précédent ne simule pas de l'objet. C'est de l'objet. Si tu penses structures de données, pointeurs de fonction, il se peut que tu ne te rendes pas compte que c'est de l'objet.
Si l'objet pour toi demande systématiquement de l'édition de lien dynamique, des type utilisateur, etc... alors pour faire de l'objet en C il faut le "simuler" et rentrer dans des techniques pas évidentes à mettre en oeuvre. Mais c'est ta conception de la POO, c'est ta façon d'aborder la programmation qui te fait penser que le C ne doit pas être utiliser pour faire de la POO.
Je peux t'assurer qu'on peut être redoutablement efficace en C même en faisant de la POO. Par contre si tu veux tout le luxe de la POO en C, c'est beaucoup plus lourdingue de le faire. Notes que faire une librairie C++ avec tout le luxe de la POO, c'est aussi beaucoup de boulot (et même beaucoup plus qu'on ne le croit en général).
Un autre exemple de programmation object très courrant, c'est tout ce qui est lié aux bases de données. Chaque enregistrement est une instance d'un object, ils ont des propriétés, par contre les méthode ne sont pas dans la base de donnée (ou rarement). Mais il y a souvent ici le paradigme POO d'appliqué.
Dès que tu fais un système de plugins, tu fais de la programmation objet. Et si c'est en C, ce n'est pas un cauchemard à réaliser.
> Qt s'est fixé pour objectif de faire une lib bien conçue
Qt est une superbe librairie.
> Les bindings vers les pricipaux langages existent aussi.
Certe.
> Je ne vois pas en quoi Qt en chie comme tu dis .
Un exemple :
http://developer.kde.org/language-bindings/java/ Pas vraiment complet. Et pourtant Java est object "comme" Qt.
Java pour gtk (mais aussi gconf, gnome, gstreamer, etc) existe depuis un bon moment.
> Donc l'objectif est rempli également.
Tout est possible. Théoriquement je ne vois pas pourquoi il n'y aurait pas de binding pour Qt. Mais c'est lourd à mettre en oeuvre. D'autant plus si Qt veut utiliser toutes les fonctionnalités du C++.
> Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.
Ben oui. Et plus tu montes la barre haut en exigence de fonctionnalités, plus tu as des difficultés pour faire des bindings, plus tu es exigent envers le language à "binder", moins tu es neutre envers les language pourvant être bindé.
[^] # Re: Performances
Posté par golum . Évalué à 2.
Mais en gros effectivement le langage C ne supporte de façon a peu près gérable qu'un sous-ensemble du paradigme objet.
Oui, le choix du langage d'implémentation influe sur la conception
Le choix de Gtk est d'offrir des possibilité limitées pour supporter un max de langages. Chaque langage et notamment tous les langages objets doivent donc réimplémenter certaines fonctionnalites pour arriver à un niveau de fonctionnalités qui sera finalement commun entre eux ou laisser le soin au developpeur d'application de refaire le travail à son niveau?
Gtk fait le choix du plus petit commun dénominateur en ayant choisi le C
Qt offre plus de possibilités mais contraint les langages plus limtés à mettre en oeuvre des contournements. Pour autant ce n'est pas chose impossible et certains bindings sont de belles réussites.
Pour Java, ton lien date un peu puisque Trolltech propose maintenant son propre binding
http://www.trolltech.com/developer/downloads/qt/qtjambi-tech(...)
[^] # Re: Performances
Posté par IsNotGood . Évalué à 3.
Non. C'est comme si tu disais que Linux offrait des possibilités limités.
Gtk demande peu au niveau fonctionnalité du language. Ça ne veut pas dire que c'est limité. Tous les programmes finissent en assembleur, ils ne sont pas forcément limités.
Bien que gtk puisse se programme en C classique, il peut aussi se programme en avec du "pure" C++ ou Python, etc... On peut avoir des constructeurs, surcharge des opérateurs, dériver, etc... le mieux adapté au language (il y a évidement quelques cas particuliers).
> Gtk fait le choix du plus petit commun dénominateur en ayant choisi le C
Pas au niveau fonctionnalité. La façon donc sa va être implémenté pour les autres languages, dépend des autres languages et de la façon dont c'est implémenté (pléonasme). Si c'est du java, c'est du java 100 % (disons 95%), ce n'est pas java limité au C.
> Qt offre plus de possibilités
Tu (et je aussi peut-être) mélange facilité du language et possibilité/fonctionnalité de la librairie.
Une librairie avec des possibilités limités, qu'elle soit en C++ ou C reste une librairie limité.
Gtk gère les thèmes car on veut que toutes les applis soient "unifiées". Gtk offre une boite "save as" complète et utilise gnome-vfs s'il est là, car on veut que toutes les applis utilisent la même boite. Gtk gère le position des widgets les un par rapport aux autres (élastique), etc...
Il ne sagit pas de limité les fonctionnalités, mais de les mettres à leur place.
Si chaque language recode la boite "save as" ou les thèmes, c'est une perte de temps et une perte de cohérence de l'ensemble du bureau.
Certe aujourd'hui une appli swing ou eclipse ne ressemble pas parfaitement à gtk, mais ce n'est pas une feature, c'est un défaut qui doit être corrigé (c'est mon avis) comme il est corrigé petit à petit dans OOo, Firefox, etc. Pas car gtk roxe, mais pour avoir un bureau cohérent.
[^] # Re: Performances
Posté par Étienne BERSAC (site Web personnel) . Évalué à 2.
Alors là c'est faut. C/GObject permet les constructeurs de classes, les destructeurs d'instance/de classe, introspection, etc.
C/GObject est au contraire plutôt complet.
Étienne.
[^] # Re: Performances
Posté par Alex . Évalué à 1.
[^] # Re: Performances
Posté par lolop (site Web personnel) . Évalué à 2.
http://ldeniau.web.cern.ch/ldeniau/html/oopc.html
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Performances
Posté par golum . Évalué à 2.
Merci de citer ce cher Kernighan pour convenir qu'une bonne conception est objet et qu'il vaut donc mieux utiliser un langage objet plutôt que procédural pour arriver au même résultat. D'où ma petite remarque un peu plus haut sur le marteau et la vis.
Notes que la POO ne résoud pas tous les pbs, ce qui explique la venue de concepts transversaux comme l'AOP par exemple.
Sinon quand je parle de contre-productivité c'est bien de ca qu'il s'agit .
Avec une telle conception tu dois impléménter l'héritage virtuel en écrasant toi même ton pointeur de fonction dans l'instanciation de ton objet ou mettre en place un mécanisme d'indirection à la place du compilo.
Si tu veux faire persister des objets dans des fichiers à plat (comme des paramètres de config de ton appli), tu dois concevoir ton application afin de ne stocker que les données et pas les blocs alloués à tes pointeurs d'opération. Sinon tu devras faire un programme de reprise de données pour réaligner les blocs en récompense de ta négligence. Heureusement les petits gars de GTk font une bonne partie du boulot pour nous (j'imagine) qui utilisons ces supers bindings alors qu'ils auraient pu réflechir à plein d'autres trucs intéressants.
Avec une telle conception tu dois passer ton temps a caster ton objet dans ton code pour tes appels polymorphes à une référence de cet objet alors que ton compilo C++ le déduit tout seul. Si tu es feignant tu mets des void* partout dans les signatures de tes contrats et il y aura toujours un benet qui travaille sur une autre lib qui passera une mauvaise référence et qui fait planter son programme. Belle séance de debbugging en perspective....
Après avoir donné 5 ans dans le registre je peux te donner plein d'autres exemples.
Oui mais chez nous on a plein de bindings pour tous les langages de la création même le pour logo et en plus le C ca déchire question perf, Na!
[^] # Re: Performances
Posté par yoplait . Évalué à 4.
Moi ce que j'aime bien avec les analogies c'est qu'avec un peu d'imagination on leur fait toujours dire ce que l'on veut...
Donc la vis représente la POO, le marteau représente le C, un langage procédural. Oui, mais GObject lui, est la cheville que l'on a adapté à la vis afin d'obtenir une magnifique cheville à clouer (qui est reconnue pour sa rapidité de mise en ½uvre) nous permettant de faire de la POO avec du C.
CQFD.
# Pas grand chose de neuf ...
Posté par Thomas Douillard . Évalué à 3.
Et si je fais un compilateur de python vers C, qu'on appellerait pyc, avec un système de bindings pour utiliser des bibliothèques C, il n'y aurait pas besoin de définir le python comme un langage accepté dans gnome, puisque "c'est du C ?"
Plus sérieusement, des compilateurs pour traduire d'un langage quelquoque vers du C, il en existe pleins, ça n'a pas grand chose d'extraordinaire. Tu as l'air de confondre le lagage en lui même et ses implémentations potentielles ... pour moi vala ça ressemble à une défaite des principes qui sous-entendent l'utilisation du C par gnome: on utilise du C parce que performant et pour faire des bibliothèques, mais au final c'est trop chiant alors on fait comme les autres et on passe à un truc plus haut niveau :)
Pour les perfs, ça dépends autant de l'implémentation du langage que du langage lui même.
Le seul intéret que j'y vois par rapport à l'utilisation d'un autre langage de plus haut niveau est de réutiliser l'existant. Après, pourquoi avoir réécris un nouveau langage et pas avoir réécris un compilateur C# par exemple (je dis ça parce que le lagage dit s'en inspirer) ?
[^] # Re: Pas grand chose de neuf ...
Posté par Étienne BERSAC (site Web personnel) . Évalué à 4.
> pour moi vala ça ressemble à une défaite des principes qui sous-entendent l'utilisation du C par gnome
Vala est loin d'être le futur langage de Gnome. Ça fait belle lurette que Gnome n'est pas écrit totalement en C/GObject. C++, Java, C#, perl et Python ont leur passerelles dans Gnome ( http://live.gnome.org/TwoPointNineteen/Bindings ). Le GObject a été conçu avec deux objectifs :
* avoir une API object en C
* passerelle automatique et transparente pour d'autre langages compilés où interprêté.
( cf. http://developer.gnome.org/doc/API/2.0/gobject/chapter-intro(...) ).
Dans le concept même de GObject, il n'y a pas l'exclusivité du C/GObject. Gnome se veut agréable pour l'utilisateur mais aussi le développeur en lui laissant le choix du langage (autant que possible). Vala n'est et ne sera qu'un choix de plus dans la liste !
Étienne.
[^] # Re: Pas grand chose de neuf ...
Posté par Thomas Douillard . Évalué à 2.
C'est assez curieux comme démarche je trouve d'implémenter un modèle objet dans un langage non objet, et ensuite seulement d'inventer le langage qui va avec le modèle. C'est comme si tu avais commencé à implémenter un langage objet en C sans même connaître le langage ...
Ça fait aussi furieusement penser aux concepts de .NET, avec sa machine virtuelle conçue pour implémenter des langages objets entre autre, sauf qu'ici on compile en C/Gobject et pas dans le langage de la machine virtuelle ( CLR ? )
[^] # Re: Pas grand chose de neuf ...
Posté par benja . Évalué à 2.
Ben justement l'intérêt c'est de pouvoir transposer cette architecture en "objets" facilement dans un language qui propose directement ces facilitées. Les bindings n'ont pas à définir un arbre d'héritage: il existe déja ! Aussi pour la documentation, l'API du binding et la documentation officielle de GTK suffisent.
Si on ne veut pas faire de GObject, on utilise un binding dans le language de sont choix et c'est tout. point barre.
# Commentaire non constructif...
Posté par Anonyme . Évalué à 2.
Pour faire à moitié semblant d'apporter quelque chose à un semblant de débat : je suis contre le langage SMS, les fautes d'orthographe à outrance (quand elles sont faites par quelqu'un qui pourrait les éviter en prenant la peine de se relire), et pourtant j'aime bien des expressions du style maichant, saymal, flashcaymalsapusaypalibre, etc. Contradiction ?
(Attention un deuxième troll s'est glissé dans ce message)
# Debugger ?
Posté par alberthier (site Web personnel) . Évalué à 2.
L'idée, c'est bien :
machin.vala -- valac -> machin.c -- gcc -> executable
donc j'imagine qu'on ne peut débugger que le fichier c généré ou alors y a moyen de remonter aux sources vala.
En tout cas, c'est un projet intéressant, permettant de remplir à la fois l'objectif de gnome d'écrire toute sa lib en C pour être portable et le désir de certains progammeurs d'utiliser un langage de haut niveau.
En tout cas, je trouve que c'est une bonne idée, je m'interroge juste sur les possibilités de debuggage.
[^] # Re: Debugger ?
Posté par Étienne BERSAC (site Web personnel) . Évalué à 2.
À mon avis, ça doit se debogué comme du pygtk. Sauf si on tombe sur une bogue de vala. C'est clair cependant, que savoir ce qui se passe sous le capot n'est pas inutils, comme partout … Faudrait voir ça en détail avec les dévs de Vala.
Étienne.
[^] # Re: Debugger ?
Posté par Nicolas Schoonbroodt . Évalué à 7.
[^] # Re: Debugger ?
Posté par Yusei (Mastodon) . Évalué à 5.
Il y a des instructions qui indiquent au compilateur C la correspondance entre sa ligne de code C et la ligne de code Yacc correspondante. Du coup, les informations de débuggage renvoient vers la bonne ligne.
[^] # Re: Debugger ?
Posté par benoar . Évalué à 3.
http://live.gnome.org/Vala/Roadmap
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.