Abandon du projet Omega, le firmware tiers pour NumWorks

[parisse]

Pour l'interface, ça risque d'être un peu long, car il faut déjà bien réfléchir à comment l'intégrer (par exemple, permettre de tracer des inéquations dans l'application fonction serait bien, mais son nom est bien fonction, donc trouver qqch qui soit logique), et après créer l'interface dans les menus sera peut être long (ça dépend de ce qui sera possible). Pour la partie tracée d'inéquation, c'est extrêmement simple.

Ca risque d'etre complique a mettre dans Fonction, deja que je trouve pas intuitif du tout de tracer une courbe parametrique ou polaire la-dedans. Je pensais plutot une app a part, avec la meme interface que pour entrer des equations dans l'app solveur (il faut juste remplacer = par > >= < ou <=, on verra).
Le trace n'est pas "extremement simple", en tout cas si on fait comme je fais, i.e. se ramener a un polygone rempli (et c'est ce qu'il faut faire pour etre rapide et si on separe le moteur de calcul de l'affichage graphique). J'ai pu coder ca en un jour parce que j'avais deja dans giac certaines fonctions, en particulier la commande convexhull.

Après, pour la partie calcul, je ne sais pas précisément ce qu'ils ont fait, mais s'ils utilisent une implémentation numérique simple, ça devrait être très rapide pour eux à coder. S'ils en font plus, ça dépendra de ce qu'ils font, mais je suis globalement plutôt sûr que la partie mathématique sera tjs plus longue que le léger ralentissement qu'apporte leur noms.

Je ne comprends pas ce que vous voulez dire. Pour etre bien sur, je precise ce que j'ai dit : le choix du style tres C++ d'Epsilon n'a au 1er ordre pas de consequences sur la vitesse d'execution du code, mais sur la vitesse de conception/ecriture du code source.

[redgl0w]

mais sur la vitesse de conception/ecriture du code source.

Je disais que ce n'était sûrement quasiment pas le cas. C'est non pas le coding style qui pose problème niveau ralentissement d'écriture je pense, mais leur allocation qui peut parfois avoir des comportements inattendues.

[parisse]

Bon, peut-etre qu'avec des outils de developpement adaptes a des noms de variables ou fonctions qui font une demi-ligne et des petits fichiers sources de partout qui sont dans des arborescences a 3 niveaux et plus, on peut ne pas trop perdre en efficacite. Mais en tout cas pour moi, s'y retrouver la-dedans c'est un vrai cauchemar (surtout qu'il n'y a aucune doc) je perds un temps fou pour trouver ou et comment modifier des trucs tout betes (par exemple mettre la calc en radians par defaut). Et bien sur l'allocation memoire est (comme le reste) tres (trop?) complexe.
Il y a comme une fascination devant cette complexite.

[Adriweb]

