What is Reddit's opinion of
JSON?
From 3.5 billion Reddit comments
➔ JSON website
By popularity on Reddit, this Service is:
77 reviews of this app found across Reddit:
> JSON grew out of a need for stateful, real-time server-to-browser communication > > https://en.wikipedia.org/wiki/JSON#History
JSON was only ever designed to be written and read by machines. It is not a human-friendly format: it is not especially easy to read and it has weird and arbitrary rules that hamper our productivity (contrary to what http://json.org/ says). The format makes it difficult to write good tooling. To help us with that somebody made JSON Schema, which is like XML Schema except it never left draft status and the latest one <em>expired</em> three years ago.
INI, TOML, YAML, and XML are all perfectly human-friendly and suitable for configuration. Of those, XML has the best tooling by far whereas INI is somewhat under- or unspecified.
JSON's two main advantages over XML are 1) that it's more compact and therefore cheaper to serialize, and 2) first-class support in browsers.
A lot of apps will download data when they are first opened up. This is usually JSON.
In their JSON feed they probably added something like this: > { "show_splash_screen": false }
The app was then waiting for that value to be true. When Google changed the value (flipped the switch) in their feed, the code to display the splash screen would run.
ECMA-404 is essentially the same thing as the RFC, and even easier to read: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
Although it's practically just a copy-paste of http://json.org
You're a 3rd year Computer Science student and you don't know about regular expressions, context-free grammars and how they relate to programming? For the sake of being charitable I will assume that you just don't recognise this style of diagram then, which I suppose is imaginable.
For those who don't know, regular expressions describe simple structurs of text, while context-free grammars describe the programming languages we use and how to parse them (also describe document formats like JSON, XML, etc). They lead into recursively enumerable languages, Turing machines etc. which are an essential mathematical abstraction of the machines we work on.
http://json.org/ has the same kind of diagram to describe how JSON is structured.
We pretty much standardized on using JSON.parse() years ago. You can get the source for that function from json.org, and practically every browser has it built in anyway.
Calling eval in JS is actually more open to abuse and bad for performance as its Python counterpart. Python can at least sandbox the code passed to eval.
Don't use eval! It's a security hole in pretty much every language that supports it.
The technical details of what "JSON" is can be found here: http://json.org/
In short, you can store Object Literals (http://www.dyn-web.com/tutorials/object-literal/) in an array in a text file (*.json) which can be loaded with an AJAX call (XMLHttpRequest for vanilla, or jQuery.getJSON if you're using that library).
The advantage is that you can store your static data in the same object structures being used in your application (which has a number of advantages for initialising your application).
(If Local Storage is an option - see: http://www.w3schools.com/html/html5_webstorage.asp) it's possible to keep the object cached between sessions.
You may need to refactor your code to take full advantage of storing your data in an external json file, but it may be worth it.
Also, if you happen to have access to Node, PHP or similar on your server, you could create a relatively simple RESTful API to update, edit, delete, etc. entries in the JSON file.
Ajax is not a language. Are you perhaps talking about JSON? JSON requires double quotes. Some environments might cope with invalid JSON that uses single quotes, but you should not rely on that.
This is not a good example. Json.org has a page dedicated to comparing xml with their json equivalents here:
For me xml/json look about the same. The big benefit for me is that JSON a very succinct data format and all the languages we use translate it into directly into a data structure the language can consume natively. This is more of an issue with the actual languages we use over xml / json however.
JSON is pretty important (lots of reasons, including but not limited to the fact it tends to be a lot easier to consume JSON in web apps versus XML.)
Fortunately, .NET has an OKish Json serializer/deserializer, and newtonsoft's JSON.NET is pretty good.
Really, unless it's for a specific academic exercise (i.e. Write a json reader or writer) you really SHOULD use a library. Most shops won't write their own JSON library because:
- It's already been done well enough
- The library has probably had more people using and fixing it than anything we'd do in house.
Also, when it comes to WebAPI and other applications, you don't even have to do much of ANYTHING to use JSON. MVC will be able to look at the headers of the message, determine it is JSON, and respond accordingly.
Most 'typical' use cases are handled by parts of the .NET framework. As I said, WebAPI doesn't even require any work to consume JSON. You can easily SEND Json to a webservice from .NET via the HttpClientExtensions.PostAsJsonAsync() method. This will take a POCO, turn it into JSON, and perform an HTTP Post with that data as the payload to the URI Provided. You an also use it to specify the object type to map the response to, provided you know what the data in question IS. (Worst comes to worst, start off as expecting a string back, take the response, Copy to Clipboard, and paste in visual studio as a class as shown here: http://blogs.msdn.com/b/webdev/archive/2012/12/18/paste-json-as-classes-in-asp-net-and-web-tools-2012-2-rc.aspx ). Visual Studio 2012 and up have this built in, makes it easy to get a response and make a POCO out of it if none was initially provided.
http://json.org/ has information on JSON itself. If you have to write your own parse, that would probably tell you most/all that you'd have to know.
In 1.8 all the models are stored in JSON and you need one JSON file or every single possible state of your block. Apparently fire requires something like 75 different JSON files.
The new model system was discussed on /r/feedthebeast in this thread. Maybe I and /u/Watchful1 got the math wrong.
[Edit] Wrong subreddit
Wait, now the string has changed. Were those outermost double quotes actually part of the string? That's also invalid JSON, and you'd have to strip them if that's the case, but are you sure you didn't accidentally add them with something you did, like maybe a stray repr()? And why did the single quotes change to double quotes? Here's the JSON spec.
It's a JSON API (there are more, e.g., http://services.runescape.com/m=itemdb_rs/api/catalogue/detail.json?item=1515).
I'm not much of a Java guy but I'm sure there is a library for parsing JSON. http://json.org/java/ might help.
I noticed one thing not logical with JSON (from http://json.org/example.html):
{"widget": { }"text": { "data": "Click Here", "size": 36, "style": "bold", "name": "text1", "hOffset": 250, "vOffset": 100, "alignment": "center", "onMouseUp": "sun1.opacity = (sun1.opacity / 100) * 90;" } }}
The same text expressed as XML:
<widget> <text data="Click Here" size="36" style="bold"> <name>text1</name> <hOffset>250</hOffset> <vOffset>100</vOffset> <alignment>center</alignment> <onMouseUp> sun1.opacity = (sun1.opacity / 100) * 90; </onMouseUp> </text> </widget>
..it seems like somehow information is lost in the JSON version, making no distinction between attributes and node elements.
XML has complexity you don't really need for the structured data case. The whole document model where you put tags in between content only makes sense for hypertext, not simpler structured data. Also I don't like the verbosity of having to repeat every tag name. You can work around that by using attributes instead of elements.
Now that I'm thinking of attributes, I'm less sure what I think. There are some interesting examples here. The "menu" example is downright nice, but the "web-app" one becomes a horrorshow in XML. Maybe the problem with web-app is that the keys in the "init-param" list are considered data instead of attributes from a fixed schema, so they need to be done using elements instead of data? Still, it could use <param name="foo" value="bar" /> instead of the five lines for each, so I guess it's a bit iffy example...
Also, roguelikes do use a lot of text, and it often gets procedurally processed somehow, so you might find XML's hypertext document features useful as well.
(What I'm actually using right now is neither of those, but RON is specific to Rust so it's not very useful in a C++ thread.)
JSON is a subset of Javascript syntax, so if you know JS, you automatically know JSON. JSON is fairly simple though, so even if you don't know JS, you shouldn't find it too hard to learn. Essentially:
String literals are done the same way as most programming languages - in double quotes, with \ as the escape character
Numeric literals are similar
Boolean literals are true and false
Arrays are enclosed in square brackets, with each element seperated by a comma - for example:
[1,2,3,"hello",[1,2]]
Objects consist of name/value pairs in the form name:value. The pairs are seperated by commas and enclosed in parentheses. The name is a string, and the value can be any JSON value. For example:
{ "a":123, "b":[1,2,3], "c": { "a":1, "b":2 } }
null is also a valid JSON value
And that's pretty much it. There are complete syntax diagrams here;
> I heard JSON can be used with Java and Python, as well.
JSON can be used with any programming language.
> So is it possible to learn JSON without knowing JS?
Yes. And there really isn't all that much to learn - JSON is light-weight by design.
> And if so any material you would recommend?
http://json.org/ and http://en.wikipedia.org/wiki/JSON give you enough information to start with
> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999.
It's JSON, a well established way to send data, and there's lots of methods to easily pull information out of it.
If someone's using the gw2spidy API, that's either JSON or CSV, and there's all kinds of websites already using that data in fun ways. Scroll down to the examples/guides here: https://github.com/rubensayshi/gw2spidy/wiki/API-v0.9
Bing API primer: http://www.bing.com/developers/s/apibasics.html Use Jersey to make the service calls: https://jersey.java.net/ Use Java JSON to parse the JSON results into java objects: http://json.org/java/
JSON is basically a string representation of an object.
The exercise is basically passing the dict as a string between functions. Your jobs is to convert the string to a python dict, add the values, and serialize it to json and return.
To understand simplejson a little better: simplejson — JSON encoder and decoder
I don't want to complete the exercise for you, but if you have more questions, I can help.
Sure, no problem. It's mostly just unreadable because I tried to hit all the features at once!
JSON is a format that lets you take programming-type objects, like a list or a dictionary, and encode them as text. You can encode pretty much anything as JSON.
MCP is the open standard protocol I'm working on, which allows you to connect to a worldwide network and share document updates. These documents can hold any JSON object, have a permissions system built in, and it's set up so you can't download an out-of-date copy of the document or have "write collisions" (where two people try to write at the same time, so nobody knows what it actually should be).
Orchard is a proof-of-concept MCP node with a friendly web interface. It encrypts all your data when storing it to disk, and part of MCP is that all data going through it is encrypted anyways. There are no central servers, and it's designed so that the network works just as well with just you and your friend, as it does years down the road with thousands of people on it.
The point of it is not so much MCP, though. That's the underlying protocol. The important thing is what you can build on top of MCP, like a distributed version of Google Wave, or a software repository that supports live typing for code collaboration in real time. It's even possible to have a P2P image editor made out of nothing but a web page!
This is addressed by another ECMAScript proposal, modules. Here's an example:
> > module JSON from 'http://json.org/modules/json2.js'; >
The symbol 'JSON' here is bound in an equivalent manner to a let construct - i.e., it is local to the function where the module statement occurs. If another function or module elsewhere imports a different JSON, or a different version of JSON, there will be no conflict because that will produce a different binding in that local scope.
Here is some more information:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples
HTTP GET to https://www.reddit.com/r/datahoarder/new/.json -> .data[].children[].url to get the external asset
Iterate the above, utilising what you said &after= with .data.after.
The format Reddit returns is JSON:
It can be parsed in pretty much any language, for example in Python (I'm not a Python programmer):
import requests; headers = {'User-Agent': 'YourBotNameHere'}; URL = "https://www.reddit.com/r/DataHoarder/comments/.json"; commentRequest = requests.get(url=URL, headers=headers); commentResponse = commentRequest.json();
You can then query it via:
commentResponse['data']['after']
Or wahtever you need.
JSON although it got its start in JavaScript it extends into almost any language you can think of. Scroll down a bit on this page and you'll see all the programming languages supported. The scripting language for the game, Lua, is in that list too.
> Humans writing JSON to be consumed by machines is far from what Crockford was thinking when he came up with the format.
First paragraph:
"It is easy for humans to read and write. [... It] uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others."
He didn't include comments because he feared that some people would abuse it for directives and things like that.
https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr
People have done exactly that and it caused compatibility issues. Very funny, Crockford. Very funny indeed.
There is no JSON specification? What about http://json.org/? Looks neatly specified to me. It does let out what type the parsed numbers are (IEEE double? int64_t when there are no decimals?). Did he perhaps mean CSV? For that there really is no specification and it is true that for that every parser does things differently. Most CSV parsers have options for parsing different flavors of CSV, though.
That massive list of text is the JSON file. JSON looks like this (source):
{ "glossary": { "title": "example glossary", "GlossDiv": { "title": "S", "GlossList": { "GlossEntry": { "ID": "SGML", "SortAs": "SGML", "GlossTerm": "Standard Generalized Markup Language", "Acronym": "SGML", "Abbrev": "ISO 8879:1986", "GlossDef": { "para": "A meta-markup language, used to create markup languages such as DocBook.", "GlossSeeAlso": ["GML", "XML"] }, "GlossSee": "markup" } } } } }
> or at least how its been implemented in browsers.
Numbers, booleans and null are all valid per spec. Any implementation that doesn't support that, just isn't spec-compliant (and thus can be considered broken).
JSON.stringify() converts an object to a string representation. For example:
> var foo = {}; undefined > foo.bar = 42 42 > foo.baz = 'blah'; 'blah' > JSON.stringify(foo) '{"bar":42,"baz":"blah"}'
The resulting string is what you'd have to write in a JS file to recreate that object. This is a format known as JSON, which has become a cross-platform standard.
The opposite of JSON.stringify() is JSON.parse(), which takes a string and parses it as JSON, returning the resulting object. These two form a matched pair. The JSON object by itself is useless, it's only there are a form of namespacing for those two functions.
Recursion enters the picture when you have nested objects. Picking up from where the above example left off, if you wrote:
> foo.quux = {abc: 123, xyz: 999} { abc: 123, xyz: 999 } > JSON.stringify(foo) '{"bar":42,"baz":"blah","quux":{"abc":123,"xyz":999}}'
The resulting string contains the entire object, including any nested objects. Recursion is how you usually write such a function.
JSON itself is pretty simple - the full spec is here
Simple explanation:
A value in JSON can be:
- a string (
"foo") - a number (
42) - a boolean (
false) - an array (
["foo", 42, false]) - which is an ordered list of values - an object (
{"myString": "foo", "myArray": ["foo", 42, false]}) - which an associative map of string based keys to values - null (
null)
That's pretty much all there is to it, everything else is specific to the domain. In the case of CloudFormation templates, there's a lot of CloudFormation specific key names etc you'll need to know - the full reference is here.
Just FYI for anyone who don't know:
You see that info in that format because it's supposed to be consumed by an application. That format it's called JSON.
Someone could easily parse that information and present it in a way a user could understand it.
Hijacking/Shameless self promotion:
I had started a plugin module for BH which would log the contents of your inventory/stash to a file in a (customizable) reddit friendly manner.
I never did get to finish it though as it still doesn't export set items correctly and there are some other bugs to work out, but its not too far off. Not sure if there would be interest in it or not, but I'd bet that this route would be safer than allowing kolbot (even if its just a subset of the features) on slash.
Here is a sample of the output:
Annihilus (L99)
> 14 all-stats
> 16 res-all
> 6 additional xp gain
Small Charm of Vita (L73)
> 18 Maximum Life
Captain's Grand Charm of Burning (L66)
> 3 Minimum Fire Damage
> 7 Maximum Fire Damage
> 1 Offensive Auras (Paladin)
Gheed's Fortune (L75)
> 33 mag%
> 152 gold%
> 14 reduces vendor prices
Spirit Kurast Shield (L80)[4]
>168 defense
> 100 mana
> 25 cast3
> 7 abs-mag
It tries to condense the stats and only includes those that are actually variable on set/unique/runeword.
It also supports exporting as JSON, and the final formatting relies on mustache templates to transform the json into what you see above.
{"lastName":"Smith","children":[],"height_cm":167.600000,"address":{"city":"New York","streetAddress":"21 2nd Street","state":"NY","postalCode":"10021-3100"},"isAlive":true,"phoneNumbers":[{"number":"212 555-1234","type":"home"},{"number":"646 555-4567","type":"office"}],"firstName":"John","spouse":null,"age":25.000000}
I've been working on a JSON-parser in the C programming language and this is the output after the first run of my parse-and-output test program! I'm quite proud of it.
http://json.org/ explains what JSON is.
Basically, it's a bunch of name-value pairs or simply a list of literals/javascript objects. So you can have something like [{'question': some_question, 'answer': some_ answer}, ... ]. You can pass this object to the the server, and have the server parse it and take what ever information is needed. If you're using JQuery, checkout JQuery's ajax documentation. I haven't used ASP, but look for ASP handling ajax calls.
I know this may seem like a lot, but once you get the intuition of this pattern you'll use it regularly! :)
Knowing how to interact with JSON via python might solve your problem, but you might find it useful to take a moment and take a look at this page. JSON is a data format that is quite ubiquitous nowadays, particularly when it comes to APIs. It might be useful to understand what it is. These simple diagrams describe it, in its entirety.
> Optional quotes around some keys, empty arrays (or objects), different cases of true/false, integers as values, keys made up of all numbers that can't be cast to integers, hanging commas, etc...
What you're describing IS NOT JSON. The standard is pretty damn simple - what makes it a standard is that you can't invent your own arbitrary rules.
A lot of what you go on to talk about has nothing to do with parsing. It's up to you to determine how you want to interpret the data. No existing library can do that for you.
NOTE: JSON is intentionally a lot stricter than Javascript, which does allow some of what you're talking about. Since you don't seem to realise there's a difference, you absolutely should not write your own JSON parser. At least until you've read the standard.
ECMA-404 only mentions for arrays to be ordered, and http://json.org as well as RFC 7159 refer to objects as "an unordered collection of zero or more name/value pairs". I understand that stability and a known ordering may be valuable in many scenarios, but such an ordering is out of scope of JSON.
You might want to also learn how to handle JSON as well, since the reddit API uses JSON. It's very easy to learn if you read http://json.org/ and if you're looking for someone to help with JSON or your app, I may be available in the evenings -6 CST, past 6PM to 10PM or so. I joined #WPDev as it says in the sidebar which is of course empty, but hey if you wanna bug me, feel free to join that.
The phrase you're looking for is "file format", not "programming language".
Anyways, the call to Valve's WebAPI supports retrieving the item schema in three formats: JSON as mentioned by the other two responses, XML, and Valve Data Format (VDF, KeyValues).
The items_game.txt file that is available from the game's installation directory uses VDF.
If you're planning to work with the schema and have the option of choice, the best option is to use JSON, as there are readers for it in almost whatever language you program in, and most other TF2-related APIs (trade.tf, backpack.tf) also use JSON. As it uses a subset of JavaScript, JSON can also be read through JavaScript in-browser.
That doesn't look like valid JSON to me, and the railway diagrams at http://json.org/ seem to disallow it as well. It is, however, valid JavaScript that would generate a JavaScript object containing references to a GLatLng.
Please don't recommend pickle for something like this. It's more powerful than needed, produces a file that can't be easily examined externally, and isn't secure. Much better to use a simple, human-readable format like JSON that has explicit support in the standard library and has no problem representing common data types.
I lied, the command is not reduce by a half, but pretty much close to 30% if you use some other little techniques
> /give @a written_book 1 0 {pages:["{\"text\":\"\",\"extra\":[{\"text\":\"Hello\",\"color\":\"red\"}]}"],title:Book,author:TellrawGenerator}
This kind of generator is probably using already made JSON parser (nothing bad about that), but Minecraft is not JSON. JSON have some strict syntax rules that Minecraft sometimes don't follow, or don't support. Here is one of the rule you must follow when using " inside commands (from the wiki):
> Double quotes have to be used if the String contains commas, curly brackets or square brackets > String can't but empty :, will not work, use :"", or :'', > To use double-quotes inside Strings, the quote is escaped by a backslash (\")
This generator respect this rule(he put " everywhere); but if you want a short command, you can do this :
> /give @a written_book 1 0 {pages:["{text:\"\",extra:[{text:Hello,color:red}]}"],title:Book,author:TellrawGenerator}
Now we have a shorter command, be we still have this annoying \"\". And since " and ' do the same thing, you can finally do :
> /give @a written_book 1 0 {pages:["{text:'',extra:[{text:Hello,color:red}]}"],title:Book,author:TellrawGenerator}
What does it look like in Notepad or whatever text editor? Should be something like this: http://json.org/example
The AllSets-x.json files are probably just copies of the original (like if you downloaded it twice, it will automatically rename the second tone to Whatever-{number}.json.
Reddit works with a JSON api you can learn about here
You could then use something like JSON in Java to manipulate the returned json data into objects.
I strongly advice you not to use built-in serialization, especially if you do not know its tricks and pitfalls well.
Instead use jackson library and serialize your objects to json - this approach will remove many problems with classes compatibility and also it will make your transfer easier to debug even manually.
There are already JS parsers for about 47 languages (listed on http://json.org/) and you can write a new one in an afternoon. For your Enterprise Service Bus, you can stick JSON inside an XML tag and save yourself a lot of headaches. :)
It's sadly been a long time since I've done any .NET. This should help a little more than the blog post though: https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-use-dom-utf8jsonreader-utf8jsonwriter?pivots=dotnet-6-0#use-jsonnode
> but if using JSON would be easier
Ah, so that's the thing, the serialization is called JSON (the full format of it can be found at http://json.org). To use it inside anything useful, you need to parse it somehow, typically using a pre-made JSON parser like the one above :).
> You see, when you are dealing with file formats, there is typically an actual, defined format. YAML, XML, JSON, and many others give a lot of information about how to serialize data, including character data, into raw bytes.
I don't know where you got this, because for example JSON specification states
> A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.
You can totally have a JSON string containing non-ASCII characters, and how they're encoded is not specified. In fact, the entire JSON file may be encoded using UTF-16, SJIS, or whatever other character encoding humankind ever invented. The JSON spec is completely silent on the question of character encoding.
I'm aware that the aeson library only accepts UTF8-encoded inputs... actually Latin1-encoded inputs, now that I've checked the source. The UTF-8 assumption is good enough because you can always convert your UCS-2-encoded JSON file into UTF-8 before feeding it to aeson. The Latin-1 assumption not so much. But generally, you still need to be aware of the multitude of possible character encodings. This is not a problem with Data.Text.IO, it's a problem of legacy encodings.
> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
According to http://json.org/ the x character is not a valid escape sequence. I am handling u by simply leaving it encoded. There is a note to that effect right at the top of the document right in the source code.
NaN is not valid JSON, the same goes with Infinity and -Infinity.
How is it that you are an expert about these things, when even a cursory glance at the spec shows otherwise?
The carriage return is "\n" like in most of programming languages, more info here JSON, Discord doesn't use html tags anywhere, only markdown and using html tags in body may cause broken json. Also you may need to check applet logs for errors. 400 - broken json, 401 - url is not full, 404 - webhook was deleted.
The JSON java module from http://json.org, by Douglas Crockford, will read a JSON input and turn it into a navigable structure. It doesn't make maps.
The javax.json API offers a streaming event parser, which you could use to populate nested lists and maps. It also offers a destructuring object builder API, which creates a navigable object with values, structures, amd arrays of the same.
> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
JSON is a way of storing objects in human-readable text. Use accounts > backup to export your wallet JSON file from your Ethereum wallet, and do the same to import it.
JSON is relatively simple. There is a complete grammar here that fits on about a page. (Crockford used to satisfy himself by pointing out that he could fit it all on a business card.)
Start off with the basics. Do you understand what the question is asking of you? Have you ever written a parser before? Do you see what the resulting data structure of parsing a JSON document would look like?
> I told him that [...] JSON is not a storage, but a data exchange format.
You're correct:
> JSON (JavaScript Object Notation) is a lightweight data-interchange format. > > http://json.org/
It's not really clear what you're asking about here. This looks like JSON. JSON is not specific to JavaScript, it's a general data interchange format that's used by lots of languages and APIs. Are you asking how to take this JSON and access the value stored under the percent_complex_words property? Or something else? What do you mean by "the definition"? Are you asking what the value 20.0163 represents? (Some googling suggests it's calculated as part of the Gunning fog index, where a complex word is defined as a word with three of more syllables, but without context it could be really anything.)
I like the idea of "what you can do in Kotlin" And this is clearly a good representation of that.
I also like that possibility that strong typing allows you to constrain the type of some data in a strongly typed language. This is a major problem with JSON (well javascript really ). It means people do ( or have to do ) things like this http://json-schema.org/ GAH! So +1 on avoiding that.
However, I guess my point on this is that, for all it's faults, JSON is a major lingua franca. There are parsers in probably every language (bottom of http://json.org/ ). So unless there is a massive advantage to a new format which is also cross platform, I don't see myself using it.
You could put all the data on a single line using tabs ('\t') to separate fields, and convert any literal tabs of text into something if needed...
Forget about it! Try JSON instead! JSON should fit your purpose and is pretty popular. True, it can't (easily) do things XML could but that's another battle...
Go here. The top/mid of that front page talks about the grammar and shows language grammar "train track" diagrams, like an old-fashioned Pascal textbook would do. It would be good to study such things, but scroll to the bottom. Free libraries for many languages!
You didn't say what language you were using, but they probably got something there you can use.
~~The example code-'s impliment a parsing state machine and a demo program to use it. The parsing code might be of interest if you're studying computer science... But mostly you'll just include in your projects and use in similar way to demos.~~
EDIT: I was looking at this. It has extra computer science in it to help library writings make thier own in other languages. Most aren't this technical.
Of course there are always other ways of doing things too. Hope it helps.
It basically means you can write object instances to a file in JSON format, and load them the next time you run your game (or whenever you want them, really).
I was working on an iOS project that allowed the user to place items in a house. The configuration of the room was then saved to a file on the device. Npcs also had houses that used the same structure, and were loaded from Asset Bundles that could be downloaded from my server. Players could also connect to other player's houses and wander around, so the data needed to be easily transferred over the net.
I initially tried ScriptableObjects, but Apple's developer guidelines (along with Unity's assorted restrictions) prevent you from including ScriptableObjects in asset bundles. Furthermore, ScriptableObjects can only be created at compile-time, meaning you can't use them for saved games. I ended up writing an XML serialization system, and a lazy-loading resource manager for it, but I would have much preferred JSON, as I find it more pleasant to work with.
Do that. It'll be easier to work with and learn. The official website describes it succiently.
Or for a quick example:
{ "thisIsAField": "Must use double quotes", "anArray": [ "Array item 0", "Array item 1", "Array item 2" ], "arrayWithObjects": [ { "field": "Yo" }, { "field": "Hellooooo" }, ], "aNumber": 123, "aBoolean": true, "aNull": null }
Everything inside the {} is an object. Objects can have fields. Everything inside the [] is an array item. Then there's numbers (floating point only), booleans (true/false), null, and strings ("in double quotes").
This closer models a programming language (in fact, it's valid JavaScript). All fields and array elements are comma separated. Field names are any valid strings (but usually you'll name fields to be valid identifiers).
You'd use a JSON parser like Json.NET. This has a strict JSON parser, but for simplicity, I'd recommend at least starting with a weak JSON parser. For the above JSON, if you wanted to get arrayWithObjects[0].field, you'd use simply:
dynamic json = JValue.Parse(jsonText); (string)json.arrayWithObjects[0].field // Must cast so that C# compiler knows type
Note that JSON objects are dictionaries. This makes them very easy to work with.
EDIT: Or you could use the built in JSON parser instead of a library. I don't think it has a dynamically typed option. Here's a little example of using it. It takes a bit more setup as you must provide statically typed classes that serve as the blueprint for the JSON objects (as is really the norm in C#), but will provide the same basic way to use the data once parsed (and no need to cast like in the above example).
I believe this is an example of a "card" stored locally as some sort of JSON (?) object.
At some point you're going to want to move your molecule list out of the code base into a file on disk. You could use a plain text file and parse it yourself but I recommend looking into JSON if you're not already familiar. Python has a built in module for <code>json</code>. You wouldn't need to modify your code by much since a dict is JSON serializable. Just need to add in a function that loads the json file.
> never explained how you know when to do what other than "experience".
As with all things in life :)
>Okay, so it sounds like my current Battleship program having 1 solution with multiple projects (Test, Logic, UI (turns out I put Board as a class within UI despite not intending to) ) was not badly done.
Well... you could have one part Board as a class in the Logic/Controller portion... and another in the GUI portion. Keep track of where the pieces are will be different than drawing them and placing them on the screen.
> Are JSON and NUget related?
Nuget is a package manager. It'll download packages (Like a package that handles JSon) and dependencies that are needed for you (say, JSon depends on another package that handles files).
Json is a file-interchange format: JSON example... like XML or CSV (comma seperated values). [
> Is there a difference in Visual Studio to right clicking on a Project then adding a Class which appears on a different tab versus staying on the same tab but adding a new class outside of the existing class codeblocks?
Programmatic-ally, it won't matter. The program can find it.
But programming is as much about keep track of where stuff is for YOU and your co-workers Multiple classes in a single file - Good or bad?
Well, I hope I wasn't too discouraging. There's lots of different ways to implement parsers, you probably want a "hand rolled" recursive descent parser. If you can't follow the sample C code without explanations you can probably find something online now that you know the search term. There's also parser combinators, tools that generate parsers, etc.
The main problem with what you were doing is that you (usually) can't skip input and get a valid result, which is what my print example tried to show. If you just use std::find it will skip over the ", which changes the context of "print" from being a function name to just an unimportant character sequence within a string. You have to examine every character if the input in order.
As a minor recommendation, you might also try starting with a simpler grammar. C is simple as far as languages go, but it's still got some weirdness and corner cases. I think JSON is a good place to start: the entire specification fits on one page and there are no real gotchas. It's also very common and there are lots of implementations in any language you want that you can compare your parser to once you're done. But that's up to you.
The original code is something to do with JSON parsing. A JSON value can be one of the following:
- string
- number
- object
- array
- true
- false
- null
Where an object is a collection of name/value pairs (in Objective-C and Swift, this is a NSDictionary / [String: AnyObject]), and an array is a list of values (including objects).
/u/ttflee/ was making an enum for the various JSON value types, though I'm not quite sure for what purpose.
I'd say your newest layout is your best yet because there's no point in having 40 pages for all these images, haha.
As something to move forward your javascript, I'd probably look into JSON objects. If you created a JSON object for all these images that included a title, description, etc... you'd be able to easily parse through it as if it was a simple array like you have here, but allow you to include more data and, frankly, it'd be easier to look at / read / update!
Start here: http://json.org/example
You can put the JSON in it's own JS file and then call with AJAX like this: https://mathiasbynens.be/notes/xhr-responsetype-json
This starts setting you up to understand a bit of things like Angular JS and how they would get / use their data.
JSON stands for JavaScript Object Notation. It is the same notation in string format as it would be for creating those object literals in JavaScript. The specifications are very simple and you can learn all you need to know by reading this page. For anymore advice you'll have to tell us which language you're planning on using to read the file, make the object , iterate through the object t and write to the database in. Pretty much every language has a JSON parser, so just pick the one you're most comfortable with.
This took me about 20 minutes, just translating the spec on http://json.org into Perl regex notation. I've done several tests, it seems to work:
^(?x:(?<value> (?<object>\s*{\s*(?<mapping>(?&string)\s*:\s*(?&value))(\s*,\s*(?&mapping))\s}\s*|\s*{\s*}\s*) | (?<array>\s*[\s*(?&value)\s*(,\s*(?&value))]\s|\s*[\s*]\s*) | (?<string>\s*"(?:[^"\\p{Cc}]|\["/\bfnrt]|\u[0-9a-fA-F]{4})"\s) | (?<number>\s*-?(?:0|[1-9][0-9])(?:.[0-9]+)?(?:[eE][+-]?[0-9]+)?\s) ))$
This could be made somewhat shorter, but I went for clarity. The main ugliness is all the \s everywhere to fulfil the "whitespace between any tokens" requirement; remove that, and it's quite readable. The hardest part was the \p{Cc} bit; that's needed to handle control characters correctly when using Unicode input.
I'm thinking of porting Simplectic Noise to C++. Do you have a specific place where you would want various ports to be stored?
It would be great if there was a complete list somewhere of all the ports, like json.org has at the bottom of their page!
The Javascript Object Notation is correct in assuming that you were passing a (badly formatted) integer object.
Python errors at characters 7-11 (the part that your example truncated).
http://json.org/ shows that objects start with a {, arrays, a [, and numbers (which you seem to have here) just start with digits.
What you have shown is how php deals with numbers that contain more than one decimal point.
var_dump(json_decode('"192.168.1.1"'));
That's the correct way to represent a string in php. An IP is not an integer, nor is it any other type of number. It's a string. It just so happens to consist of digits and delimiters, and we just so happened to borrow the same delimiter that numbers use.
provide some mini-example of your setup and functionality requirements. A picture is worth 1000 words.
reading json is trivial, you import json module in python, feed it with the plaintext, either from string or directly from file and it returns a data tree that can be easily traversed.
example:
#!/usr/bin/env python3
import json
example_str = '''{ "1": { "1-1": "aaa", "1-2": "bbb" }, "2": "xxx" }'''
data1 = json.loads( example_str ) print( 'data1[1][1-2]: ', data1['1']['1-2'] ) print( 'data1[2]: ', data1['2'] )
# test.json storing 1st example from http://json.org/example with open('test.json') as f: data2 = json.load( f )
print( 'data2[glossary][title]: ', data2['glossary']['title'] )
output
$ ./json_example.py data1[1][1-2]: bbb data1[2]: xxx data2[glossary][title]: example glossary
if you know how to use python dicts you are golden.
JSON is such an easy serialization format, I'd recommend you to actually write a simple serialization yourself, just for fun. Pick your preferred object oriented language, have a look at json.org and implement basic classes for each part of the standard (object, array, value, string etc). Then implement recursive functions that append any special characters and the string representation of each part, and writes to a file stream. This will not be as fancy as automatic serialization, but you will get how it works.
JSON stands for JavaScript Object Notation.
Basically what occurs is, Your data is transformed/mapped into a JSON Structure which can be easily sent and received by JSON parsers, which can parse the data out.
Example would be a Login Packet
So In java you tend to make Abstact Data Types
public class LoginDemoPacket { private String _username; private String _password; public LoginDemoPacket(String Username, String Pass){ _username = Username; _password = Pass; }
public String getUsername(){ return _username; }
public String getPassword(){ return _password; } }
The JSON of this class would be
{ 'username' : username, 'password' : password }
which can now be sent across any medium I choose.
Some things to note:
JSON is human readable, JSON is Key : Value Pairs, where the Key is a String normally and values are normally Ints, Booleans ,Arrays, Objects, and Strings
http://json.org/ is some information on JSON.
That's okay. Even though JavaScript and JSON go together like peanut butter and jam, they can be used separately. JSON is simply a method of storing data, much like minecraft's NBT.
JSON numbers are not limited in size, so the strings are technically redundant (http://json.org/number.gif). A pragmatic approach to reduce the redundancy and work around javascript limits would be to use strings for ids (which may need 64 bits, but don't need to support arithmetic) and JSON numbers for everything else (I doubt even PL have more than 9007199254740992 ISK so a 64 bit float should be fine).
