Re: Stop Integer Coercion to Scientific Notation in JSON

2019-09-13 Thread Trevor DeVore via use-livecode 
On Thu, Sep 12, 2019 at 1:42 PM Sannyasin Brahmanathaswami via use-livecode
 wrote:

> Been working Panos off list.
>
> There is a caveat, jsonImport and jsonExport not only "display" but
> "preserve" the scientific notation as a literal string and math will fail.
>
> Panos says: must use, (and include in a standalone)  mergeJson to
> use:  jsonToArray  and arrayToJSON
>

While ArrayToJSON does fix the problem you are experiencing, it does
introduce additional problems. Try the following code:

```
on mouseUp
  put 1 is 1 into tValueA["root"]["boolean_1"]
  put 1 is 0 into tValueA["root"]["boolean_2"]
  put null into tValueA["root"]["null_1"]
  put "100" into tValueA["root"]["text"]
  put 100+0 into tValueA["root"]["number"]
  put ArrayToJSON(tValueA)
end mouseUp
```

The output is as follows:

```
{
  "root": {
"boolean_2": false,
"text": 100,
"null_1": "",
"boolean_1": true,
"number": 100
  }
}

```

ArrayToJSON won't ever quote numbers, even if the variable in LiveCode has
the number stored as a string (and not an integer or a real). Imagine a
user enters the string "100" into a text field and then your app sends that
value to a JSON API. If you send an integer to a JSON API that is expecting
a string you will most likely get an error.

The output would more appropriately be rendered this way:

```

{
  "root": {
"boolean_2": false,
"text": "100",
"null_1": null,
"boolean_1": true,
"number": 100
  }
}

```

Here is a variation on ArrayToJSON that renders the more appropriate output:

```

function ArrayToJSON pArray,pForceRootType,pPretty
  local tKey, e

  repeat for each key tKey in pArray
if pArray[tKey] is an array then
  put "}"&ArrayToJSON(pArray[tKey]) into pArray[tKey]
else if pArray[tKey] is NULL then
  put "null" into pArray[tKey]
else if pArray[tKey] is strictly a boolean \
  or pArray[tKey] is strictly an integer \
  or pArray[tKey] is strictly a real then
  put pArray[tKey] into pArray[tKey]
else
  # treat as a string
  put "}}"&pArray[tKey] into pArray[tKey]
end if
  end repeat

  return(mergJSONEncode("pArray",pForceRootType,pPretty))
end ArrayToJSON

```

In my projects I use this modified version of ArrayToJSON to export JSON
and a wrapper around JsonImport to import JSON. In my experience that gets
me the closest to expected values. Unfortunately JsonImport is rather slow,
but it is more accurate. I don't recall all of the nuances as to why though.


Here is my wrapper around JsonImmport:

```

function _importJSON pJSON
  # zero width joiner breaks JSON Importer
  # http://quality.livecode.com/show_bug.cgi?id=19691
  replace numtoCodePoint("0x200D") with empty in pJSON
  return JsonImport(pJSON)
end _importJSON

```

-- 
Trevor DeVore
 ScreenSteps
www.screensteps.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stop Integer Coercion to Scientific Notation in JSON

2019-09-12 Thread Sannyasin Brahmanathaswami via use-livecode 
Been working Panos off list.

There is a caveat, jsonImport and jsonExport not only "display" but "preserve" 
the scientific notation as a literal string and math will fail.

Panos says: must use, (and include in a standalone)  mergeJson to use:  
jsonToArray  and arrayToJSON 

try these:

on mouseup
   local tJSON
   breakpoint
   put "{" & quote & "lastRunDate" & quote && ":" && the seconds & "}" into 
tJSON
   put jsonImport(tJSON) into tArr
   put (tArr["lastRunDate"]  +3600 ) into   tArr["lastRunDate"] 
   put jsonExport(tArr) into tJSON
   put tJSON into url  ("binfile:" & (specialFolderPath("desktop") 
&"/myPrefs.json" ))
   put url  ("binfile:" & (specialFolderPath("desktop") &"/myPrefs.json" )) 
into tNewJSON
   put jsonImport(tNewJSON) into tPreferencesA
   put tPreferencesA["lastRunDate"]  + 3600
end mouseup

# then try this

on mouseup
   local tJSON
   put "{" & quote & "lastRunDate" & quote && ":" && the seconds & "}" into 
