Tout le monde n'habite pas à Paris, tout le monde ne peut pas se libérer en milieu de semaine pour assister à ce genre de conf toutes aussi passionnantes que les autres....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pardon pour cette opinion purement cynique, mais c'est quand la mienne.
Peut être que Courtillot a raison. Je ne suis pas spécialiste et après tout je n'en sais rien.
Faire flipper les gens sur la production de carbone est la meilleur solutions pour contraindre les comportements avec qq chose de mesurable, l'idéal étant néanmoins que les gens comprennent la notion d'empreinte globale (ie. la Toyota Prius est certes écolo à l'utilisation, mais hyper poluant à la fabrication et à la destruction. Des exemples de ce genre, il y en a plein).
Ca permettra aussi de relocaliser, et d'éviter les situation débiles où on achète des trucs fabriqué au bout du monde, parce que l'énergie (fossile) ne coute pas cher, alors que l'usine d'à côté fabrique la même denrée pour la vendre à 2000 km.
Ou les tomates en hiver, etc....
Ca permettra encore d'apprendre aux citadin de se passer de voiture - j'ai encore pas mal d'amis qui l'utilisent pour un oui ou pour un non.
Parce que, si on prouve que le CO2 n'a rien à voir, qu'est-ce qui va se passer ?
A bah, c'est de la faute des volcans ma bonne dame, on y peut rien, donc c'est cool, on va pouvoir continuer à foutre le bordel autant qu'on veux ! Génial !
Si notre civilisation veut survivre, il lui faut apprendre à drastiquement diminuer son empreinte écologique.
Et avec la peur de l'emission du CO2, on va créer un marché ! Il est en train de naitre sous nos yeux. On va apprendre à utiliser du solaire, avec peu d'empreinte écologique (bon le photovoltaique, c'est pas encore, il faut 20 ans pour rembourser l'énergie qu'il a consommé à la production).
Donc que les gens soient de plus en plus conscient du mur, et croient que le CO2 est un problème, m'arrange, car toute notre société étant basé sur une consommation énergétique produisant ce gaz, c'est au centre de tout, et ça nous obligera à nous comporter autrement.
Que ce soit vrai ou faux, peu importe, du moment que les gens y croient.
Désolé pour le cynisme, et je promet qu'il n'y a aucun mépris là dedans.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est clair.
Il suffirait qu'on maintienne un outil pour vérifier que le driver soit bien propre, respecte bien les interfaces.
Le fait que les ABI changent tout le temps décourage définitivement les industriels, qui en plus de se foutre complètement d'écrire un driver pour un os qui a 2% du marché, on pas envie de le faire parce que c'est inmaintenable ou être obligé de le libérer.
Résultat, l'utilisateur gueule parce que sa carte wifi marche pas, et les windowsiens sont bien mort de rire quand tu parles d'installer Linux sur la machine de madame Michu...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ce logiciel est aussi pas mal, très simple, on envoi un code à un ami qui est ajouté et le transfert commence.
Le seul danger est l'option de config, les amis de mes amis sont mes amis, heureusement optionnelle.
J'ai récupéré qq Go avec. Et c'est rapide, ton ami en face a 100 ko de bande passante montant, s'il ne configure pas une limite, il envoi à 100ko.
Par contre, c'est un fichier par personne à la fois (mais on peut tl plusieurs fichiers chez plusieurs personnes évidemment).
Je pense que c'est indétectable, surtout qu'il y a une option cryptage.
J'aimerai bien une explication sur le pourquoi de la nazitude de l'argument du monsieur plus haut, parce qu'il m'a assez convaincu. Pas pour la forme de la doc, mais pour l'idée que je préfère faire pêter la compil plutôt que le runtime.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai été sensibilisé au contrats avec SmartEiffel et Lisaac, et Mildred nous a jour secoué les méninges afin qu'on distingue ce qui relève du contrat pré et post, et des exceptions.
L'exemple que tu cites est de l'ordre du contrat et non de l'exception.
Amha (pour le moment), l'exception sert à gérer les erreurs externes qui perturbent le bon déroulement d'un programme : plus de place sur le disque, plus de mémoire, on arrive pas à établir ou à garder la connexion, etc...
Là, c'est une erreur interne du programme : certains des argument sont à Null.
C'est un contrat qui doit être posé pour péter s'il y a erreur.
En java, il y a assert, mais c'est pas hérité. Et on a pas de mot clé Old qui permet de comparer l'état d'un paramètre au début avec ce paramètre modifié en sortie.
Sur l'entorse à la théorie, là encore, c'est une histoire de contrats... au niveau de l'objet.
En Eiffel, l'invariant de classe http://en.wikipedia.org/wiki/Class_invariant permet de vérifier à tout moment que le contrat est respecté.
Je pense que ça peut apporter une solution au problème posé par Zul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'était la faute d'hibernate, enfin plus exactement de la faute du fait que les dev ne veulent absolument pas savoir ce qu'il y a derrière et ont fait n'importe quoi.
Si je me souviens bien, ça provoquais un delete récursif, voire cyclique. Je me souviens plus trop, faudrait que je rattrape le copain qui m'avait expliqué ça.
Les développeurs *aiment* Hibernate, certes. Mais les fonctionnels beaucoup moins.
Un ami fonctionnel m'a raconté comment il a envoyé bouler Hibernate sur un projet, où un simple delete prenait.... 2 jours..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je reconnais tout ce que j'ai vu en entreprise, DTO, DAO, DTA, Services, vue..
Je comprend bien la nécessité (mais il semble que ceux qui se sont creusés la tête ont trouvé des concepts plus intéressant), mais l'implémentation me dérange.
Je la trouve inutilement lourde.
Par exemple, pourquoi ne pas mettre une fichier java à la place du xml. Vue le niveau de profondeur (de l'arbre) du fichier de conf xml de spring, ça devrai pas poser de problèmes.
Ca éviterai les emmerdes avec les typos, où tu comprend pas pourquoi ce foutu DTA se charge pas, parce qu'il y a une erreur d'un caractère dans le fichier de conf xml, qui bien entendu est examiné à l'exécution, et est bien sûr pas foutu de te donner un message d'erreur clair qui te dit "tu t ptet planté dans l'appellation de l'objet ou de sa méthode, regarde voir le fichier de conf".
Bah non, a moins d'y avoir passé 2 ans, et d'être auréolé de la gloire d'être l'expert javouille dans la boite, tu galères et perd du temps con parce que le fichier de conf est pas lu avant que l'appli démarre.
Et me dit pas que charger un .class à chaud dans une appli c'est difficile.
Une VM ça sert à ça.
Et ça s'automatise très bien.
Ya plein de langages où ça pose pas de problèmes.
Non, là, tout une couche monstreuse d'introspection pour faire un truc de base.
Sans compter la désespérante et insupportable inflation d'objet.
Ya en dans les sens ! 20 classes pour les collection, au minimum 5 pour les chaines.
T'as trois fonction qui se battent en duel dans les libs de base (String, List).
Les int, boolean pas objet, etc...
Bref, je diverge.
Java est un langage très limité, pas expressif, et t obligé d'utiliser des usine à gaz pour faire un truc simple.
Ca marche oui, mais c'est très lourd.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Tiens, je vais mettre les deux pieds joint dans le troll.
Personnellement, j'aime beaucoup SQL. C'est un vieux langage, qui as pas trop mal évolué ces derniers temps, qui a certes ses limites (pas de possibilité de jouer avec les résultats en ligne, pas possibilité de "doublonner" une même table dans le from, etc...), mais qui reste très puissant pour exprimer en 2mn des trucs hyper gonflant à écrire avec des boucles imbriquées - et moins error prone.
Je sais que je suis minoritaire, et que les j2ee fan boy aiment pas ça en général.
Mais si c'était intégré en natif dans les langages, à la HQL/LINQ/whatever (d'aileurs ça commence à venir), et qu'on prenait l'habitude de les utiliser, l'industrie de l'informatique de gestion ferait beaucoup de gains de productivité.
Et tu verrai que tu te prend beaucoup moins la tête à faire deux not in imbriqué en déclaratif, que d'écrire ta boucle qui risque de péter à cause de call on null....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
Mais plus tu globalise mieux c'est.
Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Ben, on fait pareil, vu que c'est du C derrière.
Comment ils font en Eiffel d'après toi.
Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
La chaine de production est là. Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté. Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
Chez nous, ça s'appelle "shorter".
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
Introspection, voir plus haut.
chargement dynamique (plugins) : C'est quoi ?
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
déploiement à distance : C'est quoi ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- Qu'est ce que spring a de crade? L'IoC, dependancy injection et tout le tralala, c'est quand meme vachement elegant et rudement pratique pour des grosses applis.
Pratique, c'est pas faux, élégant, j'en suis moins sûr.
A débugger, en restant des heures coincés dans les couches de spring quand tu veux tomber simplement passer de l'appel de fonction à la fonction elle même, c'est moins élégant déjà.
Et j'aime pas (mais c'est personnel) les goto cachés.
N'empêche que ça ressemble énormément à un workaround sur les limites de langages à classe. (troll open)
Et que ce soit au niveau de l'architecture ou du code, spring est clairement un tres bon exemple d'elegance.
Les fichiers de conf en xml c'est l'horreur et surtout pas élégant, pas human readable en tout cas.
Spring Webflow le pire de tous, avec ses fichiers de conf d'interface et tout le bordel que ça implique derrière (appel de fonction avec ses paramètres tordus et ses histoires de scope), c'est surtout pas élégant.
M'enfin je comprend que ça fasse tripper les ingénieurs, c'est le plus pure style d'usine à gaz d'ingénieurs typiques.
- Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate. La on se débarasse carrement de cette daube de sql.
Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème. J'en suis heureux pour toi. Moi je préfère SQL : j'aime jouer avec les ensembles (intersection, différence, etc...), et je suis très à l'aise avec ça.
HQL est pas mal, et j'aimerai bien le voir intégré au langage (cela dit je n'y toucherai pas : depuis que j'ai claqué la porte à la capa java dans ma boite, hors de question que je retouche à ce langage pourri). LINQ est intéressant à ce titre, puissant, mais asez tordu.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...)
Si les scope, ou comment mettre les trucs crade de spring (injection d'objet à l'init) en natif dans le langage.
Bref, faudrait que je creuse plus, mais ça m'a l'air d'un mélange de tous les trucs crades et dépassé de java/C#, mélangé avec les bidouilles à la spring qui sont là pour pallier aux limites de ces langages.
Mais l'idée de les intégrer en natif est intéressante.
Non, pour moi un truc vraiment nouveau serait :
- Objet à frame, avec pose de contraintes entre les membres de chaque objets
- Un sql intégré, minimum
- Une sémantique orienté agent. Ie. pourvoir définir des agents autonomes interragissant entre eux avec des règles
- Un moteur de règles avec résolution, détection de conflit à la compil
Bon aller, je --> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Dans tous compilateur utilisant de la compilation globale (Smarteiffel, Pypy peut être, Lisaac, et bien d'autres), tu bénéficies d'ors et déjà des optims sur le bouts de code que tu utilises, par rapport à des langages à JIT (ou AOT). Ie. Toute l'utilisation de ta lib est optimisée par le compilateur qui :
- N'embarque que le code que tu utilise dans ta lib
- Optimise l'utilisation de celui-ci
Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main). Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau (des collections type array, liste chainées, tables de hashage, etc...)
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Ils font comment quand ils développent en C/C++ ?
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
De plus, c'est débile comme argument :
Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte. Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
Tu as un debugger intégré en SmartEiffel, embarqué dans le code.
Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.
Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
A ces deux affirmation je répond : Pour tout langage qui font de la compilation globale (et par exemple génèrent du C), et il y en a qqun, il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé.
Smart Eiffel le fait.
Alors il est vrai que de la compil globale fait bouger assez facilement pas mal de chose, mais pas toujours.
C'est donc un faux problème, ou en tout cas aisément contournable.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
De plus, la version en préparation/test gère maintenant assez bien l'interface avec le monde extérieur.
Il y a quelques réglages à revoir d'ici la release à ce propos, mais on peut sans trop de problèmes générer des .o et les linker ensemble de sortes à ce qu'ils se parlent (via la section external).
Il reste à faire en sorte que ce soit manipulable aisément par le programmeur, qui devra s'assurer à la main que les interfaces puissent discuter ensemble.
La gestion de l'interface avec des programmes C classiques a été grandement améliorée et fonctionne assez bien maintenant (problèmes de gestion de la mémoire essentiellement).
On peut même générer des modules linux !
Le fait de pouvoir générer des lib C en lisaac et pouvoir les linker de manière classique tiendra lieu de compilation séparée dans un premier temps.
Au pire, pour vérifier l'interfacage, on pourra lancer un début de compilation globale sur le tout, et séparer en petit morceau si le compilateur ne trouve rien à redire.
Dans un second temps, ce sera essentiellement un problème de performance ie. comment ne pas faire chuter les perfs parce que chaque partie du programme n'a pas été optimisé en fonction des autres.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je constate pas mal de problème sous FF3.5 : impossible d"atrapper" la barre du bas, qui clignote.
La zone, à gauche, avec les liens permettant de créer un journal, etc... n'est pas accessible non plus (clignotement)
Je ne pense pas que le fait que ce soit sous mac soit significatif.
J'essaierai sur une machine windows au boulot.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
1/ Dans le papier que je cite, on explique pourquoi le fait d'avoir de l'héritage dynamique permet de simplifier le design et réduire l'empreinte mémoire (un seul parent à la fois). Sur 3 niveaux d'héritage la combinatoire explose vite, et ça devient vite intéressant.
2/ Ca dépend comment c'est implémenté : si c'est de la CFT à la mano en C, les perfs sont catastrophiques (les processeurs, mêmes modernes ont du mal à optimiser une fonction dont l'adresse est dans pointeur en mémoire et non en statique). Mais je pense pas qu'ils aient fait comme ça.
Le sujet de mon troll est fondamentalement : il me parait difficile à un humain d'écrire un C lisible qui permette de profiter des optims d'un C illisible mais optimisé au mieux qui serait généré par un compilateur.
Mais je te laisse le bénéfice du doute, vu le niveau de compétence impressionnant des codeurs du noyau.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je sais qu'il est horrible, mais il sera remis à jour en temps voulu.
Sinon, je te ferai la même réponse que GCU : tout le monde n'est pas hyper fort en HTML, toussa
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Et il y aurait des vidéos ?
Posté par Ontologia (site web personnel) . En réponse au journal mes présentations: à l'OSDC, et jeudi prochain. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# C'est peut être faux, mais ça m'arrange que les gens le croient
Posté par Ontologia (site web personnel) . En réponse au journal [HS] Pour en finir avec le réchauffement climatique anthropique.... Évalué à 2.
Peut être que Courtillot a raison. Je ne suis pas spécialiste et après tout je n'en sais rien.
Par contre, il est très important que les gens le croient, en grande partie pour les raisons qu'a exposé grid (premier commentaire : http://www.linuxfr.org/comments/1071796.html#1071796 )
Faire flipper les gens sur la production de carbone est la meilleur solutions pour contraindre les comportements avec qq chose de mesurable, l'idéal étant néanmoins que les gens comprennent la notion d'empreinte globale (ie. la Toyota Prius est certes écolo à l'utilisation, mais hyper poluant à la fabrication et à la destruction. Des exemples de ce genre, il y en a plein).
Ca permettra aussi de relocaliser, et d'éviter les situation débiles où on achète des trucs fabriqué au bout du monde, parce que l'énergie (fossile) ne coute pas cher, alors que l'usine d'à côté fabrique la même denrée pour la vendre à 2000 km.
Ou les tomates en hiver, etc....
Ca permettra encore d'apprendre aux citadin de se passer de voiture - j'ai encore pas mal d'amis qui l'utilisent pour un oui ou pour un non.
Parce que, si on prouve que le CO2 n'a rien à voir, qu'est-ce qui va se passer ?
A bah, c'est de la faute des volcans ma bonne dame, on y peut rien, donc c'est cool, on va pouvoir continuer à foutre le bordel autant qu'on veux ! Génial !
Si notre civilisation veut survivre, il lui faut apprendre à drastiquement diminuer son empreinte écologique.
Et avec la peur de l'emission du CO2, on va créer un marché ! Il est en train de naitre sous nos yeux. On va apprendre à utiliser du solaire, avec peu d'empreinte écologique (bon le photovoltaique, c'est pas encore, il faut 20 ans pour rembourser l'énergie qu'il a consommé à la production).
Donc que les gens soient de plus en plus conscient du mur, et croient que le CO2 est un problème, m'arrange, car toute notre société étant basé sur une consommation énergétique produisant ce gaz, c'est au centre de tout, et ça nous obligera à nous comporter autrement.
Que ce soit vrai ou faux, peu importe, du moment que les gens y croient.
Désolé pour le cynisme, et je promet qu'il n'y a aucun mépris là dedans.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Il suffirait qu'on maintienne un outil pour vérifier que le driver soit bien propre, respecte bien les interfaces.
Le fait que les ABI changent tout le temps décourage définitivement les industriels, qui en plus de se foutre complètement d'écrire un driver pour un os qui a 2% du marché, on pas envie de le faire parce que c'est inmaintenable ou être obligé de le libérer.
Résultat, l'utilisateur gueule parce que sa carte wifi marche pas, et les windowsiens sont bien mort de rire quand tu parles d'installer Linux sur la machine de madame Michu...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ca me fait penser ...
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Alliance p2p
Posté par Ontologia (site web personnel) . En réponse au journal La technologie permettant à Madame Michu de contourner Hadopi déjà disponible!. Évalué à 3.
Le seul danger est l'option de config, les amis de mes amis sont mes amis, heureusement optionnelle.
J'ai récupéré qq Go avec. Et c'est rapide, ton ami en face a 100 ko de bande passante montant, s'il ne configure pas une limite, il envoi à 100ko.
Par contre, c'est un fichier par personne à la fois (mais on peut tl plusieurs fichiers chez plusieurs personnes évidemment).
Je pense que c'est indétectable, surtout qu'il y a une option cryptage.
En plus c'est multiplateforme, chose qui était indispensable pour convaincre pas mal de copains..
http://sourceforge.net/projects/alliancep2p/
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 4.
L'exemple que tu cites est de l'ordre du contrat et non de l'exception.
Amha (pour le moment), l'exception sert à gérer les erreurs externes qui perturbent le bon déroulement d'un programme : plus de place sur le disque, plus de mémoire, on arrive pas à établir ou à garder la connexion, etc...
Là, c'est une erreur interne du programme : certains des argument sont à Null.
C'est un contrat qui doit être posé pour péter s'il y a erreur.
En java, il y a assert, mais c'est pas hérité. Et on a pas de mot clé Old qui permet de comparer l'état d'un paramètre au début avec ce paramètre modifié en sortie.
Sur l'entorse à la théorie, là encore, c'est une histoire de contrats... au niveau de l'objet.
En Eiffel, l'invariant de classe http://en.wikipedia.org/wiki/Class_invariant permet de vérifier à tout moment que le contrat est respecté.
Je pense que ça peut apporter une solution au problème posé par Zul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
c : CAT := CAT.create "Fritz" age 9 nombre_de_patte 4 poids 5 surnom "chatchat" prix_a_la_decoupe 150 date DATE.today;
C'est moins verbeux :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
Si je me souviens bien, ça provoquais un delete récursif, voire cyclique. Je me souviens plus trop, faudrait que je rattrape le copain qui m'avait expliqué ça.
De ce que j'en avais compris à l'époque, c'était la plus pur application de ce problème : http://www.joelonsoftware.com/articles/LeakyAbstractions.htm(...)
(sur le fait que hibernate connaisse mieux que toi et moi les bdd, oui evidemment, mais ce n'est pas le problème)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 1.
Un ami fonctionnel m'a raconté comment il a envoyé bouler Hibernate sur un projet, où un simple delete prenait.... 2 jours..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 4.
Je comprend bien la nécessité (mais il semble que ceux qui se sont creusés la tête ont trouvé des concepts plus intéressant), mais l'implémentation me dérange.
Je la trouve inutilement lourde.
Par exemple, pourquoi ne pas mettre une fichier java à la place du xml. Vue le niveau de profondeur (de l'arbre) du fichier de conf xml de spring, ça devrai pas poser de problèmes.
Ca éviterai les emmerdes avec les typos, où tu comprend pas pourquoi ce foutu DTA se charge pas, parce qu'il y a une erreur d'un caractère dans le fichier de conf xml, qui bien entendu est examiné à l'exécution, et est bien sûr pas foutu de te donner un message d'erreur clair qui te dit "tu t ptet planté dans l'appellation de l'objet ou de sa méthode, regarde voir le fichier de conf".
Bah non, a moins d'y avoir passé 2 ans, et d'être auréolé de la gloire d'être l'expert javouille dans la boite, tu galères et perd du temps con parce que le fichier de conf est pas lu avant que l'appli démarre.
Et me dit pas que charger un .class à chaud dans une appli c'est difficile.
Une VM ça sert à ça.
Et ça s'automatise très bien.
Ya plein de langages où ça pose pas de problèmes.
Non, là, tout une couche monstreuse d'introspection pour faire un truc de base.
Sans compter la désespérante et insupportable inflation d'objet.
Ya en dans les sens ! 20 classes pour les collection, au minimum 5 pour les chaines.
T'as trois fonction qui se battent en duel dans les libs de base (String, List).
Les int, boolean pas objet, etc...
Bref, je diverge.
Java est un langage très limité, pas expressif, et t obligé d'utiliser des usine à gaz pour faire un truc simple.
Ca marche oui, mais c'est très lourd.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 4.
Personnellement, j'aime beaucoup SQL. C'est un vieux langage, qui as pas trop mal évolué ces derniers temps, qui a certes ses limites (pas de possibilité de jouer avec les résultats en ligne, pas possibilité de "doublonner" une même table dans le from, etc...), mais qui reste très puissant pour exprimer en 2mn des trucs hyper gonflant à écrire avec des boucles imbriquées - et moins error prone.
Je sais que je suis minoritaire, et que les j2ee fan boy aiment pas ça en général.
Mais si c'était intégré en natif dans les langages, à la HQL/LINQ/whatever (d'aileurs ça commence à venir), et qu'on prenait l'habitude de les utiliser, l'industrie de l'informatique de gestion ferait beaucoup de gains de productivité.
Et tu verrai que tu te prend beaucoup moins la tête à faire deux not in imbriqué en déclaratif, que d'écrire ta boucle qui risque de péter à cause de call on null....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
Mais plus tu globalise mieux c'est.
Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Ben, on fait pareil, vu que c'est du C derrière.
Comment ils font en Eiffel d'après toi.
Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
La chaine de production est là.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté.
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
Chez nous, ça s'appelle "shorter".
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
Introspection, voir plus haut.
chargement dynamique (plugins) : C'est quoi ?
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
déploiement à distance : C'est quoi ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 4.
Pratique, c'est pas faux, élégant, j'en suis moins sûr.
A débugger, en restant des heures coincés dans les couches de spring quand tu veux tomber simplement passer de l'appel de fonction à la fonction elle même, c'est moins élégant déjà.
Et j'aime pas (mais c'est personnel) les goto cachés.
N'empêche que ça ressemble énormément à un workaround sur les limites de langages à classe. (troll open)
Et que ce soit au niveau de l'architecture ou du code, spring est clairement un tres bon exemple d'elegance.
Les fichiers de conf en xml c'est l'horreur et surtout pas élégant, pas human readable en tout cas.
Spring Webflow le pire de tous, avec ses fichiers de conf d'interface et tout le bordel que ça implique derrière (appel de fonction avec ses paramètres tordus et ses histoires de scope), c'est surtout pas élégant.
M'enfin je comprend que ça fasse tripper les ingénieurs, c'est le plus pure style d'usine à gaz d'ingénieurs typiques.
- Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate. La on se débarasse carrement de cette daube de sql.
Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème. J'en suis heureux pour toi. Moi je préfère SQL : j'aime jouer avec les ensembles (intersection, différence, etc...), et je suis très à l'aise avec ça.
HQL est pas mal, et j'aimerai bien le voir intégré au langage (cela dit je n'y toucherai pas : depuis que j'ai claqué la porte à la capa java dans ma boite, hors de question que je retouche à ce langage pourri). LINQ est intéressant à ce titre, puissant, mais asez tordu.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Rien de transcendant dirait-on
Posté par Ontologia (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 2.
Un bête langage à classe
Dans http://code.google.com/p/noop/wiki/ProposalForErrors un sucre syntaxique pas bête consistant à récupérer le résultat ET l'erreur.
La fonction renvoi deux valeurs. Rien de très nouveau.
Dans http://code.google.com/p/noop/wiki/ProposalForTestingApi
Un machin sucre syntaxique dans la grammaire en dur (beurk caca) pour que le test ait l'air d'être écrit en anglais
Un langage avec des thread (dépassé, voir mémoire transactionnel, Scoop, etc...)
Si les scope, ou comment mettre les trucs crade de spring (injection d'objet à l'init) en natif dans le langage.
Bref, faudrait que je creuse plus, mais ça m'a l'air d'un mélange de tous les trucs crades et dépassé de java/C#, mélangé avec les bidouilles à la spring qui sont là pour pallier aux limites de ces langages.
Mais l'idée de les intégrer en natif est intéressante.
Non, pour moi un truc vraiment nouveau serait :
- Objet à frame, avec pose de contraintes entre les membres de chaque objets
- Un sql intégré, minimum
- Une sémantique orienté agent. Ie. pourvoir définir des agents autonomes interragissant entre eux avec des règles
- Un moteur de règles avec résolution, détection de conflit à la compil
Bon aller, je --> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
- N'embarque que le code que tu utilise dans ta lib
- Optimise l'utilisation de celui-ci
Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main). Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau (des collections type array, liste chainées, tables de hashage, etc...)
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
par exemple :
http://www2.lifl.fr/lmo2004/slides_lmo2004/privat.pdf
http://docs.google.com/gview?a=v&q=cache:onvvYLCD35UJ:ww(...)
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Ils font comment quand ils développent en C/C++ ?
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
De plus, c'est débile comme argument :
Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte.
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
Tu as un debugger intégré en SmartEiffel, embarqué dans le code.
Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.
Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
A ces deux affirmation je répond : Pour tout langage qui font de la compilation globale (et par exemple génèrent du C), et il y en a qqun, il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé.
Smart Eiffel le fait.
Alors il est vrai que de la compil globale fait bouger assez facilement pas mal de chose, mais pas toujours.
C'est donc un faux problème, ou en tout cas aisément contournable.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Il y a quelques réglages à revoir d'ici la release à ce propos, mais on peut sans trop de problèmes générer des .o et les linker ensemble de sortes à ce qu'ils se parlent (via la section external).
Il reste à faire en sorte que ce soit manipulable aisément par le programmeur, qui devra s'assurer à la main que les interfaces puissent discuter ensemble.
La gestion de l'interface avec des programmes C classiques a été grandement améliorée et fonctionne assez bien maintenant (problèmes de gestion de la mémoire essentiellement).
On peut même générer des modules linux !
Le fait de pouvoir générer des lib C en lisaac et pouvoir les linker de manière classique tiendra lieu de compilation séparée dans un premier temps.
Au pire, pour vérifier l'interfacage, on pourra lancer un début de compilation globale sur le tout, et séparer en petit morceau si le compilateur ne trouve rien à redire.
Dans un second temps, ce sera essentiellement un problème de performance ie. comment ne pas faire chuter les perfs parce que chaque partie du programme n'a pas été optimisé en fonction des autres.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Problèmes avec FF3.5 (sous mac)
Posté par Ontologia (site web personnel) . En réponse au journal patrick_g en PDF. Évalué à 3.
La zone, à gauche, avec les liens permettant de créer un journal, etc... n'est pas accessible non plus (clignotement)
Je ne pense pas que le fait que ce soit sous mac soit significatif.
J'essaierai sur une machine windows au boulot.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
2/ Ca dépend comment c'est implémenté : si c'est de la CFT à la mano en C, les perfs sont catastrophiques (les processeurs, mêmes modernes ont du mal à optimiser une fonction dont l'adresse est dans pointeur en mémoire et non en statique). Mais je pense pas qu'ils aient fait comme ça.
Le sujet de mon troll est fondamentalement : il me parait difficile à un humain d'écrire un C lisible qui permette de profiter des optims d'un C illisible mais optimisé au mieux qui serait généré par un compilateur.
Mais je te laisse le bénéfice du doute, vu le niveau de compétence impressionnant des codeurs du noyau.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le troll
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le troll
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
Sinon, je te ferai la même réponse que GCU : tout le monde n'est pas hyper fort en HTML, toussa
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker