juliaio / json.jl Goto Github PK

In JSON we need to escape characters as \uXXXX or \uXXXX\uYYYY (UTF16 surrogates) rather than \uXX \uXXXX or \UXXXXXXXX as we do in Julia.

Similar to Go's Unmarshal, as suggested in #38.

I wanna turn a data frame into JSON.

Also, @aviks I like your avatar

I believe the json spec says that numbers are 64bit doubles, right? This just seems crazy:

julia> JSON.parse("[55555.5]")
1-element Array{Any,1}:
 55555.5

julia> JSON.parse("[666666.6]")
1-element Array{Any,1}:
 666667.0

Hi folks! Thanks for the awesome library. I noticed that:

json(reshape(1:8,2,2,2))

returns

"{}"

Is that by design?

...but is referenced in one of the test file ( perf.jl )

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

• On 2014-10-27 the testing status was Tests pass.
• On 2014-10-28 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("JSON")' log
INFO: Installing JSON v0.3.8
INFO: Package database updated
INFO: METADATA is out-of-date a you may not have the latest version of JSON
INFO: Use `Pkg.update()` to get the latest versions of your packages

>>> 'using JSON' log
Julia Version 0.4.0-dev+1330
Commit 7fdc860 (2014-10-28 03:56 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log

ERROR: `getindex` has no method matching getindex(::Array{Bool,1}, ::Char)
 in print_escaped at /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl:68
 in _print at /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl:81
 in _print at /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl:126
 in print at /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl:189
 in sprint at ./iostream.jl:230
 in json at /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl:202
 in include at ./boot.jl:242
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:293
 in _start at ./client.jl:362
 in _start_3B_3769 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/test/runtests.jl, in expression starting on line 149

INFO: Testing JSON
================================[ ERROR: JSON ]=================================

failed process: Process(`/home/idunning/julia04/usr/bin/julia /home/idunning/pkgtest/.julia/v0.4/JSON/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: JSON had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:719
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:68
 in process_options at ./client.jl:221
 in _start at ./client.jl:362
 in _start_3B_3769 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so

>>> end of log

See commit 72ada7a

I hate to do this so rapidly - but it's a bad bug and causing serious problems right now

o=open("file.json")
writecsv("o.txt",JSON.parse(o))
yesterday result was like :
rows by rows
357157182,["2013-10-04 12:22:40"=>["realtimeData"=>["intentionTags"=>{},....
344534426,["2013-10-04 15:46:36"=>["realtimeData"=>["intentionTags"=>{},
375559358,["2013-10-04 10:08:52"=>["realtimeData"=>["intentionTags"=>{}

today this same code and another result ... I prefer this first format. How I can do it ?
375865921,Dict{String,Any} with 1 entry:
"2013-10-04 14:27:45" => Dict{String,Any} with 4 entries:
"pixel" => "2"
"visitedWebsites" => {}
"data" => nothing
"realtimeData" => Dict{String,Any} with 4 entries:
"groups" => {}
"intentionTopics" => {}
"intentionTags" => {}
"tags" => {}
376089742,Dict{String,Any} with 1 entry:
"2013-10-04 19:01:41" => Dict{String,Any} with 4 entries:
"pixel" => "2"
"visitedWebsites" => {Dict{String,Any} with 3 entries:
"created_at" => "2013-10-04 17:15:31"

Paul

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

• On 2014-12-12 the testing status was Tests pass.
• On 2014-12-14 the testing status changed to Package doesn't load.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Package doesn't load. means that PackageEvaluator did not find tests for your package. Additionally, trying to load your package with using failed.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("JSON")' log
INFO: Installing JSON v0.3.9
INFO: Package database updated

>>> 'using JSON' log
ERROR: type: non-boolean (Void) used in boolean context
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in include at ./boot.jl:242
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:300
 in _start at ./client.jl:382
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/src/Parser.jl, in expression starting on line 7
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl, in expression starting on line 5
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/testusing.jl, in expression starting on line 2
Julia Version 0.4.0-dev+2114
Commit ebdaed7 (2014-12-14 08:02 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


>>> test log
no tests to run
>>> end of log

Hi,

In javascript, I stringify an object:

> obj = {"array": [1,2,3], "customer": "type1"}
<- Object {array: Array[3], customer: "type1"}
> s = JSON.stringify(obj)
<- "{"array":[1,2,3],"customer":"type1"}"    [Note: No escaped double quotes.]

and can parse it:

> JSON.parse(s)
<- Object {array: Array[3], customer: "type1"}

I get back the same object I started with. I think this seems reasonable.

However, if I "post" the stringified object to a Julia server and try to parse it, I obviously get errors because Julia is expecting the double quotes to be escaped.

Is javascript being too loose or is Julia being too tight? Is there some way for me to easily stringify javascript objects so they can be consumed by Julia? Or is there some way to get Julia to consume stringified objects from javascript without escaped double quotes?

I would presume this is the primary use case for JSON.jl. Is this something in JSON.jl that needs fixing or is this an acceptable state?

I can't make promises, but if this is something worth fixing, I could give it a shot.

You may want to implement some kind of type hinting system to preserve polymorphism when serializing / de-serializing.

Consider the following scenario:

type SketchPad
   Shapes :: Shape[]
end

abstract Shape

type Circle <: Shape
  Radius :: Int
end

type Square <: Shape
  Length :: Int
end

type HorizontalLine <: Shape
   Length :: Int
end

Serializing an instance of sketchpad would work fine, but when deserializing, type Square and Horizontal line are ambiguous.

The solution that others have adopted is to place a "type hint" field as the first field when serializing.
For example:

"Shapes": [ { "__type" : "Circle", ... ], { "__type" : "Square", ... } ]

I haven't thought through the design aspects of this, but I can tell you that supporting polymorphism in json deserialization is a pretty critical need in LOB applications.

[formatting – @StefanKarpinski]

Nothing too egregious missing at a glance, but could be a fun little project for someone.

I'm surprised this hasn't been asked before but I can't find a question/issue about it.

It would be great to be able to specify and indent (in number of spaces) so the output was "pretty".

I think this is the fundamental difference been machine only JSON and human readable JSON so would be a great addition.

For an explanation of what I mean see the python JSON docs on indents.

The master branch works. But when using the latest tagged version, I see:

ERROR: type: non-boolean (Void) used in boolean context
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in include at ./boot.jl:242
 in include_from_node1 at ./loading.jl:128
 in anonymous at no file:31
 in include at ./boot.jl:242
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:312
 in _start at ./client.jl:393
while loading /Users/dhlin/.julia/v0.4/JSON/src/Parser.jl, in expression starting on line 7
while loading /Users/dhlin/.julia/v0.4/JSON/src/JSON.jl, in expression starting on line 5

This issue has been resolved in latest master, which was not bumped yet.

Hey, I'd kind of like to bump the sha in metadata again. In general, would you prefer I posted requests here for that? or is it alright if I submit pull requests directly to metadata.jl?

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

• On 2014-09-28 the testing status was Tests pass.
• On 2014-09-29 the testing status changed to Package doesn't load.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Package doesn't load. means that PackageEvaluator did not find tests for your package. Additionally, trying to load your package with using failed.

This error on Julia 0.4 is possibly due to recently merged pull request JuliaLang/julia#8420.
This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("JSON")' log
INFO: Installing JSON v0.3.8
INFO: Package database updated

>>> 'using JSON' log
ERROR: InexactError()
 in anonymous at no file
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at loading.jl:152
 in _require at loading.jl:67
 in require at loading.jl:51
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_3625 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/src/JSON.jl, in expression starting on line 11
while loading /home/idunning/pkgtest/.julia/v0.4/JSON/testusing.jl, in expression starting on line 2
Julia Version 0.4.0-dev+842
Commit e5d8c1a (2014-09-29 06:50 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


>>> test log
no tests to run
>>> end of log

I had something strange happen in PackageEvaluator where it appears JSON created a string like:
"blah blah "blah blah" blah blah"
where the quote characters are unescaped. This caused a problem because JSON couldn't read in the file it created!
I haven't got a minimal test case, just wanted to throw this out there in case it sounds familiar to anyone

This doesn't currently handle carriage returns ('\r') as whitespace (at least when running on Linux). As a result, if you try to process a JSON file with Windows-style new lines, you get errors like:

ERROR: String starting with " expected at position 2: ... "blah": {

It's easy to strip those out, of course, but I assume this isn't the behavior you want?

@samuelcolvin mentioned that he thought Julia's JSON code is slow right now. I wasn't aware of any egregious performance problems, but it's true that it probably hasn't been much optimized.

It would be nice to do some performance benchmarks against C and C++ JSON implementations, e.g UltraJSON, JsonCpp, Jansson, YAJL, and JSON Spirit.

julia> a = [[1 2 3],[4 5 6]]
2x3 Array{Int64,2}:
1 2 3
4 5 6

julia> JSON.json(a)
"[[1,4],[2,5],[3,6]]"

I would expect: "[[1,2,3],[4,5,6]]".

I'm running version 0.3.3.

The following error is encountered when attempting to call the parse function with ordering enabled:

julia> JSON.parse("{\"x\": 3}"; ordered = true)
ERROR: OrderedDict not defined
 in parse_object at /home/christopher/.julia/v0.3/JSON/src/Parser.jl:109
 in parse_value at /home/christopher/.julia/v0.3/JSON/src/Parser.jl:231
 in parse at /home/christopher/.julia/v0.3/JSON/src/Parser.jl:318

The import statement on line 7 of Parser.jl throws the following exception:

ErrorException("unsupported or misplaced expression import")

The fallback OrderedDict function, which should give a warning that DataStructures.jl is missing seems to fail to be realised within the scope of the module.

If we (wrongly) assume that DataStructures.OrderedDict is present, we can avoid the error by replacing the "try/catch" block that deals with any failures to import OrderedDict from the DataStructures package with the following import statement:

import DataStructures.OrderedDict

So it would appear as if Julia is encountering some issues when calling import from inside a try/catch block.

Environment
Julia 0.3.5 (x86_64)
Ubuntu 12.04 LTS (x64)
Both the JSON and DataStructures packages installed.

I have a custom type called Tile, and I'm trying to JSON serialize an array of those.

typealias Face (Int, Int, Int)
type Tile
    name::String
    faces::Array{Face,1}
end

When I try to run json(tiles) where tiles is the Tile array, I get:

ERROR: type: getfield: expected DataType, got Type{(Int64,Int64,Int64)}
 in print at /home/olav/.julia/JSON/src/JSON.jl:53
 in print at /home/olav/.julia/JSON/src/JSON.jl:42
 in print at /home/olav/.julia/JSON/src/JSON.jl:61
 in print at /home/olav/.julia/JSON/src/JSON.jl:42
 in sprint at io.jl:421

I'm running from JSON.jl's latest master branch.

It looks the tuples are causing this, as everything else works as expected.

Thanks.

I have both JSON.jl and DataStructures.jl installed but cannot use ordered=true when calling JSON.parsefile.

julia> import JSON

julia> JSON.parsefile("test.json"; ordered=true, use_mmap=true)
ERROR: OrderedDict not defined
 in parse_object at /Users/marc/.julia/v0.3/JSON/src/Parser.jl:108
 in parse_value at /Users/marc/.julia/v0.3/JSON/src/Parser.jl:230
 in parse at /Users/marc/.julia/v0.3/JSON/src/Parser.jl:317
 in anonymous at /Users/marc/.julia/v0.3/JSON/src/JSON.jl:281
 in open at /Applications/Julia-0.3.5.app/Contents/Resources/julia/lib/julia/sys.dylib
 in parsefile at /Users/marc/.julia/v0.3/JSON/src/JSON.jl:279

julia> using DataStructures

julia> d = OrderedDict()
OrderedDict{Any,Any} with 0 entries

I am running Julia 0.3.5, DataStructures 0.3.5, and JSON 0.4.0 on OS X 10.10.2.

I'm getting a weird error on latest master; anyone else seeing this or did I mess something up?

julia> JSON.parse("{1: \"hey\"}")
ERROR: TypeError: instantiate_type: expected TypeConstructor, got Function
 in parse at /Users/jacobquinn/.julia/v0.4/JSON/src/Parser.jl:324

I've traced it back to this line where I can run the body of the function just fine, but when I try to compile/run the actual method, the error above shows up. As a note, I can also view the output of @code_lowered and @code_typed, but the error shows up when trying to view @code_llvm. See output in this gist

@JeffBezanson

This tries to parse some floats as ints causing errors. At least one example are some numbers written in exponential notation. E.g.: "2e10". A specific example is below:

ERROR: ArgumentError("'e' is not a valid digit (in "1e-06")")
in parseint at string.jl:1106
in parse_number at /home/rgardner/.julia/JSON/src/Parser.jl:460
in parse_value at /home/rgardner/.julia/JSON/src/Parser.jl:385
in parse_object at /home/rgardner/.julia/JSON/src/Parser.jl:195
in parse_value at /home/rgardner/.julia/JSON/src/Parser.jl:385
in parse_object at /home/rgardner/.julia/JSON/src/Parser.jl:195
in parse_value at /home/rgardner/.julia/JSON/src/Parser.jl:385
in parse_object at /home/rgardner/.julia/JSON/src/Parser.jl:195
in parse_value at /home/rgardner/.julia/JSON/src/Parser.jl:385
in parse at /home/rgardner/.julia/JSON/src/Parser.jl:476
in parse at /home/rgardner/.julia/JSON/src/JSON.jl:10

Thanks.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.3

• On 2015-03-06 the testing status was Tests pass.
• On 2015-03-08 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("JSON")' log
INFO: Installing JSON v0.4.1
INFO: Package database updated

>>> 'using JSON' log
Julia Version 0.3.6
Commit 0c24dca (2015-02-17 22:12 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3
/home/vagrant/testpkg/v0.3/JSON

>>> test log
WARNING: (OrderedDict{K,V})(::Type{K},::Type{V}) is deprecated, use (OrderedDict{K,V})() instead.
 in OrderedDict at deprecated.jl:26
 in parse_object at /home/vagrant/testpkg/v0.3/JSON/src/Parser.jl:115
 in parse_value at /home/vagrant/testpkg/v0.3/JSON/src/Parser.jl:237
 in parse at /home/vagrant/testpkg/v0.3/JSON/src/Parser.jl:324
 in anonymous at test.jl:62
 in do_test at test.jl:37
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
ERROR: test error during JSON.parse("{\"x\": 3}"; ordered=true) == (DataStructures.OrderedDict{String,Any})(["x"],[3])
`OrderedDict{String,Any}` has no method matching OrderedDict{String,Any}(::Array{ASCIIString,1}, ::Array{Int64,1})
 in anonymous at test.jl:62
 in do_test at test.jl:37
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
while loading /home/vagrant/testpkg/v0.3/JSON/test/runtests.jl, in expression starting on line 8


INFO: Computing test dependencies for JSON...
INFO: Installing DataStructures v0.3.6
INFO: Testing JSON
================================[ ERROR: JSON ]=================================

failed process: Process(`/home/vagrant/julia03/bin/julia /home/vagrant/testpkg/v0.3/JSON/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: Removing DataStructures v0.3.6
ERROR: JSON had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:718
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:67
 in process_options at ./client.jl:213
 in _start at ./client.jl:354

>>> end of log

julia> using JSON
Warning: using JSON.parse in module Main conflicts with an existing identifier.

The function parse in Main parses a string containing Julia code to an AST Expr.)

Probably the best solution is to simply not export it, so that users call it as JSON.parse. Then, for symmetry, you could rename print_to_json to JSON.print (and not export print).

(On the subject of renaming, it seems more Julian to simply have json(x) instead of to_json(x).)

Suppose you've got a string with multiple json objects in it

json_str = "{\"I\":\"am a computer\",\"beep\":\"boop\"}[44.5,66.9,22.3]"

You end up wanting something that looks like:

function parse(str::String, pos::Int64)
  ....
  v, s, e = parse_value(str, pos, len, tracer)
  return (v, e)
end

Of course you can already call parse(json_str[44:end]), but there isn't a good way to know where one object ends and another begins.

For some retarded reason JSON encodes characters above the BMP as CESU-8 (i.e. UTF-8 encoded UTF-16 surrogates), we need to decode this properly.

Given an array of Date objects (from Datetime.jl), json(dates) returns [{}, {}, {}, ..., {}], while json(map(string, dates)) returns the expected ["YYYY-MM-DD", ...] array. It seems like string/print isn't being called in all cases where it should in JSON.jl

The documentation for how to get the link is here: http://www.appveyor.com/docs/status-badges
The JSON.jl page is here: https://ci.appveyor.com/project/staticfloat/json-jl

I don't think I can get the image link, since I don't have an AppVeyor account. @staticfloat, can you help?

I just got very confused about what release we are on since v0.3.7 isn't tagged here.

Would be useful if a tag were added.

Unfortunately, it seems that the JSON standard doesn't support Inf or NaN, which means that when I try to send such things across the network, the other end complains loudly. I'm unaware of any standard workarounds (I suppose sending something like "1.#INF" could be considered a workaround, but I hate type-instability), so I'm interested to hear your thoughts on the matter.

The reason I bring this up is that speed.julialang.org is very unhappy due to some tests being run only once, having a standard deviation of Inf, and then getting those results submitted to it via JSON. I've since changed the tests to be run more than once, but I would consider this a bug in JSON.jl since it's still technically invalid JSON.

I noticed there is a pretty serious bug in the latest release (0.3.5) in which bare numbers don't parse properly. It has been fixed in master, but maybe there should be a new release so the package manager pulls the fixed version in automatically?

Please enable travis-ci testing for this repository. The .travis.yml file already exists. Someone with admin access to this repo needs to flip the switch at travis-ci.org

No sure if that is a problem with the JSON module or the HTTPClient module,
but I would expect this to work:

julia>Pkg.add("HTTPClient")

julia>using HTTPClient.HTTPC

julia> p = get("http://ip.jsontest.com")
HTTP Code :200
RequestTime :0.555796
Headers :
Transfer-Encoding : chunked
Cache-Control : private
Alternate-Protocol : 80:quic,80:quic
Content-Type : application/json; charset=ISO-8859-1
Date : Sun, 24 Aug 2014 01:21:52 GMT
Access-Control-Allow-Origin : *
Server : Google Frontend
Length of body : 24

julia> JSON.parse(p.body)

^^^^^^^^^^^^^^^^^^^^^^^^^
No result here.
p.body is of type IOBuffer, a subtype of IO.

Instead this needs to be used:
julia> JSON.parse(bytestring(p.body))
Dict{String,Any} with 1 entry:
"ip" => "67.169.75.232"

I thought I had a workaround for this, but apparently not in all cases... so I could use a little help here :)

