J'ai également le Sansa Clip+. Je l'utilise surtout pour lire le format FLAC.
Dans l'ensemble il est bien (écran lisible, petit et léger, 8h d'autonomie, micro-SD, USB standard, bon son...) mais malheureusement le volume sonore est faible. De plus il plante régulièrement (apparemment à cause des tags dans mes fichiers FLAC).
Je compte utiliser Rockbox http://www.rockbox.org/ , as tu déjà essayé sur ce modèle ?
J'imagine que la discussion a eu lieu via mailing-list
Par IRC apparemment, ca tempere quand meme les propos : en general sur une mailing-list les gens sont plus "raisonnes" et surtout pas seulement toi peux juger/interpreter ce qui s'y dit.
Je viens de passer hier soir a bidouiller un peu Mono sous Windows et il y a pas mal de trucs qui me déplaisent...
Ils utilisent encore les autotools pour compiler !
L'organisation du repository fait que pour compiler un petit composant (dans mon cas XSP, un petit serveur web) et non l’intégralité de Mono, il faut bidouiller les scripts
MonoDevelop et autres applications utilisent Gtk+ et sous Windows c'est vraiment horrible : thème qui s’intègre mal et surtout la boite de dialogue pour les fichiers anti-ergonomique
Le package Mono pour Windows dans la page de téléchargement contient tout, vraiment tout ! Gtk, XulRunner, IKVM... plus de modularité n'aurait pas fait de mal
ASP.NET MVC 3 sous Windows est censé être corrigé dans la 2.10.1, en fait non :/
et c'est pas les quelques dev' Mono qui vont pouvoir continuer le support et l'évolution
et c'est pas les quelques dev' de Linux qui vont pouvoir développer un OS
Pour info les devs de Mono ont implémenté tout .NET + ajouté pas mal de librairies et applications dont Gtk#, MonoDevelop (IDE), Moonlight, MonoDroid, MonoTouch, MonoMac, Gecko#, WebKit#...
La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.
Même pas, la licence MIT (concerne les librairies et le compilo) est quasi-identique a la BSD donc tu fais ce que tu veux.
c'est les mêmes auteurs qui font Mono et MonoDroid
Oui et non, il y a des contributeurs externe a Novell sur Mono...
Mais Novell demande l'assignement du copyright pour certaines parties de Mono (de plus en plus désuet j'imagine avec le basculement vers la licence MIT).
Seule la couche de compatibilité pourrait [...] poser problème [...] sous Linux elle n'est pas nécessaire et n'a pas vraiment d'utilité.
LINQ, ADO.Net, WCF, WF, XML, HTTP... Si tu fais du C# t'es pratiquement obligé d'utiliser des composants de .NET (même sous Linux) qui donc ne font pas partie des normes ECMA (sauf a re-inventer la roue évidemment).
ECMA couvre seulement le langage lui même, pire C# 3 et 4 ne sont pas couvert, la dernière norme date de 2006 -> une éternité !
Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.
I do not know of any patents which Mono infringes.
Et s'ils en rencontraient :
[...] (1) work around the patent by using a different implementation [...] if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Je confirme, Windows 7 fonctionne sur un vieux P4 avec 512Mo RAM : navigation internet, Word ect... C'est lent certes mais ca marche et ca m'avait plutot bluffe.
copie de T au return <------ génération de l'exception
Effectivement, je ne suis pas un specialiste de ce genre de truc.
C# et Java ne sont pas exception safe. Ce qui pose un gros problème de robustesse
Néanmoins je pense toujours que "parler d'erreurs de design est exagéré".
J'imagine que les developpeurs de Qt, C# et Java ont fait un choix en connaissance de cause. Ca ne conviendra pas a toutes les utilisations certes.
Notons que quand on developpe en Qt, en general on n'utilise pas les exceptions car Qt ne les utilisent pas.
Lors de l'étape 1 il y a un appel à l'operateur = de T (T::operator=())
Si l'operateur = lance une exception alors la copie ne se fait pas et T retourné par dequeue() est foireux.
Effectivement std::queue ne fonctionne pas ainsi et pop() (l'equivalent de dequeue()) ne retourne rien cf http://www.sgi.com/tech/stl/queue.html#3 ou les concepteurs de la STL expliquent les raisons.
Es dramatique ?
Une exception a eu lieu, ta valeur est donc non garantie, je trouve rien de choquant a ca, c'est meme plutôt commun.
Tu peux toujours utiliser QQueue de la meme façon que std::queue.
AHMA les concepteurs de la STL ne détiennent pas LA vérité. Par exemple en C# Queue.Dequeue fonctionne de la meme façon que QQueue, pareil en Java.
Parler d'"erreurs de design" est clairement exagéré.
Qt vs STL ? c'est même pas comparable tellement Qt est supérieur !
Exemple pour QString : partage implicite, UTF-8, UTF-16, utilisation des regexp, toLower(), toUpper(), split(), QStringList, startsWith(), endsWith(), contains(), replace(), append(), remove(), fromNumber(), toNumber(), trim()...
Avec std::string tu dois tout te palucher et perdre ton temps à re-inventer le n-ieme splitstring ou remplacement de chaîne de caractères.
Que Qt suive le modèle de Schwartz ou celui de Planck, que le constructeur ne prenne pas des iterateurs, la sémantique de at() et [] ect..., c'est du blabla et on s'en fou. Ce que je vois c'est le résultat au quotidien : avec Qt ça marche, c'est simple, c'est agréable, je développe plus vite et mieux parceque Qt est très bien foutu, bien mieux que la STL.
Heureusement que QString n’hérite pas de std::string !
Pareil pour QList, std::list et les autres.
De toute facon la plupart des classes de la STL (dont std::string) n'ont même pas de destructeurs virtuels.
Pour passer de std::string a QString et vis versa il y a les méthodes suivantes :
[^] # Re: Sansa
Posté par tanguy_k (site web personnel) . En réponse au journal Lost in mp3 players.... Évalué à 2.
J'ai également le Sansa Clip+. Je l'utilise surtout pour lire le format FLAC.
Dans l'ensemble il est bien (écran lisible, petit et léger, 8h d'autonomie, micro-SD, USB standard, bon son...) mais malheureusement le volume sonore est faible. De plus il plante régulièrement (apparemment à cause des tags dans mes fichiers FLAC).
Je compte utiliser Rockbox http://www.rockbox.org/ , as tu déjà essayé sur ce modèle ?
# Pourquoi ?
Posté par tanguy_k (site web personnel) . En réponse au journal Le respect des licences. Évalué à -10.
Je comprends pas pourquoi tu veux absolument que l'on te mentionne ? A priori ça ne t'apporte rien.
[^] # Re: Les vrais chiffres
Posté par tanguy_k (site web personnel) . En réponse au journal 94% des ordinateurs vendus dans le monde équipés de Windows (contre 2% pour Linux). Évalué à 1.
iOS, Android ? on parle de PC desktops pas de smartphones...
# Les vrais chiffres
Posté par tanguy_k (site web personnel) . En réponse au journal 94% des ordinateurs vendus dans le monde équipés de Windows (contre 2% pour Linux). Évalué à 3.
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Web_clients
[^] # Re: Mailing-list
Posté par tanguy_k (site web personnel) . En réponse au journal Putain de nazis de l'interface!. Évalué à 2.
Par IRC apparemment, ca tempere quand meme les propos : en general sur une mailing-list les gens sont plus "raisonnes" et surtout pas seulement toi peux juger/interpreter ce qui s'y dit.
# Mailing-list
Posté par tanguy_k (site web personnel) . En réponse au journal Putain de nazis de l'interface!. Évalué à 4.
J'imagine que la discussion a eu lieu via mailing-list, est-il possible d'avoir les liens vers les mails en question ?
# Qualite sonore
Posté par tanguy_k (site web personnel) . En réponse à la dépêche 10er10 : un « Deezer » libre et performant. Évalué à 10.
Si c'est exact c'est une connerie sans nom !
# Mono et ses petits problemes...
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 3.
Je viens de passer hier soir a bidouiller un peu Mono sous Windows et il y a pas mal de trucs qui me déplaisent...
[^] # Re: L'eternelle question
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 6.
et c'est pas les quelques dev' de Linux qui vont pouvoir développer un OS
Pour info les devs de Mono ont implémenté tout .NET + ajouté pas mal de librairies et applications dont Gtk#, MonoDevelop (IDE), Moonlight, MonoDroid, MonoTouch, MonoMac, Gecko#, WebKit#...
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 3.
Effectivement, il y a 2 normes ECMA (334 et 335).
ECMA 335 couvre la CLI et apparemment tout System.* (notamment XML, HTTP, IO...)
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf et la dernière mise a jour date de décembre 2010 !
[^] # Re: Closed???
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 3.
Même pas, la licence MIT (concerne les librairies et le compilo) est quasi-identique a la BSD donc tu fais ce que tu veux.
Oui et non, il y a des contributeurs externe a Novell sur Mono...
Mais Novell demande l'assignement du copyright pour certaines parties de Mono (de plus en plus désuet j'imagine avec le basculement vers la licence MIT).
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 5.
LINQ, ADO.Net, WCF, WF, XML, HTTP... Si tu fais du C# t'es pratiquement obligé d'utiliser des composants de .NET (même sous Linux) qui donc ne font pas partie des normes ECMA (sauf a re-inventer la roue évidemment).
ECMA couvre seulement le langage lui même, pire C# 3 et 4 ne sont pas couvert, la dernière norme date de 2006 -> une éternité !
Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.
Les développeurs de Mono ne sont pas idiots, ils ont bien conscience des risques de brevets. Cf Icaza en 2006 http://tirania.org/blog/archive/2006/Nov-04.html
Et s'ils en rencontraient :
La FAQ de Mono est également assez clair sur le sujet http://www.mono-project.com/FAQ:_Licensing#Patents
Conclusion : le risque n'est pas nul mais assez faible a mon avis
[^] # Re: Je tiendrai jusqu'à demain
Posté par tanguy_k (site web personnel) . En réponse au journal Mono pour Android en version 1.0. Évalué à 3.
Pas mal la démonstration en 2 étapes :)
AHMA La menace des brevets sur Mono s'amenuise avec le temps
[^] # Re: LGPL
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Qt, vers un retour en arrière ?. Évalué à 1.
Pas rentable : la vente des licences ne couvrait pas la R&D
[^] # Re: Millenium
Posté par tanguy_k (site web personnel) . En réponse au journal Un OS robuste qui résiste à 26 ans de mises à jour !. Évalué à 2.
Je confirme, Windows 7 fonctionne sur un vieux P4 avec 512Mo RAM : navigation internet, Word ect... C'est lent certes mais ca marche et ca m'avait plutot bluffe.
[^] # Re: C'est quoi ce troll?
Posté par tanguy_k (site web personnel) . En réponse au journal Comment ça marche chez microsoft. Évalué à 3.
Y'a que moi que ca choque ?
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 1.
Effectivement, je ne suis pas un specialiste de ce genre de truc.
Néanmoins je pense toujours que "parler d'erreurs de design est exagéré". J'imagine que les developpeurs de Qt, C# et Java ont fait un choix en connaissance de cause. Ca ne conviendra pas a toutes les utilisations certes.
Notons que quand on developpe en Qt, en general on n'utilise pas les exceptions car Qt ne les utilisent pas.
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Effectivement je crois pas que l'on puisse faire ca avec Qt. Boost/STL est effectivement plus puissant.
Y'a que moi pour trouver ce code imbitable ?
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Merci de ne pas me faire dire ce que je n'ai pas dit !
Je me cite moi-meme : "Je trouve la facon de faire plus logique, simple et lisible avec Qt"
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à -1.
Prototype :
T QQueue::dequeue()
Au moment de
dequeue()
2 étapes sont effectuées :Lors de l'étape 1 il y a un appel à l'operateur = de T (
T::operator=()
)Si l'operateur = lance une exception alors la copie ne se fait pas et T retourné par
dequeue()
est foireux.Effectivement
std::queue
ne fonctionne pas ainsi etpop()
(l'equivalent dedequeue()
) ne retourne rien cf http://www.sgi.com/tech/stl/queue.html#3 ou les concepteurs de la STL expliquent les raisons.Es dramatique ?
Une exception a eu lieu, ta valeur est donc non garantie, je trouve rien de choquant a ca, c'est meme plutôt commun.
Tu peux toujours utiliser
QQueue
de la meme façon questd::queue
.AHMA les concepteurs de la STL ne détiennent pas LA vérité. Par exemple en C#
Queue.Dequeue
fonctionne de la meme façon queQQueue
, pareil en Java.Parler d'"erreurs de design" est clairement exagéré.
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Et elle vient d'où cette exception ?
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à -1.
Pas compris, ca t'arrive souvent de spliter des nombres et des classes ? tu peux donner un exemple
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 3.
Le débat portait sur Qt vs STL :)
Donc comparons maintenant Qt vs Boost, split d'une string :
std::string str = "string to split"; std::vector<std::string> strs; boost::split(strs, str, boost::is_any_of(" "));
QString str = "string to split"; QStringList strs = str.split(" ");
"Joindre" des strings ensemble :
std::vector<std::string> list; list.push_back("Hello"); list.push_back("World!"); std::string joined = boost::algorithm::join(list, " ");
QStringList list; list << "Hello" << "World!"; QString joined = list.join(" ");
Je trouve la facon de faire plus logique, simple et lisible avec Qt.
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Qt vs STL ? c'est même pas comparable tellement Qt est supérieur ! Exemple pour QString : partage implicite, UTF-8, UTF-16, utilisation des regexp, toLower(), toUpper(), split(), QStringList, startsWith(), endsWith(), contains(), replace(), append(), remove(), fromNumber(), toNumber(), trim()...
Avec std::string tu dois tout te palucher et perdre ton temps à re-inventer le n-ieme splitstring ou remplacement de chaîne de caractères.
Que Qt suive le modèle de Schwartz ou celui de Planck, que le constructeur ne prenne pas des iterateurs, la sémantique de at() et [] ect..., c'est du blabla et on s'en fou. Ce que je vois c'est le résultat au quotidien : avec Qt ça marche, c'est simple, c'est agréable, je développe plus vite et mieux parceque Qt est très bien foutu, bien mieux que la STL.
[^] # Re: Boost ? c'est quoi ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 4.
Heureusement que QString n’hérite pas de std::string ! Pareil pour QList, std::list et les autres. De toute facon la plupart des classes de la STL (dont std::string) n'ont même pas de destructeurs virtuels.
Pour passer de std::string a QString et vis versa il y a les méthodes suivantes :
std::string QString::toStdString() const std::wstring QString::toStdWString() const QString fromStdString(const std::string & str) QString fromStdWString(const std::wstring & str)
Pareil pour QList :
std::list<T> QList::toStdList() const QList<T> QList::fromStdList(const std::list<T> & list)
Si Qt est si bien (simple, facile, puissant, intuitif, performant...) c'est aussi parcequ'ils ne se basent pas sur la STL.