manatlan a écrit 1590 commentaires

Oh, tu exagères ...

wymypy s'adresse essentiellement à la plateforme linux ...
La grande majorité des distribs linux possède python de base (non ?!)

Sous nux, pyinstaller permet de freezer une appli python ...
ça marche très bien sous win, mais sous linux, j'ai jamais essayé, et ça me fait un peu peur ... cependant, pourquoi pas ?!

Cependant, par rapport aux autres "client web" de mpd, il n'y a pas photo ... Les autres demandent l'installation d'apache le plus souvent, de php ou de java, et qqfois de mysql (c pas une blague) ... ce qui au final, est bien plus contraignant ... (ce pourquoi je me suis lancé dans wymypy)

arghhh ... pour l'accès distant, c de ma faute
merci à toi

j'ai re-uploadé une version qui fonctionne ailleurs qu'en localhost (c'est quand même le but ;-( ... je suis vert)

Qu'appelles tu faire ramer sinon, en local ?

> Surtout si tu donnes l'adresse de setup_tools et du egg de wsgi
> en cas de except, c'est simple et propre :)

En fait, je pense que je vais intégré un "server wsgi" (j'ai qques codes sources de 3/4ko) ... comme ça, aucun problème ...

> Après y a le packaging, l'internationalisation, les problemes
> d'encodage, la doc, les plugins, les ... :)

normalement, il ne devrait pas y avoir de prob d'encodage, tout est unicode/utf8 ...

et si ça fonctionne bien, je rajouterai effectivement des "plugins" (c'est tout l'intérêt d'être resté en WSGI)
pour afficher pochettes et lyrics par exemple ...(ce qui devrait être très simple)

oui, je vais remettre le bang à "env python" ...
et try/catché l'import de wsgiref ...
(si je suis courageux, je vais incorporer un autre serveur wsgi dans le source (il y en a plein des petits de 3/4ko))

Pour sajax : il ne s'agit plus de sajax ... certes je l'ai utilisé comme base (y a 1 ou 2 ans), mais je le modifie moi même suivant mes besoins. Donc ça bougera plus

Sinon, ce soir j'incorpore une seekbar en javascript de mon cru ...
et je posterai un journal sous peu ...

en fait, on a besoin du 2.5, car la lib wsgiref est incluse en standard dans le 2.5
Si tu prends la lib wsgiref et que tu l'installes dans le site-package de python2.4, ça marche aussi ...

oui, faut que je rajoute le COPYING dans l'archive ...

Cependant, dans l'archive, il n'y a pas d'autres projets (à part mpdclient.py, mais il n'évolue guère, et serait très facile à substituer)

Sinon, je me suis tromper en postant ça dans le forum, je voulais le faire dans les journaux, pensez vous que je dois le mettre dans les journaux ?

oui, ça revient souvent ...

Mais c'est un tellement beau daemon musicale qu'il faut en parler !
j'en RE-profite pour dire que le client sonata est vraiment sympa : http://sonata.berlios.de

Hier soir, je mattais un divx(*) via freeplayer/homeplayer sur ma tv (* : "j'irai dormir chez vous, au quebec")
Il s'est mis à saccader ...
Je suis allé voir sur l'ordi, un htop ... et "beagled" processait fort ...
je l'ai coupé, et un "sudo apt-get remove beagle" ont définitivement réglé le problème.

je ne garde que tracker

Pourquoi donc beagle se met il a indexe les fichiers ainsi ?! il ne marche pas avec inotify ?!

Je m'en doutais que tu devais trainer sur dlfp ...

Mais de là à te demander directement pour mes soucis de test/fonctionnement (dans le sens je veux pas embêter)
(j'avais le daemon qui tournait pendant 1h, mais le search-tool ne renvoyait rien)

Par contre ton avis m'interesserait (et certainement d'autres), sur tracker/beagle/strigi/pinot ... bref, les desktop-search

J'ai pas mal surfé là dessus hier soir ...(d'ailleurs j'ai lu qqpart que pinot était interessant, mais son plus gros reproche, c'est que personne n'arrivait à trouver l'endroit où il est développé )

oui, en surfant là dessus, suis également tombé sur strigi, et le frenchy pinot ...
Je n'ai pas reussi à faire fonctionner pinot (un repository pour edgy : http://gauvain.tuxfamily.org/repos/ ) ... Quant à strigy ( http://www.vandenoever.info/software/strigi/ ), pour l'instant, je n'ai rien pu en faire (ça a l'air trop qt-oriented quand même)

