Tigcclib - Page 4

godzil
a écrit : Ha bon, recompiler qq chose dont la licence le permet est immoral ????

C'est immoral parce qu'il sait très bien que c'est contre la volonté des auteurs.

* PpHd lance ce projet en sachant très bien que c'est contre ma volonté et celle de mon équipe (les auteurs du code en question, je rappelle), en abusant de notre licence permissive, qui est là pour permettre à tous les programmes de l'utiliser et pour permettre à tout le monde de l'améliorer, pas pour que des gens fassent ce genre de portages malgré notre opposition explicite


C'est dommage mais votre licence le permet, un point c'est tout, tu ne peux rien y faire!
Ou alors passe a autre chose et arrete la gpl pour tigcclib...

jackiechan a écrit :
Kevin Kofler>À mon avis, c'est aussi surtout parce que tu détestes les kernels. Si qq1 avait proposé de porter un jeu kernel en _nostub alors que l'auteur n'aurait pas été d'accord, tu n'aurais certainement pas réagi comme ça...

Mais dans ce cas, l'auteur, lui, aurait probablement réagi de la même manière. Et dans le cas de Backgammon, c'est moi l'auteur. Et dans le cas de Backgammon, c'est contre la licence de le recompiler en kernel sans ma permission.

alexis a écrit :
* PpHd lance ce projet en sachant très bien que c'est contre ma volonté et celle de mon équipe (les auteurs du code en question, je rappelle), en abusant de notre licence permissive, qui est là pour permettre à tous les programmes de l'utiliser et pour permettre à tout le monde de l'améliorer, pas pour que des gens fassent ce genre de portages malgré notre opposition explicite


C'est dommage mais votre licence le permet, un point c'est tout, tu ne peux rien y faire! Ou alors passe a autre chose et arrete la gpl pour tigcclib...

La licence rend son action légale. Elle ne la rend pas moralement acceptable.

Mais pourquoi parler de moral ?
Qui a t'il d'immoral de vouloir faire fonctionner qq chose sur auter chose ?????


Dans se cas, le portage du noyau linux sur une machine 68k serait immoral ???

Arrete de dire se genre de bétises..

Par contre faire tigcclib.xxz et la vendre ensuite, oui la sa serait immoral !!
Mais que je sache PpHd n'a pas l'intention de le vendre, donc je vois pas ou il y a un probleme de moral/ethique..

Le problème c que certaines personne aime pas que l'on puisse faire autrement que se qu'il préconisent (genre un certain sujet a propos de DLL) mais il oublient que se qu'il préconisent NE SONT QUE DES CONSEIL, et surtout pas la vérité absolue...

Le kernel existe, les lib dynamique aussi, alors pourquoi ne pas les utiliser !
Et surtout arrete de dire que sa existe mais c pour la poubelle, si sa plait a certain de les utiliser, autent les laisser l'utiliser ! je vois pas ou est le crime..

Ensuite j'ai un tres bon argument en faveur des lib dynamique, et surtout je vois mal comment on pourrait utiliser des libs statiques pour sa :

Faire un programme utilisant des modules externes contenant du code !
(genre un jeu ou l'IA serait sous forme de modules et on selectionne les modules qu'on veux pour l'IA)

Voila encore un bon argument en faveur des lib dynamique !

Kevin Kofler a écrit :
Mais dans ce cas, l'auteur, lui, aurait probablement réagi de la même manière. Et dans le cas de Backgammon, c'est moi l'auteur. Et dans le cas de Backgammon, c'est contre la licence de le recompiler en kernel sans ma permission.

Tu sais, je ne suis pas sûr que l'auteur réagirait comme toi.
Tu es vraiment le seul que je connaisse à être autant fermé, vis-à-vis des kernels...
C'est bizarre que ça te mette autant en colère.Et dommage surtout

godzil a écrit :
Mais pourquoi parler de moral ?
Qui a t'il d'immoral de vouloir faire fonctionner qq chose sur auter chose ?????

Dans se cas, le portage du noyau linux sur une machine 68k serait immoral ???

Ça n'a aucun rapport. Il ne s'agit pas ici d'un portage sur une nouvelle machine qui permettrait à d'utilisateurs de profiter de TIGCCLIB alors qu'ils ne pouvaient pas le faire avant. Tous ceux qui pourront utiliser ce portage (les programmeurs et utilisateurs du mode kernel) peuvent déjà utiliser TIGCCLIB maintenant!

Le kernel existe, les lib dynamique aussi, alors pourquoi ne pas les utiliser !

Parce que les librairies statiques sont plus pratiques pour l'utilisateur (il n'a pas à s'occuper de récupérer la librairie, vérifier que c'est une bonne version etc., un programme, l'éditeur de liens, fait ça pour lui) et pour les développeurs des librairies (possibilité de changer l'interface binaire à tout moment tant que la compatibilité source est maintenue). Reste un troisième parti, le programmeur qui utilise la librairie, mais pour lui, comme vous le dites suivant, il n'y a aucune différence. Donc il devrait choisir ce qui est plus pratique pour les autres. C'est très égoïste de se dire: pour moi, il n'y a pas de différence, donc je choisis au hasard, et je m'en contrefiche de ce qui est plus pratique pour le reste du monde.

