Ticalc, une bande de gros bouseux - Page 3

et j'encourage tous les nioobies à coder en nostub !!!

Kevin Kofler a écrit :
Je ne pense pas que les programmeurs _nostub soient suffisamment bêtes pour mettre des données dans une DLL.

La betise humaine n'a aucune limite.

mé à quoi ça sert de faire un prog en mode kernel qd il peut s'en passer et qu'il n'utilise aucune lib ?!!

Tourner en mode multi-tache

Mais arrêtez avec votre multi-tâche sur TI-89/92+! Si vous voulez du "multi-tâche", faites un programme évènementiel (comme les FlashApps, ou comme RPN de Lars Frederiksen). Mais on ne peut pas faire beaucoup mieux sur un matériel sans MMU (la preuve: Prosit n'est jamais sorti de bêta).

Je suis d'accord avec squale92: il y a de bons jeux sous kernel et de bons jeux en nostub (pour ce que j'en vois, il y a beaucoup de jeux et de programmes kernel qui plantent souvent, bien plus que les programmes nostub que je connais, cependant).
J'ai des camarades qui utilisent txtrider pour des pompes, ça plante très régulièrement... (en deux fois, en lançant txtrider pour voir ce que ces pompes étaient: je regarde souvent sur les calculettes des autres, j'ai planté la calculette deux fois).
Maintenant que je ne fais plus d'execs et de trucs stupides sur ma calculette, j'arrive à passer des mois sans reset; eux passent rarement une semaine... Et puis ils ont des plantages bizarres (la calculette qui reste BUSY pour un temps illimité quand on lui demande la valeur du nombre i, par exemple, ceci est-il normal ?).

Certains programmes kernels n'ont pas d'équivalent en nostub, mais l'inverse est aussi vrai (qui va porter AutoAlphaOff ou faire n'importe quel TSR sous kernel ?).
Si vous voulez que CF soit sur ticalc.org, faites un mail à news.ticalc.org . C'est pas compliqué, nom d'un chien. Et en plus ça évite de critiquer pour rien des personnes qui bossent.
Mais vous risquez d'avoir peu de succès (très peu de programmes kernel sortent, maintenant). Ceux qui sortent, c'est parce que ce sont des équipes qui bossent depuis des années sur des projets, intéressants certes, mais qui ne sont pas passés à la programmation modernel.
Pourquoi êtes-vous jaloux de TIGCC, TICT, et d'autres équipes de programmation qui font elles aussi du (bon) boulot ?

"mé à quoi ça sert de faire un prog en mode kernel qd il peut s'en passer et qu'il n'utilise aucune lib ?!!": A rien, pourquoi ? A quoi ça sert de faire des libs quand il n'y en a pas besoin (du genre: les librairies de 200 octets sont parfaitement inutiles à mon sens) ?

Le kernel sur 89 et 92+ est juste le lourd héritage de Fargo sur la 92, qui lui, à ma connaissance, à la différence des kernels actuels sur 89 et 92+, était nécessaire pour tourner des jeux intéressants sur 92.

Et du multitâche sur 89/92+: c'est une excellente idée sans MMU ! N'est-ce pas toi, PpHd, qui disais sur le forum de la Newcalc (Dioxygène), que c'était vraiment chaud/impossible de faire du vrai multitâche sans MMU. Windows est event-driven, que je sache...

XDanger a écrit :
Maintenant que je ne fais plus d'execs et de trucs stupides sur ma calculette, j'arrive à passer des mois sans reset; eux passent rarement une semaine...

Moi aussi je passe des mois ans planter.

Et puis ils ont des plantages bizarres (la calculette qui reste BUSY pour un temps illimité quand on lui demande la valeur du nombre i, par exemple, ceci est-il normal ?).

On t'a jamais dit que txtrider est tres instable ?

Certains programmes kernels n'ont pas d'équivalent en nostub, mais l'inverse est aussi vrai (qui va porter AutoAlphaOff ou faire n'importe quel TSR sous kernel ?).

Les kernels ont ete concus pour empecher les TSR, donc...

Si vous voulez que CF soit sur ticalc.org, faites un mail à news.ticalc.org . C'est pas compliqué, nom d'un chien. Et en plus ça évite de critiquer pour rien des personnes qui bossent.

Moi j'attends de faire la version anglaise.

Mais vous risquez d'avoir peu de succès (très peu de programmes kernel sortent, maintenant). Ceux qui sortent, c'est parce que ce sont des équipes qui bossent depuis des années sur des projets, intéressants certes, mais qui ne sont pas passés à la programmation modernel.

Cf detient le record du nombre de news sur tinews
Va voir sur tinews et sur timetoteam.fr.st s'il y a personne (Je peux me tromper, c'est vrai).
Et je te raconte pas le nbr de mails recus
Et si la programmation moderne, c'ést utilise LoadDLL, laisse moi me rire. Je me gausse, oui A c'ést beau l'evolution nostub : oin pompe tout sur les kernels.

