Re: From Pico to JSON in the client
It worked out OK with the :key rule, however in the end I went for prefuse flare, not processing for my visualizations and was irritated by having to change (processingjs is too slow) so I skipped the Actionscript 3 implementation, I'm just outputting JSON in picolisp now straight away which works just fine too. /Henrik On Wed, Sep 16, 2009 at 9:46 AM, Tomas Hlavaty t...@logand.com wrote: Hi Henrik and TC, I just realized that there is an ambiguity here since I can't seem to accomplish a pair looking like this: (key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the Heh, I think the problem is quite obvious when looking to the list as wh= at it really is: a chain of cons. (key (1 2 3)) - (key . ((1 . (2 . (3 . NIL) that's equivalent to: (key . (1 2 3)) =A0=3D (key (1 2 3)) well, picolisp says that: : '(key . (1 2 3)) - (key 1 2 3) : In any case I can't think of a situation where I would have a string with quotes in it. That seems to me like a serious flaw:-( Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
On Wed, 16 Sep 2009, Tomas Hlavaty wrote: Hi Henrik and TC, I just realized that there is an ambiguity here since I can't seem to accomplish a pair looking like this: (key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the Heh, I think the problem is quite obvious when looking to the list as what it really is: a chain of cons. (key (1 2 3)) - (key . ((1 . (2 . (3 . NIL) that's equivalent to: (key . (1 2 3)) = (key (1 2 3)) Brain farts happen... (key . ((1 2 3))) = (key (1 2 3)) -- This is what I tried to say. well, picolisp says that: : '(key . (1 2 3)) - (key 1 2 3) : I know, I knew this since I sent that email, but since it was only to show _why_ the (Sym . list) was not going to work, it wasn't worth it to send another email fixing this. In any case I can't think of a situation where I would have a string with quotes in it. That seems to me like a serious flaw:-( Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
I've updated the converter now, the current version is more flexible
than earlier and will now also do (:key (1 2 3)) - {key: [1, 2,
3]}.
/Henrik
On Fri, Sep 4, 2009 at 11:10 AM, Henrik Sarvellhsarv...@gmail.com wrote:
Thanks for the idea TC, another alternative would be to give the
parser a bias to lean on as an extra argument but that doesn't feel
100% right. I can't see how :key would create any conflicts either.
/Henrik
On Fri, Sep 4, 2009 at 8:23 AM, Tomas Hlavatyt...@logand.com wrote:
Hi Henrik,
First of all, to offload the server from having to build json all
the time.
your server must be very popular when it struggles to generate json;-)
1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js
2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp.
3) Parsing postscript: function PsParser() in
Another case where I built a parser on top of simple picolisp
functions peek char (i.e. without regular expressions, the picolisp
way:-) is the xml parser now part of picolisp distribution in
lib/xml.l. =A0Basically every picolisp webserver generates html or xml
on the server side so I cannot see how generating json is any
different performance-wise.
Also, your code loops over all characters in the string and calls
regular expression matcher many times. =A0This matching is redundant and
the code can be faster by removing the regexp matcher lookehead and
determining the state directly because sexp have very simple grammar
anyway.
Regards,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
Hi Henrik, First of all, to offload the server from having to build json all the time. your server must be very popular when it struggles to generate json;-) 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js 2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp. 3) Parsing postscript: function PsParser() in Another case where I built a parser on top of simple picolisp functions peek char (i.e. without regular expressions, the picolisp way:-) is the xml parser now part of picolisp distribution in lib/xml.l. Basically every picolisp webserver generates html or xml on the server side so I cannot see how generating json is any different performance-wise. Also, your code loops over all characters in the string and calls regular expression matcher many times. This matching is redundant and the code can be faster by removing the regexp matcher lookehead and determining the state directly because sexp have very simple grammar anyway. Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
Thanks for the idea TC, another alternative would be to give the parser a bias to lean on as an extra argument but that doesn't feel 100% right. I can't see how :key would create any conflicts either. /Henrik On Fri, Sep 4, 2009 at 8:23 AM, Tomas Hlavatyt...@logand.com wrote: Hi Henrik, First of all, to offload the server from having to build json all the time. your server must be very popular when it struggles to generate json;-) 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js 2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp. 3) Parsing postscript: function PsParser() in Another case where I built a parser on top of simple picolisp functions peek char (i.e. without regular expressions, the picolisp way:-) is the xml parser now part of picolisp distribution in lib/xml.l. =A0Basically every picolisp webserver generates html or xml on the server side so I cannot see how generating json is any different performance-wise. Also, your code loops over all characters in the string and calls regular expression matcher many times. =A0This matching is redundant and the code can be faster by removing the regexp matcher lookehead and determining the state directly because sexp have very simple grammar anyway. Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
That's exactly what I'm doing, ie stepping recursively, the regex is just to determine which state to put the parser in. But yes, it looks like I'm going to have to step through in order to determine type too if no regex guru shows up :) /Henrik On Thu, Sep 3, 2009 at 7:51 AM, Alexander Burgera...@software-lab.de wrote: On Thu, Sep 03, 2009 at 02:00:39AM +0200, Henrik Sarvell wrote: http://www.prodevtips.com/2009/09/02/pico-lisp-to-json-with-javascript/ ... two issues but I don't know about the rest of you, any ideas? I believe it is difficult to parse nested Lisp data with static regular expressions (I don't like regular expressions in general, due to their static nature, so I'm also not an expert). Instead, I would use a simple recursive parser (analog to the Lisp reader), which can analyze the expression step by step in a more flexible way. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
Hello, On Thursday 03 September 2009 02:00:39 Henrik Sarvell wrote: Hello everyone, I sat down tonight and ugly coded a Pico to JSON converter in JS, I documented it here: http://www.prodevtips.com/2009/09/02/pico-lisp-to-json-with-javascript/ Pretty nifty idea IMHO :) The part of your regex where you match a quoted string: [^]+ could read [^]* since an empty string is a proper string alright. I don't know if what follows will work with JS's flavor of RegEx, but here goes my stab at it. The bit that matches a quoted string could read: ([^]|[\\])* which says a string is composed of (non-quote character OR backslash-and-quote pair) repeated zero-or-more times. I am not sure if you really need to put the double backslash in brackets, but it should not hurt ;) Yay the first post to the group :) Regards, -- Mateusz Jan Przybylski -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
Thanks Mateusz, I'll try it out. /Henrik On Thu, Sep 3, 2009 at 11:52 AM, Mateusz Jan Przybylskidexen.devr...@gmail.com wrote: Hello, On Thursday 03 September 2009 02:00:39 Henrik Sarvell wrote: Hello everyone, I sat down tonight and ugly coded a Pico to JSON converter in JS, I documented it here: http://www.prodevtips.com/2009/09/02/pico-lisp-to-json-with-javascript/ Pretty nifty idea IMHO :) The part of your regex where you match a quoted string: [^]+ could read [^]* since an empty string is a proper string alright. I don't know if what follows will work with JS's flavor of RegEx, but here goes my stab at it. The bit that matches a quoted string could read: ([^]|[\\])* which says a string is composed of (non-quote character OR backslash-and-quote pair) repeated zero-or-more times. I am not sure if you really need to put the double backslash in brackets, but it should not hurt ;) Yay the first post to the group :) Regards, -- Mateusz Jan Przybylski -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
First of all, to offload the server from having to build json all the time. For me the real issue is not speed in the client, given that premise I simply took a wild guess that building the json and then evaluating it is a simpler road to take than actually building the composite objects right away. For me it doesn't matter if the result is even ten times slower as long as I can do as simple a solution as possible, people sit on such powerful machines anyway. Anyway, I've fixed things, incorporating Mateusz changes. However it wouldn't work with recognizing single pairs/objects so quotes inside keys are still a no no. This is hair splitting though, I don't even know if they are legal in the keys. In any case I can't think of a situation where I would have a string with quotes in it. I've updated the article, looks like it's working, the string evaluates OK and we can access values in the resulting object/array. /Henrik On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavatyt...@logand.com wrote: Hi Henrik, That's exactly what I'm doing, ie stepping recursively, the regex is just to determine which state to put the parser in. But yes, it looks like I'm going to have to step through in order to determine type too if no regex guru shows up :) as Alex suggests, regular expressions in this context are overkill. Instead, I would use a simple recursive parser (analog to the Lisp reader), which can analyze the expression step by step in a more flexible way. Yes. You can simulate peek, char, skip etc. functions in javascript closures and write a recursive parser. =A0I have done this in three cases: 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js =A0 is not complete (dot notation is missing) and needs some =A0 improvements based on the lesson learned from the postscript parser =A0 bellow. =A0 OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely =A0 for communication between client and server. =A0Ideally, I would like =A0 to replace javascript by client-side picolisp (implemented in =A0 javascript) completely. =A0I think it is feasible and could be =A0 efficient enough. =A0Imagine having persistent symbols/objects =A0 directly accesible in your client-side picolisp application;-) 2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp. 3) Parsing postscript: function PsParser() in =A0 http://logand.com/sw/wps/wps.js =A0 WPS http://logand.com/sw/wps/index.html proved to me that =A0 implementing interpreters in javascript is reasonably efficient =A0 although not great for coding things in a tight loop (which is =A0 usually quite little code and could be implemented directly in =A0 javascript, similarly to picolisp falling back to C). I am not sure, why would you need to build json on the client side this way unless you send it to some 3rd party. =A0Json as such is a data transfer format and I guess I need the real objects on the client side and not yet another representation of them. Regards, Tomas -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
I just realized that there is an ambiguity here since I can't seem to
accomplish a pair looking like this:
(key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the
first one is really impossible then any JSON converter will stumble on
it since it's impossible to know if [key, [1, 2, 3]] or {key: [1,
2, 3]} is the desired result.
/Henrik
On Thu, Sep 3, 2009 at 11:20 PM, Henrik Sarvellhsarv...@gmail.com wrote:
First of all, to offload the server from having to build json all the tim=
e.
For me the real issue is not speed in the client, given that premise I
simply took a wild guess that building the json and then evaluating it
is a simpler road to take than actually building the composite objects
right away. For me it doesn't matter if the result is even ten times
slower as long as I can do as simple a solution as possible, people
sit on such powerful machines anyway.
Anyway, I've fixed things, incorporating Mateusz changes. However it
wouldn't work with recognizing single pairs/objects so quotes inside
keys are still a no no. This is hair splitting though, I don't even
know if they are legal in the keys. In any case I can't think of a
situation where I would have a string with quotes in it.
I've updated the article, looks like it's working, the string
evaluates OK and we can access values in the resulting object/array.
/Henrik
On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavatyt...@logand.com wrote:
Hi Henrik,
That's exactly what I'm doing, ie stepping recursively, the regex is
just to determine which state to put the parser in. But yes, it looks
like I'm going to have to step through in order to determine type too
if no regex guru shows up :)
as Alex suggests, regular expressions in this context are overkill.
Instead, I would use a simple recursive parser (analog to the Lisp
reader), which can analyze the expression step by step in a more
flexible way.
Yes. You can simulate peek, char, skip etc. functions in javascript
closures and write a recursive parser. =A0I have done this in three
cases:
1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js
=A0 is not complete (dot notation is missing) and needs some
=A0 improvements based on the lesson learned from the postscript parser
=A0 bellow.
=A0 OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely
=A0 for communication between client and server. =A0Ideally, I would lik=
e
=A0 to replace javascript by client-side picolisp (implemented in
=A0 javascript) completely. =A0I think it is feasible and could be
=A0 efficient enough. =A0Imagine having persistent symbols/objects
=A0 directly accesible in your client-side picolisp application;-)
2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp.
3) Parsing postscript: function PsParser() in
=A0 http://logand.com/sw/wps/wps.js
=A0 WPS http://logand.com/sw/wps/index.html proved to me that
=A0 implementing interpreters in javascript is reasonably efficient
=A0 although not great for coding things in a tight loop (which is
=A0 usually quite little code and could be implemented directly in
=A0 javascript, similarly to picolisp falling back to C).
I am not sure, why would you need to build json on the client side
this way unless you send it to some 3rd party. =A0Json as such is a data
transfer format and I guess I need the real objects on the client side
and not yet another representation of them.
Regards,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: From Pico to JSON in the client
On Fri, 4 Sep 2009, Henrik Sarvell wrote:
I just realized that there is an ambiguity here since I can't seem to
accomplish a pair looking like this:
(key . (1 2 3)), no matter how I try I get: (key (1 2 3)), if the
Heh, I think the problem is quite obvious when looking to the list as what
it really is: a chain of cons.
(key (1 2 3)) - (key . ((1 . (2 . (3 . NIL)
that's equivalent to:
(key . (1 2 3)) = (key (1 2 3))
first one is really impossible then any JSON converter will stumble on
it since it's impossible to know if [key, [1, 2, 3]] or {key: [1,
2, 3]} is the desired result.
What if:
(key (1 2 3)) - [key, [1, 2, 3]]
(:key (1 2 3)) - {key: [1, 2, 3]}
(I suggest the ':' to be put at the beginning of the key-word for conventions'
sake.)
On Thu, Sep 3, 2009 at 11:20 PM, Henrik Sarvellhsarv...@gmail.com wrote:
First of all, to offload the server from having to build json all the tim=
e.
For me the real issue is not speed in the client, given that premise I
simply took a wild guess that building the json and then evaluating it
is a simpler road to take than actually building the composite objects
right away. For me it doesn't matter if the result is even ten times
slower as long as I can do as simple a solution as possible, people
sit on such powerful machines anyway.
Anyway, I've fixed things, incorporating Mateusz changes. However it
wouldn't work with recognizing single pairs/objects so quotes inside
keys are still a no no. This is hair splitting though, I don't even
know if they are legal in the keys. In any case I can't think of a
situation where I would have a string with quotes in it.
I've updated the article, looks like it's working, the string
evaluates OK and we can access values in the resulting object/array.
/Henrik
On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavatyt...@logand.com wrote:
Hi Henrik,
That's exactly what I'm doing, ie stepping recursively, the regex is
just to determine which state to put the parser in. But yes, it looks
like I'm going to have to step through in order to determine type too
if no regex guru shows up :)
as Alex suggests, regular expressions in this context are overkill.
Instead, I would use a simple recursive parser (analog to the Lisp
reader), which can analyze the expression step by step in a more
flexible way.
Yes. You can simulate peek, char, skip etc. functions in javascript
closures and write a recursive parser. =A0I have done this in three
cases:
1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js
=A0 is not complete (dot notation is missing) and needs some
=A0 improvements based on the lesson learned from the postscript parser
=A0 bellow.
=A0 OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely
=A0 for communication between client and server. =A0Ideally, I would lik=
e
=A0 to replace javascript by client-side picolisp (implemented in
=A0 javascript) completely. =A0I think it is feasible and could be
=A0 efficient enough. =A0Imagine having persistent symbols/objects
=A0 directly accesible in your client-side picolisp application;-)
2) Parsing PDFs in OnDoc: works surprisingly well fast in picolisp.
3) Parsing postscript: function PsParser() in
=A0 http://logand.com/sw/wps/wps.js
=A0 WPS http://logand.com/sw/wps/index.html proved to me that
=A0 implementing interpreters in javascript is reasonably efficient
=A0 although not great for coding things in a tight loop (which is
=A0 usually quite little code and could be implemented directly in
=A0 javascript, similarly to picolisp falling back to C).
I am not sure, why would you need to build json on the client side
this way unless you send it to some 3rd party. =A0Json as such is a data
transfer format and I guess I need the real objects on the client side
and not yet another representation of them.
Regards,
Tomas
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
