comment ca marche ziplib en C ??? - Page 2

C'est pas une question d'être sympa ou pas; si ça ne tenait qu'à moi je ne fermerais aucun topic nulle part et je ne kickerais ni ne lockerais personne, mais parfois ils ne me laissent pas le choix. Ceci dit, rien ne vous empêche d'en parler (calmement) ici ou dans un autre topic dédié.
Mais la modération n'est pas un sujet à aborder dans ce topic.

Flanker
: Kevin, Pollux > j'ai dès le début précisé que j'y connaissais presque rien au C, mais comme j'étais le seul à ce moment, j'ai fait ce que j'ai pu

Oui je sais, d'ailleurs tu disais bien que ce que tu donnais un code approximatif (mais qui a été repris tel quel par bidoo); et tu remarqueras que je n'ai slappé que le contenu des posts

Au passage, si vous utilisez kernel.h avec succès, c'est que vous avez une version obsolète de TIGCC. Avec la dernière bêta, j'ai: "Unresolved reference to `__main'" (ce qui est normal, les hacks sont incompatibles avec TIGCC 0.95). Donc mettez à jour votre TIGCC!
TIGCC 0.94:
* n'est plus maintenu depuis un an et demi!
* est incompatible avec la TI-89 Titanium!
* a un linker obsolète.
* optimise nettement moins bien que TIGCC 0.95.

Alors mettons clairement les choses au point Kevin.
TIGCC 0.95 est une version beta, donc une version de test, pas forcément stable, par conséquent TIGCC 0.94 est ce qu'on peut considérer comme une version à jour.

GoldenCrystal :
Alors mettons clairement les choses au point Kevin.
TIGCC 0.95 est une version beta, donc une version de test, pas forcément stable, par conséquent TIGCC 0.94 est ce qu'on peut considérer comme une version à jour.

Désolé, mais nous ne maintenons pas de branche stable, donc pendant un cycle de développement, les seules versions à jour sont des bêtas. Et, dans un logiciel sans branche stable comme TIGCC, les bêtas sont en général moins boguées que la dernière version "stable" (vu qu'on n'a plus rien corrigé depuis 1,5 années, alors qu'on a corrigé pas mal de bogues dans la 0.95, qui n'étaient souvent pas des régressions).

Bref, n'utilisez que la dernière bêta! (Je vais d'ailleurs discuter avec Sebastian pour changer les descriptions de la page de téléchargements, vu qu'elles sont assez éloignées de la réalité.)

>Kevin: Heureusement que tu vois pas le dernier kernel.h que j'ai fait.

Cette page te dit-elle quelque chose, Kevin ? http://tigcc.ticalc.org/download.html

PpHd :
>Kevin: Heureusement que tu vois pas le dernier kernel.h que j'ai fait.

Tu ne veux pas faire une version propre pour changer?
À quoi bon:
* redéfinir _main? Il n'y a vraiment pas de raison valable de faire ça!
* changer les options choisies par l'utilisateur?
* changer le fonctionnement de RETURN_VALUE qui marche très bien?
* redéfinir des RAM_CALLs dejà définis dans compat.h? KEY_LEFT utilise déjà le RAM_CALL en kernel quand ça a un sens (compilation pour plusieurs modèles)! Mais tel quel, ça a l'avantage d'utiliser une constante quand c'est possible. Pourquoi utiliser un RAM_CALL si on compile pour un seul modèle? La compilation pour un seul modèle sert justement à pouvoir utiliser des constantes à la place!

GoldenCrystal :
Cette page te dit-elle quelque chose, Kevin ? http://tigcc.ticalc.org/download.html

Oui, j'en ai déjà parlé:

Kevin Kofler :
Bref, n'utilisez que la dernière bêta! (Je vais d'ailleurs discuter avec Sebastian pour changer les descriptions de la page de téléchargements, vu qu'elles sont assez éloignées de la réalité.)

./39: Parce que j'ai vire totalement tigcclib.h pardis pour ne garder que le compilateur

