pb memoire en lisp

[Labletech]

Bonjour à toutes et à tous ..

Cela faisait pas mal de temps que je n'étais pas venu sur ce forum.

Je viens de subir 2 contrôles administratifs (qui ne sont d'ailleurs pas finis) et je dois dire qu'ils m'ont passablement occupé ces derniers mois !!

 

Voilà une question qui aurait pu être posé indiféremment dans l'une ou l'autre des rubriques tant elle peut paraître simple mais malgré tout bien complexe aussi !!

 

Jusqu'à maintenant je me vautrais dans le lisp avec toute l'aisance d'un gourmand goulu qui ne faisait pas bien attention aux pb de mémoire.

 

Vla ti pas que l'un de mes petits progs qui exploite des semis de points me fait des misères dès que je dépasse une gestion globale de plus de 260 points (blocs topo) pour travailler dessus.

Mon prog qui fabrique bien-sûr des listes constituées d'infos issues de ces 260 et quelques blocs s'arrête à un endroit non maitrisé par moi (apparemment jamais au même endroit) et me balance le message suivant:

Programme intérrompu: valeur d'argument incorrecte: does not fit in byte: 300

Où 300 est justement le nb de blocs que je manipule dans ce cas précis.

J'ai donc pensé que je saturais peut-être un peu mes mémoires de piles ou de tas dans mon lisp.

J'ai donc essayé d'utiliser les fonction alloc et expand. Etaient-ce les bonnes fonctions à utiliser ??

J'avoue que les résultats ont été peu probants.

J'ai par exemple tapé (alloc 100) ca m'a répondu 100 soit

J'ai ensuite tapé (expand 10) je crois que cela aurait du me répondre 1000 et en fait ca ma répondu 103.

J'avoue que je n'y comprend rien !!

Si quelqu'un pouvait m'apporter ses lumières je lui en serais infiniment gré !!

Je rappelle en l'occurence que je cherche tout simplement à faire tourner un prog qui manipule pas mal de listes dont le nb d'occurences peut donc dépasser les 260 occurences

.

Bien-sur inversement dèsque je manipule moins de 260 éléments mon prog fonctionne très bien. Il n'y a donc pas de bugs dans la programmation elle-même ...

 

Help .. :casstet:

 

[Tramber]

Je copie ce que je lis dans le manuel R13, personnalisation, page 560 :

 

......Alloc permet d'obtenir une taille autre 514 noeuds (variables, fonctions,...etc) par segements pour les prochains demandés.

elle définit la taille des noeuds comme taille de segement et renvoie l'ancenne taille.

 

Expand renvoie le nombre de segments qu'ell a réussi à se faire réserver dans la zone du tas. Ce nombre peut-être largement inférieur à ce qui est demandé.......

 

 

Tu n'as pas cette doc ?

 

Ca l'air intéressant même s'il faut relire 10 fois, je n'en suis qu'à une !...

 

et je me déconnecte dans 5 minutes.

 

[Serge]

Labletech,

 

Tu peux fixer alloc à 100000 puis faire des garbage collection de temps à autre.

 

Exemple 1:

(alloc 100000) ;; à la fin du fichier lisp, s'éxécute une fois

 

Exemple 2:

(if (= (rem nBloc 100) 0) (gc)) ;; dans le while, faire un garbage collection tous les 100 itérations

 

Dans les bonnes versions DOS (2.18 à R10_c2a), on avait une limite de mémoire Lisp due à la barrière du 640Ko. Il fallait se réserver 45ko pur le Heap et le Stack via le autoexec.bat, comme suit:

LISPHEAP=6000

LISPSTACK=39000

 

Puis est venu PharLap, le DOS-Extender. On a cru que la gestion de mémoire était caduque, mais c'était faux. Dans certains cas, comme par exemple ton programme ou si on fait de très nombreuses sélections d'objets (j'ai déjà fait une routine qui quadrillait un plan en x et y intervalles, donx x par y sélections), AutoLISP ne libère pas la mémoire. Il faut donc en prévoir plus, ou la libérer.

 

Serge

 

[Labletech]

Merci pour ces conseils mais ils restent sans effet pour ce pb:

 

En effet j'avais déjà essayé de gonfler la valeur allouée à alloc (j'avais mis 1000) sans trop savoir à quoi ca correspondait. La notion de noeud ayant du mal à passer mes synapses.

Quelque soit la valeur que je choisis (alloc x) avec X > 300 me répond toujours la même chose c'est à dire 256.

 

Quand à (gc) il me semble qu'il purge globalement toutes les mémoires de tas de mon lisp. Or j'ai bien sûr besoin des infos qui se trouvent dans mes listes locales pendant l'éxécution du prog.

Je peux peut-être glaner quelques octets économisés dans certaines boucles mais je n'arriverait de toutes facon pas à passer de 200 et quelques objets gérés à 1000 par exemple.

 

Non je pense que alloc et expand doivent être utlisé d'une certaine manière que j'ignore et dont j'aimerais bien avoir quelques éclairages ...

Merci pour toute autre idée ...

[Tramber]

Si je comprenais tout ce que je lisais, je r'aurais fait un résumé avec plaisir.

 

Veux-tu une copie personnelle des qqes pages du manuel R13 ?

Envoies-alors un MP avec ton adresse.

[Serge]

Labletech,

 

Effectivement, alloc et expand peuvent t'aider. Mais une meilleure modularité pourrait aussi aider. Est-ce posible de m'envoyer le code et un dessin à l'adresse suivante (en remplaçant le # par @ : cunivers#univers.qc.ca

 

Serge

 

[Labletech]

Si meilleur modularité veut dire meilleur structuration du prog afin d'economiser les lignes redondantes de programmation, il s'agit alors d'un concept que j'utilise depuis les années 80...

 

Je doute fort donc que tu puisses trouver dans mon prog des parties relativement inutiles .. quoi que .. on n'est jamais sur de rien !!!

 

Quoi qu'il en soit ta proposition est fort sympa mais j'aurais scrupules à sous-traiter un pb de ce type alors que j'aurais du le faire si cela était nécessaire !!

Merci encore ...

 

Par contre si un exemple bien pesé de programmation permettait de comprendre les limites des fonction alloc et expand ca serait fort interessant ... pour moi bien-sûr mais aussi pour la communauté lispienne de ce forum ...

 

 

[Labletech]

Je suis allé un peu plus loin dans mes pb de mémoire ....

En fait mon pb est basique .. et très frustrant en même temps ...

 

Un opérateur lisp peut dans certains cas, accepter plusieurs opérandes. Ce sera le cas pour les opérateurs arithmétiques simples comme +,-,* et /.

En théorie on peut mettre autant d'opérandes que l'on veut ... mais oui mais ca c'est la théorie ...

 

Essayez donc de faire (+ 1 1 1 1 ... et cela 280 fois par exemple ... 1 1 1)

et vous verrez que cela vous répond : erreur d'argument don't fit in byte memory : 280.

 

On peut changer alloc ou déposer un cierge pour Saint Lisp à l'eglise si on veut mais ca ne changera pas grand chose au principe que lisp a des limites que la chance ne m'avait pas fait rencontrer depuis quelques années !!!.

 

Dans mon prog j'utilise un principe à peu près identique pour trouver la valeur mini d'une liste de valeur.

La fonction adhoc sera par exemple (min 2 8 9 5 1) et qui retourne 1 dans ce cas précis. Et bien si le nombre de valeurs derrière le min est plus grand que 260 à peu près et bien la fonction balance l'erreur mentionnée plus haut !!

J'avais une liste lz constituée de n valeurs d'altitude .

mon prog ecrivait:

 (setq vmin (cons 'min lz))
(eval vmin) 

pour lancer l'ordre min sur le contenu de lz.

Dès que lz dépasse 260 valeurs l'ordre plante lamentablement.

 

Pour résoudre mon pb je n'ai pas vu autre chose que de faire un nouveau prog qui me permettra via une boucle pour le moins maladroite de calculer la valeur mini d'une liste.

 

 (defun valmin (llv / vmini vref)
(setq vmini (car llv) ilv 0 nlv (length llv))
(while (< ilv nlv)
  (setq vref (nth ilv llv))
  (if (< vref vmini) (setq vmini vref))
  (setq ilv (1+ ilv))
)
(eval 'vmini)
)

C'est à dire que là où ma notation symbolique permettait de traiter le pb en 2 lignes il m'en faut maintenant 9 lignes !!

Et maintenant mon prog fonctionne de nouveau correctement !!!

En d'autres termes c'est bien fustrant de ne pas pourvoir profiter de certains principes fondamentaux du lisp dans l'autolisp qui est donc plus limité ...

 

 

... A moins que quelqu'un puisse me dire comment augmenter le nb d'opérandes dans une opération autolisp ....

 

 

[Edité le 11/10/2004 par Labletech]

[Labletech]

Alors personne ne peut me dire comment augmenter le nb d'opérandes dans une oépration lisp ?? :mad:

C'est pas cool, d'autant plus que les compilateurs classique du lisp comme Le_lisp sont capables eux de traiter plus de 260 opérandes dans une opération lisp ...

:casstet:

[bruno_l]

heu .... par une fonction recursive ?

 

[bonuscad]

Oui Bruno_l a raison, il faut s'y prendre autrement.

 

Pour répondre en même temps à une question sur les limites maximun et minmun d'une liste de point sur une polyligne (boite d'encombrement d'un objet) différent de EXTMAX et EXTMIN.

 

Dessiner avec la commande MAINLEV en mode polyligne

Faites environ + de 280 sommets et une autre - de 280.

Appliquer sucessivement les 2 routines TOTO et TITI, Toto devrait avorter pour plus de 280 sommets.

 

Une limitation du Lisp à laquelle il faut penser s'y on doit manipuler des liste longues (pas évident) :o

(defun c:toto ( / )
(while (null (setq ent (entsel "\nSélectionner une polyligne: "))))
(setq ent_rec (entget (car ent)))
(cond
	((eq (cdr (assoc 0 ent_rec)) "LWPOLYLINE")
		(setq ptlst (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) ent_rec)))
(print (length ptlst))
		(list
			(list (eval (cons min (mapcar 'car ptlst))) (eval (cons min (mapcar 'cadr ptlst))))
			(list (eval (cons max (mapcar 'car ptlst))) (eval (cons min (mapcar 'cadr ptlst))))
			(list (eval (cons max (mapcar 'car ptlst))) (eval (cons max (mapcar 'cadr ptlst))))
			(list (eval (cons min (mapcar 'car ptlst))) (eval (cons max (mapcar 'cadr ptlst))))
		)
	)
	(T
		(princ "\nEntité non valide!")
	)
)
)
(defun c:titi ( / )
(while (null (setq ent (entsel "\nSélectionner une polyligne: "))))
(setq ent_rec (entget (car ent)))
(cond
	((eq (cdr (assoc 0 ent_rec)) "LWPOLYLINE")
		(setq ptlst (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) ent_rec)))
(print (length ptlst))
		(setq min_pr (caar ptlst) max_pr (cadar ptlst) ptlst (cdr ptlst))
		(repeat (length ptlst)
			(setq 
				min_pr (min (caar ptlst) min_pr)
				max_pr (max (cadar ptlst) max_pr)
				ptlst (cdr ptlst)
			)
		)
		(list min_pr max_pr)
	)
	(T
		(princ "\nEntité non valide!")
	)
)
)

 

