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

Kevin Kofler (./2460) :
C'est parce que votre système d'exploitation est pourri. GNU/Linux gère les line disciplines en userspace depuis pas mal de temps.

et bien sûr, ton truc est compatible avec VB6 et VB .NET... t'es hors sujet.

on parle pas de line discipline (RTS CTS) mais du port parallèle en bitbang, qui requiert aussi un driver sous linux.

Non sous linux tu peux faire

open("/dev/mem");

Les drivers c'est pour les chiens

Pour le coup c'est /dev/port qu'il te faut, mais bref ^^

root@yaronet.com ~ $ deluser --remove-all-files "Kevin Kofler"
C'est vrai que c'est pas si mal Linux.

Zerosquare (./2458) :
Je sais, je sais... et c'est encore rien par rapport aux conditions et délais de paiement des entités publiques... mais ça se répercute sur la facture ^^

On paye au plus tard à 30 jours dès service fait+réception de la facture, nous ! (Et c'est vraiment au plus tard, on a une moyenne qui se situe à 7 jours ouvrés - d'ailleurs, ça surprend souvent nos prestataires )

Godzil (./2445) :
Tiens en plus d’être expert en sciences politique tu es expert en sciences informatique. Bien!

Mmmm... Pas la peine d'être désagréable, si ?

Godzil (./2445) :
la solution est extrêmement simple

Tellement simple et surtout évidente/intuitive pour tout le monde qu'elle est toujours implémentée comme ça en pratique, en effet.
On ne dit pas que c'est impossible de vérifier, on dit qu'en pratique, ce n'est généralement pas fait et que dans le meilleurs des cas on a un cast, au pire un warning ignoré.

Godzil (./2445) :
Le débat est de toutes manière complètement foireux parce que signe ou pas, on ne fait que déporter le problème.

C'est pas faux, mais ça me semble quand même moins fréquent de risquer de dépasser aux infinis qu'à zéro.

Nil (./2466) :
On paye au plus tard à 30 jours dès service fait+réception de la facture, nous ! (Et c'est vraiment au plus tard, on a une moyenne qui se situe à 7 jours ouvrés - d'ailleurs, ça surprend souvent nos prestataires )

Ouais, ouais, j'ai un client qui m'a tenu le même discours... sauf qu'avant que ce soit débloqué, faut que machin donne son accord ("ah ben non, c'est pas fini, vous avez pas implémenté un truc qui n'était pas dans le contrat"), que ce soit signé par truc (qui ne s'entend pas avec machin pour des raisons futiles, donc qui traîne les pieds), que ce soit transmis au service compta sur papier en multiples exemplaires, etc. Donc bon, je connais la musique

Faut s'arranger pour que le paiement tombe en fin d'année. En général, il faut payer avant la fin de l'année pour ne pas entamer le budget de l'année suivante (et perdre le précédent) ^^

RHJPP (./2469) :
Faut s'arranger pour que le paiement tombe en fin d'année. En général, il faut payer avant la fin de l'année pour ne pas entamer le budget de l'année suivante (et perdre le précédent) ^^

Bof, ça ce n'est pas vrai, on peut très bien avoir des choses d'une année sur l'autre, même en GBCP. C'est juste que c'est chiant à gérer au niveau archivage, surtout

Ha bon ? Le CNES nous demande pourtant régulièrement en fin d'année de leur rendre un document, même une ébauche, pour qu'on puisse facturer une partie du projet avant la fin de leurs comptes de l'année. Si c'est juste parce que c'est chiant à gérer, c'est dommage ^^

Hm, le CNES doit avoir des règles de gestion différentes (nous, bien des choses ont changé depuis le passage aux RCE).
Cela dit, nous on est aussi poussé au cul pour la facturation, mais moins pour nous que pour les prestataires, en fait.

Nil (./2472) :
Cela dit, nous on est aussi poussé au cul pour la facturation

J'ai lu "passé" au lieu de "poussé" la première fois. J'ai trouvé ça vraiment dépravé, même pour toi

()

Même pour Nil ?

squalyl (./2462) :
on parle pas de line discipline (RTS CTS) mais du port parallèle en bitbang, qui requiert aussi un driver sous linux.

La libticables/libcalccables actuelle arrive à gérer le câble parallèle (qui ne suit aucun protocole parallèle, il branche juste les broches de la TI aux broches du port parallèle) sans pilote (et sans accès direct nécessitant root) sous GNU/Linux. Les line disciplines permettent justement de mettre les broches à 1 ou 0 quand on veut, sans suivre le protocole → bitbang.

Cf.
https://svn.calcforge.org/viewvc/calcforgelp/libcalccables/trunk/src/linux/ioports.c?revision=4550&view=markup
https://svn.calcforge.org/viewvc/calcforgelp/libcalccables/trunk/src/linux/link_par.c?revision=4550&view=markup

beurk

Zerosquare (./2473) :
J'ai lu "passé" au lieu de "poussé" la première fois. J'ai trouvé ça vraiment dépravé, même pour toi

Maismaismais

flanker (./2447) :
Very > mais c'est simplement que l'addition n'est pas une opération interne

Kevin Kofler (./2449) :
Ce que tu veux dire, c'est que les nombres non signés ne seraient pas un groupe additif, ce qui est vrai si on considère le vrai ℕ, mais les ordinateurs ne travaillent pas avec ℕ ni ℤ, mais toujours avec un anneau fini ℤ/2^8×2ⁿℤ.

