Re: Générateur de cours - TI83PCE/84+CE/82Avanced
Posté: 03 Mai 2017, 13:03Tout simplement car tivars_lib ne gère pas les 68k, et je n'ai aucunement prévu de le faire.
Si quelqu'un a suffisamment de temps à "perdre" pour y ajouter le support de formats 68k et faire une pull request, tant mieux, mais ce n'est pas moi qui y passerait de mon temps, il y a déjà assez de boulot par ailleurs.
Mais en attendant, kCreator fonctionne, pour autant que je sache, et n'a pas de raison de disparaître tant qu'il est utilisable et utilisé.
Je le redis, si la partie z80 (à scinder de la partie 68k si besoin donc) de GX se retrouve être mieux faite via tivars_lib+choses de wistaro, alors on pourra réfléchir à son remplacement, mais en attendant, les choses seront distinctes et disponibles en parallèle.
Pour z80 et eZ80, les formats sont similaires et peuvent-être gérés par un même code commun (mêmes tokens, en gros, ou du moins ajouts incrémentaux par modèles/versions), mais créer un programme 68k est bien différent, au niveau du format de fichier, du vartype, des tokens, etc. C'est tout simplement autre chose qui n'a donc pas sa place au sein de tivars_lib (qui aurait pu s'appeler tiz80vars_lib, si c'est le soucis) s'occupant uniquement d'un jeu de formats suffisamment identiques pour être mis en commun au sein d'un même code (les différences mineures, je les gère (une partie du moins), justement, selon le modèle/type/...).
Je parle bien évidemment d'une lib qui parse/génère dynamiquement et correctement les fichiers. GX se permet de gérer davantage formats en même temps car concatène des bouts hardcodés sans avoir donc à se préoccuper de véritablement avoir à gérer tel ou tel format de manière maintenable facilement en cas de changement/évolution (pas forcément à tort, coder d'autres trucs beaucoup plus génériques et complexes, dans le contexte de création de toujours la même chose aurait été une perte de temps au début, même si c'était pour en gagner dans le futur).
Comme je l'avais déjà dit, avoir à gérer ceci est un cas d'exemple parfait pour de l'orienté objet, ce qui a motivé mon choix d'architecture pour tivars_lib - il est ridiculement simple d'ajouter le support d'un format : un héritage/implem d'une interface + 2 méthodes à coder, c'est tout.
Par ailleurs, je me "fous" des z80 non conformes aussi, en gros
Le but premier est la CE (et aussi la 82A, Wistaro insistant sur ce point), et il se trouve que le format étant identique ou presque sur les autres z80, ça passe aussi - donc tant mieux pour ceux qui utilisent des 83+/84+ et qui pourront utiliser ça cette année ou dans d'autres contextes, ils ont de la chance.
Si quelqu'un a suffisamment de temps à "perdre" pour y ajouter le support de formats 68k et faire une pull request, tant mieux, mais ce n'est pas moi qui y passerait de mon temps, il y a déjà assez de boulot par ailleurs.
Mais en attendant, kCreator fonctionne, pour autant que je sache, et n'a pas de raison de disparaître tant qu'il est utilisable et utilisé.
Je le redis, si la partie z80 (à scinder de la partie 68k si besoin donc) de GX se retrouve être mieux faite via tivars_lib+choses de wistaro, alors on pourra réfléchir à son remplacement, mais en attendant, les choses seront distinctes et disponibles en parallèle.
Pour z80 et eZ80, les formats sont similaires et peuvent-être gérés par un même code commun (mêmes tokens, en gros, ou du moins ajouts incrémentaux par modèles/versions), mais créer un programme 68k est bien différent, au niveau du format de fichier, du vartype, des tokens, etc. C'est tout simplement autre chose qui n'a donc pas sa place au sein de tivars_lib (qui aurait pu s'appeler tiz80vars_lib, si c'est le soucis) s'occupant uniquement d'un jeu de formats suffisamment identiques pour être mis en commun au sein d'un même code (les différences mineures, je les gère (une partie du moins), justement, selon le modèle/type/...).
Je parle bien évidemment d'une lib qui parse/génère dynamiquement et correctement les fichiers. GX se permet de gérer davantage formats en même temps car concatène des bouts hardcodés sans avoir donc à se préoccuper de véritablement avoir à gérer tel ou tel format de manière maintenable facilement en cas de changement/évolution (pas forcément à tort, coder d'autres trucs beaucoup plus génériques et complexes, dans le contexte de création de toujours la même chose aurait été une perte de temps au début, même si c'était pour en gagner dans le futur).
Comme je l'avais déjà dit, avoir à gérer ceci est un cas d'exemple parfait pour de l'orienté objet, ce qui a motivé mon choix d'architecture pour tivars_lib - il est ridiculement simple d'ajouter le support d'un format : un héritage/implem d'une interface + 2 méthodes à coder, c'est tout.
Par ailleurs, je me "fous" des z80 non conformes aussi, en gros
Le but premier est la CE (et aussi la 82A, Wistaro insistant sur ce point), et il se trouve que le format étant identique ou presque sur les autres z80, ça passe aussi - donc tant mieux pour ceux qui utilisent des 83+/84+ et qui pourront utiliser ça cette année ou dans d'autres contextes, ils ont de la chance.
