ktigcc - Page 1

bonsoir,

j'essaie d'installer ktigcc sous linux ubuntu
mais quand je lance ./configure

j'obtiens l'erreur suivante
[: 9: ==: unexpected operator

kk1 peut m'aider ? merci

Il y a rien pour l'installer simplement ? (avec le gestionnaire d'installation par ex.)

romain a fait des paquets .deb, essaie de voir si tu peux les installer directement sur ton système...

imane (./1) :
bonsoir,

j'essaie d'installer ktigcc sous linux ubuntu
mais quand je lance ./configure

j'obtiens l'erreur suivante[: 9: ==: unexpected operator

C'est une erreur dans mon script configure: il est déclaré comme nécessitant #!/bin/sh, mais de la syntaxe bash s'y est malheureusement retrouvée.

Lance directement qmake (de toute façon mon configure ne fait qu'appeler qmake, le code qui foire est le code qui traduit --prefix=foo en PREFIX=foo si c'est spécifié).

Alternativement, tu peux changer #!/bin/sh en #!/bin/bash avec un éditeur de texte ou avec la commande:
sed -i -e 's,#!/bin/sh,#!/bin/bash,' configure

Pourquoi tu ne fais pas un paquet installable en 1 clic, comme pour Windows ?

Bah, j'en fais un, je n'y peux rien s'il n'utilise pas la bonne distribution.

Un paquetage GNU/Linux est forcément pour une distribution donnée, je ne peux pas faire des paquetages pour chacune, et comme Fedora est la distribution que j'utilise, ben, je fais les paquetages pour ça (et pas seulement de mes propres logiciels, par exemple j'ai essentiellement tout le sortiment LPG et je package aussi pas mal de paquetages pour les calculatrices Z80 que j'utilise très rarement ou pas du tout).

Il faut demander aux utilisateurs de Ubuntu/Kubuntu pourquoi ils ne packagent pas ces logiciels, Tyler est disponible pour l'hébergement sur repo.calcforge.org si c'est ça le problème.

Et sinon, le problème décrit ici est tout simplement un bogue, trivial à corriger, mais je n'ai pas envie de sortir une nouvelle version juste pour ça parce qu'il suffit de lancer qmake directement à la place de ./configure et que c'est ce que le document INSTALL dit d'utiliser. (Et je signale que ce problème ne se produit que sur Debian et dérivées, ce sont les seuls qui utilisent un /bin/sh merdique qui ne gère pas les extensions bash, pratiquement toutes les autres distributions utilisent bash comme leur sh, ça réduit aussi la duplication de code et le gaspillage de place sur le disque dur.)

Kevin Kofler (./7) :
Un paquetage GNU/Linux est forcément pour une distribution donnée, je ne peux pas faire des paquetages pour chacune, et comme Fedora est la distribution que j'utilise, ben, je fais les paquetages pour ça (et pas seulement de mes propres logiciels, par exemple j'ai essentiellement tout le sortiment LPG et je package aussi pas mal de paquetages pour les calculatrices Z80 que j'utilise très rarement ou pas du tout).

Pas forcément... tu peux très bien passer pas un installeur, c'est d'ailleurs ce que fait TiNa qui a un système d'installation tout Linux, ainsi qu'Oracle (sauf que TiNa se base sur du X11 pur alors qu'Oracle se base sur une console Java). Et ça fonctionne très bien.
Tu perds les avantages des systèmes de paquetages, et encore, je suis certain que tu dois pouvoir faire un installeur graphique qui soit capable de parler à différents gestionnaires de packages.

Bah, c'est une solution pourrie utilisée par les logiciels propriétaires (parce qu'ils ne peuvent pas être repackagés), ça marche très mal. La preuve: j'essaie de proposer ça pour TIGCC lui-même et il y a sans arrêt des problèmes de type "les binaires ont besoin de glibc 2.y, je n'ai que la 2.x avec x<y", et encore les binaires de TIGCC ne dépendent que de glibc, pour KTIGCC, il y a beaucoup plus de dépendances. (Et glibc n'est pas du tout prévue pour le linkage statique.) Bref, ce qui va se passer est que je vais abandonner cette solution pour TIGCC (et ne proposer que les sources et les RPMs), pas l'adopter pour KTIGCC.

Faut tout linker en static, on s'en fout de quelques octets de plus

Sauf que ce n'est pas possible avec glibc, elle charge toujours des plugins dynamiquement. C'est le cas d'autres libs aussi, par exemple les décodeurs d'images de Qt et GTK+ sont des plugins. De plus, linker glibc statiquement introduit une dépendance sur la version du noyau, donc on n'a pas gagné grand chose. Le linkage statique ne fonctionne correctement qu'avec des libs prévues pour.

encore merci pour votre aide,
ktigcc marche bien sous ma ubuntu maintenant... il manque juste le fichier completion que j'ai récupéré (mais ou faut il le mettre?)
j'ai lancé quelques build sur des exemples.. il me manque plus qu'a acheter une ti-89 titanium , j'aimerai y faire tourner des jeux
et commencer l'apprentissage du coding de jeux en mode kernel
petite question perso, tu bosses dans quoi Kevin ?

Kevin bosse dans les mathématiques, à ma connaissance.

> en mode kernel
C'est pas le mode de programmation le plus utilisé pour les nouveaux programmes...

Le mode kernel est considéré comme deprecated (déconseillé car obsolescent/obsolète) par l'équipe de TIGCC et n'est géré plus que pour la compatibilité antérieure. On ne gagne plus rien en fonctionnalités à l'heure actuelle et les programmes sont plus difficiles à faire fonctionner pour les utilisateurs. Mais je ne vois pas le rapport avec KTIGCC. Il y a eu des dizaines de topics à ce sujet, dont certains ont rempli plusieurs pages.

Pour les informations de complétion, c'est écrit dans les release notes: http://sourceforge.net/project/shownotes.php?release_id=459775&group_id=31034.
echo `kde-config --expandvars --install data`/ktigcc/
te donnera le bon endroit.

Lionel Debroux (./13) :
Kevin bosse dans les mathématiques, à ma connaissance.

Ah ! ça m'étonne pas, quand on fait des maths on peut tout faire

Kevin Kofler (./15) :
Le mode kernel est considéré comme deprecated (déconseillé car obsolescent/obsolète) par l'équipe de TIGCC

Non. Par toi. Une personne n'a jamais constitué une équipe.

Thibaut (./17) :

Kevin Kofler (./15) :
Le mode kernel est considéré comme deprecated (déconseillé car obsolescent/obsolète) par l'équipe de TIGCC

Non. Par toi. Une personne n'a jamais constitué une équipe.

Bah, c'est tout ce qui reste de l'équipe, mais Zeljko et Sebastian ont toujours été contre le kernel eux aussi.

Martial Demolins (./18) :
t'as pas vu toutes les possibilités que j'ai mises en évidence avec les ramcalls?

Ce sont juste des manières compliquées de faire la même chose qu'on peut aussi faire sans ces méthodes tordues et inefficaces (plus grandes et/ou moins rapides que la manière simple).

Et sinon, voilà un document que j'ai écrit sur les RAM_CALLs: http://www.tigen.org/kevin.kofler/ti89prog/ramcalls.txt. Et je signale aussi que pour les RAM_CALLs dans la liste "safe and appropriate to use", en C, il y a aussi une implémentation _nostub dans compat.h (sauf ROM_VERSION qui est remplacé par ReleaseVersion).

Kevin Kofler (./15) :
les programmes sont plus difficiles à faire fonctionner pour les utilisateurs.

du fud, du fud

Un programme _nostub peut être envoyé et lancé, comme un programme BASIC. Pour un programme kernel, il faut d'abord installer un kernel et souvent des libs. Donc je ne vois pas où est le FUD.

Kevin Kofler (./19) :
Un programme _nostub peut être envoyé et lancé, comme un programme BASIC.

Please stop feeding this troll. Thanks.

Vieux pots, soupes, tout ça...

Excellent Une seule allusion minuscule au kernel, et cette section qui était morte depuis 1 mois se réanime instantanément

Martial Demolins (./21) :
Compliquées? super simple tu veux dire...

Pas par rapport à la solution simple (genre tout linker en un seul programme au lieu de développer 10000 plugins).

faire tourner un prog de 20 ko avec 5 ko de RAM, t'y arrives?

Ça ne sert strictement à rien parce qu'on a beaucoup plus de 20 KO de RAM et beaucoup de logiciels en nécessitent plus (donc il faut de toute façon la garder libre). Donc tu perds ton temps à découper ton programme pour rien et tu gaspilles de l'archive (parce que ce découpage comporte un overhead en taille), de plus ton programme sera aussi plus lent qu'un programme en un seul morceau.

faire tourner un prog nostub en flash sous PedroM, t'y arrives?

Là encore, quel intérêt, sachant que:
* presque personne n'utilise PedroM,
* autant utiliser la RAM disponible (Tu veux remplir ta RAM avec quoi sous PedroM?),
* exécuter en FlashROM comporte de nombreuses limitations (pas de relogements, pas de variables globales stockées avec le code, pas de code automodifiant etc.)?

Je ne vois vraiment pas l'intérêt pratique de ces technologies.

Allez, je saute dedans à pieds joints !

Kevin Kofler (./24) :

faire tourner un prog de 20 ko avec 5 ko de RAM, t'y arrives?

Ça ne sert strictement à rien parce qu'on a beaucoup plus de 20 KO de RAM et beaucoup de logiciels en nécessitent plus (donc il faut de toute façon la garder libre). Donc tu perds ton temps à découper ton programme pour rien et tu gaspilles de l'archive (parce que ce découpage comporte un overhead en taille), de plus ton programme sera aussi plus lent qu'un programme en un seul morceau.

Ta réponse contient une contradiction : tu dis qu'on a trop de RAM, et puis tu dis qu'il faut la préserver.
En tout cas, faire tourner 20 ko de code dans 5 ko de RAM, ça permet de la préserver.
Et faire tourner 250 ko de code dans ce qu'on a de RAM sur TI, c'est quand même chiant à faire (proprement) en _nostub. Surtout si tu as plusieurs programmes qui font ça.

faire tourner un prog nostub en flash sous PedroM, t'y arrives?

Là encore, quel intérêt, sachant que:* presque personne n'utilise PedroM,

Et alors ? On t'explique juste pourquoi c'est plus puissant, c'est tout.

* autant utiliser la RAM disponible (Tu veux remplir ta RAM avec quoi sous PedroM?),

Les données manipulées par le programme (dans un jeu les personnages, objets et cartes par exemple) ?

* exécuter en FlashROM comporte de nombreuses limitations (pas de relogements, pas de variables globales stockées avec le code, pas de code automodifiant etc.)?

Je ne vois vraiment pas l'intérêt pratique de ces technologies.

Ça peut servir, mais l'objectif était surtout de montrer que le kernel rajoutant une surcouche au _nostub permet de faire des choses plus complexes plus simplement (pour le programmeur).

Sasume (./25) :
Ta réponse contient une contradiction : tu dis qu'on a trop de RAM, et puis tu dis qu'il faut la préserver.

Faux. L'archive n'est pas de la RAM. J'ai dit "tu gaspilles de l'archive".

En tout cas, faire tourner 20 ko de code dans 5 ko de RAM, ça permet de la préserver.

Non, ça ne préserve rien du tout. Il faut de toute façon la garder libre pour d'autres programmes. (Presque tous les programmes ont besoin de plus de 20 KO de RAM.) La RAM n'est pas faite pour le stockage (aussi parce qu'elle est perdue lors d'un reset). L'archive l'est, et en augmentant la quantité d'archive utilisée par le programme, ce découpage réduit la quantité de mémoire utilisable pour le stockage. La grosse différence est que le stockage (archive) est consommé par tous les programmes en même temps, la RAM par un seul programme à la fois (parce que AMS est monotâche)!

Et faire tourner 250 ko de code dans ce qu'on a de RAM sur TI, c'est quand même chiant à faire (proprement) en _nostub. Surtout si tu as plusieurs programmes qui font ça.

Il faut déjà l'avoir, le programme de 250 KO, pour se poser cette question. Ça ne sert à rien d'utiliser des techniques faites pour d'énormes programmes (et oui, le chargement dynamique de libs kernel a été conçu d'origine pour un énorme programme, le fameux Chrono Fantasy) sur des programmes de taille moyenne voire minime.

