Un moment, j'avais imaginé un système de p2p de socket UDP. Normalement un peu n'importe quoi pourrait passer dedans. L'idée est de faire de la redirection, avec au minimum un entrant et 2 sortant.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
J'ai du mal à comprendre, vous utilisez des fonctions tellement évoluer en openGL que les implémentations incomplètes de ATI et la lenteur des intel posent problèmes ?
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
Pour répondre sur les assertions et ton problème d'erreur de signe. Tu peux trouver des erreurs d'équation en utilisant les propriétés mathématiques de ta fonction, par exemple, tu vérifies que l'opération reste transitive, reflexive, tu peux vérifier les éléments neutres, et autre propriété un peu poussé. Si tu codes une multiplication de matrice tu peux vérifier par exemple que ((A*B)*A)*B =A*((B*A)*B).
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
Je serais curieux de voir le code pour comparer les 2 implémentations et voir le résultat, si il est disponible.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
En fait, c'est surtout que ext4 se comportait comme XFS en réordonnancement aussi les rename avec les write, ce qui pouvait faire en sorte de changer le nom du fichier avant que l'écriture soit effective. D'ou le débat de l'utilisation de fsync() mais qui est lente alors que le rename sous-entendait une relation d'ordre.
Les logs monstrueux, c'est quelle taille 1 Go ? 10 Go ? plus ? Les log pour les simu VHDL tracent tout :)
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
C'est toi qui disait "Le minimum, c'est de regarder l'état de l'art de ce qui se fait.". C'était bien le but de ton intervention ?
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
Je crois que niveau validation/test, tu t'es trompé de siècle.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
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.
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.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
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.
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.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
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.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
fsync() à une sorte de sémantique d'urgence, qui fait ralentir tout le système.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
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.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'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). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"+" à 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).
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
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.
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.
Je dirais que en théorie tu as raison. Mais dans ce cas, comment expliques tu que tout les utilisateurs de SSD considèrent que leur PC a perdu toutes ses petites latences qui rend l'ordinateur "mou" et surtout comment voit-il une différence entre SSD comme avec le X25-e ?
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 2.
Mon truc c'est plus du streaming.
"La première sécurité est la liberté"
# p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 3.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
# google: "Reducing HTTP latency with SPDY"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Shared Dictionary Compression over HTTP (SDCH). Évalué à 2.
google se lance aussi dans un autre protocole : SPDY.
"La première sécurité est la liberté"
[^] # Re: Tout ceci reste scandaleusement compliqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Clubic nous explique comment se faire rembourser Windows. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: La troidé sous X.Org
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 2.
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
"La première sécurité est la liberté"
# Ecran géant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ubiquitous computing. Évalué à 2.
Le coté interaction serait là uniquement pour définir la géographie des points.
http://blinkenlights.net/arcade
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
D'ailleurs, tu n'as pas répondu sur Octave vs C.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
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.
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.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
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.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
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.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
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.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'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). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
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.
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.
"La première sécurité est la liberté"
[^] # Re: AMHA
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Surfez avec Internet Explorer et offrez vous un système de sauvegarde gratuit. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Si tu fais une copie de fichier de 1 Mo par exemple ou moins, un SSD serait plus rapide qu'une grosse baie raid 5.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"