How Saving Works

Started by johnd, October 03, 2009, 09:10:00 PM

Previous topic - Next topic

johnd

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

johnd

#1
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]

>

cormullion

#2
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.. :(

Lutz

#3
What I have done in similar situations, is base-64 encode the strings, which containing the offending character sequences using 'base64-enc'.