Re: app builder from JSON
Hello,Sure it is possible, even without hard string manipulations, which would be required in common languages to codegen. But PicoLisp is homoiconic so you are able to construct your program with plain list manipulations. Just how Lisp was intended to use from the start :)Best regards, NailSent from my BlackBerry — the most secure mobile device From: bpsun...@gmail.comSent: 22 May 2019 10:23To: picolisp@software-lab.deReply to: picolisp@software-lab.deSubject: app builder from JSON hello,i have a question to pose to this group, lets assume that I have a JSON schema with TAB layout given by the end user,{"tab1": "name": {"type": "string", "length": "25"},"contact": {"type" : "number", "length": "10"}},{"tab2":"address": {"street_address" : {"line1": {"type": "string", "length": "25"},"line2": {"type": "string", "length": "25"}},"city" : {"type": "string", "length": "15"},"zipcode" : {"type": "number", "length": "10"}}is it possible to build a automated picolisp application from this? including ui? instead of hard coding.regards,sundar.
app builder from JSON
hello,
i have a question to pose to this group, lets assume that I have a JSON
schema with TAB layout given by the end user,
{"tab1":
"name": {"type": "string", "length": "25"},
"contact": {"type" : "number", "length": "10"}
},
{"tab2":
"address": {
"street_address" : {
"line1": {"type": "string", "length": "25"},
"line2": {"type": "string", "length": "25"}
},
"city" : {"type": "string", "length": "15"},
"zipcode" : {"type": "number", "length": "10"}
}
is it possible to build a *automated* picolisp application from this?
including ui? instead of hard coding.
regards,
sundar.
Re: Review request for my JSON parsing implementation
Hey Alex,
Since json.l is available in standard library, I'd prefer to use it :)
Regards,
Kashyap
On Thu, May 9, 2019 at 1:08 AM Alexander Williams
wrote:
> If you're just trying to work with the decimal numbers in PicoLisp, then
> why not just use fixed-point?
>
> You can modify my json.l and specify a 20 digit decimal, and then parse
> your file. The result will be strings instead of numbers, but it works
> fine. Here's a
> patch:
>
>
> diff --git a/json.l b/json.l
> index 551e3a9..a135c39 100644
> --- a/json.l
> +++ b/json.l
> @@ -6,6 +6,8 @@
>
> (setq *Json_control_characters (extract '((N) (unless (member N '("^H"
> "^L" "^J" "^M" "^I")) N)) (mapcar char (range 1 31
>
> +(scl 20)
> +
> # send error message to STDERR
> [de json-err-throw (Error)
> (msg Error)
> @@ -112,7 +114,7 @@
> ((= "[" Type) (make (link T) (json-link-array)))
> ((= "{" Type) (make (json-link-object)))
> ((lst? Type) (pack Type))
> - ((num? Type) Type)
> + ((num? Type) (format Type *Scl))
> ((= "-" Type) (if (num? (car *Json)) (format (pack "-" (pop
> '*Json))) (json-iterate-object)))
> ((= 'true Type) 'true)
> ((= 'false Type) 'false)
>
>
> -- Try that against my latest git commit to
> https://github.com/aw/picolisp-json (tag v4.0.0)
>
>
> AW
>
> On Wed, 8 May 2019, C K Kashyap wrote:
>
> > Perfect - It is pure bliss to see such concise code.
> > Regards,
> > Kashyap
> >
> > On Wed, May 8, 2019 at 6:59 AM Alexander Burger
> wrote:
> >
> >> On Wed, May 08, 2019 at 09:17:54AM +0200, Alexander Burger wrote:
> >>> Yes, "123.0.0" is not a legal number.
> >>>> I am sure there must a better way to do the lengthy "0"..."9" that
> I've
> >>>> done :)
> >>
> >> The best is to avoid at all looping over the characters, because
> built-ins
> >> are a
> >> lot faster than individual function calls in a loop.
> >>
> >> What I would do here is
> >>
> >>(pipe
> >> (in '("curl" "-s" "
> >> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> >> (while
> >> (prin
> >>(echo "close" "volume" "unadjustedVolume") )
> >> (when (prin (till "," "}"))
> >>(or (sub? "." @) (prin ".")) ) ) )
> >> (readJson) )
> >>
> >> The trick is to read the digits with 'till', print them, and *then*
> check
> >> if a
> >> dot is needed.
> >>
> >> ☺/ A!ex
> >>
> >> --
> >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >>
> >
Re: Review request for my JSON parsing implementation
On Fri, May 10, 2019 at 07:19:06AM -0700, C K Kashyap wrote: > Interestingly sub? also seems to work like member? Ah, right. I forgot. 'sub?' is rather tolerant, it accepts also non-symbolic values and converts them silently to transients ;) > member? is clearly the appropriate one. Yes, and has no such conversion overhead. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Thanks Alex,
"apply" is what I was looking for :)
Interestingly sub? also seems to work like member? for list of chars - but
member? is clearly the appropriate one. I think trim is required because
this is valid {"K1": 10 , "K2": 20}
Regarding the download logic - the idea is to cache the output and fetch
only if the cache does not exist or "Online" (Onl) is True. But I agree
that it does conflate ideas.
Regards,
Kashyap
On Thu, May 9, 2019 at 11:06 PM Alexander Burger
wrote:
> On Fri, May 10, 2019 at 07:38:22AM +0200, Alexander Burger wrote:
> >(de getJson (Spl File Url Oln)
> > (when (or Oln (not (info File)))
> > (wget Url) )
> > (pipe
> > (in File
>
> I think this whole construct is not wise. What if the file fetched with
> 'wget'
> has a different name?
>
> Perhaps separate this logic from this function? And why store it in a file
> at
> all, instead of directly reading from the pipe?
>
> You could analyze the file, and if it looks like an URL then
> fetch it:
>
>(de getJson (Spl File)
> (pipe
> (in
> (if (or (pre? "http://"; File) (pre? "https://"; File))
>(list "curl" "-s" File)
>File ) )
> (while (prin (apply echo Spl))
>
>
> ☺! A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Fri, May 10, 2019 at 07:38:22AM +0200, Alexander Burger wrote: >(de getJson (Spl File Url Oln) > (when (or Oln (not (info File))) > (wget Url) ) > (pipe > (in File I think this whole construct is not wise. What if the file fetched with 'wget' has a different name? Perhaps separate this logic from this function? And why store it in a file at all, instead of directly reading from the pipe? You could analyze the file, and if it looks like an URL then fetch it: (de getJson (Spl File) (pipe (in (if (or (pre? "http://"; File) (pre? "https://"; File)) (list "curl" "-s" File) File ) ) (while (prin (apply echo Spl)) ☺! A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
On Thu, May 09, 2019 at 03:39:32PM -0700, C K Kashyap wrote: > (de getJson (Spl File Url Oln) > (unless (info File) (on Oln)) > (when Oln (out File (wget Url))) > (pipe >(in File > (while >(prin > (run (list (cons 'echo Spl >(when (till (list "," "}")) > (ifn (sub? "." @) (prin (pack (trim (chop @))) ".0") (prin > @) > (readJson))) > > The question I have is about the way I've used the "Spl" parameter to > accept a list of special words to look for in the call to echo. Is this the > right approach? Building a new list is not the best. You can evaluate it directly with 'apply'. I would also do some other minor tunings, let me suggest this: (de getJson (Spl File Url Oln) (when (or Oln (not (info File))) (wget Url) ) (pipe (in File (while (prin (apply echo Spl)) (unless (member "." (prin (trim (till "," "}" (prin ".") ) ) ) (readJson) ) ) Is the 'trim' needed? In any case I see that my last proposal using 'sub?' was wrong, but I would avoid the 'pack' and use 'member' instead. Instead of appending ".0", a single dot should suffice, as "123." will be read as a fixpoint number. Again, I have not tested - please forgive any errors ;) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
I am not sure if I should start a new thread for this question - but since
it's building off of reading json, I decided to continue this thread :)
(de getJson (Spl File Url Oln)
(unless (info File) (on Oln))
(when Oln (out File (wget Url)))
(pipe
(in File
(while
(prin
(run (list (cons 'echo Spl
(when (till (list "," "}"))
(ifn (sub? "." @) (prin (pack (trim (chop @))) ".0") (prin
@)
(readJson)))
The question I have is about the way I've used the "Spl" parameter to
accept a list of special words to look for in the call to echo. Is this the
right approach?
On Wed, May 8, 2019 at 7:25 AM C K Kashyap wrote:
> Perfect - It is pure bliss to see such concise code.
> Regards,
> Kashyap
>
> On Wed, May 8, 2019 at 6:59 AM Alexander Burger
> wrote:
>
>> On Wed, May 08, 2019 at 09:17:54AM +0200, Alexander Burger wrote:
>> > Yes, "123.0.0" is not a legal number.
>> > > I am sure there must a better way to do the lengthy "0"..."9" that
>> I've
>> > > done :)
>>
>> The best is to avoid at all looping over the characters, because
>> built-ins are a
>> lot faster than individual function calls in a loop.
>>
>> What I would do here is
>>
>>(pipe
>> (in '("curl" "-s" "
>> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
>> (while
>> (prin
>>(echo "close" "volume" "unadjustedVolume") )
>> (when (prin (till "," "}"))
>>(or (sub? "." @) (prin ".")) ) ) )
>> (readJson) )
>>
>> The trick is to read the digits with 'till', print them, and *then* check
>> if a
>> dot is needed.
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
Re: Review request for my JSON parsing implementation
If you're just trying to work with the decimal numbers in PicoLisp, then
why not just use fixed-point?
You can modify my json.l and specify a 20 digit decimal, and then parse
your file. The result will be strings instead of numbers, but it works fine. Here's a
patch:
diff --git a/json.l b/json.l
index 551e3a9..a135c39 100644
--- a/json.l
+++ b/json.l
@@ -6,6 +6,8 @@
(setq *Json_control_characters (extract '((N) (unless (member N '("^H"
"^L" "^J" "^M" "^I")) N)) (mapcar char (range 1 31
+(scl 20)
+
# send error message to STDERR
[de json-err-throw (Error)
(msg Error)
@@ -112,7 +114,7 @@
((= "[" Type) (make (link T) (json-link-array)))
((= "{" Type) (make (json-link-object)))
((lst? Type) (pack Type))
- ((num? Type) Type)
+ ((num? Type) (format Type *Scl))
((= "-" Type) (if (num? (car *Json)) (format (pack "-" (pop
'*Json))) (json-iterate-object)))
((= 'true Type) 'true)
((= 'false Type) 'false)
-- Try that against my latest git commit to
https://github.com/aw/picolisp-json (tag v4.0.0)
AW
On Wed, 8 May 2019, C K Kashyap wrote:
Perfect - It is pure bliss to see such concise code.
Regards,
Kashyap
On Wed, May 8, 2019 at 6:59 AM Alexander Burger wrote:
On Wed, May 08, 2019 at 09:17:54AM +0200, Alexander Burger wrote:
Yes, "123.0.0" is not a legal number.
I am sure there must a better way to do the lengthy "0"..."9" that I've
done :)
The best is to avoid at all looping over the characters, because built-ins
are a
lot faster than individual function calls in a loop.
What I would do here is
(pipe
(in '("curl" "-s" "
https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(while
(prin
(echo "close" "volume" "unadjustedVolume") )
(when (prin (till "," "}"))
(or (sub? "." @) (prin ".")) ) ) )
(readJson) )
The trick is to read the digits with 'till', print them, and *then* check
if a
dot is needed.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Perfect - It is pure bliss to see such concise code.
Regards,
Kashyap
On Wed, May 8, 2019 at 6:59 AM Alexander Burger wrote:
> On Wed, May 08, 2019 at 09:17:54AM +0200, Alexander Burger wrote:
> > Yes, "123.0.0" is not a legal number.
> > > I am sure there must a better way to do the lengthy "0"..."9" that I've
> > > done :)
>
> The best is to avoid at all looping over the characters, because built-ins
> are a
> lot faster than individual function calls in a loop.
>
> What I would do here is
>
>(pipe
> (in '("curl" "-s" "
> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> (while
> (prin
>(echo "close" "volume" "unadjustedVolume") )
> (when (prin (till "," "}"))
>(or (sub? "." @) (prin ".")) ) ) )
> (readJson) )
>
> The trick is to read the digits with 'till', print them, and *then* check
> if a
> dot is needed.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Wed, May 08, 2019 at 09:17:54AM +0200, Alexander Burger wrote:
> Yes, "123.0.0" is not a legal number.
> > I am sure there must a better way to do the lengthy "0"..."9" that I've
> > done :)
The best is to avoid at all looping over the characters, because built-ins are a
lot faster than individual function calls in a loop.
What I would do here is
(pipe
(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(while
(prin
(echo "close" "volume" "unadjustedVolume") )
(when (prin (till "," "}"))
(or (sub? "." @) (prin ".")) ) ) )
(readJson) )
The trick is to read the digits with 'till', print them, and *then* check if a
dot is needed.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
On Tue, May 07, 2019 at 05:26:57PM -0700, C K Kashyap wrote:
> I ended up making the code less pretty. Looks like the suffix ".0" must
> only be added if the number is not already in floating point format.
Yes, "123.0.0" is not a legal number.
> (setq J
> (pipe
>(in '("sh" "-c" "curl -s
> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> (while
> (case (echo "close" "volume" "unadjustedVolume")
> (("close" "volume" "unadjustedVolume")
> (prin @)
> (prin (echo "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"))
> (setq Sfx ".0")
> (while (member (peek) (list "0" "1" "2" "3" "4" "5" "6" "7" "8" >
> "9" "."))
> (if (= "." (peek)) (setq Sfx ""))
> (prin (char)))
> (prin Sfx)
> T)
>)))
>
> I am sure there must a better way to do the lengthy "0"..."9" that I've
> done :)
You could check
(while (or (>= "9" (peek) "0") (= "." (peek)))
but that is not better.
I would go with
(while (sub? (peek) ".0123456739")
Note that 'Sfx' is not bound locally. Either
(use Sfx
(while
(case ...
...
(setq Sfx ...
or
(let Sfx ".0"
...
Side note: (setq Sfx "") could be (off Sfx)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
I ended up making the code less pretty. Looks like the suffix ".0" must
only be added if the number is not already in floating point format.
(setq J
(pipe
(in '("sh" "-c" "curl -s
https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(while
(case (echo "close" "volume" "unadjustedVolume")
(("close" "volume" "unadjustedVolume")
(prin @)
(prin (echo "0" "1" "2" "3" "4" "5" "6" "7" "8" "9"))
(setq Sfx ".0")
(while (member (peek) (list "0" "1" "2" "3" "4" "5" "6" "7" "8"
"9" "."))
(if (= "." (peek)) (setq Sfx ""))
(prin (char)))
(prin Sfx)
T)
)))
I am sure there must a better way to do the lengthy "0"..."9" that I've
done :)
Regards,
Kashyap
On Tue, May 7, 2019 at 9:33 AM wrote:
> > You would also include "[" in the 'echo' arguments, then check it with
> >
> >(use S
> > (while
> > (prin
> > (setq S
> >(echo "[" "volume" "unadjustedVolume") ) )
> > (if (= "[" S)
> > (... step through the elements ...)
> > (echo ",")
> > (prin ".0,") ) )
> >
>
> I usually use
> (case (echo "[" "volume" "unadjustedVolume")
> ("["
> ...)
> (("volume" "unadjustedVolume")
> (echo ",")
> (prin ".0,") )
> (NIL
> ... handle error case, if you like ...)
> (T
> ... general else case ) )
>
> No additional variable needed, and one can have readable code even when
> handling many cases.
> Easy to additionally handle NIL returned from (echo) - probably doesn't
> matter (too unlikely) when processing a file, but probably handy when
> processing a input stream from network (e.g. curl).
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
You would also include "[" in the 'echo' arguments, then check it with
(use S
(while
(prin
(setq S
(echo "[" "volume" "unadjustedVolume") ) )
(if (= "[" S)
(... step through the elements ...)
(echo ",")
(prin ".0,") ) )
I usually use
(case (echo "[" "volume" "unadjustedVolume")
("["
...)
(("volume" "unadjustedVolume")
(echo ",")
(prin ".0,") )
(NIL
... handle error case, if you like ...)
(T
... general else case ) )
No additional variable needed, and one can have readable code even when
handling many cases.
Easy to additionally handle NIL returned from (echo) - probably doesn't
matter (too unlikely) when processing a file, but probably handy when
processing a input stream from network (e.g. curl).
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Oh yes ... I can see how that would work!!! ... thanks Alex. echo seems like a nice function - I don't think I've seen it anywhere before :) (I mean, I've seen echo that's equivalent of printf ... but not this) Regards, Kashyap On Tue, May 7, 2019 at 8:49 AM Alexander Burger wrote: > On Tue, May 07, 2019 at 08:13:32AM -0700, C K Kashyap wrote: > > Actually my point about array was to read the numbers in the array as > fixed > > points decimals :) - 1, 2.0,3 -> with correct scaling. > > Ah, ok, this must be handled separately. > > You would also include "[" in the 'echo' arguments, then check it with > >(use S > (while > (prin > (setq S >(echo "[" "volume" "unadjustedVolume") ) ) > (if (= "[" S) > (... step through the elements ...) > (echo ",") > (prin ".0,") ) ) > > So the tricky part here is to step through the array elements. This can be > done > with 'echo'es again, or perhaps 'peek', 'char' etc. as you know from > @lib/xm.l > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Review request for my JSON parsing implementation
On Tue, May 07, 2019 at 08:13:32AM -0700, C K Kashyap wrote: > Actually my point about array was to read the numbers in the array as fixed > points decimals :) - 1, 2.0,3 -> with correct scaling. Ah, ok, this must be handled separately. You would also include "[" in the 'echo' arguments, then check it with (use S (while (prin (setq S (echo "[" "volume" "unadjustedVolume") ) ) (if (= "[" S) (... step through the elements ...) (echo ",") (prin ".0,") ) ) So the tricky part here is to step through the array elements. This can be done with 'echo'es again, or perhaps 'peek', 'char' etc. as you know from @lib/xm.l ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
(and (echo "," "}") (prin ".0" @) is so cool!
Actually my point about array was to read the numbers in the array as fixed
points decimals :) - 1, 2.0,3 -> with correct scaling.
Regards,
Kashyap
On Tue, May 7, 2019 at 8:05 AM Alexander Burger wrote:
> On Tue, May 07, 2019 at 06:30:15AM -0700, C K Kashyap wrote:
> > 1. use (echo "\"volume\"") - this way any "volume" inside a string will
> not
> > be confused
>
> Yes, or even better include the colon "\"volume\":".
>
>
> > 2. use (echo "," "}") so that it works with values that are the last
> entry
> > in the dictionary
>
> Right! Then remember it locally to output again.
>
> Instead of
>
>(echo ",")
> (prin ".0,")
>
> you can do
>
>(and (echo "," "}") (prin ".0" @)
>
> As a benefit, this also handles the case when no comma or brace is found
> (though
> it would be illegal Json then).
>
>
> > I feel that I may be pushing it - but is there some way I could deal with
> > an array too - {"somekey": [1, 2.0, 3]} :)
>
> 'readJson' handles arrays. It returns them as lists naturally. If you want
> to
> keep the info that it was an array, pass T to 'readJson', it will then
> mark the
> list with a T in the first element.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Tue, May 07, 2019 at 06:30:15AM -0700, C K Kashyap wrote:
> 1. use (echo "\"volume\"") - this way any "volume" inside a string will not
> be confused
Yes, or even better include the colon "\"volume\":".
> 2. use (echo "," "}") so that it works with values that are the last entry
> in the dictionary
Right! Then remember it locally to output again.
Instead of
(echo ",")
(prin ".0,")
you can do
(and (echo "," "}") (prin ".0" @)
As a benefit, this also handles the case when no comma or brace is found (though
it would be illegal Json then).
> I feel that I may be pushing it - but is there some way I could deal with
> an array too - {"somekey": [1, 2.0, 3]} :)
'readJson' handles arrays. It returns them as lists naturally. If you want to
keep the info that it was an array, pass T to 'readJson', it will then mark the
list with a T in the first element.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Yeah ... and each line is lot fewer than 80 characters :)
just to confirm that I got it - I believe that a couple of changes are
needed to make it work better -
1. use (echo "\"volume\"") - this way any "volume" inside a string will not
be confused
2. use (echo "," "}") so that it works with values that are the last entry
in the dictionary
I feel that I may be pushing it - but is there some way I could deal with
an array too - {"somekey": [1, 2.0, 3]} :)
Regards,
Kashyap
On Tue, May 7, 2019 at 3:45 AM Guido Stepken wrote:
> Some also call it "REST" and have written mighty libraries in other
> languages.
>
> In PicoLisp it's a 5 - liner! ;-)
>
> Alexander Burger schrieb am Di., 7. Mai 2019, 07:04:
>
>> On Mon, May 06, 2019 at 02:06:56PM -0700, C K Kashyap wrote:
>> > My mind is blown - yet again. I love it just looking at it. I'll have to
>> > look a little more to see what's going on.
>> >
>> > How do I capture the output though - I mean this does not capture the
>> > output in J
>>
>> I used 'pretty' in the example to view the result.
>>
>> You can directly 'setq' it or use it in whatever way of course.
>>
>>(let J
>> (pipe
>> (in '("curl" "-s" "
>> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
>> (while
>>(prin
>> (echo "volume" "unadjustedVolume") )
>>(echo ",")
>>(prin ".0,") ) )
>> (readJson) )
>>
>> (doSomething J)
>> ... )
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
Re: Review request for my JSON parsing implementation
Some also call it "REST" and have written mighty libraries in other
languages.
In PicoLisp it's a 5 - liner! ;-)
Alexander Burger schrieb am Di., 7. Mai 2019, 07:04:
> On Mon, May 06, 2019 at 02:06:56PM -0700, C K Kashyap wrote:
> > My mind is blown - yet again. I love it just looking at it. I'll have to
> > look a little more to see what's going on.
> >
> > How do I capture the output though - I mean this does not capture the
> > output in J
>
> I used 'pretty' in the example to view the result.
>
> You can directly 'setq' it or use it in whatever way of course.
>
>(let J
> (pipe
> (in '("curl" "-s" "
> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> (while
>(prin
> (echo "volume" "unadjustedVolume") )
>(echo ",")
>(prin ".0,") ) )
> (readJson) )
>
> (doSomething J)
> ... )
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
Thanks Alex,
After looking at the docs for echo I can follow what's going on. it's
pretty nifty!
Since all the numbers I need are values of dictionary keys, this technique
would work perfectly!
Regards,
Kashyap
On Mon, May 6, 2019 at 2:06 PM C K Kashyap wrote:
> My mind is blown - yet again. I love it just looking at it. I'll have to
> look a little more to see what's going on.
>
> How do I capture the output though - I mean this does not capture the
> output in J
>
>(setq J (pipe
>
> (in '("curl" "-s" "
> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
>
> (while
>
> (prin
>
>(echo "volume" "unadjustedVolume") )
>
> (echo ",")
>
> (prin ".0,") ) )
>
> (pretty (readJson)) ))
>
> Regards,
> Kashyap
>
> On Mon, May 6, 2019 at 1:44 PM Alexander Burger
> wrote:
>
>> On Mon, May 06, 2019 at 10:21:34PM +0200, Alexander Burger wrote:
>> >(pipe
>> > (in '("curl" "-s" "
>> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
>> > (while
>> > (prin
>> >(echo "volume" "unadjustedVolume") )
>> > (echo ",")
>> > (prin ".0,") ) )
>> > ...
>> > The code echoes all text until it hits one of the target strings. In
>> such case
>> > it echoes the number till the comma, then prints ".0" and a comma.
>>
>> This way has the additional advantage that it is extremely fast.
>>
>> It just scans and echoes the input stream in a single linear pass. Much
>> better
>> than regular expression matching with all its overhead.
>>
>> And it is a lot simpler :)
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
Re: Review request for my JSON parsing implementation
On Mon, May 06, 2019 at 02:06:56PM -0700, C K Kashyap wrote:
> My mind is blown - yet again. I love it just looking at it. I'll have to
> look a little more to see what's going on.
>
> How do I capture the output though - I mean this does not capture the
> output in J
I used 'pretty' in the example to view the result.
You can directly 'setq' it or use it in whatever way of course.
(let J
(pipe
(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(while
(prin
(echo "volume" "unadjustedVolume") )
(echo ",")
(prin ".0,") ) )
(readJson) )
(doSomething J)
... )
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
My mind is blown - yet again. I love it just looking at it. I'll have to
look a little more to see what's going on.
How do I capture the output though - I mean this does not capture the
output in J
(setq J (pipe
(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m
")
(while
(prin
(echo "volume" "unadjustedVolume") )
(echo ",")
(prin ".0,") ) )
(pretty (readJson)) ))
Regards,
Kashyap
On Mon, May 6, 2019 at 1:44 PM Alexander Burger wrote:
> On Mon, May 06, 2019 at 10:21:34PM +0200, Alexander Burger wrote:
> >(pipe
> > (in '("curl" "-s" "
> https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> > (while
> > (prin
> >(echo "volume" "unadjustedVolume") )
> > (echo ",")
> > (prin ".0,") ) )
> > ...
> > The code echoes all text until it hits one of the target strings. In
> such case
> > it echoes the number till the comma, then prints ".0" and a comma.
>
> This way has the additional advantage that it is extremely fast.
>
> It just scans and echoes the input stream in a single linear pass. Much
> better
> than regular expression matching with all its overhead.
>
> And it is a lot simpler :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Mon, May 06, 2019 at 10:21:34PM +0200, Alexander Burger wrote:
>(pipe
> (in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> (while
> (prin
>(echo "volume" "unadjustedVolume") )
> (echo ",")
> (prin ".0,") ) )
> ...
> The code echoes all text until it hits one of the target strings. In such case
> it echoes the number till the comma, then prints ".0" and a comma.
This way has the additional advantage that it is extremely fast.
It just scans and echoes the input stream in a single linear pass. Much better
than regular expression matching with all its overhead.
And it is a lot simpler :)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
On Mon, May 06, 2019 at 12:20:24PM -0700, C K Kashyap wrote:
> Thanks Alex,
> I am not so concerned by number being the day of the week since the
> assumption is that there is an implicit understanding of all the "types" in
> the consuming code - I mean, it will be understood that all the numbers
> need to be either used in mathematical expression or divided by the scale
> if it is consumed directly.
OK, but I'd prefer a general solution.
> The sed solution has the risk of altering strings that are unintended - I
> can change it a bit to make it a little more robust - also I have to do it
> twice since the first substitution may add .0 to numbers that are already
> floats.
>
> sed -r 's/(:\s+)([0-9.]+)\b/\1\2.0/g' | sed -r
> 's/(:\s+)([0-9]+)\.([0-9]+)\.0/\1\2.\3/g'
Uh, a horror indeed! :)
The PicoLisp way is usally different. It scans the stream with 'from', 'till',
'echo', 'peek' and 'char' etc.
I would go for exactly the types we know to have the ".0" missing. This I tested
for two cases, "volume" and "unadjustedVolume":
(load "@lib/json.l")
(scl 6)
(pipe
(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(while
(prin
(echo "volume" "unadjustedVolume") )
(echo ",")
(prin ".0,") ) )
(pretty (readJson)) )
(prinl)
You can add mere arguments to the 'echo' call if you know of other cases (I did
not bother to study the data in detail).
The code echoes all text until it hits one of the target strings. In such case
it echoes the number till the comma, then prints ".0" and a comma.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Thanks Alex,
I am not so concerned by number being the day of the week since the
assumption is that there is an implicit understanding of all the "types" in
the consuming code - I mean, it will be understood that all the numbers
need to be either used in mathematical expression or divided by the scale
if it is consumed directly.
The sed solution has the risk of altering strings that are unintended - I
can change it a bit to make it a little more robust - also I have to do it
twice since the first substitution may add .0 to numbers that are already
floats.
sed -r 's/(:\s+)([0-9.]+)\b/\1\2.0/g' | sed -r
's/(:\s+)([0-9]+)\.([0-9]+)\.0/\1\2.\3/g'
But I see your point. Would it be reasonable to temporarily override "read"
to read number differently? or is that an overkill?
regards,
Kashyap
On Mon, May 6, 2019 at 10:44 AM Alexander Burger
wrote:
> On Mon, May 06, 2019 at 07:22:05AM -0700, C K Kashyap wrote:
> > I'm afraid, the generating side is outside my control :( - I am looking
> at
> > this - https://api.iextrading.com/1.0/stock/aapl/chart/3m
>
> There is a way, I do this usually by reading from a pipe and modify the
> data
> along the way as necessary.
>
> Basically you can read this as
>
>(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
> (readJson) )
>
> Now you can do modifications here, either by calling a script with 'curl'
> and
> some filtering with 'sed' or 'awk, or do it directly:
>
>(in '("sh" "-c" "curl -s
> https://api.iextrading.com/1.0/stock/aapl/chart/3m | sed 's/xxx/yyy/g")
> (readJson) )
>
>
> > In this case, scaling everything does not seem so bad - infact, the
> > solution i was trying was to simply add a ".0" to all the numbers that
> did
> > not have it.
>
> Yes, can be done with the above 'sed'.
>
> But only if you are sure that none of the numbers is meant to be a plain
> integer.
>
>
> > Also, would it not be okay to say that all the numbers in the JSON (or
> some
> > other input) are scaled? It's for the user to be aware and deal with it
> > appropriately.
>
> Not in the general case. Imagine there is a number "7" in the data meaning
> a day
> of the week or whatever. It would end up as 700 :)
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Mon, May 06, 2019 at 07:22:05AM -0700, C K Kashyap wrote:
> I'm afraid, the generating side is outside my control :( - I am looking at
> this - https://api.iextrading.com/1.0/stock/aapl/chart/3m
There is a way, I do this usually by reading from a pipe and modify the data
along the way as necessary.
Basically you can read this as
(in '("curl" "-s" "https://api.iextrading.com/1.0/stock/aapl/chart/3m";)
(readJson) )
Now you can do modifications here, either by calling a script with 'curl' and
some filtering with 'sed' or 'awk, or do it directly:
(in '("sh" "-c" "curl -s https://api.iextrading.com/1.0/stock/aapl/chart/3m
| sed 's/xxx/yyy/g")
(readJson) )
> In this case, scaling everything does not seem so bad - infact, the
> solution i was trying was to simply add a ".0" to all the numbers that did
> not have it.
Yes, can be done with the above 'sed'.
But only if you are sure that none of the numbers is meant to be a plain
integer.
> Also, would it not be okay to say that all the numbers in the JSON (or some
> other input) are scaled? It's for the user to be aware and deal with it
> appropriately.
Not in the general case. Imagine there is a number "7" in the data meaning a day
of the week or whatever. It would end up as 700 :)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
I'm afraid, the generating side is outside my control :( - I am looking at
this - https://api.iextrading.com/1.0/stock/aapl/chart/3m
In this case, scaling everything does not seem so bad - infact, the
solution i was trying was to simply add a ".0" to all the numbers that did
not have it.
Also, would it not be okay to say that all the numbers in the JSON (or some
other input) are scaled? It's for the user to be aware and deal with it
appropriately.
On Mon, May 6, 2019 at 6:47 AM Alexander Burger wrote:
> Hi Kashyap,
>
> > I still have a question - if my
> > program gets its input from two json strings -
> > {"V": 10} and {"V" : 10.1}, and I need to sum up all the Vs - how can I
> do
> > it?
>
> I think there is no generic solution. It all depends on what the numbers
> *mean*.
>
> We cannot simply scale up every number in the Json text. If for example the
> first "10" is a count, we do not want to multiply it with the scale.
>
> Can't you make sure on the Json *generating* side that fixpoint numbers are
> produced with a dot?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
Hi Kashyap,
> I still have a question - if my
> program gets its input from two json strings -
> {"V": 10} and {"V" : 10.1}, and I need to sum up all the Vs - how can I do
> it?
I think there is no generic solution. It all depends on what the numbers *mean*.
We cannot simply scale up every number in the Json text. If for example the
first "10" is a count, we do not want to multiply it with the scale.
Can't you make sure on the Json *generating* side that fixpoint numbers are
produced with a dot?
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Thanks for the link to Rick's introduction. I still have a question - if my
program gets its input from two json strings -
{"V": 10} and {"V" : 10.1}, and I need to sum up all the Vs - how can I do
it?
Perhaps, I would have to suppress the . reader macro before calling
parseJson and then do a pass to normalize the numbers?
On Sun, May 5, 2019 at 1:10 PM Alexander Burger wrote:
> On Sun, May 05, 2019 at 08:00:18AM -0700, C K Kashyap wrote:
> > : (scl 2)
> > -> 2
> > : (parseJson "{\"a\": 10.1}")
> > -> (("a" . 1010))
> > : (parseJson "{\"a\": 10}")
> > -> (("a" . 10))
> >
> > Shouldn't 10 be scaled to 1000? Did I miss something here or is there
> > something I need to do so that all the numbers are normalized?
>
> No, 10 is correct.
>
> Keep in mind that PicoLisp really only has integers, which may be handled
> by a
> program as scaled fixpoinbn numbers.
>
> So the dot in 10.1 is in fact enly a read macro, scaling the number while
> *reading* it.
>
> I recommend Rick's excellent introduction to PicoLisp fixpoint numbers
>
>https://the-m6.net/blog/fixed-point-arithmetic-in-picolisp/
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Sun, May 05, 2019 at 08:00:18AM -0700, C K Kashyap wrote:
> : (scl 2)
> -> 2
> : (parseJson "{\"a\": 10.1}")
> -> (("a" . 1010))
> : (parseJson "{\"a\": 10}")
> -> (("a" . 10))
>
> Shouldn't 10 be scaled to 1000? Did I miss something here or is there
> something I need to do so that all the numbers are normalized?
No, 10 is correct.
Keep in mind that PicoLisp really only has integers, which may be handled by a
program as scaled fixpoinbn numbers.
So the dot in 10.1 is in fact enly a read macro, scaling the number while
*reading* it.
I recommend Rick's excellent introduction to PicoLisp fixpoint numbers
https://the-m6.net/blog/fixed-point-arithmetic-in-picolisp/
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Interesting ... for some reason, I believed that PicoLisp did not contain a
json parser !!! - perhaps because, a search for json on
https://picolisp.com/wiki/?Documentation takes me to the external
repositories section :)
pipe is awesome :) - I was looking for just that.
It occurred to me that the "@lib/json.l" also seems to work with scaling a
little different from my expectation -
*kashyap@continue*:*~*$ pil +
: (load "@lib/json.l")
-> printJson
: (scl 2)
-> 2
: (parseJson "{\"a\": 10.1}")
-> (("a" . 1010))
: (parseJson "{\"a\": 10}")
-> (("a" . 10))
:
Shouldn't 10 be scaled to 1000? Did I miss something here or is there
something I need to do so that all the numbers are normalized?
Regards,
Kashyap
On Sat, May 4, 2019 at 11:49 PM Alexander Burger
wrote:
> On Sat, May 04, 2019 at 11:27:28PM -0700, C K Kashyap wrote:
> > Thank you so much Alex ... What would it take to transform this code to
> > handle string as input instead of file stream?
>
> There are two ways:
>
> 1. To parse strings directly, then a different code is needed. As an
> example,
>see 'parseJson' (strings) versus 'readJson' (input stream) in
> "@lib/json.l".
>
> 2. Simpler is to use a pipe, printing strings to one end and reading from
> the
>other:
>
>: (parseJson "{a: 7, s: \"abc\"}")
>-> ((a . 7) (s . "abc"))
>
>: (pipe (prinl "{a: 7, s: \"abc\"}")
> (readJson) )
>-> ((a . 7) (s . "abc"))
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Review request for my JSON parsing implementation
On Sat, May 04, 2019 at 11:27:28PM -0700, C K Kashyap wrote:
> Thank you so much Alex ... What would it take to transform this code to
> handle string as input instead of file stream?
There are two ways:
1. To parse strings directly, then a different code is needed. As an example,
see 'parseJson' (strings) versus 'readJson' (input stream) in "@lib/json.l".
2. Simpler is to use a pipe, printing strings to one end and reading from the
other:
: (parseJson "{a: 7, s: \"abc\"}")
-> ((a . 7) (s . "abc"))
: (pipe (prinl "{a: 7, s: \"abc\"}")
(readJson) )
-> ((a . 7) (s . "abc"))
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Thank you so much Alex ... What would it take to transform this code to handle string as input instead of file stream? On Sat, May 4, 2019 at 11:17 PM Alexander Burger wrote: > On Sun, May 05, 2019 at 07:58:16AM +0200, Alexander Burger wrote: > > Hi Kashyap, > > > > > Gentle reminder :) > > ... > > > > (while (not (= (peek) "\"")) > > > > Better (until (= (peek) "\"") > > Like what I said about 'prog', also 'not' should seldom be necessary. At > least > *never* in conditionals. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Review request for my JSON parsing implementation
On Sun, May 05, 2019 at 07:58:16AM +0200, Alexander Burger wrote: > Hi Kashyap, > > > Gentle reminder :) > ... > > > (while (not (= (peek) "\"")) > > Better (until (= (peek) "\"") Like what I said about 'prog', also 'not' should seldom be necessary. At least *never* in conditionals. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Hi Kashyap,
> Gentle reminder :)
Yeah, good! :)
I think it looks good, not much to say on a short glance.
*If* anything at all, I would only mention minor stuff like
> > (while (not (= (peek) "\""))
Better (until (= (peek) "\"")
> > (case (peek)
> >("\\" (char) (link (char)))
> >(T (link (char))
As there are only two cases, an 'if' would be shorter. In this case, I would use
'ifn'
(link
(ifn (= "\\" (peek))
(char)
(char)
(link (char)) ) )
but anyway can be reduced to
(and (= "\\" (peek)) (char))
(link (char))
> > (let R
> > (pack
> > (make (do (length W) (link (char)
> >(prog (unless (= W R) (quit (pack "Expected " W ", got " R))) R)))
The 'prog' seems not necessary.
> > (let (
> >Neg (if (= "-" (peek)) (char))
Personally I would not use 'if' here, I use it only if there is also an 'else'
body. 'and' or 'when' feels better.
> > (while (not (= (peek) E))
as above
> >(if (= (peek) ",") (prog (char) (skip) (if (= E (peek)) (quit
> > "Incorrect collection termination"))
Here the 'prog' can probably avoided too.
In general, if 'prog' is used, then very often there is another conditional
which handles it directly.
> > (de isNum (n) (or (= "." n) (num? (format n
'n' -> 'N'
(num? (format N))) -> (format N)
All without guarantee, I haven't tested :)
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Review request for my JSON parsing implementation
Gentle reminder :)
On Fri, May 3, 2019 at 6:24 PM C K Kashyap wrote:
> Hi all,
> I've made an attempt at JSON parsing. I did this since json.l at
> https://github.com/aw/picolisp-json does not handle floating numbers and
> that is something I need. I also took it as an opportunity to implement
> something bigger than a function and get some feedback about it - I used
> xml.l from picolisp source as a reference. What would be a good way to use
> this implementation to parse an json string - as opposed to input from a
> file.
> The code is located here -
> https://gist.github.com/ckkashyap/90602086fd4edafa75897a131f8cb88a - I
> also have it inline for the folks reluctant to click on the link :)
>
> (de parse-json ()
> (skip)
> (case (peek)
> ("\"" (read-string))
> ("{" (read-object))
> ("[" (read-array))
> ("t" (read-bare-word "true"))
> ("f" (read-bare-word "false"))
> ("n" (read-bare-word "null"))
> (T (read-number
>
> (de expect (C)
> (skip)
> (let P (peek)
>(unless (= P C) (quit (pack "Expected <" C "> Got <" P ">")
>
> (de read-string ()
> (expect "\"")
> (char)
> (let R
> (make
> (while (not (= (peek) "\""))
> (case (peek)
>("\\" (char) (link (char)))
>(T (link (char))
> (char)
> (pack R)))
>
> (de read-object () (read-collection read-key-value "{" "}"))
>
> (de read-array () (read-collection parse-json "[" "]"))
>
> (de read-bare-word (W)
> (skip)
> (let R
> (pack
> (make (do (length W) (link (char)
>(prog (unless (= W R) (quit (pack "Expected " W ", got " R))) R)))
>
> (de read-number ()
> (skip)
> (let (
> Neg (if (= "-" (peek)) (char))
>_ (unless (isNum (peek)) (quit (pack "Not an number " (peek
>Flt NIL
>R (make (while (isNum (peek)) (if (= "." (peek)) (setq Flt T)) (link
> (char)
>(round (pack (if Neg "-") R (unless Flt ".0")
>
> (de read-key-value ()
> (let (
>k (read-string)
>_ (skip)
>_ (unless (= (char) ":") (exit ":" (peek)))
>v (parse-json))
>(list k v)))
>
> (de read-collection (F S E)
> (expect S)
> (char)
> (let R
>(make
> (while (not (= (peek) E))
>(link (F))
>(skip)
>(if (= (peek) ",") (prog (char) (skip) (if (= E (peek)) (quit
> "Incorrect collection termination"))
>(char)
>R))
>
> (de isNum (n) (or (= "." n) (num? (format n
>
>
> Regards,
> Kashyap
>
Review request for my JSON parsing implementation
Hi all,
I've made an attempt at JSON parsing. I did this since json.l at
https://github.com/aw/picolisp-json does not handle floating numbers and
that is something I need. I also took it as an opportunity to implement
something bigger than a function and get some feedback about it - I used
xml.l from picolisp source as a reference. What would be a good way to use
this implementation to parse an json string - as opposed to input from a
file.
The code is located here -
https://gist.github.com/ckkashyap/90602086fd4edafa75897a131f8cb88a - I also
have it inline for the folks reluctant to click on the link :)
(de parse-json ()
(skip)
(case (peek)
("\"" (read-string))
("{" (read-object))
("[" (read-array))
("t" (read-bare-word "true"))
("f" (read-bare-word "false"))
("n" (read-bare-word "null"))
(T (read-number
(de expect (C)
(skip)
(let P (peek)
(unless (= P C) (quit (pack "Expected <" C "> Got <" P ">")
(de read-string ()
(expect "\"")
(char)
(let R
(make
(while (not (= (peek) "\""))
(case (peek)
("\\" (char) (link (char)))
(T (link (char))
(char)
(pack R)))
(de read-object () (read-collection read-key-value "{" "}"))
(de read-array () (read-collection parse-json "[" "]"))
(de read-bare-word (W)
(skip)
(let R
(pack
(make (do (length W) (link (char)
(prog (unless (= W R) (quit (pack "Expected " W ", got " R))) R)))
(de read-number ()
(skip)
(let (
Neg (if (= "-" (peek)) (char))
_ (unless (isNum (peek)) (quit (pack "Not an number " (peek
Flt NIL
R (make (while (isNum (peek)) (if (= "." (peek)) (setq Flt T))
(link (char)
(round (pack (if Neg "-") R (unless Flt ".0")
(de read-key-value ()
(let (
k (read-string)
_ (skip)
_ (unless (= (char) ":") (exit ":" (peek)))
v (parse-json))
(list k v)))
(de read-collection (F S E)
(expect S)
(char)
(let R
(make
(while (not (= (peek) E))
(link (F))
(skip)
(if (= (peek) ",") (prog (char) (skip) (if (= E (peek)) (quit
"Incorrect collection termination"))
(char)
R))
(de isNum (n) (or (= "." n) (num? (format n
Regards,
Kashyap
Re: JSON lib rewritten in pure PicoLisp - no C/ffi bindings
By popular demand, I've published a **new** EXPLAIN document regarding this JSON library. Feel free to read: https://github.com/aw/picolisp-json/blob/master/EXPLAIN_v3.md AW On 01/10/2018 05:19 AM, r...@tamos.net wrote: > Thanks, aw! Your EXPLAINs are something I always look forward to > reading, and this one did not disappoint. I also like your style of > coding. As an aside, I smiled when you mentioned PAIP. I love this book > too! All the best, —Rick > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: JSON lib rewritten in pure PicoLisp - no C/ffi bindings
*fistbump* On 01/10/2018 05:19 AM, r...@tamos.net wrote: > Thanks, aw! Your EXPLAINs are something I always look forward to > reading, and this one did not disappoint. I also like your style of > coding. As an aside, I smiled when you mentioned PAIP. I love this book > too! All the best, —Rick > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: JSON lib rewritten in pure PicoLisp - no C/ffi bindings
Thanks, aw! Your EXPLAINs are something I always look forward to reading, and this one did not disappoint. I also like your style of coding. As an aside, I smiled when you mentioned PAIP. I love this book too! All the best, —Rick
Re: JSON lib rewritten in pure PicoLisp - no C/ffi bindings
I discovered a bug in v3.0 of the parser, so I took that opportunity to add more tests; as well as refactor, simplify, and optimize the code (and fix the bug). Latest version can be obtained here: https://github.com/aw/picolisp-json/blob/master/json.l Thanks! AW On 01/08/2018 10:18 AM, Alexander Williams wrote: > Hi everyone, > > I've published a significant change to my picolisp-json[1] library. The > decoder, now at version 3.0, has been completely rewritten to avoid the > use of a C/ffi library. > > This means it also works on 32-bit systems. > > I've added ~30 unit tests[2] to validate various edge cases, and the > library now conforms to the "ECMA-404 The JSON Data Interchange > Standard"[3] (except for floating point/scientific numbers). > > It shouldn't introduce any breaking changes, but validations on > improperly formatted JSON strings will now output a message to STDERR, > while still returning NIL as before. > > The code isn't super optimized yet, but so far "it seems to work" ;) > > Feel free to ask me any questions, or submit issues[4] / pull requests > if you want to contribute. > > [1]: https://github.com/aw/picolisp-json library > [2]: https://travis-ci.org/aw/picolisp-json/jobs/326289902 > [3]: > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf > [4]: https://github.com/aw/picolisp-json/issues/new > > Cheers, > > AW > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: JSON lib rewritten in pure PicoLisp - no C/ffi bindings
awesome, thanks Den 8 jan. 2018 11:26 fm skrev "Alexander Williams" : > Hi everyone, > > I've published a significant change to my picolisp-json[1] library. The > decoder, now at version 3.0, has been completely rewritten to avoid the > use of a C/ffi library. > > This means it also works on 32-bit systems. > > I've added ~30 unit tests[2] to validate various edge cases, and the > library now conforms to the "ECMA-404 The JSON Data Interchange > Standard"[3] (except for floating point/scientific numbers). > > It shouldn't introduce any breaking changes, but validations on > improperly formatted JSON strings will now output a message to STDERR, > while still returning NIL as before. > > The code isn't super optimized yet, but so far "it seems to work" ;) > > Feel free to ask me any questions, or submit issues[4] / pull requests > if you want to contribute. > > [1]: https://github.com/aw/picolisp-json library > [2]: https://travis-ci.org/aw/picolisp-json/jobs/326289902 > [3]: > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf > [4]: https://github.com/aw/picolisp-json/issues/new > > Cheers, > > AW > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
JSON lib rewritten in pure PicoLisp - no C/ffi bindings
Hi everyone, I've published a significant change to my picolisp-json[1] library. The decoder, now at version 3.0, has been completely rewritten to avoid the use of a C/ffi library. This means it also works on 32-bit systems. I've added ~30 unit tests[2] to validate various edge cases, and the library now conforms to the "ECMA-404 The JSON Data Interchange Standard"[3] (except for floating point/scientific numbers). It shouldn't introduce any breaking changes, but validations on improperly formatted JSON strings will now output a message to STDERR, while still returning NIL as before. The code isn't super optimized yet, but so far "it seems to work" ;) Feel free to ask me any questions, or submit issues[4] / pull requests if you want to contribute. [1]: https://github.com/aw/picolisp-json library [2]: https://travis-ci.org/aw/picolisp-json/jobs/326289902 [3]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf [4]: https://github.com/aw/picolisp-json/issues/new Cheers, AW -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Yet another JSON lib, and a tutorial
Hey, cool. Now you lured me into reading about nanomsg. :-) On March 10, 2015 2:53:58 PM CET, Alexander Williams wrote: >Hi list, > >I've written yet another JSON encoder/decoder for PicoLisp. I know, >they >already exist.. > >This library is using a native C library for JSON parsing, so it's a >bit >different. > >Of course, I've written a tutorial which explains a few more concepts I >learned (Thanks Mr. Burger). > > https://github.com/aw/picolisp-json/blob/master/EXPLAIN.md > >And the library: https://github.com/aw/picolisp-json > >Please let me know if you find any issues.. > > >Thanks! -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
Yet another JSON lib, and a tutorial
Hi list, I've written yet another JSON encoder/decoder for PicoLisp. I know, they already exist.. This library is using a native C library for JSON parsing, so it's a bit different. Of course, I've written a tutorial which explains a few more concepts I learned (Thanks Mr. Burger). https://github.com/aw/picolisp-json/blob/master/EXPLAIN.md And the library: https://github.com/aw/picolisp-json Please let me know if you find any issues.. Thanks!
Re: JSON Rest
This encoder/decoder is based on Alex's rosetta example https://bitbucket.org/hsarvell/ext/src/31f26bbff901e1a88aa997ce919b7edb50ea810d/json.l?at=defaultbut has turned out quite changed to automatically account for various edge cases. With this CURL based client you can post the JSON straight in the body of the HTTP message: https://bitbucket.org/hsarvell/ext/src/31f26bbff901e1a88aa997ce919b7edb50ea810d/client.l?at=default Pl-web also recently started to support consuming a "raw" JSON POST body on the server by way of the *Body global: https://bitbucket.org/hsarvell/pl-web/commits/a710a5e934b669f859963c36b6c8b020f2fdee0c On Tue, Feb 18, 2014 at 3:45 AM, Rick Lyman wrote: > Look at this post: > http://blog.gmane.org/gmane.lisp.picolisp.general/month=20121001. > > For session management you may want to look at: > http://picolisp.com/wiki/?macropis. > > > > > On Mon, Feb 17, 2014 at 1:44 PM, klaus schilling > wrote: > >> hello, >> is it possible to write a client for a JSON rest service in picolisp? >> >> Many services abandon their XML-RPC API and flee to JSON rets, for >> whatever reason. >> >> Klaus Schilling >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> > >
Re: JSON Rest
Look at this post: http://blog.gmane.org/gmane.lisp.picolisp.general/month=20121001. For session management you may want to look at: http://picolisp.com/wiki/?macropis. On Mon, Feb 17, 2014 at 1:44 PM, klaus schilling wrote: > hello, > is it possible to write a client for a JSON rest service in picolisp? > > Many services abandon their XML-RPC API and flee to JSON rets, for > whatever reason. > > Klaus Schilling > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: JSON Rest
Hi Klaus, yes, if you search this mailing list, you should be able to find discussions and examples. Cheers, Tomas klaus schilling writes: > hello, > is it possible to write a client for a JSON rest service in picolisp? > > Many services abandon their XML-RPC API and flee to JSON rets, for > whatever reason. > > Klaus Schilling -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
JSON Rest
hello, is it possible to write a client for a JSON rest service in picolisp? Many services abandon their XML-RPC API and flee to JSON rets, for whatever reason. Klaus Schilling -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: json example w/ersatz
Hi Joe,
> Are there any tips on how to port the json example to ersatz since it
> does not support pipe? I experimented with parsing out the string into
> a new string and calling str on it but didn't get very far yet. I'd
> like something that can parse a string.
The function 'str' is the brother of 'read' in this context. It accepts
an analog argument syntax:
: (str "{ \"foo\": 1, \"bar\": [10, \"apples\"] }" "_")
-> ("{" "foo" ":" 1 "," "bar" ":" "[" 10 "," "apples" "]" "}")
You could modify 'readJson' so that it operates on the resulting list
instead of the current input channel.
On the other hand, is this really necessary? I see JSON primarily as an
I/O format. The string argument was just a requirement of the
RosettaCode task. I would expect that typical application would rather
call (readJson) in an 'in' body (reading from a file or socket). Reading
a string first, and converting it immediately, is just overhead.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
json example w/ersatz
Are there any tips on how to port the json example to ersatz since it does not support pipe? I experimented with parsing out the string into a new string and calling str on it but didn't get very far yet. I'd like something that can parse a string. Thanks Joe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
On Fri, 27 Jan 2012 13:58:50 +0100 Alexander Burger wrote: > On Fri, Jan 27, 2012 at 01:48:41PM +0100, Alexander Burger wrote: > > Let me check more thoroughly. > > How about that? > >(de readJson () > (case (read "_") > ... > (T > (let X @ >(if (and (= "-" X) (format (peek))) > (- (read)) > X ) ) ) ) ) That seems to work for all my test cases, thanks! Changed it in the Rosetta page too. -José -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
On Fri, Jan 27, 2012 at 01:48:41PM +0100, Alexander Burger wrote: > Let me check more thoroughly. How about that? (de readJson () (case (read "_") ... (T (let X @ (if (and (= "-" X) (format (peek))) (- (read)) X ) ) ) ) ) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
On Fri, Jan 27, 2012 at 01:45:12PM +0100, Alexander Burger wrote: > We can simply add the "-" character to the atom-specifiers: Sorry, forget that. These are only for symbols :( Let me check more thoroughly. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
Hi José,
> Hmmm, it still doesn't work quite well, it chokes on negative
Oops again ;-)
> numbers, no idea how to fix that. :(
We can simply add the "-" character to the atom-specifiers:
(de readJson ()
(case (read "-_")
("{"
...
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
Hmmm, it still doesn't work quite well, it chokes on negative numbers, no idea how to fix that. :( -José -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
On Fri, 27 Jan 2012 12:55:29 +0100 Alexander Burger wrote: > Hi José, > > > Looks like the example JSON functions choke on empty objects. I > > made a > > Oops. Right. > > > > If it's OK I'll edit the task page, buggy code is ugly code! > > Indeed. Please do so. Many thanks! Done! > > Cheers, > - Alex -José -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Bug in the JSON example in rosetta
Hi José, > Looks like the example JSON functions choke on empty objects. I made a Oops. Right. > If it's OK I'll edit the task page, buggy code is ugly code! Indeed. Please do so. Many thanks! Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Bug in the JSON example in rosetta
Looks like the example JSON functions choke on empty objects. I made a
quick and dirty fix, but I'm not sure if I introduced extra bugs.
Diff follows:
##
--- json.orig.l 2012-01-27 07:34:25.0 -0300
+++ json.l 2012-01-27 07:46:32.0 -0300
@@ -6,7 +6,7 @@
(case (read "_")
("{"
(make
-(for (X (readJson) T (readJson))
+(for (X (readJson) (not (= "}" X)) (readJson))
(checkJson ":" (readJson))
(link (cons X (readJson)))
(T (= "}" (setq X (readJson
@@ -14,7 +14,7 @@
("["
(make
(link T) # Array marker
-(for (X (readJson) T (readJson))
+(for (X (readJson) (not (= "]" X)) (readJson))
(link X)
(T (= "]" (setq X (readJson
(checkJson "," X) ) ) )
@@ -22,7 +22,7 @@
(de printJson (Item) # For simplicity, without indentation
(cond
- ((atom Item) (print Item))
+ ((atom Item) (if Item (print @) (prin "{}")))
((=T (car Item))
(prin "[")
(map
##
Tested with this:
: (pipe (prinl "{\"one\":[[],[1,2,3],[],[]],\"two\":{}}") (readJson))
-> (("one" T (T) (T 1 2 3) (T) (T)) ("two"))
: (printJson @)
{"one": [[], [1, 2, 3], [], []], "two": {}}-> "}"
If it's OK I'll edit the task page, buggy code is ugly code!
Cheers,
-José
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: JSON
Hi Henrik, > I suppose I have to refer to my own stuff for completeness here too > then. Yes. Though I knew about your work, and we've discussed it in the past, I must confess that I didn't remember it when I saw the RosettaCode task today. Your library is much more general and complete. Yet, for RosettaCode, a plain little functional solutions should do. It has the advantage that it is serves more easily as a PicoLisp coding example (the purpose of RosettaCode after all). > It will solve some ambiguous situations with some help from the caller > and will also encode "real" PL objects (not just paired lists). Conversion of real objects to/from paired lists could be done with 'putl'/'getl' (as you also do), combined with a 'mapcar' or so. The main difference of the simple solution is that it uses I/O instead of strings. This has both disadvantages (needs extra wrenching when strings are needed) and advantages (faster and easier when using it via sockets, which is I think the more typical case). The I/O solution is particularly simple, because the built-in 'read' function does all the parsing. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: JSON
I suppose I have to refer to my own stuff for completeness here too then. It will solve some ambiguous situations with some help from the caller and will also encode "real" PL objects (not just paired lists). Mailing list entry: http://www.mail-archive.com/picolisp@software-lab.de/msg01361.html Some documentation: http://www.prodevtips.com/2008/09/11/pico-lisp-and-json= / Hm I just realized there's a dependency to a class called +Str, here is the function being used: (dm entityQuotes> (S) (pack (mapcar '((C) (if (=3D 34 (char C)) """ C )) (chop S Seems like I was trying to solve the double quote bug through html encoding, not really ideal since it doesn't make for a general solution (it works for my special case since I show all text in the browser anyway). Cheers, Henrik Sarvell On Thu, Aug 26, 2010 at 4:23 PM, Alexander Burger wro= te: > Hi all, > > for the fans of JSON: I wrote a simple library (if we should call such a > trivial thing a "library" ;-) > > =A0 http://rosettacode.org/wiki/JSON > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
JSON
Hi all, for the fans of JSON: I wrote a simple library (if we should call such a trivial thing a "library" ;-) http://rosettacode.org/wiki/JSON Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: JSON
I use the JSON library extensively on vizreader.com so I know it works for most things, actually the text I mentioned before that broke it contained javascript inside it I think. As for the tag stripping I'm actually only using PHP-cli for all my needs at the moment, leaving Ruby out of the equation completely. /Henrik On Mon, Dec 14, 2009 at 3:23 PM, Benjamin Pollack wrote: > Wow. =A0That's the first time I've gotten a response from a mailing list = by > merely googling for an answer--and faster than sometimes when I've asked > directly, too. =A0Impressive. :) > > I was enjoying messing around with PicoLisp, and wanted to know what the > library situation looked like for some key modules before I dove in. =A0I > found your post about processing PicoLisp client-side rather than working > with JSON server-side, and the one where you wrote that you gave up, and > were going to shell out to Ruby for HTML escapes. =A0An interesting > combination. > Thanks very much for the encoder. =A0I haven't written anything meaningfu= l in > PicoLisp yet (I only even worked through the tutorial yesterday), but am > going to try to write something simple sometime this week. =A0Having > server-side JSON support is going to make what I have in mind vastly > simpler. =A0PicoLisp looks fascinating; this should be quite fun. > --Benjamin > > On Mon, Dec 14, 2009 at 5:12 AM, Henrik Sarvell wrot= e: >> >> I just noticed that someone had searched for "picolisp json" on >> Google, I've attached the JSON encoder/decoder to this mail. >> >> However there is one problem, it isn't properly managing when there >> are complex texts involved, then the double quote escaping might get >> it wrong if there are already escaped double quotes in the text and so >> on. That's what I suspect anyway, I was too lazy to properly debug >> when I ran into problems, both because debugging decoding failures on >> the JS side is extremely tedious and because the size of the text that >> was failing was enormous. >> >> Possibly outdated documentation here: >> http://www.prodevtips.com/2008/09/11/pico-lisp-and-json/ (should be >> better than nothing though). >> >> /Henrik > > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: JSON
Wow. That's the first time I've gotten a response from a mailing list by merely googling for an answer--and faster than sometimes when I've asked directly, too. Impressive. :) I was enjoying messing around with PicoLisp, and wanted to know what the library situation looked like for some key modules before I dove in. I found your post about processing PicoLisp client-side rather than working with JSON server-side, and the one where you wrote that you gave up, and were going to shell out to Ruby for HTML escapes. An interesting combination. Thanks very much for the encoder. I haven't written anything meaningful in PicoLisp yet (I only even worked through the tutorial yesterday), but am going to try to write something simple sometime this week. Having server-side JSON support is going to make what I have in mind vastly simpler. PicoLisp looks fascinating; this should be quite fun. --Benjamin On Mon, Dec 14, 2009 at 5:12 AM, Henrik Sarvell wrote: > I just noticed that someone had searched for "picolisp json" on > Google, I've attached the JSON encoder/decoder to this mail. > > However there is one problem, it isn't properly managing when there > are complex texts involved, then the double quote escaping might get > it wrong if there are already escaped double quotes in the text and so > on. That's what I suspect anyway, I was too lazy to properly debug > when I ran into problems, both because debugging decoding failures on > the JS side is extremely tedious and because the size of the text that > was failing was enormous. > > Possibly outdated documentation here: > http://www.prodevtips.com/2008/09/11/pico-lisp-and-json/ (should be > better than nothing though). > > /Henrik >
JSON
I just noticed that someone had searched for "picolisp json" on Google, I've attached the JSON encoder/decoder to this mail. However there is one problem, it isn't properly managing when there are complex texts involved, then the double quote escaping might get it wrong if there are already escaped double quotes in the text and so on. That's what I suspect anyway, I was too lazy to properly debug when I ran into problems, both because debugging decoding failures on the JS side is extremely tedious and because the size of the text that was failing was enormous. Possibly outdated documentation here: http://www.prodevtips.com/2008/09/11/pico-lisp-and-json/ (should be better than nothing though). /Henrik json.l Description: Binary data
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
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 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
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))
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=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 Sarvell 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 Hlavaty 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
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 Hlavaty 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
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 Sarvell 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 Hlavaty 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
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 Sarvell 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 Hlavaty 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
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 Hlavaty 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
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. I have done this in three cases: 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js is not complete (dot notation is missing) and needs some improvements based on the lesson learned from the postscript parser bellow. OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely for communication between client and server. Ideally, I would like to replace javascript by client-side picolisp (implemented in javascript) completely. I think it is feasible and could be efficient enough. Imagine having persistent symbols/objects 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 http://logand.com/sw/wps/wps.js WPS http://logand.com/sw/wps/index.html proved to me that implementing interpreters in javascript is reasonably efficient although not great for coding things in a tight loop (which is usually quite little code and could be implemented directly in 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. Json 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=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 Przybylski 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
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
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 Burger 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
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
From Pico to JSON in the client
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/ If you check the code and read at the bottom you see that there are two issues. My regexp skills are not up to the task of solving these two issues but I don't know about the rest of you, any ideas? /Henrik -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
