TiWiki wiki en français, ti68k - Page 3

mouais.

Uther> on ne peut pas modifier la doc de tigcc.
De plus si c'est un lien, c'est par définition pas un regroupement

La réalisation d'une documentation alternative pour les appels AMS a été l'un des moteurs fondateurs de TiWiki, et tigcc et sa documentation n'ont rien à voir là dedans .
Il est également prévu de documenter des bibliothèques de fonctions couramment utilisées, par exemple genlib (squale92 a commencé un peu il me semble).

Ah oué Uther, complètement indépendemment : si je le marques sur ta page de discussion je sais pas si tu vas le lire alors je le marque ici => Evite de faire des articles genre DoorsOS si tu n'as rien d'autre à y marquer que "voir preos parce que c'est mieux/plus récent/etc". Les pages sans valeur ajoutée font diminuer la qualité perçue du site par les visiteurs
(en plus les jugements de valeur sur les pages risquent de délencher des trolls, et c'est pas le but de la chose (voir [url=http://fr.wikipedia.org/wiki/Wikipédia:Neutralité_de_point_de_vue]Neutralité de point de vue[/url] sur wikipedia ).

> Uther> on ne peut pas modifier la doc de tigcc
Faux: les sources sont disponibles, des centaines de fichiers ont été faits par des contributeurs externes.

> De plus si c'est un lien, c'est par définition pas un regroupement
Logique, mais il serait bête de faire deux regroupements (ce qui semble pourtant être ce qui va se passer)... roms a déjà fait un regroupement des principales docs techniques en-dehors de TIGCC.

Lionel Debroux :
> Uther> on ne peut pas modifier la doc de tigcc
Faux: les sources sont disponibles, des centaines de fichiers ont été faits par des contributeurs externes.

Tu as probablement compris que le point intéressant n'était pas ce à quoi tu as répondu. Cf le temps qu'il a fallu pour merger tes apports à la doc de tigcclib; le wiki est conçu pour ne pas avoir ce genre de problème.

> De plus si c'est un lien, c'est par définition pas un regroupement
Logique, mais il serait bête de faire deux regroupements (ce qui semble pourtant être ce qui va se passer)... roms a déjà fait un regroupement des principales docs techniques en-dehors de TIGCC.

(très intéressantes comme docs soit dit en passant)
Et il y avait déjà la doc de tifs, donc bon, je ne vois pas de quoi tu te plains. Je ne conçois même pas comment on peut critiquer le fond de ce genre de projet en fait.

Lionel Debroux :
> Uther> on ne peut pas modifier la doc de tigcc
Faux: les sources sont disponibles, des centaines de fichiers ont été faits par des contributeurs externes.

C'est loin d'etre la meme chose qu'un wiki : meme si les mainteneurs étaient bienveillants (), il n'y a pas du tout la meme facilité de modification (donc on n'y touche que quand c'est VRAIMENT indispensable : contenu incorrect, fonctions manquantes) Alors qu'avec TiWiki quelqu'un qui se rend compte que telle fonction du tios est lente peut facilement faire part de ses remarques, indiquer en combien de tps la fonction s'execute, qqun peut a son tour nuancer en disant qu'on peut regler tel parametre ou utiliser tel autre code, etc...
Et encore, je ne parle que du domaine de la doc de TIGCC, a savoir les fonctions standard ; il y a plein d'autres choses dignes d'intéret qui ne sont pas mentionnées dans TIGCClib (par exemple, les ports hardware, ou des conseils d'optimisation ; et une doc externe, c'est pas pareil : c'est utile de pouvoir parler de $600005 dans la doc de [tiwiki]idle[/tiwiki], par exemple)

> Cf le temps qu'il a fallu pour merger tes apports à la doc de tigcclib; le wiki est conçu pour ne pas avoir ce genre de problème.
Disons que le choix de priorités du (il est tout seul) mainteneur n'est pas de vérifier et mettre la doc (boulot plutôt _pénible_ et long) en premier. Je ne peux pas l'aider, puisque je serais juge et partie.
Mes apports ne sont pour la plupart pas mergés. Le premier bloc l'est presque entièrement (c'était du temps où Sebastian s'occupait encore de TIGCC). Le deuxième, pas, même après que je lui aie donné une liste d'une quarantaine de fonctions faciles à intégrer.
En ce moment, il est à fond sur le debug. Ca aidera surtout ceux qui ne lisent que le C (ce qui est à mon avis, pour notre plateforme, un gros défaut: on ne sait alors pas ce qui fait que c'est mal optimisé), parce que ceux qui connaissent déjà la programmation évoluée sur les TI-68k depuis longtemps savent comment on s'en passe.

Les fonctions de progress bar d'AMS 2.00+ sont ultra-lentes. C'est mentionné dans ma documentation de ces fonctions...

> par exemple, les ports hardware,
Doc de roms.
> ou des conseils d'optimisation
Upcoming tutorial S1P9 by TICT...

> Et il y avait déjà la doc de tifs, donc bon, je ne vois pas de quoi tu te plains
A part le CAS et les FlashApps, c'est indigent (documentation des ports, des fonctions de relativement bas niveau !) et parfois faux. C'est toujours orienté contre les programmes assembleur, même si la plupart de leurs arguments pour les FlashApps contre les programmes ASM ne tiennent pas.

Sur le fond, je suis d'accord que le wiki a l'avantage de la flexibilité, du nombre de mainteneurs. Mais:
> Je ne conçois même pas comment on peut critiquer le fond de ce genre de projet en fait.
Comme Kevin l'a dit: à moins que ça ait changé depuis qu'il l'a posté, le fait de ne pas citer la source (actuellement) principale, la documentation de TIGCC, n'est pas correct.

Lionel Debroux :
Les fonctions de progress bar d'AMS 2.00+ sont ultra-lentes. C'est mentionné dans ma documentation de ces fonctions...

Oui mais bon c'est pas suffisant. Par exemple j'avais déja mesuré le tps d'execution de HeapAlloc() en fonction de la taille a allouer dans le meilleur des cas, si y avait eu un truc du style de TiWiki je l'aurais bien écrit dedans... alors que la pour le retrouver ca mettrait un certain tps ^^

spectras:
Ah oué Uther, complètement indépendemment : si je le marques sur ta page de discussion je sais pas si tu vas le lire alors je le marque ici => Evite de faire des articles genre DoorsOS si tu n'as rien d'autre à y marquer que "voir preos parce que c'est mieux/plus récent/etc". Les pages sans valeur ajoutée font diminuer la qualité perçue du site par les visiteurs

Je n'ai pas fait un long article car je donne surtout un lien vers le mot [tiwiki]kernel [/tiwiki]qui lui contient une description plus détaillée. J'ai fait un article bien plus long sur PreOS car il dispose de bien plus de fonctionalité. Alors que celle de DoorsOS, UniOS et TeOS sont très proches c'est pourquoi j'ai fait un lien vers kernel qui contient une definition commune à tous les kernel.
Je pense qu'il est quand même important de présiser qu'il n'est plus à jour. 'est d'ailleurs une grosse source de problème.

Lionel Debroux :
> par exemple, les ports hardware, Doc de roms.

ben oui, mais ca s'integre moins bien avec le reste ^^

> ou des conseils d'optimisation
Upcoming tutorial S1P9 by TICT...

[mode=méchant] oh le bel oxymore [/mode]

C'est toujours orienté contre les programmes assembleur, même si la plupart de leurs arguments pour les FlashApps contre les programmes ASM ne tiennent pas.

-assembleur+kernel -flashapp+nostub

Uther> oué ok. J'ai vu le commentaire de squale qui disait la même chose. Tant que ça reste des cas isolés c'est bon .
Cela dit il serait tout de même intéressant d'avoir un minimum d'infos pour TeOS, doorsos, etc. Par exemple les dates de sortie, date de dernière mise à jour, qui en a été le mainteneur, et éventuellement en quoi ils différaient de DoorsOS (pour DoorsOS en quoi l'arrivée d'un kernel a changé les choses).

Pour DoorsOS la dernière mise à jour date du 21 Aout 2000. C'est dire s'il est pas à jour. Pour TeOS ca doit être pire mais je sais plus ou chercher ce genre d'information. Leur seule véritable différence c'est les version d'AMS et HW sur lequel ils fonctionnaient.
Il me semble qu'UniOS marchait très bien juqu'à l'AMS 2.05, mais obligait l'utilisation de HW2Patch.
Bref ca fait pas grand chose à dire et je serais pas certain de ce que je raconterais c'est pourquoi j'ai préferé faire un article sur les kernel en général.

> par exemple, les ports hardware,
Doc de roms.

Ben moi je préfère un beau wiki lisible qu'un fichier texte de base.

je m'en vais de ce pas demander au roms en question si on peut inclure sa doc (normalement oui) (je me fais une spécialité du HW moi )

D'ailleur idéalement, vu que la doc de tigcc est penible (chose que je comprend) a maintenir/maitre a jour, un Wiki serait la solution idéale, comme ça (bon bien sur il faut que le wiki soit impécable, et qu'il y ai pas des boulets pour faire les chieurs) on exporte le contenu du wiki pour en générer la doc et pouf

Ca me semble etre la solution presque idéal...

C'est la fête aujourd'hui chez Pollux, non ?
>>> ou des conseils d'optimisation
>> Upcoming tutorial S1P9 by TICT...
> [mode=méchant] oh le bel oxymore [/mode]
La plupart du travail que j'ai fait sur les programmes de TICT est de l'optimisation.
Et j'ai amélioré les programmes de beaucoup d'autres programmeurs, ceux que je cite le plus souvent étant Ice Hockey 68k et Civ89 (plus de 10 KB chacun, tout en les rendant plus rapides).

La doc officielle, à ma connaissance, ne parle pas de programmation non native...


> D'ailleur idéalement, vu que la doc de tigcc est penible (chose que je comprend) a maintenir/maitre a jour, un Wiki serait la solution idéale, comme ça (bon bien sur il faut que le wiki soit impécable, et qu'il y ai pas des boulets pour faire les chieurs)
C'est un défaut des wiki... Locker les edits, ce n'est plus un Wiki. Soumettre les contributions à vérification, c'est trop lourd pour les intégrateurs, surtout au début.
> on exporte le contenu du wiki pour en générer la doc et pouf
Pour ça, il faut que les structures soient suffisamment proches. Cela semble être le cas en ce qui concerne la doc de TIGCC.

Je ne suis pas sûr que Kevin soit prêt à faire le boulot d'écriture des convertisseurs...

Il faudrait discuter de tout ça à un endroit où tout le monde puisse s'exprimer. il n'y a pas tellement le choix: le forum de TIGCC/TICT. Je sais, Kevin est à peu près le seul modérateur là-bas, car Sebastian et Thomas sont quasi-absents, mais ni TI-Gen ni yAronet ne sont fréquentés de manière régulière par les internationaux. Travis (Fisch2) était à peu près le seul autre que moi à le faire, et il n'a plus beaucoup de temps pour s'occuper de la communauté.
En revanche, avant de lancer quoi que ce soit là-bas, il faut arrondir les angles. Autrement dit, marquer très clairement les sources d'information, d'une manière qu'il n'est pas possible d'éditer - si ça n'est pas déjà fait, je n'ai pas regardé.

Lionel Debroux
: C'est la fête aujourd'hui chez Pollux, non ?

j'ai touché un point sensible ?

>>> ou des conseils d'optimisation
>> Upcoming tutorial S1P9 by TICT...
> [mode=méchant] oh le bel oxymore [/mode] La plupart du travail que j'ai fait sur les programmes de TICT est de l'optimisation.

Ah non mais je ne dis pas qu'il y a pas du boulot a faire en optimisation chez TICT, bien au contraire #remue#

La doc officielle, à ma connaissance, ne parle pas de programmation non native...

Ah oui, j'ai oublié -"doc officielle"+"doc de tigcclib" dans mon post ^^

C'est un défaut des wiki... Locker les edits, ce n'est plus un Wiki. Soumettre les contributions à vérification, c'est trop lourd pour les intégrateurs, surtout au début.

Il est absolument hors de question de bloquer les edits (excepté deux ou trois pages comme la page d'Accueil, encore que je me demande si c'est une bonne idée), et soumettre les contributions à vérification grandissez un peu, quoi ([jeu] trouvez à qui s'adresse ce pluriel).

on exporte le contenu du wiki pour en générer la doc et pouf

Oué c'est pas bete ça. Un peu comme la Wikipédia qui release un snapshot du wiki sur CD . Y'aurait moyen de développer un petit prog qui parse la BDD et génère une version offline.

Pour ça, il faut que les structures soient suffisamment proches. Cela semble être le cas en ce qui concerne la doc de TIGCC. Je ne suis pas sûr que Kevin soit prêt à faire le boulot d'écriture des convertisseurs...

Mais on n'a pas parlé de tigcc. Et je vois encore moins ce que Kevin vient faire là-dedans

Il faudrait discuter de tout ça à un endroit où tout le monde puisse s'exprimer. il n'y a pas tellement le choix: le forum de TIGCC/TICT.

Non. Les trois seuls posts que j'ai fait là-bas ont été supprimés. Pour l'instant le seul endroit où tout le monde peut s'exprimer c'est le Forum TI International.

spectras
:

on exporte le contenu du wiki pour en générer la doc et pouf

Oué c'est pas bete ça. Un peu comme la Wikipédia qui release un snapshot du wiki sur CD . Y'aurait moyen de développer un petit prog qui parse la BDD et génère une version offline.

L'installation de mediawiki est chiant a mettre en oeuvre ?

pasque exporter sous forme de ficheir HTML ne doit vraiment pas etre compliqué apres, a la limite on pourrait exporter dans un format XML et on peu y appliquer ce qu'on veux derriere (meme faire un PDF)

Je pense que proposer une verion "snapshot" offline serait vraiment une bonne idée. Je peut regarder ce qui est faisable si tu veux

enfin pour l'instant ce serait tres prématuré de faire une version offline je pense ^^

PolluX> Oui Mais avoir l'idée en tête permet de définir un objectif.
L'installation de mediawiki est assez lourde quand même oué. Il te faut un apache avec php et Pear installé, mysql et de préférence mod_gzip et mod_rewrite. Sans compter que j'ai modifié le moteur, il utilise quelques progs supplémentaires (notamment pour la coloration syntaxique du C et du Java) et les nouvelles balises ne sont évidemment pas supportées par le mediawiki d'origine (enfin pour tester c'est pas super important, mais si c'est pour faire du rendu c'est très gênant).

Apriori de ce que j'ai pu lire mediawiki peut exporter vers de l'XML ^^

Sinon une fonction interessante que mediawiki semble ne pas avoir, c'est le surlignage de mots quand on tombe sur la page en ayant comme referer google, ça me semble sympa comme feature (ça surligne les mots qui on été cherché dans google)

SpectraSSSS> certes, mais godzil avait l'air de vouloir se plonger dans les détails ^^

Godzil :
Sinon une fonction interessante que mediawiki semble ne pas avoir, c'est le surlignage de mots quand on tombe sur la page en ayant comme referer google, ça me semble sympa comme feature (ça surligne les mots qui on été cherché dans google)

beurk, ca rend souvent le texte illisible ca... pour faire ca bien il faudrait au moins que ca soit désactivable facilement et que le surlignage ne soit pas trop voyant... ou alors qu'il faille cliquer qqpart pour surligner ^^

le surlignage n'apparais QUE quand tu arrive d'une page de google qui t'amenne DIRECTEMENT sur le wiki, sinon c'est pas activé

ben oui je me doute, mais je trouve ca qd meme tres chiant... c'est d'ailleurs pour ca que j'utilise le cache google que qd vraiment un site répond pas, ou que j'ai effectivement besoin du surlignage (ce qui n'arrive pas hyper souvent)

enfin je parle pour moi hein, je sais pas ce qu'en pensent les autres...

./81> Tu sais quoi, je propose de créer une page, genre [tiwiki]TiWiki:Fonctionnalités[/tiwiki] pour mettre les idées de nouvelles fonctionnalités. Je garantis rien, mais déjà avoir toutes les idées au même endroit me permettra d'éviter d'avoir à fouiller partout quand j'ai du temps pour y réfléchir.

C'est sur

D'ailleur idéalement, vu que la doc de tigcc est penible (chose que je comprend) a maintenir/maitre a jour, un Wiki serait la solution idéale, comme ça (bon bien sur il faut que le wiki soit impécable, et qu'il y ai pas des boulets pour faire les chieurs) on exporte le contenu du wiki pour en générer la doc et pouf

l'avantage d'un wiki, pour peu qu'il soit fréquenté par un minimum de gens sérieux et un nombre réduit de "boulets" (je cite), c'est que les gens sérieux feront rapidement le ménage
(bon, après, s'il y a plus de lourds que de gens intéressés (et intéressants) ... me semble qu'on a vu ce que ça donnait dans le temps;.. ne serait-ce que pour le wiki intégré à yN)

Y'aurait moyen de développer un petit prog qui parse la BDD et génère une version offline.

serait pas con
pour les débuttants, y'a l'avantage de la lecture off-line
pour les autres, par contre, on perd la possibilité de corriger, genre, une ou deux fautes d'orthographe en lisant un article mais bon.

Oui mais la version offline n'est pas faite pour etre corrigé bien sur mais pour pouvoir l'emporter partout avec soi

sur sa calc ?

pourquoi pas

Apres tout on a bien un lecteur de eBook