yAroTweet (ou le topic des pensées à la con) - Page 38

fine oie ?

/\

joli

./1102 excellent, pourquoi personne n'y a pensé dans ma promo

la MécaQ, c'était amusant, puis , puis carrément #fffffuuuuu avec tous leurs opérateurs couplés, observables et autres merdouilles

Voilà

Ce soir, je me balladais sur le blog de Zerosquare, et j'y ai vu... rien de neuf

Folco, toujours aussi subtil

Pour la mise à jour du blog ça va malheureusement pas être maintenant, boulot + todolist trop longue...

eh oui ça prend du temps de blogger correctement

Zerosquare (./1117) :
Folco, toujours aussi subtil

Oh mince ! Tu sais, je pensais vraiment pas que tu lirais ce post, hein

Pourquoi Casio c'est de la merde ? une preuve en image : http://9gag.com/gag/amX2jDo

Et ? La TI-89 fait pareil, c'est normal si tu es en mode exact.

C'est quoi le problème ? (cross)

Qui a eu l'idée géniale de mettre TiEmu-nogdb dans les dépôts de Debian testing ? C'est le pied total !

Lionel, ton script ne fonctionne plus pour compiler, les svn des libti* ont changé, et je les trouve pas sur ton github, donc j'ai pas pu corriger le script...

Enfin, grâce aux paquets, ça va tout seul maintenant.

J'ai pensé à un truc hier : en fait, d'après la Bible, Ève est un fork d'Adam

Effectivement.

Le Root a mis le process Adam en sleep et l'a forké.

De plus, ils sont capables de se merger pour créer un nouveau thread. Quelle belle machine !

N'est-ce pas ?

Eve a même une interface graphique plutôt jolie, malheureusement elle est mal documentée.

Folco (./1126) :
De plus, ils sont capables de se merger pour créer un nouveau thread. Quelle belle machine !

Sauf que ça prends 9 mois et que pendant ce temps, le processus mère ralenti.

(gnnnn... résister à l'envie de réécrire des bouts de la Bible à la sauce Unix... résister...)

Zerosquare (./1127) :
Eve a même une interface graphique plutôt jolie, malheureusement elle est mal documentée.

Il ne faut pas hésiter à faire un Eve --help. Elle se fait une joie d'expliquer son fonctionnement afin d'être utilisée toujours mieux.

Ça semble ne pas être implémenté sur toutes les versions, malheureusement

Faut pas oublié que les deux processus ont été sandboxés (et tous leurs fils avec) parce que le processus Eve a corrompu le /home...

Ah oui, l'option fonctionne de manière un peu déconcertainte au premier abord. D'abord peu loquace et très généraliste, elle peut progressivement devenir beaucoup plus verbeuse au fur et à mesure des appels. L'essentiel est de ne pas hésiter à utiliser autant de fois l'option que nécessaire, en se disant qu'on aura toujours un tip ou un autre à apprendre.

(cross -> c'est plutôt les process originaux qui étaient sandboxés dans un paradis unixien, non ? )

Polom polom.

@Folco

Effectivement, on peut le voir comme ça.

Folco (./1123) :
Qui a eu l'idée géniale de mettre TiEmu-nogdb dans les dépôts de Debian testing ? C'est le pied total !

C'est totalement pourri, ils te fournissent un TiEmu castré qui n'a même pas la fonctionnalité la plus importante! De plus, ils n'activent ni DCOP (kdelibs3), ni D-Bus, donc ce TiEmu ne peut pas être utilisé avec KTIGCC, même pour tester. Bref, ce paquetage est totalement inutilisable et inutile.

OBO (./1128) :

Folco (./1126) :
De plus, ils sont capables de se merger pour créer un nouveau thread. Quelle belle machine !

Sauf que ça prends 9 mois et que pendant ce temps, le processus mère ralenti.

Chez les ordinateurs, le fsck se passe après une période de downtime, chez les humains, c'est l'inverse.

Kevin Kofler (./1136) :
Bref, ce paquetage est totalement inutilisable et inutile

Pour toi peut être, mais pour celui qui veut juste se servir de la calculette, c'est suffisant, utilisable et utile...

Tous les possesseurs de Ti ne sont pas des développeurs. Et tous les développeurs n'utilisent pas forcément KTIGCC

Kevin Kofler (./1136) :
C'est totalement pourri, ils te fournissent un TiEmu castré qui n'a même pas la fonctionnalité la plus importante! De plus, ils n'activent ni DCOP (kdelibs3), ni D-Bus, donc ce TiEmu ne peut pas être utilisé avec KTIGCC, même pour tester. Bref, ce paquetage est totalement inutilisable et inutile.

Sur TI, je code en 68k pur, donc GDB ne m'est d'aucune utilité. Je ne dis pas que c'est inutile pour les codeurs en C. Je dis que c'est inutile pour moi.

Question D-Bus, je t'ai reporté X fois, au fur et à mesure des versions de Fedora, un problème avec D-Bus qui empêchait le transfert vers l'émulateur. Bien que t'aies cherché, tu n'as pas trouvé (probablement par ma faute, données de configuration que je ne t'ai pas données, ou matériel exotique et improbable, bref je ne te l'impute pas). Mais au final, je me fous de cette fonctionnalité.



Surtout que (K)TIGCC (IDE) est vraiment très mal foutu pour faire de l'assembleur.
Une raison simple : dans mes projets, j'ai un fichier asm, parfois avec un peu de code, maiq qui inclut les différents sources, parce que je sais dans quel ordre je veux que mon code soit assemblé (c'est de l'assembleur, il est légitime de matriser chaque octet du binaire final de bout en bout). (K)TIGCC (IDE) ne permet pas d'avoir des sources non compilées dans un projet, donc l'IDE perd intégralement son intérêt. Retour à Kate, un script de compilation, et une copie des binaires expédiée par magie dans le répertoire de transfert par défaut de TiEmu (ou de VTI, mais Wine déconne désormais avec VTI). Bref, exit D-Bus.

Tu déplaces les .asm que tu veux inclure à la place de les assembler séparément dans "Header Files", cette fonctionnalité a été rajoutée exprès pour les utilisateurs comme toi.

Sinon, la manière propre de faire les choses est d'avoir, oui, plusieurs fichiers .asm, mais de les assembler séparément et de laisser le linker faire son travail. Mais TIGCC IDE / KTIGCC ne t'obligent pas à fonctionner comme ça.

Folco (./1139) :
Sur TI, je code en 68k pur, donc GDB ne m'est d'aucune utilité. Je ne dis pas que c'est inutile pour les codeurs en C. Je dis que c'est inutile pour moi.

j'allais dire que gdb fait aussi l'asm. mais en fait l'ému le fait déja par lui même ^^