Pourquoi êtes-vous jaloux de TIGCC, TICT, et d'autres équipes de programmation qui font elles aussi du (bon) boulot ?

? Heu ?

"mé à quoi ça sert de faire un prog en mode kernel qd il peut s'en passer et qu'il n'utilise aucune lib ?!!": A rien, pourquoi ? A quoi ça sert de faire des libs quand il n'y en a pas besoin (du genre: les librairies de 200 octets sont parfaitement inutiles à mon sens) ?

Quel est ton sens ?

Le kernel sur 89 et 92+ est juste le lourd héritage de Fargo sur la 92, qui lui, à ma connaissance, à la différence des kernels actuels sur 89 et 92+, était nécessaire pour tourner des jeux intéressants sur 92.

Tu n'ás toujours pas compris l'interet des kernels toi.

[cite]
Et du multitâche sur 89/92+: c'est une excellente idée sans MMU ! N'est-ce pas toi, PpHd, qui disais sur le forum de la Newcalc (Dioxygène), que c'était vraiment chaud/impossible de faire du vrai multitâche sans MMU.
Du multi-tache stable oui. Mais du multitache si les applications sont stables il n'y a aucun probleme.

Windows est event-driven, que je sache...

Et alors ? J'ai l'impression que tu ne sais pas la difference entre les differents multitaches et les evenements...

XDanger
a écrit : Certains programmes kernels n'ont pas d'équivalent en nostub, mais l'inverse est aussi vrai (qui va porter AutoAlphaOff ou faire n'importe quel TSR sous kernel ?).

Celui qui fait ça aura de gros ennuis avec moi!

"mé à quoi ça sert de faire un prog en mode kernel qd il peut s'en passer et qu'il n'utilise aucune lib ?!!": A rien, pourquoi ? A quoi ça sert de faire des libs quand il n'y en a pas besoin (du genre: les librairies de 200 octets sont parfaitement inutiles à mon sens) ?

Entièrement d'accord.

Le kernel sur 89 et 92+ est juste le lourd héritage de Fargo sur la 92, qui lui, à ma connaissance, à la différence des kernels actuels sur 89 et 92+, était nécessaire pour tourner des jeux intéressants sur 92.

C'est ce que je dis sans arrêt, mais on ne m'écoute pas.

les seuls programmes que je fais qui planteraient ma TI si preOS n'était as installé sont des programmes en mode nostub !!!

Kevin Kofler a écrit :
Celui qui fait ça aura de gros ennuis avec moi!

arrete, tu me donnes des envies de le faire

erf

LOL

Mort de rire!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Bon vous avez terminés?

Je vais repondre a qqs questions:
>Pourquoi il y a plus de programme nostub aujourd'hui:
Tout simplement parce que TIGCC genere par defaud des prog nostub, et que pas mal de gens se sont mis a programmer avec ce soft pour la simple est bonne raison qu'ils connaissent le C / ou que le C est plus simple a apprendre.

>Pourquoi il y a plus de programme de bonne qualité en mode kernel:
Tout simplement parce que la communauté ti était la plus productive en quantité (mais pas forcement en qualité) il y a 2/3 ans ou il n'y avait que le mode kernel a la disposition des programmeurs.
De plus pas mal de daubes sortent a cause du language C qui est apparu avec TIGCC. Certaine personne prog sur ti comme sur pc... ce qui donne des resultats catastrophique.
Neanoins, il y a des progs en C qui vallent le coup. Jeux, mais surtout utilitaires.

Maintenant pour le mode kernel:
Il y a des prog stupide genre SMQ qui font leur propres lib, ce qui est ridicule car elle n'est utiliser par aucun autre programme.. Ce programme tire donc aucun avantage du mode kernel, il serait tout aussi interessant de le faire en nostub.
Maintenant il faut voir le juste milieu...
Perso, je prefere ne pas avoir de kernel sur ma calc, car je joue tres peu avec, et que le seul prog que j'ai sur ma ti est un viewer de texte nostub.

Maintenant, ce que je prefererai, et conseillerai, serai un grand projet:
Utiliser le mode kernel, mais en imposant qu'un seul kernel (preos) puisqu'il s'agit du meilleur, et de proposer avec 3 Lib universelles:
1 lib graphique tres optimisée (Xlib like).
1 Lib d'utilitaire
1 Lib de compression.

C'est trois lib etant programmée par l'ensemble de la communauté. Bien entendu avec un devellopement controllé, c'ad sortie de version controllée (pas comme le bordel qu'il y a eut pour util). Etant donné que tout le monde participe (sous la direction de 2 3 programmeurs principaux) a ce projet, chaque lib ne pourai etre que le meilleur qu'il puisse existé, chaque personne poura apporter sa contribution...

