Un tout nouveau shell pour TI: sh`L - Page 18

au sens strict du terme non, mais dans la pratique oui.
encore une analogie avec MS. y'a windows et linux, donc il n'y aurait pas de monopole de windows ?

Bien entendu mais personnelement lorsque j'ai voulu programmer en C sur TI j'ai était déçu par TI-FlashStudio mais en découvrant TIGCC j'ai était surpris. Je trouve dommage de faire des guerres et critiques sur TIGCC et les autres compilateurs ainsi que le Nostub et le Kernel chacun possédant des avantages et inconvénient et il serait plus intélligent de faire évoluer ceci en prenant les bon cotés et tenir compte des mauvais cotés. Pourquoi pas créer un topic sur critiques et suggestions de TIGCC pour lui permettre d'évoluer plus vite.
Chaque programmaeur qu'il soit bon au débutant apporte quelque chose au TI et ainsi permettant de faire vivre la communauté donc je ne voit pas pourquoi les décevoirs et les démotivés pour des compatibilités, nostub-kernel, compilateurs.... Chacun est libre de chosir.

TIGCC est un bon compilateur et j'encourage l'équipe à le faire évoluer. J'encourage aussi les débutant à programmer sur TI car les TI sont un bon moyen d'appentisage de la programmation, du fonctionnement d'un processeur... Et aussi un moyen de voir les possibilités et capacités extraordinaire des TI pour les exploiter à fond.

Bien sûr beaucoup seront en désaccord avec moi mais je trouve que TIGCC est un très bon compilateur et je ne critique pas les autres comme CC et TI-FlashStudio mais ils ne sont pas encore adapté.

personne ici n'a critiqué tigcc, et je suis sur que beaucoup de monde pense comme toi
l'objet de la discution ici est a propos de l'integration des librairies statiques. l'option choisie par l'équipe tigcc est de mettre en librairie standard, une librairie qui ne convient pas a tout le monde.

Je ne vois vraiment pas en quoi c'est un problème. Si ça ne vous convient pas, vous êtes toujours libres d'utiliser autre chose. En effet, le grand avantage du système de librairies statiques est que si vous n'utilisez pas ces fonctions, le fait qu'elles soient là ne changera strictement rien pour vous.

sur le plan technique, pour moi y'a pas de probleme
mais d'un point de vue "moral", vous "imposez" comme standard votre librairie. C'est la que ca me choque un peu.

Ben, nous incluons à notre projet le travail de ceux qui y contribuent, ce qui m'apparaît plutôt logique. Les autres auteurs ont pris le choix de distribuer leurs routines séparément (aucun ne nous a proposé ses routines, du moins pas sous la licence de TIGCCLIB - contribuer veut aussi dire mettre sous la même licence!), donc leurs routines ne seront pas dans TIGCCLIB par leur propre choix, et ils en tireront les conséquences.

Kevin Kofler
a écrit : Je ne vois vraiment pas en quoi c'est un problème. Si ça ne vous convient pas, vous

Comme je le disais plus haut, le problème n'est pas au niveau des utilisateurs actuels, mais plutôt des débutants qui n'iront pas chercher ailleurs, puisque tout est déjà fourni.

C'est de toute façon complètement absurde de vouloir contrecarrer la concurence; elle est nécessaire pour l'évolution ... donc par un raisonnement scabreux, inclure EXTgraph à TiGCC-Lib implique la mort de la prog sur ti puisque vous seriez les seuls à developper les environnements

-

Désolé Orion_, mais je me sens obligé de répondre à ces critiques injustifiées.

ExtendeD
a écrit : Comme je le disais plus haut, le problème n'est pas au niveau des utilisateurs actuels, mais plutôt des débutants qui n'iront pas chercher ailleurs, puisque tout est déjà fourni.

Et alors? Tu préfères qu'ils utilisent les routines de sprites qui sont actuellement dans TIGCCLIB?

nEUrOne
a écrit : C'est de toute façon complètement absurde de vouloir contrecarrer la concurence; elle est nécessaire pour l'évolution ...

C'est faux.

donc par un raisonnement scabreux, inclure EXTgraph à TiGCC-Lib implique la mort de la prog sur ti puisque vous seriez les seuls à developper les environnements

N'importe quoi!

Déjà, il y a des tas de domaines de programmation autres que celui des environnements de développement: jeux, programmes mathématiques et scientifiques, utilitaires divers, ... Je ne vois pas en quoi un "monopole" (entre guillemets, parce que ce n'en est pas un) au niveau des environnements de développement voudrait dire que la programmation est "morte".

Et ensuite, rien ne vous empêche de contribuer vous aussi à TIGCC si vous avez de nouvelles idées. TIGCC est un logiciel libre, et les contributions sont bienvenues. L'équipe de ExtGraph compte contribuer ExtGraph, donc je ne vois pas pourquoi nous devrions refuser cette offre. Le respect de la "concurrence" propriétaire dont les auteurs ne participent pas à notre projet n'est pas une raison valable.

Et alors? Tu préfères qu'ils utilisent les routines de sprites qui sont actuellement dans TIGCCLIB?

A mon avis ces routines ne devraient pas du tout être dans TIGCCLIB, TIGCCLIB devrait ce limiter a ce qu'elle sait faire le mieux: les ROMCALLS et fonction liées a l'AMS.

>C'est de toute façon complètement absurde de vouloir contrecarrer la concurence; elle est nécessaire pour l'évolution ... C'est faux.

C'est en partie vrai. Trop de concurence ne permet pas forcément de progresser mais l'absence de concurrence est en général source de stagnation.

Et ensuite, rien ne vous empêche de contribuer vous aussi à TIGCC si vous avez de nouvelles idées. TIGCC est un logiciel libre, et les contributions sont bienvenues. L'équipe de ExtGraph compte contribuer ExtGraph, donc je ne vois pas pourquoi nous devrions refuser cette offre. Le respect de la "concurrence" propriétaire dont les auteurs ne participent pas à notre projet n'est pas une raison valable.

Le problème c'est que comme vous refuserez la pluspart fonctions ou tout ce qui n'est pas conforme 100% a votre lgne de conduite, ca risque d'être dur

Uther Lightbringer
a écrit : A mon avis ces routines ne devraient pas du tout être dans TIGCCLIB, TIGCCLIB devrait ce limiter a ce qu'elle sait faire le mieux: les ROMCALLS et fonction liées a l'AMS.

C'est trop tard maintenant! Il est hors de question de supprimer des routines existantes, pour des soucis de compatibilité antérieure!

C'est en partie vrai. Trop de concurence ne permet pas forcément de progresser mais l'absence de concurrence est en général source de stagnation.

Ce n'est pas vrai du tout! Sebastian et moi, nous travaillons sur TIGCC autant que possible. Nous y passons une très grande partie de notre temps libre. La présence ou non de concurrence ne changera strictement rien à la vitesse à laquelle TIGCC progresse.

Le problème c'est que comme vous refuserez la pluspart fonctions ou tout ce qui n'est pas conforme 100% a votre lgne de conduite, ca risque d'être dur

Évidemment que les fonctions devront remplir nos standards de qualité de code pour être acceptées. C'est d'ailleurs aussi valable pour ExtGraph: si les fonctions ne correspondent pas à nos standards de qualité, elles ne seront pas acceptées elles non plus.

Kevin Kofler a écrit :
Ce n'est pas vrai du tout! Sebastian et moi, nous travaillons sur TIGCC autant que possible. Nous y passons une très grande partie de notre temps libre. La présence ou non de concurrence ne changera strictement rien à la vitesse à laquelle TIGCC progresse.

Quelle est la concurrence sérieuse de TiGCC ?
Y'en a pas ... S'il y avait de la concurrence, je suis sûr que TiGCC ne serait pas exactement comme cela, il y aurait des idées fortes de la concurrence etc.

nEUrOne
a écrit : Quelle est la concurrence sérieuse de TiGCC ?

TI-FlashStudio.

Et je répète que nous travaillons déjà le maximum possible sur TIGCC et que la présence ou non de concurrence n'y changera strictement rien!

j'ai dit "sérieuse"

Il y a des gens qui programment avec TI-FlashStudio, donc on prend cette concurrence au sérieux.

oui, mais ... pour toi, ce n'est pas une concurrence sérieuse et pour moi non plus !

Dans ce cas je demande par soucie d'equité que Xlib soit incluse directement dans tigcc tout comme graphx et genlib!

De toute maniere il faut comprendre la tigcc team...
leurs routines ne font pas le poid fasses au autres.. donc le seul moyen de les faire utiliser c'est de les imposées...

De toute maniere si ca se passe comme ca, je vais finir par dev une autre version de tigcc a partir de la divergence indiquée!

-

j'aime pas le pascal!

Si.

le pascal c de la merde !!!!!!!! C PoWa !!!!!!!!!

TiMad : c'est une bonne idée ça
Tu pourrais mettre en DL plusieurs ZIP, chaque ZIP contenant un compilo optimisé pour une famille de processeurs (cf le topic où Littleboy propose des TIGCC sur mesure ).

L'idée est quand même extremiste.

Orion_ > Je crois qu'il y a déjà un compilo pascal qui existe sur ti (Ultra Pascal)... enfin, s'il existe, il est mort, mais tu devrais peut-être chercher le site (s'il y en a un), il risque de contenir des infos intéressantes...

Voila : http://mxm.ticalc.org/

TiMad
a écrit : Dans ce cas je demande par soucie d'equité que Xlib soit incluse directement dans tigcc tout comme graphx et genlib!

Pour GraphX et GenLib, c'est impossible pour des raisons de licence.

XLib pourra être prise en considération si et seulement si tu nous permets de la diffuser sous la licence de TIGCCLIB (GPL + exception permettant l'usage dans les programmes propriétaires). Et attention, ça ne veut pas forcément dire qu'elle sera acceptée! Il y a des raisons contre, par exemple qu'elle ne s'intègre pas bien aux routines existantes. Par exemple, elle utilise sa propre fonction d'initialisation à la place de GrayOn. Et elle traffique les plans alloués par GrayOn de manière très sale.

TiMad a écrit :
De toute maniere il faut comprendre la tigcc team... leurs routines ne font pas le poid fasses au autres.. donc le seul moyen de les faire utiliser c'est de les imposées...

N'importe quoi!
Nous n'imposons rien du tout! Nous diffusons ce qu'il nous est possible de diffuser légalement sous une licence acceptable pour nous. (Celles de A68k et de ttpack - distribution commerciale interdite - sont déjà à la limite du tolérable, et les librairies closed-source comme GenLib ou GraphX dépassent cette limite. Et surtout, il est techniquement et légalement impossible d'intégrer une librairie closed-source dans TIGCCLIB, et nous n'avons aucune intention de diffuser d'autres librairies que TIGCCLIB.) Mais les utilisateurs sont libres d'utiliser des librairies propriétaires s'ils acceptent leur licence. C'est juste qu'elles ne seront pas dans TIGCCLIB. Le système de librairies statiques fait que si le programmeur n'utilise pas les fonctions de TIGCCLIB, le fait qu'elles soient là ou pas ne change strictement rien pour lui. Donc je ne vois que des avantages à lui proposer un nombre important de routines. S'il n'en veut pas, il n'a qu'à faire comme si elles n'existaient pas, le fait qu'elles soient là ne change rien pour lui, vu que de toute façon elles ne se retrouveront pas dans le programme.

De toute maniere si ca se passe comme ca, je vais finir par dev une autre version de tigcc a partir de la divergence indiquée!

LOL, tu n'as même pas le temps pour tes propres projets, alors pour forker le nôtre, c'est mal parti...
Et comme déjà dit, il n'y a aucune raison pratique pour faire un fork.

> L'idée est quand même extremiste.
Si peu, si peu...

> Le système de librairies statiques fait que si le programmeur n'utilise pas les fonctions de TIGCCLIB, le fait qu'elles soient là ou pas ne change strictement rien pour lui. Donc je ne vois que des avantages à lui proposer un nombre important de routines. S'il n'en veut pas, il n'a qu'à faire comme si elles n'existaient pas, le fait qu'elles soient là ne change rien pour lui, vu que de toute façon elles ne se retrouveront pas dans le programme.
Ce qui ne serait pas le cas si on utilisait un système de librairies dynamiques on-calc comme le kernel... Mais on ne va pas relancer un débat ici, on a tous d'autres choses bien plus utiles à faire...

> LOL, tu n'as même pas le temps pour tes propres projets
En effet. Monsieur TiMad, lui, au moins, BOSSE en CLASSE PREPARATOIRE...

Hummmm

Xlib est en GPL !

Si tu veux les source suffit de demander

XLib n'a jamasi été closed source