[F] [mOved] Mon langage est mieux que le tien - Page 50

Les deux sont plutôt compilant avec les standards, c'est juste que par défaut gcc accepte le K&R alors que clang est en C99.
Si on spécifie a gcc d'utiliser le C99, il aura les même problèmes que clang.

Oh c'est pas de toi ce code Godzil ? Je suis déçu, j'avais commencé à le décortiquer

Non malheureusement il n'est pas de moi
Mais c'est le genre de code que je sais que tu aime

Je l'ai trouvé via la chaine YT computerphile

Intéressant

(il utilise la gamme pentatonique apparemment, ça aide à faire des trucs harmonieux, mais quand même)

Ça me fait penser qu'il faudrait que je poste une ou deux vidéos trouvées sur cette chaîne

Brunni (./1469) :
Le résultat est très joli. Il sonne très faux au début, mais après un petit moment c'est surprenant. Quoi qu'il en soit, je ne vois pas comment ce programme peut compiler, un prototype de main à 3 paramètres… je ne sais pas ce qu'ils sont censés valoir…

http://www.gnu.org/software/libc/manual/html_node/Program-Arguments.html
Si tu lis bien le message d'erreur de Clang, ce n'est que du type des arguments 2 et 3 dont il se plaint, pas du fait qu'il y en a 3.

Merci de l'info

Erf le SPIN est trop lent, meme a 80Mhz pour faire de la musique procedurale
• Godzil va devoir le faire en PASM

\o\ |o| /o/

{{

"One line music" for the Propeller

}}


CON
    _clkmode = xtal1 + pll16x
    _xinfreq = 5_000_000  
    SAMPLE_RATE = 8000

var


PUB main
    start(24,15)

PUB start(left, right)
    sampleRate  := clkFreq / SAMPLE_RATE
    ctrL        := %00110 << 26 + left
    ctrR        := %00110 << 26 + right
    r1          := ((1<<right) | (1<<left))&!1
    cognew(@oneLiner, 0)


DAT org 0
oneLiner
        mov dira, r1
        mov ctra, ctrL
        mov ctrb, ctrR
        mov waitCounter, cnt
        add waitCounter, sampleRate
        mov i, #0
mainLoop
        mov n, i
        shr n, #14
        mov s, i
        shr s, #17

        'Channel 1
        mov x, #1
        mov note, n    
        mov octave,#12
        call #gFunc
        mov c1, r1

        'Channel 2
        mov x, s
        mov note, n
        mov r1, i
        shr r1, #13
        xor note, r1
        mov octave,#10
        call #gFunc
        mov c2, r1
       
        'Channel 3
        mov mx, s
        mov my, #3
        call #divide
        mov x, mx
        and x, mask16

        mov mx, i
        shr mx, #11
        mov my, #3
        call #divide
        mov note, mx
        shr note, #16
        
        add note, n
        call #gFunc
        mov c3, r1
        
        'Channel 4
        mov mx, s
        mov my, #5
        call #divide
        mov x, mx
        and x, mask16
        
        mov mx, i
        shr mx, #10
        mov my, #3
        call #divide
        mov mn, mx
        shr mn, #16
        mov note, #8
        add note, n
        sub note, mn
        mov octave, #9
        call #gFunc
        mov c4, r1
        
        ' mixing
        mov out, c1
        add out, c2
        add out, c3
        add out, c4

        and out, #$FF
        shl out, #24
        waitcnt waitCounter, sampleRate
        mov frqa, out
        mov frqb, out
        add i, #1
        jmp #mainLoop

gFunc
        mov r1, i               ' r1 = i
        shr r1, #16             ' r1 = r1 >> 16
        and r1, #3          WZ  ' r1 = r1 & 3
        mov r2, note            ' r1 = i
        and r2, #7              ' r2 = r2 & 7
        mov r3, #RAMP1
  if_z  mov r3, #RAMP2          ' r3 = *RAMPx
        add r3, r2
        movs rampRd, r3
        add r2, #1
