Sur les assembleurs modernes, on peut définir des labels locaux, en général avec un préfixe ou un suffixe dédié (par exemple un . ou un $). La portée est entre deux labels globaux. Du coup, toutes les boucles peuvent s'appeler ".loop" ou quelque chose de ce genre.
ça permet aussi de migrer des morceaux du code vers du C "propre" petit à petit. C'est possible de mélanger le C et l'assembleur aussi, mais pas forcément évident surtout si c'est de l'assembleur écrit pour MS-DOS (avec accès direct à la RAM vidéo, tout ça).
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
"No Superuser, No System Administration – There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in POSIX.1-2008. POSIX.1-2008 is also not concerned with hardware constraints or system maintenance."
La version actuelle de POSIX a donc supprimé la notion de super-utilisateur (il en reste quelques traces, cependant), ainsi que toutes les commandes liées à l'administration système. Pas de "su", pas de "chroot", par exemple.
Donc, la présence ou l'absence d'un utilisateur root n'est pas liée à POSIX. Peut-être aux systèmes "UNIX-like", éventuellement.
Même aujourd'hui, il y a toujours une "guerre" de performances entre C et Fortran qui pousse à garder ces possibilités d'optimisation. C'est comme ça que C99 a ajouté le "strict aliasing", les "restrict" sur les pointeurs, et quelques autres trucs qui permettaient à Fortran d'aller plus vite que le C à l'époque.
ça n'empêche pas de le réécrire, en fait. Mais ça permet déjà d'avoir un code fonctionnel, à partir duquel on peut réécrire les choses petit à petit.
Parce que réécrire du code assembleur en C et le porter de DOS vers SDL en même temps et sans pouvoir tester tant que tout n'est pas fini, c'est pas forcément évident.
Je demande à voir quelle serait l'erreur levée. Comme c'est indiqué dans le premier commentaire sur reddit, ce code a un cas d'exécution valide, si NeverCalled est appelé (ce qui est possible, puisque cette fonction n'est pas statique) avant main() (ce qui est possible, par exemple en C++ en initialisant un objet statc/global).
Le compilateur optimise ce cas valide, et a le droit d'ignorer l'autre cas (celui ou le pointeur est NULL et donc le comportement indéfini). Lui faire faire la même chose que l'autre cas, c'est un choix raisonable.
Ceux qui trouvent ça inacceptable, il faut changer de langage comme ça a été dit plein de fois au-dessus. Et accepter d'avoir du code un peu moins performant mais beaucoup plus sûr.
Il y a déjà eu quelques corrections dans C99, par exemple, sur le comportement de l'opérateur % avec des opérandes négatifs (c'est juste un exemple, il y en a probablement d'autres dans C99 et C11).
Mais le C reste un langage bas niveau et qui tient compte des possibilités de très nombreuses architectures, notament des trucs franchement euh… "créatifs" pour certains systèmes embarqués: bytes qui ne font pas 8 bits (avec CHAR_BITS), mémoire adressée par segment:offset comme sur les 386, architectures ou l'espace mémoire est découpé en une partie pour le code et l'autre pour les données (AVR8, par exemple). Le tout en préférant toujours l'approche qui donnera les meilleures performances quitte à avoir un comportement indéfini, ou au mieux, défini par l'implémentation (là au moins on sait ce qu'il se passe pour un compilateur donné).
Je ne pense pas que le langage se prête bien à l'écriture de code sur et sans comportements indéfinis. Donc oui, à mon avis, il serait mieux de changer de langage, même si cela demandera beaucoup d'efforts.
Ce qui m'inquiète là dedans, c'est pas forcément qu'il y aie une limite. C'est plutôt les langages où ça finit par faire une erreur de segmentation ou un autre truc du genre. Résultat, n'importe qui peut faire planter ton API REST en envoyant une requête de 27Ko (c'est à dire pas grand chose).
S'il y a juste une exception et qu'elle peut être interceptée et testée par l'applicatif, je pense que ça n'est pas vraiment un problème à condition que ce soit documenté et que les applications qui en ont besoin (pour des raisons de sécurité et de continuité de service, pas parce qu'elles ont vraiment besoin de parser des très gros fichiers JSON avec 100 niveaux d'imbrication) puissent réagir en conséquence.
Faire une documentation de qualité, c'est un métier et ça demande d'y passer du temps.
En fait, Doxygen peut même être nuisible pour ce genre de choses. L'idée est de mettre la documentation et le code dans le même fichier, en se disant que comme ça les gens vont peut-être mieux arriver à garder les deux synchronisés. Mais l'inconvénient, c'est que ça conduit souvent à une documentation qui est seulement une paraphrase du code: on va sagement mettre un gros commentaire Doxygen au début de chaque fonction et bêtement répéter ce que fait le code dedans. ça n'a aucun intérêt. Une documentation est utile quand elle arrive à prendre de la hauteur et à décrire l'architecture sans trop rentrer dans les détails.
Il y a des cas ou Doxygen marche plutôt bien, par exemple pour documenter les APIs d'un module. Il est possible de l'utiliser pour faire une documentation d'architecture complète, mais ça reste beaucoup de travail. Et surtout, c'est pénible de devoir inclure toute cette documentation dans les fichiers source, dont ça encombre la lecture. J'ai en tête un projet qui a trouvé une solution en mettant les commentaires Doxygen dans des fichiers séparés du code source pour éviter ce problème. Mais du coup, Doxygen n'a plus grand intérêt, si ce n'est de parser les fichiers .h du projet pour vérifier que les APIs documentées sont bien celles qui sont implémentées.
J'ai lu quelque part des arguments contre la publication complète des jeux de données et du code utilisé sous licence libre, qui m'on paru plus ou moins pertinents.
En gros, ne pas publier ces outils forcerait les gens à refaire l'expérience de leur côté, et permettrait de s'assurer qu'elle est reproductible et qu'ils ne trouvent pas des résultats différents. Il serait gênant d'avoir un résultat faux à cause d'un bug, et que personne ne s'en aperçoive tant que tout le monde utilise le même code et les mêmes données.
Je sais pas, le ";-)" à la fin du commentaire par exemple?
Cela dit on va apprendre plein de choses sur la prononciations de l'anglais, et je remercie les gens qui réagissent toujours sérieusement et avec des faits pour étayer leur propos. J'apprécie souvent les discussions (parfois hors-sujet, mais c'est pas grave) qui en résultent.
J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.
Le code source, ça serait donc l'équivalent des plans d'architecte.
La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.
Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).
Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)
Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.
Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?
J'ai également un Kindle, mais je l'utilise avec des livres que je télécharge ailleurs que chez Amazon, ce qui marche plutôt bien avec le logiciel par défaut sauf pour les fichiers epub. Mais il est très facile d'installer un autre lecteur d'ebooks sur les Kindle (Duokan lite, Koreader, …) ou de faire plein d'autres choses avec (j'ai vu par exemple un Kindle transformé en station météo).
C'est un peu inattendu de la part d'Amazon, mais il y a peu de verrouillage logiciel sur les Kindle. Il est facile de se connecter en ssh ou telnet puis de faire un "/etc/init.d/framework stop" pour se débarasser de leur application et se retrouver avec un système Linux tout à fait normal.
Je monte mon Kindle en mass storage et j'utilise la commande cp. Je ne crois pas avoir rencontré de problèmes avec cette solution. Est-ce que ça a changé sur les modèles plus récents?
Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.
L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.
Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.
Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.
Je peux te faire un retour personnel là dessus. Il y a pour moi un problème principal (dans la façons don't c'est réalisé par chez moi). Si tu es tout seul, en 10 minutes le transport à la demande te dépose à l'arrêt de tramway le plus proche et c'est très pratique. Par contre s'il y a un peu de monde qui a réservé sur le même créneau que toi, c'est parti pour la tournée de tous les villages du canton, qui peut parfois prendre plus d'une heure. Du coup si tu as besoin d'arriver à un horaire précis, tu es obligé de prévoir une heure de marge en cas de période de pointe.
Finalement, je fais le trajet jusqu'à l'arrêt de tramway en vélo. Sauf cas particuliers, du genre je dois aller prendre un train ou un avion et j'ai un gros bagage à transporter (encore que, avec un peu d'habitude ça peut se faire en vélo aussi).
Les banques proposent des prêts "relais" pour ce genre d'opération, ce qui permet d'acheter d'abord, puis de vendre ensuite, sans trop de problèmes financiers.
Personellement je fais 15km de vélo pour aller travailler, et je mets à peine plus de temps que mes collègues qui font à peu près le même trajet en voiture. Et oui, il m'arrive d'être trempé quand il y a une averse. Je prévois des vêtements de rechange, et le problème est réglé (sans avoir à construire autoroutes, bretelles de déviation, rond points, tout ça).
Tiens d'ailleurs, en espagnol, le masculin s'écrit souvent avec une terminaison en o, le féminin en a, et l'écriture inclusive en @ qui est un mélange des deux. Ce qui est un peu moins pénible à lire (mais pas plus simple à prononcer) qu'en français.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
Puisqu'on parle de #balancetonporc et de Rust, pour les dénonciations ça se passe ici:
https://github.com/ansuz/RIIR
https://transitiontech.ca/random/RIIR
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Sur les assembleurs modernes, on peut définir des labels locaux, en général avec un préfixe ou un suffixe dédié (par exemple un . ou un $). La portée est entre deux labels globaux. Du coup, toutes les boucles peuvent s'appeler ".loop" ou quelque chose de ce genre.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
ça permet aussi de migrer des morceaux du code vers du C "propre" petit à petit. C'est possible de mélanger le C et l'assembleur aussi, mais pas forcément évident surtout si c'est de l'assembleur écrit pour MS-DOS (avec accès direct à la RAM vidéo, tout ça).
Le temps de la https://www.svgalib.org est révolu!
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
Oh et pour la musique chiptune faite "à la main": https://www.linusakesson.net/hardware/chiptune.php
[^] # Re: Droit root, petite nuance
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche F-Droid 1.0 est sorti. Évalué à 3.
Dans la specification POSIX (http://pubs.opengroup.org/onlinepubs/9699919799/) je n'ai trouvé que ceci à propos d'un utilisateur "root":
"No Superuser, No System Administration – There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in POSIX.1-2008. POSIX.1-2008 is also not concerned with hardware constraints or system maintenance."
La version actuelle de POSIX a donc supprimé la notion de super-utilisateur (il en reste quelques traces, cependant), ainsi que toutes les commandes liées à l'administration système. Pas de "su", pas de "chroot", par exemple.
Donc, la présence ou l'absence d'un utilisateur root n'est pas liée à POSIX. Peut-être aux systèmes "UNIX-like", éventuellement.
[^] # Re: Comportement attendu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 4.
Même aujourd'hui, il y a toujours une "guerre" de performances entre C et Fortran qui pousse à garder ces possibilités d'optimisation. C'est comme ça que C99 a ajouté le "strict aliasing", les "restrict" sur les pointeurs, et quelques autres trucs qui permettaient à Fortran d'aller plus vite que le C à l'époque.
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 10.
ça n'empêche pas de le réécrire, en fait. Mais ça permet déjà d'avoir un code fonctionnel, à partir duquel on peut réécrire les choses petit à petit.
Parce que réécrire du code assembleur en C et le porter de DOS vers SDL en même temps et sans pouvoir tester tant que tout n'est pas fini, c'est pas forcément évident.
[^] # Re: Erreur?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 1.
Je demande à voir quelle serait l'erreur levée. Comme c'est indiqué dans le premier commentaire sur reddit, ce code a un cas d'exécution valide, si NeverCalled est appelé (ce qui est possible, puisque cette fonction n'est pas statique) avant main() (ce qui est possible, par exemple en C++ en initialisant un objet statc/global).
Le compilateur optimise ce cas valide, et a le droit d'ignorer l'autre cas (celui ou le pointeur est NULL et donc le comportement indéfini). Lui faire faire la même chose que l'autre cas, c'est un choix raisonable.
Ceux qui trouvent ça inacceptable, il faut changer de langage comme ça a été dit plein de fois au-dessus. Et accepter d'avoir du code un peu moins performant mais beaucoup plus sûr.
# Beaver Debugger
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal CGDB 0.7.0 est sorti... il y a plusieurs mois :S. Évalué à 2.
Il y avait ça qui marchait pas mal:
http://pasnox.tuxfamily.org/project/beaverdbg
L'idée était de prendre la partie "debugger" de Qt Creator sans la partie IDE. Mais je ne crois pas que ça soit tenu à jour :(
[^] # Re: Existe-t-il des compilateurs C/C++ qui donnent une sémantique à tous les programmes ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Compilateur trop intelligent. Évalué à 5.
Il y a déjà eu quelques corrections dans C99, par exemple, sur le comportement de l'opérateur % avec des opérandes négatifs (c'est juste un exemple, il y en a probablement d'autres dans C99 et C11).
Mais le C reste un langage bas niveau et qui tient compte des possibilités de très nombreuses architectures, notament des trucs franchement euh… "créatifs" pour certains systèmes embarqués: bytes qui ne font pas 8 bits (avec CHAR_BITS), mémoire adressée par segment:offset comme sur les 386, architectures ou l'espace mémoire est découpé en une partie pour le code et l'autre pour les données (AVR8, par exemple). Le tout en préférant toujours l'approche qui donnera les meilleures performances quitte à avoir un comportement indéfini, ou au mieux, défini par l'implémentation (là au moins on sait ce qu'il se passe pour un compilateur donné).
Je ne pense pas que le langage se prête bien à l'écriture de code sur et sans comportements indéfinis. Donc oui, à mon avis, il serait mieux de changer de langage, même si cela demandera beaucoup d'efforts.
[^] # Re: J’attends toujours un exemple…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 7.
Ce qui m'inquiète là dedans, c'est pas forcément qu'il y aie une limite. C'est plutôt les langages où ça finit par faire une erreur de segmentation ou un autre truc du genre. Résultat, n'importe qui peut faire planter ton API REST en envoyant une requête de 27Ko (c'est à dire pas grand chose).
S'il y a juste une exception et qu'elle peut être interceptée et testée par l'applicatif, je pense que ça n'est pas vraiment un problème à condition que ce soit documenté et que les applications qui en ont besoin (pour des raisons de sécurité et de continuité de service, pas parce qu'elles ont vraiment besoin de parser des très gros fichiers JSON avec 100 niveaux d'imbrication) puissent réagir en conséquence.
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 5.
Doxygen ce n'est pas de la magie.
Faire une documentation de qualité, c'est un métier et ça demande d'y passer du temps.
En fait, Doxygen peut même être nuisible pour ce genre de choses. L'idée est de mettre la documentation et le code dans le même fichier, en se disant que comme ça les gens vont peut-être mieux arriver à garder les deux synchronisés. Mais l'inconvénient, c'est que ça conduit souvent à une documentation qui est seulement une paraphrase du code: on va sagement mettre un gros commentaire Doxygen au début de chaque fonction et bêtement répéter ce que fait le code dedans. ça n'a aucun intérêt. Une documentation est utile quand elle arrive à prendre de la hauteur et à décrire l'architecture sans trop rentrer dans les détails.
Il y a des cas ou Doxygen marche plutôt bien, par exemple pour documenter les APIs d'un module. Il est possible de l'utiliser pour faire une documentation d'architecture complète, mais ça reste beaucoup de travail. Et surtout, c'est pénible de devoir inclure toute cette documentation dans les fichiers source, dont ça encombre la lecture. J'ai en tête un projet qui a trouvé une solution en mettant les commentaires Doxygen dans des fichiers séparés du code source pour éviter ce problème. Mais du coup, Doxygen n'a plus grand intérêt, si ce n'est de parser les fichiers .h du projet pour vérifier que les APIs documentées sont bien celles qui sont implémentées.
[^] # Re: Partenariat
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Propriété intellectuelle dans la recherche public. Évalué à 4.
J'ai lu quelque part des arguments contre la publication complète des jeux de données et du code utilisé sous licence libre, qui m'on paru plus ou moins pertinents.
En gros, ne pas publier ces outils forcerait les gens à refaire l'expérience de leur côté, et permettrait de s'assurer qu'elle est reproductible et qu'ils ne trouvent pas des résultats différents. Il serait gênant d'avoir un résultat faux à cause d'un bug, et que personne ne s'en aperçoive tant que tout le monde utilise le même code et les mêmes données.
Des idées sur quoi faire pour éviter ce problème?
[^] # Re: Le contraire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Une Demande d’Emploi en 2017. Évalué à 5.
Je sais pas, le ";-)" à la fin du commentaire par exemple?
Cela dit on va apprendre plein de choses sur la prononciations de l'anglais, et je remercie les gens qui réagissent toujours sérieusement et avec des faits pour étayer leur propos. J'apprécie souvent les discussions (parfois hors-sujet, mais c'est pas grave) qui en résultent.
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 4. Dernière modification le 26 octobre 2017 à 11:18.
J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.
Le code source, ça serait donc l'équivalent des plans d'architecte.
La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.
Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).
Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)
Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.
Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?
[^] # Re: Bidouillabilité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 2.
Il a l'air possible d'installer koreader en conservant le Linux fourni par Kobo:
https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices
[^] # Re: Question de poids
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 3.
J'ai un doute sur la possibilité de remplacer les cahiers.
J'ai un très gros doute sur la possibilité pour une liseuse de survivre dans un cartable d'écolier de façon durable.
[^] # Re: beaucoup d'avantages, quelques défauts
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 3.
J'ai également un Kindle, mais je l'utilise avec des livres que je télécharge ailleurs que chez Amazon, ce qui marche plutôt bien avec le logiciel par défaut sauf pour les fichiers epub. Mais il est très facile d'installer un autre lecteur d'ebooks sur les Kindle (Duokan lite, Koreader, …) ou de faire plein d'autres choses avec (j'ai vu par exemple un Kindle transformé en station météo).
C'est un peu inattendu de la part d'Amazon, mais il y a peu de verrouillage logiciel sur les Kindle. Il est facile de se connecter en ssh ou telnet puis de faire un "/etc/init.d/framework stop" pour se débarasser de leur application et se retrouver avec un système Linux tout à fait normal.
[^] # Re: Calibre
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 3.
Je monte mon Kindle en mass storage et j'utilise la commande cp. Je ne crois pas avoir rencontré de problèmes avec cette solution. Est-ce que ça a changé sur les modèles plus récents?
[^] # Re: la spec, c'est le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 10.
Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.
L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.
Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.
Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.
[^] # Re: T'aimes pas le maire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 6.
Je peux te faire un retour personnel là dessus. Il y a pour moi un problème principal (dans la façons don't c'est réalisé par chez moi). Si tu es tout seul, en 10 minutes le transport à la demande te dépose à l'arrêt de tramway le plus proche et c'est très pratique. Par contre s'il y a un peu de monde qui a réservé sur le même créneau que toi, c'est parti pour la tournée de tous les villages du canton, qui peut parfois prendre plus d'une heure. Du coup si tu as besoin d'arriver à un horaire précis, tu es obligé de prévoir une heure de marge en cas de période de pointe.
Finalement, je fais le trajet jusqu'à l'arrêt de tramway en vélo. Sauf cas particuliers, du genre je dois aller prendre un train ou un avion et j'ai un gros bagage à transporter (encore que, avec un peu d'habitude ça peut se faire en vélo aussi).
[^] # Re: D'ou l'intéret de supprimer la taxe d'habitation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 3.
Les banques proposent des prêts "relais" pour ce genre d'opération, ce qui permet d'acheter d'abord, puis de vendre ensuite, sans trop de problèmes financiers.
[^] # Re: une généralité malheureusement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 10.
Ben oui, la pluie ça mouille.
Personellement je fais 15km de vélo pour aller travailler, et je mets à peine plus de temps que mes collègues qui font à peu près le même trajet en voiture. Et oui, il m'arrive d'être trempé quand il y a une averse. Je prévois des vêtements de rechange, et le problème est réglé (sans avoir à construire autoroutes, bretelles de déviation, rond points, tout ça).
[^] # Re: D'ou l'intéret de supprimer la taxe d'habitation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 5.
Supprimons les patacoufins!
[^] # Re: Singulier, pluriel, faut savoir !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 2.
Tiens d'ailleurs, en espagnol, le masculin s'écrit souvent avec une terminaison en o, le féminin en a, et l'écriture inclusive en @ qui est un mélange des deux. Ce qui est un peu moins pénible à lire (mais pas plus simple à prononcer) qu'en français.