tJSON
   breakpoint
   put jsonToArray(tJSON) into tArr
   put (tArr["lastRunDate"] +3600 ) into tArr["lastRunDate"]
   put arrayToJSON(tArr) into tJSON
   put tJSON into url ("binfile:" & 
(specialFolderPath("desktop")&"/myPrefs.json" ))
   put url ("binfile:" & (specialFolderPath("desktop") &"/myPrefs.json" )) into 
tNewJSON
   put jsonImport(tNewJSON) into tPreferencesA
   put the seconds &cr& tPreferencesA["lastRunDate"]  +3600
end mouseup

Solved!

BR


Hello all,

There is not a lost of precision in the operations. The problem is just that 
LCB *displays* the value of large numbers in scientific notation, but if you 
actually do any calculations with the variables that hold these numbers, the 
calculations are accurate.

In other words the variables do hold the full value - it is the emission which 
is turning them into the scientific notation.
(emisson as text in json)

Hope this helps.

Kind regards,
Panos
--

On Wed, 11 Sep 2019 at 16:29, Sannyasin Brahmanathaswami via use-livecode 
 wrote:
One tries his best to not get excited by bugs that are left untouched, With 
some OS's to. keep current, engineering  has a tough time, we all know that … 
but this one pushes a button…

bug https://quality.livecode.com/show_bug.cgi?id=18159

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stop Integer Coercion to Scientific Notation in JSON

2019-09-11 Thread panagiotis merakos via use-livecode 
Hello all,

There is not a lost of precision in the operations. The problem is just
that LCB *displays* the value of large numbers in scientific notation, but
if you actually do any calculations with the variables that hold these
numbers, the calculations are accurate.

In other words the variables do hold the full value - it is the emission
which is turning them into the scientific notation.
(emisson as text in json)

Hope this helps.

Kind regards,
Panos
--

