call stack overflow in function list:

[HPW]

I have a huge lisp table and want to read it.

Here 2 sample rows:

Code Select Expand


(setq CADT_WOINT_ARTBEZTAB
(list
(list "A0002" "Test1" "PRO-MEH" (CADT_MBI_MDEF_LISP "A0002") "100100" nil "S" "0")
(list "A0010" "Test2" "PRO-ELK" (CADT_MBI_MDEF_LISP "A0010") "102401" nil "S" "1")
...
)
)
)


But in row 2048 I get an:

call stack overflow in function list : (lambda (artnr) artnr)



I have the following dummy function:

Code Select Expand


(define (CADT_MBI_MDEF_LISP artnr)
artnr)


The return-string should be the member of the loaded list.

In real it is a more complex function.



Is there a limit in list-length?

I know the hint to emulate large list as symbol-table within a namespace, but I have to load them first to convert them. My current list is about 6000.

[Lutz]

There is no limit to a length of a list, but there is a limit in the number of arguments the function 'list' can take and I can easily change that for the next version.



I wonder if meanwhile you can do:

Code Select Expand


(setq CADT_WOINT_ARTBEZTAB '(
("A0002" "Test1" "PRO-MEH" (CADT_MBI_MDEF_LISP "A0002") "100100" nil "S" "0")
("A0010" "Test2" "PRO-ELK" (CADT_MBI_MDEF_LISP "A0010") "102401" nil "S" "1")
(...)
(...)
))


This assumes of course that all that info is static, and I am not sure if this is the case, or if

" (CADT_MBI_MDEF_LISP "A0002") " is a function which has to be evaluated, then of course you would need 'list' so all elements in the list are evaluated first.



Lutz

[HPW]

>if " (CADT_MBI_MDEF_LISP "A0002") " is a function which has to be evaluated,

>then of course you would need 'list' so all elements in the list are evaluated first.



Yes in the moment it has to be evaluated. It is on the alisp-side where I load it at different times where the function return different strings at load-time. I could change the source with a additional converting step before I import it into newlisp. But it would be easier to be able to do it in newlisp.





And when it is easy and has no negativ effekt elsewhere do it.

So how big could you make the number of possible arguments?

[Lutz]

I changed it already in 7.3.4, which goes up in about 2 hours (still working on some doc corrections from Kazemori) There is no limit now, whatever fits in memory. There never should have been a limit, it was just an oversight in the code, fogetting to clear one of the stacks after each evaluation.



Lutz

[HPW]

Good to hear. That way is the best possible.

Thanks for the quick fix.

[HPW]

From the 7.3.4:



>list now accepts an unlimited number of arguments



Does it only means 'list. What is with commands like 'set/'setq?

Does they accept unlimited numbers of arguments?