I like the format. A formal spec would be nice, to aid implementations in as many languages as possible.
TOML, Tom's Own Markup Language
111–120 of 173 posts
Re: TOML, Tom's Own Markup Language
#112Earlier quoted context omitted.
Parker Moore and I (along with many contributors) have been spending quite a bit of time on Jekyll recently. Over the last 30 days we've merged 17 pull requests and closed 62 issues. We're ramping up for a 1.0 release and there's a brand new website in the works. You can check it all out on the master branch. Tens (or possibly hundreds) of thousands of people use Jekyll now. It's interesting to note that Jekyll start…
Tom, I've been waiting two years on a pull-request to the official gem which adds the ability to view open/closed issues in private repositories. https://github.com/defunkt/github-gem/pull/59 The pull has 19 people asking for integration and has some stellar comments: "seriously? year long pull request with two lines of changes?" "I normally would think that the github gem features for paying users would get a lot of…
That project isn't actively maintained at the moment (nor is it an official GitHub project), but I'll see what I can do tomorrow to get it merged in and released. Sorry for the frustration!
Re: TOML, Tom's Own Markup Language
#113Earlier quoted context omitted.
The difficulty level is hardly extreme. It is not an unreasonable challenge to learn that writing an array of elements requires opening and closing brackets.
The issue here might be that JSON has become widely used for two things: Data marshalling/transfer Config formats For the latter, as they are typically written by hand, it's not particularly appropriate as the syntax is noisy and multiple nesting with brackets tends to lead to errors, even if you understand it perfectly well in principle, and of course there are no comments, no datetimes etc. I imagine this is intend…
FWIW I've also recognized the problem and wrote and implemented my own configuration syntax, which makes the aforementioned JSON data look like:
[because=[[80=percent][of=JSON;is=brackets]]]
The implementation, which is in Haxe and has an informal spec in comments, can be seen here: https://github.com/triplefox/triad/blob/master/dev/com/ludam...
I didn't view bracketing as the enemy(which seems to be the focus of a lot of config syntaxes) but rather the combination of multiple types of bracketing, plus start-and-stop usage of shift keying. I only have two types of brackets, the sequence [ type and the long string {" type, and you can "feel" when you're writing a long string because of that sudden need to use the shift.
Re: TOML, Tom's Own Markup Language
#114What is wrong with JSON? Everything already supports it. JSON has two drawbacks: a lack of comments (although you could add "#" keys in relevant places) and no binary support (arbitrary conventions include base64) but this doesn't support binary anyway.
Lack of comments is pretty much a deal breaker for configuration. I see a lot of undocumented JSON used for configuration and I find it difficult to believe that is something we want for the future. Lack of comments makes JSON much better for data exchange than formats with comments.
Lack of comments is at once annoying and beneficial: it forces your [JSON-based] configuration to be simple.
Re: TOML, Tom's Own Markup Language
#115Ah, the power of fame. Implementations spreading like weeds. Four already in javascript, even though the spec is not anywhere near finished:
npm search toml
npm http GET https://registry.npmjs.org/-/all/since?stale=update_after&startkey=1361700343737
npm http 200 https://registry.npmjs.org/-/all/since?stale=update_after&startkey=1361700343737
NAME DESCRIPTION AUTHOR DATE
node-toml TOML parser =ricardobeat 2013-02-24 10:08
toml TOML parser for Node.js =binarymuse 2013-02-24 04:19 toml parser
toml-node TOML ==== =thehydroimpulse 2013-02-24 08:01
toml-parser A TOML parser for node.js =aaronblohowiak 2013-02-24 06:41Re: TOML, Tom's Own Markup Language
#116Earlier quoted context omitted.
Nitpick: that's an issue with JavaScript, not JSON.
I'd agree if JSON had a different name, but given that it is called "JavaScript Object Notation" on the main page ( http://json.org/ ) there's an implicit expectation that it's somehow related to javascript.
And there's an implicit expectation that JavaScript is somehow related to Java.
Re: TOML, Tom's Own Markup Language
#117Working node.js version: https://github.com/aaronblohowiak/toml I just need to auth and push it to npm.
Wrote my own dumb parser in CoffeeScript as an experiment, tried to publish as `toml-parser` :D
https://github.com/ricardobeat/toml/blob/master/index.coffee
Re: TOML, Tom's Own Markup Language
#118This is quite nice but there are a few of things that I miss:
1. A way to have multi-line values for non array types
2. A more flexible number syntax (e.g. allow hex and binary integers, allow exponents on floats, allow NaN and +/-Inf)
3. Make it possible to have an extra comma after the last element on an array (as in Python)
4. Add a way to "include" another config file
#1 is important because some projects require all lines to have a max width of 80 lines, including on config files.
#2 is important for scientific/engineering projects. I think the current simple format shows that this format is a little too web centric. If this is going to be used for non-web stuff this is a must.
#3 is something that helps when putting this sort of configuration file in version control. Without this, adding an extra entry to a multi-line array creates a diff in two lines rather than 2 (since you must add a comma to the line above the one that you inserted). This is something I miss in JSON and which Python did just right (IMHO).
#4 would be useful in cases in which you want to provide a base configuration file for example.
Also, maybe I missed it but it is not super clear what would happen if you redefine an existing entry (I hope it is possible). Finally, is order important?
EDIT: typo.
Re: TOML, Tom's Own Markup Language
#119Earlier quoted context omitted.
And this is only 10% curly braces, not counting spaces.
Despite that, the thread easily illustrates the difficulty of writing valid JSON by hand.
I've /never/ had a problem writing JSON by hand.
Try this in TOML:
key = "value1", "value2"
The same mistakes can be ignorantly made in any markup.
Re: TOML, Tom's Own Markup Language
#120I note that, like many erstwhile specs, TOML does not document the escape sequences accepted in strings. Nor does it exhaustively specify integer formats and float formats - rather ironic for a spec that advertises "TOML is designed to be unambiguous and as simple as possible." The limitation on array types seemed fairly arbitrary at first glance, but after thinking it over I realized it aided compatibility with lang…
I'm just wondering what the point of having homogeneous arrays is when the dictionaries aren't...
Seconded. Otherwise it seems quite nice, but this one inconsistency stands out.