tracker j'ai pu l'installé, faire l'indexation (ultra rapide), l'intégrer dans nautilus, l'intégrer dans la deskbar ... en moins de temps qu'il n'en faut pour l'écrire ...

oui, j'ai oublié de préciser dans mon journal que ça utilisait bien evidemment dbus pour communiquer

> meta-tracker ne gère pas la moitié des sources de données que
> Beagle gère, à commencer par toutes les sources de données
> liées aux applications (IM, mail, navigateur web, etc.).

faut pas se fier au site officiel, qui n'est pas mis à jour régulièrement !
meta-tracker cherche déjà dans les mails par exemple (Evolution, Thunderbird and KMail ... ainsi que les dossiers génériques de mails (cf tracker.conf) )
http://jamiemcc.livejournal.com/3782.html

Ils developpent plus vite qu'ils ne communiquent ...

Joyeux noël à toutes les moules de dlfp !

Merci pour tous ces journaux, ces trolls, et les discussions à n'en plus finir (où généralement on est tous d'accord, mais c'est juste pour le plaisir)

Que le père noël offre plein de distribs gnu/linux à toutes et tous !

> Vous y allez un peu fort tous les deux, il faut assumer son incompétence

j'ose esperer que tu blaguais ...
Pour ma part (jbrout), c'est un programme que je faisais uniquement pour moi et mes besoins. Puis je me suis dit que ça pourrait peut être servir à d'autres ...
Et c'est là, que ça commencé à se compliquer. Alors si en plus de coder son appli, il faut en plus s'occuper du site, s'occuper des news, manager le forum, répondre aux mails/questions, et en plus packager pour chaque distrib ... c'est 80% de COM, 20% de codage ...
On s'en rends pas compte de suite, mais rien que releaser en gpl, c'est un boulot de ouf ... Si en plus faut se coltiner chaque distrib, chaque type de paquet et les moults dépendances, c'est énorme.
Certes je me suis interessé à essayer de faire un paquet deb, pk qqpart ça m'interessait (pk ces les paquets de ma distrib), mais tu n'imagines pas à quel point, faire un paquet rpm ou arch ça ne m'interesse pas (et je me force, à contre coeur, à faire un paquet windows (alors que je n'ai même plus windows) uniquement pk c'est historique (mon prog ratissait win au début des temps))... (et pour ta gouvernes, qu'on utilise ou pas mon programme, tu n'as pas idée à quel point ça me passe au dessus de la tête ...). Par contre je suis hyper reconnaissant des apports envoyé par la communauté (autres paquets, doc, support ...), et ça, ça me motive ...

En exagérant un tout peu, ça fait 10ans que j'utilise de l'IM
Je me suis toujours démerder pour lancer mon client sans être obligé de saisir mon MDP ...

Et v'là t y pas que le nouveau Gajim accède au gnome-keyring (ceci dit c'est très bien, bonne intention)
Mais je continuerai d'utilser PSI si je ne peux pas changer ça

C'est pas ce à quoi sert les "alertes googles" ?

