1

Le projet GCC4TI est fier d'annoncer sa deuxième release, GCC4TI 0.96 Beta 10.

C'est la première release de GCC4TI pour *nix, et la seconde pour Windows. Depuis la précédente release (Janvier 2009), nous sommes six personnes à avoir réalisé et testé un certain nombre d'améliorations visibles par les utilisateurs, particulièrement durant les deux dernières semaines :
[ul][li]outils : corrections de bugs dans l'IDE, tprbuilder, tigcc; déplacement de la plupart des "pctools" de la TIGCC Tools Suite dans l'environnement de développement, qui est leur place logique, ce qui veut dire que par exemple, ttbin2oth peut être utilisé sans installation supplémentaire de programmes ;[/li]

[li]exemples : création d'un script qui compile les examples, légère amélioration de la couverture de tests de TIGCCLIB par les exemples. Le fait de compiler et exécuter les exemples a permis de détecter et corriger trois bugs dans les outils, une erreur de compilation présente depuis 2005, deux warnings, et deux douzaines de conflits de noms entre exemples ;[/li]

[li]TIGCCLIB : sept optimisations. Les deux qui sortent du lot sont :
- SAVE_SCREEN (une des sections du code de démarrage les plus utilisées) : -16 octets. Cette optimisation a été contribuée à TIGCC il y a au moins deux ans, mais elle n'a pas été appliquée dans TIGCC, bien que le code de SAVE_SCREEN soit testé par de nombreux exemples ;
- Sprite8/16/32. Même si les nouvelles routines supportent un mode de dessin supplémentaire (RePLaCe) par rapport aux anciennes routines, elles sont plus petites et plus rapides. Une version plus ancienne de ces routines a été contribuée à TIGCC en octobre 2005, en même temps qu'un programme de test, mais ces routines améliorées n'ont pas été appliquées dans TIGCC ;[/li]

[li]documentation : vérification et intégration d'une petite partie des mises à jour de documentation qui ont été contribuées à TIGCC en 2002-2003. L'intégration a été facilitée par l'implémentation, dans la précédente release de GCC4TI, d'un contournement trivial pour une limitation des outils de documentation spécifiques à TIGCC/GCC4TI ;[/li]

[li]scripts d'installation *nix : ajout de la capacité de cross-compiler, pour faciliter la production de releases futures ; tests sur de nombreuses autres familles d'*nix, qui ont produit beaucoup de corrections de portabilité ; d'autres améliorations, comme un meilleur empaquetage et une extraction automatique + patch automatique des sources de binutils et gcc.[/li][/ul]

Note de mise à jour : l'IDE des versions précédentes ne dispose pas de numéro de version pour les définitions de coloration syntaxique, ce qui rend difficile la création d'un mécanisme automatique de mise à jour. Nous avons introduit le numéro de version, mais pour qu'il soit créé dans vos définitions, il faut remettre à zéro les définitions de coloration (c'est la procédure utilisée par les IDE précédents pour mettre à jour les définitions) :

Dans File > Preferences > Syntax Highlighting :
[ul][li]sélectionnez "Settings for:" > C Files, cliquez sur Reset[/li]
[li]sélectionnez "Settings for:" > GNU ASM Files, cliquez sur Reset[/li]
[li]sélectionnez "Settings for:" > A68k ASM Files, cliquez sur Reset[/li][/ul]
Quand vous cliquerez sur OK, toutes les modifications que vous aviez précédemment faites aux définitions seront effacées (!), mais vos définitions seront mises à jour ;


Allez à http://trac.godzil.net/gcc4ti/ pour les téléchargements, et l'infrastructure communautaire (mailing list, channel IRC, bug + feature request + patch tracker), pour pouvoir mettre vos commentaires sur les idées de la communauté, et ajouter d'autres idées.
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

2

Bravo top
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

3

Folco (./1) :
ce qui veut dire que par exemple, ttbin2oth peut être utilisé sans installation supplémentaire de programmes ;

Yeah ! top
Folco (./1) :
scripts d'installation *nix : ajout de la capacité de cross-compiler, pour faciliter la production de releases futures ; tests sur de nombreuses autres familles d'*nix, qui ont produit beaucoup de corrections de portabilité ; d'autres améliorations, comme un meilleur empaquetage et une extraction automatique + patch automatique des sources de binutils et gc

En effet, ça facilite la vie sur OS X happy
Folco (./1) :
Nous avons introduit le numéro de version, mais pour qu'il soit créé dans vos définitions, il faut remettre à zéro les définitions de coloration (c'est la procédure utilisée par les IDE précédents pour mettre à jour les définitions) :

