Je rebondis sur le journal "Quel langage pour quel utilisation" ( http://linuxfr.org/~hrod/20037.html ) pour m'interroger sur les raisons et la pertinence du choix de langages interpretés pour des applications de "desktop".
Je pense en particulier à des applications comme :
- Perlpanel, une barre de taches proposant une trentaine de plugins, écrite en Perl.
- Pypanel, une barre de taches plus modeste, écrite en Python.
- L'environnement Rox, ou de nombreux plugins sont écrit en Python, et au moins un en Ruby
- Les environnements d'applet de bureau gdesklets et adesklets
Pour les environnements traditionnellement développés en C ou C++ comme XFCE, Gnome ou KDE, on voit murir des bindings Python, Perl, Ruby, voire Mono ou Java.
Cet engouement pour les langages interprétés est-il :
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
- Une critique de la complexité des librairies de ces environnements ?
- Une critique du cycle de développement sous ces mêmes environnements (et Klik serait une autre réponse à ce problème) ?
On peut déplorer la dilution des performances et l'occupation mémoire accrue de ces applications face à des langages compilés. Cependant, le principal "gaspillage" réside à mon sens, plus dans la multiplicité des interpreteurs utilisés que dans l'usage, en soi d'un interpréteur.
La multiplicité des interpréteurs se conjugue avec la multiplicité déjà contre-productive des librairies graphiques, ce qui fait qu'on peut craindre un appauvrissement du desktop linux face à l'homogénéité de Windows.
On peut aussi se réjouir que la marche d'entrée pour développer sa propre applet, sa propre extension de bureau, s'abaisse au cours du temps, et constitue en soi un avantage du desktop linux face à Windows.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
Journal Langages pour desktop
23
nov.
2005
# ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
On voit de plus en plus dans le libre, un outils bien autère mais qui fait tout ce qu'on lui demande (cdrecord) et une foultitude d'outils graphique qui essait de coller les morceaux.
Avec un tel approche, on enfin pu voir un truc simple comme k3b s'imposer.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Raoul Volfoni (site web personnel) . Évalué à -1.
Doit-on comprendre qu'ils laissent passer les fautes d'othographe? ;)
[^] # Re: ...
Posté par Fanf (site web personnel) . Évalué à 1.
Arg. Moi, je dirais, "souvent, les langages modernes sont de plus haut niveau que les vieux trucs". Mais je reconnais que ta phrase est très nuancée ;)
OCaml, c'est compilé, et c'est de haut niveau. Juste pour donner un exemple.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A quand un OcamlC :)
"La première sécurité est la liberté"
[^] # Re: ...
Posté par golum . Évalué à 6.
Celui là il est énOOOrme
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Fanf (site web personnel) . Évalué à 3.
Peut être que ce qui est déconcertant avec OCaml, pour les néophite, c'est qu'on peut programmer en fonctionnel (c'est aussi un très gros avantage en terme d'expressivité). Par contre, ça demande de penser un peu différemment, et donc de s'habituer à cette manière de penser.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
# let average a b =
(a +. b) /. 2.0;;
val average : float -> float -> float =
pour :
float
average (float a, float b)
{
return (a + b) / 2;
}
Lequel est plus clair ?
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Uvoguine . Évalué à 2.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il aussi le fait qu'une majorité de langage sont basé sur le C (perl, C#, java, C++, php(?)) et qu'une partie du cerveau des développeurs est codé sur ce modèle. Donc, changé pour changé n'a pas "suffisamment" d'interet.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par nooky59 . Évalué à 1.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 5.
Dans la plupart des cas, rajouter des parenthèses facultatives rend le code beaucoup plus clair, mais comme ce n'est pas obligatoire, ce n'est pas systématique. Au moins en Lisp, pas de problème :)
[^] # Re: ...
Posté par Khâpin (site web personnel) . Évalué à 5.
C'est pas le principe de base d'Unix, ça?
(chaque outil ne fait qu'une chose, mais le fait bien, séparation client/serveur, IHM/programme...)
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 7.
Si mais ce principe était parfaitement adapté y'a 20-30 ans, et il ne l'ai plus en partie aujourd'hui. Un truc qui fait une seule chose et qui la fait bien, OK. Mais ca c'est pas vraiment le propre d'Unix. Une grosse particularité d'Unix c'est le trip des "pipes", il y a une époque où l'on croyait quon construirait des logiciels fabuleux (et complexe, loin d'être simple) justement en chaînant les programmes grâce aux pipes. Du coup on se retrouve avec des programmes comme cdrecord, prévus pour marcher en ligne de commande, avec une entrée et une sortie standard. Ben dans le cadre actuel, et peux ceux qui réalise des IHM c'est tout simplement affreux, pénible, pas performant, bref c'est nul :)
Heuresement les choses évoluent, et les outils en ligne de commande sont enfin parfois vus pour ce qu'ils sont : une simple IHM comme une autre, qui ne fait pas le boulot. Le boulot il est dans une lib, une lib partagée avec des méthodes, des types, des classes, etc., bref quelque chose d'infiniment plus friendly qu'un traitement de chaîne de caractères sur une redirection de pipe pour communiquer avec un soft en ligne de commande.
Le principe de séparer les responsabilités n'est pas du tout le propre d'Unix, il est présent partout dans l'informatique. La méthode "ala Unix" à base de pipe et redirection est périmée, le modèle actuel c'est plutôt la programmation objet, on un objet fait une chose et une seule et la fait bien.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 5.
regarde MPD qui n'est qu'un serveur de son ... il le fait, et il le fait bien ...
après, il y a moults interfaces, dans tous les langages du monde ... peu de chance de pas trouver ton bonheur (ça va de la ligne de commande, en passant pas le web et le client GUI digne, et j'en passe)
ce principe là, moi je l'adore ... et je le trouve proche de la perfection. Les tâches ont été bien découpé, et il y en a pour tout le monde.
Comparé aux clients lourds que sont rhythmbox, muine, amarok et cie ?! y a pas photo ... qui regarde son player quand il joue un morceau ?! ;-)
sinon, pas trop grand chose à voir ...
mais si ça peut faire débat :
http://www.timestretch.com/FractalBenchmark.html
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 3.
Euh, c'est idiot ce que tu dis... tous ces logiciels sont pour la plupart des frontend à GStreamer ou autre Xine. Rien ne les empêcherait d'être des frontend à MPD. Mais l'idée est là, que ce soit sous forme de serveur ou de lib, il y a une séparation fonctionnelle et une interface autre qu'une simple entrée/sortie standard.
qui regarde son player quand il joue un morceau ?! ;-)
Ben faut bien choisir à un moment ou un autre ce que tu veux écouter, et rien ne vaut une interface épurée et simpliste comme Muine :)
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 3.
> la plupart des frontend à GStreamer ou autre Xine. Rien ne
> les empêcherait d'être des frontend à MPD
il y a une sacré différence entre ce qu'est MPD et ce qu'est Gstreamer.
(MPD est un serveur de musique, Gstreamer ne sont que des tuyaux)
tu vois de suite la différence : si tu quitte muine (ou autre), la musique elle s'arrête ;-) ... pour faire simple
> Muine :)
C'est du mono, c'est ça ? ;-)
mais il me semble que le projet mono phare, dans le monde musical est banshee ...(n'est pas un fork de muine ?!)
toujours utilie que je persiste ces "interfaces/player de son" tout en un sont dépassés ... ce serait tellement mieux si ces interfaces, utilisait le serveur de son MPD, qui lui même utiliserait gstreamer comme tuyaux vers l'audio ...
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Je sais bien, comme je l'ai précisé, il ya 2 solutions : faire une lib (gstreamer) ou faire un serveur (MPD), forcement dans la première solution la musique s'arrête quand tu fermes l'appli :)
mais il me semble que le projet mono phare, dans le monde musical est banshee ...(n'est pas un fork de muine ?!)
Oué mais je préfères Muine pour le moment. Et Mono ou pas, j'ai pas trouvé mieux à mon goût sous Gnome :-p
e serait tellement mieux si ces interfaces, utilisait le serveur de son MPD, qui lui même utiliserait gstreamer comme tuyaux vers l'audio ...
Mouais pas forcement. Ca commence à faire lourd là, on a un serveur qui parle à gstreamer qui parle au serveur de son qui parle au hardware...
L'utilisateur lambda, il y connait kedal de ces détails clients/serveurs, pour lui quand il ferme l'appli il veut que la musique s'arrête. Pour moi le paradigme client/Serveur n'a d'utilité en règle générale que s'il y a un réseau ou plusieurs utilisateurs(programmes) en local.
Un serveur de son est utile, parcque plusieurs utilisateurs peuvent jouer de la musique en même temps. Un serveur de musique en local, je vois tout de suite moins l'intérêt. C'est un peu ce qui arrive au serveur X, celui-ci avait tout son intérêt auparavant, quand les terminaux X étaient légion, mais aujourd'hui c'est plus un boulet qu'autre chose... alors je sais pas lequel est dépassé :)
Dans tous les cas c'est un choix d'architecture, je ne vois absolument pas où est l'avantage d'avoir un serveur comme MPD en tant qu'utilisateur et pas plus en tant que développeur. Le modèle client lourd n'est pas du tout dépassé.
[^] # Re: ...
Posté par Mildred (site web personnel) . Évalué à 1.
Et aussi, pouvoir fermer le player et pouvoir toujours écouter la musique, c'est très bien, je trouve. Et ce n'est psa forcément inintuitif.
Sur Mac OX X (que j'aime bien) par exemple, lorsque tu ferme la fenêtre d'iTunes (et sans doute des uatres players), iTunes, reste chargé et la musique continue. A mon avis, c'est un des avantages de l'environnement MacOS : la possibilité d'avoir une application qui reste ouverte sans fenêtre.
Bien sûr c'est possible partout. Mais Mac OS l'a intégré a son environnement et c'est un comportement normal. Quel interêt de voir une grande fenêtre.
Un autre exemple, pour garder préchargées eds applications lourdes (OpenOffice par exemple). Lorsque tu ferme un document, le logiciel reste lancé et tu peux réouvrir un autre document sans perdre de temps. Et pas besoin d'avoir une grande fenêtre vide avec juste deux menus ...
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
(dans le sens, t'es obligé de lancer un process/gui, qui va bouffer 150mo en memoire, pour jouer un simple mp3 ?!?, et tout ça uniquement à cause de l'interface, qu'en plus : tu n'es pas censé regarder ?!)
Mais, à mon humble avis, c'est les habitudes ancestrales de l'autre os.
Pour ne pas rebuter un "utilisateur novice", il y aurai moyen d'installer tout ça (mpd + interfaces), sans qu'il puisse entre-appercevoir qu'il y a un serveur de son ...
Le serveur, c'est la fonctionnalité, c'est lui qui joue, et qui occupe si peu de ressources pour faire la zic, et il se pilote par moults interfaces, c'est tellement logique ...
[ma vie]
- je me suis fait un frontend en python pour lancer des albums tout fait sous mpd
- j'utilise aussi glurp (gui gtk), pour constituer des playlists ou faire des ecoutes unitaires dans mpd
- j'utilise phpmpc, pour piloter la zic à distance via http, le tout branché sous icecast, ce qui me permet d'écouter ma zic, partout où internet est, sous mpd
- mon clavier multimedia pilot "mpc" pour piloter l'audio (et des touches spécifiques pour qques radios)
- idem pour ma telecommande via lirc
- et plein de petites choses, comme l'affichage en OSD du titre,
c'est d'une cohérence totale ... et tout ça, que je sois sous X, en console, en ssh/http distants.
[/ma vie]
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Désolé, on n'a pas tous envie d'utiliser la console pour jouer des mp3. Faut bien lancer une IHM à un moment ou un autre pour jouer de la musique, et celle-là t'es censé la regarder. Ces IHM te facilite la recherche de musique, te fournissent des informations comme la pochette de l'album, les paroles ou encore la bio de l'auteur. Ces IHM sont donc tout à fait utile.
Si l'IHM te dérange, tu diminues la fenêtre, et hop pour Muine par exemple, l'appli se met dans la zone de notification avec les boutons vitales play/pause/next.
Le serveur, c'est la fonctionnalité, c'est lui qui joue, et qui occupe si peu de ressources pour faire la zic, et il se pilote par moults interfaces, c'est tellement logique ...
C'est logique pour toi informaticien, mais pas pour l'utilisateur Lambda ! Tu prends une appli existante comme Rhythmbox, tu lui appliques ton modèle "client/serveur", ca changera rien au fait que ton client sera toujours lancé et bouffera toujours autant de mémoire ! L'utilisateur voudra en effet par moment aller consulter l'interface, pour changer de morceau, choisir un autre album, etc.
Quand à la liste de tes fonctionnalités, à part la diffusion à distance de flux (ce qui pour moi n'a pas beaucoup d'intérêt, je préfères lire directement ma zik sur mon ftp), je ne vois rien du tout qui ne soit pas possible avec une appli classique, le fait que ce soit client/serveur n'apportant strictement rien du tout.
et tout ça, que je sois sous X, en console, en ssh/http distants.
Vi c'est tellement user-friendly tout ca... Mais tant mieux, y'a des applis pour tous les goûts, pour tous les types d'utilisation ! Le fait est qu'il n'y a pas un modèle plus "logique" qu'un autre, j'estime ne pas être un utilisateur "lambda" et je peux utiliser mpd en ligne de commande, mais je préfère 1000 fois lancer Muine, et pouvoir accéder à tous moment à l'IHM. Et ma copine est bien contente que la musique se coupe quand elle ferme l'application.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
là, t'exageres ...
il y a au moins 30 guis différents pour piloter MPD ... dans tous les widgets existants, et même sous win ... (moi j'utilise glurp, avant pympc, et m'interesse à pygmy ... sous gtk).
Et ils font tout ce que tu dis ...
Si l'IHM te dérange, tu diminues la fenêtre, et hop pour Muine par exemple, l'appli se met dans la zone de notification avec les boutons vitales play/pause/next.
oui ;-), et bouffe 150mo, et du cpu, uniquement pour jouer du son, et proposer 3 pauvres boutons vitaux .... c'est démesuré
(n'as tu pas ces boutons sur ton clavier multimedia ?!)
L'utilisateur voudra en effet par moment aller consulter l'interface, pour changer de morceau, choisir un autre album, etc.
si t'écoutes des albums de suite, par exemple, toutes les heures tu devras aller dans l'interface pour changer d'album.... pendant 1h, l'appli qui tourne en arrière-plan, et bouffe 150mo, ne sert à RIEN !
- tu peux aussi mettre plusieurs albums de suite dans ta playlist, si t'en met 10, par exemple ... pendant 10 heures, t'auras une grosse appli qui tourne juste pour faire du son ?! et proposer 3 boutons ?!
Et ma copine est bien contente que la musique se coupe quand elle ferme l'application.
ne prefererait elle pas appuyer sur la touche STOP de ton clavier multimedia, pour arreter la musique ?!?
Je pinaille, mais tu pinailles aussi ;-)
on aime bien pinailler ...
Déjà sous win, j'étais un extremiste de l'audio, avec mon foobar ... Sous nux, je suis content d'avoir trouver un concept encore plus novateur, plus logique ... et je peux te dire, que de la zic, j'en écoute vraiment à outrance ... je ne pourrai pas me permettre d'avoir une grosse appli monopolisant mes pauvres ressources ;-)
Et je peux te dire aussi, que jamais au grand jamais, un mp3/audio n'a sauté !! même en rebootant X ;-)
Ce n'est que du bonheur, et comme je suis un passioné, j'ai envie de faire partager ça au plus grand nombre ...
Mais j'admet très bien qu'il existe des amaroks, muine, banshee, rhythmbox et autres grosses interfaces ... mais c'est démesuré, je trouve
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
il y a au moins 30 guis différents pour piloter MPD ...
Je dis pas que y'a pas de GUI pour MPD, je dis juste qu'à part utiliser la ligne de commande je ne vois aucun intérêt à MPD, puisque dans tous les cas tu as une GUI.
oui ;-), et bouffe 150mo, et du cpu, uniquement pour jouer du son, et proposer 3 pauvres boutons vitaux .... c'est démesuré
(n'as tu pas ces boutons sur ton clavier multimedia ?!)
Raaah mais tu comprends rien :) Même avec MPD il te faut une IHM et 150 Mo et gnagnagna. C'est exactement pareil ! Et toi tu me dis que c'est démesuré... Ben moi je te répond que c'est encore plus démesuré d'avoir un protocole client serveur en local EN PLUS de l'ihm.
n'as tu pas ces boutons sur ton clavier multimedia ?!
Gnome a des signaux multimédia par défaut, il est pas compliqué de configurer une appli pour les utiliser, comme le fait très bien Muine d'ailleur, je capte pas ta remarque.
si t'écoutes des albums de suite, par exemple, toutes les heures tu devras aller dans l'interface pour changer d'album.... pendant 1h, l'appli qui tourne en arrière-plan, et bouffe 150mo, ne sert à RIEN !
...
Déjà utiliser une appli qui bouffe 150 Mo de RAM pour lire du son, y'en a pas beaucoup.
Ensuite je vois pas le rapport avec client/serveur, rien n'empêche l'utilisateur lambda de laisser tourner le client IHM et d'avoir le même problème, comme rien n'empêche la version monolithique de désallouer les ressources utilisées pour l'IHM quand elle est minimisée et dans le systray. Ca n'a strictement rien à voir avec le modèle client/Serveur. Au contraire, avec ton modèle où je suppose tu t'amuses à relancer ton client graphique systématiquement, ca risque d'être plutôt "lourd" à charger systématiquement. Ou alors c'est que l'appli était resté en mémoire, auquel tu bouffes toujorus autant de mémoire.
t'auras une grosse appli qui tourne juste pour faire du son ?! et proposer 3 boutons ?!
Mais qui te parle d'une grosse appli ? Muine c'est petit, c'est simple :)
ne prefererait elle pas appuyer sur la touche STOP de ton clavier multimedia, pour arreter la musique ?!?
Elle pourrait si mon clavier avait un bouton stop. Ma télécommande a un bouton stop, elle peut l'utiliser si ca l'amuse, mais le fait est qu'en règle générale elle préfère fermer la fenêtre (peut être parcque al télécommande est jamais là où t'es :) )
Je pinaille, mais tu pinailles aussi ;-)
on aime bien pinailler ...
Je pinaille pas, tu passes ton temps à me dire que seul le modèle client/Serveur est intelligent, et tu ne me montres strictement rien qui a un rapport avec le modèle client/serveur, toutes les critiques que tu fais peuvent être faites à ton modèle, et inversement.
Sous nux, je suis content d'avoir trouver un concept encore plus novateur, plus logique ...
Je le répète : ca n'a strictement rien de novateur, et si aucun autre lecteur ne propose cela c'est bien que c'est loin d'être révolutionnaire et d'apporter des avantages.
Je le répète : pour l'utilisateur lambda, c'est pas du tout logique. Sa musique va continuer à tourner alors que l'utilisateur ne verra plus d'ihm !!
je ne pourrai pas me permettre d'avoir une grosse appli monopolisant mes pauvres ressources ;-)
Ca n'a rien à voir avec ton trip client serveur. T'utilises pas de gui dans ce cas, mais c'est un autre problème.
Mais j'admet très bien qu'il existe des amaroks, muine, banshee, rhythmbox et autres grosses interfaces ... mais c'est démesuré, je trouve
T'as déjà essayé Muine ? Nan parcque t'arrête pas de parler de "grosses interfaces" et de "150 Mo de mémoire"...
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
- muine/rhythmbox = 80mo (moitié moins que ce que j'avançais, désolé)
- mpd = 13mo *3 + gui 13mo (quand lancé)
sinon cf plus bas pour plus de détails
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
- mpd = 13mo *3 + gui 13mo (quand lancé)
Il est bizzare ton muine :) Pour rhythmbox je sais pas.
Enfin si la GUI de mpd prend que 13 Mo, ca n'a strictement rien à voir avec le modèle client/serveur. C'est une question de codage. Maintenant tes ihm ne doivent sûrement pas faire la même chose. Faut bien voir que Muine par exemple scan ton disque dur à la recherche de nouveaux morceaux de musique, va cherché sur internet la liste des pochettes, etc. Bref ils bossent.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
http://manatlan.free.fr/muine.png
et en plus, j'ai mis qu'une infime partie de ma collection (je suis maintenant persuadé que j'arriverai à le monter à 150mo sans prob)
et c'est plus proche de 90mo que de 80mo d'ailleurs
sinon, pour l'anecdote, j'ai bien aimé l'orientation "album" de muine ;-), pas mal !!! je le note
mais 90mo pour écouter un mp3, c trop pour moi ...
car si je coupe l'interface, ça coupe la musique ?! c'est étrange ?! pourtant j'ai pas besoin de l'interface quand j'écoute ?!?
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
non, elle en font bien plus que muine, pour 10x moins d'espace memoire !!
Muine, dans la tendance gnome, a une interface minimaliste (et ce n'est pas pour me déplaire, au contraire !) ... mais je peux te garantir que ça fait moins que glurp (seek dans le morceau, conception de playlists, gestion de streams, recherche spécifique (suivant un tag précis) ...)
d'ailleurs, muine bien chargé met pas mal de temps à se lancer en plus !
> va cherché sur internet la liste des pochettes
oui j'ai vu, mais je les ai toutes en local, dans le repertoire de l'album
> Faut bien voir que Muine par exemple scan ton disque dur
> à la recherche de nouveaux morceaux
dans les interfaces gui de mpd, il y a toujours un bouton pour demander à mpd de raffraîchir la base
sinon, tant mieux que ça te plaise, et qu'il y en ai pour tout le monde! mais je n'échangerai pas mon baril mpd contre 10 barils de muine ou autres amarok ...
Mon ordi a pas mal de ressources, mais pour lire des mp3, je ne supporterai pas que ça monopolise plus de 3% de celles-ci ... j'en ai besoin pour plein d'autres choses ...
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Muine chez moi c'est 51 Mo en mémoire avec 3000 chansons et affichage instantané des albums :
http://pascalfresnay.free.fr/divers/muine2.png
Ah oui : dont 15 Mo partagés, donc tu peux ne pas en tenir compte. Soit au final 35 Mo ouaouh.
Quand à mon expérience de mpd+glurp :
étape 1 :
f***ng .conf de merde !
étape 2 :
glurp : impossible de se connecter au serveur
...
étape 3 :
gmpc :
Raaaah faut aller dans config et cliquer sur connecter au serveur !
Oups j'ai fermé l'appli et toujours la zik (réflexe désolé)
killall mpd.
Conclusion : l'utilisateur lambda n'arrivera de toute façon jamais à ce servir de mpd.
Ensuite mpd ne gère pas braiment de base de donnée de mp3, il se contente d'indexer une arborescence.
Muine il scanne les tags, il organise par album, par auteur, etc. Ca prend nettement plus de ressources. Et tout est instantané : un click dans la barre de notif et hop j'ai l'interface pour sélectionner un album.
Enfin bon voilà, tout ca pour le fun, mais ca n'a toujours rien à voir avec ton trip client/Serveur, rien n'empêche de faire en sorte que Muine décharge l'ihm quand il est dans la zone de notification. Ca c'est plutôt des problèmes de gestion de ressources par les programmeurs. Chez Muine ils ont préféré la réactivité et la simplicité. CHez MPD : je sais pas ca marche pas. Ca doit être le côté révolutionnaire.
[^] # Re: ...
Posté par lezardbreton . Évalué à 2.
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
car apparemment tu ne connaissais pas ...
SI SI SI, mpd gère une libraire, avec les tags mp3 et tout le tintouin !
et tu peux le questionner sur des tags précis (test avec mpc, glurp aussi !)
> Et tout est instantané : un click dans la barre de notif et
> hop j'ai l'interface pour sélectionner un album.
tout pareil ! instantanné !
> CHez MPD : je sais pas ca marche pas. Ca doit être le
> côté révolutionnaire.
ça, c un autre problème ! et il doit être situé entre la chaise et le clavier ;-)
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
En fait j'avais déjà utilisé dans un passé lointain parcque justement j'aimais bien l'idée, mais depuis j'en suis revenu :)
SI SI SI, mpd gère une libraire, avec les tags mp3 et tout le tintouin !
Où ca où ca ? Nan parcque je l'ai vu scanner mes mp3, il me propose d'effectuer des recherches, mais je ne l'ai pas vu me proposer ma liste d'albums. Où alors je suis aveugle. Si je veux tous les albums de BRMC je fais quoi ?
tout pareil ! instantanné !
Bon ben alors tu vois bien que c'est pareil :)
TIens si ca t'amuses, Muine fait aussi serveur en quelque sorte puisqu'il écoute D-Bus.
ça, c un autre problème ! et il doit être situé entre la chaise et le clavier ;-)
Oué entre le clavier et la chaise du développeur. Nan parcque bon mpd ne pas proposer de config par défaut, glurp qui arrive pas à se connecter au serveur et qui a un bouton config qui fait rien et gmpc qui n'est pas configuré par défaut pour aller chercher le fichier de conf de mpd et qui n'est pas configuré par défaut pour se connecter... Franchement ils ont tout fait pour que par défaut ca marche pas.
Et pourtant je suis pas un newbie, je savais qu'il fallait télécharger un serveur, un client, lancer le serveur en ligne de commande, ajouter un fichier de conf dans ~/.mpd, modifier ce fichier pour qu'il trouve mes mp3, qu'il fallait que j'ajoutes un dossier playlists pour qu'il râle pas, un dossier jesaisplusquoi pour la même raison, puis lancer le client, configurer le foutu client qui n'était pas foutu de se configurer tout seul, bref... Désolé mais je comprends pourquoi mpd n'a aucun succès et que son modèle client/Serveur n'a aucun succès, c'est un truc de geek, fait par des geeks pour des geeks.
Muine, tu lances, tu glisses le dossier de ton album sur l'ihm, et ca marche. Je bouffe peut être 35-15 = 20 Mo de ram en plus, mais je trouves que ca vaut le coup :)
Et puis je penses qu'il sera assez facile de démontrer que ce "surpoid" vient en grande partie du runtime Mono ;)
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
Où ca où ca ? Nan parcque je l'ai vu scanner mes mp3, il me propose d'effectuer des recherches, mais je ne l'ai pas vu me proposer ma liste d'albums. Où alors je suis aveugle. Si je veux tous les albums de BRMC je fais quoi ?
bah justement ... mpd contient toute la librairie et propose des api pour y accéder ... après ça dépends des interfaces/gui ... il y en a qui sont tout simple, et d'autres plus complexe ...
dans glurp, tu peux faire une recherche, sur le tag "artist" par exemple, pour rechercher "black rebel motorcycle club"
sinon y a des clients qui classent, regarde celui là sous mac :
http://www.musicpd.org/uploads/images/screenshots/MpcOSX/scr(...)
ça dépends des interfaces, et là je rejoins ton premier post sur le sujet !
c'est très vite fait de refaire un player (y a des bindings pour tous les languages) ... y a juste besoin de développer l'interface, tout le moteur est dans mpd ... pas besoin de réinventer la roue à chaque fois
toi qui est plutot mono, mpcsharp (sorte de clone de pympc) est excellent :
http://pympc.sourceforge.net/mpcsharp/
et se rapproche beaucoup de muine, avec pochette et tout et tout ...
glurp n'est qu'un clone de gmpc plus fini ...
phpmp2 est l'interface qui utilise le plus de features de mpd, avec mpc bien evidemment ....
et pour tout dire, je n'ai pas encore trouvé l'interface qui me sied à ravir ... (je cherche une interface à la foobar (onglet=playlist)) mais je compte peut être la faire un jour, si ça tarde encore ...
laisse encore un peu de temps à mpd et ses interfaces ... et tu verras
c'est vraiment le concept excellent ....
et tu pourrai même trouver une interface pour ta copine, une spécifique ... une pour toi .... une pour ton clavier/telecommande .... une pour ta ligne de commande .... etc ...
parcque bon mpd ne pas proposer de config par défaut [...]
je suis d'accord, j'ai un peu galéré jadis pour configurer/comprendre sous mdk, mais depuis je trimballe ma config d'os en os, et ça continue de marcher.
ok, c pour les geeks, mais il suffirait de simplifier un peu le process d'install d'un mpd+gmpc pour le commun des mortels, et ça serait bon de suite, sans entrer dans des configs complexes ... (mais c'est quand même pas aussi complexe que ça)
Je bouffe peut être 35-15 = 20 Mo de ram en plus
C'est relatif à ta collection, si t'as une "petite collection", ça tient la route ... Mais apparemment c relativement proportionnel par rapport au nombre d'items .... donc ça peut croitre très vite
sinon, je lis dans tes posts que tu serai tenté par l'experience
vas-y, tente un coup ! tu y trouveras forcément ton bonheur ...
ET dis toi bien que l'interface de muine greffé sur mpd, c tout à fait possible ! et ça prendrai pas trop de temps à faire ...
c'est vraiment un PLUS par rapport à l'autre os, pour moi ...
sur ce, je vais tester mpcsharp, car ça fait un bail, et j'ai vu qu'il a beaucoup évolué ... même s'il est en mono, et prendra 15mo de plus ;-) ... mais je m'en tape, car je le coupe quand ma selection est lancé, et je pilote la suite avec les touches multimedia du clavier branchés sur mpc
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 1.
http://sharpmusic.sourceforge.net/
c'est fou, j'en parlais dans mon précédent post ...
l'interface de rhythmbox pour mpd :
http://pympd.sourceforge.net/
et si tu veux des petits bouton dans ta systray :
http://mgc.berlios.de/
décidément j'avais pas encore vu toutes ces nouveautés ...
on a maintenant les interfaces des clients lourds célèbres
trop fort
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 1.
c'est vraiment le concept excellent ....
Bof, je te l'ai dis, au final Muine me convient très bien, j'ai besoin de rien en plus !
Et puis tu oublies un détails, tu dis que mpd c bien tu peux fermer le client et bouffer moins de ram, ben moi je te répond, quand tu fermes muine, y'a plus de ram du tout de bouffée contrairement à mpd ;)
C'est relatif à ta collection, si t'as une "petite collection"
BOf je suis pas sûr du tout. Il m'a pas bouffé plus avant et après que j'ai mis 3000 chansons. Et puis t'auras exactement le même problème avec MPD, sauf que MPD il te les bouffera en permanence puisqu'il tourne tout le temps ;)
vas-y, tente un coup ! tu y trouveras forcément ton bonheur ...
ET dis toi bien que l'interface de muine greffé sur mpd, c tout à fait possible !
Pour moi ca n'a aucun intérêt, Muine c'est simple, ca marche, ma télécommande marche, ma copine aussi. Je demandes rien d'autre moi :) Et puis quand je coupes la musique je veux pas d'un daemon qui tourne pour rien :-D
[^] # Re: ...
Posté par lezardbreton . Évalué à 2.
Arrètes de dire ça, ça décrédibilise tout le reste.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
Je me suis connecté chez moi, via freenx ...
Je n'ai que rhythmbox actuellement d'installé sur mon ordi, (mais je l'utilise pas).
et il ne prends que 80mo en memoire en lecture (avec seulement 1/10 de mes fichiers ...)
(j'avais pas envi d'installer amarok, car j'ai pas les libs kde)
j'ai aussi vite fait, un apt-get install muine ....
un peu plus de 75 mo, en lecture, (avec seulement 1/10 de mes fichiers ...)
mpd, (avec tous mes fichiers) : 3 process de 13mo (et encore, je pourrai baisse le nb de process)
les gui glurp ou gmpc : environ 13mo quand il sont lancés ;-)
j'ai un peu exagéré en disant 150, fallait lire moitié moins, mais ça reste énorme (et encore tous mes fichiers sont pas dedans)
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
http://manatlan.free.fr/muine.png
mais je suis maintenant quasi persuadé que je peux le faire monter à 150mo si je met toute ma zic dedans ...
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
pour lire un mp3 de 3min, c'est 110mo pendant 3min .... c'est démesuré ....
sinon, par rapport à ce que disait timaniac dans un post précédent ... c'est d'autant plus démesuré que l'interface de muine n'a vraiment pas beaucoup d'objets/feature ... (même, glurp, gmpc, pygmy ou pympc en possède bien plus (c des clients de mpd, (à 15mo max) )
[^] # Re: ...
Posté par lezardbreton . Évalué à 2.
Sinon, tu pourrais comparer avec xmms, ou xfmedia, autrement appelé xfce-media par certaines distribution, ou quod libet. Ne prends pas comme référence des applications connues pour avoir des problèmes (rhythmbox) ou des technologies pas encore matures (muine). Je ne pense pas que xmms dépasse les 15 Mo, non ?
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
bin essaie le, et regarde par toi même ...
"sudo apt-get install muine", c'est pas bien compliqué ;-)
et on n'est jamais mieux servi que par soi même !
> Sinon, tu pourrais comparer avec xmms, ou xfmedia
voilà un screenshot de xmms et xfmedia
http://manatlan.free.fr/xmedia.png
xmms : 30mo et xfmedia 150mo, tous les 2 à vide
mais bon, ils ne jouent pas dans la même catégorie, il ne gère pas de bibliothèques ... (cependant xfmedia s'alloue beaucoup de ram dès le début ;-) ?!?)
quodlibet je ne connaissais pas (il a qques fonctionnalités sympa)!, j'ai vite mis qques mp3 dedans , 130mo sans prob, et l'interface a du mal à suivre ... (mais c de l'interprété, et c'est le sujet du post !!! on y reviens) ....
au fait, j'ai un p4 2.6ghz et 1go de ram ...
mais j'échangerai vraiment pas mon mpd/glurp contre ces "vieux players" ;-) ...
de plus je viens de tester l'occupation cpu sur ces lecteurs ... non vraiment, le player qui remplacera mon mpd n'est pas encoré né ...
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 3.
BRef, ec qui est inquiétant c'est une appli qui bouffe 100 Mo de RAM alors que y'en a que 128 au total et qui fait swapper le disque comme un porc.
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
http://manatlan.free.fr/banshee.png
140mo, et encore il avait même pas fini d'importer qu'1/3 de ma collection .... (il s'est arreté tout seul ?!)
sinon, là, on explosait clairement les 150mo, sans prob
bon je vais arreter de tester ces players ... car maintenant, je suis persuadé que amarok ou rhythmbox monterait egalement autour des 150mo sans problème ...
(néanmoins, ces players sont bien pour les petites collections de 1000 à 3000 morceaux, et quand on a des ressources à allouer pour jouer un mp3)
donc, je n'ai pas dit de conneries ! ni exagéré !
bon point pour muine qui plafonne à 110mo (mais pareil, j'ai pas l'impression qu'il a tout importé, car c t très rapide)
[^] # Re: ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> de flux (ce qui pour moi n'a pas beaucoup d'intérêt, je préfères lire
> directement ma zik sur mon ftp), je ne vois rien du tout qui ne soit
> pas
J'ai l'impression que ton problème à la lecture de tes posts précédents, c'est que tu travailles toujours en local sur ta machine. C'est d'aileurs un problème actuel avec pas mal de nouveau ou d'utilisateur de portable pour qui une machine égal une personne.
Il arrive toujours un jour où la machine montre ses limites et ou heureusement, ssh est là pour nous sauver la mise (ou freenx mais c'est kif kif). Que le client soit gros ou que le client soit plus petit et qu'un serveur prenne en charge une partie du boulot, ca change quoi ? Ca change que ca marche à distance !
Un des principaux problème d'XWindows en ce moment, ce n'est pas tellement la gestion de la transparence à mon avis mais la redirection automatique d'autre flux que X, comme le son. Je sais, il y a des serveurs de son mais tout cela n'est pas intégré ni standard. Pourquoi pas MPD ou un autre... Ce qu'il faut pour que cela devienne vraiment intéressant, c'est que lorsque je fais un ssh, le son soit automatiquement redirigé et suive X.
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben oui comme 90% des utilisateurs lambda de Gnome. Et pour eux Muine ou autre Rhythmbox est largement suffisant et visiblement beaucoup plus fonctionnel que MPD. VOilà, comme je l'ai déjà dis, MPD peut être utile dans certaines situation (à distance, et encore je l'ai dis je boufferai sans doute moins de ressources avec un pauvre serveur ftp), mais MPD n'est pas du tout plus "révolutionnaire" que Muine & Co. TOut ça pour rappeler qu'à la base je critiquais les propos indiquant que le modèle monolithique était "dépassé" et que MPD c'est LA solution.
Et les quelques tests que j'ai effectéavec MPD m'ont largement conforté dans mon idée :)
Pour moi la solution idéale c'est pas MPD, c'est plutôt un système de fichier qui soit une base de donnée multimédia, un peu comme ce que compte faire MS avec son WinFS ou ce que fond chaque application de musique dans leur coin (bibliothèque de musique à la winamp, à la iTunes, etc.)
Avec bien sûr partage sur réseau le tout sur un MediaCenter :)
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
Muine joue de la musique ...Rhythmbox joue de la musique ... Banshee joue de la musique ... Xmms joue de la musique ... amarok joue de la musique ...
Quel est le point commun entre ces applications ? (réponse : "elles jouent de la musique") ...(certaines gèrent une librairie ...)
Jusque là, on est ok ? c'est bon ?
Comme toutes ces applications font qqchose en commun ... n'y aurait il pas moyen de capitaliser ?! D'avoir une base commune ? Plutôt que de réinventer pour chaque player, la gestion d'une librairie, la production du son etc ...
Et c'est là qu'intervient "mpd" ... Toi tu focus, à fond, sur l' utilisation forcément distante ... oui, c possible ... mais c'est pas tout !
Je pensais que t'avais compris l'intérêt de séparer l'interface du moteur ....
> Muine ou autre Rhythmbox est largement suffisant
> et visiblement beaucoup plus fonctionnel que MPD
?!? ... je t'ai montré une interface mpd qui imitait l'interface de muine, à s'y méprendre, et une autre qui reprennait celle de rhythmbox ..
tu n'es pas crédible ...
ton seul problème "fonctionnel", à mon avis, c'est toi ....
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Tout à fait d'accord avec cette idée.
Plutôt que de réinventer pour chaque player, la gestion d'une librairie, la production du son etc ...
Euh, y'a une autre manière de créer une base commune que le serveur (qui par son principe n'apporte que le côté multi-client) : la bibliothèque.
GStreamer résoud une bonne partie du problème, en 3 lignes tu joues un mp3.
Pour la gestion d'une base de données virtuelle de mp3, c'est un autre problème : il y a déjà des bases existantes, le véritable problème c'est que chacun y va de ses propres idées, ses propres variantes qui réponde exactement à ses besoins. Sous Windows la bibliothèque de WindowsMediaPlayer est accessible à tous les programmes, sans qu'il y est pour autant de protocole client/serveur.
En tout cas une chose est sûr : ce n'est absoluement pas à la même appli qui fourni les capacité multimédias de s'en occuper, bref, c'est pas à GStreamer, mais à une autre bibliothèque dédiée, voir au système de fichier (comme je l'ai expliqué avec les futurs systèmes de fichier ala WinFS). Communiquer avec la couche multimédia de l'OS et gérer une base de fichiers avec métadatas sont 2 boulots totalement différents.
Je pensais que t'avais compris l'intérêt de séparer l'interface du moteur ....
Tout à fait, mais ajouter le protocole client/serveur entre les 2 n'a pas que trop peu d'intérêt, et après tests, surtout des inconvénients.
?!? ... je t'ai montré une interface mpd qui imitait l'interface de muine, à s'y méprendre, et une autre qui reprennait celle de rhythmbox ..
tu n'es pas crédible ...
Je parlais de suffisant dans le sens où j'en ai rien à cirer de l'apport du protocole client/serveur. Moi ce que je veux d'abord, c'est que ca marche.
Visiblement tu sembles entêté avec le protocole client/serveur, pourtant je n'arrête pas de te montrer qu'on peut avoir exactement le même principe avec la séparation programme/bibliothèque, le même niveau de réutilisation, sans la lourdeur du protocole client/serveur.
Client/serveur, s'il n'y a pas plusieurs clients ou aucune utilisation à distance n'a aucun intérêt, c'est le principe même de tous protocoles clients/serveur. Pour le reste y'a les bibliothèques.
Mais bon la plupart des programmes me donne raison, les serveurs multimédias ne sont jamais utilisé en local mais pour diffuser sur un réseau où il y a plusieurs clients (bref là où le protocole client/serveur est utile).
[^] # Re: ...
Posté par manatlan (site web personnel) . Évalué à 2.
> à distance n'a aucun intérêt, c'est le principe même de tous
> protocoles clients/serveur. Pour le reste y'a les bibliothèques.
je suppute alors aussi, que tu dois être très fortement contre le principe du serveur X11 ... utilisé à 95% en local ...(je dis un chiffre au hasard) ...
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Je comprends son architecture initiale, où il y avait une forte proportion d'utilisateurs de terminaux X. Mais tout le monde s'accorde à dire que le serveur X11, innovant à son époque, a une architecture aujourd'hui totalement dépassé dans un contexte d'utilisation local.
On en arrive à des lourdeurs comme lancer plusieurs serveurs X pour avoir plusieurs sessions graphiques sur la même machine.
De plus le modèle ala Windows (moteur graphique intégré) montre clairement que l'absence de protocole client/Serveur n'est pas un obstacle, rien n'empêche d'avoir une application serveur tierce qui soit capable de rediriger une session sans avoir la lourdeur du protocole client/serveur en local : vnc, bureau à distance, etc.
C'est un peu la même vision que j'ai pour la musique :
une application tierce faisant serveur, mais dédiée au streaming. En local pas de client/serveur.
Bref : utiliser client/serveur que quand c'est justifié.
[^] # Re: ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> clairement que l'absence de protocole client/Serveur n'est pas un
> obstacle, rien n'empêche d'avoir une application serveur tierce qui
Dis donc, le truc de Windows ne va pas du tout. Moteur graphique obligatoire. On se tappe du direct9c plein de bogue sur des serveurs web... Quand ca plante, t'es marron ;-(
Non, ca ne vas pas du tout. Avoir une couche graphique intépendante du noyau est une très bonne chose.
Ensuite, tu peux très bien mettre en place des tunnels qui font qu'en local, ca pulse. Il y a les sockets UNIX et on pourrait peut être faire mieux aussi pour la couche graphique.
Dans le dernier noyau, il y a bien un nouveau système de fichier pour améliorer le taux de transfert entre le mode noyau et le mode utilisateur. Il me semble que l'objectif est d'aider FUSE a aller plus vite à terme.
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Rien à voir. Le prochain Windows, Vista, tu ne seras pas obligé d'installer le moteur graphique. C'est pas pour autant que c'est un serveur comme X11.
Avoir une couche graphique intépendante du noyau est une très bonne chose.
Tout à fait. D'où les modifs dans le prochain Windows. Mais c'est pas pour autant qu'il faut en faire un serveur comme X11.
Bref, ne nous écartons pas du débat initiale :)
[^] # Re: ...
Posté par golum . Évalué à 5.
toujours ambigu, sujet à des modifications de formatage dans la sortie sans préavis entre 2 versions du même prog.
Bref on est loin de pouvoir assurer des developements de qualité
Avec des objets, on dispose d'un contrat clairement défini, de la possibilité de traiter des exceptions, du contrêle de type .... .
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Avec son shell Monad, Microsoft a en partie mariée les 2 mondes : les outils en ligne de commande lisent et pondent des objets typés.
[^] # Re: ...
Posté par golum . Évalué à 2.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans le cas du truc MS, au contraire du pipe, cela ne peut marcher si l'objet qui reçoit est prévus pour. Donc en gros, tu perds l'interet de connecté de faire des petits bouts qui cause le même langage (l'ASCII). Le xml permet de mieux structurer.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 4.
N'importe quoi... dans les deux cas, si tu ne sais pas ce que tu reçois, tu ne peux pas le traiter, et le XML n'est pas une solution magique. Il s'agit d'un format standardisé, mais tu as toujours besoin de savoir comment manipuler ce qui est contenu dedans.
Opposer les échanges d'objets et les échanges de XML, c'est très étrange. On peut très bien échanger des objets en utilisant le format XML, par exemple. Bref, choisir le format (XML) c'est bien, mais il faut encore choisir le protocole (objets sérialisés, données brutes, ...)
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu as du xml, au lieu d'avoir un programme pour choper chaque champs, tu peux en avoir un genre find _lenom_du_champ et cela marche partout.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 5.
f = Fonction.parse("3x²+4x+6")
f'' = Fonction.parse( (Fonction.parse(f.dérivée).dérivée )
Tout le monde sera d'accord pour dire que ce n'est pas très efficace: la méthode dérivée est obligée de convertir sa valeur de retour en chaîne de caractères, et après on est obligé de parser à nouveau pour avoir une fonction. Il serait bien plus simple de manipuler les objets sans passer par des chaines:
f = Fonction.parse("3x²+4x+6")
f'' = f.dérivée.dérivée
Dans cette analogie, le premier langage c'est les commandes Unix et la communication par flux. Comme tu ne peux pas échanger des objets, tu dois te taper les conversions de données à chaque fois.
Maintenant, pour en venir à ton objection:
Je te répondrais que ce n'est pas vrai dans l'analogie des langages de programmation, et que ce n'est pas vrai non plus dans le cas de programmes qui communiquent avec des objets. Pourquoi ? Parce que si on peut emboîter des objets dans un langage objet, on peut aussi emboiter des programmes qui manipulent des objets.
Typiquement, un programme Grep n'est applicable qu'à des objets contenant des chaînes de texte. Donc, le programme Grep serait défini comme recevant en entrée des objets implémentant la méthode read_char, et c'est tout ce qui est nécessaire, pas besoin de coder un grep dans l'objet lui même. Dans ce cas, l'objet reçu en entrée est en pratique un flux, comme dans le bon vieux Unix, parce que par définition Grep fonctionne sur des flux.
Maintenant si on prend un programme qui manipule autre chose que des flux, par exemple des dates, on a intéret à pouvoir lire en entrée directement un objet Date avec ses méthodes day, week, year, etc.
Pour prendre un exemple idiot, qui ne s'est jamais énervé sur son script shell qui ne donnait pas de bons résultats, simplement parce qu'on a donné en entrée un nombre décimal comme "3.14", alors que dans la locale fr, awk considère que le séparateur est une virgule, et qu'il fallait entrer "3,14" ?
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Donc, avec ton exemple, pour que grep marche il faut une méthode read_char. Si tu veux un cut ? il faut un select_fields(), etc ... en gros une méthode par programme à piper ?
Certe, c'est "plus puissant" mais pas assez générique, sauf si les interfaces sont standardisé mais cela risque de beaucoup ressemblé à un passage de xml (avec la pénalité de parse en moins).
"La première sécurité est la liberté"
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 4.
Tu confonds un peu tout et n'importe quoi là :)
Ce qui a été vendu comme réutilisable, c'est toute l'informatique depuis les débuts, les pipes Unix étaient censé être la solution miracle pour connecter des briques, maintenant c'est plutôt les composants, ce à quoi tu devais sans doute vouloir faire allusion.
Quand tu parles d'un objet, je suppose que tu veux parler d'une classe. Ben dans les faits les classes sont très souvent réutilisées, ne serait-ce qu'au sein d'un même programme.
Maintenant je n'ai qu'un conseil à te donner : essai Monad si t'as la possibilité (je sais WIndows gnagnagna), et tu verras comment il ont fait le grep.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Et j'ai vu leur demo à Solution linux, et cela m'avait l'air pas très "générique".
"La première sécurité est la liberté"
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Yusei (Mastodon) . Évalué à 2.
Donc en fait, tu penses que le premier langage de programmation, celui dans lequel toutes les méthodes renvoient des chaînes, est plus générique que le deuxième ?
C'est un argument circulaire: tu pars tu principe que pour faire quelque chose avec l'objet, il faut que tout le traitement soit contenu dans l'objet, et tu conclus qu'il faut une méthode par programme à piper.
Si tu veux faire un cut, tu n'as pas besoin d'une méthode qui te renvoie des champs. Tu as juste besoin d'une méthode read_char, comme pour grep. Par contre si tu as à ta disposition une méthode qui te donne une liste de champs, c'est encore mieux.
D'un autre côté, si tu prends toujours comme exemple des commandes qui manipulent du texte, tu n'auras jamais intéret à obtenir en entrée autre chose que du texte. Ça ne devient intéressant que dans le cas de données structurées associées à leur comportement.
Ce n'est pas vrai, tout dépend de la hiérarchie de classes utilisées. Si tu dis "je reçois en entrée n'importe quel objet qui implémente les méthodes ajouter et multiplier", tu peux faire un programme qui fait des opérations sur plein de types d'objets. Mais là on n'est pas dans une discution sur l'intéret de pouvoir piper des objets, on est dans une discution sur les mérites de la programmation objet en général.
Et même si chaque objet était spécifique, admettons que dans un script shell j'aie besoin de prendre une date et d'ajouter trois jours à cette date. Dans le bon vieux modèle Unix, je pourrais piper le résultat de "date" dans mon script, le parser, et ensuite écrire un algo qui ajoute trois jours, et qui change de mois/année quand c'est nécessaire. Dans un modèle objet, ça donnerait ça:
d = lire_une_date_en_entrée();
d2 = d+3;
À condition que la méthode Date::+ soit fournie par l'objet. C'est du code spécifique à l'objet Date, mais ça va tout à fait dans l'esprit de réutilisation de code, puisque c'est disponible pour tous les programmes qui veulent manipuler des dates.
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 4.
D'où l'intérêt : tu sais ce que tu attends, et tu peux le traiter beaucoup plus facilement.
Avec XML, il y a juste à connaitre le xml.
Et tu te retrouves avec le même problème qu'avant : tu ne sais pas ce que tu vas trouver entre les balises. XML tout seul ca sert à rien, un document XML sans schéma ou DTD associé est pas plus exploitable qu'un fichier texte. Et la DTD/Schéma correspond en gros à l'interface d'un objet, bref sa définition.
Bref l'XML n'apportera strictement rien, à part peut-être une lourdeur dans les flux, sans parler du fait que le XML est très mal approprié à un contexte de flux, le programme traitant la sortie d'un tel flux devant attendre une éventuelle balise fermante avant de traiter le contenu.
De plus la solution de MS se base sur .NET, bref tu peux très bien récupérer un "object" et faire de l'introspection dessus si t'as envie de découvrir ce qu'il y a dedans sans connaître au préalable l'interface.
[^] # Re: ...
Posté par golum . Évalué à 3.
Et tu dois connaitre le fonctionnement du prog pareil et en plus la DTD ou le schéma, en lieu et place du contrat.
Evidemment pour être utilsable il faut que les programmes jouent le jeu, mais rien n'empêche de reconstruire les sevices de base sur ce modèle.Tu sais les modèle à base de composants ca commence à prendre (XPCOM, DCOP, .....) . Là on rajoute juste un interface en ligne de commande
Evidemment ca ne serait plus tellement GNU ni même POSIX.
# L'engouement pour les languages interprétés
Posté par niol (site web personnel) . Évalué à 8.
Les langages interprétés sont aussi plus accessibles (pas besoin de savoir ce qu'est un librairie statique et la différence avec une librairie dynamique). Y'a qu'à voir la popularité de PHP qui attire tous les gens qui veulent faire un peu plus avec leur ordinateur que de le subir, y compris les windowsiens.
Attention, je ne dis pas que les langages compilés sont inutiles, d'ailleurs c'est fort heureux que par exemple KDE et Gnome soient compilés. Mais un lecteur de musique ou un client mail en Python/GTK ou en Python/QT, pourquoi pas. Il faut juste savoir écrire du C quand cà vaut le coup (décompression ogg/FLAC pour suivre mon exemple du lecteur de musique).
[^] # Re: L'engouement pour les languages interprétés
Posté par fredix . Évalué à 2.
Et encore c'est rarement nécessaire car bien souvent il existe déjà des modules python/ruby/perl la plupart en C pour ce genre de choses standards (pyogg, libvorbisfile-ruby, ...).
# Ne pas oublier ...
Posté par Louis Nyffenegger . Évalué à 5.
En effet, normalement le code d'un bon langage interprété est quand même optimisé et sera plus rapide qu'un code compilé faisant la même chose développé par quelqu'un n'étant pas forcément à l'aise en programmation.
# Performance de dev
Posté par Stibb . Évalué à 6.
Mais est ce une raison? Non.
Mais je suis désolé, ca me désole de voir de plus en plus d'application graphique utilisant python ou perl et c'est "lennnnnnnnnnnnnt".
gdesklet fonctionne très bien meme il bouffe trop en ram.
Meme en java, je suis désolé, tant qu'il n'y aura pas de coprocesseur matériel supportant le java, un code java/.NET sera toujours plus lent qu'un code C bien développé (je parle pas du java natif)
J'ai peut etre une position d'arriéré, mais une application python est réservé pour ma par à des scripts (sans interface) ou des interfaces simples "que j'ai pas à me faire ch... à faire une jolie interface". Mais pour un "vrai" projet (que je n'aurais pas de honte à distribuer et supporter), je ne choisirais pas python, en tout cas pas un langage interprété.
Java à la limite.
Bref il faudrait un langage aussi puissant que le C (ou C++) mais avec une bonne gestion de la mémoire : garbage collector pour ne jamais de delete,...
Est ce que ça existe déjà ?
L'idéale : une biblothèque en C qui abstrait le développeur de toutes ses considérations bassement matérielle.
J'ai déjà essayé de compiler un code java en natif j'ai toujours été tres décu du résultat. Mono C# semble un bon compromis, mais il faut tout un runtime derrière.
Pour les librairies graphiques, les EFL sont extremement puissant et je pense que je vais m'y plonger plus sérieusement pour étudier leur capacité.
G.
[^] # Re: Performance de dev
Posté par Sylvain (site web personnel) . Évalué à 3.
http://www.xharbour.org/
Tu utilise des commandes RAD pour le developpement, tu ne gere pas la mémoire. Mais tu compile et tu link comme en C.
[^] # Re: Performance de dev
Posté par Sylvain (site web personnel) . Évalué à 3.
La gestion du GUI ce fait par bibliotheque tierce (NTK, FiveWin) mais pour l'instant aucune lib de GUI est libre seul le langage l'est.
Sinon on peut travailler en mode API pour gerer un GUI sans lib tierce.
Le projet xHarbour est en train d'implementer une gestion de GUI RAD. Mais je pense que celle de sis-log(Boite francaise travaillant avec xHarbour) (NTK) qui a beau ne pas etre libre presente un avantage d'etre dans un avenir proche multiplateforme (Win32SDK & GTK).
Bientot le grand retour de la programmation "a la" Clipper.
[^] # Re: Performance de dev
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
> graphique utilisant python ou perl et c'est "lennnnnnnnnnnnnt".
Combien de serveur web tourne avec mod_perl ? Désolé mais correctement codé, ca tourne vite. Franchement, pour une application avec trois boites de dialogue, on ne voit pas la différence. Prenons un code de calcul par élément finis pour exemple. L'IHM pourrait être en langage de script, de toute manière, tout le temps est passé dans la résolution du problème, c'est à dire en général deux routines.
Par ailleurs, Perl avec son CPAN est génial. Il suffit de voir quelques modules de base pour voir que la personne qui l'a fait connait son sujet bien mieux que soit. Globalement, les modules sont bien optimisés.
Moi, j'aime bien ce développement cathédrale qui a produit des milliers de modules utiles à tout le monde. Désolé pour le monde Java, mais je le trouve bien moins intéressant.
[^] # Re: Performance de dev
Posté par Stibb . Évalué à 1.
Pour du calcul scientifique, script d'administration, bref, dans les cas d'utilisation que tu décris, perl est parfaitement adapté.
[^] # Re: Performance de dev
Posté par golum . Évalué à 5.
post plus haut de Gaetan_63
à Gaetan_63
Fais gaffe! un pythoneux t'a piqué ton pseudo
à Gaetan_63
Fais gaffe ! Un usurpateur perlien t'as floué
[^] # Re: Performance de dev
Posté par lezardbreton . Évalué à 3.
[^] # Re: Performance de dev
Posté par Stibb . Évalué à 1.
[^] # Re: Performance de dev
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Sinon, Perl a l'avantage d'être sans doute le plus rapide des langages interprétés.
"La première sécurité est la liberté"
[^] # Re: Performance de dev
Posté par manatlan (site web personnel) . Évalué à 2.
?!?
d'où tu tiens cette info ?!
[^] # Re: Performance de dev
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://shootout.alioth.debian.org/benchmark.php?test=all&(...)
Mais cela n'est plus vrai python s'est rattrapé.
Par contre, ruby reste en arrière.
"La première sécurité est la liberté"
[^] # Re: Performance de dev
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
http://www.mozilla.org/projects/xpcom/
# avis
Posté par fredix . Évalué à 8.
- Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?
Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.
Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.
Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.
Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.
Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.
Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
http://freedesktop.org
Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.
Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.
[^] # Re: avis
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Tout a fait, comme Perl avec son futur parrot http://www.parrotcode.org/ , que pense utiliser aussi les developpeurs de PHP, et qui sera certainement utilisé par d'autres langages de scripts. (parrot est une machine virtuelle, executant donc du bytecode, avec garbage collector et tout le toutim)
[^] # Re: avis
Posté par manatlan (site web personnel) . Évalué à 0.
[^] # Re: avis
Posté par djrom . Évalué à 3.
Avec même pleins des vraies choses qui marchent, sisi !
[^] # Re: avis
Posté par Éric (site web personnel) . Évalué à 2.
Source ? pour suivre le développement de PHP je peux t'assurer que ce n'est pas du tout le cas.
Il y a certes deux personnes qui ont fait un jet pour s'amuser mais c'est resté du domaine de l'anecdote.
# Le problème avec les bindings...
Posté par Croconux . Évalué à 3.
Pour Gtk, les choses se passent un peu mieux, il me semble (du C "normal", non customisé ça passe déjà mieux), mais il n'empêche que pour profiter d'une nouvelle version (surtout sous autre chose que Linux) il faut quand même attendre.
Enfin avec les bindings on profite des bugs de la bibliothèque plus des bugs du binding. On se retrouve parfois avec un code qui merde en GtkRuby et qui passe en C alors que normalement on fait exactement la même chose.
[^] # Re: Le problème avec les bindings...
Posté par fredix . Évalué à 2.
Mais quand on a fait du GTK+ en C et qu'on en fait en Ruby on se rend compte de l'énorme simplicité et donc rapidité de développement qu'apporte un langage script.
Si le but est de faire du multiplateforme alors effectivement le binding complique les choses surtout si celui-ci est plus ou moins mal porté. Dans ce cas autant coder directement en GTK+ ou QT.
Cependant, l'on parle de desktop ici où la portabilité n'est pas le but premier, même si des projets (stupides à mes yeux) de porter KDE ou GNOME sur Windows existent.
En programmation desktop, l'intérêt d'utiliser un binding est énorme. Quel développeur linux utilisant pyQT ou RG2 voudrait faire du C ou du C++ pour son IHM ?
Quant à faire des applications multiplateformes, à mon avis c'est vouloir sacrifier pas mal de possibilités du desktop sur l'autel de la portabilité ... et c'est une grosse erreur. Il suffit de voir l'énorme catalogue d'applis GTK+ multiplateforme exploitant mal GNOME au contraire des appli KDE, d'ailleurs on ne dit pratiquement pas appli QT puisqu'il n'en existe que très peu pour le bonheur de KDE...
[^] # Re: Le problème avec les bindings...
Posté par golum . Évalué à 2.
Avec Java par exemple, on a la possibilité d'utilser Swing et SWT et de l'attaquer avec tous les langages portés sur la plateforme: JRuby, Jython, Groovy et bien d'autres:
http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
En outre tu as accès à toutes les autres API du JDK.
Seul problème le portage des dernières versions du langage.
# monolithe ?!
Posté par Sylvain Sauvage . Évalué à 4.
Je ne pense pas que l'on puisse parler de « modèle monolithique », en tout cas pas par idéologie.
Il est logique que :
- le langage soit répandu, pour avoir un maximum de contributeurs et une plus grande chance de survivre ;
- le langage permette d'écrire des bibliothèques « de base » (c'est-à-dire des .so pour ELF), pour être utilisables par un max. de programmes, en tout ou partie, et de manière optimale ;
- le projet ne s'éparpille pas en utilisant quarante langages.
À partir de là, les langages possibles sont le C (plus utilisé) et le C++ (un peu moins).
Ensuite, si les contributions sont d'utilisation générale, il est logique de demander que celles-ci s'intègrent dans l'existant, c'est-à-dire qu'elles puissent être utilisées depuis le langage choisi par le projet et qu'elles puissent aussi être intégrées dans des .so.
De plus, il est aussi bon de rappeler que Gnome a, dès le début, proposé une interaction via CORBA, et KDE via DCOP, permettant ainsi à une communication à la fois dynamique et ouverte (multi-langage).
Ça, c'était pour le côté « mono-langage ». En ce qui concerne l'aspect monolithique, rappelons encore que le modèle de KDE est compentiel (toujours DCOP) et que celui de Gnome ne l'est pas beaucoup moins. Ils sont largement plus modulaires que monolithiques.
Voilà pour ce point. Pour les autres points, complexité et cycle de développement, la complexité est inhérente à la nature de ce genre de projet et je ne vois pas trop ce que le cycle de développement peut poser comme problèmes au développeur d'applications Gnome ou KDE ou en quoi l'utilisation d'un langage interprété viendrait modifer ce cycle.
# Joli discours...
Posté par blenderman . Évalué à 1.
Pourquoi faire simple quand on peut faire compliqué ;)
Nan mais sérieux, je saurais pas t'aider pour le language que tu cherche, mais moi j'aime beaucoup python+wxwidget...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.