rampRd  mov r1, 0-0              ' r1 = r3


        add r1, #51             ' r1 = r1 + 51
        
        
        ' >> r1 = r1 * i
        mov mx, i
        mov my, r1
multiply
        shl mx, #16
        mov mt, #16
        shr my, #1       WC
:loop 
  if_c  add my, mx       WC
        rcr my, #1       WC
        djnz mt, #:loop
        mov r1, my
        
        shr r1, octave          ' r1 = r1 >> octave
        and r1, x               ' r1 = r1 & x
        and r1, #3              ' r1 = r1 & 3
        shl r1, #4              ' r1 = r1 << 4
gFunc_ret ret



divide  shl my, #15
        mov mt, #16
:loop   cmpsub mx, my   WC
        rcl mx, #1
        djnz mt, #:loop
divide_ret ret

mn          long 0
mx          long 0
mt          long 0
my          long 0

mr          long 0
idx         long 0
n           long 0
s           long 0
x           long 0
note        long 0
octave      long 0
r1          long 0
r2          long 0
r3          long 0
RAMP1       long "B","Y","}","6","Y","B","6","%"
RAMP2       long "Q","j","}","6","j","Q","6","%"
sampleRate  long 0
waitCounter long 0
i           long 0
c1          long 0
c2          long 0
c3          long 0
c4          long 0
out         long 0
ctrL        long 0
ctrR        long 0
mask16      long $FFFF

⇒ 636 octets, et le meme resultat que le code en C #w00t#