Vers un système de màj automatique ? happy Ça serait cool, ça !


En tout cas, beau boulot !
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

4

Folco (./1) :
déplacement de la plupart des "pctools" de la TIGCC Tools Suite dans l'environnement de développement, qui est leur place logique

Pas du tout, ces outils n'ont pas grand chose à voir avec la chaîne d'outils et peuvent être utiles aussi séparément.
ce qui veut dire que par exemple, ttbin2oth peut être utilisé sans installation supplémentaire de programmes

Et du coup tu te tapes l'installation de tout GCC4TI si tu as juste besoin de ttbin2oth.
création d'un script qui compile les examples

Ne sert à rien, il y a des .tpr pour chaque exemple, je ne vois pas l'intérêt de compiler tous les exemples en même temps. De toute façon, leur but primaire n'est pas d'être compilés tels quels, mais d'être lus et adaptés. C'est de la documentation, ce ne sont pas des programmes faits pour être utiles tels quels (avec l'exception des 2 jeux de Zeljko Juric).
deux douzaines de conflits de noms entre exemples

"Conflits" genre "le même nom on-calc"? C'est normal, ces exemples ne sont pas faits pour être envoyés tous en même temps à la calculatrice, ce ne sont que des exemples!
- SAVE_SCREEN (une des sections du code de démarrage les plus utilisées) : -16 octets. Cette optimisation a été contribuée à TIGCC il y a au moins deux ans, mais elle n'a pas été appliquée dans TIGCC, bien que le code de SAVE_SCREEN soit testé par de nombreux exemples ;

Il faut tester les modifications intensivement parce que ce code va se retrouver dans presque tous les programmes et faire ça pour seulement 16 octets n'était tout simplement pas ma priorité.
- Sprite8/16/32. Même si les nouvelles routines supportent un mode de dessin supplémentaire (RePLaCe) par rapport aux anciennes routines, elles sont plus petites et plus rapides. Une version plus ancienne de ces routines a été contribuée à TIGCC en octobre 2005, en même temps qu'un programme de test, mais ces routines améliorées n'ont pas été appliquées dans TIGCC ;

