Tu sais que tu as le droit de définir le répertoire en cours comme sous Linux ? Et il me semble que gcc arrive à fonctionner avec les chemins relatifs
Mais bon, c'est vrai qu'il y a peut-être probablement des bugs liés à la constante MAX_PATH à l'intérieur de gcc… :]

Bien vu, ce test sur la longueur ne doit pas aider
Mais sa présence ne suffit pas à expliquer pourquoi l'IDE ne rencontre pas de problème, malgré l'UAC activé, sur certaines machines: "C:\Documents and Settings\a\Local Settings\temp" fait toujours plus de 30 caractères.

TEMP peut se redéfinir.

Je vérifierai ma VM Vista quand j'y aurai accès.

Vérifier quoi ?
Ça peut se redéfinir, c'est tout à fait certain. D'ailleurs c'est le cas sur ma machine du boulot. Et j'ai dû le faire chez moi aussi, sur un autre volume...

Vérifier les valeurs des variables d'environnement TEMP ou TMP, si elles existent
(désolé, je me suis mal exprimé)

Ben oui elles existent. Je suis sur un Vista 64 là.

C:\>echo %tmp% 
C:\TEMP 
 
C:\>echo %temp% 
C:\TEMP

Nan, mais je parlais des valeurs de TEMP et TMP (et de leur existence éventuelle) sur ma machine virtuelle
Je sais bien que ces variables d'environnement peuvent être redéfinies à volonté, avec override des variables per-user sur les variables globales.


Je viens de reproduire le problème: quand l'UAC est activé, ce test sur la taille du chemin du répertoire temporaire peut effectivement faire merder le build,

Sur ma VM, le user name est tel que l'expansion du path TMP=TEMP=%USERPROFILE%\Documents\temp (choisi pour le test, car les droits y sont suffisants même quand l'UAC est activé), à savoir C:\Users\login6\Documents\Temp produit une chaîne d'exactement 30 caractères. Le build fonctionne.
Avec TMP=TEMP=%USERPROFILE%\Documents\temp2 (31 caractères), le build merde (pas trouvé extgraph.h).
Avec la valeur TMP=TEMP=%USERPROFILE%\AppData\Local\Temp (34 caractères), répertoire temporaire plus traditionnel, le build merde aussi pour la même raison, bien sûr.


Le minimum à faire est donc de dégager les deux "or (Length (Temp) > 30) " de l'extrait de code posté en ./50
Mais il est clair que dégager ces deux tests n'est pas suffisant: si, à la fin de la détermination du path du répertoire temporaire, la variable Delphi "Temp" pointe vers un répertoire protégé par l'UAC (soit parce que TMP ou TEMP contiennent une telle valeur, soit parce que les fallbacks vers %WINDIR%\TEMP ou C:\TEMP ont été déclenchés), on aura quand même un problème avec l'UAC. Il y a donc d'autres modifs à faire ailleurs dans le code, pour prendre en compte l'UAC.


J'avais regardé les symptômes avec ProcessExplorer, aidé d'un utilisateur dont j'ai oublié le pseudo et qui pouvait, lui, reproduire le problème, et publié les fichiers - mais en fait, pour une fois, le problème est visible en revue de code.

Heu, franchement si j'étais toi, je me contenterais de renvoyer un message d'erreur explicite si %temp% n'est pas accessible en écriture. Faut pas déconner quand même

Si TEMP ou TMP sont overridées vers un répertoire protégé, c'est a priori parceque l'utilisateur l'a fait en connaissance de cause (ou qu'un autre soft lui a pourri ses variables d'environnement, mais ça reste un problème étranger à TIGCC/GCC4Ti) ; donc crayon Pen^2 ^^

Egalement. Tu ne peux pas tout blinder, et de toute façon l'utilisateur arrivera toujours à te trouver le cas kivabien qui mettront tes protections en défaut. Et me cherche pas, je suis très fort à ça.
Donc aussi.

Mouais, c'est pas faux... tester Temp en écriture et afficher un message s'il n'est pas possible d'y écrire, paraît un bon premier pas
Bon, ça n'est pas super pressé (à faire absolument ce soir, je veux dire ), puisqu'il y a depuis longtemps un workaround efficace et bien documenté.

l'utilisateur arrivera toujours à te trouver le cas kivabien qui mettront tes protections en défaut. Et me cherche pas, je suis très fort à ça.

Ca m'arrive aussi, voir par exemple le bugfix qui a suivi mon report du bug qui se produisait quand on lançait ttstart avec lui-même

Ce que tu appelles "workaround" c'est désactiver l'UAC ? Si oui alors c'est une extrêmement mauvaise idée... ça implique d'annuler cette sécurité sur l'ensemble du système, je n'appelle pas ça une solution.

On peut aussi lancer l'IDE en mode administrateur mais ça a d'autres impacts, et ça permet potentiellement à l'IDE de toucher des fichiers auxquels elle n'est pas censée avoir accès, donc c'est également très moyen je trouve. Étant donné la simplicité du correctif, il me semble au contraire que ça fait partie des corrections qui pourraient être mises en place aussi tôt que possible.

Nous sommes d'accord, le workaround n'est qu'un pis-aller en attendant une meilleure compatibilité avec l'UAC
Je voulais juste signifier juste que je ne vais pas coder la modif complète (dégager les deux "or (Length (Temp) > 30) ", je peux y arriver sans faire d'erreurs de syntaxe / sémantique; en revanche, pas ajouter un message d'erreur et refaire la chaîne d'exceptions pour faire en sorte qu'il y ait moins d'avalements silencieux d'erreurs), et releaser de build de test de l'IDE de GCC4TI, ce soir

