On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.

Why not use a well defined subset of YAML then?

On Thursday, 26 November 2015 at 13:10:30 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
>> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.
>
> Why not use a well defined subset of YAML then?

I really think that small subset of YAML would be very good solution. It's easy to read and easy to write. DUB do not have full implement it. Just some basic things.

TOML is harder to read, and write bu hands.

On Thursday, 26 November 2015 at 12:11:25 UTC, Daniel Kozak wrote:

>
> Btw. when your book will be published? :)

Soon. The schedule slipped a bit on the publisher's end, but I don't know how it will affect the release date. I submitted my copy edits of the prefinals last week, so now I'm just waiting for a status update.

Sorry but for me this is another "HOT" thread for a sh*t problem. The OP dislikes SDL, so use JSON. What's the big deal, and as Sönke Ludwig said, it was announced before (http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/) and most agree with this change.

I'm here almost every day reading the topics. And is weird to see how the sh*t ones usually got attraction.

Matheus.

On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg wrote:
>> On 2015-11-25 11:17, Suliman wrote:
>>> [...]
>>
>> BTW, why was not TOML [1] chosen? I know it was discussed but I can't remember why SDL was preferred. I think TOML is more widely used than SDL [2]. GitLib CI multi runner is also using it.
>>
>> [1] https://github.com/toml-lang/toml
>> [2] https://github.com/toml-lang/toml#projects-using-toml
>
> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.

If it's good enough for Rust, it's good enough for us.

On Thursday, 26 November 2015 at 13:44:48 UTC, Vladimir Panteleev wrote:
> On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
>> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg wrote:
>>> On 2015-11-25 11:17, Suliman wrote:
>>>> [...]
>>>
>>> BTW, why was not TOML [1] chosen? I know it was discussed but I can't remember why SDL was preferred. I think TOML is more widely used than SDL [2]. GitLib CI multi runner is also using it.
>>>
>>> [1] https://github.com/toml-lang/toml
>>> [2] https://github.com/toml-lang/toml#projects-using-toml
>>
>> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.
>
> If it's good enough for Rust, it's good enough for us.

No, because we have to write a parser and update it every time TOML changes. Since it's only 0.4 you can expect it to change a lot till 1.0. We already have a solid JSON parser and JSON has settled down. But it doesn't matter, TOML will not happen any time soon so let's not waste our energy on this. We've wasted enough on this thread already.

It's weird how the minor issues that could be fixed in an instant always cause flamewars. I say, let's just revert to JSON as standard format and provide a converter (as I and others have suggested). That should end the discussion.

On 2015-11-26 12:47, Daniel Murphy wrote:

> We get to delete the non-boost INI parser from the frontend!

How much trouble is that causing?

-- 
/Jacob Carlborg

On 2015-11-26 14:10, Ola Fosheim Grøstad wrote:

> Why not use a well defined subset of YAML then?

I think that's perfectly fine as well.

-- 
/Jacob Carlborg

On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
> On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko wrote:
>
>>
>> Single language, json based configuration engine is simpler for IDE development and configuration tools. For example, Sublime Text.This is very important to make language used by big amount of users.
>>
>> Ilya
>
> This is not even an issue. IDEs can create a dub.json for all new projects and call 'dub describe' on imported projects without ever touching SDLang. Again, *there is no problem here*.

The problem is dependency from dub because some dependencies of a project can have SDL configs.

On 27/11/2015 1:37 AM, Jacob Carlborg wrote:
> On 2015-11-26 12:47, Daniel Murphy wrote:
>
>> We get to delete the non-boost INI parser from the frontend!
>
> How much trouble is that causing?
>

None, it just annoys me.