Mise au point interface Khi+KhiCAS/chat

[Adriweb]

Une interface web, qui laisse a déplorer, après si vous êtes prêts a accepter des contributeur cela peut largement être améliorer avec un peut de temps, la preuve je vous le propose.

Pour info, j'avais commencé: https://github.com/adriweb/emgiac, et Parisse avait même fait des contributions et updates du moteur, à l'époque.

Mais bon, pas eu le temps de continuer, donc si quelqu'un veut reprendre, on peut "relancer" ce projet, à la fois côté web, et côté cœur si Parisse recommence à mettre à jour le cœur - j'ajouterai bien volontiers des contributeurs au repo github.

[Adriweb]

Je ne sais pas si intégrer GMP et MPFR dans la toolchain Ndless soit la meilleur solution, il faudrait juste un repo giac qui submodule les repo de GMP et MPFR et compiler le tout ...

Je ne serai pas forcément contre, mais:
- essayons déjà de régler quelques problèmes en gardant l'archi actuelle sans parler de spécificités git.
- la toolchain Ndless fait déjà comme ça pour plusieurs libs utilisables via header + .a, ce ne serait pas donc une nouveauté en soi, juste 2 libs en plus.

[legmask]

Je ne sais pas si intégrer GMP et MPFR dans la toolchain Ndless soit la meilleur solution, il faudrait juste un repo giac qui submodule les repo de GMP et MPFR et compiler le tout ...

Je ne serai pas forcément contre, mais:
- essayons déjà de régler quelques problèmes en gardant l'archi actuelle sans parler de spécificités git.
- la toolchain Ndless fait déjà comme ça pour plusieurs libs utilisables via header + .a, ce ne serait pas donc une nouveauté en soi, juste 2 libs en plus.

Je suis totalement pour le fait de régler le problème, par contre je n'utilise khicas uniquement pour la numworks (donc je l'utilise pas), a savoir donc que l'intégrer pour la toolchain ne me serait pas vraiment utile ... Mais oui réglons le problème ...

[Lionel Debroux]

Juste sur un point, et même s'il est un fait que Git favorise la collaboration - il y a de bonnes raisons au basculement de nombreux projets vers Git, à l'existence de Github / Gitlab / etc.:

ayant utiliser les deux je parle d'expérience, svn est nettement plus complexe que git,