On Wed, 11 Sep 2019 at 16:29, Sannyasin Brahmanathaswami via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One tries his best to not get excited by bugs that are left untouched,
> With some OS's to. keep current, engineering  has a tough time, we all know
> that … but this one pushes a button…
>
> bug https://quality.livecode.com/show_bug.cgi?id=18159
>
>
> How can such a bug go unfixed for three years? Computing should be "exact"
> when comes to simple "arithmetic"  operations, after all the CPU is nothing
> but passing bit and bytes around, in large equations. …. if "arithmetic"
> operations are off all Apps and any OS would immediately have a meltdown
>
> So to have a process that loses digits from a simple integer > 100,000 Is
> "unconscionable "
> …for a language of the 21century
>
> We need to know that we can depend on "seconds" through all
> processes…"time" is fundamental to computing at all levels.
>
> You should put this on the list a top priority.
>
> With so many apps now working with the cloud, REST/XML and related
> proprietary transfers using JSON.  It is ever more in important that we can
> depend of LiveCode for the simple act of keeping a number/integer (any
> size) intact!
>
> At least I think I have a hack: to store time as a string -- the internet
> time in the json to keep in intact and to convert it after unpacking, and
> before store again but  something as simple as
>
> put ( (the seconds) +3600) into tOneHourLater
>
> Should always work.
>
> God help anyone using Livecode widgets/LCB extensions for physics.
>
> BR
>
>
>
> Hello Brahmanathaswami,
>
> I think this is because of how currently some handlers in lcb work.
>
> See bug https://quality.livecode.com/show_bug.cgi?id=18159 (and the
> related bugs) for more details.
>
> This affects other areas, such as how large numbers are shown in the
> variables pane in the debugger.
>
> Kind regards,
> Panos
> --
>
> On Tue, 10 Sep 2019 at 22:59, Sannyasin Brahmanathaswami via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
> setPref "preferences/global/lastRunDate", (the seconds) # e.g 1568144731
>
> put getPref ("preferences/global/lastRunDate") into tLastRunDate
>
> returns
> {"preferences":
> {"global":
> {"lastRunDate": 1.56814e+09},
> [snip]
>
> # we are using jsonImport
>
>  put jsonImport(tJSON) into tPreferencesA
>
> # handle data and
>
> put jsonExport(tPreferencesA) into tJSON.
>
> # thereafter my simple arithmetic functions like
>
> put (tLastRunDate + 3600) into 1HourLater
>
> # now throw a "left operand" error
>
> How can we prevent the coercion of simple integer notation to scientific?
>
> Why is it needed for simple 10 digit number is beyond me.
>
> There is nothing about automatic coercion in the dictionary.
>
> BR
>
>
>
>
>
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stop Integer Coercion to Scientific Notation in JSON

2019-09-11 Thread Sannyasin Brahmanathaswami via use-livecode 
One tries his best to not get excited by bugs that are left untouched, With 
some OS's to. keep current, engineering  has a tough time, we all know that … 
but this one pushes a button…

bug https://quality.livecode.com/show_bug.cgi?id=18159


How can such a bug go unfixed for three years? Computing should be "exact" when 
comes to simple "arithmetic"  operations, after all the CPU is nothing but 
passing bit and bytes around, in large equations. …. if "arithmetic" operations 
are off all Apps and any OS would immediately have a meltdown

So to have a process that loses digits from a simple integer > 100,000 Is 
"unconscionable "
…for a language of the 21century

We need to know that we can depend on "seconds" through all processes…"time" is 
fundamental to computing at all levels.

You should put this on the list a top priority.

With so many apps now working with the cloud, REST/XML and related proprietary 
transfers using JSON.  It is ever more in important that we can depend of 
LiveCode for the simple act of keeping a number/integer (any size) intact!

At least I think I have a hack: to store time as a string -- the internet time 
in the json to keep in intact and to convert it after unpacking, and before 
store again but  something as simple as

put ( (the seconds) +3600) into tOneHourLater

Should always work.

God help anyone using Livecode widgets/LCB extensions for physics.

BR



Hello Brahmanathaswami,

I think this is because of how currently some handlers in lcb work.

See bug https://quality.livecode.com/show_bug.cgi?id=18159 (and the related 
bugs) for more details.

This affects other areas, such as how large numbers are shown in the variables 
pane in the debugger.

Kind regards,
Panos
--

On Tue, 10 Sep 2019 at 22:59, Sannyasin Brahmanathaswami via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:
setPref "preferences/global/lastRunDate", (the seconds) # e.g 1568144731

put getPref ("preferences/global/lastRunDate") into tLastRunDate

returns
{"preferences":
{"global":
{"lastRunDate": 1.56814e+09}, [snip]

# we are using jsonImport

 put jsonImport(tJSON) into tPreferencesA

# handle data and

put jsonExport(tPreferencesA) into tJSON.

# thereafter my simple arithmetic functions like

put (tLastRunDate + 3600) into 1HourLater

# now throw a "left operand" error

How can we prevent the coercion of simple integer notation to scientific?

Why is it needed for simple 10 digit number is beyond me.

There is nothing about automatic coercion in the dictionary.

BR









___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stop Integer Coercion to Scientific Notation in JSON

2019-09-11 Thread panagiotis merakos via use-livecode 
Hello Brahmanathaswami,

I think this is because of how currently some handlers in lcb work.

See bug https://quality.livecode.com/show_bug.cgi?id=18159 (and the related
bugs) for more details.

This affects other areas, such as how large numbers are shown in the
variables pane in the debugger.

Kind regards,
Panos
--

On Tue, 10 Sep 2019 at 22:59, Sannyasin Brahmanathaswami via use-livecode <
use-livecode@lists.runrev.com> wrote:

> setPref "preferences/global/lastRunDate", (the seconds) # e.g 1568144731
>
> put getPref ("preferences/global/lastRunDate") into tLastRunDate
>
> returns
> {"preferences":
> {"global":
> {"lastRunDate": 1.56814e+09},
> [snip]
>
> # we are using jsonImport
>
>  put jsonImport(tJSON) into tPreferencesA
>
> # handle data and
>
> put jsonExport(tPreferencesA) into tJSON.
>
> # thereafter my simple arithmetic functions like
>
> put (tLastRunDate + 3600) into 1HourLater
>
> # now throw a "left operand" error
>
> How can we prevent the coercion of simple integer notation to scientific?
>
> Why is it needed for simple 10 digit number is beyond me.
>
> There is nothing about automatic coercion in the dictionary.
>
> BR
>
>
>
>
>
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Stop Integer Coercion to Scientific Notation in JSON

2019-09-10 Thread Sannyasin Brahmanathaswami via use-livecode 
setPref "preferences/global/lastRunDate", (the seconds) # e.g 1568144731

put getPref ("preferences/global/lastRunDate") into tLastRunDate

returns
{"preferences": 
{"global":  
{"lastRunDate": 1.56814e+09}, [snip]

# we are using jsonImport

 put jsonImport(tJSON) into tPreferencesA

# handle data and

put jsonExport(tPreferencesA) into tJSON.

# thereafter my simple arithmetic functions like

put (tLastRunDate + 3600) into 1HourLater

# now throw a "left operand" error

How can we prevent the coercion of simple integer notation to scientific?

Why is it needed for simple 10 digit number is beyond me.

There is nothing about automatic coercion in the dictionary.

BR









___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode