Progs en C - Page 2

Microbug
: vous étiez prévenu

Puis je savoir pourquoi on n'a pas le droit de discuter au sujet de GTools C dans un topic qui annonce sa sortie???

parce que ici l'auteur demande des sources pour tester, pas de dire que son travail selon toi est de la merde

Fais pas semblant de ne pas comprendre. Tu peux parler de GTC tant que tu veux du moment que ça sert à quelque chose, or :

Kevin Kofler
: ... qui ne sert strictement à rien parce que sur PC, il y a déjà TIGCC.

La c'est ton post, qui en plus de détruire gratuitement le travail de Pollux, ne sert strictement à RIEN.

[Edit] Post croisé ac Microbug.

Microbug :
parce que ici l'auteur demande des sources pour tester, pas de dire que son travail selon toi est de la merde

Écoute, si on n'a plus le droit de discuter des valeurs d'un logiciel dans un topic qui l'annonce, la liberté d'expression, elle est où? Je pensais que vous y teniez tellement...

Vertyos :
Fais pas semblant de ne pas comprendre. Tu peux parler de GTC tant que tu veux du moment que ça sert à quelque chose, or :

Kevin Kofler
: ... qui ne sert strictement à rien parce que sur PC, il y a déjà TIGCC.

La c'est ton post, qui en plus de détruire gratuitement le travail de Pollux, ne sert strictement à RIEN.

Si, il servait à rappeler que ce n'est que la version PC qui va sortir, pas celle que presque tous ceux qui attendent sa sortie attendent.

Et le message d'Orion_ servait à quelque chose (il a répondu à Thibaut) et il a aussi été censuré.

et la prochaine fois que tu posts hors sujet ici c tu rejoins orion ?

dans ton prochain topic ou tu annonces une release de tigcc, si on débarque et qu'on dit "tigcc c de la merde" ca te fera plaisir ?

Pour rappeller que TIGCC existe et que ce n'est "que" la version PC qui va sortir, tu aurais très bien pu le faire sans détruire GTC pour autant. Quand au kick d'Orion_ je n'y suis pour rien.

Kevin Kofler :
Écoute, si on n'a plus le droit de discuter des valeurs d'un logiciel dans un topic qui l'annonce, la liberté d'expression, elle est où? Je pensais que vous y teniez tellement...

ton comportement est 100x pire que ce que j'ai pu faire sur tict, mais dès que tu as le pouvoir, tu ne te prives pas pour censurer la moindre personne qui va à l'encontre de tes opinions.

En compilant GTC avec GTC, tu gagnes combien, par rapport à TIGCC ?

Je ne compile pas GTC avec GTC, parce que j'ai un programme un peu gore qui travaille sur le résultat (.s) de TIGCC et parce que GTC ne génère plus d'asm correct depuis un bail, donc ça sera difficile... Et quand la librairie utilisera le support des sections façon TIGCC 0.95, il y aura une rupture absolument irréversible avec la sortie asm. Mais c'est vrai que ça aurait été intéressant

Euh sinon pour ceux que ça intéresse :

[image]http://membres.lycos.fr/ltech/tichess-gtc.gif[/image]

Regardez la taille dans le Var-link

euh à la base c'est combien ?

33536 pour la version PPG inclue dans la distrib
28599 pour la version PPG recompilée avec GCC 3.3, -mregparm et -fomit-frame-pointer
auxquels il faut bien entendu rajouter 1685 octets de launcher...

et donc toi ça fait un fichier compressé auto exécutable ?

Et Kevin qui répète que GTC est inutile, incapable, et qu'on ne peut pas programmer de choses intéressantes avec...
Si TI-Chess n'est pas un gros projet intéressant...
Si Einstein n'est pas un gros projet intéressant...
Quel sera le prochain ?

Pollux : il faudrait comparer les temps de réflexion de l'IA

Euh j'ai oublié de préciser que le PPG de GCC 3.3 est en -Os pour tout le prog, donc ça explique aussi en partie la différence de taille avec le PPG de la distrib.

Ximoon> ouép Il est aussi conçu de façon à ce qu'un shell par exemple puisse enlever le stub de chargement (qui fait un peu plus d'un ko) et ne le remette qu'au moment de l'envoyer à une autre calc ou à la demande de l'utilisateur.

Thibaut> je pense que GTC va se faire latter parce qu'il n'y a pas l'ASM inline (mais pour que la comparaison de taille soit équitable je l'avais aussi désactivé sur TIGCC).