Oui absolument : avec un IDE comme Clion c'est trivial de naviguer/ajouter/modifier/refactorer le code d'Epsilon (ou n'importe quelle autre codebase C ou C++). Et par refactor j'entends pas un simple renommage par rechercher/remplacer ; je parle bien d'un renommage intelligent qui prend en compte toute la semantique du code C++ pour savoir ce qu'il faut faire exactement comme changement. Et l'extraction de méthodes, génération de code, debugging, analyse statique et dynamique, profiling... Bref la totale.

Je n'arrive vraiment pas à comprendre pourquoi les gens se limitent leur efficacité à cause d'outils archaïques et/ou inadaptés. Arrêtez de perdre du temps et de vous faire mal vous-memes, bon sang !

A défaut de Clion, il y en a d'autres a moindre mal, comme VS Code avec le plugin officiel de gestion du C++.

Je ne connais pas les histoires d'allocations dans epsilon donc je ne donnerai aucun avis dessus

[parisse]

Pourquoi j'utilise des outils "archaiques"? C'est parce que ce sont les memes outils depuis que je code, et ils sont parfaitement adaptes a mon style de codage. Je ne vais pas reapprendre a utiliser une nouvelle interface toutes les quelques annees, d'abord parce que passe un certain age, c'est beaucoup plus difficile de changer d'habitudes, et ensuite parce que je ne vois pas bien ce que ca m'apporterait. C'est un peu la meme chose que pour les commandes textes Unix de base vs toutes les interfaces graphiques.
C'est un style de codage complexe qui impose d'utiliser des IDE modernes : comme on peut plus facilement ecrire du code complexe avec des arborescences on le fait, mais ca ne veut pas dire que c'est necessaire. Et personnellement je pense que c'est au contraire nuisible, les gens se gargarisent de la complexite au lieu de se focaliser sur l'ecriture de code original et efficace.

En fait c'est une querelle des anciens et modernes que nous avons et argumenter de maniere objective risque d'etre difficile. Je vais quand meme essayer de le faire avec 2 observations.

Premiere observation: prenons l'application tableau periodique des elements qui existe en 3 versions : application Epsilon, application externe et application additionnelle de KhiCAS. Ces 3 versions sont tres proches fonctionnellement parlant. La version KhiCAS occupe 330 lignes de code (dont 135 lignes pour le tableau lui-meme). La version application externe a peu pres la meme chose (347 lignes de code, 2622 mots, 18876 caracteres dont pour le tableau lui-meme 120 lignes, 1757 mots et 11250 caracteres), a quoi il faut rajouter quelques fichiers pour la gestion de l'application mais ca reste simple. La version application Epsilon sans les fichiers de localisation comporte 1224 lignes de code, 3127 mots et 42009 caracteres (wc *.cpp *.h).
Conclusion: hors le tableau lui-meme, il faut environ 2 fois plus de code dans Epsilon qu'en-dehors pour faire essentiellement la meme chose.

Deuxieme observation: combien avons-nous d'applications NW developpees par la communaute? Regardons dans Omega: sauf erreur, il y a trois applications Epsilon, Atomic, RPN et External (ca fait donc deux "vraies" applications). En applications externes, nous avons au moins 6 applications: KhiCAS, Periodic, Hexedit, Nofrendo, PeanutGB, BadApple. Et les 6 applications externes ne tiennent pas dans les 6Mo, alors que les 2 vraies applis Epsilon sont relativement simples et tiennent en une centaine de K : en fait les applis Epsilon de la communaute se comparent plutot a une appli additionnelle de KhiCAS de la complexite du mastermind.

Donc je maintiens mon avis: la complexite globale d'Epsilon et l'absence de support pour les librairies standard en font un ecosysteme peu favorable aux developpements de la communaute et probablement aussi pour les developpeurs d'Epsilon.

[Lionel Debroux]

Si les IDEs avancés peuvent être lents à démarrer et lourds pour des éditions rapides de texte formatté ou des projets d'un seul fichier, le modèle de code est utile pour certains types de recherche - comme "toutes les références à cette variable" - même dans du code qu'on connaît, et encore plus pour des parcours un peu détaillés de code qu'on ne maîtrise pas, ou bien le refactor. Le tout est d'utiliser un outil adapté à son usage actuel.
Je fais partie des gens qui utilisent à la fois un éditeur de texte à coloration syntaxique, presque toujours SciTE, et des IDEs avancés, Qt Creator ou Visual Studio (pas VS Code)... et pas assez souvent le deuxième type, d'ailleurs
Sur les projets complexes, la consommation de ressources (RAM, CPU) des IDEs avancés peut être un problème. On ne peut pas toujours utiliser une machine plus puissante.

[Adriweb]

Mon post s'adressait plutôt à quiconque n'avait jamais utilisé d'IDE modernes, en fait.

Mais bref comme Lionel j'utilise plusieurs outils selon ce que je fais, de nano et vim (petits codes simples, et/ou édition remote) à Clion ou Intelllj (gros projets), en passant par sublime text et VS Code (petits/moyen codes multi-fichiers qui ne sont pas vraiment organisés en projet). Ça me permet d'être aussi efficace que possible selon ce que j'ai à faire.

[parisse]

Mon post s'adressait plutôt à quiconque n'avait jamais utilisé d'IDE modernes, en fait.

Je ne sais pas si je suis vise:-) mais pour info, je suis oblige de temps en temps d'utiliser un IDE (celui de visual c++ pour etre plus precis) et franchement je n'en vois pas l'interet pour ce que je fais, d'abord je trouve qu'il y a beaucoup trop de menus/options pour une utilisation occasionnelle, et en prime ca change d'une version a l'autre. Je ne parle meme pas d'une initiation avec ce genre d'outil par rapport a ecrire un programme pour utilisation en console, en editant un unique fichier source avec emacs (ou vi si vous preferez), compilation en ligne de commande et execution par ./a.out ou mise au point avec gdb depuis l'editeur.

[Adriweb]

L'aspect visuel est complètement personnalisable (affichage et emplacement des menus/options), tout comme la configuration du clavier (il y a un mode VIM par exemple). Perso j'ai un setup relativement minimaliste et un certain nombre de raccourcis claviers. Et qui ne change en gros pas du tout depuis bien des années.

[critor]

Je viens de mettre a jour https://www-fourier.univ-grenoble-alpes.fr/~parisse/nws.html, avec la commande plot de KhiCAS qui accepte maintenant des inegalites lineaires (on peut en combiner plusieurs avec and et or). Par exemple (on peut utiliser shift-3 pour saisir plot et shift-0 pour and)

Code: Select all

plot(x+y<1 and x-2y>0)


Déjà ? Superbe, je viens donc de mettre à jour :
QCC 2021

Si je comprends bien, ces nouveautés sont uniquement disponibles sous Khi ?
Seront-elles encore offertes via Omega malgré l'abandon du projet ou pas ?

C'est pour savoir quel firmware je recommande dans le tableau QCC sur la ligne "modification suggérée". Je ne peux pas mettre plusieurs liens sur une même case, nous n'avons rien de prévu en ce sens actuellement. Devrais-je donc remplacer Omega par Khi ?

Merci.