Toujours plus loin dans les bugs stranges - Page 2

Bon courage pour ton déménagement !

Merci ! Au fait, même kompare ne comprends pas le patch tel que tu l'as posté, et je ne comprends pas pourquoi. Je l'appliquerai à la main. Peut-être que je m'y prends très mal. Kevin, tu pourrais regarder ce que ça fait chez toi stp ? Merci d'avance.

Le problème, c'est que les pre ne conservent pas l'espace blanc, notamment les tabs.

./28: comme tu le sais, je suis actuellement en train de modifier pstarter et ttstart, en vue de l'unification. Tu veux que je fasse la suppression de shrnklib au passage ?

Tu fais ce que tu veux avec ton fork, je fais ce que je veux avec le mien.

Si tu veux travailler avec moi, tu sais où ça se passe.

toujours plus loin dans la diplonazie

KEVINOU, BISOU \o/

Tu t'exprimes mal, Kevin. Il serait plus conforme à la réalité d'écrire

Vous faites ce que vous voulez avec votre fork, je fais ce que je veux avec le mien.

Si je crée un topic sur TIGCC Programming, tu seras content ?
(ni #tigcc ni les mails privés ne sont publiquement accessibles et traçables, et TIGCC ne dispose ni de ML, ni de bug / feature request tracker, ni de Wiki)

ah oui pas mal le facepalm aussi

A noter, pour ceux qui ne connaissent pas pstarter, que ça prend presque moins de temps de faire le changement que de répondre dans ce topic (et puis c'est plus utile de faire le changement que de répondre une stupidité comme ./35).
En effet, pstarter est fait pour être modulaire, de telle sorte que supprimer un des décompresseurs consiste en la suppression (pour ceux qui utilisent un vrai SCM) ou le déplacement vers l'attic (pour ceux qui utilisent CVS) du .h correspondant (ici, pst-shrn.h) et en un three-liner dans pstarter.s:

@@ -40,13 +40,10 @@
 .include "pst-ttup.h"
 .endif
 .ifdef ttunpack_fast
 .include "pst-ttuf.h"
 .endif
-.ifdef shrink92
-.include "pst-shrn.h"
-.endif
 
 .xdef _ti89
 .xdef _ti92plus
 .xdef _v200
 .xdef _ti89ti

Kevinou, je peux poster cette trivialité sur le forum de TIGCC (ça lui ferait un peu d'activité...) - mais est-ce bien utile, d'autant plus que des choses postées il y a six mois n'ont pas été traitées ?

merci d'avoir contribué à notre fork

Bon, un des derniers posts aavnt 3 semaines de black-out (je fais ça pour emmerder albanel ), j'aimerais savoir si le bug décrit ici ne viendrait pas du compresseur/archiveur sur PC, étant donné que c'est le nombre lu dans l'archive par shrnklib est mauvais. Ca pourrait être ça ? Il vaudrait mieux alors chercher dans le code C PC plutôt que de rester sur ce wrapper ? PpHd ?
Je compte mettre ces semaines à profit de ce côté-là, si l'emménagement m'en laisse le temps.

Merci d'avance.

(rsvp avant samedi matin 6 h ^^)

bon courage pour ton [dé|em]ménagement

Merci

Euh merde... le ./6 n'est pas en contradiction avec le ./41 des fois ? Que vient faire shrinklib dans un programme appelant une dll au fait ?!?

Bon courage

Suite à Martial qui ne m'a toujours pas laché (ca ne plantait plus mais ca marchait toujours pas), je me suis remis dedans et j'ai trouvé le problème.
Bug de PreOS dans kernel::ExtractFromPack. Release corrective ASAP.

puissant encore une fois

(et je te jure que je t'apporterai tous les bugs de PreOs à force de te le torturer)

PreOS 1.0.7 est sorti: www.yaronet.com/t3
avec le fix.

Merci, super !