Page 1 of 1
return string of newlispEvalStr?
Posted: Thu Dec 29, 2005 11:14 pm
by HPW
I think I have a bug in my plugin on processing the return-string of newlispEvalStr.
When I call newlispEvalStr in newLISp.DLL and a string is returned it is either packed into double quotes:
"........."LF
or when more than 2048 bytes:
[text].......[/text]LF
But what I did not understand right is that the quoted return-string does contain escape-characters and the [text]-string does not.
Is that right?
Try:
Code: Select all
(dup {"Test} 100)
(dup {"Test} 1000)
(dup "\r\"Test" 100)
(dup "\r\"Test" 1000)
If so I have to correct some post processing I do on the string when returning it to neobook.
Posted: Fri Dec 30, 2005 12:42 am
by Lutz
That is correct, strings limited by [text], [/text] tags are in raw form and special characters are not escaped.
The [text], [/text] tags have a double purpose: allow strings with length > 2048 and allow embedding raw text, like HTML into newLISP programs.
Lutz
Posted: Fri Dec 30, 2005 7:58 am
by HPW
Any way to force the return string into the [text]-format even when it is smaller than 2048 bytes?
Something like:
Code: Select all
>(raw(dup "\r\"Test" 100))
[text]
"Test
"Test
..
..
"Test
"Test
"Test[/text]
Posted: Fri Dec 30, 2005 2:06 pm
by Lutz
You could use 'silent' on the return expression to suppress the output and then use 'print' or 'println' to get the raw ASCII:
Code: Select all
> (silent (print "A\nB\nC\n"))
A
B
C
Lutz
Posted: Fri Dec 30, 2005 6:12 pm
by HPW
Then we are back on the memory leak diskussed here:
http://www.alh.net/newlisp/phpbb/viewto ... emory+leak
My idea was to use the code which is used for strings > 2048 with the [text] tag, could be used on shorter strings on demand.
Posted: Fri Dec 30, 2005 6:37 pm
by Lutz
I wonder when MS will fix this, if ever. What you could do is check for [text] at the beginning and if not there do the translation of \n \r \t and \nnn characters yourself.
Another possibility would be to partition the strings server side and pieces less then 2048 characters.
Yet another possibility would to always append 2048 spaces at the end before returning. This way guaranteeing always the tags. The beginning of the string could encode the 'real' length, so it could be trimmed on the NeoBook receiving side.
Lutz
Posted: Fri Dec 30, 2005 9:59 pm
by HPW
Lutz wrote:I wonder when MS will fix this, if ever.
I think never. Since they are building on new fundament .NET they only work/fix for that OS.
Lutz wrote:What you could do is check for [text] at the beginning and if not there do the translation of \n \r \t and \nnn characters yourself.
That is what I am doing now in plugin V2.10 from yesterday.