Les données manipulées par le programme (dans un jeu les personnages, objets et cartes par exemple) ?

Tu as besoin de 192 KO pour ça?!

Ça peut servir, mais l'objectif était surtout de montrer que le kernel rajoutant une surcouche au _nostub permet de faire des choses plus complexes plus simplement (pour le programmeur).

Et ma position est que ces "choses plus complexes" ne servent strictement à rien en pratique (pas sur un exemple tordu comme le programme de 250 KO, qui de plus doit être suffisamment découpable pour pouvoir être coupé en morceaux de 64 KO maximum), elles ne font que vous compliquer la vie si vous choisissez de les utiliser.

(bon, finalement j'ai la flemme de redire ce qui a déjà été dit - par moi et d'autres - alors je ne réponds pas, dsl)

Martial Demolins (./28) :

Kevin Kofler (./24) :
(genre tout linker en un seul programme au lieu de développer 10000 plugins)

-9999 si no veut les relogements en flash, les ramcalls, et les variables. sinon, -10000.

Je parle de la technologie des programmes en morceaux là, pas de l'exécution en FlashROM. (Tu as proposé 2 technologies différentes, aussi inutiles l'une que l'autre.) Regarde bien le contexte de ce à quoi tu réponds!

(et les sauvegardes d'écran sur la pile (avec une routine même pas optimisée !))

La sauvegarde de l'écran sur la pile permet justement d'économiser de la mémoire heap! Quant aux histoires d'optimisation, ce n'est pas retirer 2 octets qui changera énormément les choses.

La place en archive, c'est minime, minime.

Pas tellement, fais le calcul, tu verras que toutes les tables d'importation et d'exportation prennent beaucoup de place que tu as l'air de croire.

Et justement, le but est de se servir de la flash pour économiser la RAM, et pas de la RAM pour économiser la flash

Et justement, c'est économiser au mauvais endroit. La RAM est de la mémoire de travail, tu as environ 150 KO minimum de libre en conditions normales, tant que tu n'utilises pas ces 150 KO (ou disons 100 KO pour être surs, c'est la quantité de mémoire nécessitée par TI-Chess par exemple), ça ne sert rien de l'économiser. L'archive, elle, est de la mémoire de stockage, plus tu consommes d'archive, moins de programmes l'utilisateur pourra garder sur sa calculatrice. Donc consommer 1 KO d'archive pour réduire la consommation de RAM de 100 KO à 1 KO est déjà un mauvais choix (ou le serait si c'était possible, en réalité l'overhead pour une granularité aussi fine serait immense!).

Quant au temps, j'ai déjà posté publiquement la routine (~50 lignes?) qui fait ça, ya plus qu'à coder autour sans rien changer.

Je sais que tu as déjà perdu ton temps, ça n'en fait pas moins du temps perdu.

C'est sûr, si tu t'amuse à charger 20 ko de code entre l'affichage de deux persos, ça va ramer. Kilukru Si c'est bien fait, tu n'y vois que du feu.

Ce n'est pas de ça que je parle, mais du fait qu'un saut relogé en abs.l (ou pire, du F-Line) est beaucoup plus lent qu'un bsr.w voire bsr.s qu'on aurait en général dans un programme monolithique (surtout grâce à --reorder-sections). Mais effectivement, il y a le temps de chargement/déchargement aussi.

CF, oui.

CF utilise la mémoire (aussi l'archive) de manière totalement abusive, je sais. (AMHA, optimiser en taille plutôt qu'en vitesse pourrait réduire de beaucoup cette consommation.) Mais ce n'est pas le genre de programmes qu'un nouveau programmeur comme imane va coder.

ah ça y est? c'est reparti? #popcorn#