(ça fait deux ou trois messages pas clairs de ma part en quelques heures dans le topic, c'est beaucoup ^^)

Ben dis donc , ça papote ici

Bon, l'est sympa cette lib, tout marche vraiment nickel, et c'est plutot fluide (considerant la taille des images du jeu) donc chuis plutot content
sinon j'ai un probleme justement du a la taille des GFX : ya t'il moyen de les stocker ailleurs que dans l'executable et de les charger quand on en a besoin ?





(Autre question qui n'a rien a voir: ya t'il moyen de lancer un prog compilé pour 89 sur une v200 ?)

sawamura (./73) :
ya t'il moyen de lancer un prog compilé pour 89 sur une v200 ?

Pour que le programme fonctionne ou non, ça va dépendre de comment il a été codé et de comment il a été compilé.
Si les options spécifient précisément TI89 uniquement, alors tu as de fortes chances qu'il ne marche que sur TI89.
Mais il est possible de faire des programmes qui tournent sur les deux modèles

GoldenCrystal (./74) :

sawamura (./73) :
ya t'il moyen de lancer un prog compilé pour 89 sur une v200 ?

Pour que le programme fonctionne ou non, ça va dépendre de comment il a été codé et de comment il a été compilé.
Si les options spécifient précisément TI89 uniquement, alors tu as de fortes chances qu'il ne marche que sur TI89.
Mais il est possible de faire des programmes qui tournent sur les deux modèles

ouioui, ca je sais
en fait j'ai retrouvé sur le net un jeu que j'avais codé ya un bout de temps sur 89, je voulais le lancer histoire de me remémorer le truc, mais j'vais faire ça via VTI
( http://www.ticalc.org/archives/files/authors/74/7410.html )

Oui, suffit que tu le définisse dans les options du projet, que la compilation doit se faire pour les deux machines. Mais c'est le cas par défaut.
ps -> si tu utilises genlib et son joypad, t'auras déjà pas de problème pour le clavier. Ensuite, pour l'écran, deux constantes font l'affaire (regarde le ramcall CALCULATOR, ou LCD_SIZE, je ne sais pas, il y a l'embaras du choix pour connaitre le matériel sur lequel tu tournes).

Et tu peux mettre tes sprites dans un fichier externe.
Deux possiblités :
Tu utilises un fichier de données quelconque, extension de ton cru. Pour obtenir un pointeur sur ton fichier, il faudra faire :
void* ptr = HLock(SymFindPtr(SYMSTR("monfichier", 0))->handle);
Bon, oublie pas de vérifier que le SymFindPtr a marché évidemment, je te laisse consulter la doc de vat.h.

Ma solution préférée : une librarie dynamique. Comme on met ce qu'on veut dedans, on peut mettre des données.
Avantage d'une librairie sur un fichier quelconque :
- tu peux exporter tout ce que tu veux comme données, genre malib__SpritesPerso etc... du coup dans ton programme, tu écris juste "malib__SpritePerso" comme si ça faisait partie du même binaire, le kernel s'occupe de te reconstituer le tout quand ton programme se lance
- pas besoin de vérifier où est ton fichier à la main, le kernel poussera une gueulante si ton fichier de donnée n'est pas là, et refusera de lancer ton programme

Ca, c'est que la partie supérieure du haut du sommet de la partie visible qui dépasse de l'iceberg, on peut faire des milliards de choses avec une librairie dynamique.

Si on a seulement le binaire, ce logiciel peut aider.

Folco (./76) :
- tu peux exporter tout ce que tu veux comme données, genre malib__SpritesPerso etc... du coup dans ton programme, tu écris juste "malib__SpritePerso" comme si ça faisait partie du même binaire, le kernel s'occupe de te reconstituer le tout quand ton programme se lance

Avec à chaque fois un relogement de lib, 2 octets minimum (+ les 4 octets de l'adresse absolue). Plus 2 octets par export différent qu'on importe, plus 10 octets par lib. Et la lib a aussi besoin d'un header qu'il n'y a pas dans un simple fichier de données.

- pas besoin de vérifier où est ton fichier à la main, le kernel poussera une gueulante si ton fichier de donnée n'est pas là, et refusera de lancer ton programme

Bah, si SymFindPtr retourne NULL, pas la peine de chercher plus loin, le fichier n'existe pas. Ce n'est pas sorcier.

Ca, c'est que la partie supérieure du haut du sommet de la partie visible qui dépasse de l'iceberg, on peut faire des milliards de choses avec une librairie dynamique.

La preuve que ce n'est pas fait pour un simple fichier de données!

Mouarf
J'ai toujours ce foutu probleme du programme qui ne se lance qu'une seule fois :/
Apres j'ai juste droit a un "DONE"

Et si tu l'archives ? (juste pour tester)

toujours "done"

Archivé avant de le lancer la première fois ?

oué c'était ça la question en fait

là ca fonctionne
mais bon, je comprend pas...

Ça veut dire que quelque part ton programme modifie les données qui sont contenues à l'intérieur…
Donc quand tu l'exécutes la deuxième fois, ce n'est plus le même programme. (sauf si archivé puisque la mémoire archive conserve la version originale)
Après, pour ce qui est la cause de ce comportement, là faut regarder le code. ^^

ya vraiment que ca pour l'instant

(chui surtout en mode rippage de sprites )

Ben là ton problème doit venir des variables globales. (Enfin surtout la variable « done »)
(C'est spécifique à TIGCC ça mais bon… Il me semblait que TIGCC bidouillait pour qu'on aie plus ce problème ?)
Pourquoi ne pas déclarer ces variables dans ta fonction main plutôt ?

ben done n'est pas réinitialisé à 0

 
int done;  
void gl_main()  
{  
   done= 0 ; 
   while ( done != 1 )