Parce qu'il n'y avait pas de documentation. Si je me rappelle bien, on m'a envoyé la documentation depuis (assez récemment), je n'ai juste pas eu le temps de la merger. (Et si vous avez refait la documentation au lieu d'utiliser celle qu'on m'a envoyée, tant pis pour vous, fallait attendre...)
contournement trivial pour une limitation des outils de documentation spécifiques à TIGCC/GCC4TI

Contournement qui fait exactement le contraire de ce qui est désiré.
ajout de la capacité de cross-compiler, pour faciliter la production de releases futures

Intéressant, mais certainement pas indispensable... Et gérer cross-MinGW dans ces scripts est totalement inutile, il n'y a pratiquement que la personne qui produit les binaires officiels qui a besoin de compiler avec cross-MinGW et de toute façon ça ne peut pas être entièrement automatisé tant qu'il reste des composants Delphi (qui ne peuvent pas être cross-compilés).
tests sur de nombreuses autres familles d'*nix, qui ont produit beaucoup de corrections de portabilité

Pour une petite valeur de "beaucoup".

Je trouve aussi très malhonnête votre manière de nous faire un gros code dump juste avant la release. Vous n'allez pas me raconter que vous avez codé toutes les fonctionnalités qui n'étaient pas dans le dépôt la veille (22 commits, et je n'ai pas compté le dernier parce qu'il a visiblement été effectué après le code dump) en 2 minutes. roll Ces modifications ont clairement été développées ailleurs et transvasées sur le dépôt public juste avant la release. Ce n'est pas ça que j'appelle "développement ouvert". Et après vous m'attaquez parce que je ne committe pas certaines contributions tout de suite, mais compte le faire avant la release... roll Je committe mon travail directement dans le dépôt public, moi.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

Quant aux histoires de coloration syntaxique: les réglages ne sont pas mis à jour automatiquement parce qu'ils peuvent avoir été modifiés par l'utilisateur, c'est fait exprès.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

6

#kevin#
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7

Tout d'abord, bon anniversaire Kevin smile
Ensuite: merci pour ta constructivité et ton objectivité habituelles wink
Je vais répondre point par point au tissu de conneries que tu nous as une nouvelle fois pondu, pour laisser une trace argumentée, contenant des faits, du fait que tu écris de la merde. Inutile de chercher à répondre si tu n'as rien d'autre de plus constructif à dire.
[quote]
déplacement de la plupart des "pctools" de la TIGCC Tools Suite dans l'environnement de développement, qui est leur place logique

Pas du tout, ces outils n'ont pas grand chose à voir avec la chaîne d'outils[quote]
Ce n'est ni l'avis de Thomas (que j'ai évidemment consulté avant de faire le changement) ni le mien.
et peuvent être utiles aussi séparément.

Oui, c'est bien pour ça que:
ce qui veut dire que par exemple, ttbin2oth peut être utilisé sans installation supplémentaire de programmes
Et du coup tu te tapes l'installation de tout GCC4TI si tu as juste besoin de ttbin2oth.

Faux. Une précédente discussion que nous avons eue sur le sujet (flemme de retrouver le lien) fait ressortir la nécessité de continuer à fournir une release séparée des TI-68k Developer Utilities (ne serait-ce que pour ceux qui utilisent TIGCC, puisque tu n'as manifestement pas l'intention de répercuter ce changement).
Ca ne changera que quelques lignes dans le processus de build des TI-68k Developer Utilities (en gros, cp des .c depuis le répertoire qui va bien, paramétrable par une variable définie dans le script / Makefile).
deux douzaines de conflits de noms entre exemples
"Conflits" genre "le même nom on-calc"?

Oui.
C'est normal, ces exemples ne sont pas faits pour être envoyés tous en même temps à la calculatrice, ce ne sont que des exemples!

Mais ces conflits de nom font chier pour les tests de non-régression:
création d'un script qui compile les examples
Ne sert à rien, il y a des .tpr pour chaque exemple, je ne vois pas l'intérêt de compiler tous les exemples en même temps. De toute façon, leur but primaire n'est pas d'être compilés tels quels, mais d'être lus et adaptés. C'est de la documentation, ce ne sont pas des programmes faits pour être utiles tels quels (avec l'exception des 2 jeux de Zeljko Juric).

La compilation de tous les TPR en même temps a trouvé trois bugs dans les outils, une erreur de compilation présente depuis 2005 (ce qui montre que tu n'as pas compilé ces TPR depuis 2005, même pas comme tests de non-régression pour les versions de GCC & binutils que tu as releasées entretemps !) et un warning... en effet, ça ne sert absolument à rien. trinon
TIGCC ne dispose même pas du degré zéro de la qualité du logiciel que sont ce genre de tests de non régression triviaux.
Il faudra du temps et des efforts pour améliorer l'héritage qualité de TIGCC...
SAVE_SCREEN (une des sections du code de démarrage les plus utilisées) : -16 octets. Cette optimisation a été contribuée à TIGCC il y a au moins deux ans, mais elle n'a pas été appliquée dans TIGCC, bien que le code de SAVE_SCREEN soit testé par de nombreux exemples ;
Il faut tester les modifications intensivement parce que ce code va se retrouver dans presque tous les programmes et faire ça pour seulement 16 octets n'était tout simplement pas ma priorité.

1) c'est très difficile de reviewer et tester 8 lignes de code présentes dans la plupart des programmes AMS native trioui
2) tu nous emmerdes depuis des années avec ta défense de l'optimisation taille à fond, mais tu ne l'appliques pas dans tes propres programmes.
Sprite8/16/32. Même si les nouvelles routines supportent un mode de dessin supplémentaire (RePLaCe) par rapport aux anciennes routines, elles sont plus petites et plus rapides. Une version plus ancienne de ces routines a été contribuée à TIGCC en octobre 2005, en même temps qu'un programme de test, mais ces routines améliorées n'ont pas été appliquées dans TIGCC ;
Parce qu'il n'y avait pas de documentation.

Faux (mauvais prétexte). On parle des trois seules routines de sprite de TIGCCLIB, Sprite8, Sprite16 et Sprite32, qui restent encore et toujours les versions non optimisées de 2001 environ, et cela malgré:
[ul][li]des optimisations que je t'ai envoyées en mai 2002 (plus de sept ans !), puis en octobre 2003, c'est à dire à peu près au même moment que ces optimisations étaient appliquées à ExtGraph (donc elles étaient testées !);[/li]
[li]les optimisations supplémentaires et le mode de dessin supplémentaire qui t'ont été contribuées par Joey Adams en octobre 2005. Même au cas où il n'aurait pas documenté SPRT_RPLC, ça t'aurait pris cinq minutes de le faire, soit moins que le temps que tu as passé cette nuit à nous pondre le tissu de conneries qu'est ./4...[/li][/ul]
Le programme de test de Joey Adams a trouvé des bugs dans des routines d'ExtGraph, sur des parties autres que les optimisations que j'avais contribuées en 2002 et 2003: ces bugs ont été corrigés dans les jours qui suivaient le report, en octobre 2005 (r11 du SVN).
Si je me rappelle bien, on m'a envoyé la documentation depuis (assez récemment), je n'ai juste pas eu le temps de la merger.