Essentially, escaping / unescaping things doesn't quite work:

julia> str = "\x16\x02?1\\\x0effffff&@"
"\x16\x02?1\\\x0effffff&@"

julia> d = {"blarg" => str}
{"blarg"=>"\x16\x02?1\\\x0effffff&@"}

julia> j = JSON.to_json(d)
"{\"blarg\":\"\\x16\\x02?1\\\\\\x0effffff&@\"}"

julia> p = JSON.parse(j)
["blarg"=>"x16x02?1\\x0effffff&@"]

julia> str == p["blarg"]
false

I seem to lose some \es along the way

The JSON module is inconsistent in handling strings containing "$":

julia> parse(json("\$"))
ERROR: ParseError("invalid interpolation syntax: \"\"\"")
 in parse at string.jl:1215

@aviks, can you transfer this one too?

Hi,
By trying to connect IPython notebook to julia I came across a diference in JSON parsing than what I expected or what python does. . I haven't read the rfc yet to see who is right.

julia> JSON.parse("{\"code\":\"1\\n2\"}")
no method ref(Function,Int64)
 in parse_string at /Users/bussonniermatthias/.julia/JSON/src/JSON.jl:152
 in parse_value at /Users/bussonniermatthias/.julia/JSON/src/JSON.jl:190
 in parse_object at /Users/bussonniermatthias/.julia/JSON/src/JSON.jl:65
 in parse at /Users/bussonniermatthias/.julia/JSON/src/JSON.jl:248