Enfin, vu que personne ne voudra faire ce projet, je ne peut qu'encourager les prog nostub, car ils evitent d'avoir 1 lib par programme etc.....
D'ailleur la prog nostub/asm est plus complexe que la prog kernel/asm.... enfin bon pas grave....

[cite]Kevin Kofler a écrit :
Celui qui fait ça aura de gros ennuis avec moi!


Pourquoi? Tu vas pas nous faire ton coup de propriété intellectuelle, tout le monde copie tout le monde sur ti...
Toi tu es bon pour finir dans une boite comme adobe ou macromedia, qui se font la guerre entre eux, pour vol de propriété intellectuelle sur l'agencement et le reagencement des module sur l'ecran!

Timad: J'ai quelques idées sur la compression pour ma part ca avance (pour ti bien sur compression avec ou sans pertes, pour textes, images et animations! son, est-ce bien util, je ne sais pas mais je peux le faire)

Xdanger! tu confonds le multitache preemptif(nt) et le multitache cooperatif(9x)

C'est trois lib etant programmée par l'ensemble de la communauté. Bien entendu avec un devellopement controllé, c'ad sortie de version controllée (pas comme le bordel qu'il y a eut pour util). Etant donné que tout le monde participe (sous la direction de 2 3 programmeurs principaux) a ce projet, chaque lib ne pourai etre que le meilleur qu'il puisse existé, chaque personne poura apporter sa contribution...

alala c bo les gens ki reve !!
enfin bon ya ka voir comm"ent tu t'entend avec tout le monde

[cite]freka a écrit :

Kevin Kofler a écrit :
Celui qui fait ça aura de gros ennuis avec moi!


Pourquoi? Tu vas pas nous faire ton coup de propriété intellectuelle, tout le monde copie tout le monde sur ti... Toi tu es bon pour finir dans une boite comme adobe ou macromedia, qui se font la guerre entre eux, pour vol de propriété intellectuelle sur l'agencement et le reagencement des module sur l'ecran!

Snake va te tuer

freka a écrit :
Timad: J'ai quelques idées sur la compression pour ma part ca avance (pour ti bien sur compression avec ou sans pertes, pour textes, images et animations! son, est-ce bien util, je ne sais pas mais je peux le faire)

ta compression avec pertes, elle donne koi? c vraiment rentable sur ti?
si oui, ca m'interesse bcp

Je peux pas encore te dire neurone j'ai aps encore essayé pour la compression avec perte pour l'image
Les images sont deja tellement pourries niveau qualité qu'on y verrait plus rien donc ca reste a voir, mais pour les enchainements d'images, j'ai mon idée, voir mes idées, on en avait parlé d'une avec thibaut! J'ai deja implémenté en java un algo de compression de type bz, donc en l'associant a une ou deux idées, on devrait obtenir de tres bon taux de compression d'images sur ti, du fait qu'il n'y a que 2 "layers" de couleurs
J'ai encore un bug avec le compresseur, que j'ai pas eu le temps de corrigé parce que je suis en exam, malgré que ca prenne une seconde, donc pour l'instant, je peux testé qu'avec des fichiers contenant des bytes < a 127 il faut que j'utilise une autre methode de lecture de stream c'est tout (readUnsignedByte, au lieu de readByte : l'erreur est flagrante et comprehensible, j'utilise des tableaux ), mais avec des fichiers textes, j'ai deja mis plus haut les taux que j'atteins, ensuite, si on l'associe d'autres methodes specifiques pour le format de ti (lié a l'affichage sur ti68k) on peut faire des choses bien je pense, en ne s'avancant pas trop, on peut faire facilement je pense du 75% facile, meme plus mais ca reste a voir, la je parle sans pertes!

TiMad> ton idée est loin d'être mauvaise, même si je doute qu'elle soit un jour réalisée...

freka> ton algo de bz serait peut-être un peu lent pour la ti nan?
sinon, la compression avec pertes, c kler que c l'avenir de la compression sur ti (il me semble que ca a pas encore été fait .. car shrnklib est choix entre huffman, RLE et lz77 enfin, il me semble !)

donc bosse bien

neuRone, non c'est completement faux, au contraire c'est tres rapide en decompression
Et toc
En effet la compression est un peu longue sur ti a mon avis...

oki
tu gagnes combien comparé au LZW ? (enfin, quand ce sera fini)

Ben ca depend du type de fichier, en tout cas, sur les petits fichiers, c'est un trs bon taux, par rapport au lzw et c'est normal.

La on a envoye l'e-mail au moment de la release de la version anglaise de cf a ticalc : ils n'ont plus d'escuses.

Bah si: c'est un programme pour kernel.

Peut etre

arf...

Quelle bande de bouseux ces ricains, 'font rien pour être aimés

pas grave, on n'a pas envie de les aimer