Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Tu ne les lance pa stous mais tu est très doué pour les entretenir.
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ?
Oui je sais ce que je cherche, mais le probleme c'est que tu as l'air de mieux le savoir que moi :
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
Sauf que si j'ai eu besoin de faire plusieurs compilation avec des log différents c'est justement parce que le volume de log est monstrueux. Donc je devais sélectionner quoi logger et le comparer aux logs valides. Donc ta trace elle peut faire ce quelle veut elle pourra pas deviner toute seule quoi logger.
Pour ce qui de ton système de dimension sur les données, avec les assertions, etc... va falloir que tu développe parce que dans le cas précisdont je parle, je ne vois absolument pas a quoi ça peut servir.
Donc... De plus, es-tu sûr de vraiment savoir ce que tu cherches ?</Ii ...oui moi je sais ce que je cherche et tu me propose des choses qui ne me conviennent pas et qui en plus ne sont pas présentes dans Lisaac. Donc en gros tu me dit : « tu veut ça, donc je te propose ceci qui ne résoud pas ton problème et que je ne sais même pas faire, donc j'ai raison » et après tu veut me faire croire que tu ne troll pas ?
Sachant qu'en plus ce n'est qu'un exemple de cas ou une compilation séparée et utile. Il en existe plein d'autre. Est-ce que pour chacune d'entre elle tu vas me dire, que l'on pourrait implemeter tel truc qui ne résoud pas le problème mais c'est pas grave ?
Par exemple, un code plein d'assertion ou de contrat dans une boucle critique peu se trouver devnir extrèmement lent, donc une foi ce module debuggé, j'aime désactiver les assertions dans ce module. Est-ce que lisaac peut gérer des options de compilation différentes en fonction du module ?
"+" à la place d'un "-", je veux bien comprendre que cela soit difficile à attraper statiquement, mais cela dépend aussi de comment tu écris ton contrat. Il y a des contrats ou tu utilises des propriétés à conserver, genre "f(a,b)=f(b,a)", cela permetrait d'attraper certaine erreur dans les équations. On pense aussi mettre une lib qui vérifie la dimension physique des opérations (cela n'aura pas le + à la place du -, certe).
Le problème c'est les «il y a des», «cela permetrait», «on pense aussi». Cela ne couvre qu'une partie des erreurs. Il va toujours en rester et il faut bien pouvoir les debugger celles la.
Et sur la masse total d'erreur ?
Ce n'est pas vraiment imprtant. On doit surement pas être loin de la regle des 80/20 ici ausssi. C'est-à-dire 20% des bugs représentent 80% du temps de débuggage. Dans mon code, j'ai des assertion pour vérifier l'indicage des tableaux et autre conneries du même style, donc généralement tous ces bigs sont résolus très rapidement.
Par contre, les bugs de logique me demandent souvent beaucoup de temps. Là ou en Lisaac je purais mettre un contrat, en C je peut mettre une assertion, donc la manière de faire est différente mais le résultat est proche.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Même si c'est cas ne représentent au final que 1% du nombre d'erreur, à eux seul ils peuvent représenter l'essentiel du temps de debuggage.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
Sur mes programmes, je monte rarement à plus de deux ou trois minutes de compilation, donc pour moi ce n'est pas vraiment un problème, mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
À mon avis, c'est le genre de truc indispensable si vous voulez que Lisaac perce pour de gros projets.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile).
Le problème c'est qu'un debuggeur est très pratique pour certains type de bug, mais pas tous. Si je prend un cas que j'ai eu jeudi dernier. Je code un algo en C car la quantité de calcul est monstrueuse et j'ai besoin que ce soit relativement rapide.
Avant de faire l'implémentation en C, j'en ai fait une sous Octave qui m'a permis de le coder de manière très rapide et bien plus sure. La version sous Octave à été beaucoup plus simple à debugger, et je sais maintenant que le résultat qu'elle me sort est correcte même si elle y passe des heures sur de petites données d'entrée.
La version en C me sortait un résultat différent, donc il y a un bug. Pour débugger, j'ai sortit plusieur logs des différents calculs intermédiaires fait par la version en Octave. Dans ces log j'ai des matrices gigantesques, donc impossible de faire un gdb et de lui demander de m'afficher les matrice et de comparer à la main.
J'ai recompiler plusieurs version du programme en C, dans lequel je sort aussi des logs, pour trouver ou ce situe le problème et voir à quel endroit il y a une différence.
GDB est très utile quand tu as un bug bien localisé, c'est-à-dire, un bug ou tu peut mettre un point d'arret très près de l'enroit ou ce produit le bug, ou une surveillance sur une donnée quand tu sait qu'elle va prendre une valeur interdite. Mais dans mon cas, et je suis souvent confronter à ce genre de problème, ce n'est pas un segfault ou autre, le programme est parfaitement correct, c'est juste qu'il traite de grosse quantitées de donnée et ne fait pas le bon calcul sur certaines d'entre elles.
Il faut bien comprendre qu'il n'y a pas une seule bonne manière de debugger.
Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Et comme d'habitude, la réponse classique est à côté de la plaque ;-) Si tu veux nous vendre Lisaac avec comme argument «il ne fait que de la compilation globale parce que c'est meilleur pour les optims» il faut bien t'attendre à avoir des remarques sur le «que»...
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant... Et pour prouver que je suis de bonne foi, il y a eu une news qui m'avait même fait tester Lisaac. Je l'avais installer, porter si je me souvien bien, deux codes de calculs et donner les résultats en commentaire de mes petits benchs.
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
Pour ce qui est de ce journal, je parlais de javascript, mais j'avais surtout en tête, l'impression qui ressort de l'ensemble des journaux et news sur Lisaac. Quasiment à chaque fois on à vraiment l'impression que seul Lisaac est un bon langage et que le reste est de la merde à vous lire.
C'est ça que je n'apprécie pas...
Oui mais les bugs sont attrapé par le compilo en majorité. Une grosse parti de la compile pour être mis en cache.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur. Si dans ton programme tu remplace une addition par une soustraction, ton compilo n'a aucun moyen de savoir qu'il y a un bug.
Et ce genre de bug me demande souvent des faire de tres nombreuses compilations pour obtenir des sorties intermédiaires, faire des vérifications et autres.
Quand tu vois le temps de compilation d'un gros projet avec la compilation séparée, tu comprend que l'on soit septique quand on nous dit que lisaac ne sait pas gérer autre chose qu'une compilation globale.
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
Ensuite concernant faire un tour sur le web, tu tombes sur la page wikipedia. Et souvent sur des très trucs pointus, c'est pas la joie.
J'ai bien préciser, à la faois dans le message auquel tu répond et dans plusieurs autres sur cette page que je parlais bien d'aller voir ailleur que sur wikipedia : Tu va faire un tour sur le net (et pas que wikipedia)
Il y a beaucoup de gens tout aussi respectable que ta source qui pense que javascript est un langage à prototype.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Les news et journaux sur Lisaac, j'ai du à peu près tous les voir et même participé à plusieurs d'entre eux, et c'est pour ça que je me suis permit de te donner mon avis sur ton comportement. Et je le maintient.
Tu dira ce que tu veux, mais sur ce journal, le plus obtus et trolleur, ça reste toi. La personne qui semble le plus vouloir dénigrer les autres langage, c'est toi. Ce n'est peut-être pas ton intention, mais c'est comme ça que moi je le perçoit, et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Pour avoir une taille critique il faut attirer les gens, et pour cela il faut leur donner envie de tester le langage, et de rejoindre une comunautée. Donc tu commence par essayer de donner une bonne image des deux, pour cela on commence par ne pas dénigrer les autres langages. Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Je passerai sur l'aspect gourou puisque ça plait à certains, mais le fait d'avoir un boulot ou de bosser d'en une autre branche n'empêche pas d'assumer ses conneries.
Être du domaine n'apporte qu'une chose, réduire les risque de dire des conneries, mais une fois qu'elles sont dite, quel que soit le context, c'est pas dur de les assumer.
Ce que je trouve génial avec le message 2 que tu cite c'est que :
- il confirme l'impression que donne Nicolas Boulay de la communauté Lisaac. Ce genre de ton dédaigneux et compatissant j'ai du mal ;
- il prouve que l'on a donné a Nicolas Boulay avant hier soir un debut d'argument (pas trés convaincant mais bon...) et qu'il n'a pas daigné le recopier ici.
Bah oui mais faut pas venir ce plaindre après. Que tu lui ait gait confiance pas de problèmes, bien au contraire ces normal. Le truc c'est que moi aussi j'ai une thèse et des publis et c'est pas pour ça que je ne me trompe jamais, même sur mon sujet de recherche.
Ce que je te reproche, ce n'est pas de t'être trompé au départ, mais ton attitude gamine après qui à été de ne pas vouloire reconnaître qu'un truc clochait.
C'est simple, quand on te dit «si, si, il y a plein de gens fiable qui pensent que javascript est un langage a prototype et qui le disent sur internet» tu as trois choix valables :
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
Depuis le debut tu ne fais qu'affirmer sans argumenter au contraire des commentaires qui te répondent, donc permet moi d'avoir des doutes sur ce que tu dis.
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
Je suis pas dur, je suis réaliste.
Sur la phrase qui fait débat, tout le monde ne peut pas avoir raison. Soit Lisaac est le premier, soit il ne l'est pas, et de mon point de vue, on a amené uffisament d'éléments indiquant qu'il ne l'est pas.
Ce que je lui reproche n'est pas d'avoir eu tord au début, mais de ne pas l'admettre et justement d'avoir poluer son journal avec cette discution pas plus intéressante que ça et montrer ça mauvaise foi. C'est très typique des membres de la comunauté Lisaac qui s'expriment sur LinuxFR.
Je ne conclu pas que Lisaac est mauvais, ce que je conclus c'est que je ne retournerais pas voir ce langage vu la comunauté qu'il y a autour. Une comunauté est indispensable pour qu'un langage ce dévelope. Et vu que je n'ai pas trop de temps à perdre, je mefais une idée de la comunauté autour de Lisaac en regardant le comportement de l'échantillon que l'on à sur LinuxFR.
C'est très approximatif comme méthode, mais c'est réaliste. Des langages intéressants il y en a un paquet. Je n'aurais jamais le temps de tous les regarder en détail, donc tout ce qui me permet de faire un tri est bon à prendre.
C'est comme un DRH devant une pile de 500 CVs. Il ne peut pas tous les étudier en détails et convoquer toutes les personnes pour un entretien. Donc il fait le tri, un premier passage sur la pile et tous les CVs qui ont été fait à la rache avec de grosses fautes dans les titres, ça donne pas l'impréssion que le mec est serieux, donc direct à la poubelle. (on va pas entrer dans le débat des autres critères très discutables)
Java, c'est un langage a VM, meme si la spec du langage en soit est techniquement decorrelle de la vm, mais je n'arrive pas a imaginer un seul interet a implementer le langage en dehors de la vm. De meme, j'ai jamais compris a quoi pouvait bien servir gcj (bon, ok, jvm pas libre tout ca, mais c'est plus le cas).
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
Tout dépend du point de vue. Il y a de très grandes quantités de code java disponible que tu n'as pas forcément envie de réécrire, mais en même temps tu en as peut-être rien à foutre de la portabilitée car tu es sur une plateforme figée : ton desktop par exemple.
Dans ce cas, avec gcj tu profites du code tout en ayant les avantages d'un code directement natif.
Il faut bien voir que la portabilité c'est un concept qui existe au moment de la difusion, mais beaucoup moins dans de nombreux cas d'utilisation. Quand on écrit du code on veut qu'il marche chez le plus de personnes possibles, quand on l'utilise on veut qu'il marche chez soit.
Une VM permet les deux mais un compilateur tel que gcj permet uniquement le deuxième. L'avantage c'est qu'il n'y a pas à attendre que la VM s charge ou que le JIT produise du code.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
Je pense que les créateurs de Ch ne soient pas d'accord avec toi, et leur bizness dure depuis un bout de temps donc leur clients ne doivent pas être d'accord non plus.
L'avantage de faire tourner du C sur une machine virtuelle c'est que tu éxectues le code dans un environement sécuriser et tu peut inclure l'interpreteur dans un autre programme.
Et comme pour au dessus, du dispose d'une quantité faramineuse de code déjà écrit.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
Et pourtant si, ça aurait un sens. Le programme gagne les avantages de l'environement managé de .net ou de la jvm, et des facilitées de comunications inter langages. Cela permet aussi de cibler des plateformes ou seul ce genre de code est accepté.
Sur android par exemple tu ne peut éxectuer que du code java, ça pourrait être cool d'avoir autre chose. L'exemple est mal choisit puisque c'est une JVM modfié et qu'ils ont sortit un NDK, mais l'idée est là.
Il faut bien voir que natif ou VM c'est des techniques complémentaires qui ont chacune leurs avantages et inconvénients, et à part certaines construction particulière il est généralement possible de ciber l'un ou l'autre indiférament. Disposer des deux est même un avantage pour un langage.
les langages interprétés tel que les premiers basics par exemple. L'interpreteur va lire lire une instruction dans le langage source et l'interpréter avant de passer à la suivante. Le code n'est jamais compilé et cela à pour conséqueces par exemple que l'éxecution du programe commence très rapidement, mais qu'elle est très lente, et qu'une erreur de syntaxe à la ligne 243 ne sera détectée que si cette ligne est éxecutée.
les langages compilés en code natif dans ce cas le code est transformé en code natif pour un processeur donné. On peut faire plein d'optimisation spécifiques mais c'est pas ortable, mais surtout on obtient un binnaire directement utilisable en général, avec souvent des dépendance à des libs externes qui peuvent contenir un runtime.
les langages compilé pour une VM ou la compilation cible une architecture virtuelle. Dans ce cas, on obtient pas un executable indépendant mais un code qui va être executer par une machine virtuelle qui doit être distribuée avec le programme. Cette machine virtuelle va éxecuter des instruction particulière mais ces instruction ne seront jamais transformées en code natif.
En gros, ces 3 la correspondent au 3 catégoreis que tu donnais, mais ce qu'il faut bien voir c'est que il y a compilation dans les deux dernier cas. Ce qui donnait la première ambiguité de la phrase du journal. Mais on va pas s'étaler là dessus, je pense que tou le monde à copris qu'il parlait de compiler en code natif.
Le truc c'est que entre le 2 et le 3 il y a d'autres étapes :
les langage avec JIT la le code pour la machine virtuelle est transformé en code natif au juste avant l'éxécution, donc on a du code pour une VM mais qui devient du code natif. Sans vraiment le dire dans le journal, il excluait ce cas là. Donc pour reformuler plus clairement la phrase du journal on en serait à «lisaac est le premier langage à prototype compiler directement en code natif sans jit». Là c'est déjà beaucoup plus discutable comme phrase. C'est un peu plus vrai (mais pas completement) mais considérer le JIT comme n'étant pas vraiment du natif car la conversion est faite tardivement, je suis pas sur que tout le monde sera d'accord, moi le premier, mais bon.
Il y a encore une autre catégorie : les langage un peu mixte que je sais pas comment appeler Dans cette catégorie, il y a les langages dont le compilateur de base cible une VM, mais qui offre aussi un compilateur qui va de cette VM vers du code natif. C'est le principe par exemple du compilateur CLang du projet LLVM. Le compilateur CLang va compiler du C vers la machine virtuelle de LLVM. Ce code peut ensuite être interpreter avec même du JIT, il y a tout ce qu'il faut pour ça dans le projet, mais surtout il peut être compiler vers du code natif, ce qui est le principal interet. Je pense que personne ne prétendra qu'un binnaire produire par CLang n'est pas compilé en code natif.
Et le problème est là... Il y a une implementation de javascript dans .net qui cible une VM et qui offre un compilateur qui traduit le code de cette VM vers du code natif. Donc ça devient dur de modifier la phrase de départ sans qu'elle deviennent ridicule.
Donc on a bien un autre langage «à prototype» compiler vers du «code natif». Histoire de ce rattraper à des branches mortes, on peu encore critiquer les deux choses que j'ai mise entre guillemets.
- Est-ce que javascript est un langage à prototypes ? Personnellement, j'ai trouvé beaucoup de source sur internet avec des gens plus ou moins serieux qui le prétendent. Il n'y a que ici qu'on voit des personnes prétendre le contraire. Donc avant que je considère que ce n'est pas un langage à prototypes, il va falloir un peu argumenter.
- Est-ce que c'est vraiment du code natif ? Indéniablement oui, mais en cherchant bien, il y a une fonction qui est impossible à implémenter directement... la fonction eval en question...
Le problème c'est que, d'une cette fonction utilise le JIT donc, pour pas mal de personne ça va quand même rester du natif, mais on va faire comme si on avait pas vu.
Mais... si on enleve cette fonction, bien sur on a plus tout-à-fait du javascript, on peut appeller le résultat du jvscrpt. Donc on a du jvscrpt qui est compilé en code natif et qui reste un langage à prototype. La fonction eval n'est pas indispensable pour ça. (heureusement car sinon lisaac ne serait pas un langage à prototype...)
Petits exercices de réflexion :
- Lisaac ce sert, si je me souvien bien, de gcc pour compiler le code C qu'il génére. GCC passe, tout comme CLang par une représentation intermédiaire un peu différente mais qui restes une représentation sous forme un peu virtuelle du code que l'on pourrais vaguement interprété à l'aide d'une VM. Est-ce que ça veut dire que Lisaac n'est pas un langage compilé (au sens du journal ?)
- on peut reprocher à l'exemple du javascript de .net de ne faire la compilation que au moment de l'instalation en général. Si on oublit le fait que cette compilaion peut-être faite sur l'ordi du dev, on peut quand même ce demander si dans ce cas un programme compiler par clang en fichier .lm et transformer en code natif au moment de l'instalation est vraiment compiler au sens du journal. Ça voudrait dire que le gestion de paquet qui à été présenter il y a quelques temps dans un autre journal qui proposait justement de faire cela permettrait d'avoir une distrib ou la majoritée des composants ne sont pas compilés au sens du journal ?
Tout cela pour dire que le problème viens, d'une part de l'ambiguité de la phrase du journal. Ambiguité qui ne peut pas être levé sans rendre la phrase fausse. Et d'autre par de la mauvaise foi de son auteur qui ne veut pas admettre qu'il à été un peu vite dans son affirmation.
J'avais préparé un joli message, un peu ironique sur les bord avec une explication sur le fait que eval n'est qu'une fonction du runtime que l'on implémente comme on veux et qui ne change rien au fait que le langage lui même peut être compilé, mais en y réflechissant j'ai tout viré.
J'étais revenu sur le journal histoire de voir ou vous en etiez, et voir si des sujets intéressants était apparus, et je m'apperçoit que tu cherches encore des branches ou te rattraper comme tu peux...
C'est quand même pas la mort d'admetre qu'on c'est trompé surtout sur un truc aussi insignifiant. Le problème de Lisaac, ce n'est pas le langage en lui-même qui, bien qu'ayant des défault, reste un truc sympa. Le problème, sur linuxfr en tout cas, c'est que les gens qui le défende donne vraiment l'impression que le langage ne vaut rien.
Quand je lis un journal comme celui là, tu commence par m'annoncer des trucs sympas sur les nouveautées et autres. Le ton fait «vendeur d'aspirateur» mais c'est le jeu, et il faut savoir lire entre les lignes. L'objectif étant quand même de vendre le langage. Mais quand je lit les commentaires et tes réponses, et sans vouloir généraliser, c'est souvent le cas dans les journaux sur lisaac ; à la moindre critique, un gros mur ce dresse, impossible de discuter.
Il y a une mauvaise fois flagrante quand on lit le thread qui fait que au final je ne retient qu'une seule chose de ce journal : «la comunauté autour de lisaac à toujours pas changé, pas la peine de retourner voir ce que donne le langage, j'ai mieux à foutre»
Si tu avais rapidement admis que en effet la formulation que tu as utilisée n'était pas bonne mais plus vendeuse. Et si à la place de troller tu avais expliquer ce que la manière de faire de lisaac de mieux. Peut-être donné quelques chiffres de perfs ou explqué pourquoi vous penser qu'une compilation native telle que vous la faite est mieux que celle de .net ou qu'un jit ; je serais partis en me disant : «c'est cool, ça bouge lisaac, faudrais peut-être que je retourne voir ce que ça donne»
Tu peut trouver le fait de considérer un langage en fonction de sa communautée débile mais c'est un fait : ça marche comme ça. Et pour deux raisons :
- tester un langage ça implique de prendre du temps pour regarder sa syntaxe, pour apprendre les base, passer un peu de temps pour porter un code à soit pas trop compliquer mais qui vaut le coup, pour voir réellement les perfs et si on se sent à l'aise avec le langage. Tout ça demande du temps, donc il faut donner envie au gens de prendre ce temps, et c'est à la communautée de le faire.
- un nouveau langage ne s'apprend pas du jour au lendemain, on a souvent des galère, besoins de conseil sur comment coder tel ou tel truc, bref toutes les petites choses au jour le jour avant de vraiment maitriser le langage, et pour tout ça il y a souvent besoin de l'aide de la communautée. Donc si des le début tu donnes l'impression que ça va mal ce passer, tu fait fuir tout le monde.
Si je prend mon cas, je programme principalement en C pour tout ce qui est code critique, mais le C n'est pas adapté pour une grosse partie du programme, donc il y a quelques années j'ai cherché un langage de script pour coder tout ce qui n'est pas critique et appeller mon code critique en C.
J'ai choisit Lua alors que je le connaissait quasiment pas et que je n'était pas super fan de la syntaxe, mais derrière il y avait une communauté très ouverte et très réactive. La mailing liste est très active avec un rapport sigal/bruit presque parfait. Les gens sont parfaitement conscient des limitations du langage et ne cherchent pas à les présenter comme une feature ou donner des arguments plein de mauvaise fois, il se contente d'expliquer pourquoi ces comme ça et d'expliquer si ça va changer à l'avenir ou quand passer outre.
Don pour conclure, bon courrage à votre petite communauté autour de lisaac, mais si vous voulez la faire grossir il va falloir faire des éfforts, et si vous préférez rester entre vous, ça sert à rien de poster des journaux à part le vendredi.
Sur le liens que tu indique, il est bien indiqué que c'est une «mise à disposition» et non pas une location. C'est la dessus que joue free. Dans les petite lignes ils parlent même des «détenteur» et non pas des «possesseurs» de la freebox HD.
C'est capilotracté, mais c'est leur argumentaire et on sent qu'il font bien attention ustement aux mots qu'ils utilisent.
Je pense que ce qu'il voulait dire c'est que en général ce genre de protection c'est du pipo. Dans le cas que l'on a ici, il est tout à fait possible, et pas improbable du tout, que ce qui se trouve à l'adresse 0xBF018411 ce soit un CRC du firmware situé à l'adresse 0xBF80000. Mais ça fait plus pro et plus peur d'écrire key à la place de CRC.
En général, les dev ne se font pas chier à coder un vrai système cryptographique à clé publique/privée, il se contente d'une solution simple. Bien sur, il y a de bonne chance que ce soit un peu plus qu'un simple CRC en clair, mais un truc tout con que l'on voit souvent sur ce genre de système est : la clé est sous la forme de deux valeurs : A et B, tu calcule un CRC sur le firmware : C et la verification c'est juste A xor C == B.
L'avantage de cette dernière solution c'est que, soit tu envoie B avec le firmware, soit tu ajoute un entier à la fin du firmware auquel tu met la bonne valeur pour que sa passe. Il y a un minimum de sécurité pour pouvoir dire "on l'a fait" et pour pas que le premier andouille venu tripote trop le matos sans que ce soit super chiant à gérer.
Le fait qu'il affiche plein de message avec des termes de crypto ne veut absolument rien dire. Il pourrait t'afficher un truc super complexe ou il t'indique qu'il fat une négociation de clée avec un serveur distant pour recevoir une deuxième clé qui permet de decoder une partie du firmware qu'il renvoi via un canal sécurisé pour validation qui lui permet d'obtenir la clé décodant le reste de firmware.
Et derière juste des printf avec des sleep, un petit reseau quand même, et hop on indique que tout ok juste parce que l'on a verifier que le premier entier à pour valeur la date d'anniverssaire de la fille du dev...
Moi je dirais que actuellement la situation avec les CPUs est plutôt très bonne pour le libre. Les processeurs sont documentés, les jeux d'instructions sont connus et très bien documentés, les micro-architectures des procs sont elles aussi suffisament documentées pour que l'on puisse optimiser un code prédisant les cache-miss, les erreur de prédictions de branchement les bules dans le pipeline...
Entre la doc des constructeur qui est très fournie et celle que l'on trouve sur le net tels que les exceptionel manuels de agner, on a vraiment tout ce qui faut. Je me souviens même d'une époque ou lorsque l'on achetait un processeur intel, de gros manuels était fournis directement avec... Le seul problème ce trouve entre les constructeurs pour savoir qui a le droit d'implémenter quoi dans son CPU.
Le gros problème ce situe au niveau de toutes les autres puces qui trainent dans notre ordinateur. Ce qui semble parfaitement normale et évident pour le CPU parrait, au constructeurs, completement abhérent pour un GPU ou chipset wifi. D'un point de vue utilisation directe, ça ne me dérange pas car si j'ai les compétence pour exploiter les docs des CPU et m'en servir régulièrement, ce n'est pas le cas por un GPU. J'avais jeter un coup d'oeil, a la foi au doc publier par AMD/ATI et au code disponible, et j'ai abandonné.
Mais ce qui me choque, c'est qu'on se retrouve payer pour un materiel que l'on ne peut pas utiliser. Si seulement pour tous ces trucs, les constructeurs pouvait faire comme pour les CPU.
Et je pris pour que ce ne soit pas l'inverse qui se passe. Imaginez un monde ou les processeurs ne sont plus documentés et ou seul le compilateur d'intel peut compiler des logiciels pour leur plateforme, et de même avec tous les autres CPU....
Et moi, cela me gave de lire des gens qui pinaillent sur des bêtises et qui cassent les trucs innovants et ne font que ça. Comptes le nombre de commentaires sur la page qui demande des précisions et comptes ceux qui cassent sans chercher à comprendre !
Et bien regarde justement la page en question et imagine ce que ça pourrait être si tu était moins borné. On un message qui rétabli une erreur dans un journal, chose très courrante et justifiée. Et derrière il y a toi qui ne veut pas admetre que ta phrase était trop ambitieuse.
J'irais même jusqu'a dire que la remarque de base est très importante. Depuis que les ordinateurs permette d'avoir de bonne perf avec les VM, la notion de code compilé est devenue très ambigue et il faut apprendre a bien différencier la compilation en code natif et pour une VM qui sont très différent de l'interpretation.
Et concernant Javascript, il ne s'agirait pas d'un vrai langage à prototype. C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Justement, tant que tu n'aura pas une bonne argumentation, cet argument ne vaut rien. Je viens de faire un peu de recherche sur le net et il semble que tout le monde soit d'accord sur le fait que javascript est un langage a prototypes. Donc la il va falloir que tu explique pourquoi tout le monde ce trompe.
Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
C'est bien pour cela que lon ne distribue pas les binnaires natifs mais les binnaires pour la VM, comme je l'ai bien précisé dans mon message. Le code est transformé en code machine au moment de l'instalation du logiciel sur la machine de l'utilisateur. Ce qui permet de valider le code avant la compilation, et en plus de le compiler de maniere particulierement optimisée pour la config de l'utilisateur (du moins en théorie). C'est transparent.
Et ne me sort pas un argument du style oui mais on ne distribue pas du natif donc c'est moins bien que lisaac car :
- On peut le faire mais on perd alors le modele de securitee, et on se retrouve avec un modele equivalent a celui de lisaac ;
- Quelle soit faite sur la machine du developpeur ou de l'utilisateur, il y a bien compilation vers du code machine.
Donc pour moi la discution s'arrete ici, mais je trouve domage que tu t'entete sur ce genre de conneries plustot que de defendre de maniere intelligente ce langage. On en pas grand chose a battre de savoir qui est le premier, par contre tu aurrais mit en avant de vrais avantage du langage tu m'aurais peut etre donner envie de rééssayer.
Je ne vais pas admettre un truc parce que tu en change en la définition.
Quelle définition est-ce que j'ai changée ? En regardant bien je ne voit qu'une chose que j'ai changer par rapport au debut : on est passer de "compiler" à "compiler en code natif". Donc le seul changement est a ton avantage, et si on revient à la formulation d'origine, il n'y a même plus a discuter.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
Je ne compare pas et je m'en bas les couille de leur difference de taille. Ça ne change absolument rien au fait que le programme est compiler en code natif, que ce soit par NGen a partir de code .net, ou par GCJ a partir d'un code java intermediaire.
C'est pourtant pas compliqué, et le fait de ne pas etre le premier n'enleve rien a Lisaac. Plutot que de defendre un truc indéfendable et qui ne lui apporte rien, il serait beaucoup plus pertinent d'essayer de mettre en avant les vrai avantage du langage. Se serait bien plus efficace que du pseudo intégrissme a deux balles.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Tu n'a pas vraiment compris le modele de securite de .NET. Le principe c'est tu as un code que tu compile pour un machine virtuelle. Ton code est valide pour cette machine et ne peut pas faire de conneries. Ensuite tu as un compilateur auquel tu fait confiance qui traduit ce code en langage machine en respectant la semantique definie par la VM.
Donc tu garde ton modele de securite. En general tu difuse le code pour la VM, et l'utilisateur a un compilo auquel il fait confiance sur ca machine qui, al'instalation, va verifier le code et le compiler.
Tu as donc bien du code natif qui est aussi securiser que le code VM. Bien sur le compilo n'est pas infaible, mais une VM non plus.
Des fonction telle que setjmp et longjmp, les fonctions de gestion des signaux, la gestion des arguments variables sont du runtime. Dans une certaines meure la gestion bas niveau des fichier fait aussi pour moi partit du runtime, mais je vais pas pinailler.
Ça ne change rien au fait que le programme est compilé en natif. La majorité des langages de programation nécessitent un runtime plus ou moins lourd. Même le C embarque la stdlib, et Lisaac n'est pas une exception.
Qu'il y ait un runtime ou pas, le code obtenu est du code natif qui va être exécuter directement sur le processeur sans passer par la case JIT.
Je ne comprend pas pourquoi ça te gène autant d'admettre que tu as fait une petite erreur dans le journal en disant que Lisaac est le premier langage à prototype compilé. D'autant qu'il y avait déjà une erreur dans le fait de ne pas préciser "compilé en code natif".
Non cela n'a rien à voir. Au runtime, tu as plein d'information sur les données. Par exemple, tracemonkey ne compile que les coeurs de boucle qu'il détecte.
Tu ne lit que la moitier des commentaire auquels tu répond ?
Ensuite j'ai pris soin de mettre un exemple qui produit un fichier exécutable avant l'exécution : JScript.NET + NGEN. Ce qui montre qu'on peut aussi se passer de JIT.
J'avoue que mon racourçit était un peu rapide, mais j'en avais déjà écrit une tartine donc j'ai pas eu le courage de développer plus précisément.
Donc pour être un peu plus clair, lagestiondes dépendance est un problème NP-complet, ce qui ce prouve par une réduction du problème CNF-SAT. Et, dans aptitude, cette résolution est faite par des heuristique notament inspirées des techniques employées dans les solveurs SAT ainsi que des heuristiques supplémentaires pour choisir parmis les différentes solutions trouvées celle qui est la plus adapté au problème de gestion des dépendances.
Tout simplement parce que mon objectif est juste de simplifier la vie de tout le monde. Donc celle des packagers s'ils veulent ajouter mon programme dans leur distrib, mais aussi celle des utilisateurs s'il ne disposent pas d'un paquet pour la leur.
Et dans ce cas, la version simple qui consiste à faire un "make" et un "make install" ne devrait pas installer par default dans "/bin", mais au minimum dans "/usr/bin" ou "/usr/local/bin".
Ce problème ne peut pas ce règler juste avec DESTDIR, mais en effet avec PREFIX, il suffit de le mettre par defaut à "/usr" ou "/usr/local" pour que ça marche. J'avais oublié celui-là, mais la encore une petite doc sur les bon principe aurait permis de ne pas oublier...
Le truc c'est que le respect des standards je suis pour, mais quels standards ? C'est ce que je cherche depuis longtemps mais sans trouver. Même en cherchant dans les docs des distributions et des gestionnaires de paquets on ne trouve une petite page qui explique aux dévelopeurs les bonnes pratiques pour faciliter l'empaquetage.
Pour le script configure, dans mon cas il faut juste un compilateur C et parfois la lib pthread, rien de sorcier, donc je me contente en général de l'indiquer clairement dans les fichiers d'info. Mais si quelqu'un à un petit script qui vérifie les deux de manière portable et qui reste très léger, pas de problèmes.
Le truc c'est plus que tout ça, ça reste très flou. Si je prend la variable DESTDIR par exemple, comment l'utiliser simplement ? Est-ce que je dois installer dans
$(DESTDIR)/bin ou dans $(DESTDIR)/usr/bin ?
Bref, moi je ne demande qu'a faciliter le travail des packageurs mais que l'on m'en donne les moyens...
La bonne qualité du code. Un logiciel avec un Makefile pourri rendra difficile la création d'un paquet, pour tous les systèmes
D'ailleur il y a longtemps que je cherche une doc sur les bonnes conventions à adopter dans un Makefile et dans le code en général pour rendre la création des paquets simple en dehors du DESTDIR.
Globalement à chaque fois la réponses c'est utilise autoconf et automake chose que je refuse. Je ne vois pas l'interet d'utiliser un système imbitable et très lourd, qui va ajouter facilement 1Mo de fichiers à un programme qui représente 50ko de sources.
Donc en dehors du DESTDIR, qu'est ce qui est important ?
Alors qu'un logiciel de gestion des logiciels traditionnel fonctionne la plupart du temps en relation avec une BDD, que presque tout se passe dans les requêtes SQL et dans les jointures des tables ( j'exagère, je n'ai aucune idée de la façon dont fonctionne RPMDrake ) , ici, SteckDenis nous propose une vision fondamentalement beaucoup plus réfléchie.
Comme tu dis, tu n'a aucune idée de la manière dont ça fonctione et ça ce voit... ;-)
Des gestionnaire de paquets qui utilise SQLlite out une autre base de données SQL, il y en a pas de masses.
La majoritée du temps c'est un format interne tout simplement parce que la gestions de dépendances qui est l'opération la plus complexe qu'ils aient à réaliser ne ce fait pas à coup de jointure mais plutot à coup de solveur SAT pour les plus bourrins.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , [...]
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Même s'il n'y a pas de SQL ou autre dans les gestionnaire de paquets, ce que tu dis reste faux. On est ici sur des données qui font quelques dizaine de Mo, et même en imaginant une base de donnée très lourde qui à un surcout de 50% ça reste sans problème chargeable en mémoire. Je serais surpris que n'importe quelle base de donnée ne charge pas une telle base en mémoire éventuellement de manière indirecte par un mmap.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Deux chose qui n'on absolument rien à voir : le chargement en RAM c'est juste l'endroit ou tes données sont stockée, l'utilisation de SQL ou d'XML c'est la mnière dont tu les stocke à cet endroit. Tu peut stocker du SQL ou du XML en RAM sans problème. (heureusement d'ailleur...)
Et pour ce qui est du surcout éventuel du SQL, il faut bien voir que les bases de données sont optimisées avec éventuellement des index pour accélérer au maximum toutes es opérations de recherche, donc le surcout, il n'éxiste pas vraiment, bien au contraire.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
C'est un peut hors sujet, mais que tu le fasse en C ou en C++ ça prend le même temps... la meilleur manière de charger ton fichier en mémoire c'est de faire un mmap...
Une table SQL mapper c'est en général juste un mmap pour la charger en mémoire, enfin pas tout à fat charger, juste mapper et elle est chargée à la demande. La strucuture est dans le fichier mapper pas besoin de la reconstruire. Si tu as rééllement besoin de relire tout le fichier explicitement plutot que par un mappage c'est que tu est obliger de reconstruire la structure et donc c'est bien plus lent. Donc soit c'est égalitée, soit c'est SQL qui gagne...
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
C'est la que le SQL perd car la gestion des dépendances est un problème qui n'est pas adapté à SQL et c'est pour cela que à peu près aucun gestionnaire de paquetages ne l'utilise donc pas d'avantage à logram sur cet aspect.
Pour les algos utilisés, Logram en utilise des plus simples que apt par exemple, car celui-ci utilise un solveur SAT, mais c'est aussi la faiblesse de logram car il ne peut pas gérer tous les cas. Cela à déjà été évoquer dans un des journaux précédents, c'est un choix qu'il à fait.
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
C'est cette phrase qui m'a décidé à répondre. Je crois que pour l'instant en tout cas, non logram n'aura que très peu d'impact sur les autre logiciels de gestions de paquet. Ce n'est pas méchant mais réaliste. Setup à des objectifs différents c'est tout.
D'un point de vue fonctionalitées, il n'apporte rien par rapport aux autres, c'est même le contraire.
Son seul avantage c'est la rapiditée (qui demande à être confirmée sur dans les mêmes conditions que pour les autres) et les dev des autres gestionnaires de paquets sont déjà au courrant qu'ils ont des problèmes à ce niveau là, et il y a déjà des personnes qui bosse dessus.
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Là par contre je suis tout à fait d'accord. Il faut pas prendre mon commentaire comme une critique de Logram ou de setup, mais juste une reponse au comentaire du dessus.
Même si je ne voit pas l'utilitée de tes projets pour moi, je suis pas du genre à dire ça sert à rien il y a déjà tout ce qu'il faut. Code ce qui te fait plaisir, moi ça me fait plaisir de voir des gens coder ce qu'il aiment. Et c'est pas par ce que pour l'instant je ne voit rien qui m'intéresse personnellement que je n'y trouverais rien à l'avenir.
Et surtout, continue de nous tenir informer, j'aime bien ce genre de journaux au milieu de tout ceux qui parlent de politique ou autre.
Plutôt que de te plaindre, tu pourrais réexpliquer différement pour essayer de te faire comprendre, non ?
Et pour l'histoire, je serais même près à payer 30 ou 40 euros par mois (mon budget CD actuel) pour n'importe quelle solution qui me permette de téléchager en bonne qualité n'importe quel album, dans un format libre et sans restriction d'utilisation.
J'ai des gouts très éclectiques en musique, une chaine hifi haut-de-gamme, un auto-radio et un baladeur, ainsi que des ordinateurs sous linux et BSD. Actuellement les obstacles pour que j'ai une solution qui me convienne sont :
- sur les platformes actuelles il manque une gorsse part de ce que j'écoute ;
- dans beaucoup de cas il faut un logiciel propriétaire qui ne tourne pas sur mes platformes pour téléchargé e lire les morceaux ;
- je ne peut les transférer sur mon baladeur ou sur un CD pour mon autoradio ;
- la qualité est si mauvaise que sur ma chaine c'est même pas la peine.
J'attend toujours une plateforme d'abonnement correcte à ce niveau là. Et même pour la vente en ligne il y a du foutage de gueule. Il y a pas longtemps, j'ai acheter un album de "The free design" sur un site en ligne au format Flac, dès le début du premier morceaux c'était clair que c'était un mauvais mp3 réencoder en Flac. Il a fallut une dizaine de mail et 2h de téléphone pour qu'ils admettent que c'était le cas et accepetent de me rembourser.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Tu ne les lance pa stous mais tu est très doué pour les entretenir.
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ?
Oui je sais ce que je cherche, mais le probleme c'est que tu as l'air de mieux le savoir que moi :
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
Sauf que si j'ai eu besoin de faire plusieurs compilation avec des log différents c'est justement parce que le volume de log est monstrueux. Donc je devais sélectionner quoi logger et le comparer aux logs valides. Donc ta trace elle peut faire ce quelle veut elle pourra pas deviner toute seule quoi logger.
Pour ce qui de ton système de dimension sur les données, avec les assertions, etc... va falloir que tu développe parce que dans le cas précisdont je parle, je ne vois absolument pas a quoi ça peut servir.
Donc... De plus, es-tu sûr de vraiment savoir ce que tu cherches ?</Ii ...oui moi je sais ce que je cherche et tu me propose des choses qui ne me conviennent pas et qui en plus ne sont pas présentes dans Lisaac. Donc en gros tu me dit : « tu veut ça, donc je te propose ceci qui ne résoud pas ton problème et que je ne sais même pas faire, donc j'ai raison » et après tu veut me faire croire que tu ne troll pas ?
Sachant qu'en plus ce n'est qu'un exemple de cas ou une compilation séparée et utile. Il en existe plein d'autre. Est-ce que pour chacune d'entre elle tu vas me dire, que l'on pourrait implemeter tel truc qui ne résoud pas le problème mais c'est pas grave ?
Par exemple, un code plein d'assertion ou de contrat dans une boucle critique peu se trouver devnir extrèmement lent, donc une foi ce module debuggé, j'aime désactiver les assertions dans ce module. Est-ce que lisaac peut gérer des options de compilation différentes en fonction du module ?
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le problème c'est les «il y a des», «cela permetrait», «on pense aussi». Cela ne couvre qu'une partie des erreurs. Il va toujours en rester et il faut bien pouvoir les debugger celles la.
Et sur la masse total d'erreur ?
Ce n'est pas vraiment imprtant. On doit surement pas être loin de la regle des 80/20 ici ausssi. C'est-à-dire 20% des bugs représentent 80% du temps de débuggage. Dans mon code, j'ai des assertion pour vérifier l'indicage des tableaux et autre conneries du même style, donc généralement tous ces bigs sont résolus très rapidement.
Par contre, les bugs de logique me demandent souvent beaucoup de temps. Là ou en Lisaac je purais mettre un contrat, en C je peut mettre une assertion, donc la manière de faire est différente mais le résultat est proche.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Même si c'est cas ne représentent au final que 1% du nombre d'erreur, à eux seul ils peuvent représenter l'essentiel du temps de debuggage.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
Sur mes programmes, je monte rarement à plus de deux ou trois minutes de compilation, donc pour moi ce n'est pas vraiment un problème, mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
À mon avis, c'est le genre de truc indispensable si vous voulez que Lisaac perce pour de gros projets.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile).
Le problème c'est qu'un debuggeur est très pratique pour certains type de bug, mais pas tous. Si je prend un cas que j'ai eu jeudi dernier. Je code un algo en C car la quantité de calcul est monstrueuse et j'ai besoin que ce soit relativement rapide.
Avant de faire l'implémentation en C, j'en ai fait une sous Octave qui m'a permis de le coder de manière très rapide et bien plus sure. La version sous Octave à été beaucoup plus simple à debugger, et je sais maintenant que le résultat qu'elle me sort est correcte même si elle y passe des heures sur de petites données d'entrée.
La version en C me sortait un résultat différent, donc il y a un bug. Pour débugger, j'ai sortit plusieur logs des différents calculs intermédiaires fait par la version en Octave. Dans ces log j'ai des matrices gigantesques, donc impossible de faire un gdb et de lui demander de m'afficher les matrice et de comparer à la main.
J'ai recompiler plusieurs version du programme en C, dans lequel je sort aussi des logs, pour trouver ou ce situe le problème et voir à quel endroit il y a une différence.
GDB est très utile quand tu as un bug bien localisé, c'est-à-dire, un bug ou tu peut mettre un point d'arret très près de l'enroit ou ce produit le bug, ou une surveillance sur une donnée quand tu sait qu'elle va prendre une valeur interdite. Mais dans mon cas, et je suis souvent confronter à ce genre de problème, ce n'est pas un segfault ou autre, le programme est parfaitement correct, c'est juste qu'il traite de grosse quantitées de donnée et ne fait pas le bon calcul sur certaines d'entre elles.
Il faut bien comprendre qu'il n'y a pas une seule bonne manière de debugger.
Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Et comme d'habitude, la réponse classique est à côté de la plaque ;-) Si tu veux nous vendre Lisaac avec comme argument «il ne fait que de la compilation globale parce que c'est meilleur pour les optims» il faut bien t'attendre à avoir des remarques sur le «que»...
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant... Et pour prouver que je suis de bonne foi, il y a eu une news qui m'avait même fait tester Lisaac. Je l'avais installer, porter si je me souvien bien, deux codes de calculs et donner les résultats en commentaire de mes petits benchs.
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
Pour ce qui est de ce journal, je parlais de javascript, mais j'avais surtout en tête, l'impression qui ressort de l'ensemble des journaux et news sur Lisaac. Quasiment à chaque fois on à vraiment l'impression que seul Lisaac est un bon langage et que le reste est de la merde à vous lire.
C'est ça que je n'apprécie pas...
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur. Si dans ton programme tu remplace une addition par une soustraction, ton compilo n'a aucun moyen de savoir qu'il y a un bug.
Et ce genre de bug me demande souvent des faire de tres nombreuses compilations pour obtenir des sorties intermédiaires, faire des vérifications et autres.
Quand tu vois le temps de compilation d'un gros projet avec la compilation séparée, tu comprend que l'on soit septique quand on nous dit que lisaac ne sait pas gérer autre chose qu'une compilation globale.
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
J'ai bien préciser, à la faois dans le message auquel tu répond et dans plusieurs autres sur cette page que je parlais bien d'aller voir ailleur que sur wikipedia : Tu va faire un tour sur le net (et pas que wikipedia)
Il y a beaucoup de gens tout aussi respectable que ta source qui pense que javascript est un langage à prototype.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Les news et journaux sur Lisaac, j'ai du à peu près tous les voir et même participé à plusieurs d'entre eux, et c'est pour ça que je me suis permit de te donner mon avis sur ton comportement. Et je le maintient.
Tu dira ce que tu veux, mais sur ce journal, le plus obtus et trolleur, ça reste toi. La personne qui semble le plus vouloir dénigrer les autres langage, c'est toi. Ce n'est peut-être pas ton intention, mais c'est comme ça que moi je le perçoit, et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Pour avoir une taille critique il faut attirer les gens, et pour cela il faut leur donner envie de tester le langage, et de rejoindre une comunautée. Donc tu commence par essayer de donner une bonne image des deux, pour cela on commence par ne pas dénigrer les autres langages. Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Je passerai sur l'aspect gourou puisque ça plait à certains, mais le fait d'avoir un boulot ou de bosser d'en une autre branche n'empêche pas d'assumer ses conneries.
Être du domaine n'apporte qu'une chose, réduire les risque de dire des conneries, mais une fois qu'elles sont dite, quel que soit le context, c'est pas dur de les assumer.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
- il confirme l'impression que donne Nicolas Boulay de la communauté Lisaac. Ce genre de ton dédaigneux et compatissant j'ai du mal ;
- il prouve que l'on a donné a Nicolas Boulay avant hier soir un debut d'argument (pas trés convaincant mais bon...) et qu'il n'a pas daigné le recopier ici.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Ce que je te reproche, ce n'est pas de t'être trompé au départ, mais ton attitude gamine après qui à été de ne pas vouloire reconnaître qu'un truc clochait.
C'est simple, quand on te dit «si, si, il y a plein de gens fiable qui pensent que javascript est un langage a prototype et qui le disent sur internet» tu as trois choix valables :
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
Depuis le debut tu ne fais qu'affirmer sans argumenter au contraire des commentaires qui te répondent, donc permet moi d'avoir des doutes sur ce que tu dis.
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
Sur la phrase qui fait débat, tout le monde ne peut pas avoir raison. Soit Lisaac est le premier, soit il ne l'est pas, et de mon point de vue, on a amené uffisament d'éléments indiquant qu'il ne l'est pas.
Ce que je lui reproche n'est pas d'avoir eu tord au début, mais de ne pas l'admettre et justement d'avoir poluer son journal avec cette discution pas plus intéressante que ça et montrer ça mauvaise foi. C'est très typique des membres de la comunauté Lisaac qui s'expriment sur LinuxFR.
Je ne conclu pas que Lisaac est mauvais, ce que je conclus c'est que je ne retournerais pas voir ce langage vu la comunauté qu'il y a autour. Une comunauté est indispensable pour qu'un langage ce dévelope. Et vu que je n'ai pas trop de temps à perdre, je mefais une idée de la comunauté autour de Lisaac en regardant le comportement de l'échantillon que l'on à sur LinuxFR.
C'est très approximatif comme méthode, mais c'est réaliste. Des langages intéressants il y en a un paquet. Je n'aurais jamais le temps de tous les regarder en détail, donc tout ce qui me permet de faire un tri est bon à prendre.
C'est comme un DRH devant une pile de 500 CVs. Il ne peut pas tous les étudier en détails et convoquer toutes les personnes pour un entretien. Donc il fait le tri, un premier passage sur la pile et tous les CVs qui ont été fait à la rache avec de grosses fautes dans les titres, ça donne pas l'impréssion que le mec est serieux, donc direct à la poubelle. (on va pas entrer dans le débat des autres critères très discutables)
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
Tout dépend du point de vue. Il y a de très grandes quantités de code java disponible que tu n'as pas forcément envie de réécrire, mais en même temps tu en as peut-être rien à foutre de la portabilitée car tu es sur une plateforme figée : ton desktop par exemple.
Dans ce cas, avec gcj tu profites du code tout en ayant les avantages d'un code directement natif.
Il faut bien voir que la portabilité c'est un concept qui existe au moment de la difusion, mais beaucoup moins dans de nombreux cas d'utilisation. Quand on écrit du code on veut qu'il marche chez le plus de personnes possibles, quand on l'utilise on veut qu'il marche chez soit.
Une VM permet les deux mais un compilateur tel que gcj permet uniquement le deuxième. L'avantage c'est qu'il n'y a pas à attendre que la VM s charge ou que le JIT produise du code.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
Je pense que les créateurs de Ch ne soient pas d'accord avec toi, et leur bizness dure depuis un bout de temps donc leur clients ne doivent pas être d'accord non plus.
L'avantage de faire tourner du C sur une machine virtuelle c'est que tu éxectues le code dans un environement sécuriser et tu peut inclure l'interpreteur dans un autre programme.
Et comme pour au dessus, du dispose d'une quantité faramineuse de code déjà écrit.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
Et pourtant si, ça aurait un sens. Le programme gagne les avantages de l'environement managé de .net ou de la jvm, et des facilitées de comunications inter langages. Cela permet aussi de cibler des plateformes ou seul ce genre de code est accepté.
Sur android par exemple tu ne peut éxectuer que du code java, ça pourrait être cool d'avoir autre chose. L'exemple est mal choisit puisque c'est une JVM modfié et qu'ils ont sortit un NDK, mais l'idée est là.
Il faut bien voir que natif ou VM c'est des techniques complémentaires qui ont chacune leurs avantages et inconvénients, et à part certaines construction particulière il est généralement possible de ciber l'un ou l'autre indiférament. Disposer des deux est même un avantage pour un langage.
[1] http://www.softintegration.com/products/
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
les langages interprétés tel que les premiers basics par exemple. L'interpreteur va lire lire une instruction dans le langage source et l'interpréter avant de passer à la suivante. Le code n'est jamais compilé et cela à pour conséqueces par exemple que l'éxecution du programe commence très rapidement, mais qu'elle est très lente, et qu'une erreur de syntaxe à la ligne 243 ne sera détectée que si cette ligne est éxecutée.
les langages compilés en code natif dans ce cas le code est transformé en code natif pour un processeur donné. On peut faire plein d'optimisation spécifiques mais c'est pas ortable, mais surtout on obtient un binnaire directement utilisable en général, avec souvent des dépendance à des libs externes qui peuvent contenir un runtime.
les langages compilé pour une VM ou la compilation cible une architecture virtuelle. Dans ce cas, on obtient pas un executable indépendant mais un code qui va être executer par une machine virtuelle qui doit être distribuée avec le programme. Cette machine virtuelle va éxecuter des instruction particulière mais ces instruction ne seront jamais transformées en code natif.
En gros, ces 3 la correspondent au 3 catégoreis que tu donnais, mais ce qu'il faut bien voir c'est que il y a compilation dans les deux dernier cas. Ce qui donnait la première ambiguité de la phrase du journal. Mais on va pas s'étaler là dessus, je pense que tou le monde à copris qu'il parlait de compiler en code natif.
Le truc c'est que entre le 2 et le 3 il y a d'autres étapes :
les langage avec JIT la le code pour la machine virtuelle est transformé en code natif au juste avant l'éxécution, donc on a du code pour une VM mais qui devient du code natif. Sans vraiment le dire dans le journal, il excluait ce cas là. Donc pour reformuler plus clairement la phrase du journal on en serait à «lisaac est le premier langage à prototype compiler directement en code natif sans jit». Là c'est déjà beaucoup plus discutable comme phrase. C'est un peu plus vrai (mais pas completement) mais considérer le JIT comme n'étant pas vraiment du natif car la conversion est faite tardivement, je suis pas sur que tout le monde sera d'accord, moi le premier, mais bon.
Il y a encore une autre catégorie :
les langage un peu mixte que je sais pas comment appeler Dans cette catégorie, il y a les langages dont le compilateur de base cible une VM, mais qui offre aussi un compilateur qui va de cette VM vers du code natif. C'est le principe par exemple du compilateur CLang du projet LLVM. Le compilateur CLang va compiler du C vers la machine virtuelle de LLVM. Ce code peut ensuite être interpreter avec même du JIT, il y a tout ce qu'il faut pour ça dans le projet, mais surtout il peut être compiler vers du code natif, ce qui est le principal interet. Je pense que personne ne prétendra qu'un binnaire produire par CLang n'est pas compilé en code natif.
Et le problème est là... Il y a une implementation de javascript dans .net qui cible une VM et qui offre un compilateur qui traduit le code de cette VM vers du code natif. Donc ça devient dur de modifier la phrase de départ sans qu'elle deviennent ridicule.
Donc on a bien un autre langage «à prototype» compiler vers du «code natif». Histoire de ce rattraper à des branches mortes, on peu encore critiquer les deux choses que j'ai mise entre guillemets.
- Est-ce que javascript est un langage à prototypes ? Personnellement, j'ai trouvé beaucoup de source sur internet avec des gens plus ou moins serieux qui le prétendent. Il n'y a que ici qu'on voit des personnes prétendre le contraire. Donc avant que je considère que ce n'est pas un langage à prototypes, il va falloir un peu argumenter.
- Est-ce que c'est vraiment du code natif ? Indéniablement oui, mais en cherchant bien, il y a une fonction qui est impossible à implémenter directement... la fonction eval en question...
Le problème c'est que, d'une cette fonction utilise le JIT donc, pour pas mal de personne ça va quand même rester du natif, mais on va faire comme si on avait pas vu.
Mais... si on enleve cette fonction, bien sur on a plus tout-à-fait du javascript, on peut appeller le résultat du jvscrpt. Donc on a du jvscrpt qui est compilé en code natif et qui reste un langage à prototype. La fonction eval n'est pas indispensable pour ça. (heureusement car sinon lisaac ne serait pas un langage à prototype...)
Petits exercices de réflexion :
- Lisaac ce sert, si je me souvien bien, de gcc pour compiler le code C qu'il génére. GCC passe, tout comme CLang par une représentation intermédiaire un peu différente mais qui restes une représentation sous forme un peu virtuelle du code que l'on pourrais vaguement interprété à l'aide d'une VM. Est-ce que ça veut dire que Lisaac n'est pas un langage compilé (au sens du journal ?)
- on peut reprocher à l'exemple du javascript de .net de ne faire la compilation que au moment de l'instalation en général. Si on oublit le fait que cette compilaion peut-être faite sur l'ordi du dev, on peut quand même ce demander si dans ce cas un programme compiler par clang en fichier .lm et transformer en code natif au moment de l'instalation est vraiment compiler au sens du journal. Ça voudrait dire que le gestion de paquet qui à été présenter il y a quelques temps dans un autre journal qui proposait justement de faire cela permettrait d'avoir une distrib ou la majoritée des composants ne sont pas compilés au sens du journal ?
Tout cela pour dire que le problème viens, d'une part de l'ambiguité de la phrase du journal. Ambiguité qui ne peut pas être levé sans rendre la phrase fausse. Et d'autre par de la mauvaise foi de son auteur qui ne veut pas admettre qu'il à été un peu vite dans son affirmation.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 6.
J'étais revenu sur le journal histoire de voir ou vous en etiez, et voir si des sujets intéressants était apparus, et je m'apperçoit que tu cherches encore des branches ou te rattraper comme tu peux...
C'est quand même pas la mort d'admetre qu'on c'est trompé surtout sur un truc aussi insignifiant. Le problème de Lisaac, ce n'est pas le langage en lui-même qui, bien qu'ayant des défault, reste un truc sympa. Le problème, sur linuxfr en tout cas, c'est que les gens qui le défende donne vraiment l'impression que le langage ne vaut rien.
Quand je lis un journal comme celui là, tu commence par m'annoncer des trucs sympas sur les nouveautées et autres. Le ton fait «vendeur d'aspirateur» mais c'est le jeu, et il faut savoir lire entre les lignes. L'objectif étant quand même de vendre le langage. Mais quand je lit les commentaires et tes réponses, et sans vouloir généraliser, c'est souvent le cas dans les journaux sur lisaac ; à la moindre critique, un gros mur ce dresse, impossible de discuter.
Il y a une mauvaise fois flagrante quand on lit le thread qui fait que au final je ne retient qu'une seule chose de ce journal : «la comunauté autour de lisaac à toujours pas changé, pas la peine de retourner voir ce que donne le langage, j'ai mieux à foutre»
Si tu avais rapidement admis que en effet la formulation que tu as utilisée n'était pas bonne mais plus vendeuse. Et si à la place de troller tu avais expliquer ce que la manière de faire de lisaac de mieux. Peut-être donné quelques chiffres de perfs ou explqué pourquoi vous penser qu'une compilation native telle que vous la faite est mieux que celle de .net ou qu'un jit ; je serais partis en me disant : «c'est cool, ça bouge lisaac, faudrais peut-être que je retourne voir ce que ça donne»
Tu peut trouver le fait de considérer un langage en fonction de sa communautée débile mais c'est un fait : ça marche comme ça. Et pour deux raisons :
- tester un langage ça implique de prendre du temps pour regarder sa syntaxe, pour apprendre les base, passer un peu de temps pour porter un code à soit pas trop compliquer mais qui vaut le coup, pour voir réellement les perfs et si on se sent à l'aise avec le langage. Tout ça demande du temps, donc il faut donner envie au gens de prendre ce temps, et c'est à la communautée de le faire.
- un nouveau langage ne s'apprend pas du jour au lendemain, on a souvent des galère, besoins de conseil sur comment coder tel ou tel truc, bref toutes les petites choses au jour le jour avant de vraiment maitriser le langage, et pour tout ça il y a souvent besoin de l'aide de la communautée. Donc si des le début tu donnes l'impression que ça va mal ce passer, tu fait fuir tout le monde.
Si je prend mon cas, je programme principalement en C pour tout ce qui est code critique, mais le C n'est pas adapté pour une grosse partie du programme, donc il y a quelques années j'ai cherché un langage de script pour coder tout ce qui n'est pas critique et appeller mon code critique en C.
J'ai choisit Lua alors que je le connaissait quasiment pas et que je n'était pas super fan de la syntaxe, mais derrière il y avait une communauté très ouverte et très réactive. La mailing liste est très active avec un rapport sigal/bruit presque parfait. Les gens sont parfaitement conscient des limitations du langage et ne cherchent pas à les présenter comme une feature ou donner des arguments plein de mauvaise fois, il se contente d'expliquer pourquoi ces comme ça et d'expliquer si ça va changer à l'avenir ou quand passer outre.
Don pour conclure, bon courrage à votre petite communauté autour de lisaac, mais si vous voulez la faire grossir il va falloir faire des éfforts, et si vous préférez rester entre vous, ça sert à rien de poster des journaux à part le vendredi.
[^] # Re: Ils vont s'en tirer hein...
Posté par beagf (site web personnel) . En réponse au journal Orange publie le code source de la Livebox ... ou presque. Évalué à 5.
C'est capilotracté, mais c'est leur argumentaire et on sent qu'il font bien attention ustement aux mots qu'ils utilisent.
[^] # Re: De toutes façons...
Posté par beagf (site web personnel) . En réponse au journal Orange publie le code source de la Livebox ... ou presque. Évalué à 5.
En général, les dev ne se font pas chier à coder un vrai système cryptographique à clé publique/privée, il se contente d'une solution simple. Bien sur, il y a de bonne chance que ce soit un peu plus qu'un simple CRC en clair, mais un truc tout con que l'on voit souvent sur ce genre de système est : la clé est sous la forme de deux valeurs : A et B, tu calcule un CRC sur le firmware : C et la verification c'est juste A xor C == B.
L'avantage de cette dernière solution c'est que, soit tu envoie B avec le firmware, soit tu ajoute un entier à la fin du firmware auquel tu met la bonne valeur pour que sa passe. Il y a un minimum de sécurité pour pouvoir dire "on l'a fait" et pour pas que le premier andouille venu tripote trop le matos sans que ce soit super chiant à gérer.
Le fait qu'il affiche plein de message avec des termes de crypto ne veut absolument rien dire. Il pourrait t'afficher un truc super complexe ou il t'indique qu'il fat une négociation de clée avec un serveur distant pour recevoir une deuxième clé qui permet de decoder une partie du firmware qu'il renvoi via un canal sécurisé pour validation qui lui permet d'obtenir la clé décodant le reste de firmware.
Et derière juste des printf avec des sleep, un petit reseau quand même, et hop on indique que tout ok juste parce que l'on a verifier que le premier entier à pour valeur la date d'anniverssaire de la fille du dev...
[^] # Re: De toutes façons...
Posté par beagf (site web personnel) . En réponse au journal Orange publie le code source de la Livebox ... ou presque. Évalué à 6.
Entre la doc des constructeur qui est très fournie et celle que l'on trouve sur le net tels que les exceptionel manuels de agner, on a vraiment tout ce qui faut. Je me souviens même d'une époque ou lorsque l'on achetait un processeur intel, de gros manuels était fournis directement avec... Le seul problème ce trouve entre les constructeurs pour savoir qui a le droit d'implémenter quoi dans son CPU.
Le gros problème ce situe au niveau de toutes les autres puces qui trainent dans notre ordinateur. Ce qui semble parfaitement normale et évident pour le CPU parrait, au constructeurs, completement abhérent pour un GPU ou chipset wifi. D'un point de vue utilisation directe, ça ne me dérange pas car si j'ai les compétence pour exploiter les docs des CPU et m'en servir régulièrement, ce n'est pas le cas por un GPU. J'avais jeter un coup d'oeil, a la foi au doc publier par AMD/ATI et au code disponible, et j'ai abandonné.
Mais ce qui me choque, c'est qu'on se retrouve payer pour un materiel que l'on ne peut pas utiliser. Si seulement pour tous ces trucs, les constructeurs pouvait faire comme pour les CPU.
Et je pris pour que ce ne soit pas l'inverse qui se passe. Imaginez un monde ou les processeurs ne sont plus documentés et ou seul le compilateur d'intel peut compiler des logiciels pour leur plateforme, et de même avec tous les autres CPU....
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 4.
Et bien regarde justement la page en question et imagine ce que ça pourrait être si tu était moins borné. On un message qui rétabli une erreur dans un journal, chose très courrante et justifiée. Et derrière il y a toi qui ne veut pas admetre que ta phrase était trop ambitieuse.
J'irais même jusqu'a dire que la remarque de base est très importante. Depuis que les ordinateurs permette d'avoir de bonne perf avec les VM, la notion de code compilé est devenue très ambigue et il faut apprendre a bien différencier la compilation en code natif et pour une VM qui sont très différent de l'interpretation.
Et concernant Javascript, il ne s'agirait pas d'un vrai langage à prototype. C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Justement, tant que tu n'aura pas une bonne argumentation, cet argument ne vaut rien. Je viens de faire un peu de recherche sur le net et il semble que tout le monde soit d'accord sur le fait que javascript est un langage a prototypes. Donc la il va falloir que tu explique pourquoi tout le monde ce trompe.
Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
C'est bien pour cela que lon ne distribue pas les binnaires natifs mais les binnaires pour la VM, comme je l'ai bien précisé dans mon message. Le code est transformé en code machine au moment de l'instalation du logiciel sur la machine de l'utilisateur. Ce qui permet de valider le code avant la compilation, et en plus de le compiler de maniere particulierement optimisée pour la config de l'utilisateur (du moins en théorie). C'est transparent.
Et ne me sort pas un argument du style oui mais on ne distribue pas du natif donc c'est moins bien que lisaac car :
- On peut le faire mais on perd alors le modele de securitee, et on se retrouve avec un modele equivalent a celui de lisaac ;
- Quelle soit faite sur la machine du developpeur ou de l'utilisateur, il y a bien compilation vers du code machine.
Donc pour moi la discution s'arrete ici, mais je trouve domage que tu t'entete sur ce genre de conneries plustot que de defendre de maniere intelligente ce langage. On en pas grand chose a battre de savoir qui est le premier, par contre tu aurrais mit en avant de vrais avantage du langage tu m'aurais peut etre donner envie de rééssayer.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 4.
Quelle définition est-ce que j'ai changée ? En regardant bien je ne voit qu'une chose que j'ai changer par rapport au debut : on est passer de "compiler" à "compiler en code natif". Donc le seul changement est a ton avantage, et si on revient à la formulation d'origine, il n'y a même plus a discuter.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
Je ne compare pas et je m'en bas les couille de leur difference de taille. Ça ne change absolument rien au fait que le programme est compiler en code natif, que ce soit par NGen a partir de code .net, ou par GCJ a partir d'un code java intermediaire.
C'est pourtant pas compliqué, et le fait de ne pas etre le premier n'enleve rien a Lisaac. Plutot que de defendre un truc indéfendable et qui ne lui apporte rien, il serait beaucoup plus pertinent d'essayer de mettre en avant les vrai avantage du langage. Se serait bien plus efficace que du pseudo intégrissme a deux balles.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Tu n'a pas vraiment compris le modele de securite de .NET. Le principe c'est tu as un code que tu compile pour un machine virtuelle. Ton code est valide pour cette machine et ne peut pas faire de conneries. Ensuite tu as un compilateur auquel tu fait confiance qui traduit ce code en langage machine en respectant la semantique definie par la VM.
Donc tu garde ton modele de securite. En general tu difuse le code pour la VM, et l'utilisateur a un compilo auquel il fait confiance sur ca machine qui, al'instalation, va verifier le code et le compiler.
Tu as donc bien du code natif qui est aussi securiser que le code VM. Bien sur le compilo n'est pas infaible, mais une VM non plus.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Des fonction telle que setjmp et longjmp, les fonctions de gestion des signaux, la gestion des arguments variables sont du runtime. Dans une certaines meure la gestion bas niveau des fichier fait aussi pour moi partit du runtime, mais je vais pas pinailler.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Qu'il y ait un runtime ou pas, le code obtenu est du code natif qui va être exécuter directement sur le processeur sans passer par la case JIT.
Je ne comprend pas pourquoi ça te gène autant d'admettre que tu as fait une petite erreur dans le journal en disant que Lisaac est le premier langage à prototype compilé. D'autant qu'il y avait déjà une erreur dans le fait de ne pas préciser "compilé en code natif".
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Tu ne lit que la moitier des commentaire auquels tu répond ?
Ensuite j'ai pris soin de mettre un exemple qui produit un fichier exécutable avant l'exécution : JScript.NET + NGEN. Ce qui montre qu'on peut aussi se passer de JIT.
Je croi qu'on ne peut pas être plus clair :
lisaac --> c89 --> code natif
jscript.net --> code intermediaire --> code natif
Et dans les deux cas sans JIT, donc c'est exactement la même chose.
[^] # Re: pas d'accord
Posté par beagf (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 1.
Donc pour être un peu plus clair, lagestiondes dépendance est un problème NP-complet, ce qui ce prouve par une réduction du problème CNF-SAT. Et, dans aptitude, cette résolution est faite par des heuristique notament inspirées des techniques employées dans les solveurs SAT ainsi que des heuristiques supplémentaires pour choisir parmis les différentes solutions trouvées celle qui est la plus adapté au problème de gestion des dépendances.
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 3.
Et dans ce cas, la version simple qui consiste à faire un "make" et un "make install" ne devrait pas installer par default dans "/bin", mais au minimum dans "/usr/bin" ou "/usr/local/bin".
Ce problème ne peut pas ce règler juste avec DESTDIR, mais en effet avec PREFIX, il suffit de le mettre par defaut à "/usr" ou "/usr/local" pour que ça marche. J'avais oublié celui-là, mais la encore une petite doc sur les bon principe aurait permis de ne pas oublier...
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 6.
Pour le script configure, dans mon cas il faut juste un compilateur C et parfois la lib pthread, rien de sorcier, donc je me contente en général de l'indiquer clairement dans les fichiers d'info. Mais si quelqu'un à un petit script qui vérifie les deux de manière portable et qui reste très léger, pas de problèmes.
Le truc c'est plus que tout ça, ça reste très flou. Si je prend la variable DESTDIR par exemple, comment l'utiliser simplement ? Est-ce que je dois installer dans
$(DESTDIR)/bin ou dans $(DESTDIR)/usr/bin ?
Bref, moi je ne demande qu'a faciliter le travail des packageurs mais que l'on m'en donne les moyens...
[^] # Re: Pas d'accord non plus
Posté par beagf (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 6.
D'ailleur il y a longtemps que je cherche une doc sur les bonnes conventions à adopter dans un Makefile et dans le code en général pour rendre la création des paquets simple en dehors du DESTDIR.
Globalement à chaque fois la réponses c'est utilise autoconf et automake chose que je refuse. Je ne vois pas l'interet d'utiliser un système imbitable et très lourd, qui va ajouter facilement 1Mo de fichiers à un programme qui représente 50ko de sources.
Donc en dehors du DESTDIR, qu'est ce qui est important ?
[^] # Re: pas d'accord
Posté par beagf (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 10.
Comme tu dis, tu n'a aucune idée de la manière dont ça fonctione et ça ce voit... ;-)
Des gestionnaire de paquets qui utilise SQLlite out une autre base de données SQL, il y en a pas de masses.
La majoritée du temps c'est un format interne tout simplement parce que la gestions de dépendances qui est l'opération la plus complexe qu'ils aient à réaliser ne ce fait pas à coup de jointure mais plutot à coup de solveur SAT pour les plus bourrins.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , [...]
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Même s'il n'y a pas de SQL ou autre dans les gestionnaire de paquets, ce que tu dis reste faux. On est ici sur des données qui font quelques dizaine de Mo, et même en imaginant une base de donnée très lourde qui à un surcout de 50% ça reste sans problème chargeable en mémoire. Je serais surpris que n'importe quelle base de donnée ne charge pas une telle base en mémoire éventuellement de manière indirecte par un mmap.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
Deux chose qui n'on absolument rien à voir : le chargement en RAM c'est juste l'endroit ou tes données sont stockée, l'utilisation de SQL ou d'XML c'est la mnière dont tu les stocke à cet endroit. Tu peut stocker du SQL ou du XML en RAM sans problème. (heureusement d'ailleur...)
Et pour ce qui est du surcout éventuel du SQL, il faut bien voir que les bases de données sont optimisées avec éventuellement des index pour accélérer au maximum toutes es opérations de recherche, donc le surcout, il n'éxiste pas vraiment, bien au contraire.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
C'est un peut hors sujet, mais que tu le fasse en C ou en C++ ça prend le même temps... la meilleur manière de charger ton fichier en mémoire c'est de faire un mmap...
Une table SQL mapper c'est en général juste un mmap pour la charger en mémoire, enfin pas tout à fat charger, juste mapper et elle est chargée à la demande. La strucuture est dans le fichier mapper pas besoin de la reconstruire. Si tu as rééllement besoin de relire tout le fichier explicitement plutot que par un mappage c'est que tu est obliger de reconstruire la structure et donc c'est bien plus lent. Donc soit c'est égalitée, soit c'est SQL qui gagne...
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
C'est la que le SQL perd car la gestion des dépendances est un problème qui n'est pas adapté à SQL et c'est pour cela que à peu près aucun gestionnaire de paquetages ne l'utilise donc pas d'avantage à logram sur cet aspect.
Pour les algos utilisés, Logram en utilise des plus simples que apt par exemple, car celui-ci utilise un solveur SAT, mais c'est aussi la faiblesse de logram car il ne peut pas gérer tous les cas. Cela à déjà été évoquer dans un des journaux précédents, c'est un choix qu'il à fait.
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
C'est cette phrase qui m'a décidé à répondre. Je crois que pour l'instant en tout cas, non logram n'aura que très peu d'impact sur les autre logiciels de gestions de paquet. Ce n'est pas méchant mais réaliste. Setup à des objectifs différents c'est tout.
D'un point de vue fonctionalitées, il n'apporte rien par rapport aux autres, c'est même le contraire.
Son seul avantage c'est la rapiditée (qui demande à être confirmée sur dans les mêmes conditions que pour les autres) et les dev des autres gestionnaires de paquets sont déjà au courrant qu'ils ont des problèmes à ce niveau là, et il y a déjà des personnes qui bosse dessus.
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Là par contre je suis tout à fait d'accord. Il faut pas prendre mon commentaire comme une critique de Logram ou de setup, mais juste une reponse au comentaire du dessus.
Même si je ne voit pas l'utilitée de tes projets pour moi, je suis pas du genre à dire ça sert à rien il y a déjà tout ce qu'il faut. Code ce qui te fait plaisir, moi ça me fait plaisir de voir des gens coder ce qu'il aiment. Et c'est pas par ce que pour l'instant je ne voit rien qui m'intéresse personnellement que je n'y trouverais rien à l'avenir.
Et surtout, continue de nous tenir informer, j'aime bien ce genre de journaux au milieu de tout ceux qui parlent de politique ou autre.
[^] # Re: Spotify.
Posté par beagf (site web personnel) . En réponse au journal Spotify, Deezer et petit calcul. Évalué à 6.
Et pour l'histoire, je serais même près à payer 30 ou 40 euros par mois (mon budget CD actuel) pour n'importe quelle solution qui me permette de téléchager en bonne qualité n'importe quel album, dans un format libre et sans restriction d'utilisation.
J'ai des gouts très éclectiques en musique, une chaine hifi haut-de-gamme, un auto-radio et un baladeur, ainsi que des ordinateurs sous linux et BSD. Actuellement les obstacles pour que j'ai une solution qui me convienne sont :
- sur les platformes actuelles il manque une gorsse part de ce que j'écoute ;
- dans beaucoup de cas il faut un logiciel propriétaire qui ne tourne pas sur mes platformes pour téléchargé e lire les morceaux ;
- je ne peut les transférer sur mon baladeur ou sur un CD pour mon autoradio ;
- la qualité est si mauvaise que sur ma chaine c'est même pas la peine.
J'attend toujours une plateforme d'abonnement correcte à ce niveau là. Et même pour la vente en ligne il y a du foutage de gueule. Il y a pas longtemps, j'ai acheter un album de "The free design" sur un site en ligne au format Flac, dès le début du premier morceaux c'était clair que c'était un mauvais mp3 réencoder en Flac. Il a fallut une dizaine de mail et 2h de téléphone pour qu'ils admettent que c'était le cas et accepetent de me rembourser.