Je pensais pas que c'était possible un chipset son qui crame, et je trouve bizarre que des applications freeze à cause d'un chipset son défectueux, c'est pour ça que j'ai fais autant d'essais.
Bon alors pour ta première référence, c'est bien ce que j'avais trouvé avec google, il s'agit de l'émulation OSS, c'est pas vraiment un problème d'alsa.
Pour la seconde référence, le paragraphe suivant est celui-ci:
There are two functions for this kind of transfer. Application can get an access to memory areas via snd_pcm_mmap_begin() function. This function returns the areas (single area is equal to a channel) containing the direct pointers to memory and sample position description in snd_pcm_channel_area_t structure. After application transfers the data in the memory areas, then it must be acknowledged the end of transfer via snd_pcm_mmap_commit() function to allow the ALSA library update the pointers to ring buffer. This kind of communication is also called "zero-copy", because the device does not require to copy the samples from application to another place in system memory.
Si je comprends bien le fonctionnement de l'API, il faut utliser snd_pcm_mmap_begin() pour savoir où écrire dans mmap. Donc le problème que tu as décrit n'existe pas dans alsa, il s'agit bien d'un problème lié à l'éumlation OSS.
Je trouvais étonnant que les phase de terratec, qui sont recommandées un peu partout sur internet pour le son sous linux ne soient pas supportées en hard...
PS: ce n'est pas moins qui ai moinssé, j'ai trouvé ta remarque très intéressante.
Tu as des références?
Parce qu'une recherche sur google m'indique juste un problème lié à l'émulation oss avec les jeux dérivés de Quake3.
Donc si tu as des liens, ça m'intéresse!
PS: certains fabricants prétendent être "compatible linux" de manière très abusive, il y a donc un intérêt à regarder sur le site de la FSF (ati et nvidia par exemple supportent officiellement linux, mais fournissent des drivers binaires tout pourris).
Puisque tu parle de racisme, il me semble que c'est bien de cela qu'il est question, mais que c'était plutôt le policier qui était visé par ce racisme.
Pour ce qui se passe à la sortie des boites, je suis bien d'accord avec toi, mais ce n'est pas ce qui s'est passé ici.
Alors réfléchi et informe toi. Cette affaire n'est pas un bon prétexte pour parler de bavure raciste.
Pour récuperer ton ancienne installation commence par supprimer tout ce qui fait réference à Dapper dans /etc/apt/sources.list.
Tu voulais sans doute dire, commence par supprimer tout ce qui fait référence à Edgy.
Je ne connais pas le principe de l'analyse de branche, mais j'ai cru comprendre que c'est une opération réalisée par le CPU pour "deviner" la suite des opérations.
Apparement cette attaque est basée sur une surveillance de l'analyse de branche effectuée par le CPU.
Alors je me demendais si tous les processeurs font de l'analyse de branche (je sais pas, peut-être que les ARM n'en font pas...) ou si le fait d'avoir une architecture matérielle exotique pourrait être une parade acceptable à ce type d'attaque?
Bon ben voilà, Microsoft c'est toujours pas des bisounours. Si je m'écoutais, je dirais facilement que ce sont de lamentables charognes qui puent (hein? mais non je l'ai pas dit.) et vous, vous diriez quoi?
Ceci étant dit, si tu veux travailler tout le temps sur des fichiers latex (ce qui ne sert à rien avec LyX), tu peux utiliser en permanence exporter en latex pour sauvegarder, et importer latex pour charger.
C'est très fiable tant que tu fais toutes tes opérations d'édition avec LyX.
J'avoue que j'étais très sceptique au début, parce que j'avais très peur que ça ressemble à openoffice qui est très lourd (et un troll de plus :-) ).
Mais en fait LyX c'est vraiment léger, plus léger que Kile en tout cas, et puis c'est très rapide aussi. Bref, que du bonheur.
En plus je pense qu'on gagne du temps car on évite une bonne partie des essais erreurs de compilation/erreur qui arrivent forcément quand on utilise LaTeX avec un éditeur de texte.
Enfin, si tu veux vraiment faire du léger, qui se compile très rapidement, je te conseille d'écrire en plain TeX avec vi qui est plus léger que vim.
J'aime bien kile aussi, mais j'avoue que très vite, dans un document latex, on s'y perd...
Donc j'utilise LyX qui est très stable et disponible aussi sous windows (pour le boulot).
Pour ceux qui ne connaissent pas, c'est un éditeur WYSIWYM (What You See Is What You Mean), c'est à dire qu'on a pas exactement le rendu latex pendant l'édition, mais la structure du document est tout de même mise graphiquement en évidence lors de l'édition.
C'est très pratique, notamment pour l'écriture de formules mathématiques parce que ça permet de voir directement le résultat sans passer par la phase de compilation.
Donc kile, c'est bien. Mais LyX c'est mieux!! (c'est pour nourrir le troll...)
Pour le fonctionnement par référence ou par copie, il me semble que c'est essentiellement une question de génération. En fait, pratiquement tous les langages récents fonctionnent par référence, tandis que les langages plus anciens utilisent la copie. D'autres langages utilisent un peu les deux (les pointeurs en C permettent de faire la même chose).
Je pense que ça n'est pas utilisé dans matlab parce que ça change vraiment beaucoup la façon d'écrire les programmes, et puis aussi parce que personne n'en parle.
Dans le même ordre d'idée, matlab devient de plus en plus limité par le fait qu'il est fait pour une programmation procédurale. Il est par conséquent assez difficile de faire des programmes vraiment réutilisables, pourtant, la syntaxe ne change pas...
Ok, je ne connais pas bien fortran, et je ne sais pas pourquoi tu tiens tellement à ce que je dise des choses pas vraies, mais comme je te l'ai déjà dis plus haut:
En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
C'est exactement ce que tu viens d'affirmer en disant que j'avais tord.
Alors relis tout, et calme toi.
En attendant, je le dis et je le répete, quand en math tu as une matrice qui s'écrit: a=[[1 2 3]
[4 5 6]
[7 8 9]]
Alors, en python comme en matlab comme en math (et apparement fortran d'après ce que tu viens de dire), tu as: a[:,j] : colonne j de la matrice a
a[i,:] : ligne i de la matrice a
Maintenant si tu t'y perd, je ne peut rien pour toi...
autant pour moi, je pensais qu'en fortran c'était comme en matlab.
Pour ce qui est de matlab/octave/scilab, là je suis sur de moi, c'est pareil qu'en python.
Pour les mathématiques, ben je suppose que ça dépend des écoles, mais pendant toute ma scolarité, c'était comme ça aussi.
Il semble donc que le fortran est à contre courant, ce qui confirme sa réputation de langage à la syntaxe pourrie...
Houla!!
Je t'arrêtes tout de suite, ce n'est pas de cela qu'il s'agit. En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
Par contre en mémoire, la matrice [[1, 2, 3]
[4, 5, 6]]
sera stockée ainsi en Fortran/Matlab (stockage colonne): 1-4-2-5-3-6
mais en C/Python, elle sera stockée ainsi (stockage ligne): 1-2-3-4-5-6
Cela a une incidence pour savoir quel indice (de ligne ou colonne) va le plus vite. Je ne sais pas si les performances globales changent.
Chouette!!
J'aime beaucoup cette solution, je la trouve très élégante. Le seul inconvénient c'est qu'on doit toujours faire appelle à une variable intermédiaire mais tant pis...
Par contre je mettrai pas le . a pres le a a ta place ;)
Ben si, il faut mettre le point après le a sinon on fait une multiplcation matricielle qui s'écrirait avec une boucle:
c=0;
for i =1:length(a)
c = c + a(i)*b(i)
end
Scilab et Matlab c'est équivalent au niveau des performances et de l'utilisation mémoire. D'ailleurs, pour les 70 Mo ben je sais pas comment tu as eu ces chiffres mais pour moi ça serait plutôt 10Mo.
Pour les boucles, c'est toujours aussi lent car le code est interprété, et c'est le même problème sous Octave, Scilab, Python, etc.
Pour optimiser les performances, il faut écrire les opérations sous forme matricielle au maximum. C'est une gymnastique un peu difficile au début, mais ça fini par devenir un réflexe.
En gros, il ne faut pas écrire:
for i = 1:length(a)
c(i) = a(i)*b(i);
end
Mais plutôt
c = a.*b
Evidemment, cet exemple est trivial. C'est souvent plus compliqué mais ça s'apprend.
Excuse-moi je ne voulais pas être désagréable.
En fait je pense que l'avantage avec python c'est qu'on peut faire la transition de manière assez douce.
Je m'explique:
Python s'interface assez facilement avec des librairies écrites en C/C++/Fortran, par conséquent on peut toujours écrire les parties "critiques" du code dans un langage performant et utiliser python pour faire l'import export de données, etc. On bénéficie alors des avantages des deux approches.
Je te conseille le livre "python scripting for computational science" qui permet de bien comprendre l'intérêt d'utiliser python pour le calcul scientifique. On peut le trouver en PDF sur internet.
Maintenant, pour ce qui est des performances de ce module python en particulier, ça doit dépendre énormément des algorithmes utilisés dans l'application. En effet, il n'y a a priori pas de différence entre un code écrit en C effectuant une multiplication de matrices et un code Python qui appelle une librairie écrite en C pour faire la multiplication des matrices (enfin je crois!).
Effectivement, pour ce genre d'application, on peut dire Matlab/Scilab/Scipy/etc ne sont pas forcément très adaptés.
Je crois qu'un grand sage a dit: " Il ne faut pas utiliser un marteau pilon pour enfoncer un clou, ni un pèse-personne pour peser un éléphant " (ou alors c'est de moi...)
En fait, je crois qu'ils ne réécrive pas Numeric, numarray, numpy tous les deux ans. Par contre, ils n'arrètent pas de changer de nom et ça c'est assez génant je trouve.
En récapitulant doucement, c'est assez simple:
* Numeric : première implémentation performante d'un objet de type array.
* numarray: une autre implémentation d'un array, apparue peu après Numeric.
* NumPy: l'implémentation actuelle d'un array, qui remplace les deux précédentes. Au début, NumPy s'appellait "Scipy core".
* SciPy: un ensemble d'outils pour faire du calcul numérique. Utilise NumPy pour représenter les array.
Je pense qu'ils auraient au moins du garder le nom scipy core, je trouve ça plus explicite.
Pour le stockage en ligne ou colonne, je n'ai pas d'avis, mais il y a peut-être un spécialiste dans la salle?
[^] # Re: visiblement...
Posté par Gilles G. . En réponse au message Chipset son AC97 mort?. Évalué à 2.
Je pensais pas que c'était possible un chipset son qui crame, et je trouve bizarre que des applications freeze à cause d'un chipset son défectueux, c'est pour ça que j'ai fais autant d'essais.
[^] # Re: Pavé dans la marre :)
Posté par Gilles G. . En réponse au journal Pendant que Linux progresse.... Évalué à 4.
Pour la seconde référence, le paragraphe suivant est celui-ci:
Si je comprends bien le fonctionnement de l'API, il faut utliser snd_pcm_mmap_begin() pour savoir où écrire dans mmap. Donc le problème que tu as décrit n'existe pas dans alsa, il s'agit bien d'un problème lié à l'éumlation OSS.
Je trouvais étonnant que les phase de terratec, qui sont recommandées un peu partout sur internet pour le son sous linux ne soient pas supportées en hard...
PS: ce n'est pas moins qui ai moinssé, j'ai trouvé ta remarque très intéressante.
[^] # Re: Pavé dans la marre :)
Posté par Gilles G. . En réponse au journal Pendant que Linux progresse.... Évalué à 3.
Parce qu'une recherche sur google m'indique juste un problème lié à l'émulation oss avec les jeux dérivés de Quake3.
Donc si tu as des liens, ça m'intéresse!
# les perles rares
Posté par Gilles G. . En réponse au message Choisir une carte Wifi (PCMCIA). Évalué à 3.
Par ailleurs, tu peux trouver une liste de carte wifi recommandées par la FSF ici:
http://www.fsf.org/resources/hw/net/wireless/cards.html
Plus généralement, avant d'acheter du matériel, regarde ici:
http://www.fsf.org/resources/hw
J'ai pris de suivre les conseils de la FSF avant d'acheter mon matériel, depuis je n'ai plus de problème.
Comme carte wifi PCMCIA, j'ai pris une MSI que j'ai achetée ici:
http://www.ldlc.com/fiche/PB00022705.html
et ça marche, tout simplement.
PS: certains fabricants prétendent être "compatible linux" de manière très abusive, il y a donc un intérêt à regarder sur le site de la FSF (ati et nvidia par exemple supportent officiellement linux, mais fournissent des drivers binaires tout pourris).
[^] # Re: Et, et, et !
Posté par Gilles G. . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 2.
Vive la France! (<-this is "second degré"...)
[^] # Re: Vu que je peux pas psoter de journal
Posté par Gilles G. . En réponse au journal MediaInfo 0.7.4.0 sous Linux. Évalué à 6.
http://www.lexpress.fr/info/quotidien/actu.asp?id=7373
ou encore
http://www.lemonde.fr/web/article/0,1-0@2-3242,36-838304@51-(...)
et ne pollue pas linuxfr s'il te plait.
Puisque tu parle de racisme, il me semble que c'est bien de cela qu'il est question, mais que c'était plutôt le policier qui était visé par ce racisme.
Pour ce qui se passe à la sortie des boites, je suis bien d'accord avec toi, mais ce n'est pas ce qui s'est passé ici.
Alors réfléchi et informe toi. Cette affaire n'est pas un bon prétexte pour parler de bavure raciste.
[^] # Re: dist-upgrade
Posté par Gilles G. . En réponse au message Catastrophe. Évalué à 2.
Tu voulais sans doute dire, commence par supprimer tout ce qui fait référence à Edgy.
[^] # Re: Et les garçons?
Posté par Gilles G. . En réponse au journal [PUB] les filles, saimal ! dites le en Web 2.0. Évalué à 4.
http://les.garcons.saimal.fr
# Et si on change d'architecture?
Posté par Gilles G. . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 4.
Apparement cette attaque est basée sur une surveillance de l'analyse de branche effectuée par le CPU.
Alors je me demendais si tous les processeurs font de l'analyse de branche (je sais pas, peut-être que les ARM n'en font pas...) ou si le fait d'avoir une architecture matérielle exotique pourrait être une parade acceptable à ce type d'attaque?
Merci de vos éclaircissements.
# L'interview de Ballmer
Posté par Gilles G. . En réponse au journal Pas de trêve. Évalué à 5.
http://blog.seattlepi.nwsource.com/microsoft/archives/108806(...)
Allez la lire, c'est sans appel
Bon ben voilà, Microsoft c'est toujours pas des bisounours. Si je m'écoutais, je dirais facilement que ce sont de lamentables charognes qui puent (hein? mais non je l'ai pas dit.) et vous, vous diriez quoi?
[^] # Re: c'est vrai on est vendredi
Posté par Gilles G. . En réponse au journal LaTEX : un modèle de rapport de stage et écrire en japonais (sous LaTEX). Évalué à 2.
C'est très fiable tant que tu fais toutes tes opérations d'édition avec LyX.
[^] # Re: c'est vrai on est vendredi
Posté par Gilles G. . En réponse au journal LaTEX : un modèle de rapport de stage et écrire en japonais (sous LaTEX). Évalué à 2.
Tu as déjà essayé LyX?
J'avoue que j'étais très sceptique au début, parce que j'avais très peur que ça ressemble à openoffice qui est très lourd (et un troll de plus :-) ).
Mais en fait LyX c'est vraiment léger, plus léger que Kile en tout cas, et puis c'est très rapide aussi. Bref, que du bonheur.
En plus je pense qu'on gagne du temps car on évite une bonne partie des essais erreurs de compilation/erreur qui arrivent forcément quand on utilise LaTeX avec un éditeur de texte.
Enfin, si tu veux vraiment faire du léger, qui se compile très rapidement, je te conseille d'écrire en plain TeX avec vi qui est plus léger que vim.
Bonne chance!
[^] # Re: c'est vrai on est vendredi
Posté par Gilles G. . En réponse au journal LaTEX : un modèle de rapport de stage et écrire en japonais (sous LaTEX). Évalué à 4.
Donc j'utilise LyX qui est très stable et disponible aussi sous windows (pour le boulot).
Pour ceux qui ne connaissent pas, c'est un éditeur WYSIWYM (What You See Is What You Mean), c'est à dire qu'on a pas exactement le rendu latex pendant l'édition, mais la structure du document est tout de même mise graphiquement en évidence lors de l'édition.
C'est très pratique, notamment pour l'écriture de formules mathématiques parce que ça permet de voir directement le résultat sans passer par la phase de compilation.
Donc kile, c'est bien. Mais LyX c'est mieux!! (c'est pour nourrir le troll...)
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
Je pense que ça n'est pas utilisé dans matlab parce que ça change vraiment beaucoup la façon d'écrire les programmes, et puis aussi parce que personne n'en parle.
Dans le même ordre d'idée, matlab devient de plus en plus limité par le fait qu'il est fait pour une programmation procédurale. Il est par conséquent assez difficile de faire des programmes vraiment réutilisables, pourtant, la syntaxe ne change pas...
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 4.
En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
C'est exactement ce que tu viens d'affirmer en disant que j'avais tord.
Alors relis tout, et calme toi.
En attendant, je le dis et je le répete, quand en math tu as une matrice qui s'écrit:
a=[[1 2 3]
[4 5 6]
[7 8 9]]
Alors, en python comme en matlab comme en math (et apparement fortran d'après ce que tu viens de dire), tu as:
a[:,j] : colonne j de la matrice a
a[i,:] : ligne i de la matrice a
Maintenant si tu t'y perd, je ne peut rien pour toi...
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
Pour ce qui est de matlab/octave/scilab, là je suis sur de moi, c'est pareil qu'en python.
Pour les mathématiques, ben je suppose que ça dépend des écoles, mais pendant toute ma scolarité, c'était comme ça aussi.
Il semble donc que le fortran est à contre courant, ce qui confirme sa réputation de langage à la syntaxe pourrie...
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 3.
Je t'arrêtes tout de suite, ce n'est pas de cela qu'il s'agit. En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
Par contre en mémoire, la matrice
[[1, 2, 3]
[4, 5, 6]]
sera stockée ainsi en Fortran/Matlab (stockage colonne):
1-4-2-5-3-6
mais en C/Python, elle sera stockée ainsi (stockage ligne):
1-2-3-4-5-6
Cela a une incidence pour savoir quel indice (de ligne ou colonne) va le plus vite. Je ne sais pas si les performances globales changent.
[^] # Re: zip, sort, unzip
Posté par Gilles G. . En réponse au message Tri dans un dictionnaire de liste. Évalué à 2.
J'aime beaucoup cette solution, je la trouve très élégante. Le seul inconvénient c'est qu'on doit toujours faire appelle à une variable intermédiaire mais tant pis...
Merci à tous!
[^] # Re: beh ca
Posté par Gilles G. . En réponse au message Tri dans un dictionnaire de liste. Évalué à 2.
Je vois que ma question n'était pas si simple. Je verrais ce soir si je peux faire quelque chose dans ce genre.
Si quelqu'un a d'autres idées, je suis preneur.
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 3.
Effectivement, on parlait de Scilab/Matlab/Octave.
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
Ben si, il faut mettre le point après le a sinon on fait une multiplcation matricielle qui s'écrirait avec une boucle:
c=0;
for i =1:length(a)
c = c + a(i)*b(i)
end
Voilà!!
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
Pour les boucles, c'est toujours aussi lent car le code est interprété, et c'est le même problème sous Octave, Scilab, Python, etc.
Pour optimiser les performances, il faut écrire les opérations sous forme matricielle au maximum. C'est une gymnastique un peu difficile au début, mais ça fini par devenir un réflexe.
En gros, il ne faut pas écrire:
for i = 1:length(a)
c(i) = a(i)*b(i);
end
Mais plutôt
c = a.*b
Evidemment, cet exemple est trivial. C'est souvent plus compliqué mais ça s'apprend.
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
En fait je pense que l'avantage avec python c'est qu'on peut faire la transition de manière assez douce.
Je m'explique:
Python s'interface assez facilement avec des librairies écrites en C/C++/Fortran, par conséquent on peut toujours écrire les parties "critiques" du code dans un langage performant et utiliser python pour faire l'import export de données, etc. On bénéficie alors des avantages des deux approches.
Je te conseille le livre "python scripting for computational science" qui permet de bien comprendre l'intérêt d'utiliser python pour le calcul scientifique. On peut le trouver en PDF sur internet.
Maintenant, pour ce qui est des performances de ce module python en particulier, ça doit dépendre énormément des algorithmes utilisés dans l'application. En effet, il n'y a a priori pas de différence entre un code écrit en C effectuant une multiplication de matrices et un code Python qui appelle une librairie écrite en C pour faire la multiplication des matrices (enfin je crois!).
[^] # Re: benchs/ tests
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 1.
Je crois qu'un grand sage a dit: " Il ne faut pas utiliser un marteau pilon pour enfoncer un clou, ni un pèse-personne pour peser un éléphant " (ou alors c'est de moi...)
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
En récapitulant doucement, c'est assez simple:
* Numeric : première implémentation performante d'un objet de type array.
* numarray: une autre implémentation d'un array, apparue peu après Numeric.
* NumPy: l'implémentation actuelle d'un array, qui remplace les deux précédentes. Au début, NumPy s'appellait "Scipy core".
* SciPy: un ensemble d'outils pour faire du calcul numérique. Utilise NumPy pour représenter les array.
Je pense qu'ils auraient au moins du garder le nom scipy core, je trouve ça plus explicite.
Pour le stockage en ligne ou colonne, je n'ai pas d'avis, mais il y a peut-être un spécialiste dans la salle?