Quand tu génères du JavaScript, derrière il y a plusieurs implémentations de l'interpréteur (au moins une par navigateur - WebKit en a plusieurs et passe de l'une à l'autre à la volée pour chaque fonction, selon plusieurs critères). Elles sont parfois très différentes. Du coup, le principe est plutôt de laisser le runtime faire l'optimisation.
On a un peu la même philosophie quand on génère du bytecode Java: le bytecode standard est pas du tout optimal, en fait il est plutôt éloigné de ce que les machines virtuelles font vraiement. Mais, chaque machine virtuelle vient avec une "surcouche" qui s'occupe de faire l'optimisation qui va bien.
Cela a un inconvénient: il faut faire cette phase d'optimisation au runtime alors qu'elle aurait pu être faite une fois pour toute à la compilation. Mais ça a un gros avantage: ton code "objet" (bytecode java ou code js généré) sera optimisé pour la machine virtuelle qui l'exécute, même si elle n'existe pas encore lorsque tu écris le code.
Du coup, il n'est pas nécessaire et parfois même contre-productif de "pré-optimiser" le code js. Tu ne sais pas quelle machine virtuelle va l'interpréter, de toutes façons.
gcc arrive très bien à conserver les commentaires C (et même, ajouter les lignes du fichier C en commentaire) dans les fichiers assembleur qu'il génère. D'ailleurs, c'est indispensable qu'il sache faire ça car c'est aussi utilisé pour générer les informations de debug, qui permettent à un debugger de savoir quelle ligne du fichier C est en train de s'exécuter.
Encore plus fort: quand on génère du C, on peut ajouter des directives #line et #file, et du coup, annoter que le fichier est généré à partir d'un autre. Et cela sera aussi intégré et le debugger pourra afficher où on est dans le fichier source qui a servi à la génération.
Si Grumpy (et les autres transpileurs ) ne sait pas faire ça, alors comment on fait pour debugger? Obligé de regarder le code généré qui n'a pas de commentaires, et retrouver l'équivalent dans le fichier Python à la main? ça me semble être la moindre des choses, quand même?
Tiens, je pense à un truc: les Grands Anciens de l'Informatique ont inventé ASN.1 et PER, qui permettent de décrire le contenu du message. Il existe des outils qui peuvent non seulement générer les fichiers binaires, mais aussi le code (C, Python, …) pour encoder et décoder un message depuis/vers une structure ou un objet du langage.
1) Faire tourner l'application existante en la convertissant en Go
2) Commencer à réécrire certains morceaux en Go pour migrer petit à petit
3) à la fin, tout le code est réécrit en Go.
C'était le cas jusqu'à maintenant. Ils ont prévenus Lilypond que c'étaient les derniers à utiliser Guile 1.8 lors de la release précédente et avaient déjà conservé ce paquet pas maintenu rien que pour eux. Entretemps, le problème n'est toujours pas réglé.
Si la migration n'est vraiment pas possible, il aurait fallu que Lilypond (ou quelqu'un d'autre) forke Guile 1.8 et prenne en charge la maintenance. Personne chez Debian n'ayant envie de le faire.
J'avais lu un blog plus détaillé (les infos sont peut être dans le rapport complet du deuxième lien). Mais en gros, en dehors du record, on voit surtout un décalage de 7° qui apparaît "d'un coup", dont on ne se rend compte qu'en comparant à d'autres stations proches et en faisant quelques statistiques.
Il a fallu remonter aux relevés papier originaux pour voir que l'écriture change juste à ce moment là. Et la conclusion: la station n'était plus opérée par la même personne, et visiblement, le nouveau responsable ne savait pas utiliser un thermomètre à maxima correctement: il a lu la température en haut du marqueur, et pas en bas.
Ce genre d'erreur peut donc apparaître et disparaître avec le temps, en fonction du matériel, des gens (ou des machines) qui font les relevés, etc. La cohérence d'une série avec elle-même n'est donc pas complètement assurée et personne ne pense à prendre note de ces changements. Du coup les données sont difficiles à interpréter.
Personnellement, j'aurais plus confiance dans une machine (conçue correctement: plusieurs mesures indépendantes, un système qui les compares pour éliminer celles qui sont trop à côté de la plaque par rapport aux autres, et un système d'alerte pour quand la machine n'arrive plus à décider: problème matériel probable), que dans un humain. Mais j'aurais moins confiance dans une machine mal pensée et sans surveillance.
Donc, je ne vois pas de problème avec l'automatisation. Mais j'en vois avec le manque de contrôle. Ensuite, le contrôle peut lui-même être automatisé, et ça récurse!
Ben euh, le DNS a déjà plusieurs niveaux. Tu proposes quoi? machin.com.racine1 et machin.com.racine2? mais du coup, ce ne sont plus des racines, juste des branches de l'arbre des DNS…
On devrait pouvoir se contenter des TLDs existants (surtout qu'il y en a plein maintenant), et les gens peuvent faire ce qu'ils veulent en-dessous de leur propre domaine (truc.machin.com, bidule.machin.com, et ainsi de suite). Avoir plusieurs racines ne sert donc pas à grand chose.
On a besoin de ce genre de trucs dans mon travail. La solution retenue: on met un noyau Linux récent, avec la distro du choix du développeur, et les outils qui ont besoin de "vieux trucs" (des libs, mais aussi des versions spécifiques de perl ou de GNU make par exemple) tournent dans un chroot construit à partir d'un Debian de l'époque.
Le noyau Linux faisant très attention à ne pas casser son interface au niveau des syscalls, ça marche très bien, et cela n'a qu'un faible impact sur les performances (pas besoin de sortir une VM). On peut même utiliser le serveur X principal, avec donc les derniers drivers graphiques et l'accélération qui va bien (quelqu'un sait si ça peut fonctionner avec Wayland?)
Essayons d'être constructif: as-tu un meilleur terme à proposer? On peut parler "d'informatique en nuage", par exemple.
Quand aux titres de films, on est juste habitués à se dire qu'en anglais, ça claque plus. Mais en fait non: les titres anglais sont déjà nazes, c'est juste qu'on s'en rend moins compte quand on comprend pas bien l'anglais.
Ce n'est pas indiqué, et je ne sais pas si on peut commander en ligne.
C'est du PCB simple comme ceux qu'on peut faire à la maison: PCB + pistes + étamage. Pas de silkscreen et pas de vernis, et perçage à la main (pas de vias). Mais on peut commander un seul exemplaire et être livré en moins d'une semaine.
C'est pas pour les mêmes besoins que ce que fait oshpark, mais pour des projets simples, c'est déjà très bien et moi ça m'a permis d'avancer pas mal en électronique sans avoir besoin de graver des circuits chez moi (ou chez mes parents, à l'époque).
The minimum allowed stack size for secondary threads is 16 KB and the stack size must be a multiple of 4 KB. The space for this memory is set aside in your process space at thread creation time, but the actual pages associated with that memory are not created until they are needed.
Par contre (et en fait, c'est logique), il y a quand même une limite qui est qu'on finit forcément par atteindre l'adresse logique d'une autre allocation. Donc la stack n'est pas illimitée pour autant. Par défaut la limite est de 1MB pour le thread principal et de 512K pour les autres.
Il est aussi possible d'allouer la pile de façon dynamique: on mappe 4Ko au départ, et juste au-dessus, une page interdite d'accès pour le thread en question. Quand le thread utilise ses 4Ko, il finit par essayer d'écrire dans ce bloc protégé. Cela déclenche une exception (segmentation fault) qui est interceptée, le noyau peut alors ajouter 4Ko de mémoire supplémentaire, et ainsi de suite.
Il me semble que cette stratégie est utilisé par iOS, entre autres.
Ou bien trouver une boutique située en France qui propose de le faire.
Par exemple si vous êtes à Pau, c'est possible chez Distronic (http://www.distronic.fr/) et ça prend largement moins de 2 semaines. J'espère que ce n'est pas la seule/dernière boutique en France à proposer ça.
[^] # Re: La tablette : l'avers des services privateurs
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tablette 2017. Évalué à 3.
Il te faut un frogpad pour taper avec une main tout en tenant la tablette dans l'autre: http://www.frogpad.com
[^] # Re: logique pour Google
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 4.
Quand tu génères du JavaScript, derrière il y a plusieurs implémentations de l'interpréteur (au moins une par navigateur - WebKit en a plusieurs et passe de l'une à l'autre à la volée pour chaque fonction, selon plusieurs critères). Elles sont parfois très différentes. Du coup, le principe est plutôt de laisser le runtime faire l'optimisation.
On a un peu la même philosophie quand on génère du bytecode Java: le bytecode standard est pas du tout optimal, en fait il est plutôt éloigné de ce que les machines virtuelles font vraiement. Mais, chaque machine virtuelle vient avec une "surcouche" qui s'occupe de faire l'optimisation qui va bien.
Cela a un inconvénient: il faut faire cette phase d'optimisation au runtime alors qu'elle aurait pu être faite une fois pour toute à la compilation. Mais ça a un gros avantage: ton code "objet" (bytecode java ou code js généré) sera optimisé pour la machine virtuelle qui l'exécute, même si elle n'existe pas encore lorsque tu écris le code.
Du coup, il n'est pas nécessaire et parfois même contre-productif de "pré-optimiser" le code js. Tu ne sais pas quelle machine virtuelle va l'interpréter, de toutes façons.
[^] # Re: L'annonce
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 2.
Parfois il vaut mieux une bibliothèque Python bien optimisée, plutôt qu'un code C écrit à la main. Un exemple qui me revient: https://www.tablix.org/~avian/blog/archives/2016/04/measuring_interrupt_response_times/
(et dans lequel, finalement, il vaut mieux un driver dans le noyau, mais c'est une autre histoire).
[^] # Re: logique pour Google
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 10.
gcc arrive très bien à conserver les commentaires C (et même, ajouter les lignes du fichier C en commentaire) dans les fichiers assembleur qu'il génère. D'ailleurs, c'est indispensable qu'il sache faire ça car c'est aussi utilisé pour générer les informations de debug, qui permettent à un debugger de savoir quelle ligne du fichier C est en train de s'exécuter.
Encore plus fort: quand on génère du C, on peut ajouter des directives #line et #file, et du coup, annoter que le fichier est généré à partir d'un autre. Et cela sera aussi intégré et le debugger pourra afficher où on est dans le fichier source qui a servi à la génération.
Si Grumpy (et les autres transpileurs ) ne sait pas faire ça, alors comment on fait pour debugger? Obligé de regarder le code généré qui n'a pas de commentaires, et retrouver l'équivalent dans le fichier Python à la main? ça me semble être la moindre des choses, quand même?
# ASN.1 et PER
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal BinMake : pour construire un fichier binaire décrit en texte. Évalué à 7.
Tiens, je pense à un truc: les Grands Anciens de l'Informatique ont inventé ASN.1 et PER, qui permettent de décrire le contenu du message. Il existe des outils qui peuvent non seulement générer les fichiers binaires, mais aussi le code (C, Python, …) pour encoder et décoder un message depuis/vers une structure ou un objet du langage.
# Taille des entiers décimaux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal BinMake : pour construire un fichier binaire décrit en texte. Évalué à 7.
Dans ton exemple, tu rentre "0123" mais le résultat est sur un seul octet. Comment fait-on pour encoder 123 (décimal) sur 2 octets ou 4 octets?
[^] # Re: Du Python au goroutines
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 4.
Si j'ai bien compris, le but c'est:
1) Faire tourner l'application existante en la convertissant en Go
2) Commencer à réécrire certains morceaux en Go pour migrer petit à petit
3) à la fin, tout le code est réécrit en Go.
[^] # Re: Logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal LilyPond ne sera pas dans Debian Stretch. Évalué à 6.
C'était le cas jusqu'à maintenant. Ils ont prévenus Lilypond que c'étaient les derniers à utiliser Guile 1.8 lors de la release précédente et avaient déjà conservé ce paquet pas maintenu rien que pour eux. Entretemps, le problème n'est toujours pas réglé.
Si la migration n'est vraiment pas possible, il aurait fallu que Lilypond (ou quelqu'un d'autre) forke Guile 1.8 et prenne en charge la maintenance. Personne chez Debian n'ayant envie de le faire.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
J'avais lu un blog plus détaillé (les infos sont peut être dans le rapport complet du deuxième lien). Mais en gros, en dehors du record, on voit surtout un décalage de 7° qui apparaît "d'un coup", dont on ne se rend compte qu'en comparant à d'autres stations proches et en faisant quelques statistiques.
Il a fallu remonter aux relevés papier originaux pour voir que l'écriture change juste à ce moment là. Et la conclusion: la station n'était plus opérée par la même personne, et visiblement, le nouveau responsable ne savait pas utiliser un thermomètre à maxima correctement: il a lu la température en haut du marqueur, et pas en bas.
Ce genre d'erreur peut donc apparaître et disparaître avec le temps, en fonction du matériel, des gens (ou des machines) qui font les relevés, etc. La cohérence d'une série avec elle-même n'est donc pas complètement assurée et personne ne pense à prendre note de ces changements. Du coup les données sont difficiles à interpréter.
Personnellement, j'aurais plus confiance dans une machine (conçue correctement: plusieurs mesures indépendantes, un système qui les compares pour éliminer celles qui sont trop à côté de la plaque par rapport aux autres, et un système d'alerte pour quand la machine n'arrive plus à décider: problème matériel probable), que dans un humain. Mais j'aurais moins confiance dans une machine mal pensée et sans surveillance.
Donc, je ne vois pas de problème avec l'automatisation. Mais j'en vois avec le manque de contrôle. Ensuite, le contrôle peut lui-même être automatisé, et ça récurse!
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
Il y a des cas d'erreurs humaines dans des stations météo, aussi.
Ce que tu dit me semble justifié, mais complètement indépendant de l'automatisation.
Exemple:
http://www.notre-planete.info/actualites/actu_3465_temperature_plus_haute_Terre.php
http://journals.ametsoc.org/doi/abs/10.1175/BAMS-D-12-00093.1
[^] # Re: Proposer un travail aux personnes qu'elle va remplacer ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 2.
ça marche aussi avec "les reptiliens", "l'union européenne", et "le concentré de tomate".
…ah non, en fait ça marche pas avec le concentré de tomates. Bizarre.
[^] # Re: Format JPEG 2000
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Quel format d'image pour les dépêches et journaux ?. Évalué à 2. Dernière modification le 06 janvier 2017 à 17:18.
Il faut attendre 4 ans de plus pour être sûr que les brevets ont expiré, non? Ensuite on pourra commencer à l'implémenter sans danger…
[^] # Re: Un résolveur à la maison
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal DNS anonyme. Évalué à 1.
On peut aussi utiliser les signaux radio DCF77 (https://fr.wikipedia.org/wiki/DCF77) ou celui d'Allouis (https://fr.wikipedia.org/wiki/%C3%89metteur_d%27Allouis#Signaux_horaires). L'avantage sur le GPS est qu'ils sont plus faciles à recevoir depuis l'intérieur d'un bâtiment.
[^] # Re: Autre DNS et utilisation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal DNS anonyme. Évalué à 2.
Ben euh, le DNS a déjà plusieurs niveaux. Tu proposes quoi? machin.com.racine1 et machin.com.racine2? mais du coup, ce ne sont plus des racines, juste des branches de l'arbre des DNS…
On devrait pouvoir se contenter des TLDs existants (surtout qu'il y en a plein maintenant), et les gens peuvent faire ce qu'ils veulent en-dessous de leur propre domaine (truc.machin.com, bidule.machin.com, et ainsi de suite). Avoir plusieurs racines ne sert donc pas à grand chose.
[^] # Re: Bourne
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Librsvg utilise maintenant le langage Rust. Évalué à 5.
Il y a déjà un OS complet, avec GUI et tout: http://www.redox-os.org
Il faut quoi de plus? :o)
[^] # Re: Il oublie LES 2 raisons principales
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Pourquoi Windows. Évalué à 10.
On a besoin de ce genre de trucs dans mon travail. La solution retenue: on met un noyau Linux récent, avec la distro du choix du développeur, et les outils qui ont besoin de "vieux trucs" (des libs, mais aussi des versions spécifiques de perl ou de GNU make par exemple) tournent dans un chroot construit à partir d'un Debian de l'époque.
Le noyau Linux faisant très attention à ne pas casser son interface au niveau des syscalls, ça marche très bien, et cela n'a qu'un faible impact sur les performances (pas besoin de sortir une VM). On peut même utiliser le serveur X principal, avec donc les derniers drivers graphiques et l'accélération qui va bien (quelqu'un sait si ça peut fonctionner avec Wayland?)
[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 6.
Et si on essayait de ne pas faire une traduction littérale? «essaim d'ordinateurs»?
[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 4. Dernière modification le 04 janvier 2017 à 17:15.
cherche quels mots ont été collés dans "cloud computing" (et "star wars", et "star trek", et…)
Alors que "informatique", c'est un collage de "information automatique". Comme quoi…
[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 4.
Essayons d'être constructif: as-tu un meilleur terme à proposer? On peut parler "d'informatique en nuage", par exemple.
Quand aux titres de films, on est juste habitués à se dire qu'en anglais, ça claque plus. Mais en fait non: les titres anglais sont déjà nazes, c'est juste qu'on s'en rend moins compte quand on comprend pas bien l'anglais.
[^] # Re: Les étoiles sont une moyenne?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Framalibre est en train de renaître. Évalué à 6.
https://xkcd.com/937/
https://xkcd.com/1098/
[^] # Re: PCB homemade
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Faites tourner les PCB !. Évalué à 2.
Ce n'est pas indiqué, et je ne sais pas si on peut commander en ligne.
C'est du PCB simple comme ceux qu'on peut faire à la maison: PCB + pistes + étamage. Pas de silkscreen et pas de vernis, et perçage à la main (pas de vias). Mais on peut commander un seul exemplaire et être livré en moins d'une semaine.
C'est pas pour les mêmes besoins que ce que fait oshpark, mais pour des projets simples, c'est déjà très bien et moi ça m'a permis d'avancer pas mal en électronique sans avoir besoin de graver des circuits chez moi (ou chez mes parents, à l'époque).
[^] # Re: Script sieve
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Chiffrement, chiche ?. Évalué à 1.
En clair: ça marche pour le courrier, mais pas pour les pièces jointes.
[^] # Re: What you see is not what you get
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 4.
J'ai retrouvé ma source: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html
Par contre (et en fait, c'est logique), il y a quand même une limite qui est qu'on finit forcément par atteindre l'adresse logique d'une autre allocation. Donc la stack n'est pas illimitée pour autant. Par défaut la limite est de 1MB pour le thread principal et de 512K pour les autres.
[^] # Re: What you see is not what you get
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.
Il est aussi possible d'allouer la pile de façon dynamique: on mappe 4Ko au départ, et juste au-dessus, une page interdite d'accès pour le thread en question. Quand le thread utilise ses 4Ko, il finit par essayer d'écrire dans ce bloc protégé. Cela déclenche une exception (segmentation fault) qui est interceptée, le noyau peut alors ajouter 4Ko de mémoire supplémentaire, et ainsi de suite.
Il me semble que cette stratégie est utilisé par iOS, entre autres.
[^] # Re: PCB homemade
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Faites tourner les PCB !. Évalué à 2.
Ou bien trouver une boutique située en France qui propose de le faire.
Par exemple si vous êtes à Pau, c'est possible chez Distronic (http://www.distronic.fr/) et ça prend largement moins de 2 semaines. J'espère que ce n'est pas la seule/dernière boutique en France à proposer ça.