même problème ...
J'ai reussi à faire un package deb, en hackant un deb existant ;-)
(maintenant je pourrai faire mieux en suivant ce tuto : http://showmedo.com/videos/video?name=linuxJensMakingDeb&(...) )
Le rpm est généré en alien'ant le deb (et pose prob sur certaines distribs)
Après c'est des contribs (arch, ebuild, ...)
Je ne me vois pas générer chaque type de paquet et tester dans une VM chaque paquet pour sa distrib ...

ce n'est pas "smart" qui est censé réglé ce prob à terme ?

skateinmars ?
c'est l'alsacien d'ubu-fr ?

Je m'interesse énormément au python/web

Cependant, bien que j'ai testé les 2, vite fait ... J'ai du mal à accrocher à l'un ou à l'autre ... (j'aime pas les frameworks)
L'approche MVC est certes interessante, mais j'ai du mal à m'adapter à un framework qui m'impose une certaine façon de faire (et il en est de même pour Ror, avant que qqu'un ne saute là dessus)
Django est plus proche dans l'esprit MVC/ror, en proposant du tout frais. Turbogears est plus dans l'esprit réutilisation (à base de libs connus).
Prônant la réutilisation j'aurai tendance à préconiser TG. Mais on entends plus de bien sur django.

Maintenant aussi, je n'aime pas les frameworks qui impose des conventions, et t'oblige à apprendre les règles du framework ...
Je préfère faire le mien, qui par définition, me va mieux ! (attention : ce n'est réinventé la roue non plus !!! car le web sous python c'est avec le standard WSGI, donc on peut réutiliser plein de choses existantes, et les agancer à sa guise (j'y reviens plus tard))

Je suis un grand/big fan de webpy ( http://webpy.org/ ) (l'anti framework par excellence, mais qui apporte son lot de choses magiques). Avec lequel tu peux batir aisément ton propre framework, en utilisant les mêmes briques que TG par exemple.

Dans le même style, en light, il y a collubrid ( http://wsgiarea.pocoo.org/colubrid/ )... ou des choses comme pylons ( http://pylonshq.com/ ) ou simpleweb ( http://simpleweb.essienitaessien.com/getstarted ) qui sont light aussi et apporte une approche MVC light également (en donnant moins de contraintes que django ou tg) (d'ailleurs avant de partir dans Django/TG, il est bien de matter simpleweb avant, car c'est vraiment le MVC au plus simple ! du coup ça permet de bien comprendre les 2 mastodontes)

Dans la mesure où maintenant, le web en python est bati autour de WSGI (tous sont wsgi, evidemment).

Sinon comme dit, il existe déjà des foultitudes de briques WSGI (http://wsgi.org/wsgi/Middleware_and_Utilities) , qui chainées entre elles, te permettent également d'arriver à des choses vraiment sympas très rapidement.

Moi perso, webpy me suffit amplement pour la majorité de mes besoins (avec utilisations de briques externes suivant les besoins, mais webpy vient également avec le minimum syndical).

Mais si devais partir sur un gros truc, je partirai maintenant avec des briques WSGI que je monterai moi même, avec paste ( http://pythonpaste.org/index.html )

ça peut paraître un peu complexe par rapport aux soluces des frameworks clé-en-mains. Mais ça ne l'est absolument pas (http://wsgi.org/ et les docs sur paste expliquent vraiment bien les fondements et l'idée derrière tout ça).

SInon, un truc pour un système de payement, faut bien partir du principe, qu'en python, il existe des libs pour tout ce qui est imaginable ... avec google, je suis tombé la dessus : http://sourceforge.net/projects/pypfpro/ ça devrait faire l'affaire !
(cependant, en python, il existe souvent plusieurs libs, donc faudrait poursuivre les recherches, et trouver la mieux)

> Ben non, vu que justement, le prérequis pour arriver la, cf ton argumentaire,
> c'est de bien adapté le driver proprio dans le systeme, pour rafler les parts
> de marchés.

Oui, mais le driver proprio ne sera jamais au poil ! Ce n'est ni nvidia ni ati qui vont faire que leur driver proprio marchent au poil (acpi, conflits, ...). Ils ne sont pas assez aware du "LL/linux" pour rentrer dans des considérations comme ça. Ils vont au moins toujours essayé de sortir qqchose qui "marche un peu prêt".

Un blob proprio empechera toujours un certain degré de liberté autour du noyau. Et ça, ça pose problème. (sinon je vais lire l'article de lwn, qui me semble déjà vraiment bien !)

Pour le plugin flash, je suis également pour le livrer (toujours dans l'idée "faute de mieux") (enlever youtube/dailymotion à qqu'un est un sacrilège !)

L'analogie avec XP : c pour de rire, je pense ;-)

Il ne faut pas avoir peur du "driver proprio", il sera toujours pourri face à un driver libre ... Et même avec les meilleurs volontés, le "driver proprio", par essence, posera toujours des problèmes, que les linuxiens auront tant qu'il n'existe pas un driver/cg libre.

Après on est d'accord, il faut fixer des prorités ...
Moi, je suis clairement pour prendre des PDM coûte que coûte (quitte a passer une "sale periode" (utilisation de blob proprio)) ...
je crois au cercle vertueux, plus il y aura de monde, plus on se fera entendre, et plus ça avancera vite ...

Exactement !!!

Terminons notre rèves avec une animation à la buster Kitton, qu'aurait fait ati/nvidia si un milliardaire qui avait été dans les étoiles avait été leur proposer d'acheter 50 milllions de carte graphique 3D, si il avait la possibilité d'écrire un pilote 3D potable et stable (même si 15-20% moins rapide que sous winwin) et qu'ensuite il avait vendu les cartes sur un site pour son prix d'achat + une faible marge+ le driver open source) tu crois pas que son apport au libre aurait été 50 millions de fois plus important ? Et là oui, il aurait eu mon profond respect et là oui, les gens qui sont sous ubuntu pourrait me dire : "nous, connard, on a fait pour le libre", mais ce n'est pas le cas.

C'est pas bête ! Mais je reste persuadé que ça arrivera ...

Je reste un partisan des drivers proprios dans l'ubu ! Même si comme tu le dis très bien, ça ne fait pas avancer le developpement des drivers "nouveau" par exemple (comme fedora le fait)

Je vois 2 options/scenariis ...

- on vire les drivers proprios des cg à tous les niveaux (et d'ailleurs tous les drivers proprios) ... et on attends 3/4 ans qu'un eventuel mecene injecte de l'argent dans une cg libre, ou que les drivers libres arrivent a un niveau correcte ... mais on va perdre 3/4 ans, et vista prendra encore plus de PDM (verouillant toujours un peu plus le marché) ... d'ici 3/4 ans : les CG auront encore beaucoup changé, et ces drivers libres seront alors obsoletes. et on refait la boucle. (faire un driver libre sur une carte prorio, en reverse engenering n'ai pas la bonne soluce, et introduira toujours un retard enorme entre le hard et le soft)

- on force les drivers proprios ... du coup, le windowsiens avec sa carte nvidia de ouf pourra switché facilement, car il pourra encore l'utilisé (beryl, google earth, jeux 3D ...) (comprendre il n'aura pas l'impression de jeter sa CG à la poubelle) ... du coup, il est plus facile de prendre qques PDM à vista ... d'ici 3/4 ans, il y aura un peu plus de linux (3 à 4% ?!) ! Et "l'entreprise/le gars" qui voudra rafler le marché linux des CG en sortira une avec des drivers libres ... et il est certain de rafler le marché, même avec une CG moins bien .... (car sous linux qui dit driver libre, dit driver excellement bien adapté avec le reste du systeme / (avec un proprio y aura toujours des probs (acpi, api, version de noyau, version xorg, ...))

On est dans une période transitoire, et tout le monde le ressent ... il faut forcer le proprio ... le geek s'il n'en veut pas pour des raisons éthiques, il peut toujours les enlever (par contre c plus dure de dire au newbie d'installer les proprios)

il faut qu'unbuntu livre le proprio par defaut, ainsi il livrera aussi la MAJ de ces drivers proprios lors de l'update de kernel ... et on evitera le genre de prob d'une upgrade noyau, et un retour en mode console (cf le point [4] du post initiateur). qui a fait très mal à pas mal de newbie ...

A mon avis, il y a plus de personne sous ubu qui installent cache le driver proprio suite à l'installe fraîche d'une buntu, que de personnes qui reste avec le driver libre. Par conséquent, il faut fournir le "proprio" ... en attendant, faute de mieux.

Le libre monte en puissance un peu partout ... ça suivra dans les CG aussi, je ne me fais aucun soucis ... il y a des "constructeurs intelligents" (bon je suis de nature optimiste)

oui, je me suis mal exprimé, et je me suis fait bien moinssé (

Le hic, vient du fait que je n'ai recopié que le début des ses points. (j'aurai du les reprendre en entier)
et mon commentaire répondait à l'ensemble du point ... en gros "je n'aime pas ubuntu, pk ubuntu = gnome" ....
C'est du grand n'importe quoi, bien evidemment ! ça dénote une mauvaise fois profonde qui enferme son rédacteur dans le creneau qu'il croit dénoncer.

Les autres points, c'est pareil, aucun n'a vraiment de sens.

Donc je suis désolé de m'être fait mal comprendre

> Les aspects commerciaux me gênent toujours quelque part ...

Dans ce cas, il en est de même pour mandriva, fedora, suse, mepis, etc ... (80% des distribs)

> Je n'aime pas la philosophie de l'emploi de sudo dans Ubuntu...

C'est pourtant bien sympa comme concept. et on y arrivera aussi sur d'autres distribs. C'est bien clair, et largement suffisant pour le commun des mortels. Après un geek peut le désactiver sans problème.

> Je n'aime pas Gnome...

Oui, tu es sectaire, c'est ton choix ... Mais ça n'a que très peu de rapport avec ubuntu.

> Je ne parlerai pas de la stabilité exemplaire ...

N'importe quoi (encore ?). Mais on sens l'experience derrière ;-)

> Les Ubuntistes sont en train de devenir les plus radicaux, extrémistes et sectaires ...

Oui, ubu est la bête noire sur dlfp depuis qques temps, mais avant c'était mand[riva|rake] ... et demain ce sera une autre distrib (on me souffle ulteo?) ...
Catégoriser les gens ainsi dénote un certain sectarisme.
Quoi que t'en dise, l'ubu est certainement la distrib la plus apte a venir remplacer un windows au pied levé sur le poste d'un newbie. Les ubunteros l'ont bien compris, et tente de corriger le bug#1 (cf launchpad) ... certes peut être un peu trop ... mais peut on empecher les gens de propager linux/le logiciel libre/la bonne parole ?

> Les Ubuntistes sont en train de cracher sur la distribution-mère

Beaucoup ne savent pas à mon avis que debian en est la mère. Donc c'est juste une question d'éducation. Mais c'est aussi ça "populariser un linux", on commence à toucher à certaines franges de la populasse, et plus les geeks aware.


...
Bref, on sent le mec aigri à plein nez ... si encore on était vendredi, ça aurait été fun de démonter tes allégations étapes par étapes en poussant un troll de temps à autres ...
Mais là, c'est de la méchanceté pure et infondée. Ce n'est malheureusement pas avec des gars comme toi qu'on fera avancé le schmilblick ...
Alors qu'on devrait tous se donner la main pour aider à la linuxisation/liberalisation "du monde" ... y en a qui continu à fragmenter ... m'enfin
C'est ainsi, et faut faire avec ...

Je pensais voir plein de commentaires sur cette news, mais que neni.
Tout le monde utilise jBrout ?!?

Blagues à part ... il faudrait quand même que j'essaie digikam, maintenant qu'il stocke les infos principales dans les pictures
(ne serait pour voir que si jbrout/digikam sont compatibles)

Cependant, apparemment il faut toutes les libs KDE pour le faire tourner ... non ?

Certes, ce que tu dis est vrai ...
mais ce n'est que les différences entre 2 types de langage ...
il y a vraiment 2 écoles ...

(moi pour eviter ce genre de problème en aval, j'ai tendance à mettre des assert, ça evite d'avoir des surprises plus loin (mais c au runtime : on est d'accord))

> le typage explicite et uniforme montre sa supériorité.
Comme disait qqu'un dans le thread ... ça permet surtout à un programmeur de ne pas faire des erreurs bêtes (sinon ça compile pas). Ce qui permet de prendre des devs moins "experimentés" (dans le sens, suffit de lire le message d'erreur du compilateur, puis de corriger)
On est d'accord, ça donne un certain gage de "qualité" ... le dev est corrigé en amont !

Mais, vraiment, pour faire du csharp(~=java) à longueur de journée, ça apporte aussi énormément de bruit, et d'obligations (déclaration de type, castage toutes les 2 lignes) .... pour des choses souvent simples/triviales. Ca a aussi tendance à augmenter énormément le nb de lignes (5 à 10x) pour un même algo. ça prends du temps !
J'aurai tendance à penser qu'on est en permanence en train de lutter avec ces obligations et ces syntaxes, ce qui empêche réellement de se concentrer sur l'algorithme qu'on est en train d'implémenter. Le cerveau est en permanence agacé par ce bruit. (oui, les habitudes et un bon ide aident énormément)

En python, tu as cette liberté qui est énorme, le cerveau est totallement libre pour se concentrer sur l'essentiel : l'algorithme à implémenter.
Après c'est des conventions de codage, et de documentation. On doit plus faire confiance à l'humain, au dev.

Certes en statiquement typé, tu peux aussi faire du "dynamique", travailler avec des "objects" et caster à tout bout de champs. Mais dès que t'as besoin de faire de l'introspection, de créer des class dynamiquement, et toutes ces genres de choses : ça rentre très vite dans du code complexe, voire très tordu. (genre appelé dynamiquement une méthode d'une instance de classe que tu ne connais pas).

Maintenant dans la vraie vie pythonesque, j'utilise énormément de libs que j'ai pas codé et même pas vu le code .... et je peux te dire que c'est très très rare de tomber sur le genre d'erreur que tu décris (même si c'est techniquement possible)
Tu tombes bien plus souvent sur des "null object reference" que sur des erreurs de type ... et ça j'ai aussi avec des assemblies externes que je n'ai pas codé, en csharp (et dont je ne peux pas voir le code, en passant ;-)

L'avantage de python : c'est la vitesse de développement, bien supérieure aux langages statiquement typé.

Mais au boulot, quand je dois concevoir un "algo complexe" (embriquement d'algo), je le fais vite fait en python pour voir si ça roule, et je le traduis après en cs. C'est bien plus rapide que le faire en CS. Quand je dis complexe : c pas qqchose de pondable en "one shot", donc ça necessite qques tatonnements, et avec les languages compilés tu perds déjà 50% du temps à compiler avant de tester rellement l'algo ... et 30% du temps à batailler avec les syntaxes/obligations.
(bon quand ça compile, ça me laisse le temps de surfer ;-)