#20922 - Dwitter - JavaScript demos in 140 characters
Des démos en 140 caractères de JS.
Y a des jolis trucs, principalement dans des HTML Canvas.
Des démos en 140 caractères de JS.
Y a des jolis trucs, principalement dans des HTML Canvas.
(Pardon, oui je partage un peu mes trouvailles et réflexions ici)
Donc quand on produit deux sons et qu’on les somme, le son est absolument horrible. C’est parce que les deux sons sont par défaut avec un gain de 100 %. Si on les somme, ça peut produire des moments où le gain est de 200 % (le son sature), qui est alors tronqué à 100 % et d’une sinusoïde bien pure on passe pratiquement à un signal carré (qui est horrible).
Solution : mettre les deux sont à 50 % de gain. Le total ne dépassera pas 100 % et on a un joli son.
Ceci va me servir pour mon générateur de tonalités DTMF (outil qui ne sert à rien en soi, on est d’accord).
Je veux ajouter les sons à mon outil pour le morse.
Plutôt que de jongler avec une série de fichiers MP3 ou OGG, je vais utiliser l’API audio JS.
On peut générer des fréquences, des gains, etc. et moduler ça avec un timer.
De l’audio procédurale dans le navigateur.
On pourrait même faire un piano dans une page web. Je vais regarder tout ça.
J’avais déjà gratté cette API quand j’avais fait mon spectrogramme en JS. On ouvrait un MP3, l’API nous sortait les fréquences jouées et à quelle amplitude (une simple analyse FFT), et il ne restait plus qu’à utiliser l’API canvas pour dessiner tout ça : https://lehollandaisvolant.net/tout/tools/spectrum/spectrograph.php
Je manque de temps pour tout étudier autant en profondeur que je le voudrais :'(
If the computer knows I’m missing a semi-colon here, why won’t it add it itself
De même, dans un terminal (je ne sais plus lequel, peut-être Python) tu as le message quand on tape « quit » : « “quit” n’est pas la bonne commande : utilisez “exit” à la place ». En gros l’ordinateur a très bien compris ce qu’on voulait faire, mais refuse de le faire si on ne lui demande pas poliment.
Le site de MDN (mozilla developper network, le wikipédia du webdév) change de look :)
lol^^
Une minuscule lib de coloration syntaxique (2.2 kio).
Sa particularité est de ne pas recourir aux couleurs pour rendre le code plus lisible, mais sur l’intensité des ombres et l’opacité. Ça fonctionne avec tous les langages.
Peut-être pas le plus lisible de toutes (loin de là), mais de très loin la plus légère. Les autres sont au minimum 100 ko si l’on veut supporter un paquet de langages.
#Édit : ce n’est pas parfait, mais ça rend du code nettement plus lisible que juste du blanc.
En jouant un peu le code, j’arrive à revenir à des couleurs et ça me fait une lib de coloration syntaxique en 2 ko.
On y revient.
Je pense qu’on devrait ajouter une clause aux petites lib comme ça similaire à la clause « NC » des licences CC.
À savoir aussi que n’importe qui peut aussi demander une licence spécifique à un dév.
Ça m’est déjà arrivé de contacter un dév pour lui demander d’utiliser son code qui n’était, à la base, pas libre). Je mets alors généralement « ressource de Untel, utilisé avec accord de l’auteur ».
Pour du code, ça permet deux choses, si c’est respecté :
— si le dév voit que c’est une grosse boîte qui demande, il peut exiger une contrepartie ;
— si le dév voir qu’une grosse boîte utilise sa lib, il peut engager des poursuites
Après, je vois bien certaines grosses boîtes utiliser le code sans en avoir le droit, puis aller réclamer un support en cas de grosse faille. Ça serait vraiment con, mais fort probable que ça arrive xD
Vous jouez à Wordle / Sutom ? Vous ne connaissez pas tous les mots en français ?
Je vous ait fait un z'outil (pas encore terminé) !.
Exemple, si le mot est « R . . . . . .S », tapez « R......S » et il vous sort tous les mots possibles (c’est en regex, donc le joker c’est le point).
Dans l’outil, le début est fixe (le « ^ » est implicite) mais pas la fin (le « $ » peut être rajouté à votre texte). En vrai il faut donc mettre «R......S$ ».
Le dictionnaire de mots utilisé fait 336 411 mots (y a les singuliers, les pluriels, les conjugaisons…) et pèse un peu. Attendez que le chargement se finisse avant de lancer la recherche.
Pour les plus férus, vous pouvez créer et taper la régex parfaite qui permettra à partir des lettres bonnes (en rouge) et les lettres déplacées (en jaune) =) de filtrer suffisamment pour réduire la recherche à tout juste quelques mots.
Il ne resterait plus qu’à utiliser le dictionnaire interne de Sutom et à faire un script qui analyse et automatise la résolution du jeu :-D.
Après tout, c’est de la pure logique, ça doit pouvoir se faire. On fait bien des solveurs de Sudoku ou de Rubik's-Cube.
En dehors de ça, cet outil peut aussi servir pour les mots croisés (toujours en exploitant la puissance des régex pour filtrer au nombre de lettres (avec « .{5}$ » par exemple).
(PS : ceux qui pensent que c’est de la triche, c’est votre droit, mais ne vous fatiguez pas : si vous n’êtes pas programmeur, vous ne comprendriez pas le fun de faire un script qui fait tout à votre place, y compris répondre une fois par jour à un jeu gratuit où y a rien à gagner ou à perdre :p)
J’aime ce genre d’article où on montrer itérrativement comment résoudre un problème de prog, et comment on arrive à passer d’une solution qui fonctionne mais qui est un peu lente (8 secondes) à une solution faisant appel à quelques astuces logiques (issues de l’intelligence humaine, impossible à deviner pour un script comme ça) pour le réduire à 0,7 secondes (le nombre de calculs passe lui de 8,9 millions à 1 200). Magnifique.
As so often when debugging something that doesn't make sense, we need to determine if what we're looking at is actually what we think we're looking at. We wrote some code, and we run an executable, but who's to say that the executable uses the exact instructions we wrote into the code?
C is not an interpreted language, but a compiled language, meaning we use a tool -- a compiler -- to translate our high-level code into machine instructions. And if you remember the various stages of a compiler, you'll note that one of them includes code optimization. So let's take a look at what exactly our compiler produces:
Parfois, les compilateurs remplacent certaines fonctions que vous écrivez par d’autres qu’ils jugent plus appropriées. Et ça peut provoquer des désagréments. Ici, printf() retourne la longueur de la chaîne affichée. Mais le compilateur peut le remplacer par une fonction qui retourne autre chose (ici, puts(), qui retourne un code, pas la longueur de la chaîne passée en paramètres).
Un script JS pour uploader des fichiers ET des répertoires.
Ça marche dans Firefox et dans Chrome.
Alors que généralement, cette fonction est décrite comme ne fonctionnant pas dans Firefox.
En vrai, Firefox supporte une fonction de Webkit ici, mais elle le supporte depuis 2016 (la fonction — expérimentale et préfixée — existe elle depuis 2012, mais est utilisée partout), et autant de temps qu’on a droit à ce genre de bullshit :
https://twitter.com/lehollandaisv/status/1447595435233882114
Déjà connu depuis longtemps sur les sites de Google (qui ont tout intérêt à descendre la concurrence), voir là :
https://lehollandaisvolant.net/?d=2016/01/03/16/30/39-youtube-lent-en-html5-avec-firefox-42
… et sur les sites codés avec des moufles sur chaque main :
https://lehollandaisvolant.net/?d=2017/07/03/20/33/52-ce-site-nest-fait-que-pour-chrome-bla-bla-blah
#ChromeIsTheNewIE
C’est un truc de fou quand-même.
Imaginons de faire un tableau avec des nombres aléatoires dedans :
while (howmany != 0) {
out[index] = random();
index += 1;
hownany--;
}
Ceci, coûte environ 3 cycles CPU par itération.
Maintenant, disons que l’on veuille mettre des nombres aléatoires, mais seulement paires :
while (howmany != 0) {
var = random();
if (val is odd) {
out[index] = val;
index += 1;
}
hownany--;
}
Comme il dit, on pourrait penser que c’est aussi rapide (le test de parité se fait en regardant seulement le bit de poids faible), voire plus rapide car le tableau de sortie est en moyenne moitié moins gros.
En réalité, c’est 5 fois plus lent à 15 cycles CPU par ittération !
Ceci est plus rapide :
while (howmany != 0) {
val = random();
out[index] = val;
index += (val bitand 1);
howmany--;
}
Ça fait la même chose : l’index est incrémenté par le bit de poids faible (BPF) du nombre créé. Autrement dit, si le nombre est pair, le BPF est 1, donc l’index est incrémenté, et au prochain tour de boucle, on passe à l’index suivant du tableau.
Si le nombre est impaire, le BPF est 0, et le nombre sera écrasé dans le tour de boucle suivant.
Ici, on trouve la vitesse de la méthode initiale, à environ 4 cycle CPU par tour de boucle.
Pourquoi ?
Parce que les CPU modernes font du calcul prédictif. Ils essayent de gagner de temps en calculant un résultat futur.
Si la prédiction est bonne, on aura gagné du temps : le calcul est déjà fait.
Mais s’il est faux, on aura calculé pour rien ET on devra faire le calcul réel. On aura donc perdu davantage de temps à essayer d’en gagner, que ce qu’on on aurait perdu à ne pas vouloir en gagner. Si les CPU intègrent ça, c’est que le gain est globalement plus important que la perte dans la majorité des cas.
Dans notre exemple, lors de la seconde méthode avec un if, la méthode change à chaque tour de boucle. Autrement dit, tout le travail de prédiction ne sert systématiquement à rien et le CPU perd du temps à jeter la prédiction et à en recalculer une autre, qui sera à son tour jetée au tour suivant… à chaque fois !
Le calcul prédictif est là, mais il n’est pas encore assez évolué pour reconnaître le patern qu’on fait ici (c’est du très bas niveau ici, et on est encore loin d’une IA intégrée dans les CPU).
C’est pour ça que le dernier bout de code est plus rapide : la logique utilisée est la même à chaque tour de boucle. Il n’y a pas "if", le calcul est toujours le même.
On réalise ceci en limitant le nombre de niveaux d’embranchement dans le code (moins de IF). Il est préférable de faire plus de calculs sans branches que moins de calculs avec des branches.
Je ne sais pas trop dans quelles mesures tout ceci peut s’appliquer à du calcul de haut niveau (affichage d’une page web, par exemple et dans mon cas), je pense que ça reste limité, hormis pour les très grosses quantité de JSON ou les gros travaux sur le DOM, mais pour du calcul plus compliqué, comme le calcul 3D d’un jeu vidéo, ça doit jouer énormément.
Dans une certaine mesure, il ne m’étonnerait pas que certains vieux jeux tournent plus rapidement sur des CPU/GPU qui leur seraient contemporains que sur des systèmes modernes, qui perdraient alors plus de temps à vouloir en gagner. Dans les faits, le gain de la vitesse pure des CPU modernes sera toujours là, mais si ça arrive, faudra pas s’étonner je pense.
Juste pour le titre : « How to deal with bugs in an agile setting ».
Je ne sais même pas pourquoi je m’attendais à une astuce style kung-fu pour gérer les moustiques… Car non c’est pas ça :(.