J'espère pour toi que tu as publié ce qui t'a été contribué ? Si ce n'est pas le cas, tu ne peux pas te plaindre qu'on ait attendu maximum 10 jours pour committer des patches, surtout des patches qu'on a testés et re-testés pendant ce temps...
(Et si vous avez refait la documentation au lieu d'utiliser celle qu'on m'a envoyée, tant pis pour vous, fallait attendre...)

Attendre quoi ? Que quelqu'un qui s'assoit sur certaines contributions depuis 7 ans (!!!), qui est super occupé par ailleurs (et qui s'occupe de se donner de l'occupation inutile...), et qui n'a peut-être même pas publié les contributions, fasse quelque chose ?

Le fait est qu'à la date du 30 juin 2009, dans le repository CVS de TIGCC, il n'y a eu que six commits depuis le 3 janvier 2009 (release de GCC4TI 0.96 Beta 9). Parmi ceux-ci, quatre sont, dans les faits, des backports de GCC4TI; un corrige une typo; et un ajoute deux lignes, certes intéressantes, mais dans la doc des outils de doc, outils qui sont utilisés par environ trois personnes dans le monde... Même des trucs qui t'ont été reportés sur #tigcc (pour autant qu'il me semble, l'endroit que tu préfères pour ce genre de choses), n'ont pas été corrigés !
Ne parlons pas des patches qu'on a contribués il y a 9 mois, avant la première release de GCC4TI.
TIGCC n'est peut-être pas un projet mort, mais en tout cas, il n'est pas très vivant grin
contournement trivial pour une limitation des outils de documentation spécifiques à TIGCC/GCC4TI
Contournement qui fait exactement le contraire de ce qui est désiré.

Mais qui corrige dans la pratique le plus gros défaut à l'utilisation de ces outils, permettant ainsi d'avancer le boulot, au bénéfice de la communauté.
Le seul use case un peu convaincant pour la réécriture des outils de doc est l'ajout du format de sortie Qt4... et encore, puisqu'il existe d'excellents lecteurs libres de CHM pour les divers *nix. La génération du CHM est un problème pour toi, mais pas pour nous: les packages binaires que nous avons générés et testés montrent que nous disposons d'un panel important d'OS, Windows compris.
La participation à un projet collaboratif ouvert est tellement plus facile, et plus agréable, quand on peut discuter en groupe, décider en groupe, et partager le boulot wink

ajout de la capacité de cross-compiler, pour faciliter la production de releases futures
Intéressant, mais certainement pas indispensable... Et gérer cross-MinGW dans ces scripts est totalement inutile, il n'y a pratiquement que la personne qui produit les binaires officiels qui a besoin de compiler avec cross-MinGW et de toute façon ça ne peut pas être entièrement automatisé tant qu'il reste des composants Delphi (qui ne peuvent pas être cross-compilés).

Vrai, mais à nuancer nettement par le fait que les composants Delphi changent peu wink

Vous n'allez pas me raconter que vous avez codé toutes les fonctionnalités qui n'étaient pas dans le dépôt la veille (22 commits, et je n'ai pas compté le dernier parce qu'il a visiblement été effectué après le code dump) en 2 minutes. roll

En deux minutes, non, on ne va pas le raconter, parce que ce n'est pas crédible grin
En moins de deux semaines (depuis le 20 juin), avec plusieurs itérations de beta tests et de multiples réécritures d'historiques (scripts de build: pousser les bugfixes au point le plus tôt où ils avaient du sens), oui, on va te le raconter, parce que c'est un fait.
La réécriture itérative des commits donne un historique beaucoup plus clean que le commit-too-early-and-fix-afterwards (on aurait eu une bonne quarantaine de commits si on avait utilisé cette ""méthode"" de travail !). C'est une méthode de travail autre que la tienne, mais sache que plusieurs itérations et réécriture d'historique sont les méthodes de travail utilisées avec grand succès par, entre autres, les gros projets que sont le kernel Linux et Wine: c'est la bonne façon de faire, point à la ligne.

Et puis bon... ça te va bien de te plaindre qu'on n'a pas tout committé absolument tout de suite, toi qui ne prends pas le temps de committer des optimisations et contributions qui attendent, pour certaines, depuis plus de sept ans...
Conrad principalement, et peut-être Joey (qui n'est pas connecté en permanence) pourront te confirmer qu'on a mentionné sur #GCC4TI à la fois les modifs du build system et les optimisations. Tant pis pour toi si tu n'étais pas sur #GCC4TI wink
Franchement, est-ce que ça fait une grosse différence pour la communauté de retarder de moins d'une semaine (les patches optimisation sont dans la deuxième moitié de la série, ils ont été faits après les patches build system) le commit d'optimisations qui attendent, pour certaines, depuis des années tu t'en occcupes ? Non, très clairement. Au contraire, cette semaine a justement été utilisée à faire plus de tests (pour certains de ces tests, ça consiste juste à modifier quelques caractères dans un TPR pour qu'une option du code de startup soit testée...) ?

Quant aux histoires de coloration syntaxique: les réglages ne sont pas mis à jour automatiquement parce qu'ils peuvent avoir été modifiés par l'utilisateur, c'est fait exprès.

On en a déjà discuté tous les deux: s'il n'y a aucun moyen de détecter de quelle version l'utilisateur dispose (et c'est le cas, c'est dommage que Sebastian n'ait pas pensé à versionner sad ), il n'y a aucun moyen simple de proposer un jour, si nécessaire, un upgrade automatique qui ne détruise pas les modifications de l'utilisateur.
On a donc ajouté un tel moyen de détecter de quelle version l'utilisateur dispose, par la création de la clé de version lors d'un Reset (qui crée un état cohérent et connu des définitions). A partir de là, on a un point de base à partir duquel détecter les différences.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

