Lecture de Chaine 89s - Page 2

Et alors ? Avec l'installation automatique du kernel (Nouvelle feature de preos 0.58 ), y'a aucun probleme

Et avec le systeme de packaging, de compression de preos 0.58, ca fait deux fichiers au maximum :
programme (= pack avec auto-install + auto-extractible + libraries compressees)
preos (= kernel + decompresseur).

Et on lance avec programme()
alors moi l'avantage des nostub fasse aux kernels, je lui dis

-

PpHd a écrit :
Et alors ? Avec l'installation automatique du kernel (Nouvelle feature de preos 0.58 ), y'a aucun probleme

Elle ne marche pas correctement. (Cf. mini-messages.) Et elle ne sera jamais supportée par TIGCC, donc les programmeurs C ne pourront pas l'utiliser.

Et ça fait quand-même 4 fichiers externes (kernel + 3 libs), qui de plus sont à télécharger séparément. Donc les membres de notre forum vont t'envoyer ch**r si tu leur proposes ça.

Sur mon disque dur.

Orion_
a écrit : il est dispo ou PreOS 0.58 ?

Pas du tout. Il n'y a que PpHd qui a le code pour l'installation automatique du kernel, et il ne marche pas, donc laisse tomber.

Ah ? Pkoi tu me l'as pas dit ?

-

(11:34) Kevin Kofler » PpHd: << Bon ok, y'a tout le systeme d'anti-crash de preos qui est parti en couille (tictex resintalle les vecteurs d'origine) >>
Et hop, c'est déjà en dessous de nos standards de qualité. Désolé, mais j'ai l'impression qu'on ne peut pas faire ce que tu veux faire de manière qui fonctionne correctement. De programmes qui foutent la merde s'ils sont lancés sous Tictex, non merci, on n'en a pas besoin.

Et d'ailleurs, si h220xTSR n'a pas encore été installé et qu'on est dans TICTEX, ça fera quoi à ton avis? Réponse: plantage! (Il faudra d'ailleurs que je trouve un moyen de refuser l'installation de h220xTSR si on n'est pas dans l'écran HOME...)

Ben oué. Mais si tu trouves un moyen de refuser l'install, ca marchera.
Et le seul probleme, c'est les lancer depuis un shell.
J'appelle pas ca un gros probleme, perso.

Ecoute Orion, la simplicité d'utilisation est vraiment un argument a la con ...

Si qqun trouve compliqué d'installer un kernel et d'envoyer 2 libs (ce qui est deja fait pour 80% des utilisateurs potentiels), bah tant pis pour lui.

Je ne pense pas vraiment que c'est en machant le travail des utilisateurs (et accesoirement en faisant des choses pas propres du tout - comme recopier le contenu d'une lib, ce qui fait perdre de la place et de l'evolutivité - surtout pour graphlib, je te rapelle que les programmes qui refont leurs niveau de gris et qui sont sortis avant les niveau de gris parfaits de JM et PpHd sont toujours merdiques sur HW2, et qu'on pas trop comment ca va se passer sur V200) qu'on va faire avancer le shmilblic ...

Si l'utilisateur et trop con pour installer un kernel et pour lire les read-me, comment veut-tu qu'il utilise ton programme pour créer une vidéo ??
Et est-ce que ca vaut de la peine de se battre pour gagner des utilisateur incapables ?

-

je répondais au post de Dark Angel.

>Elle ne marche pas correctement (Cf. mini-messages.)
T'es idiot la. Ca marche parfaitement sous la ligne de commande d'abord.
Et je vais verouiller pour que ca ne fonctionne pas sous tictex, en testant si le pc est > a $40000 (meme si ca posera des pbs au "relancement").

>Et elle ne sera jamais supportée par TIGCC, donc les programmeurs C ne pourront pas l'utiliser.
Tu veux pas ? Bah, c'est pas grave.
Faut que j'optimise encore.
Votre stub me laisse 44 octets, et mon stub d'installation fait 60.
Faut gagner 16 octets pour faire un patcher propre.
Dur, dur

>Et ça fait quand-même 4 fichiers externes (kernel + 3 libs), qui de plus sont à
>télécharger séparément.
>Donc les membres de notre forum vont t'envoyer ch**r si tu leur proposes ça.
Nan. 2 fichiers : le programme principal qui contient ses libs integres (meme si je nconsogne pas ca), plus le kernel seul en fichier externe (pas encore implante le de decompresseur integre de preos mais ca ne saurait tarde).
Et je n'empeche personne de distribuer preos avec le programme