[Patrick_35]

Salut,

Tu as bien la fonction gc, mais je n'ai jamais réellement compris à quoi elle servait

 

@+

[didier]

bonsoir

pour répondre à LableTech,

il ne faut pas confondre le LISP ,

de John McCarthy en 1958,

qui a continué à évoluer,

et l'AUTOLISP qui est livré avec AutoCad, (depuis 1986 quand même ...)

il a surement perdu beaucoup de sa réflexivité,

ce qui fait toute sa puissance par ailleurs.

c'est regrettable, je te l'accorde,

mais c'est quand même FANTASTIQUE d'avoir la possibilité de programmer soi même, pour compléter le Logiciel.

le VBA a les mêmes limitations rapport au VB

et on s'en contente.

 

amicalement

 

[didier]

re coucou

et ne pas perdre de vue cet adage :

quand la porte se ferme,

tu pourras toujours entrer par la fenêtre . ;)

visiblement tu l'as trouvée, la fenêtre ;)

amicalement

[Labletech]

Merci à vous pour vos marques de sympathie.

Passer par les fenêtres m'a toujours donné l'impression de passer pour un Arsene Lupin .. c'est de toute façon plus exotique que de passer par les portes !!

Quand je vous ai posé cette question, c'était surtout pour savoir si un petit rusé avait déjà trouvé une astuce quelconque pour maitriser un quelconque pouvoir sur les mémoires lispiennes de notre cher Autocad.

Cette question est venue sur ce forum parcque Autodesk ne semblait pas trop réagir à ma demande. Mais tout arrive à point pour qui sait attendre.

J'avais envoyé ma question à Autodesk, 2 semaines environ avant de vous la poser sur ce forum.

J'ai recu hier mon Numéro d'ID de process d'erreur géré par la société Autodesk et j'ai reçu aujourd'hui la réponse technique. Comme quoi les mails mettent un mois pour franchir l'atlantique dans le sens aller et un jour dans le sens retour !!

J'ai toujours pensé que la terre tournait ... maintenant j'en ai la preuve !! Les mails vont plus vite dans le sens de marche de la terre que dans le sens contraire !!

 

Pour mettre donc un terme à toute incertitude sur ce sujet voilà donc la réponse officielle d'Autodesk pour mon pb:

Your case was escalated to Developer Technical Services by our Product

Support team.

>

> Unfortunately, this is a known problem, and was logged as the following

Change Request:

>

> ID 247791 MIN OR MAX FUNCTIONS LIMITED TO 255 ARGUMENTS

>

> As an alternative, you can use the Visual LISP function (vl-sort), which

does not have this limitation. I modified part of your sample code to

demonstrate this. See below:

>

>

> (defun valmin2 (lv)

> (car (vl-sort lv '<))

> )

Cette fonction Visual-lisp vl-sort remplace donc avantageusement la fonction initiale min. Vu qu'elle peut gérer un nombre d'opérandes bien plus important !!!

Je vois qu'un bon nombre d'entre vous ne connaissent pas plus que moi ces fonctions !!! :casstet:

Je crois que ce serait bien si on pouvait trouver une liste d'équivalence entre les vieilles fonctions Autolisp et les éventuelles nouvelles fonctions Visual-lisp qui les remplacent ... Avis à ceuce qui voudraient s'investir dans une telle recherche !! :cool:

 

 

[didier]

hello

Merci à Toi de nous faire connaître cette réponse.

tu prouves qu'on peut échanger des informations.

c'est le but d'un tel site,

et il remplit en grande partie son rôle.

encore merci à Toi.

très amicalement