(probleme, le Propeller n'a pas d'instruction de multiplication, division ni modulo, donc obligé de faire a la main, et le pire aucun moyen "direct" d'addresser un tableau obligé de faire du SMC )

Le pire c'est que certaines instructions comme MUL sont accepte par l'assembleur parce qu'elle sont "for future revisions" qui n'existeront jamais et le résultat c'est que ton code s'exécute mais fait des choses bizarres.. J'ai passé un certain temps là dessus pour rien...
Enfin le coup de "pas d'adressage indirect" est chiant, même si on peu via des instructions faites pour le SMC
MOVS > Move Source
MOVI > Move Instruction
MOVD > Movz Destination

Une instruction est un mot de 32 bit, la mémoire interne du cog est adressée en mot de 32bit, et les champs source et destination sont commun à toutes les instructions, et ces 3 instructions sont là pour spécialement modifier ces champs dans une instruction à une adresse donnée. Seul probleme le Propeller à un pipeline, petit: une instruction, mais il en a un, donc après du SMC il faut au moins une instruction entre le MOVx et l'instruction modifié pour qu'elle soit correctement lu....
Et pour faire un accès indirect ben pas le choix on faut éditer le champ source ou destination d'une instruction normale.....

Mais c'était fort interessant a faire, le code d'origine est assez tortueux ceci dit, je n'en ai pas encore compris tout le mécanisme, sur la fonction G, je suis sur de "note" et "x", mais ce que j'ai appelé "octave" etait juste un guess a force de tester le bousin, mais j'ai l'impression que c'est un poil plus compliqué que ca..

note n'est pas exactement la note a jouer car suivant l'état de i, la note va etre choisie entre les deux rampes, mais c'est bel et bien le choix de la note.
X est en fait l'element qui va définir la forme d'onde finale, le canal 1 est carré parce que x est toujours égal a 1, mais dans le cadre des 3 autres canaux, c'est un peu plus compilé parce que plus le temps passe plus le canal sera quelque proche d'une dent de scie, en commençant par du carré, et plus le temps passe plus on ajoute des paliers.

Mais octave est utilisé pour diviser la valeur récupéré par la note tiré de la rampe (note multiplié par i au passage... )

En fait fait interessant, le fait de multiplier par i genere un signal en dent de scie qui va etre apres limité par "x" (et 3) et tranformé a un signal carré

C'est simple et super compliqué a la fois


Edit: Correction d'auto carottes

Impressionnant !

Huhu Godzil

Mais c'est aussi une bonne chose parce que j'ai pu m'amuser un peu avec le PASM et le SPIN, et travailler sur l'OricMouse sera un peu plus simple maintenant

Le SPIN est interessant en conception, son seul probleme est son overhead etant donné que c'est un language interprété. Mais maintenant je sais pourquoi ce code etait peine perdu en SPIN, toutes les fonctions mathématiques utilisé (ou presque) sont executé par du code generique car pas d'instruction hardware, donc forcement ca ralentit pas mal les choses.

Un potentiel defaut dans mon implementation, comme I augmente tout le temps, au bon d'un certains temps on fini par faire un mod ou une division avec un valeur de I tres grande, et la boucle, meme si optimisé, va tourner plus longtemps, donc, plus I augment, plus le temps d'execusion d'une boucle sera long.

Mais maintenant que j'ai fait ca, je vais pouvoir faire mon emulateur du soundchip de la NES

http://blog.thezerobit.com/2014/05/25/python-3-is-killing-python.html
Un petit troll pythonesque, exprès pour Flan.

Ah, le bon vieux troll de la communauté Python ^^

Je n'ai pas *du tout* la même opinion.
D'abord, est-ce que Python est en train de mourir ? Quand on le compare à PHP ou Perl, pas franchement.
(je sais, TIOBE n'est pas terrible, mais je n'ai pas mieux)

Ensuite, Python 2 souffrait de graves erreurs de conception (la confusion entre unicode et str, notamment), qu'on ne pouvait pas résoudre sans casser la compatibilité.
Avec la même rigueur d'écriture, un code Python 3 sera moins buggué que le code Python 2 correspondant (à cause de cette énorme connerie).
Soit on passait à un nouveau langage, soit on cassait pour une fois la compatibilité, soit on conservait ces erreurs fondamentales.
À cause de ça, oui, passer un code Python 2 à Python 3 est (parfois) compliqué, justement à cause de cette confusion (et qu'en pratique, la migration corrige plein de bugs au passage).

Est-ce vraiment compliqué de passer à Python 3 ?
Par expérience, non, contrairement à ce qu'il dit, c'est facile, sachant qu'on a plein de solutions :

* écrire du code Python 2, avec 2to3 qui le convertit en Python 3,
* écrire du code Python 3, avec 3to2 qui le convertit en Python 2,
* écrire du code mixte soi-même (ça, c'est chiant),
* utiliser __futures__ qui modifie localement la grammaire de Python 2 (pour la rendre compatible avec Python 3) : on a donc un fichier écrit en pur Python 3 qui fonctionne indifféremment avec Python 2 et 3(*),
* utiliser des libs de backport en Python 2 pour certaines nouvelles libs de Python 3,
* écrire du code mixte avec une lib d'assistance (six, par exemple) pour les libs qui ont été renommées.

On peut donc migrer progressivement un code Python 2 en 3, fichier par fichier, alors que l'ensemble continue à fonctionner en Python 2.
Ça explique la lenteur de la migration, mais au moins Python n'en est pas mort.

Depuis un an environ, on passe enfin massivement à Python 3, avec un phénomène de sélection naturelle.
On se retrouve avec un langage ET un écosystème complet, mûr (packaging, déploiement, libs, tests, documentation, …) débarassé des vieux projets abandonnés.
La communauté a également beaucoup évolué, et quasiment tous les projets que je regarde sont franchement propres :

* packagés correctement et uploadés sur Pypi,
* installables via pip (packageables très facilement en rpm ou deb),
* code sur Github,
* docs générées par Sphinx et uploadées automatiquement sur ReadTheDocs,
* code respectant la PEP008 (la norme décrivant le style officiel),
* tests unitaires sur TravisCL.


Si on regarde P3 WoS (qui donne la compatibilité des lib Python les plus courantes), on voit qu'elles sont quasiment toutes compatibles Python 3, sauf

* des projets indépendants (genre Supervisor : on s'en fout qu'il soit Python 2, 3 ou écrit en C ou en Go),
* des projets morts en terme d'évolutions ou de communauté (Fabric, totalement dépassé par Ansible) et avec un équivalent moderne,
* des projets dont une version Python 3 existe (python-openid).


Oui, la transition a été (très) longue, mais c'était volontaire (le but était de faire évoluer Python 3 lentement au début en développant Python 2 en parallèle, pour éviter les erreurs de conception) et au moins ça n'a pas complètement tué Python (cf. Perl 6 : le projet est mort-né).

Bon, sinon, sa conclusion est la pire des solutions : personne ayant fait du Python 3 n'accepterait de refaire du Python 2 (avec tous les bugs qui viennent avec automatiquement). Oui, Python 2 est mort, ça n'empêche pas les projets existants de continuer à vivre)

(*) par exemple, en Python 2 print est un opérateur (print "toto"), les chaînes unicodes s'écrivent u"string" et les chaînes binaires s'écrivent "bytes";
En Python 3, print est une fonction (print("toto")), les chaînes de texte s'écrivent "string" et les chaînes binaires s'écrivent b"bytes".
Si au début de son fichier Python, on fait "from __futures__ import *", on peut utiliser la syntaxe Python 3 en exécutant Python 2 (dans ce fichier uniquement, les autres ne sont pas affectés).

Intéressant, merci pour l'explication

flanker (./1486) :
* des projets morts en terme d'évolutions ou de communauté (Fabric, totalement dépassé par Ansible) et avec un équivalent moderne,

Mais Ansible reste lui aussi bloqué à l'âge de pierre de Python 2.

on s'en fout à 99% : Ansible pourrait très bien être en Ruby ou en C que ce serait à peu près la même chose.
Quand tu utilises Fabric, tu fais du Python. Quand tu utilises Ansible, tu fais du YAML sans faire de Python.

Moui, c'est quand même quelque chose que je prends en compte personnellement. Ansible commence à avoir une base de code conséquente, mais il lui manque également plein de features fortement réclamées par ses utilisateurs. Quand l'évolution de Python 2 s'arrêtera ils finiront par devoir migrer vers Python 3, ce qui gèlera probablement le projet pour un moment. J'y aurais réfléchi à deux fois si j'avais basé quoi que ce soit sur une solution en Silverlight il y a quelques années, et ce de façon totalement indépendante que je sois moi-même obligé de faire du Silverlight ou pas, aujourd'hui pour moi c'est un peu la même chose avec Python 2.

L'évolution de Python 2 est *déjà* arrêtée. Il n'y aura jamais de Python 2.8, et ça se sait depuis déjà longtemps.

Je ne vois pas pourquoi le code serait gelé, Django a également une base de code conséquente (avec beaucoup de code tierce-partie), et son passage à Python 3 s'est très bien fait, sans que le projet n'ait été gelé. Le code aura été compatible 2&3 pendant pas mal d'années, au final.
D'ailleurs, Ansible accepte maintenant les patchs qui rendent le code compatible Python 2.6, 2.7 et 3.4.
Le code extérieur est généralement un code simple (comme les filtres perso), qui est facile à rendre compatible 2 & 3 (c'est d'ailleurs ce que je fais). Maintenant, c'est vrai qu'ils pourraient bosser dessus, mais c'est leur choix politique de ne pas travailler dans cette direction (que je trouve un peu curieux en 2016 de préférer Python 2.4 à Python 3.4 sachant que la 2.5 est sortie en 2006, mais bon…).

Je reconnais que c'est gênant, mais la gêne n'était pas suffisante pour que je me tourne vers une autre techno : de toute façon il n'y a pas de concurrent en Python 3 (salt ne l'est pas non plus).

Ils refusent d'abandonner Python 2.4 parce que c'est le Python par défaut de RHEL 5, qui est supporté jusqu'au 31 mars 2017, voire 30 novembre 2020 pour les clients qui ont acheté le support prolongé.

flanker (./1491) :
Le code aura été compatible 2&3 pendant pas mal d'années, au final.

Ça n'est pas vraiment pour me rassurer, quand il s'agit justement d'un projet qui a tout juste commencé sa migration

flanker (./1491) :
Je reconnais que c'est gênant, mais la gêne n'était pas suffisante pour que je me tourne vers une autre techno : de toute façon il n'y a pas de concurrent en Python 3

Oui, c'est pour ça que j'utilise Ansible malgré tout. Mais au-delà de ce cas particulier je rebondissais surtout sur le fait qu'être en Python 2, pour un projet connu et duquel j'attends encore beaucoup d'évolutions, est un désavantage dont je ne me "fous pas à 99%" ^^

Zeph (./1493) :

flanker (./1491) :
Le code aura été compatible 2&3 pendant pas mal d'années, au final.

Ça n'est pas vraiment pour me rassurer, quand il s'agit justement d'un projet qui a tout juste commencé sa migration

Comment ça ?
J'ai dû mal m'exprimer : Django a été compatible Python 3 en à peu près un an de mémoire, mais il reste compatible Python 2 pour les sites qui n'ont pas été migrés.

flanker (./1491) :
Je reconnais que c'est gênant, mais la gêne n'était pas suffisante pour que je me tourne vers une autre techno : de toute façon il n'y a pas de concurrent en Python 3

Oui, c'est pour ça que j'utilise Ansible malgré tout. Mais au-delà de ce cas particulier je rebondissais surtout sur le fait qu'être en Python 2, pour un projet connu et duquel j'attends encore beaucoup d'évolutions, est un désavantage dont je ne me "fous pas à 99%" ^^

Je ne pense pas qu'une migration vers Python 3 oblige à bloquer l'évolution, c'est pour ça que ça ne me fait pas trop peur. Mes propres plugins sont écrits de façon à être compatibles, donc pour moi une migration sera transparente.
Par contre, je reste persuadé que ne pas prévoir cet aspect a été une grosse erreur dans la mesure où en 2012 Python 3 existait déjà depuis longtemps et on savait que Python 2 était mort. Ils auraient dû écrire un code compatible 2/3 dès le début.

C'est vrai que ca a été un peu galere au début la transition Python2 => Python3, Gentoo a été pas mal impacté par cette migration vu que portage est principalement ecrit en Python. Il est resté longtemps compatible python2 uniquement, mais quand ils ont fait l'effort de mettre a jour ca c'est passé en douceur

(je ne sais plus si je l'ai pas déjà posté)

Si vous trouvez que votre projet informatique est catastrophique, voilà qui devrait vous redonner le moral :
https://projectfailures.wordpress.com/2008/06/24/project-from-hell/
http://brucefwebster.com/2008/06/16/anatomy-of-a-runaway-it-project/

Ah ouais, mais pal quand-même

Zerosquare (./1496) :
https://projectfailures.wordpress.com/2008/06/24/project-from-hell/

WTF?! D'ailleurs, à un moment, l'auteur critique le C++, mais le C++ n'est pas du tout le problème dans ce projet, il y a plein d'autres trucs qui ne vont pas et qui n'ont rien à voir avec le C++! La conception est totalement foireuse dans tous les sens!

Déjà citer http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm (un hoax) comme preuve...

Ce n'est pas cité en tant que preuve, mais que tant que parodie, justement. Et ce n'est pas vraiment un hoax (c'est trop gros pour être crédible) : sous forme humoristique, ça reprend des critiques récurrentes sur le C++.

Et même si le C++ en soi n'est pas mauvais, c'est un langage connu pour être "dangereux" entre des mains inexpérimentées.