indead, julia don't expect the \ in front of the \nto be escaped.

julia> JSON.parse("{\"code\":\"1\n2\"}")
["code"=>"1\n2"]

same in python (opposite result)

In [5]: json.loads("{\"code\":\"1\\n2\"}")
Out[5]: {u'code': u'1\n2'}

In [6]: json.loads("{\"code\":\"1\n2\"}")
traceback

Thanks.

https://github.com/JuliaLang/JSON.jl/blob/7f5266221deb2063c83dee28a49d251d71f5cc46/src/Parser.jl#L63-L71

I was getting errors about indexing into a non-valid character from this. How should this be written to avoid indexing into the string like this?

Hey there,

Running on OS X 10.9.5, Xcode 6.0.1 (6A317), Julia Version 0.4.0-dev+1313 - Commit 4f98c92 (2014-09-29 09:26 UTC)

I'm receiving the following error:

julia> using MAT
ERROR: InexactError()
 in anonymous at no file
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:54
 in require at /Users/rje/julia/usr/lib/julia/sys.dylib
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:54
 in require at /Users/rje/julia/usr/lib/julia/sys.dylib
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:54
 in require at /Users/rje/julia/usr/lib/julia/sys.dylib
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in include at ./boot.jl:245
 in include_from_node1 at ./loading.jl:128
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in require at /Users/rje/julia/usr/lib/julia/sys.dylib
while loading /Users/rje/.julia/v0.4/JSON/src/JSON.jl, in expression starting on line 11
while loading /Users/rje/.julia/v0.4/Homebrew/src/Homebrew.jl, in expression starting on line 9
while loading /Users/rje/.julia/v0.4/HDF5/src/plain.jl, in expression starting on line 28
while loading /Users/rje/.julia/v0.4/HDF5/src/HDF5.jl, in expression starting on line 1
while loading /Users/rje/.julia/v0.4/MAT/src/MAT_HDF5.jl, in expression starting on line 30
while loading /Users/rje/.julia/v0.4/MAT/src/MAT.jl, in expression starting on line 25