8

Lionel Debroux (./7) :
Tout d'abord, bon anniversaire Kevin smile

Merci. wink

Je précise tout de suite que je ne vais pas répondre à toutes les "conneries" (ton propre mot!) que tu racontes, seulement là où il y a une réponse importante à fournir.
1) c'est très difficile de reviewer et tester 8 lignes de code présentes dans la plupart des programmes AMS native trioui

C'est parce que ce code est présent presque partout qu'il a besoin d'attention particulière.
2) tu nous emmerdes depuis des années avec ta défense de l'optimisation taille à fond, mais tu ne l'appliques pas dans tes propres programmes.

Je suis avant tout pour la correction du code, l'optimisation c'est bien, mais pas si on risque d'introduire des erreurs pour gagner pas grand chose au final.
Faux (mauvais prétexte). On parle des trois seules routines de sprite de TIGCCLIB, Sprite8, Sprite16 et Sprite32, qui restent encore et toujours les versions non optimisées de 2001 environ, et cela malgré:
[ul][li]des optimisations que je t'ai envoyées en mai 2002 (plus de sept ans !), puis en octobre 2003, c'est à dire à peu près au même moment que ces optimisations étaient appliquées à ExtGraph (donc elles étaient testées !);[/li]
[li]les optimisations supplémentaires et le mode de dessin supplémentaire qui t'ont été contribuées par Joey Adams en octobre 2005. Même au cas où il n'aurait pas documenté SPRT_RPLC, ça t'aurait pris cinq minutes de le faire, soit moins que le temps que tu as passé cette nuit à nous pondre le tissu de conneries qu'est ./4...[/li][/ul]

La version que tu as mergée est soit dépassée, soit incomplète, les routines actuelles de Joey Adams rajoutent tout un paquet de fonctions supplémentaires. Joey a dit clairement qu'il est contraire à un merge de ses routines sans les versions spécialisées, plus rapides, et dans certains cas aussi plus compactes (si on n'utilise qu'un mode).

Maintenant, tu dis peut-être qu'il faut utiliser ExtGraph dans ce cas, mais dans ce cas ce serait ton avis seulement. Le but de Joey et de moi est de proposer une solution convenable à l'intérieur de TIGCCLIB.
J'espère pour toi que tu as publié ce qui t'a été contribué ?

Ça a été discuté sur #tigcc.

Et je ne vais pas publier les contributions pour que vous les mergiez avant moi. Vous ne le faites pas non plus, tu ne le fais même pas pour tes propres modifications, cf. le patch dump juste avant la release. roll
Si ce n'est pas le cas, tu ne peux pas te plaindre qu'on ait attendu maximum 10 jours pour committer des patches

C'est minimum 10 mois qu'il faut attendre, pas 10 jours!

Et sinon, tu aurais dû en parler à Joey, il est présent sur #tigcc tout le temps. Il t'aurait parlé des fonctions spécialisées et de la doc qui va avec.
Vrai, mais à nuancer nettement
par le fait que les composants Delphi changent peu wink