J'ai l'expérience contraire, avec une dizaine de collègues de travail, et le bazar que plusieurs ont été capables de mettre, plusieurs fois, dans les divers repositories Git - malgré l'utilisation d'une seule branche (tant qu'ils ne sont pas capables de faire comme il faut avec une seule, on ne va pas en mettre plusieurs !), des formations et un document qui décrit des procédures à appliquer. C'est à moi de réparer les bêtises après, de les forcer à re-cloner les repos, etc.
Avec SVN, c'est plus difficile de mettre le bazar quand on travaille sur une seule branche. Et oui, le branching SVN n'est pas très bon, même s'il doit être moins mauvais que le branching CVS.
A titre personnel et professionnel, ça fait plus de 14 ans cette année que j'utilise presque exclusivement Git, au début par-dessus SVN et plus tard également en pur Git.

[legmask]

Juste sur un point, et même s'il est un fait que Git favorise la collaboration - il y a de bonnes raisons au basculement de nombreux projets vers Git, à l'existence de Github / Gitlab / etc.:

ayant utiliser les deux je parle d'expérience, svn est nettement plus complexe que git,

J'ai l'expérience contraire, avec une dizaine de collègues de travail, et le bazar que plusieurs ont été capables de mettre, plusieurs fois, dans les divers repositories Git - malgré l'utilisation d'une seule branche (tant qu'ils ne sont pas capables de faire comme il faut avec une seule, on ne va pas en mettre plusieurs !), des formations et un document qui décrit des procédures à appliquer. C'est à moi de réparer les bêtises après, de les forcer à re-cloner les repos, etc.
Avec SVN, c'est plus difficile de mettre le bazar quand on travaille sur une seule branche.
A titre personnel et professionnel, ça fait plus de 14 ans cette année que j'utilise presque exclusivement Git, au début par-dessus SVN et plus tard également en pur Git.

Oui, certe je vais essayer de fixer la ci du mirroir git, je ne sais pas pourquoi ca marche pas..., mais rien que d'avoir un mirroir c'est deja parfait

[Lionel Debroux]

La CI est un point important, en effet. Mais c'est du boulot, et quand l'environnement est spécial, ça prend du temps à mettre en place.

Show/Hide spoilerAfficher/Masquer le spoiler

C'est d'ailleurs pour ça que je n'avance pas la release de libti*/gfm/tilp: l'environnement de build Windows est pénible à mettre en place, avec l'installation ou la compilation de nombreuses dépendances de build. C'est tellement plus simple sur Linux...

[parisse]

@LeGmask:
Comme le dit Adriweb, j'ai essaye git. Mais non, je n'ai pas reussi a m'y faire du tout, a chaque fois que je devais faire un commit ca me prenait un temps demesure. Au passage, l'editeur d'Adrien a commence par foutre le bazar dans l'ecriture de mon code source ce qui ne m'a pas vraiment plu non plu, et comme il n'avait pas le temps de travailler dessus, c'etait du temps investi pour moi sans avantages en retour, alors autant continuer a ma facon.
Je trouve tortoisesvn simple a utiliser (je n'utilise qu'une seule branche) et puis je ne vais pas utiliser plusieurs outils differents pour differentes collaborations. Geogebra a mis en place un mecanisme qui permet d'acceder sur github a la version a jour de giac, https://github.com/geogebra/giac/commits/master, qu'est-ce qu'il vous faut de plus?
Compiler giac et ses dependances est complique, il me faut pas mal de temps a chaque fois que je dois le faire sur une nouvelle architecture en faisant plein d'essais et en essuyant des echecs, quand j'arrive a un truc qui marche, je fais une archive, mais je n'ai pas l'energie pour rendre ca propre et automatique. Si c'etait simple, j'imagine que Adrien l'aurait finalise sur la npsire.
Pour finir, vous sous-estimez completement le temps et l'energie que ca prend de changer d'habitudes, et c'est de pire en pire quand on prend de l'age (c'est un peu comme le risque covid). C'est d'ailleurs tres probablement ce qui vous donne l'impression que l'interface actuelle de KhiCAS est difficile a utiliser. Ben oui, il vaut mieux lire un minimum la doc, parce que c'est prevu pour fonctionner en mode shell, entree algebrique, comme dans les annees 90. C'est quoi cet argument "Les jeunes ne veulent plus lire de doc?" (surtout quand vous me demandez de me taper la doc de git:-)). Vous pensez reellement qu'on apprend des maths sans faire un minimum d'efforts?

P.S.: concernant les contributions au code source de giac, je l'ai deja dit, je ne vois pas de personnes sur tiplanet capables d'y contribuer. Le faire a ma facon ne serait surement pas l'obstacle principal.
Si collaboration il doit y avoir sur KhiCAS, ce sera chacun dans son domaine (i.e. je ne touche plus a l'UI).

[legmask]

Bon j'etait un peut trop salé je pense, le prenez pas mal mais je suis un peut deg qu'un aussi beau projet ne soit pas utiliser a cause d'une mauvaise interface...

Oui il ya bien le trunk geogebra, j'ai exactement la même chose de mon coté ... et ca depuis Mai : https://github.com/giac-sync/giac-src
Si vous êtes prêts a continuer a push les changements via SVN sur le trunk de geogebra, je pense qu'on devrait pouvoir se débrouiller pour refaire le make system (initalement c'etait ce qu'on avait prévu avec Maxime) dans un repo a part (on garde que les source de giac) et donc de la CI. si vous êtes partant bien évidemment et si ya du monde partant ici aussi, puisque c'est un travail monstre ...

[Adriweb]

:Au passage, l'editeur d'Adrien a commence par foutre le bazar dans l'ecriture de mon code source ce qui ne m'a pas vraiment plu non plu,

Je n'étais même pas au courant 😮
Mais d'ailleurs pourquoi/comment du code de front end sur mon fork peut avoir fait change quelque chose (de non-frontend ?) sur le code upstream? Il ne me semble pas avoir changé quoi que ce soit à part le html et css. De toute façon c'est pas l'interface d'appel à la lib qui est la partie la plus compliquée la dedans, donc à la limite elle pourrait aussi évoluer que ça ne serait pas un obstacle.

Mais bon oui, pour le moment pas besoin de passer du temps sur ce fork, en tout cas moi je n'ai plus assez de temps libre pour ça. Mais comme je disais, si quelqu'un veut continuer, pourquoi pas

[parisse]

@LeGmask: ne vous inquietez pas, j'ai bien l'intention de continuer a faire des commits sur le svn de geogebra. C'est necessaire pour Geogebra et une precaution tres importante pour moi, je ne veux pas prendre le risque de perdre mon source (si par exemple je me fais voler mon PC et qu'il se produise en meme temps un incendie dans mon labo)

@Adriweb: c'etait le code JS qui avait ete modifie (par exemple ajout systematique d'espaces autour d'operateurs).