LOL, et donc on ne peut plus du tout utiliser TIGCCLIB avec kernel.h? Très intelligent...
Je ne comprends pas pourquoi tu cherches à remplacer TIGCCLIB plutôt que de rajouter les choses qui "manquent" (c'est-à-dire tout ce qu'on ne veut pas dans TIGCCLIB parce que c'est kernel-only: les déclarations de DLLs kernel et les trucs PreOs-only) tout simplement.

Chacun est libre de faire ce qu'il veut du moment que ca n'impiete pas sur la liberte d'autruis.

Mais ça n'explique toujours pas pourquoi tu remplaces TIGCCLIB au lieu de t'intégrer proprement!

Pkoi j'utiliserai tigcclib.h ? Je n'ai aucune raison, donc hop. On zippe le contenu, et on se met ses propres headers. Faut pas chercher + loin.

Je suis a la fois d'accord avec PpHd et Kevin. C'est dommage de rajouter des incompatibilités quand on peut s'en passer, mais ce passer de tigcclib ne me déplait pas du tout.

pourquoi ne pas faire un ifndef pphd_kernel.h dans tigcclib ?

La version actuelle de kernel.h n'utilise plus du tout tigcclib.h, donc à quoi bon? Et de toute façon, si je mets un #ifdef comme ça, je mettrai un #error dedans, donc tu n'as pas intérêt à ce que je le fasse. Quelle partie de "unsupported header" ne comprends-tu pas?

Et de toute façon, si je mets un #ifdef comme ça, je mettrai un #error dedans, donc tu n'as pas intérêt à ce que je le fasse

et la première chose que le gars qui veut fair eun programme fera, c'est de supprimer le ifndef...
c'est comme les commentaires mis par défaut, le première chose que je fais en créant un projet, c'est les virer... c'est aussi la première chose que j'explique dans mon tutorial

Il devra quand-même corriger les vraies erreurs (cf. ./33)...
Et sinon, je peux aussi mettre les vérifications dans GCC, ça ne sera pas aussi facile à supprimer.
Mais vu que kernel.h ne fonctionne de toute façon pas (./33), je n'ai rien à faire pour empêcher son utilisation, le header se rend lui-même inutilisable à travers ses propres hacks.

Et sinon, je peux aussi mettre les vérifications dans GCC, ça ne sera pas aussi facile à supprimer.

et plus de gens utiliseraient les anciennes versions...
déjà que certains ont mis bien longtemps avant de passer à la 0.95... je suppose qu'avec ce genre de comportement, ce serait pire encore.

De toute façon, cette discussion est futile:

Kevin Kofler :
Mais vu que kernel.h ne fonctionne de toute façon pas (./33), je n'ai rien à faire pour empêcher son utilisation, le header se rend lui-même inutilisable à travers ses propres hacks.

Donc rien ne sera changé de notre côté.

Kevin Kofler :
Et sinon, je peux aussi mettre les vérifications dans GCC, ça ne sera pas aussi facile à supprimer.

Ah bon, tu crois être le seul à savoir modifier GCC.. ?

Il n'y a pas grand monde ici à savoir même compiler GCC (sans les scripts de TIGCC/*nix), alors bon...

Il n'y a pas grand monde ici à savoir même compiler GCC

il suffit d'un

Ça dépend. Il suffit qu'il rate une formalité de la GPL et je peux lui interdire la distribution de TIGCC de manière permanente (GPL section 4).

moué... m'enfin, en même temps...

Mais bon, même la FSF ne fait pas ça (ils donnent toujours une chance de corriger le problème, et heureusement, parce que TIGCC lui-même n'a pas toujours été en règle avec les formalités). Et je ne pense pas qu'on en arrivera là; comme déjà dit, la version boguée de kernel.h s'est rendue inutilisable toute seule (et ce n'est pas faute d'avoir averti PpHd que son hack n'était pas compatible avec TIGCC 0.95).

en même temps, s'embourber dans des conflits à cause de licence, tout ça à cause d'un kernel.h, je crois que c'est un peu risible, non ?