Ils changent peu parce que personne ne veut les maintenir parce qu'ils sont en Delphi (raison de plus de les remplacer).
multiples réécritures d'historiques

sick
Le passé est passé, par définition il n'a pas à changer.
Je ne peux pas raconter que Napoléon était Italien et luttait pour l'indépendance de la Corse, alors pourquoi ce genre de réécriture de l'Histoire serait-il tolérable pour du code?
Votre manière de fonctionner est contraire à la GPL, parce qu'elle demande d'indiquer la date de tout changement, pas la date du gros dump, avec des modifications séparées mélangées en une seule.

Et puis tout ça ne change rien au fait que vos modifications n'étaient pas publiques jusqu'au gros patch dump.
Conrad principalement, et peut-être Joey (qui n'est pas connecté en permanence) pourront te confirmer qu'on a mentionné sur #GCC4TI à la fois les modifs du build system et les optimisations. Tant pis pour toi si tu n'étais pas sur #GCC4TI wink

Et tant pis pour toi si tu n'étais pas sur #tigcc quand on a parlé des routines de sprites de Joey il y a quelques mois. tongue
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

9

Kevin Kofler (./9) :
Et puis tout ça ne change rien au fait que vos modifications n'étaient pas publiques jusqu'au gros patch dump.


et alors?

10

Kevin... ce que tu es en train de faire, c'est de passer du temps à essayer de justifier ta paresse (et c'est très difficile à faire sans poster des conneries, tu n'y arrives d'ailleurs pas...), plutôt que de passer du temps à avancer (faire ENFIN ton boulot de mainteneur, quoi).
Il est vrai que tu as organisé TIGCC de sorte à ce que tu sois presque tout seul à faire tout, donc il est un fait que c'est d'autant plus lourd pour toi...
c'est très difficile de reviewer et tester 8 lignes de code présentes dans la plupart des programmes AMS native trioui
C'est parce que ce code est présent presque partout qu'il a besoin d'attention particulière.

1) Prétexte non valable: l'attention particulière de plusieurs personnes, ce code l'a déjà eue.
2) Prétexte non valable: reviewer huit instructions, c'est quand même vraiment pas la mort.
2) tu nous emmerdes depuis des années avec ta défense de l'optimisation taille à fond, mais tu ne l'appliques pas dans tes propres programmes.
Je suis avant tout pour la correction du code, l'optimisation c'est bien, mais pas si on risque d'introduire des erreurs pour gagner pas grand chose au final.

1) Avec la review de plusieurs personnes, et le programme de test ultra-fort que Joey t'a envoyé, qu'est-ce que tu veux de plus ??
2) "pas grand chose"... tu nous as déjà fait tout un plat, à plusieurs reprises, quand on a déroulé des boucles (parfois, pour une perte de place de seulement deux octets - DoubleSpriteDimensions, par exemple !) dans des routines graphiques qui ont besoin d'être rapides... et quand on diminue de 16 octets un code qui est présent dans la quasi-totalité des programmes, c'est "pas grand chose" ??
Tu te fous vraiment de la figure du monde...


La version des routines de Joey dont il m'a causé ce mois-ci, est une version qui comprend les spécifiques AND, OR, XOR et RPLC + la générique qui fait ces quatre modes de dessin. Pas de documentation HSF associée aux fonctions spécifiques, pas de documentation HSF associés aux fonctions génériques.
Joey n'a pas indiqué qu'il était contre un merge de ses routines sans les versions spécialisées, et n'a pas commenté en bien ou en mal l'indication du fait que les routines Sprite8, Sprite16 et Sprite32 étendues par ses soins et optimisées par mes soins (je lui ai envoyé les sources modifiés), passées avec succès à travers le même programme de test ultra-fort, feraient partie de la prochaine release de GCC4TI.
Après tout, il est quand même loin d'être dommage que des routines dont au moins deux personnes se sont occupées, à au moins trois reprises au total, la première fois il y a plus de sept ans (une éternité en informatique !), soient ENFIN proposées à la communauté !

Et je ne vais pas publier les contributions pour que vous les mergiez avant moi. Vous ne le faites pas non plus, tu ne le fais même pas pour tes propres modifications, cf. le patch dump juste avant la release. roll

Je te retourne la remarque: allons-nous toujours publier sur le champ des contributions de qualité beta, dont nous savons qu'elles nécessiteront certainement des modifs importantes (et ça a été le cas quand on a fait des tests sur OpenSolaris 2009.06, par exemple) et qu'elles seront releasées dans moins de deux semaines ?
La review et les échanges de patches ont été faits principalement, mais pas exclusivement, par mail.

