Prière de les consigner, datées ici même. Macro CMZ =========== + pouvoir forcer de compiler des decks, ou au moin des patch. Pour aux moin deux raisons : - en cas de "plantage" ou bug - vue la gestion rustique des patch "librairies" (en plus des patch /proc et /zinit) , il est extrement penible de sortir d'une situation dans laquelle on a repondu Y a Ok to update lib ? exemple : exe modif Ok to update lib ? Y <== funeste erreur exe modif atmlib MKALL: Library oa_demo/oa_demo.lib up to date JLD le 10/05/94 Reponse (non satisfaisante mais on va y reflechir !) Robert FRANCHISSEUR (1994/07/08) il suffit dans ce cas d'effacer la librairie ( she dlf oa_demo/oa_demo.lib ) mais ca recompilera le tout ( c'est la punition pour la "funeste erreur" ) A present avec les nouvelles KUMACS on recompile en fonction de la date des .bin ce qui resout le pb. precedent. =========== Macros PDL-000 ============== A partir du point d'entree R (ou S pour les TR) la division de travail est la division standard (i.e. 2). Si l'on doit alors creer un block d'une espece repertoriee (ayant donc sa place dans l'arbre,avec des contraintes de division), il faut changer de division; exemple d'un appendice de TD-bank : implicit access to bank CD(LCD); declare class CD; rlink wght <==== link de reference du TD vers le WGHT in class cd; local_var capa in class CD; end declare class CD; ! declare class wght; local_var numtv, weight([numtv]) in class wght; link_var flux([numtv]) in class wght; end declare class wght; ; ................................................... "dans le point d'entree R : creation du WGHT" !switch to FRAM division in order to create WGHT bank in the right place NODKE = NODV; NODV = NOFRAM; " "SET .NUMTV FOR WGHT = NTV; " "LIFT LWGHT OF CLASS WGHT UNDER (2,0); <===== le WGHT est cree dans la chaine lineaire des TD " "@LCD@CD@WGHT@ = LWGHT; !Restore current division NODV=NODKE; CONCLUSION : ---------- Il faudrait au moins une instruction specifique pour creer les blocs description, avec changement de division implicite. Pour les autres blocks, je ne sais pas. JYG le 3/06/94 ======================= PDL (0) ====== Faire une macro 'set D-matrix flag' qui elimine ce genre de commande : CALL SBIT1(IQ(LTR),2); "Set D-Matrix flag" &'Set D_Mx flag'='CALL SBIT1(IQ(LTR),IODMX);' &'Set D_Matrix flag'='CALL SBIT1(IQ(LTR),IODMX);' ; &'Set K_Tr flag'='CALL SBIT1(IQ(LTR),IOKTR);' ; &'Set Pseudo1_K_Tr flag'='CALL SBIT1(IQ(LTR),IOK2TR);' &'Set K1_Tr flag'='CALL SBIT1(IQ(LTR),IOK2TR);' ; &'Set Pseudo2_K_Tr flag'='CALL SBIT1(IQ(LTR),IOK3TR);' &'Set K2_Tr flag'='CALL SBIT1(IQ(LTR),IOK3TR);' en DEV, OK ?(Al1) JYG le 3/06/94 (reponse Al1) ==================== DECLARE.mac ===========(Al1 vendredi 03/06/1994) Y aurait-il moyen de diagnostiquer les set .Machin for Truc = ... quand malencontreusement il n existe pas de Var[Machin] ??? mardi 20/09/1994 ===============(JYG) Pointeurs sur SZ Banks de MXT et MXR : il suffit de generer : &'@#@mt@' = '@#1@mt.#1.@' &'+OMT.#.' = '+OMT' &'+OMT.#.SR'='-0_(#1.MT).Nb_St_BRows-4' au lieu de : &'+OMTSC'='-(MT).VR.Nb_St_BRows-4-1 ' Pour ZBM/ker : Macro DoNext LADR=LFirst < ;>; ::> Loop; jeudi 23/01/1997 ===============(Al1) Il serait utile de pouvoir creer des Var_Linked, pointant sur un tableau (LTab) a l'aide d'un seul link, et donnant acces aux valeurs du tableau. Exemple : Var_Linked Fi_TRProcName_TV reserve une variable protegee ODimFi_TRProcName_TV ... link Fi_TRProcName_TV to Fi_TV du processeur en question lui donne sa valeur et stocke LTab dans LQ(LCD-OBIASFi_TRProcName_TV)... utilisation : Fi_Tr(i) => Q(LQ(OBIASFi_TRProcName_TV)+i-1) check array entre i=1 et ODimFi_TRProcName_TV Var_Linked Fi_TRProcName_TV(n) reserve n variable protegee ODimFi_TRProcName_TV(n) ... link Fi_TRProcName_TV(i) to Fi_TV d'un processeur stocke LTab dans LQ(LCD-OBIASFi_TRProcName_TV-i+1)... utilisation : Fi_Tr(i/k) => Q(LQ(OBIASFi_TRProcName_TV+k-1)+i-1) check array entre i=1 et ODimFi_TRProcName_TV(k) et k.le.n jeudi 26/03/1998 ==============(Al1) de l'interet d'une variable TimCar(10?) equivalent dTimeNxt, TimcarC, TimcarT, ... dans le common /otime/ qui permettrait d'echanger de l'information entre les processeurs et le ZSTEER pour gerer les variations de dTime. EQUIVALENCE (Time_char(1),dTime_next),(Time_char(2),Tim_char_Cl), +(Time_char(3),Tim_char_Tr) implementé le lundi 30/03/1998. pour test prelim. Il faut prevoir un tableau des temps en // a un tableau d'identification de l'objet/proc et donc des macros. mardi 11/08/1998 ==============(Al1) Ou' on retrouve un pb recurent concernant les transferts cumules. On rapelle que Fi est calcule, et dFi = dE = Sum_dt[Fi.dTau] Qu'en est-il des Tr_cum ayant une matrice D ? A verifier, mais il se pourrait que dans la D_loop, dFi soit bien dFi, et qu'il ne devienne dE que dans la Step_Advance. Finalement, seules les cellules sont concernees; on pourrait garder a dFi son contenu standard et avoir dE en plus/a part ? Il semble que a l'heure dite, Fiz des tr_cum reste nul. Pourquoi ? On en profite pour relancer un tour de table sur les initialisations possibles de Fi : a partir de Zinit (Fiz), des S_entry, et de Resume from. Faire l'etat des possibilites. (Rq: ONCO remplit Fi et FIz en se debarassant de FzT de Zinit.) vendredi 08/01/1999 =================(Al1) En ce qui concerne la gestion du pas de temps (dTime, Time_char()), il serait judicieux de prevoir une gestion a la sortie de la D_loop et non a la fin du pas, car alors, on est en retard. La determination de Time_char serait faite dans les K_Entries de cellules (appeles pendant la D_loop) et en fin de D_loop, on appellerait un point d'entree DZSTEER de Zinit. On aurait alors les contraintes a jour avant le step_advance.