[nosmile]Juste. lol Kevin

>Et elle ne sera jamais supportée par TIGCC, donc les programmeurs C ne pourront pas l'utiliser.
C pas très gentil de bloquer tout le monde comme ça, Kevin. Laisse les autres faire leur choix, que diable. Il faut que tu réussisses à convaincre, là tu veux vaincre par n'importe quel moyen. C pas bien.

PpHd a écrit :
Ben oué. Mais si tu trouves un moyen de refuser l'install, ca marchera.
Et le seul probleme, c'est les lancer depuis un shell. J'appelle pas ca un gros probleme, perso.

Ce ne sont pas les seuls problèmes:
- Il est inacceptable pour moi qu'un programme qui n'est pas un TSR installe un TSR sans le désinstaller quand il a fini de s'exécuter.
- Je ne vois pas du tout l'intérêt de ça. L'utilisateur devra quand-même envoyer PreOs à la calculatrice, donc tout ce que ça apporte, c'est qu'il épargne 9 appuis de touches. Ça ne vaut vraiment pas le coup pour les ennuis que ça apporte.
- Ce genre de méthodes pour faire passer un programme kernel comme un programme normal ne font que cacher les défauts du format kernel, pas les supprimer. Si un programmeur veut que son programme se lance tout de suite, il n'a qu'à faire un vrai programme _nostub, pas un bidouillage qui ne marche pas dans tous les cas.
- Si le programme dépasse les 24 KO, tu fais quoi? L'installation automatique du kernel ne marchera pas parce qu'on aura droit à un "ASAP or Exec string too long". Donc il faut un lanceur en plus. D'ailleurs, ton idée de détecter TICT Explorer à travers PC>0x40000 ne marche pas dans ce cas. Et elle ne marche pas non plus si h220xTSR est déjà installé, mais PreOs ne l'est pas. Je te rappelle que h220xTSR exécute tous les programmes dans l'espace fantôme.

Pen^2 a écrit :
>Et elle ne sera jamais supportée par TIGCC, donc les programmeurs C ne pourront pas l'utiliser.
C pas très gentil de bloquer tout le monde comme ça, Kevin. Laisse les autres faire leur choix, que diable. Il faut que tu réussisses à convaincre, là tu veux vaincre par n'importe quel moyen. C pas bien.