Et surtout arrete de dire que sa existe mais c pour la poubelle, si sa plait a certain de les utiliser, autent les laisser l'utiliser ! je vois pas ou est le crime..

Il n'y a pas de crime au sens propre, mais le problème est que les utilisateurs (donc tout le monde à part l'auteur!) devront souffrir des problèmes d'utilisabilité des librairies dynamiques.

Ensuite j'ai un tres bon argument en faveur des lib dynamique, et surtout je vois mal comment on pourrait utiliser des libs statiques pour sa :

Faire un programme utilisant des modules externes contenant du code !
(genre un jeu ou l'IA serait sous forme de modules et on selectionne les modules qu'on veux pour l'IA)
Voila encore un bon argument en faveur des lib dynamique !

Là, c'est une bonne utilisation des librairies dynamiques. Le partage de code n'en est pas une.

Kevin, évite de foncer tête baisser dans des pièges aussi stupide, ça sert à rien

Pour une fois, je suis assez d'accord avec Kevin, en ce que intégrer toutes les fonctions de TIGCCLib est un peu idiot.

Mais je pense qu'une lib dynamique avec seulement les fonctions du type Gray, fopen/fclose et sprites représenterait un gain de place quasiment aussi important que celui obtenu avec tigcclib.9xz, tout en minimisant la maintenance dûe à la modification de fonctions de type scanf & co.
Il faut aussi impérativement standardiser la convention d'appel; je pense que regparm(2) est un bon compromis.

Kevin Kofler a écrit :
Je me suis fâché beaucoup parce que:
* PpHd lance ce projet en sachant très bien que c'est contre ma volonté et celle de mon équipe (les auteurs du code en question, je rappelle), en abusant de notre licence permissive, qui est là pour permettre à tous les programmes de l'utiliser et pour permettre à tout le monde de l'améliorer, pas pour que des gens fassent ce genre de portages malgré notre opposition explicite

Mais c'est une amelioration de la mettre en dynamique !

* des personnes proposent de compiler Backgammon avec cette librairie dynamique, alors que ma licence interdit explicitement la distribution de versions modifiées (et ce genre de recompilation est une version modifiée). Ce ne serait donc pas seulement immoral (comme ce que fait PpHd), mais illégal.

C'etait une (mauvaise) blague !

Kevin Kofler a écrit :
Parce que les librairies statiques sont plus pratiques pour l'utilisateur (il n'a pas à s'occuper de récupérer la librairie, vérifier que c'est une bonne version etc., un programme, l'éditeur de liens, fait ça pour lui)

En tant qu'utilisateur je prefere les libs dynamiques, que je peux mettre a jour independamment du programme.

et pour les développeurs des librairies (possibilité de changer l'interface binaire à tout moment tant que la compatibilité source est maintenue).

Changer l'ABI entraine necessairement des problemes. Ne serait-ce qu'a cause de l'asm. Mais vous connaissez pas l'asm a tigccland. (Mauvais blague 2, je precise car tu pourrais croire que c'est du premier degre).

Reste un troisième parti, le programmeur qui utilise la librairie, mais pour lui, comme vous le dites suivant, il n'y a aucune différence. Donc il devrait choisir ce qui est plus pratique pour les autres. C'est très égoïste de se dire: pour moi, il n'y a pas de différence, donc je choisis au hasard, et je m'en contrefiche de ce qui est plus pratique pour le reste du monde.

Plus pratique : pas de maintenance de code a faire si les libs evoluent !

Il n'y a pas de crime au sens propre, mais le problème est que les utilisateurs (donc tout le monde à part l'auteur!) devront souffrir des problèmes d'utilisabilité des librairies dynamiques.

Qui sont inexistants sauf aux yeux d'aveugles.

Pollux a écrit :
Pour une fois, je suis assez d'accord avec Kevin, en ce que intégrer toutes les fonctions de TIGCCLib est un peu idiot.

Y'en a pas tant que ca (<11Ko). Et je peux surement faire baisser la taille rapidement.
en eviant le message : 'Libraries are not executable'.

Mais je pense qu'une lib dynamique avec seulement les fonctions du type Gray, fopen/fclose et sprites représenterait un gain de place quasiment aussi important que celui obtenu avec tigcclib.9xz, tout en minimisant la maintenance dûe à la modification de fonctions de type scanf & co. Il faut aussi impérativement standardiser la convention d'appel; je pense que regparm(2) est un bon compromis.

La maintenance sera inutile car j'imposerais une ABI.
Et la correction des bogues sera quand meme simple.

de tte facon mes prochaine creation vont tte avoir besoin de lib dynamiques..
J'utiliserait deja pas le format de tigcc, donc me reste 2 choix
Soit devel mon format (g deja qq ids)
Soit utilise le kernel

Je pense que je vais faire un mix des deux

PpHd> OK. Quelle convention d'appel comptes-tu utiliser? (pour GTC il vaut mieux ne pas dépasser regparm(2), et l'idéal serait peut-être regparm(2,1))

La convention standard. _stkparm. Je ne modifies en aucun cas les sources actuelles !
Je ne fais juste que les recompiler.

Il me semble que les sources C se compilent par défaut en regparm (et 3 je crois). En tout cas ce serait dommage de faire du stkparm pur (addq.l #2,a7, pas de moveq, bcp moins efficace lorsqu'on passe en arg le résultat d'un calcul...)

PpHd
a écrit : La convention standard. _stkparm.

La convention utilisée par TIGCCLIB pour les fonctions écrites en C n'est pas stkparm. C'est regparm(4).
Pour les fonctions écrites en assembleur, c'est actuellement stkparm, mais pour TIGCC 0.95, la convention utilisée variera de fonction en fonction selon ce qui est plus efficace.

A mon avis, c'est totalement inutile... mais vous faites ce que vous voulez.
En fait, c'est pas grave car je memorise le prototype de la fonction lorsque je crees la librarie.

???

Qu'est-ce qui est pas grave? Il vaudrait qd même mieux faire les bons choix pdt qu'il est encore temps de ne pas avoir l'ABI

Oui. Mais je ne veux pas toucher aux sources assembleurs. Donc je prend et garde ce qu'il y a a l'heure actuelle.

OK pour les sources asm, je parle des sources C.

Il parait qu'elles ont ete compiles avec regparm(4) (Cf post de Kevin).
Donc ca doit etre ca qu'elles utilisent.

Oui, ben c pour ça que je dis que c pas une bonne idée si tu veux que les progs compilés avec GTC marchent aussi. Prends plutôt regparm(2).

Bonne idée, comme ça on pourra dire que tigcc.a est nettement plus efficace que cette DLL de !"§$%&/()=?.

Oui, "nettement".

De maniere extremement significative
Ok, je les recompilerais. Mais faut que je recupere aussi les sources d'obj2ti pour enlever ce *ù*^*ù de message de 'Libraries are not executable' qui prend quasiment 3Ko sur les 10Ko.

Lol Tu veux pas grouper un petit peu certaines fonctions? Parce que ça risque de bouffer quand même un peu de RAM en plus

Mais non car c'est une vitrine technologique pure :

"Seule les fonctions reellements utilisees sont en RAM."

arrête tu vas finir par devenir comme Kevin :
"vous n'avez rien besoin d'installer à côté => vous perdez le moins de place possible"

C'est justement parce qu'il le dit sans arret, que j'ai eu envie de le faire.