Comment convertir les instructions "move" en hexa ? - Page 3

tails (./52) :
Ah pourtant il y est /etc/bashrc sur mon système ...

Il doit avoir été créé par TIGCC, justement.

bizarre que ça ne fonctionnât pas avant que j'édite auparavant le fichier ~/.bashrc (Ca me laisse perplexe.)

/etc/bashrc n'est pas lu directement par bash, il est lu par le .bashrc par défaut de certaines distributions (Red Hat et dérivées en particulier), mais pas celui de Debian et dérivées. Ça fait partie des différences casse-pieds entre distributions.

Franchement, je te conseille Fedora pour le développement TI, ça te permettrait d'utiliser mon dépôt avec les paquetages binaires de tous les outils tous prêts et c'est aussi la distribution sur laquelle TIGCC est testée.

tails (./56) :
-> le transfert de ti89 à linux (et inversement) : tilp2 ne pouvaut s'installer chez moi sans désinstaller des paquets nécessaires à TIEmu

Il faut que tu utilises des versions qui correspondent, sinon effectivement il va y avoir un conflit avec les libs. Oublie tout de suite les binaires dans le dépôt Ubuntu universe officiel (s'ils existent toujours), ce sont des versions totalement dépassées et il n'y a pas de vrai mainteneur. Tu peux essayer le dépôt Debian de Romain Liévin ou tu peux compiler à partir des sources. Ou enfin tu peux passer à Fedora et utiliser mon dépôt.

Je pense passer à Fedora10. Sinon, la nouvelle version de Fedora (11?) ne devrait pas tarder à sortir, non ?

Je ne suis pas sûr qu'il va vouloir changer de distro juste pour faire un peu de programmation TI-68k

Pour permettre à tails de choisir en meilleure connaissance de cause, tu devrais mentionner, par exemple, que Fedora est une distro beaucoup moins stable qu'Ubuntu 8.04 LTS (qui a 5 ans de support, contre 1 an pour les Fedora), ou que les autres Ubuntu (2 ans de support)
(et accessoirement, Ubuntu 9.04 va bientôt sortir. Avant Fedora 11 pour laquelle il est préférable, comme d'habitude, d'attendre quelques semaines avant de l'installer si on veut disposer tout de suite, dans les dépôts de packages, des corrections des bugs les plus gênants)

A part ça, toi et moi sommes off-topic, Kevin

C'est vrai que sous Ubuntu, tigcc fonctionne au moins sans l'IDE. Je n'ai pas vraiment essayé d'installer TIGCC (j''ai plein de doutes quant à mes capacités à respecter la procédure d'installation); mais sinon je pense pouvoir m'en sortir avec la ligne de commande seule ... donc Ubuntu peut me suffire .

Au fait, est-ce que TILP 1 ou 2 fonctionne avec un cable parallèle fait-maison ? J'ai vu que c'est le moins cheret le plus simple à fabriquer .

Oui, TILP fonctionne avec un câble parallèle fait maison: c'est ce que j'utilise sur mes machines qui ont encore un port parallèle.

Ok merci beaucoup

t1 t'as de la chance tails d'avoir un port // sur ta CM... ^^

tails (./62) :
Je pense passer à Fedora10. Sinon, la nouvelle version de Fedora (11?) ne devrait pas tarder à sortir, non ?

C'est prévu pour le 26 mai. C'est actuellement en bêta.

Lionel Debroux (./63) :
Pour permettre à tails de choisir en meilleure connaissance de cause, tu devrais mentionner, par exemple, que Fedora est une distro beaucoup moins stable qu'Ubuntu 8.04 LTS

Moins stable selon qui? Fedora marche très bien, et nous on a des corrections de bogues en mise à jour.

qui a 5 ans de support

Seulement les paquetages serveur. C'est 3 années pour les paquetages GNOME et comme une release normale pour les paquetages KDE (Kubuntu a été exclue du LTS à cause de la transition KDE 3 - KDE 4).

contre 1 an pour les Fedora

13 mois environ (la durée exacte, c'est 2 releases + 1 mois).

ou que les autres Ubuntu (2 ans de support)

N'est-ce pas 1 année et demie (18 mois) seulement?

et accessoirement, Ubuntu 9.04 va bientôt sortir.

Mais ça ne va résoudre aucun de ses problèmes d'installation de logiciels TI. Il n'y a toujours pas de packageur Ubuntu pour ces logiciels.

Avant Fedora 11

Mais Fedora 10 + mises à jour est plus à jour sous pas mal d'aspects. Par exemple, Ubuntu 9.04 va sortir avec un noyau 2.6.28 (qui ne sera pas mis à jour), Fedora 10 va bientôt avoir le 2.6.29 en mise à jour. (Et au passage, le 2.6.28 est très bogué, au point où c'est le premier noyau depuis pas mal de temps que Fedora a sauté dans les mises à jour! Fedora 10 en est actuellement au 2.6.27.21 et va passer directement au 2.6.29.)

tails (./64) :
C'est vrai que sous Ubuntu, tigcc fonctionne au moins sans l'IDE. Je n'ai pas vraiment essayé d'installer TIGCC (j''ai plein de doutes quant à mes capacités à respecter la procédure d'installation)

(Je suppose que tu veux dire KTIGCC là, pas TIGCC.)

C'est pourtant très simple de compiler KTIGCC:
qmake
make
sudo make install

Il suffit d'avoir les dépendances qu'il faut installées, tous les paquetages -dev qu'il te faut sont listés.

Je déconseille fortement l'utilisation de la ligne de commande. La raison nº1, c'est que la ligne de commande ne peut pas savoir si un projet est nouveau ou non et qu'il faut donc utiliser un grand nombre de switches pour avoir le comportement conseillé pour tout nouveau projet. Le minimum (sauf cas particuliers dans lesquels il peut être utile de supprimer ou remplacer l'un ou l'autre switch):
-Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -Wall -Wextra -Wwrite-strings
KTIGCC te met tout ça tout seul pour les nouveaux projets. Il y a aussi d'autres raisons pour utiliser KTIGCC: envoi à TiEmu en un clic, complétion des fonctions de TIGCCLIB etc. (Je ne cesse de lister ces fonctionnalités, je suis sûr que tu vas retrouver des listes plus ou moins complètes en faisant une recherche dans ce forum.)

La ligne de commande de TIGCC est à considérer comme obsolète, tous les nouveaux projets sont censés utiliser KTIGCC ou TIGCC IDE. (Et ces EDIs sont compatibles l'un avec l'autre, c'est fait exprès pour avoir des projets portables.)

Ce n'est pas vraiment que KTIGCC est compliqué à installer ,c'est qu'au niveau des paquets je ne les trouve pas tous ou sinon sous desnoms différents
-> par exemple Synaptic ne trouve pas dbus-qt3

Kevin Kofler (./68) :
Je déconseille fortement l'utilisation de la ligne de commande. La raison nº1, c'est que la ligne de commande ne peut pas savoir si un projet est nouveau ou non et qu'il faut donc utiliser un grand nombre de switches pour avoir le comportement conseillé pour tout nouveau projet. Le minimum (sauf cas particuliers dans lesquels il peut être utile de supprimer ou remplacer l'un ou l'autre switch):
-Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -Wall -Wextra -Wwrite-strings
KTIGCC te met tout ça tout seul pour les nouveaux projets. Il y a aussi d'autres raisons pour utiliser KTIGCC: envoi à TiEmu en un clic, complétion des fonctions de TIGCCLIB etc. (Je ne cesse de lister ces fonctionnalités, je suis sûr que tu vas retrouver des listes plus ou moins complètes en faisant une recherche dans ce forum.)

Faut arrêter, les scripts d'assemblage sont très simples à écrire, et les switches que tu donnes, on s'en passe très bien si l'on sait ce qu'on écrit. Ce sont pas les exemples (par exemple dans mes programmes) qui manquent. De plus, (K)TIGCC est très rigide et peu paramétrable au niveau compilation, et on petu pas vraiment faire ce qu'on veut dès qu'on veut sortir ne serait-ce qu'un Hello World un peu personnalisé. C'est pas un reproche, mais faut simplement arrêter de dire "l'IDE c'est parfait, la ligne de commandes aux chiottes". C'est faux.

(Kevin)

(Je ne cesse de lister ces fonctionnalités, je suis sûr que tu vas retrouver des listes plus ou moins complètes en faisant une recherche dans ce forum.)

Je pense aussi qu'une recherche dans ce forum lui donnera aussi les arguments contre l'utilisation du système de build très limité que sont les TPR (que ce soit dans TIGCC IDE, KTIGCC ou tprbuilder), ou sur le fait que les IDE de TIGCC ont des comportements contraires à ceux de nombre d'autres IDE, qu'on ne cesse nous aussi de lister


Les choses ne sont quasiment jamais toutes noires ou toutes blanches. Ca fait des années que diverses personnes te font la remarque, mais toi, tu continues à ne donner que rarement les DEUX visions des choses (la tienne, ET les arguments contraires), ce qui prive les utilisateurs d'éléments de décision.
Il serait d'autant plus nécessaire que tu donnes les DEUX visions des choses, que ta vision des choses est souvent loin de faire l'unanimité (voir, entre bien d'autres, ta vision du logiciel à topics/2-120352-lopen-source-une-utopie ), voire que tu racontes carrément des conneries, parce que tu ne mets pas de nuances:

Fedora marche très bien

Ecrit comme ça, c'est faux. Voir les reviews à la sortie de Fedora 9, très majoritairement négatives à cause de ce foutu KDE 4.x feature-incomplete et buggé.
Il serait acceptable que tu écrives des choses du genre "Fedora marche très bien pour moi, qui suis un utilisateur de longue date de Linux (= capable de contourner et corriger des problèmes), et aussi un développeur de Fedora (donc je risque d'être biaisé)". Sinon, tu écris quelque chose qui n'est ni vrai en général, ni honnête


(tails)

par exemple Synaptic ne trouve pas dbus-qt3

Quand c'est comme ça, je te conseille de faire une recherche par mots clés sur packages.ubuntu.com
Ici: http://packages.ubuntu.com/search?suite=hardy&arch=any&searchon=names&keywords=dbus%20qt
-> "libdbus-qt-1-dev", vraisemblablement.

Oui je conaissais le site package.ubuntu.com; j'avais tellement pris l'habitude de faire des recherches fructueuses sur Synaptic que je l'avais oublié .
Merci

tails (./69) :
Ce n'est pas vraiment que KTIGCC est compliqué à installer ,c'est qu'au niveau des paquets je ne les trouve pas tous ou sinon sous desnoms différents-> par exemple Synaptic ne trouve pas dbus-qt3

Et bah, n'utilise pas le patch dbus alors.

Lis le readme des patches, ils ne sont pas à appliquer bêtement, c'est bien pour ça qu'ils sont publiés séparément et pas appliqués par défaut. Il y a écrit noir sur blanc en gras dans la news qui annonce la release: "Please read the description of each patch carefully before applying them!" Si tu ne comprends pas ce qu'ils font, n'utilise pas les patches.

Folco (./70) :
Faut arrêter, les scripts d'assemblage sont très simples à écrire, et les switches que tu donnes, on s'en passe très bien si l'on sait ce qu'on écrit.

1. Pas en C (pas tout le monde se limite à l'assembleur comme toi!) et
2. pas dès qu'on a plus d'une unité de compilation.
Et tu le sais très bien.

De plus, (K)TIGCC est très rigide et peu paramétrable au niveau compilation, et on petu pas vraiment faire ce qu'on veut dès qu'on veut sortir ne serait-ce qu'un Hello World un peu personnalisé.

N'importe quoi. Maintenant, si ton "Hello World un peu personnalisé" comporte 3 libs, un lanceur personnalisé qui lance le programme en FlashROM sous PedroM et je ne sais pas quoi encore, peut-être, mais à ce moment-là ce n'est pas à KTIGCC qu'il faut se prendre. (Indice: Tout ce bordel n'est pas et ne sera jamais supporté par TIGCC (tout TIGCC, pas seulement les EDIs). Il est de toute façon absolument inutile. Le modèle d'exécution visé par TIGCC est un programme _nostub, au choix avec ou sans compression pucrunch (et le lanceur autogénéré qui va avec). Le kernel est supporté pour pouvoir compiler les vieilles sources, mais fortement déconseillé pour les nouveaux programmes. Tout le reste n'est pas supporté.)

C'est pas un reproche, mais faut simplement arrêter de dire "l'IDE c'est parfait, la ligne de commandes aux chiottes". C'est faux.

Non, dans TIGCC c'est vrai, et la ligne de commande n'existe que pour les vieux projets qui l'utilisent (genre ceux développés sur *nix quand KTIGCC n'existait pas encore).

Lionel Debroux (./71) :
Je pense aussi qu'une recherche dans ce forum lui donnera aussi les arguments contre l'utilisation du système de build très limité que sont les TPR (que ce soit dans TIGCC IDE, KTIGCC ou tprbuilder)

Il se limite à ce dont on a réellement besoin pour un projet pour calculatrice. Mais il est aussi très puissant (genre dossiers virtuels etc.).

ou sur le fait que les IDE de TIGCC ont des comportements contraires à ceux de nombre d'autres IDE, qu'on ne cesse nous aussi de lister

Moi aussi je les liste, dans ma liste des raisons pour lesquelles il faut les utiliser. Ce sont des fonctionnalités volontaires, ils font la puissance des EDIs.

[snip sur les attaques personnelles qui n'ont rien à voir avec le sujet du topic]

Fedora marche très bien

Ecrit comme ça, c'est faux. Voir les reviews à la sortie de Fedora 9, très majoritairement négatives à cause de ce foutu KDE 4.x feature-incomplete et buggé.

Pourtant j'ai installé Fedora 9 sur mon PC portable (depuis le live CD, donc à l'origine sans mises à jour) et ça marchait tout à fait. Ensuite j'ai mis les mises à jour de l'époque (c'était toujours un KDE 4.0.x, c'était peu après la sortie de Fedora 9) et le résultat était parfaitement utilisable.

Et au fait, j'écris ce message depuis Fedora 9 (avec les mises à jour, donc KDE 4.2.1, une mise à jour avec Qt 4.5 et KDE 4.2.2 est actuellement en phase de test), ça marche parfaitement comme OS de tous les jours.

De plus, (K)TIGCC est très rigide et peu paramétrable au niveau compilation, et on petu pas vraiment faire ce qu'on veut dès qu'on veut sortir ne serait-ce qu'un Hello World un peu personnalisé.

N'importe quoi.

Et allez hop, Kevin poste encore une fois les mêmes conneries sur lesquelles on a déjà discuté de trop nombreuses fois...

Rapidement: ceux des softs de TICT qui ont été passés en TPR, l'ont été parce que je n'avais pas encore compris pourquoi d'autres (PpHd et al.) n'étaient pas contents de ce système de build. C'est le cas de TI-Minesweeper et TICT-Explorer, par exemple.
Une fois que j'avais fait la conversion, ça n'avait pas beaucoup de sens de repasser à autre chose...
En revanche, pour d'autres programmes plus complexes, pas de conversion en TPR:

maintenant, si ton "Hello World un peu personnalisé" comporte [...]

Non, juste (par exemple, il n'y a pas que celui-ci) des fichiers compilés avec des options d'optimisation différentes (-Os vs -O2/-O3). Cas d'utilisation réel des programmes qui ont besoin de calcul un peu plus rapide, tout en limitant la taille de l'interface graphique. Entre autres, TI-Chess, "juste" le programme TI-68k le plus téléchargé sur ticalc.org. Faire ça avec des TPR est du brain damage (3 TPRs pour linker le tout ensemble).
ExtGraph a un système de build hybride, parce que là aussi, il y a des fichiers qu'il faut absolument compiler avec des options d'optimisation différentes (-fno-omit-frame-pointer, par exemple).

Mais il est aussi très puissant (genre dossiers virtuels etc.).

C'est une anti-feature, ça, puisque nombre de systèmes de build plus réalistes que tails utilisera peut-être un jour, s'il fait de l'informatique son métier, ne font pas comme ça...
La capacité de builder des sources non sauvegardés est une autre anti-feature, pour la même raison.

[snip sur les attaques personnelles qui n'ont rien à voir avec le sujet du topic]

Mais qui aideront tails, assez nouveau venu, à comprendre les relations dans la communauté

Lionel Debroux (./74) :
Non, juste (par exemple, il n'y a pas que celui-ci) des fichiers compilés avec des options d'optimisation différentes (-Os vs -O2/-O3).

1. On peut très bien s'en passer et tout compiler avec -Os.
2. La bonne solution dans ce cas est de mettre à jour le patch TIGCC vers GCC 4.4, ça permettrait de contrôler les paramètres d'optimisation à l'aide d'un pragma, plus besoin de bidouiller les switches de compilation.

Cas d'utilisation réel des programmes qui ont besoin de calcul un peu plus rapide, tout en limitant la taille de l'interface graphique. Entre autres, TI-Chess, "juste" le programme TI-68k le plus téléchargé sur ticalc.org.

TI-Chess fonctionne très bien s'il est entièrement compilé avec -Os. (Je l'ai fait régulièrement pour mesurer l'évolution de la consommation de place entre les différentes versions de GCC.)

3 TPRs pour linker le tout ensemble

Effectivement, c'est du bidouillage absurde, la bonne solution est d'utiliser -Os partout, en attendant GCC 4.4.

C'est une anti-feature, ça, puisque nombre de systèmes de build plus réalistes que tails utilisera peut-être un jour, s'il fait de l'informatique son métier, ne font pas comme ça...La capacité de builder des sources non sauvegardés est une autre anti-feature, pour la même raison.

Moi, je trouve ces fonctionnalités très utiles et puissantes.

Mais qui aideront tails, assez nouveau venu, à comprendre les relations dans la communauté

=> C'est de l'argumentation ad hominem. => C'est malhonnête et contourne les vrais points sous discussion.

Ah oui d'accord : dbus est un patch ...
Bon je l'avoue, je ne sais pas ce qu'est un patch (et ce n'est pas assez explicite même dans une interface graphique telle que Synaptic) .

Par exemple pour le paquet libdbus-qt-1-dev, la description est la suivante :

simple interprocess messaging system (Qt interface)
D-BUS is a message bus, used for sending messages between applications.
Conceptually, it fits somewhere in between raw sockets and CORBA in
terms of complexity.

This package provides a Qt-style interface to D-BUS.

Oui je sais c'est une honte de pas connaître un patch pour quelqu'un qui doit s'intéresser à la programmation. Mais il se trouve que je ne sais pas .

1. On peut très bien s'en passer et tout compiler avec -Os.

la bonne solution est d'utiliser -Os partout,

C'est TON avis, qui ne fait pas du tout l'unanimité, mais que tu présentes ENCORE sans nuances comme "la bonne solution"...

2. La bonne solution dans ce cas est de mettre à jour le patch TIGCC vers GCC 4.4, ça permettrait de contrôler les paramètres d'optimisation à l'aide d'un pragma, plus besoin de bidouiller les switches de compilation.

En 2009, la solution ne paraît pas idiote. Même si je ne suis pas sûr qu'elle suffirait pour ExtGraph (qui a des différences de switches autres que -Os/-O2/-O3), je devrais RTM pour le savoir.
Mais c'est facile de dire ça maintenant: en 2003-2005, quand les dernières releases de la plupart des programmes de TICT ont été faites, cette solution n'était pas sur la table...

C'est malhonnête

L'hôpital qui se moque de la charité... Qui a fait, comme à son habitude, une présentation biaisée des choses (./61) et déclenché tout ce off-topic (parce qu'il faut bien donner aux gens une autre vision des choses que la tienne pour leur permettre de choisir... j'ai l'impression de me répéter...).


Bon, allez, assez montré à tails, à travers une enième resucée de la même discussion, les visions différentes des choses qu'il y a entre certain et les autres,.

En fait, non, dbus n'est pas un patch: c'est une infrastructure pour passer des messages entre les applications.
Mais il doit falloir un patch à KTIGCC pour activer ou désactiver le support D-Bus (j'aurais dit qu'il fallait passer quelque chose comme --disable-dbus ou --enable-dbus à ./configure, mais ça fait longtemps que je n'ai pas essayé de compiler ce truc que je n'utilise presque pas).


[EDIT: OK, j'ai trouvé un patch D-Bus dans le ktigcc-patches-1.10.tar.bz2 accessible à http://sourceforge.net/project/showfiles.php?group_id=31034&package_id=195050
tails, je suis à peu près sûr que tu n'as pas besoin d'appliquer des choses qui sont dans ces patches

Poste-nous ce que ça fait quand tu essaies de compiler ktigcc
(déjà, à partir de quoi le compiles-tu ? Le ktigcc-1.10.tar.bz2 qu'on trouve dans le lien que je viens juste de donner ?]

Bon, on dira que je pourrais déjà m'en sortir avec la ligne de commande . Visiblement installer KTIGCC sous Ubuntu me demande des connaissances et compétences que je n'ai pas encore .

tails (./76) :
Ah oui d'accord : dbus est un patch ...

Non, la modification qui fait utiliser D-Bus à la place de DCOP à KTIGCC est un patch. Tu n'as pas besoin de libdbus-qt-1-dev pour la release officielle de KTIGCC.

Oui je sais c'est une honte de pas connaître un patch pour quelqu'un qui doit s'intéresser à la programmation. Mais il se trouve que je ne sais pas .

Un patch est une modification à un logiciel, tout simplement.

Les patches les plus courants dans le domaine du logiciel libre sont les diffs de code source. Ils se créent avec l'outil diff et s'appliquent avec l'outil patch.

Lionel Debroux (./77) :
Mais c'est facile de dire ça maintenant: en 2003-2005, quand les dernières releases de la plupart des programmes de TICT ont été faites, cette solution n'était pas sur la table...

Ça fait pas mal de temps que cette fonctionnalité était sur la table dans le cercle des développeurs de GCC.

Lionel Debroux (./78) :
Mais il doit falloir un patch à KTIGCC pour activer ou désactiver le support D-Bus (j'aurais dit qu'il fallait passer quelque chose comme --disable-dbus ou --enable-dbus à ./configure, mais ça fait longtemps que je n'ai pas essayé de compiler ce truc que je n'utilise presque pas).

Normalement, KTIGCC 1 utilise DCOP pour communiquer avec TiEmu, le patch permet d'utiliser D-Bus à la place, ce qui permet de compiler TiEmu sans le support KDE 3 (ou avec KDE 4, mais je n'ai pas encore implémenté ça dans TiEmu), et donc aussi d'éviter que ça foire si on utilise le gtk-qt-engine Qt 4. En revanche, il faut compiler TiEmu avec --enable-dbus, ce n'est pas encore le réglage par défaut dans la release actuelle de TiEmu (je vais peut-être changer ça dans le SVN).

Mais je conseille à tails de compiler KTIGCC sans ce patch, et donc il n'a pas besoin de libdbus-qt-1-dev.

tails (./79) :
Visiblement installer KTIGCC sous Ubuntu me demande des connaissances et compétences que je n'ai pas encore .

Bah non, il suffit de lire les instructions.

Comme déjà dit, ignore complètement ktigcc-patches-1.10.tar.bz2, tu as besoin seulement de ktigcc-1.10.tar.bz2.

Kevin Kofler (./73) :
1. Pas en C (pas tout le monde se limite à l'assembleur comme toi!) et

Pardon ?

Kevin Kofler (./73) :
2. pas dès qu'on a plus d'une unité de compilation.

Que veux-tu dire ??

Kevin Kofler (./73) :
Et tu le sais très bien.

Non ! Je pense ce que j'écris, merci de le croire.

Kevin Kofler (./73) :
N'importe quoi. Maintenant, si ton "Hello World un peu personnalisé" comporte 3 libs, un lanceur personnalisé qui lance le programme en FlashROM sous PedroM et je ne sais pas quoi encore, peut-être, mais à ce moment-là ce n'est pas à KTIGCC qu'il faut se prendre. (Indice: Tout ce bordel n'est pas et ne sera jamais supporté par TIGCC (tout TIGCC, pas seulement les EDIs). Il est de toute façon absolument inutile. Le modèle d'exécution visé par TIGCC est un programme _nostub, au choix avec ou sans compression pucrunch (et le lanceur autogénéré qui va avec). Le kernel est supporté pour pouvoir compiler les vieilles sources, mais fortement déconseillé pour les nouveaux programmes. Tout le reste n'est pas supporté.)

Tu illustre parfaitement ici que TIGCC ne correspond pas pleinement aux attentes des utilisateurs, et que tu t'en fous...

Kevin Kofler (./73) :
Il se limite à ce dont on a réellement besoin pour un projet pour calculatrice. Mais il est aussi très puissant (genre dossiers virtuels etc.).

Mes kooyes Compare les featuers d'éditions de Kate par exemple, avec celles de (K)TIGCC ! On peut pas dire que ton IDE croule sous les features, malgré les requests depuis un paquet d'années !

Voici des instructions étape par étape si vraiment tu n'arrives pas à trouver tout seul:

sudo bash
echo 'deb http://repo.calcforge.org/debian/i386 stable main non-free' >>/etc/apt/sources.list
apt-get update
apt-get install libglib2.0-dev libqt3-mt-dev kdelibs4-dev qt3-assistant pkg-config exuberant-ctags libticables2-1-dev libticalcs2-7-dev libticonv3-dev libtifiles2-5-dev
exit 0
qmake
make
sudo make install
wget http://switch.dl.sourceforge.net/sourceforge/tigcc-linux/ktigcc-completion-data-0.96b08r1-1.tar.bz2
export KTIGCC_SRCDIR=`pwd`
cd `kde-config --expandvars --install data`/ktigcc/
sudo tar xjf $KTIGCC_SRCDIR/ktigcc-completion-data-0.96b08r1-1.tar.bz2
cd $KTIGCC_SRCDIR

(Oui, kdelibs4-dev, c'est KDE 3 , cherche pas à comprendre. Et il n'y a pas de kdebase de KDE 3 dans Intrepid, donc tu ne pourras pas configurer les réglages de proxy pour la récupération des news, mais je pense que tu pourras te passer de cette fonctionnalité. Si vraiment tu en as besoin, tu peux installer kcontrol3 depuis https://launchpad.net/~vaidasn/+archive/ppa/, il y a sans doute aussi le module de configuration proxy là-dedans, mais normalement tu t'en sortiras très bien sans.)

je vais essayer merci

Folco (./82) :
Pardon ?

Ton premier et dernier programme en C?
En tout cas, tu as compris ce que je veux dire.

Kevin Kofler (./73) :
2. pas dès qu'on a plus d'une unité de compilation.

Que veux-tu dire ??

Plusieurs fichiers .c, .s ou .asm. (Et pas inclus l'un dans l'autre avec #include , évidemment. ) L'optimisation linker est indispensable pour les programmes modulaires, sinon on se retrouve avec des relogements inutiles. Elle a été conçue pour ça.

Kevin Kofler (./73) :
Et tu le sais très bien.

Non ! Je pense ce que j'écris, merci de le croire.

Dans ce cas, merci d'avoir bien suivi dans toutes les discussions passées qu'on a eues à ce sujet.

Mes kooyes Compare les featuers d'éditions de Kate par exemple, avec celles de (K)TIGCC !

Kate n'est même pas un EDI, c'est un éditeur de texte. Elle est excellente comme éditeur de textes, mais elle ne propose pratiquement aucune fonctionnalité de type EDI.

Juste un petit problème :

prompt$ cd `kde-config --expandvars --install data`/ktigcc/
bash: cd: /usr/share/apps/ktigcc/: Aucun fichier ou dossier de ce type

J'ai recherché tigcc dans le systeme de fichier
-> les docs sont dans /usr/local/share/doc/tigcc
-> l'éxécutable dans /proc/6177/cwd
-> l'icône dans /proc/6177/cwd/images

...
J'ai du faire une fausse manipulation ou c'est l'organisation de Ubuntu qui diffère de Debian .
Sympa l'interface ... il ne me manque plus que l'auto-complétion à définir dans le bon dossier .

Oups... Faut le créer d'abord ce dossier, par exemple avec un:
sudo mkdir -p `kde-config --expandvars --install data`/ktigcc

Nickel Merci beaucoup
Par contre je l'ai installé dans un repertoire ~/tmp => il faut juste que je pense à ne pas supprimer ledit dossier

Folco (./67) :
t1 t'as de la chance tails d'avoir un port // sur ta CM... ^^

Excuses je n'avais pas lu ton message .
Les nouvelles Unités Centrales n'ont plus de port // ?

Ça fait quelques années que ces ports ont quasiment disparu, oui.