L'idée de PpHd ne sera jamais supportée par TIGCC parce qu'elle apporte des problèmes et parce qu'elle n'a pratiquement aucun intérêt pratique. (D'accord, l'utilisateur évite de taper sur 9 touches... Cela vaut-il vraiment le risque de plantages à ton avis? À mon avis non. Et en plus il est pris pour un con, parce qu'on installe un kernel contre sa volonté - sinon il l'installerait lui-même. C'est PpHd qui veut "vaincre par n'importe quel moyen" - en cachant un cheval de Troie qui installe un kernel dans des programmes utilisateur -, pas moi.)

Donc n'essayez pas de me faire changer d'avis: TIGCC ne supportera pas le mode "cheval de Troie"!

Dark Angel a écrit :
Ecoute Orion, la simplicité d'utilisation est vraiment un argument a la con ...
Si qqun trouve compliqué d'installer un kernel et d'envoyer 2 libs (ce qui est deja fait pour 80% des utilisateurs potentiels), bah tant pis pour lui.

On voit que tu as tout compris du concept d'utilisabilité...
Il faut programmer en pensant à l'utilisateur. Et aussi en pensant au fait que l'utilisateur pourrait être con. La majorité des gens du monde sont cons, donc il faut programmer des programmes utilisables par des cons.

Je ne pense pas vraiment que c'est en machant le travail des utilisateurs (et accesoirement en faisant des choses pas propres du tout - comme recopier le contenu d'une lib, ce qui fait perdre de la place et de l'evolutivité - surtout pour graphlib, je te rapelle que les programmes qui refont leurs niveau de gris et qui sont sortis avant les niveau de gris parfaits de JM et PpHd sont toujours merdiques sur HW2,

Ils ont pratiquement tous été recompilés. Et puis, maintenant, on a déjà atteint les niveaux de gris "parfaits", donc plus la peine de penser à ça.

et qu'on pas trop comment ca va se passer sur V200)

Selon Scott Noveck, nos niveaux de gris marchent très bien sur V200. Ceux de graphlib de PreOs utilisent le même algorithme (mais un code différent), donc ils devraient également marcher très bien sans modifications.

Si l'utilisateur et trop con pour installer un kernel et pour lire les read-me, comment veut-tu qu'il utilise ton programme pour créer une vidéo ??

Tu oublies que TI-DivX est un outil pour programmeurs, et que donc l'utilisateur final ne sera pas celui qui a créé la vidéo!

Et est-ce que ca vaut de la peine de se battre pour gagner des utilisateur incapables ?

Oui. La plupart des utilisateurs sont incapables, donc en ignorant les incapables, tu discrimines la majorité.

Kevin Kofler a écrit :
Ce ne sont pas les seuls problèmes:
- Il est inacceptable pour moi qu'un programme qui n'est pas un TSR installe un TSR sans le désinstaller quand il a fini de s'exécuter.

Si ce n'est que ca, je ne vois pas ou est le pn. Si tu le souhaites, preos peut se desinstaller tout seul comme un grand.

Attend je reorganise ta reponse :

- Je ne vois pas du tout l'intérêt de ça. L'utilisateur devra quand-même envoyer PreOs à la calculatrice, donc tout ce que ça apporte, c'est qu'il épargne 9 appuis de touches. Ça ne vaut vraiment pas le coup pour les ennuis que ça apporte.

On voit que tu as tout compris du concept d'utilisabilité...
Il faut programmer en pensant à l'utilisateur. Et aussi en pensant au fait que l'utilisateur pourrait être con. La majorité des gens du monde sont cons, donc il faut programmer des programmes utilisables par des cons.

Bon est-ce que je dois expliciter d'avantage ?

- Ce genre de méthodes pour faire passer un programme kernel comme un programme normal ne font que cacher les défauts du format kernel, pas les supprimer. Si un programmeur veut que son programme se lance tout de suite, il n'a qu'à faire un vrai programme _nostub, pas un bidouillage qui ne marche pas dans tous les cas.

Ca marche tres bien que tu le veuilles ou non.

- Si le programme dépasse les 24 KO, tu fais quoi? L'installation automatique du kernel ne marchera pas parce qu'on aura droit à un "ASAP or Exec string too long". Donc il faut un lanceur en plus.

Comme les nostubs. Sauf que l'on peut lancer manuellement preos pour que ca fonctionne dans ce cas la.

D'ailleurs, ton idée de détecter TICT Explorer à travers PC>0x40000 ne marche pas dans ce cas. Et elle ne marche pas non plus si h220xTSR est déjà installé, mais PreOs ne l'est pas. Je te rappelle que h220xTSR exécute tous les programmes dans l'espace fantôme.

H220xTSR est sufisament intelligent pour savoir s'il est deja installe.
Dans ce cas je peux traiter ca a part. Je n'ai pas trouve la solution miracle pour detecter tictex je le sais bien.

L'idée de PpHd ne sera jamais supportée par TIGCC parce qu'elle apporte des problèmes

Lesquels ? Le probleme des shells ? Il suffit de faire une desinstallation propre, et y'aura aucun probleme. (penser a desinstaller h220xtsr si ncessaire aussi).
Donc ton code. Je peux faire un copier coller de ton code de seinstallation de h200xTSR ?

et parce qu'elle n'a pratiquement aucun intérêt pratique. (D'accord, l'utilisateur évite de taper sur 9 touches... Cela vaut-il vraiment le risque de plantages à ton avis? À mon avis non. Et en plus il est pris pour un con, parce qu'on installe un kernel contre sa volonté - sinon il l'installerait lui-même. C'est PpHd qui veut "vaincre par n'importe quel moyen" - en cachant un cheval de Troie qui installe un kernel dans des programmes utilisateur -, pas moi.)

Donc tu avoues que c'est pas genant pour l'utilisateur d'installer un programme avant un autre programme. Je croyais que c'etait pas bien
Tu atteinds des sommets dans la mauvaise foi la !
Et si tu consideres cela comme un cheval de Troie, je ne peux rien pour toi.
De ton point de vue, il suffit de ne pas envoyer preos et ca ne s'installera pas !

Donc n'essayez pas de me faire changer d'avis: TIGCC ne supportera pas le mode "cheval de Troie"!

M'en fous. Je suis assez grand pour demander a des personnes plus raisonnables. je vais envoyer un mail a Sebastian. Et sinon je distriburerais une version d'obj2ti qui le fait. Allala, dans quelles extremites tu me pousses.

Ils ont pratiquement tous été recompilés. Et puis, maintenant, on a déjà atteint les niveaux de gris "parfaits", donc plus la peine de penser à ça.

Le mot "pratiquement" me chagrine beaucoup... Et je n'en suis pas si sûr.

Tu oublies que TI-DivX est un outil pour programmeurs, et que donc l'utilisateur final ne sera pas celui qui a créé la vidéo!

Justement une lib dynamique serait plus adaptee.

Oui. La plupart des utilisateurs sont incapables, donc en ignorant les incapables, tu discrimines la majorité.

On instruit les incapables. On les aide. On ne leur mache pas le travail.

PpHd
a écrit : M'en fous. Je suis assez grand pour demander a des personnes plus raisonnables. je vais envoyer un mail a Sebastian.

Je vais avertir Sebastian de ça et lui expliquer pourquoi je n'en veux pas.
Même si je ne pense pas qu'il mettrait ça sans me demander mon avis, je vais quand-même lui rappeler de demander mon avis.

-

Je suis pour la deuxième solution.
C'est plus pratique pour tout le monde. Pas de kernel à installer (ni volontairement, ni involontairement), pas de fichiers externes qui traînent, ...

Je suis pour la 1. Pour des raisons de droits et de gain en taille memoire.
C'est moins souple. imagine qu'un jour quelqu'un ameloire un poil pk92lib, et que son code de decompression doit etre reecrit : les utilisateurs ne pourront pas profiter plienmenet de ses nouvelles fonctionnalites. Alors qu'il suffirait de mettre a jour pk92lib pour que ca marche !!!

-

Kevin Kofler a écrit :
Je vais avertir Sebastian de ça et lui expliquer pourquoi je n'en veux pas.
Même si je ne pense pas qu'il mettrait ça sans me demander mon avis, je vais quand-même lui rappeler de demander mon avis.

Moui, s'il-te-plait, donne moi un SEUL VRAI argument, et pas des trucs de mauvaises fois.

Si tu ne veux pas lire mes arguments, je n'y peux rien. Je t'en ai donné au moins une demi-douzaine!

c la 1/2 douzaine qui est désignée par la dernière partie de sa phrase

Relis toi aussi mes arguments.
J'ai donné des arguments techniques (pas seulement de principe) qu'il n'a pas voulu écouter.

LEs arguments que tu as donne sont :

1. Il est inacceptable pour moi qu'un programme qui n'est pas un TSR installe un TSR sans le désinstaller quand il a fini de s'exécuter.
2. Je ne vois pas du tout l'intérêt de ça. L'utilisateur devra quand-même envoyer PreOs à la calculatrice, donc tout ce que ça apporte, c'est qu'il épargne 9 appuis de touches. Ça ne vaut vraiment pas le coup pour les ennuis que ça apporte.
3. Ce genre de méthodes pour faire passer un programme kernel comme un programme normal ne font que cacher les défauts du format kernel, pas les supprimer. Si un programmeur veut que son programme se lance tout de suite, il n'a qu'à faire un vrai programme _nostub, pas un bidouillage qui ne marche pas dans tous les cas.
4. Si le programme dépasse les 24 KO, tu fais quoi? L'installation automatique du kernel ne marchera pas parce qu'on aura droit à un "ASAP or Exec string too long". Donc il faut un lanceur en plus. D'ailleurs, ton idée de détecter TICT Explorer à travers PC>0x40000 ne marche pas dans ce cas. Et elle ne marche pas non plus si h220xTSR est déjà installé, mais PreOs ne l'est pas. Je te rappelle que h220xTSR exécute tous les programmes dans l'espace fantôme.

Pkoi ca ne marche pas tes arguments ?
1. Je suis d'accord. La je code le systeme de desinstallation apres execution. Donc argument => poubelle.
2. Cf :

On voit que tu as tout compris du concept d'utilisabilité...
Il faut programmer en pensant à l'utilisateur. Et aussi en pensant au fait que l'utilisateur pourrait être con. La majorité des gens du monde sont cons, donc il faut programmer des programmes utilisables par des cons.

Sans commentaire, ou je dois encore pousser le bouchon ?
3. Et s'il veut faire un prog kernel qui soit utilisable directement ? C'est pas un argument technique la.
4. Dans ce cas il faudrait aussi un launcher pour les nostubs. Sauf que la on peut faire soit un launcher, soit lance preos avant le programme. Ou est le probleme ?

Kevin tu as une attitude lamentable