The offending line is:

const unescaped = Bool[isprint(c) && !iscntrl(c) && !(c in ['\\','"']) for c in '\x00':'\x7F']

It appears the problem is with the range '\x00':'\x7F'. For example,

julia> for c in '\x00':'\x7F'
           println(c)
       end
ERROR: InexactError()
 in anonymous at no file

Trying to see now what in base Julia might have caused this.

Best,
Rob

Cf ML and bug on IJulia,

I suppose the following is not what is expected :

julia> using JSON

julia> x = ['a'=>1 ,'b'=>{}]
['a'=>1,'b'=>{}]

julia> json(x)
"{\"a\":{},\"b\":[]}"

Is there a way to parse a string whose content is a javascript function?

I find this article maybe useful

It seems to me the real problem behind PR #29 (and probably issue #30) is that the parser is written to depend on AsyncStream in an odd way. It should not use readavailable, and it should certainly not access io.buffer directly (this is a bug). I'm also not sure the bracket counting code works --- won't it be confused by possible unmatched brackets in strings?

Wes' patch #29 is an improvement, but it should write the characters to an IOBuffer and use takebuf_string instead of join.

I've been using (testing) the changes made in the last few weeks quite a lot. I think it's about time to bump the sha1.

Lacking a more formal process, if no one objects or goes ahead and does it, I'm going to submit a pull request tomorrow.