Vrai, mais à nuancer nettement par le fait que les composants Delphi changent peu wink
Ils changent peu parce que personne ne veut les maintenir

Faux, tu sais très bien qu'on (GCC4TI) dispose de Delphi.
De plus, il y a trois mois (31 mars), sur #tigcc, je t'ai proposé de compiler les softs Delphi. Ca m'étonnerait que tu me donnes la permission de poster ta courte réponse grin

Votre manière de fonctionner est contraire à la GPL, parce qu'elle demande d'indiquer la date de tout changement, pas la date du gros dump, avec des modifications séparées mélangées en une seule.

Si c'est vraiment ça que demande la GPL (??!), alors nombreux sont les projets, à commencer par le kernel Linux et ses 30-50K patches par an, qui ne respectent pas la manière de fonctionner GPL, il me semble... et c'est bien mieux ainsi, d'ailleurs, parce que c'est clairement improductif de mentionner chaque changement !
Le truc que tu sembles ne pas comprendre, c'est que le logiciel, ce n'est pas la même chose que l'Histoire... On ne peut évidemment pas réécrire des _faits_ de la vie réelle, mais le logiciel n'est pas un fait de la vie réelle. Le logiciel est TRES différent de la vie réelle.
Et puis tout ça ne change rien au fait que vos modifications n'étaient pas publiques jusqu'au gros patch dump.

Toute cette discussion ne change rien au fait que tu passes BEAUCOUP plus de temps à troller, ici et ailleurs, plutôt qu'à faire ton boulot d'unique mainteneur sur TIGCC.
Et tant pis pour toi si tu n'étais pas sur #tigcc quand on a parlé des routines de sprites de Joey il y a quelques mois. tongue

