)
PpHd (./32) :
Et au prochain GC d'AMS les programmes foirent totalement...
PpHd (./32) :
C'est pas si simple, sinon ca aurait été déjà fait.
)PpHd (./23) :
Trouve moi plutôt un bug dans preos et je fais une release
34-kernel::LibsCall(LIB_DESCRIPTOR l, WORD function, ...) (Preos only) The parameters are pushed on the stack. It will call the function without modifying the registers, and it will pop its argument during the call (LIB_DESCRIPTOR, function, and version).
Folco (./37) :PpHd (./32) :
Et au prochain GC d'AMS les programmes foirent totalement...
Oublié de préciser qu'il faut déreloger le programme en RAM à la fin. Il n'y a pas un flag in use en archive, qui permet de passer à travers le garbage ? Au pire, tu peux faire ça pour PedroM, vu que de toute façon ça ne fonctionnera jamais sous AMS. Et là c'est parfait.PpHd (./32) :
C'est pas si simple, sinon ca aurait été déjà fait.
Ca a déjà été pensé ? Ras le bol d'être à la ramasse :/
squalyl -> on parle de quelques centaines de fois pour un uitlisateur très acharné contre des centaines de milliers de fois possibles (le top étant d'implémenter un cache pour ne pas avoir à re-reloger)
Godzil (./47) :
La memoire flahs utilisé dans les TI 68k est de la NOR, il faut compter quelques milliers d'effacement, pas bien plus. Pas des centaines de milliers ça c'est sur.
squalyl (./48) :
kevin: va faire un patch et fous nous la paix, merci.
)
Kevin Kofler (./187) :
=> Bug Report à travers le formulaire, mail à Sebastian, ou ce que tu veux, mais ce forum n'est pas le bon endroit pour les bug reports de l'IDE, je dois le répéter combien de fois pour que vous le comprenez? Dès maintenant, tout bug report posté ici sera ignoré avec un commentaire "Merci de passer par le formulaire." ((C) yAro).
.Kevin Kofler (./509) :Martial Demolins (./509) :
Le problème, c'est que j'ai jamais vu un seul bug corrigé sur les reports de bugs que j'ai faits...
Wine, KDE, GRUB, dmc (ou plutôt dnc, c'est communautaire) à chaque fois. (et j'ai fait vérifier les bugs par d'autres, via IRC, systématiquement)Ca sert à quoi leurs pages de reports ?
Bah, on ne peut pas corriger tous les bogues du jour au lendemain. Mais ce n'est pas râler sur les forums qui fera qu'ils seront corrigés plus vite (au contraire, personnellement, ça me donne envie de faire exprès de ne pas les corriger en temps utile, parce que cette manière de "reporter" les bogues m'agace).
Il faut que tu comprennes les développeurs:
* Pour toi, ton bogue est le plus important de tous, mais pour nous, c'est un des nombreux bogues qui nous sont reportés et l'arrogance de certains utilisateurs de demander un traîtement préférentiel pour leurs bogues nous agace.
* Un développeur ne veut pas lire que son logiciel est pourri, bogué etc. sur un forum, surtout si on ne lui a jamais signalé ces problèmes auparavant (donc on ne lui a donné aucune chance de les corriger).
* Un développeur a besoin de détails pour reproduire et corriger les bogues, donc une phrase comme "le logiciel XYZ est bogué" ou "le logiciel XYZ ne marche pas" (à chaque fois que je lis "marche pas" sur un forum, j'ai envie de frapper quelqu'un!) ou une capture d'écran qui montre le résultat d'un bogue et non pas comment y parvenir ne servent à rien si ce n'est à chauffer les âmes.
* Nous ne pouvons pas aller chercher nos bogues sur tous les forums du monde, il faut que vous nous signalez les bogues (donc utilisez nos formulaires), ce n'est pas à nous d'aller parcourir le web en quête de bug reports! Nous avons autre chose à faire aussi! De plus, les formulaires sont souvent (pas toujours, cf. TIGCC) reliés à un bug tracker qui nous permet de ne pas oublier les bogues et de voir ce qui est corrigé et ce qui reste à faire. Contourner ce tracker est la manière la plus efficace d'assurer que ton bogue sera oublié.
* Un développeur ne peut pas corriger des bogues 24/7, et même s'il pouvait, ça ne suffirait souvent pas pour corriger tous les bogues.
