I've created a script that generates a large data structure and then writes it out as follows:
...create data...
(save "data.lsp" 'data)
(exit)
When I load data.lsp in a separate newlisp session, however, I get a error and newlisp exits.
This isn't a memory limitation. Although I think a long text string contained in some element of data is generating the error, data itself isn't very large.
Are there any limitations on saving newlisp symbols to a file and reloading them? It seems unlikely that there is some issue with save, but right now that's all I have to go on.
John
I can reproduce the errors I'm getting with a small script. The problem is that a lone "[/text]" loads fine when the entire string is less than 2048 characters but causes 2 different errors for lengths exceeding 2048.
In short, if I save the symbol that evaluates to a long string (> 2048 chars) containing "[/text]" and then reload that file newlisp will generate an error.
The script demonstrating this follows.
newLISP v.10.1.1 on OSX IPv4 UTF-8, execute 'newlisp -h' for more info.
> (silent (set 'p (string (dup "p" 2040) "[/text]")))
> (silent (set 'q (string (dup "q" 2041) "[/text]")))
> (save "p.lsp" 'p)
true
> (save "q.lsp" 'q)
true
> (load "p.lsp")
"pppppp <REMOVED> ppppppppppppppppppppppppppppppp[/text]"
> (load q.lsp")
ERR: string token too long : ")"
> (silent (set 'r (string (dup "r" 10000) "[/text]")))
> (save "r.lsp" 'r)
true
> (load "r.lsp")
ERR: symbol expected in function set : [/text]
>
I've had this problem before too.
"[/text]" is the only string that's not allowed in a string delimited by [text] and [/text]. So when newLISP sees
[text]qqqqqqqqqqqqqqq[/text][/text]
it complains. about the final superfluous [/text]. I got this error when I was processing some blog entries that were including the [text] and [/text] tags as part of the string data. ( I remember having to replace the 'real' ones with [/txt] so that the ones newLISP added were valid, then alter them back when possible.)
I don't know how you could work round this in your case, though.. :(
What I have done in similar situations, is base-64 encode the strings, which containing the offending character sequences using 'base64-enc'.