READ string too long on input

READ string too long on input

CodeDing
Advisor Advisor
3,940 Views
22 Replies
Message 1 of 23

READ string too long on input

CodeDing
Advisor
Advisor

I'm trying to convert a JSON response to a list which I can then manipulate with AutoLISP.

Normally I can accomplish that with this simple function:

(defun JSON->LIST (json / tmp dbl nwl)
;json - string, as json data
;returns - list or nil, list of data converted from json
(if (eq 'STR (type json)) (read (vl-string-translate "[]{}:," "()()  " json)) nil)
);defun

However, the READ function must have a limit which I cannot directly find. Because when I send the Attached JSON information as a single string to the function, I get this error:

; error: string too long on input

I have tried removing excess spaces and newline characters with:

- (while (vl-string-search "  " str) (setq str (vl-string-subst " " "  ")))

- (while (vl-string-search "\n" str) (setq str (vl-string-subst " " "\n")))

Still no luck. (my shortened string length comes to 37,367 characters).

 

So, I was hoping that I could create any function (perhaps recursive?) that will allow me to merely construct lists on the fly since, in THIS case, I know that I have many 'Lists' inside of my JSON data. Then I could break my 'Reads' into smaller chunks... I just am not able to understand how my workflow should go and I have been racking my brain on this for hours..

 

This isn't a function but hopefully it can help you get an idea of how i'm trying to break this down:

 

Instead of this:
(read "(\"abc\" 123 (\"def\" 456) (\"ghi\" 789) \"jkl\" 000)")
...Do this...
(list "abc" 123 (list "def" 456) (list "ghi" 789) "jkl" 000)

Best,

~DD

0 Likes
Accepted solutions (2)
3,941 Views
22 Replies
Replies (22)
Message 21 of 23

CodeDing
Advisor
Advisor

@Sea-Haven ,

I appreciate your responses, however the read char does not seem most useful here for 2 reasons.

The first, is that I am getting my original string all at once from a browser response text. So there is no file involved.

And second, is that if a file were involved, I do believe that the read-line function would be better suited to that situation. 

Unless you can perhaps provide an example function of read-char outperforming read-line in that instance?

 

I'm open to more solutions, but I need someone to walk the walk, not just talk the talk! And since I've seen you posting to many forums for quite some time now, I'm curious to see what other tricks you might have up your sleeve that I haven't seen yet.

 

 

0 Likes
Message 22 of 23

Sea-Haven
Mentor
Mentor

I think I read to much into the json file rather than a string answer. 😀

0 Likes
Message 23 of 23

martti.halminen
Collaborator
Collaborator

If you decide to try the Common Lisp route, there is more setup work than for some of the other choices, but more room for growth if you need to expand your application.

 

You'd need to set up a full CL environment. For this kind of task any implementation will do; CLISP and Clozure CL are some of the freely available ones that usually work painlessly on Windows (some of the others are better supported on Linux). They are command line tools, but most people working with CL use the Emacs editor with the Slime library to connect them; the result is not as showy as your typical IDE, but hidden inside are hundreds of commands built to help Lisp work (and a few thousand others).

- The file extensions are usually configurable. I use .lsp for AutoLISP and .lisp for CL.

 

You could work with just the development environment, but if your application is intended for several users, it would be better to build a stand-alone application for that.

 

The program would need to acquire its input data (either as a command line parameter or reading from a file in a hardcoded location would be simplest), load the parser library, parse the .json file, do any other post-processing that may be easier on the CL side, and write the results somewhere.

- for anything with a human in the loop, using simple text files for communication is usually fast enough: on my computer AutoLISP can read a file at about 60000 lines per second, CL is faster.

 

Calling the parser varies depending on which library you are using and what your data is; for example in our case it was just 

(cdr
           (jsown:parse
            res
            "Specification"
            "MinSpeed"
            "MaxSpeed"
            "CriticalSpeeds"))

 

Calling your stand-alone application from AutoLISP can be done using STARTAPP as a native function call, or we are using DOSlib:

(dos_exewait path 2)

 

--