Je sais qu'il va se faire later. On peut difficilement diminuer autant la taille d'un programme tout en augmentant la vitesse

Ma question était précisément : de combien se fait-il later ? Est-il 2 fois plus lent ? 1,5 fois ? 1,1 ?

C'est idiot de mettre les données compressées dans le même exécutable que le lanceur!
1. Ça fera une double recopie en RAM pour les programmes archivés: une copie compressée et une non-compressée.
2. Ça ne permet pas de dépasser les 24 KO compressés. Le décompresseur ExePack est très pratique parce qu'il sert en même temps de lanceur pour dépasser les 24 KO.
Bref, il y a des raisons pour lesquelles ExePack ne fait pas ça!

Pollux> Ce serait plus intéressant de comparer les tailles non-compressées.
Tu compresses avec quoi, toi ?

bref, les packs archives restent le moyen le plus efficace de gérer les auto-extractibles.

Kevin> N'importe quoi.

1. Ça fera une double recopie en RAM pour les programmes archivés: une copie compressée et une non-compressée.

Absolument pas. Le lanceur s'occupe de ça. C'est d'ailleurs en implémentant ça que je me suis rendu compte du bug avec SET_FILE_IN_USE_BIT.

2. Ça ne permet pas de dépasser les 24 KO compressés. Le décompresseur ExePack est très pratique parce qu'il sert en même temps de lanceur pour dépasser les 24 KO.

Oui, c'est pour ça qu'il y a aussi un lanceur. Et la plupart des progs font moins de 24 ko compressé, donc ça économise le lanceur.

Bref, il y a des raisons pour lesquelles ExePack ne fait pas ça!

... mais elles peuvent être contournées pour la plupart

Tu n'as pas répondu à mon post ./47

Soit moins agressif Kevin !
C'est comme quand on parlait de la conversion HANDLE -> SYM_ENTRY il n'y a pas longtemps, dans Einstein. Tu as tout de suite lancé "quelle merde ta méthode ! Einstein est bogué".
Avant de faire ce genre de remarques, pose des questions pour t'assurer que la pesonne n'a as trouvé moyen de faire bien.
Et quand tu fais une remarque, tu n'as pas à être agressif. Tu es agressif parceque le concurrent t'emmerde, il ténerve... Ne plus être le seul à servir la communauté, le seul maître, ça te déprime, hein

et aussi arrête de dire que tous les programmes sont bogués sans donner d'exemples de bug...

Le lanceur qui décharge sa copie en cours d'exécution, c'est un hack assez sale (qui a été refusé pour ExePack parce qu'il est trop sale, les logiciels de la TICT ayant la réputation d'être programmés proprement). Maintenant, la question probablement plus importante que s'il est propre ou pas est s'il est stable ou pas. Ça, je ne peux pas le dire parce que je n'ai ni les sources pour vérifier, ni les binaires pour tester. (J'ai été objectif là, Monsieur Barthélémy???)

Oui, et c'est dommage que ce soit exceptionnel. Là tu es agréable, très appréciable. On peut discuter calmement et intelligement

Juste une question : pourquoi c'est sale (enfin pourquoi "plus" sale qu'un lanceur et des données compressées à part) ?

Normalement, si on a le lanceur intégré dans le programme, on a le programme en RAM 2 fois:
* une fois compressé dans le twin du lanceur
* une fois décompressé
Ce que font PpHd (packs archive) et Pollux (la compression dont on est en train de parler) pour résoudre ce problème est qu'ils suppriment le twin du lanceur alors qu'il se trouve théoriquement en pleine exécution (en prenant bien sûr, du moins je l'espère, des précautions pour ne jamais exécuter du code dans le twin qu'ils viennent de supprimer). C'est ça qui est sale.

Pollux redimensionne peut-être le twin pour qu'il ne reste que le code du launcher. Comme ça, le handle ne change pas, et le TIOS doit n'y voir que du feu

Kevin: Ce n'est pas très dur de copier le code de décompression dans un handle avant de supprimer le twin, tu sais...

Pollux redimensionne peut-être le twin pour qu'il ne reste que le code du launcher.

Mais as-tu seulement pensé au cas où le programme n'est pas archivé ?

Et bien il ne fait rien
Que ce soit avec ttstart ou la méthode de Pollux, il y a double-copie du programme dans ce cas !