Je ne me souviens pas d'avoir lu ça...
Si c'était entre le 3 ou 4 janvier et le 31 mars, c'est facile à expliquer: un certain Kevin Kofler, 26 ans aujourd'hui, m'avait banni après après que j'aie mentionné sur ce forum qu'il nous avait insultés (un mot + un timestamp). L'insulte était, outre un manque de respect, venant de la part de quelqu'un qui se plaint avec véhémence quand on l'insulte, une violation des règles du chan. Le fait de révéler l'insulte sans avoir demandé la permission (que je n'aurais pas obtenue, de toute façon... grin) était aussi une violation des règles du chan.
Et encore, 'assholes' était carrément gentillet à côté d'un truc que Kevin s'est permis de poster en juin. Penser ce genre de choses, c'est déjà mal, mais se permettre de l'écrire en public (surtout quand on est op, et par là-même censé montrer l'exemple...), c'est complètement inadmissible. Si quelqu'un avait écrit ça à son sujet, il aurait été kb de façon définitive... Je n'ai pas testé, évidemment grin


Bref, je crois qu'on va laisser "Kevinou partout" à ses trolls et passer à des choses plus constructives...


[EDIT: correction d'une balise mal fermée.]
[EDIT2: Kevin me fait indirectement remarquer que ce n'est pas "ce mois-ci" qu'il a posté cette insanité, c'est en juin]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

11

bon heu... c'est quoi les nouveautés prévues pour la beta 11?

12

En regardant le tracker, on peut voir, par exemple:
* général: continuer la démarche vers un logiciel de meilleure qualité logicielle (#26 peut-être, #29, #46, etc). Ca prendra du temps et des efforts d'améliorer ce qu'on a hérité de TIGCC...
* TIGCCLIB: plus d'optimisations (#7) et de contributions (pas forcément des optimisations refusées par Kevin, ce qui est le sujet du ticket #8 ), j'imagine. #9 (upgrade "kernel" support) est un autre axe que Kevin a laissé en friche depuis au moins six ans, verrouillant loin dans le passé le support "kernel"...

Eléments possibles:
* #17: intégrer les patches de PpHd à ld-tigcc (y compris la doc, évidemment). Dans l'état actuel des choses, l'optimisation n'est pas aussi bonne que ce qu'elle pourrait - mais c'est plus difficile, et plus risqué (création de bugs...), de faire un patch complet.
C'est mieux d'avoir quelque chose qui fonctionne dans les cas principaux, même s'il n'est pas optimal, que rien du tout sous prétexte que le patch n'est pas fini. Voir Wine et ses nombreux FIXME("xxx not yet supported").
* peut-être (faut que je le poste sur le tracker), investiguer une bonne fois pour toutes sur ce foutu __need_in_use_bit;, dont il est assez manifeste qu'il est nécessité par beaucoup trop de fonctions. En gros, n'importe quel programme non trivial contient ce stub de ~130 octets, à moins qu'un edit sauvage des headers l'ait désactivé (ce que j'ai fait pour plusieurs releases de plusieurs programmes de TICT, sans retours négatifs: c'est pour ça que je pense que son utilisation est trop large).


Ce ne sont que des idées, bien sûr, qui ne demandent qu'à être discutées wink
(j'ai, en gros, repris les éléments du tracker dans l'ordre ^^)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

13

(je voulais juste que vous arrêtiez de vous fritter ^^)

14

Clair, on a plus de travail à faire que de discussion stériles à avoir avec le mainteneur d'un logiciel, fût-il le logiciel parent. Pour moi, cette release a prouvé que le travail commun donne des fruits autrement plus intéressants que les vaines polémiques...

(je me fais cette réflexion sûrement très bête pour tous, mais c'est la première fois que j'ai écris du code pour qqun d'autre que pour moi, si on excepte quelques patches minimes ici ou là).
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

15

(J'ai du boulot à sous traiter si ça t'intéresse trioui)

16

Bien joué les gars. Et quand vous parlez de l'IDE, c'est toujours celle en Delphi ou bien vous utilisez celle en C++/Qt ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

17

celle en delphi.

parce que celle en Qt dépend de KDE. Je dirai rien de plus.

18

Kevin Kofler (./8) :
Votre manière de fonctionner est contraire à la GPL, parce qu'elle demande d'indiquer la date de tout changement,


La seule chose qui se rapprocherait de loin de cette énormité est:
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
    * a) The work must carry prominent notices stating that you modified it, and giving a relevant date.

Source: http://www.fsf.org/licensing/licenses/gpl.html

Ce n'est pas la même chose...

19

Bon, OK, visiblement la GPLv3 a affaibli ça à "a relevant date". La formulation de la GPLv2 (que j'avais toujours dans la tête, je connais presque par cœur la GPLv2) était:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

20

Kevin Kofler (./19) :
je connais presque par cœur la GPLv2

eeek

Finalement, tu es plus proche de l'ordi que de l'humain, non ?

nono-le-petit-robot.png
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

21

Kevin Kofler (./19) :
Bon, OK, visiblement la GPLv3 a affaibli ça à "a relevant date". La formulation de la GPLv2 (que j'avais toujours dans la tête, je connais presque par cœur la GPLv2) était:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

Dans ce contexe, date est égale à l'année que l'on doit mettre en haut de chaque fichier modifié, pas le jour et le mois :
Copyright 1999, 2001, 2002, 2004, 2006, 2007, 2008, 2009 Free Software Foundation, Inc

Sinon je ne connais aucun logiciel sous GPL qui respecte la licence embarrassed

22

Va lire le fichier ChangeLog d'un logiciel maintenu par la FSF (mais ils sont bien les seuls (ou presque) à faire des changelogs aussi détaillés).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

23

La formulation de la GPLv2 demande à ce que ca soit inclut dans le fichier modifié, pas dans un fichier à part.

24

Information pour tous ceux qui voudraient faire passer des news sur TI-Gen: il faut bien penser à les fournir en français ET en anglais.
Règle énoncée par Kevin cette nuit. Je pense que nous sommes plusieurs à l'avoir oubliée ou à ne pas être au courant.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

25

c'est pour ça que le sous-titre de tigen est "le portail francophone de la communauté Ti" ? grin

au fait, il y a un problème avec le ndd : "tigen.org" (sans www) redirige vers un webmail
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

26

anéfé, j'avais pas fait de redir sur le domaine de base mais seulement www, parce que .tigen.org doit être un A et peut pas être un CNAME. Ca y est j'ai ajouté un vhost et une redir vers www.tigen.org, ça devrait être bon dès que la propagation DNS est faite.

27

sauf que la virgule dans l'url est problématique...

N'hésitez pas à mettre votre release sur ti-fr, un peu de vie dans la communauté, ça mérite toujours d'e^tre salué !
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

28

Zephyr (./25) :
c'est pour ça que le sous-titre de tigen est "le portail francophone de la communauté Ti" ? grin

Je suis également curieux de connaître le nombre de non-francophones lisant les news cheeky
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

29

Certes...
En fait, la première version de ./24 contenait "Règle énoncée (édictée ? grin)"... j'ai enlevé la parenthèse parce que c'était peut-être légèrement méchant, mais apparemment, non trioui
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

30

Et sur ti-fr ?
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant