Michaël a écrit 2935 commentaires

Je commencerai bien avec un petit Emacs peut le faire.

Je crois que ce qui l'intéresse c'est un environnement ou tu saisis tes programmes, tu appuies sur un bouton et zou ton programme est compilé, lié et lancé: même gcc -c il ne semble pas vouloir en entendre parler.

Ça fait un peu 5 ans qu'on en parle, et c'est le coup de quelques heures en comptant large :)

Au détail près qu'il y a probablement quelques endroits du code qui travaillent sur les IPs des intervenants et que ces parties ne sont pas forcément écrites avec IPv6 en tête.

Voilà, et si tu n'a pas le droit d'écrire dans /etc/hosts tu peux ranger tes IPs dans des variables du Shell.

Tu peux te passer d'être agressif. Sans l'existence d'un maximum,

Oulà, je range tout de suite mon placard au placard alors! :)

Entre-temps j'ai réussi à me convaincre qu'on avait bien affaire à une fonction et je te remercie de ton argument expliquant que celle-ci est continue par morceaux.

Et toi, tu veux les forcer à parler anglais ? C'est pareil. Le plus cohérent, ce serait de parler français, portugais ou russe.

Le plus cohérent est de choisir une langue parlée par tous les contributeurs concernés. Il n'y a pas de raison que ce choix s'arrête sur la langue maternelle d'une partie de contributeurs.

J'ai l'impression que tu fais comme-ci on prenait un groupe de gens de diverses nationalités ne parlant aucune langue étrangère et qu'on allait les former pour contribuer au projet: dans ce cas choisir une langue maternelle d'une partie des contributeurs réduirait le temps de formation. Mais ce n'est pas comme cela que ça se passe!

C'est une case où tu peux signer.

En Allemagne ils remplacent cet avertissement par de la réclame pour la bière et pour les cigarettes. Au début ça fait bizarre!

interdit au moins de X ans

Et tu es allé voir quoi comme genre de film au juste?

Il doit penser à calendar(1).

J'ai écrit «(pas forcément atteinte)» donc tu peux ranger ta contradiction au placard.

Ce qui compte est que la valeurs de la fonction aient une borne sup, pour le raisonnement de Laffer on se fiche complètement que cette borne soit atteinte ou non. Laffer se borne à faire remarquer que l'impôt levé n'est pas une fonction croissante du taux d'imposition.

La condition continue par morceaux n'est pas très contraignante, je doute qu'il y ai un nombre infini de sauts de discontinuité dans les changements de comportements ou les exils fiscaux.

Sur quoi repose ton affirmation? La courbe en question est juste une courbe dont tu ne sais rien. D'ailleurs rien ne dit que ce soit une courbe, ce n'est pas parcqu'on a des x et des y que l'un dépend forcément de l'autre de façon fonctionnelle.

Oui par exemple moi je n'ai pas la télé et j'écoute la radio.

La continuité de la courbe ne sert à rien puisque le gain maximal est borné a priori (probablement par le PIB) donc les valeurs de la fonctions ont une borne supérieure (pas forcément atteinte).

Quand le CG77 a demandé une version correcte de la documentation, Logica a répondu avec un devis supplémentaire à 34k€.

Vous n'avez pas des recours juridiques contre ça? Parceque s'ils n'ont pas de doc à jour, c'est bien la preuve qu'ils ne savent pas ce que fait leur logiciel (bon OK les gars qui l'écrivent en ont une vague idée, mais les autres ils font comment?) Ça ne devrait pas être la peine de préciser dans une appelle d'offre que la documentation doit être à jour (une documentation pas à jour ne se rapporte pas au produit vendu).

Alors qu'il est bien connu que dans le privée, les ressources sont toujours optimisés, les ratios toujours parfait, aucune ressource n'est gaspillée.

Moi dans mon entreprise privée où je travaille on n'utilise pas de poudre verte et on fait à peu près tout ce qu'il faut pour travailler avec la plus petite productivité possible. À minuit et demie, j'ai donc besoin de cracher mon venin.

D'un autre côté, il devrait être normal que ceux qui payent (les citoyens) puissent savoir comment est dépensé leurs sous.

En pratique c'est une représentant de toi qui a un doit de regard sur ces choses là. (En l'occurence ce doit être le préfet, si ton sentiment qu'il te représente est plutôt mitigé, je le partage!)

Si tout à la fin tu enlèves l'appel à la fonction principale, tu peux jouer avec les diverses fonctions pour voir ce qu'elles font.

C'est très important d'expérimenter pour se sentir à l'aise!

Ah. Ça ne se voulait pas perfide en tout cas, juste pragmatique

Sans me targuer d'une orthographe parfaite, je n'ai pas besoin de visiter beaucoup d'autres forums avant de trouver des contributeurs qui s'en tirent plutôt moins bien… c'est pour ça que je trouvais ta remarque vaguement perfide.

Tu veux sans doute parler des anglophones au lieu des anglo-saxons.

Indice: pointeur.

pourquoi ne pas faire pareil pour le code des binaires

C'est déjà le cas sur tout OS digne de ce nom, sauf s'il autorise la modification du segment .text de tes programmes, évidemment!

Préconiser l'assembleur pour débuter me semble une vaste blague.

Je ne suis pas du tout d'accord. Si tu programmes en assembleur tu peux utiliser quelques boîtes noires magiques du type printf pour l'affichage (qui de toute façon va finalement passer par une boîte noire appel système ).

L'écriture des algorithmes d'Euclide ou des algorithmes de tri n'est pas plus compliquée qu'en C et ce sont les exemples classiques de toute introduction à la programmation. Le manque d'expressivité de l'assembleur n'est pas du tout un obstacle à une introduction et on peut déjà aborder beaucoup de problèmes fondamentaux de programmation avec l'assembleur.

D'ailleurs l'assembleur a été mon deuxième langage de programmation (après l'AMOS Basic) et mon premier langage sur PC, car c'est le seul langage pour lequel j'avais dégotté un compilateur gratos. (Le a86 de Isaacson.) Vu qu'à l'époque j'avais douze ans, je ne vois rien qui puisse rébuter des élèves ingénieurs.

Débuter par un assembleur, je pense que tu veux dégoûter des gens de l'informatique inutilement.

Pas du tout, c'est bien mieux de commencer par l'assembleur que par le C.

Pas si simple. Il faut aussi s'assurer que tout ce passe comme prévu : de ne pas garder de mutex ver ouillé par erreur, de bien libérer toutes les ressources qui ont été allouée par la fonction. De garder l'état du programme dans un état correcte, sans structure de donnée à moitié initialisées.

Eh oui, programmer n'est pas facile!

En plus l'utilisateur de la bibliothèque devra faire pareil et ajouter du code pour gérer cette erreur.

Et en plus il va écrire un programme tout autour! Quelle idée!

Les programmes qui ont vraiment besoin de gérer les cas d'OOM sont plutôt rares. Et il vaux mieux ne pas gaspiller de temps et de ressources à le faire.

En réalité tous les programmes sont susceptibles de rencontrer un OOM, à cause du voisin qui a bouffé toute la place. Si tes programmes sont instables en cas d'OOM cela signifie que si un programme ange toute la mémoire les autres partent en cacahuète. Super.

Quand tu as ce genre d'erreur pour des petites demande de création mémoire comme un bête outil de l'exemple, que l'outil soit conforme ou pas à l'API est le dernier de tes soucis… à la limite si tu demandais un realloc(100*1000*1000),

Quelles que soient ses motivations, un programmeur codant comme un cochon reste un programmeur codant comme un cochon. Et les cochons écrivent des programmes difficiles à debugger, difficiles à modifier, … autrement dit ils renoncent à l'aspect soft du software. Même si c'est un choix qui peut être parfois viable, il ne doit jamais être présenté comme anodin!

Puis quand on cherche à faire light, c'est l'idéal, on peut contrôler on ne peux plus finement la taille du tas.

C'est seulement vrai si tu connais bien ton allocateur de mémoire.

De plus, en C tes données ne peuvent être déplacées après avoir été allouées, donc un programme C est particulièrement vulnérable à la fragmentation de la mémoire.

et caste de *alloc ou pas).

On ne caste pas les malloc, cela ne sert à rien et peut cacher une faute (oubli de l'inclusion de stdlib.h) qui peut déclencer un UB si sizeof(int) != sizeof(void*).