En assez bas niveau ouais. En assez bas niveau tout est une suite de bits, donc en fait tous les types du monde ne servent à rien et autant faire de l'assembleur directement etc.

Enfin je comprends bien la logique de l'anneau modulo 2^p, le truc cool c'est que en plus d'être mathématiquement élégant c'est ce que fait le processeur, je sais bien, mais bon c'est tellement cool que c'est une des premières causes de bugs informatiques ^^

Bon et en quoi la soustraction est différente ? Formellement c'est pareil, humainement c'est différent.
Souvent les gens vont travailler dans ℤ/2^8×2ⁿℤ en se disant "je m'en fou des dépassements car je travaille avec des très petits nombres, je suis trop large avec 32 ou 64 bits, etc."
Mais ça ne marche à peu près tant que l'on ne fait pas certains types d’opérations, comme l'exponentiation ou la soustraction. Sauf que les puissances, exponentiations, voir les multiplications, on se rend bien compte que ça peut donner des nombres importants. Alors que la soustraction est super fourbe : eh ouais tu fais 5-6 et tu débordes... Du coup je réitère que pour une utilisation naïve, c'est un peu compliqué de mettre la soustraction dans les entiers naturels. (et pourquoi utiliser ça si c'est pour se taper un if à chaque fois en plus ? )

Donc selon les cas, pour une utilisation naïve, ça va donner le résultat attendu grâce à un cast implicite, ou sinon ça va rester unsigned éventuellement surprendre l'utilisateur naif.

Bref vu d'une part le très faible gain et d'autre part le surnombre de problèmes potentiels important, je comprends largement que certains langages plutôt haut-niveau n'aient pas de type unsigned de base. À mon sens ça ressemble plus à une survivance de l'assembleur, où les mecs voulaient gratter un peu, que a un type qui a un vrai intérêt dans un langage plus haut niveau.

Évidemment on ne parle pas du mec conscient qui sait vraiment ce qu'il fait (qui représente un % de codeurs assez faible, mais passons ) et veut de la performance pour faire de l'arithmétique bien précise.

Kevin Kofler (./2449) :
La fonction d'ordre est toute simple, et c'est évidemment comme ça que c'est implémenté: on prend le représentant principal non signé de chaque classe d'équivalence (donc 0 pour 0+2^8×2ⁿℤ, 1 pour 1+2^8×2ⁿℤ, …, 2^8×2ⁿ-1 pour 2^8×2ⁿ-1+2^8×2ⁿℤ) et on range par conséquent: 0 < 1 < 2 < … < 2^8×2ⁿ-1, donc 0+2^8×2ⁿℤ < 1+2^8×2ⁿℤ < 2+2^8×2ⁿℤ < … < 2^8×2ⁿ-1+2^8×2ⁿℤ.

tu as pas trouvé une explication encore plus fastidieuse pour dire que comparer deux éléments mudulo une puissance de 2 ça revient à comparer leur représentant, ie les p premiers bits ?

(bon c'est un troll apparemment : https://www.amazon.com/gp/profile/amzn1.account.AH4UWRLKB46T5W7PMFQB7NM4YHGA
Dommage, c'était rigolo )

(erf, anéfé )

Ceci dit il m'a fallu bien moins de 6 semaines pour faire mon premier driver (sous linux) donc certains commentaires sont du pipeau aussi

Blague a part, voila le genre de raison qui me font détester le C++:

http://stackoverflow.com/questions/41134190/linker-can-not-find-symbols-but-theyre-there

Je ne comprends pas comment on peux faire des changement dans un langage qui cassent complètement la compatibilité avec les version précédentes.

On parle bien de ce langage qui n'a aucune compatibilité binaire entre objets générés par deux compilateurs différents, voire par deux versions différentes d'un même compilateur ?

voila

Godzil (./2485) :
Je ne comprends pas comment on peux faire des changement dans un langage qui cassent complètement la compatibilité avec les version précédentes.

Ce n'est pas (directement) le langage qui a changé, mais GCC (enfin, la libstdc++) qui a choisi d'implémenter une nouvelle ABI pour la STL, parce que le standard C++11 est maintenant plus explicite sur les comportements autorisés, et en particulier, interdit le copy-on-write pour std::string ( – une optimisation utile et le standard l'interdit, la STL sera toujours inférieure à QtCore). Franchement, je ne vois pas comment les programmes remarqueraient la différence (à part que c'est plus rapide avec le COW), mais ils ont choisi de changer l'ABI pour ça.

Maintenant, la libstdc++ elle-même gère les deux ABIs, donc normalement, le changement est transparent. Le problème, c'est quand tu utilise une bibliothèque tierce qui utilise les types de la STL, qui est en général compilée pour l'une ou l'autre ABI. Donc si les versions de la libstdc++ ne correspondent pas entre ton GCC et celui utilisé pour compiler la bibliothèque tierce, tu as un problème. (Le problème n'existe pas avec des bibliothèques comme Qt qui interdisent l'utilisation des types de la STL dans leur API publique.)

Un petit module en Javascript, je veux renommer une classe définie dans un fichier et utilisée seulement dans un autre. Au début j'ai fait un find all pour voir où je devais changer. Comme ça ne semblait jamais finir j'ai pris le risque de faire un replace all.



Pour.. une.. classe.. utilisée.. à un seul.. endroit.

pas si que ca, au final