lancement de ppg??? - Page 1

Je voudrais savoir pourquoi j'obtient un planatage en lançant un ppg depuis un répertoire autre que main

J'obtient ce plantage que ce soit en uitlisant HomeExecute ou le lanceur de la faq de TIGCC

De plus en lançant le ppg avec ttstart, de la ligne de commande y'a pas de problème

Déjà, à moins que ce ne soit dans un TSR, oublie HomeExecute pour lancer un programme en assembleur/C, ça ne marchera pas sur HW2 AMS 2 sans h220xTSR ni HW2Patch.

Ensuite, pour le lanceur de l'exemple, tu dois avoir fait une bêtise en l'adaptant. Je ne peux pas te dire où exactement se trouve le problème si tu ne postes pas ton code modifié.

Ben oui c'est pour mon TSR!!!

le lanceur le voici: // Lancement d'un prog (tiré de la FAQ de TIGCC) void launch(const char *prog) {      HANDLE h;      TRY           push_parse_text(prog);           h=HS_popEStack();           NG_execute(h, FALSE);           HeapFree(h);      ONERR           ST_helpMsg("Lancement impossible");      ENDTRY }

et je l'appelle avec une chaîne caractères contenant le code à évaluer!!!

Utiliser HS_popEstack dans un TSR est une très mauvaise idée, parce que ce ROM_CALL prélève tout le contenu de la pile d'expressions, même ce qui pourrait y avoir été mis par AMS!

D'ailleurs, pour HomeExecute, attention à ne pas utiliser HomeExecute dans des évènements comme "appui sur [ENTER]" qui peuvent être déclenchés par HomeExecute lui-même!

Pourtant launch fonctionne très bien avec les kbdfunc!!!

C'est quand-même une mauvaise idée, parce que ça ne marchera pas dans tous les cas. (Ça risque fort de planter dans certaines situations!)

Le ONERR est la pour ces cas la quand même???
Ben sinon s'en est fini de kbdfunc pour un petit moment

slubman
a écrit : Le ONERR est la pour ces cas la quand même???

Non.

Kevin Kofler a écrit :
Utiliser HS_popEstack dans un TSR est une très mauvaise idée, parce que ce ROM_CALL prélève tout le contenu de la pile d'expressions, même ce qui pourrait y avoir été mis par AMS!

Mais pourquoi dans un programme normal ça ne gène pas ?
Et comment faire à part en executant le programme directement (en désarchivant, Ex_patchant, ...) ?
ID utilise ça

ExtendeD
a écrit : Mais pourquoi dans un programme normal ça ne gène pas ?

Parce que au lancement d'un programme "normal", AMS fait une sauvegarde de top_estack et la met au bon endroit pour que HS_popEstack ne prélève que la partie de la pile d'expressions correspondant au programme en cours.

Et comment faire à part en executant le programme directement (en désarchivant, Ex_patchant, ...) ?
ID utilise ça

Soit on tokénise le nom à la main, soit on fait comme Shortcuts de Samuel Stearley:

    lea		end_of_name(pc),a0
    move.b		#'(',(a0)
    move.b		#')',1(a0)

lt:
    tst.b		-(a0)
    bne		lt
    pea		1(a0)
    move.l		push_parse_text*4(a6),a0			;push it and parse it
    jsr		(a0)
    lea		end_of_name(pc),a0
    clr.b		(a0)
    addq.l		#6,a7				;reset the stack
    tst.w		d0				;test for error
    bne.s		no_error2
    dc.w    	$A38E				;throw an error
no_error2:
    move.l		top_estack*4(a6),a0
    move.w		2(a0),d3			;get top of estack as a word
    sub.w		a2,d3				;get the difference from the old top of estack
    addq.w		#2,d3				;increase it
    move.w 		d3,-(a7)			;put it onto the stack
    clr.w 		-(a7)				;turn word into a long
    subq.w 		#2,d3				;decrease d3
    move.l		HeapAllocHigh*4(a6),a0
    jsr		(a0)				;allocate memory
    move.w		d0,-62(a5)			;put the allocated handle into the save position
    move.w 		d0,-(a7)
    move.l		HLock*4(a6),a0			;gratuitously call heap lock
    jsr		(a0)
    move.w 		d3,(a0)+			;will be offset to the tag
    move.w 		d3,-(a7)			;place size as a long on the stack
    clr.w 		-(a7)
    pea 		1(a2)				;place the source
    move.l 		a0,-(a7)			;place the destination
    move.l		memcpy*4(a6),a0			;copy memory
    jsr		(a0)
    move.w 		-62(a5),-(a7)		;put handle on the stack
    move.l		HeapUnlock*4(a6),a0
    jsr		(a0)				
    clr.w 		-(a7)				;executing flags
    move.w 		-62(a5),-(a7)		;handl of stuff to execute
    move.l		NG_execute*4(a6),a0			;ng_execute
    jsr		(a0)
    move.l		HeapFree*4(a6),a0			;heapfree
    jsr		(a0)

(j'ai remplacé ses constantes numériques pour les ROM_CALLs par les constantes symboliques correspondantes), soit on exécute le programme directement (mais ça ne marche pas pour le BASIC, donc la tokénisation à la main est une idée meilleure).

merci
Et pour la méthode de Samuel Stearley, ce qu'on a mis sur la pile d'expression, on le laisse comme ça sans nettoyer ?

Non, on remet la valeur qu'on a sauvegardée au début. (Je ne sais pas pourquoi ce n'est pas dans l'extrait que j'ai posté, tu peux télécharger la source complète sur http://www.calvin.edu/~sstear70/.)

Ah oui, ok.

Ce qui me surprend, c'est que meme en cas de redimensionnement de l'estack, le ptr de l'estack reste valide. En fait, HeapRealloc d'AMS si le bloc est locke bouge tous les blocs qui sont derriere s'ils sont pas lockes pour satisfaire la requete. C'est plutot bien foutu. Fin de la note culturelle.

Dommage que le Garbage Collection de la Flash ne soit pas aussi bien étudié... Tu vas nous en faire un beau pour PreROM
(ça devrait être plus lent par contre)

En remettant le stack à son niveau avant le lancement, y'a pas de pb, par cpntre il semblerait que txtrider rechigne à lancer des textes qui ne sont pas dans le répertoire courant