return string of newlispEvalStr?

[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 Expand


(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.

[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

[HPW]

Any way to force the return string into the [text]-format even when it is smaller than 2048 bytes?



Something like:

Code Select Expand


>(raw(dup "r"Test" 100))
[text]
"Test
"Test
..
..
"Test
"Test
"Test[/text]


[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 Expand


> (silent (print "AnBnCn"))
A
B
C

Lutz

[HPW]

Then we are back on the memory leak diskussed here:



http://www.alh.net/newlisp/phpbb/viewtopic.php?t=425&highlight=memory+leak">http://www.alh.net/newlisp/phpbb/viewto ... emory+leak">http://www.alh.net/newlisp/phpbb/viewtopic.php?t=425&highlight=memory+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.

[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

[HPW]

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.

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.