www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Before we implement SDL package format for DUB

reply "Jonathan Marler" <johnnymarler gmail.com> writes:
Hello everyone,

I've been working on SDL support for DUB and wanted to get some 
people's opinions on whether we should really use SDL.  I've 
posted my thoughts here: 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
Aug 25 2014
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


I kind of get the feeling you're trying to push dub to use ASON.

My first reaction is, please don't invent yet another markup 
language for developers to learn. Especially as this new language 
is only relevant to dub. Honestly it would seriously make me not 
want to use dub. Just pick one of the existing ones, XML, Yaml, 
Json, SDL (i've never heard of this one.) and stick with it. All 
other package managers seem to do just fine. Don't fix what isn't 
broken.

Relevant: http://xkcd.com/927/

Seriously though are you also willing to break all existing 
dub.json files? That's 317 (http://code.dlang.org/ as of today) 
packages this change is going to mess with. Are you really going 
to do that? Just as things are starting to take off?

I'm in favour of just sticking to plain, normal old Json. 
Everyone knows it, everyone understands it and everything else 
does just fine using it.
Aug 25 2014
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 25 August 2014 at 18:28:39 UTC, Gary Willoughby wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some people's opinions on whether we should really use SDL.  
 I've posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 I kind of get the feeling you're trying to push dub to use ASON.

 My first reaction is, please don't invent yet another markup 
 language for developers to learn. Especially as this new 
 language is only relevant to dub. Honestly it would seriously 
 make me not want to use dub. Just pick one of the existing 
 ones, XML, Yaml, Json, SDL (i've never heard of this one.) and 
 stick with it. All other package managers seem to do just fine. 
 Don't fix what isn't broken.

 Relevant: http://xkcd.com/927/

 Seriously though are you also willing to break all existing 
 dub.json files? That's 317 (http://code.dlang.org/ as of today) 
 packages this change is going to mess with. Are you really 
 going to do that? Just as things are starting to take off?

 I'm in favour of just sticking to plain, normal old Json. 
 Everyone knows it, everyone understands it and everything else 
 does just fine using it.


If only it supported comments...
Aug 25 2014
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
 If only it supported comments...


Yes comments would be amazing...also non-quoted keynames.  If we 
just added those 2 things to the JSON parser I would be happy:)
Aug 25 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 25 August 2014 at 18:42:43 UTC, Jonathan Marler wrote:

 If only it supported comments...


 Yes comments would be amazing...also non-quoted keynames.  If 
 we just added those 2 things to the JSON parser I would be 
 happy:)


Why are comments and non quoted key names needed?
Aug 25 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 25 Aug 2014 19:26:59 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Why are comments and non quoted key names needed?


'cause people are not computers. let's think about people first.
Aug 25 2014
parent "Suliman" <evermind live.ru> writes:
please don't invent yet another markup language for developers 
to learn. Especially as this new language is only relevant to 
dub. Honestly it would seriously make me not want to use dub.



Please no custom markup languages when existing ones are good 
enough.


I am totally agree! JSON or SDL are really enough! Please do not 
add new language!
Aug 25 2014
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:

 If only it supported comments...


Yeah, that's what I hate about JSON. It's pretty good overall, 
but that's a huge deficiency IMHO - and I'd very much like to be 
able to put comments in my dub package files. So, in that 
respect, ASON seems like a definite improvement. However, I am a 
bit wary of creating a new file format. Maybe if it's good enough 
and marketed well enough, it could challenge JSON, but at the 
moment, it would just be for dub, which isn't so great.

The fact that it's backwards compatible with JSON would be useful 
for avoiding breaking existing dub packages, and it does sound 
like it's a better format, but the fact that it's just been 
created for this makes me leery. And even if we were to push it 
beyond dub and try and get it accepted more widely, it's new 
enough that I question that it won't need to be adjusted after 
further use, since it's rare that anything complicated is done 
right the first time.

So, I'm not necessarily against the idea of using ASON, but I'm 
not sure that it's a good idea either.

- Jonathan M Davis
Aug 25 2014
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:

 If only it supported comments...


 Yeah, that's what I hate about JSON. It's pretty good overall, 
 but that's a huge deficiency IMHO - and I'd very much like to 
 be able to put comments in my dub package files. So, in that 
 respect, ASON seems like a definite improvement. However, I am 
 a bit wary of creating a new file format. Maybe if it's good 
 enough and marketed well enough, it could challenge JSON, but 
 at the moment, it would just be for dub, which isn't so great.

 The fact that it's backwards compatible with JSON would be 
 useful for avoiding breaking existing dub packages, and it does 
 sound like it's a better format, but the fact that it's just 
 been created for this makes me leery. And even if we were to 
 push it beyond dub and try and get it accepted more widely, 
 it's new enough that I question that it won't need to be 
 adjusted after further use, since it's rare that anything 
 complicated is done right the first time.

 So, I'm not necessarily against the idea of using ASON, but I'm 
 not sure that it's a good idea either.

 - Jonathan M Davis


Thanks for your reply Jonathan, I would have the same 
reservations as you...I wouldn't want a languages exclusively 
used for DUB.  And you could be right that the language may 
require some modifications since I just wrote it last Saturday.  
On the other hand, new languages have to be introduced some where 
right?  Maybe if DUB started using it...other tools and software 
would look into it?
Aug 25 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 25 August 2014 at 19:52:56 UTC, Jonathan Marler wrote:

 Maybe if DUB started using it...other tools and software would 
 look into it?


That was already the idea behind using SDL, since it's seldom 
used in the wild.
Aug 26 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 The fact that it's backwards compatible with JSON would be 
 useful for avoiding breaking existing dub packages, and it does 
 sound like it's a better format, but the fact that it's just 
 been created for this makes me leery.


Well, formats are created if existing formats are suboptimal. 
JSON is not a general-purpose format, it was designed to be 
locked on javascript parsers.
Aug 26 2014
parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis 
 wrote:

 The fact that it's backwards compatible with JSON would be 
 useful for avoiding breaking existing dub packages, and it 
 does sound like it's a better format, but the fact that it's 
 just been created for this makes me leery.


 Well, formats are created if existing formats are suboptimal. 
 JSON is not a general-purpose format, it was designed to be 
 locked on javascript parsers.


If we want a popular markup language at some expense to save 
people from learning new language, it should be XML - it's more 
popular, than anything else.
Aug 26 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 26.08.2014 15:37, schrieb Kagamin:

 On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 The fact that it's backwards compatible with JSON would be useful for
 avoiding breaking existing dub packages, and it does sound like it's
 a better format, but the fact that it's just been created for this
 makes me leery.


 Well, formats are created if existing formats are suboptimal. JSON is
 not a general-purpose format, it was designed to be locked on
 javascript parsers.


 If we want a popular markup language at some expense to save people from
 learning new language, it should be XML - it's more popular, than
 anything else.


XML may pass the popularity test, but utterly fails at providing a more 
concise and usable experience. As far as I'm concerned, it's about 
finding the most "usable" language among those that are *decently* popular.
Aug 26 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-08-26 at 15:55 +0200, S=C3=B6nke Ludwig via Digitalmars-d wrot=
e:

 Am 26.08.2014 15:37, schrieb Kagamin:

 On Tuesday, 26 August 2014 at 13:28:28 UTC, Kagamin wrote:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 The fact that it's backwards compatible with JSON would be useful for
 avoiding breaking existing dub packages, and it does sound like it's
 a better format, but the fact that it's just been created for this
 makes me leery.


 Well, formats are created if existing formats are suboptimal. JSON is
 not a general-purpose format, it was designed to be locked on
 javascript parsers.


 If we want a popular markup language at some expense to save people fro=




m

 learning new language, it should be XML - it's more popular, than
 anything else.


=20
 XML may pass the popularity test, but utterly fails at providing a more=


=20

 concise and usable experience. As far as I'm concerned, it's about=20
 finding the most "usable" language among those that are *decently* popula=


r.

XML has clearly failed as a build specification language. I offer you
Ant and Maven as evidence for the persecution of people who inflict XML
as a user written file format.

Clearly I am biased, but I like internal DSLs on dynamic languages for
build specification.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 26 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
 Clearly I am biased, but I like internal DSLs on dynamic 
 languages for
 build specification.


What are DSLs?  Link?
Aug 26 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan Marler:


 What are DSLs?  Link?


http://en.wikipedia.org/wiki/Domain-specific_language

Bye,
bearophile
Aug 26 2014
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-08-26 at 17:25 +0000, Jonathan Marler via Digitalmars-d
wrote:

 Clearly I am biased, but I like internal DSLs on dynamic=20
 languages for
 build specification.


=20
 What are DSLs?  Link?


Technically it is a Domain Specific Language, but the whole thing is
really complicated since anyone who writes any functions or classes is
creating a DSL =E2=80=93 it is really just the notion of creating abstracti=
on:
tokens forming a language of discourse.

Internal vs external DSL: internal means a language constructed using
the symbols of the base language and not requiring a compiler, cf.
Boost.Spirit, anything written in a dynamic language. External DSL are
those requiring some form of compilation, cf. Make. Basically internal
DSL scripts are executed whereas external DSL scripts must be parsed.

In the context, Python can support an internal DSL for build, cf. SCons,
Waf. Groovy can support an internal DSL for build, cf. Gant, Gradle.

http://en.wikipedia.org/wiki/Domain-specific_language is not entirely
wrong ;-)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 26 2014
prev sibling parent reply "eles" <eles eles.com> writes:
On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:



 The fact that it's backwards compatible with JSON would be 
 useful for avoiding breaking existing dub packages, and it does


That's not a tragedy. For a while, dub could maintain the ability 
to read, even write the JSON format, and even to read .json and 
write .sdl, de facto converting.
Aug 26 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:



 The fact that it's backwards compatible with JSON would be useful for
 avoiding breaking existing dub packages, and it does


 That's not a tragedy. For a while, dub could maintain the ability to
 read, even write the JSON format, and even to read .json and write .sdl,
 de facto converting.


It will *always* continue to support JSON. There are absolutely no plans 
to remove support. The plan is just to support an additional alternative 
format that is better suited for human editors.
Aug 26 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis 
 wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:







 additional alternative format


SDL or D
Aug 26 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:







 additional alternative format


 SDL or D


D's an interesting option but it utterly fails the KISS test. All it 
would do is provide many tempting and creative ways to accidentally 
obfuscate the package description file. And then there's meta-mess of 
needing the right compiler version to properly handle a given package. 
Blech.
Aug 26 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky 
wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis 
 wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz 
 wrote:











 D's an interesting option but it utterly fails the KISS test.


Because there is no std.make or std.build or std.scons or 
std.cmake module to help with that.


 All it would do is provide many tempting and creative ways to 
 accidentally obfuscate the package description file.


I agree partially with this, this is why I am not pushing for D. 
A declarative language seems to be more appropriate in this case.

But we could imagine a declarative layer in/over D or a module 
directed at it. You know, one language to rule them all 
(including declarative languages, just as the functional ones...).


 And then there's meta-mess of needing the right compiler 
 version to properly handle a given package. Blech.


C'mon. This is because D is still running after its own tail. I 
mean, keeps evolving ans is unstable. I bet things will very much 
improve sooner than you think and that D frontend will play a 
role.
Aug 26 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/27/2014 1:40 AM, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:











 D's an interesting option but it utterly fails the KISS test.


 Because there is no std.make or std.build or std.scons or std.cmake
 module to help with that.


 All it would do is provide many tempting and creative ways to
 accidentally obfuscate the package description file.


 I agree partially with this, this is why I am not pushing for D. A
 declarative language seems to be more appropriate in this case.

 But we could imagine a declarative layer in/over D or a module directed
 at it. You know, one language to rule them all (including declarative
 languages, just as the functional ones...).


 And then there's meta-mess of needing the right compiler version to
 properly handle a given package. Blech.


 C'mon. This is because D is still running after its own tail. I mean,
 keeps evolving ans is unstable. I bet things will very much improve
 sooner than you think and that D frontend will play a role.


All reasonable points, but it still seems like swatting a fly with a 
bazooka. ;)
Aug 26 2014
parent reply "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky 
wrote:

 On 8/27/2014 1:40 AM, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky 
 wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig 
 wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M 
 Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz 
 wrote:















 All reasonable points, but it still seems like swatting a fly 
 with a bazooka. ;)


Well, you need a sharp eye and a sure hand. But otherwise, the 
sole problem is if the fly is on someone's nose...
Aug 27 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.08.2014 10:29, schrieb eles:

 On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote:

 On 8/27/2014 1:40 AM, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:















 All reasonable points, but it still seems like swatting a fly with a
 bazooka. ;)


 Well, you need a sharp eye and a sure hand. But otherwise, the sole
 problem is if the fly is on someone's nose...


And you will have to pay the price for a rocket and have to rebuild 
parts of your house every time you kill a fly ;)
Aug 27 2014
parent reply "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote:

 Am 27.08.2014 10:29, schrieb eles:

 On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky 
 wrote:

 On 8/27/2014 1:40 AM, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick 
 Sabalausky wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig 
 wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M 
 Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz 
 wrote:



















 And you will have to pay the price for a rocket and have to 
 rebuild parts of your house every time you kill a fly ;)


If it's 3 AM and you cannot yet sleep because that fly is 
annoying you, I bet you'll consider that's a very small price to 
pay...
Aug 27 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.08.2014 11:49, schrieb eles:

 On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote:

 Am 27.08.2014 10:29, schrieb eles:

 On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote:

 On 8/27/2014 1:40 AM, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote:

 On 8/26/2014 1:43 PM, eles wrote:

 On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 15:37, schrieb eles:

 On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:

 On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:



















 And you will have to pay the price for a rocket and have to rebuild
 parts of your house every time you kill a fly ;)


 If it's 3 AM and you cannot yet sleep because that fly is annoying you,
 I bet you'll consider that's a very small price to pay...


But the next morning you'll wake up and regret what you did that night
Aug 27 2014
parent "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 11:29:32 UTC, Sönke Ludwig wrote:

 Am 27.08.2014 11:49, schrieb eles:



 But the next morning you'll wake up and regret what you did 
 that night


Well, that saying could be applied to so many things in life...
Aug 27 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 27/08/14 07:40, eles wrote:


 But we could imagine a declarative layer in/over D or a module directed
 at it. You know, one language to rule them all (including declarative
 languages, just as the functional ones...).


You could probably come quite far with UDA's or similar.

-- 
/Jacob Carlborg
Aug 26 2014
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 27 August 2014 at 05:40:51 UTC, eles wrote:

 On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky 
 wrote:

 All it would do is provide many tempting and creative ways to 
 accidentally obfuscate the package description file.


 I agree partially with this, this is why I am not pushing for 
 D. A declarative language seems to be more appropriate in this 
 case.


Ideally we wouldn't even need that, but reality is rarely so 
kind.  I suppose if we can't be sufficiently Perl-like, maybe 
Portage-like is the next best thing. :/

Thought dump:
The DUB package specification is versioned, right?  So, in the 
vein of the Package Manager Specification, for a given...let's 
call it "DUBAPI version"... provide higher-level functions that 
abstract away things that are common or things that are tricky to 
get right if you try to always do them manually.  Package them in 
modules that can be imported and use the DUBAPI version within 
the module to select version-specific behaviour.  For those of 
stern fortitude, an ugly ebuild-like thing; a...uhm, "dubuild":

DUBAPI=1;
import dub.autotools;
import dub.git;
import dub.utils : patch;

DESCRIPTION = "Plugin providing semi-solids for bread";
HOMEPAGE = "http://toa.st/spread";
LICENSE = "zlib";
PHOBOS_VERSION = "<=2.065"; // TODO: fix the failure
GIT_REPO_URI = "http://github.com/toast/spread";
GIT_BRANCH = "butter"; // Vars defined in the dub.git module
DEPEND = {">=libyeast-1.3", ">=libbread-2.2" }; // Build-time 
dependency

// Each of these phase functions overrides a default.
// If it doesn't need overridden, the default is used.
src_unpack(){
     git_fetch(GIT_BRANCH); // No argument gets master branch
     patch("files/melt_butter.patch"); // Apply our local patch
}

src_configure() {
     assert(autoreconf(), "configure failed!"); // Die if this 
fails.
}

src_install() {
     dub_install("~/toast/plugins/"); // Non-standard location
}

post_install() {
     dublog("Activate the spread plugin under Tools -> Options -> 
Plugins");
}

NOTE: I want to believe this is overkill and we'll never need to 
consider anything even resembling this route, but experience 
makes that hard.

-Wyatt
Aug 27 2014
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
Please read the entire post when you reply.


 I kind of get the feeling you're trying to push dub to use ASON.


Yes, in fact I explicitly stated that was my intention.


 My first reaction is, please don't invent yet another markup 
 language for developers to learn. Especially as this new 
 language is only relevant to dub.


That would have also been my first reaction. However, instead of 
immediately dismissing the idea, it would be more productive to 
state why you think the language is not a good fit, or why you 
think SDL will do just fine. I explained why I think ASON would 
be a better fit than SDL, do you have a counter-argument?


 Honestly it would seriously make me not want to use dub. Just 
 pick one of the existing ones, Yaml, Json, SDL (i've never 
 heard of this one.) and stick with it. All other package 
 managers seem to do just fine. Don't fix what isn't broken.


It would make you not want to use DUB? Could you please explain 
why? If we used ASON you wouldn't have to change anything, you 
could just continue to use regular JSON since it is already valid 
ASON.


 Seriously though are you also willing to break all existing 
 dub.json files? That's 317 (http://code.dlang.org/ as of today) 
 packages this change is going to mess with. Are you really 
 going to do that? Just as things are starting to take off?


No, I wouldn't be willing to break anything. That's why I like 
ASON, it doesn't break anything. Please read the post before you 
reply next time.


 I'm in favour of just sticking to plain, normal old Json. 
 Everyone knows it, everyone understands it and everything else 
 does just fine using it.


That's fine, if we used ASON you could just continue to use plain 
old JSON.
Aug 25 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 25 August 2014 at 18:40:02 UTC, Jonathan Marler wrote:

 That would have also been my first reaction. However, instead 
 of immediately dismissing the idea, it would be more productive 
 to state why you think the language is not a good fit, or why 
 you think SDL will do just fine. I explained why I think ASON 
 would be a better fit than SDL, do you have a counter-argument?


Yes i do, it's simple, we don't need yet another markup language.


 It would make you not want to use DUB? Could you please explain 
 why?


Because learning a markup language tied exclusively to dub means 
more work to use it. It means i have to learn yet another markup 
language to package my code for others. Please answer why should 
i bother?


 No, I wouldn't be willing to break anything. That's why I like 
 ASON, it doesn't break anything. Please read the post before 
 you reply next time.


I have read it and i don't agree with inventing yet another 
markup language.


 That's fine, if we used ASON you could just continue to use 
 plain old JSON.


If that's the case why do we need ASON?
Aug 25 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 25 August 2014 at 19:25:50 UTC, Gary Willoughby wrote:

 On Monday, 25 August 2014 at 18:40:02 UTC, Jonathan Marler 
 wrote:

 That would have also been my first reaction. However, instead 
 of immediately dismissing the idea, it would be more 
 productive to state why you think the language is not a good 
 fit, or why you think SDL will do just fine. I explained why I 
 think ASON would be a better fit than SDL, do you have a 
 counter-argument?


 Yes i do, it's simple, we don't need yet another markup 
 language.


You say "It's simple". How do you define simple...is ASON not 
simple?  I included the full grammar, it doesn't seem very 
complex to me.  Also you say, "we don't need another markup 
language".  That's what I was asking you to explain.  The reason 
we are looking into new languages is because of the list of 
grievances we have with JSON (see the original post).  Are you 
saying that people's problems with JSON are invalid?  Also, 
what's wrong with new languages?  If you have a problem with new 
languages, what are you doing here on the D forum?  Sounds like 
C++ is a better fit for you.


 It would make you not want to use DUB? Could you please 
 explain why?


 Because learning a markup language tied exclusively to dub 
 means more work to use it. It means i have to learn yet another 
 markup language to package my code for others. Please answer 
 why should i bother?


Well I just invented ASON last saturday so I don't know how 
people will react to it.  If DUB ends up using it I hope it isn't 
exclusively used with DUB. I plan on introducing it at my work (I 
work at HP) so we may start using it here.  Also, is ASON really 
that hard to learn?  Here's my full tutorial on moving from JSON 
to ASON:

1. Comments are supported...yay!
2. No need to quote strings if you don't want to.
3. No need for colons or commas if you don't want them.

There's a couple more features you can use like SingularNames and 
Nameless fields but don't worry about those, those features come 
with the advanced course that takes alot longer.  Don't go there 
unless you're willing to give up 5 minutes of your day.


 I have read it and i don't agree with inventing yet another 
 markup language.


You still haven't explained why inventing new languages is bad.  
If we had it your way we'd still be using assembly language.  
Just because computer languages have been around for a while 
doesn't mean they still can't be improved.  D is a perfect 
example of that.  Instead of just writing things that you assume 
are always correct, take the time to look at the situation and 
provide useful insight as to why you think this particular 
language is not a good fit.


 That's fine, if we used ASON you could just continue to use 
 plain old JSON.


 If that's the case why do we need ASON?


Please see the original list of JSON grievances.  I would say the 
main one is COMMENTS.
Aug 25 2014
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


You said that "The standard way to read a dub package description 
is to use the output of "dub describe", not to parse dub.json 
directly", but what about tools that *write* to dub.json? 
Currently, if an IDE wants to use DUB behind the scenes as it's 
build system it can parse dub.json and modify it as it wishes, 
and that should even work if someone modified dub.json by hand. 
But what if someone modifies dub.json by hand and adds ASON stuff 
to it? I think we need a command like `dub normalize` that'll 
convert the dub.json file into a pure JSON file that has exactly 
the same data, so IDEs could call it before loading dub.json.


About the language - if you are making a new data serialization 
language(NOT markup language. These languages don't actually mark 
anything up) for DUB, could you please make it support heredocs? 
This will allow, in the future, to easily add pre-build and 
post-build scripts directly in the build-file.

Alos - nameless fields scare me. They mean that ASON is not a 
schema-less format - and schema-less-ness is one of the most 
important features of languages like JSON, XML and YAML. I accept 
it if consumers break when suppliers remove fields - but nameless 
fields mean that consumers might break when the supplier added 
fields in the middle or reordered fields. This makes ASON a 
schema-bound format - and developers that choose schema-bound 
formats, usually care about compactness that ASON does not 
supply(since most the syntax is one of schema-less formats, it's 
very verbose compared to schema-bound formats).


At any rate, it would be nice to have the ASON parser as a DUB 
package before making it the official language for DUB 
build-files.
Aug 25 2014
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
 You said that "The standard way to read a dub package 
 description is to use the output of "dub describe", not to 
 parse dub.json directly", but what about tools that *write* to 
 dub.json? Currently, if an IDE wants to use DUB behind the 
 scenes as it's build system it can parse dub.json and modify it 
 as it wishes, and that should even work if someone modified 
 dub.json by hand. But what if someone modifies dub.json by hand 
 and adds ASON stuff to it? I think we need a command like `dub 
 normalize` that'll convert the dub.json file into a pure JSON 
 file that has exactly the same data, so IDEs could call it 
 before loading dub.json.


Good points...


 About the language - if you are making a new data serialization 
 language(NOT markup language. These languages don't actually 
 mark anything up) for DUB, could you please make it support 
 heredocs? This will allow, in the future, to easily add 
 pre-build and post-build scripts directly in the build-file.


I am not familiar with the term "herdoc".  After a quick google, 
it looks like it refers to a way of escaping the language.  Is 
this not something that a single-quoted string couldn't handle?  
You would still need to escape single-quotes and back-slashes, 
but it comes close.  However, I wouldn't be against adding a 
special character sequence to support this (Maybe '<<' or 
something).



 Alos - nameless fields scare me. They mean that ASON is not a 
 schema-less format - and schema-less-ness is one of the most 
 important features of languages like JSON, XML and YAML. I 
 accept it if consumers break when suppliers remove fields - but 
 nameless fields mean that consumers might break when the 
 supplier added fields in the middle or reordered fields. This 
 makes ASON a schema-bound format - and developers that choose 
 schema-bound formats, usually care about compactness that ASON 
 does not supply(since most the syntax is one of schema-less 
 formats, it's very verbose compared to schema-bound formats).


Yes when you start using nameless fields your data now needs a 
schema.  And I had the same concerns you mentioned when 
adding/removing fields. That's why I recommended the only fields 
that DUB should make nameless are the "name" fields on some 
objects.  However, this is not important, completely dismissing 
the nameless fields feature for DUB would be completely 
reasonable as well.


 At any rate, it would be nice to have the ASON parser as a DUB 
 package before making it the official language for DUB 
 build-files.


I'm writing it now for other projects of mine.
Aug 25 2014
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler wrote:

 About the language - if you are making a new data 
 serialization language(NOT markup language. These languages 
 don't actually mark anything up) for DUB, could you please 
 make it support heredocs? This will allow, in the future, to 
 easily add pre-build and post-build scripts directly in the 
 build-file.


 I am not familiar with the term "herdoc".  After a quick 
 google, it looks like it refers to a way of escaping the 
 language.  Is this not something that a single-quoted string 
 couldn't handle?  You would still need to escape single-quotes 
 and back-slashes, but it comes close.  However, I wouldn't be 
 against adding a special character sequence to support this 
 (Maybe '<<' or something).


Heredoc, after parsed, is no different from a regular string. But 
isn't ASON as well, after parsed(with schema), is no different 
from regular JSON?

As far as I understand, the point of ASON is to make the build 
files more human readable and writeable. Heredoc do the same 
thing - if you have a long script(a shell script, or one in a 
hosted scripting language, or even D code that'll be ran with 
rdmd) it's hard to write it in a regular quoted string, because 
they don't support newlines(you have to use '\n') and you need to 
be careful not to use the quote in the script itself(unless you 
escape them). Heredoc makes writing these scripts more 
straightforward.



 Alos - nameless fields scare me. They mean that ASON is not a 
 schema-less format - and schema-less-ness is one of the most 
 important features of languages like JSON, XML and YAML. I 
 accept it if consumers break when suppliers remove fields - 
 but nameless fields mean that consumers might break when the 
 supplier added fields in the middle or reordered fields. This 
 makes ASON a schema-bound format - and developers that choose 
 schema-bound formats, usually care about compactness that ASON 
 does not supply(since most the syntax is one of schema-less 
 formats, it's very verbose compared to schema-bound formats).


 Yes when you start using nameless fields your data now needs a 
 schema.  And I had the same concerns you mentioned when 
 adding/removing fields. That's why I recommended the only 
 fields that DUB should make nameless are the "name" fields on 
 some objects.  However, this is not important, completely 
 dismissing the nameless fields feature for DUB would be 
 completely reasonable as well.


Using the nameless fields in DUB is not the problem - DUB has a 
well defined schema with a well defined single source of 
authority. If you want to see ASON used as a data transfer 
format(like JSON) then these nameless fields will be problematic.
Aug 25 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 26 August 2014 at 00:12:37 UTC, Idan Arye wrote:

 On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler 
 wrote:

 About the language - if you are making a new data 
 serialization language(NOT markup language. These languages 
 don't actually mark anything up) for DUB, could you please 
 make it support heredocs? This will allow, in the future, to 
 easily add pre-build and post-build scripts directly in the 
 build-file.


 I am not familiar with the term "herdoc".  After a quick 
 google, it looks like it refers to a way of escaping the 
 language.  Is this not something that a single-quoted string 
 couldn't handle?  You would still need to escape single-quotes 
 and back-slashes, but it comes close.  However, I wouldn't be 
 against adding a special character sequence to support this 
 (Maybe '<<' or something).


 Heredoc, after parsed, is no different from a regular string. 
 But isn't ASON as well, after parsed(with schema), is no 
 different from regular JSON?

 As far as I understand, the point of ASON is to make the build 
 files more human readable and writeable. Heredoc do the same 
 thing - if you have a long script(a shell script, or one in a 
 hosted scripting language, or even D code that'll be ran with 
 rdmd) it's hard to write it in a regular quoted string, because 
 they don't support newlines(you have to use '\n') and you need 
 to be careful not to use the quote in the script itself(unless 
 you escape them). Heredoc makes writing these scripts more 
 straightforward.



 Alos - nameless fields scare me. They mean that ASON is not a 
 schema-less format - and schema-less-ness is one of the most 
 important features of languages like JSON, XML and YAML. I 
 accept it if consumers break when suppliers remove fields - 
 but nameless fields mean that consumers might break when the 
 supplier added fields in the middle or reordered fields. This 
 makes ASON a schema-bound format - and developers that choose 
 schema-bound formats, usually care about compactness that 
 ASON does not supply(since most the syntax is one of 
 schema-less formats, it's very verbose compared to 
 schema-bound formats).


 Yes when you start using nameless fields your data now needs a 
 schema.  And I had the same concerns you mentioned when 
 adding/removing fields. That's why I recommended the only 
 fields that DUB should make nameless are the "name" fields on 
 some objects.  However, this is not important, completely 
 dismissing the nameless fields feature for DUB would be 
 completely reasonable as well.


 Using the nameless fields in DUB is not the problem - DUB has a 
 well defined schema with a well defined single source of 
 authority. If you want to see ASON used as a data transfer 
 format(like JSON) then these nameless fields will be 
 problematic.


ASON single-quoted strings support any character inside them 
except unescaped single-quotes and unescaped backslashes.  You 
can put raw newlines in a single-quoted string.
Aug 25 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/25/2014 7:00 PM, Jonathan Marler wrote:

 I am not familiar with the term "herdoc".  After a quick google, it
 looks like it refers to a way of escaping the language.  Is this not
 something that a single-quoted string couldn't handle? You would still
 need to escape single-quotes and back-slashes, but it comes close.
 However, I wouldn't be against adding a special character sequence to
 support this (Maybe '<<' or something).


Heredoc is just a raw string that doesn't choke on embedded newlines.

And often the "end of string" delimiter is customizable so you don't 
have to worry about escaping the quotes or anything.
Aug 26 2014
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 26.08.2014 00:14, schrieb Idan Arye:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some
 people's opinions on whether we should really use SDL.  I've posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 You said that "The standard way to read a dub package description is to
 use the output of "dub describe", not to parse dub.json directly", but
 what about tools that *write* to dub.json? Currently, if an IDE wants to
 use DUB behind the scenes as it's build system it can parse dub.json and
 modify it as it wishes, and that should even work if someone modified
 dub.json by hand. But what if someone modifies dub.json by hand and adds
 ASON stuff to it? I think we need a command like `dub normalize` that'll
 convert the dub.json file into a pure JSON file that has exactly the
 same data, so IDEs could call it before loading dub.json.


That's a good point. Although I think that IDEs would be best off 
limiting themselves to JSON, because not keeping comments and formatting 
for any more complex format may be an issue.

However, SDL has on it's plus side that there are implementations for 
Java, .NET, D and Ruby. So most popular IDEs *could* relatively easily 
add support. Any IDE that can integrade D libraries can also use DUB as 
a library.
Aug 26 2014
parent "eles" <eles215 gzk.dot> writes:
On Tuesday, 26 August 2014 at 09:43:21 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 00:14, schrieb Idan Arye:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:




What about enhancing the command-line interface of dub to reduce 
the need of editing the dub.json/dub.sdl file. For example:

dub depadd "name" "version"
dub depdel "name"
dub depmod "name" "newversion"

Configurations etc could be handled in the same way.

This way, for many use cases, editing the text file won't even be 
needed.
Sep 02 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/25/2014 6:14 PM, Idan Arye wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some
 people's opinions on whether we should really use SDL.  I've posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 You said that "The standard way to read a dub package description is to
 use the output of "dub describe", not to parse dub.json directly", but
 what about tools that *write* to dub.json?


...They *continue* writing to dub.json just as before?

I don't see the problem. "dub describe" isn't going to magically start 
failing just because it was a machine that wrote to dub.json instead of 
a human.

You did catch the part where people keep saying that support for JSON is 
*not going anywhere*, right?


 Currently, if an IDE wants to
 use DUB behind the scenes as it's build system it can parse dub.json and
 modify it as it wishes, and that should even work if someone modified
 dub.json by hand. But what if someone modifies dub.json by hand and adds
 ASON stuff to it?


Again, use "dub describe" to read the data, then write to "dub.{whatever}".


 I think we need a command like `dub normalize` that'll


"dub describe"


 convert the dub.json file into a pure JSON file


"dub describe"


that has exactly the
 same data, so IDEs could call it before loading dub.json.


I don't see the problem.
Aug 26 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky 
wrote:

 On 8/25/2014 6:14 PM, Idan Arye wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some
 people's opinions on whether we should really use SDL.  I've 
 posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 You said that "The standard way to read a dub package 
 description is to
 use the output of "dub describe", not to parse dub.json 
 directly", but
 what about tools that *write* to dub.json?


 ...They *continue* writing to dub.json just as before?

 I don't see the problem. "dub describe" isn't going to 
 magically start failing just because it was a machine that 
 wrote to dub.json instead of a human.

 You did catch the part where people keep saying that support 
 for JSON is *not going anywhere*, right?


 Currently, if an IDE wants to
 use DUB behind the scenes as it's build system it can parse 
 dub.json and
 modify it as it wishes, and that should even work if someone 
 modified
 dub.json by hand. But what if someone modifies dub.json by 
 hand and adds
 ASON stuff to it?


 Again, use "dub describe" to read the data, then write to 
 "dub.{whatever}".


 I think we need a command like `dub normalize` that'll


 "dub describe"


 convert the dub.json file into a pure JSON file


 "dub describe"


that has exactly the
 same data, so IDEs could call it before loading dub.json.


 I don't see the problem.


`dub describe` does not give you a normalized version of 
"dub.json". It gives you something else:

$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined - 
expected string.

Sure, the data to build a new "dub.json" is in there - after all, 
all the data DUB can provide is in there. But that's the problem 
- *all* the data DUB can provide is in there. That includes data 
from downloaded dependencies, system data, (possibly) local 
configuration data and anything can be added in the future. 
That's the point of `dub describe` - query for anything DUB can 
tell you and let the user pick what they need.

Even if the result of `dub describe` were valid for "dub.json", 
you wouldn't want to put all that data in the project's 
build-file! You want to be able to put "dub.json" under source 
control and for that it must only contain information about the 
project - not about the specific configuration of the machine of 
the last developer who happened to run `dub describe` and 
overwrite "dub.json".

`dub describe` is perfect for automated tools that want to query 
DUB, but it's not a solution for tools that need to modify it.
Aug 27 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/27/2014 2:38 PM, Idan Arye wrote:

 On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky wrote:

 On 8/25/2014 6:14 PM, Idan Arye wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some
 people's opinions on whether we should really use SDL.  I've posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 You said that "The standard way to read a dub package description is to
 use the output of "dub describe", not to parse dub.json directly", but
 what about tools that *write* to dub.json?


 ...They *continue* writing to dub.json just as before?

 I don't see the problem. "dub describe" isn't going to magically start
 failing just because it was a machine that wrote to dub.json instead
 of a human.

 You did catch the part where people keep saying that support for JSON
 is *not going anywhere*, right?


 Currently, if an IDE wants to
 use DUB behind the scenes as it's build system it can parse dub.json and
 modify it as it wishes, and that should even work if someone modified
 dub.json by hand. But what if someone modifies dub.json by hand and adds
 ASON stuff to it?


 Again, use "dub describe" to read the data, then write to
 "dub.{whatever}".


 I think we need a command like `dub normalize` that'll


 "dub describe"


 convert the dub.json file into a pure JSON file


 "dub describe"


that has exactly the
 same data, so IDEs could call it before loading dub.json.


 I don't see the problem.


 `dub describe` does not give you a normalized version of "dub.json". It
 gives you something else:

 $ dub init
 Successfully created an empty project in '/tmp/dub-test'.
 $ dub describe > dub.json.new
 $ mv dub.json.new dub.json
 $ dub describe
 Error executing command describe: Got .name of type undefined - expected
 string.


Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a 
difficult feature to add, though.


 `dub describe` is perfect for automated tools that want to query DUB,
 but it's not a solution for tools that need to modify it.


Well, it would probably work, it just wouldn't be an ideal solution. But 
again, that "dub normalize" you suggest (or "dub describe --normalize" 
or something) should do the trick. So it doesn't appear to be a 
deal-breaker for supporting another language, it's just an additional 
TODO for dub.
Aug 27 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky 
wrote:

 On 8/27/2014 2:38 PM, Idan Arye wrote:

 On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky 
 wrote:

 On 8/25/2014 6:14 PM, Idan Arye wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some
 people's opinions on whether we should really use SDL.  
 I've posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 You said that "The standard way to read a dub package 
 description is to
 use the output of "dub describe", not to parse dub.json 
 directly", but
 what about tools that *write* to dub.json?


 ...They *continue* writing to dub.json just as before?

 I don't see the problem. "dub describe" isn't going to 
 magically start
 failing just because it was a machine that wrote to dub.json 
 instead
 of a human.

 You did catch the part where people keep saying that support 
 for JSON
 is *not going anywhere*, right?


 Currently, if an IDE wants to
 use DUB behind the scenes as it's build system it can parse 
 dub.json and
 modify it as it wishes, and that should even work if someone 
 modified
 dub.json by hand. But what if someone modifies dub.json by 
 hand and adds
 ASON stuff to it?


 Again, use "dub describe" to read the data, then write to
 "dub.{whatever}".


 I think we need a command like `dub normalize` that'll


 "dub describe"


 convert the dub.json file into a pure JSON file


 "dub describe"


that has exactly the
 same data, so IDEs could call it before loading dub.json.


 I don't see the problem.


 `dub describe` does not give you a normalized version of 
 "dub.json". It
 gives you something else:

 $ dub init
 Successfully created an empty project in '/tmp/dub-test'.
 $ dub describe > dub.json.new
 $ mv dub.json.new dub.json
 $ dub describe
 Error executing command describe: Got .name of type undefined 
 - expected
 string.


 Ok, I see now. Yea, that could be improved. Luckily it 
 shouldn't be a difficult feature to add, though.


 `dub describe` is perfect for automated tools that want to 
 query DUB,
 but it's not a solution for tools that need to modify it.


 Well, it would probably work, it just wouldn't be an ideal 
 solution. But again, that "dub normalize" you suggest (or "dub 
 describe --normalize" or something) should do the trick. So it 
 doesn't appear to be a deal-breaker for supporting another 
 language, it's just an additional TODO for dub.


I don't like `dub describe --normalize` - it implies that the 
regular `dub describe` is in some non-normalize format and adding 
this flag will normalize the output. If you want to add 
normalization as a `dub describe` flag, I'd prefer something like 
`dub describe --buildfile-only`
Aug 27 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/27/2014 3:26 PM, Idan Arye wrote:

 I don't like `dub describe --normalize` - it implies that the regular
 `dub describe` is in some non-normalize format and adding this flag will
 normalize the output. If you want to add normalization as a `dub
 describe` flag, I'd prefer something like `dub describe --buildfile-only`


Yea, that's better. I just meant "Maybe a flag for 'describe' rather 
than a separate dub command." and didn't feel like coming up with an 
alternative name. :)
Aug 27 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 25 August 2014 at 22:14:59 UTC, Idan Arye wrote:

 About the language - if you are making a new data serialization 
 language(NOT markup language. These languages don't actually 
 mark anything up) for DUB, could you please make it support 
 heredocs? This will allow, in the future, to easily add 
 pre-build and post-build scripts directly in the build-file.


If it's something non-trivial, it should be put into separate 
file at least to get dedicated syntax highlighting and editor 
support.
Aug 27 2014
prev sibling next sibling parent reply "Weaseldog" <weaseldog gmail.com> writes:
On Monday, 25 At 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


Have you considered TOML? Rust's cargo uses it; it's very clean 
IMO. Like an extension to INI.
Aug 25 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 25 August 2014 at 22:21:49 UTC, Weaseldog wrote:

 On Monday, 25 At 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some people's opinions on whether we should really use SDL.  
 I've posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 Have you considered TOML? Rust's cargo uses it; it's very clean 
 IMO. Like an extension to INI.


TOML was one of the candidates I looked at.  I like it.  The 
biggest advantage that ASON would have over TOML for DUB is it is 
a superset of JSON.  TOML has it's own advantages, I personally 
wouldn't mind using it.
Aug 25 2014
parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, Aug 25, 2014 at 4:08 PM, Jonathan Marler via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 25 August 2014 at 22:21:49 UTC, Weaseldog wrote:


 On Monday, 25 At 2014 at 16:40:10 UTC, Jonathan Marler wrote:


 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some people's
 opinions on whether we should really use SDL.  I've posted my thoughts
 here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.
 dub/thread/2263/


 Have you considered TOML? Rust's cargo uses it; it's very clean IMO. Like
 an extension to INI.


 TOML was one of the candidates I looked at.  I like it.  The biggest
 advantage that ASON would have over TOML for DUB is it is a superset of
 JSON.  TOML has it's own advantages, I personally wouldn't mind using it.



If you are going to use a superset of JSON (which I heartily agree with)
then should just go ahead and use one of the many existing ones rather than
rolling yet another.

Google turns up quite a few, pretty much all of which are equivalent to
ASON in features.  Find one that has decent support and run with it.
Aug 25 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
 If you are going to use a superset of JSON (which I heartily 
 agree with)
 then should just go ahead and use one of the many existing ones 
 rather than
 rolling yet another.

 Google turns up quite a few, pretty much all of which are 
 equivalent to
 ASON in features.  Find one that has decent support and run 
 with it.


Yes there are some reasonable ones out there.  I would be happy 
using some of the other JSON variants.  FWIW, here's what makes 
ASON unique from other JSON variants:

1. Singular named list elements

   Helps solve the deep nesting issue with DUB package files.

2. Supports nameless fields

   This is an interesting feature that isn't very useful for DUB 
but could be very useful for other applications.  I designed ASON 
to be useful in the general case so it could be more widely 
accepted.

3. Supports tables

   As a data interchange format, this feature can really cut down 
on the size and maintenance of long lists of objects.  Another 
feature that could make ASON more useful in general cases.

For the details on each of these features, see the ASON spec: 
https://github.com/marler8997/mored/wiki/ASON-(Application-Specific-Object-Notation)
Aug 25 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


Please no custom markup languages when existing ones are good 
enough.
Aug 25 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some people's opinions on whether we should really use SDL.  
 I've posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 Please no custom markup languages when existing ones are good 
 enough.


Are they good enough really? I've tested it all.

- SDL is _whitespace sensitive_ and have a date data-type which 
complicate the parser for little good. Lack of parsers ensues.
- I've actually tested TOML. It has a weird edge case for tables 
of hashes and hashes of tables, it's not composable syntax and 
the worst of the bunch as far as I'm concerned. TOML is also 
whitespace sensitive.
- JSON has no comments, also trailing commas are disallowed (but 
allowed in DUB which push constraints on foreign parsers)
- XML is XML. I find it actually OK.

To me ASON (minus unnamed fields minus unquoted values :) ) is 
certainly a better configuration format, and being JSON 
compatible doesn't hurt.
Aug 26 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:

 On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:





 - SDL is _whitespace sensitive_


I don't like this.


 - JSON has no comments, also trailing commas are disallowed


To me, these are not very bad limitations. Yes, I would like 
comments, but I could leave without, especially if fields have 
meaningful names.


 - XML is XML. I find it actually OK.


I would support this. Yes, is verbose, we know that. But is a 
very solid foundation.

My vote would go for JSON and/or XML (why not both formats?).

But I am against a new language. We have enough...
Aug 26 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 26 Aug 2014 08:53:44 +0000
eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 - XML is XML. I find it actually OK.


 I would support this. Yes, is verbose, we know that. But is a=20
 very solid foundation.


any homemade format or character soup is better than XML. it's not only
verbose, it's hard to write, hard to read and hard to parse. the worst
from all worlds.
Aug 26 2014
parent reply "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 09:12:36 UTC, ketmar via 
Digitalmars-d wrote:

 On Tue, 26 Aug 2014 08:53:44 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:



 the worst
 from all worlds.


Granted, but still the "most standard" and you find a lot of 
standard tools to process it.

Are the drawbacks of JSON so big? Why to move away from it and, 
more, towards another, custom-built, markup language. Isolating D 
even more from the rest of the world?
Aug 26 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 26 Aug 2014 09:32:09 +0000
eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Are the drawbacks of JSON so big? Why to move away from it


i don't know too. i think that it's enough to add three features to
current json parser to be happy:
1. comments, both '//' and '/* */.
2. unquoted field names.
3. ignoring trailing commas.

ah, optional 4th feature: allow omiting highest-level curly brackets.

this additions will not break any existing json definitions, but allow
us to use some human-friendly features.
Aug 26 2014
next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Are the drawbacks of JSON so big? Why to move away from it


 i don't know too. i think that it's enough to add three features to
 current json parser to be happy:
 1. comments, both '//' and '/* */.
 2. unquoted field names.
 3. ignoring trailing commas.

 ah, optional 4th feature: allow omiting highest-level curly brackets.

 this additions will not break any existing json definitions, but allow
 us to use some human-friendly features.


I agree. Those would be the points with most impacts. However, the 
outcome would be quite far away from standard JSON, so we would really 
be talking about something like ASON or SDL already.
Aug 26 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 26 Aug 2014 12:20:55 +0200
S=C3=B6nke Ludwig via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I agree. Those would be the points with most impacts. However, the=20
 outcome would be quite far away from standard JSON, so we would
 really be talking about something like ASON or SDL already.


most widely-used json parsers supports that three features anyway, i
believe, so it's almost safe to just add 'em.

yes, we can have other backends -- xml, ason, sdl, anything. but i
can't see any sane reasons to add such backends. they will lead to code
bloating, more testing and will just confuse end-users ("oh, which
backend i should use? why there are so many?").
Aug 26 2014
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 10:20:53 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:





 I agree. Those would be the points with most impacts. However, 
 the outcome would be quite far away from standard JSON, so we 
 would really be talking about something like ASON or SDL 
 already.


There are some beginnings like this one:

http://json5.org/
Aug 26 2014
parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
  I agree. Those would be the points with most impacts. However, the

 outcome would be quite far away from standard JSON, so we would really be
 talking about something like ASON or SDL already.


 There are some beginnings like this one:

 http://json5.org/


Here's another, that supports tables:
https://github.com/krisnye/ion

Unfortunately there doesn't seem to be any decently popular winner of the
'extended JSON' language, apparently most are fine with just adding
comments.  YAML might be a choice, but I find it diverges a bit too far
(and I'm not a fan of significant whitespace).
Aug 26 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via 
Digitalmars-d wrote:

  I agree. Those would be the points with most impacts. 
 However, the

 outcome would be quite far away from standard JSON, so we 
 would really be
 talking about something like ASON or SDL already.


 There are some beginnings like this one:

 http://json5.org/


 Here's another, that supports tables:
 https://github.com/krisnye/ion

 Unfortunately there doesn't seem to be any decently popular 
 winner of the
 'extended JSON' language, apparently most are fine with just 
 adding
 comments.  YAML might be a choice, but I find it diverges a bit 
 too far
 (and I'm not a fan of significant whitespace).


Well, ion already has that in its name: "indented object 
notation" :-(

Basic YAML is not so bad (apart from significant whitespace, 
which I also dislike), but the full specification is surprisingly 
complicated (properties, tags, lots of different ways to format 
text...). Even though it wouldn't be utilized in most cases, 
these features would still need to be supported.

SDL is preferable IMO.
Aug 26 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 26 August 2014 at 20:18:10 UTC, Marc Schütz wrote:

 On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via 
 Digitalmars-d wrote:

 I agree. Those would be the points with most impacts. 
 However, the

 outcome would be quite far away from standard JSON, so we 
 would really be
 talking about something like ASON or SDL already.


 There are some beginnings like this one:

 http://json5.org/


 Here's another, that supports tables:
 https://github.com/krisnye/ion

 Unfortunately there doesn't seem to be any decently popular 
 winner of the
 'extended JSON' language, apparently most are fine with just 
 adding
 comments.  YAML might be a choice, but I find it diverges a 
 bit too far
 (and I'm not a fan of significant whitespace).


 Well, ion already has that in its name: "indented object 
 notation" :-(

 Basic YAML is not so bad (apart from significant whitespace, 
 which I also dislike), but the full specification is 
 surprisingly complicated (properties, tags, lots of different 
 ways to format text...). Even though it wouldn't be utilized in 
 most cases, these features would still need to be supported.

 SDL is preferable IMO.


Since YAML is common enough to have implementations for most 
popular programming languages, supporting it's complicated 
features should not be a problem.
Aug 26 2014
prev sibling parent "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 10:20:53 UTC, Sönke Ludwig wrote:

 Am 26.08.2014 12:00, schrieb ketmar via Digitalmars-d:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:





 I agree. Those would be the points with most impacts. However, 
 the outcome would be quite far away from standard JSON, so we 
 would really be talking about something like ASON or SDL 
 already.


Anyway, if moving away from JSON is a must, and SDL will be good 
enough, the I would vote for it.
Aug 26 2014
prev sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via 
Digitalmars-d wrote:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Are the drawbacks of JSON so big? Why to move away from it


 i don't know too. i think that it's enough to add three 
 features to
 current json parser to be happy:
 1. comments, both '//' and '/* */.


Not exactly that, but look here two approaches for introducing 
comments in standard JSON:

1: a convention

http://stackoverflow.com/a/244858


2: a hack

http://fadefade.com/json-comments.html
Aug 26 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 26 Aug 2014 10:36:14 +0000
eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Not exactly that, but look here two approaches for introducing=20
 comments in standard JSON:


they both 'hacks'. and i'm pretty sure that most people who using JSON
never bother to read specs, they just expect it to work "like
javascript". i myself wasn't aware about JSON limitations when i was
writing my own JSON parser, so my parser allows comments and unquoted
field names from the beginning.

i'm still sure that JSON specs are needlessly strict in some areas, and
specs should include comments from the start...
Aug 26 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 26 Aug 2014 13:47:05 +0300
schrieb ketmar via Digitalmars-d <digitalmars-d puremagic.com>:


 On Tue, 26 Aug 2014 10:36:14 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:
=20

 Not exactly that, but look here two approaches for introducing=20
 comments in standard JSON:


 they both 'hacks'. and i'm pretty sure that most people who using JSON
 never bother to read specs, they just expect it to work "like
 javascript". i myself wasn't aware about JSON limitations when i was
 writing my own JSON parser, so my parser allows comments and unquoted
 field names from the beginning.


It depends on the personality of the person looking into
it. Diligent people, when faced with something that looks like
something else, first drop that notion to avoid taking
incorrect shortcuts subconsciously. Then they read the official
documentation until they can't imagine any more questions
and corner cases of the kind "Is there a length limitation for
numbers? How do i deal with overflow? Are other encodings than
Unicode allowed?"

But in the end it comes down to the robustness principle:
Be conservative in what you do,
be liberal in what you accept from others.

--=20
Marco
Aug 26 2014
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 26 August 2014 at 10:36:15 UTC, eles wrote:

 On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via 
 Digitalmars-d wrote:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Are the drawbacks of JSON so big? Why to move away from it


 i don't know too. i think that it's enough to add three 
 features to
 current json parser to be happy:
 1. comments, both '//' and '/* */.


 Not exactly that, but look here two approaches for introducing 
 comments in standard JSON:

 1: a convention

 http://stackoverflow.com/a/244858


 2: a hack

 http://fadefade.com/json-comments.html


These are mostly useful for documentation comments, but not so 
much for disabling parts of the definitions temporarily, which 
would be my primary use case.
Aug 26 2014
parent "eles" <eles eles.com> writes:
On Tuesday, 26 August 2014 at 11:19:34 UTC, Marc Schütz wrote:

 On Tuesday, 26 August 2014 at 10:36:15 UTC, eles wrote:

 On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via 
 Digitalmars-d wrote:

 On Tue, 26 Aug 2014 09:32:09 +0000
 eles via Digitalmars-d <digitalmars-d puremagic.com> wrote:







 These are mostly useful for documentation comments, but not so 
 much for disabling parts of the definitions temporarily, which 
 would be my primary use case.


Yes, I missed that. Good point.
Aug 26 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/26/2014 4:53 AM, eles wrote:

 On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:

 - SDL is _whitespace sensitive_


 I don't like this.


That's somewhat misleading.

More accurately, SDL is newline-delimited (with backslash line 
continuation). That's pretty darn simple and has an age-old history. 
It's not like we're talking weird Python/JavaScript rules or anything here.

The only thing that does trip people up is that the existence of { and } 
in the syntax makes people think "C-family and therefore freeform". And 
then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!" 
Well...or something vaguely sorta kinda like that ;)



 - JSON has no comments, also trailing commas are disallowed


 To me, these are not very bad limitations. Yes, I would like comments,
 but I could leave without, especially if fields have meaningful names.


Personally, I find those, along with the syntax noise, to be the three 
core pillars of JSON pain.



 - XML is XML. I find it actually OK.


 I would support this. Yes, is verbose, we know that. But is a very solid
 foundation.


XML is the spawn of satan. And not the cool "rock n roll", "heavy metal" 
kind of satan, or the bumbling lovable DBZ "Mr. 'Hercule' Satan" either, 
but the "hey, let's write a commercial webserver in shell scripts" kind 
of raw pulsating evil.
Aug 26 2014
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky 
wrote:

 That's somewhat misleading.

 More accurately, SDL is newline-delimited (with backslash line 
 continuation). That's pretty darn simple and has an age-old 
 history. It's not like we're talking weird Python/JavaScript 
 rules or anything here.

 The only thing that does trip people up is that the existence 
 of { and } in the syntax makes people think "C-family and 
 therefore freeform". And then it isn't, so that makes them 
 angry. "Yeeargh! Hulk Not Want!" Well...or something vaguely 
 sorta kinda like that ;)


That's justified, because SDL fails to not surprise. Curly brace 
syntaxes are not line-delimited not requires backslash line 
continuations.


 - XML is XML. I find it actually OK.


 I would support this. Yes, is verbose, we know that. But is a 
 very solid
 foundation.


 XML is the spawn of satan. And not the cool "rock n roll", 
 "heavy metal" kind of satan, or the bumbling lovable DBZ "Mr. 
 'Hercule' Satan" either, but the "hey, let's write a commercial 
 webserver in shell scripts" kind of raw pulsating evil.


What's wrong with XML? I work with it daily and see no problem. 
The less syntax a language has, the worse it scales, and if it 
doesn't scale, its adoption creates a technical debt. 100 lines 
with 3 levels of nesting and JSON becomes hard to follow and TOML 
becomes simply unmanageable.
Aug 27 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.08.2014 10:02, schrieb Kagamin:

 On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:

 That's somewhat misleading.

 More accurately, SDL is newline-delimited (with backslash line
 continuation). That's pretty darn simple and has an age-old history.
 It's not like we're talking weird Python/JavaScript rules or anything
 here.

 The only thing that does trip people up is that the existence of { and
 } in the syntax makes people think "C-family and therefore freeform".
 And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
 Well...or something vaguely sorta kinda like that ;)


 That's justified, because SDL fails to not surprise. Curly brace
 syntaxes are not line-delimited not requires backslash line continuations.


Like JavaScript for example?


 - XML is XML. I find it actually OK.


 I would support this. Yes, is verbose, we know that. But is a very solid
 foundation.


 XML is the spawn of satan. And not the cool "rock n roll", "heavy
 metal" kind of satan, or the bumbling lovable DBZ "Mr. 'Hercule'
 Satan" either, but the "hey, let's write a commercial webserver in
 shell scripts" kind of raw pulsating evil.


 What's wrong with XML? I work with it daily and see no problem. The less
 syntax a language has, the worse it scales, and if it doesn't scale, its
 adoption creates a technical debt. 100 lines with 3 levels of nesting
 and JSON becomes hard to follow and TOML becomes simply unmanageable.


The reason to search for an additional format is to make it more 
convenient and readable for human interaction. XML wouldn't structurally 
a bad choice, but is awful because of it's syntactical overhead.
Aug 27 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:

 Am 27.08.2014 10:02, schrieb Kagamin:

 On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky 
 wrote:





 The reason to search for an additional format is to make it 
 more convenient and readable for human interaction.


There is also this quest:

http://www.gnu.org/software/recutils/
Aug 27 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.08.2014 11:47, schrieb eles:

 On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:

 Am 27.08.2014 10:02, schrieb Kagamin:

 On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:





 The reason to search for an additional format is to make it more
 convenient and readable for human interaction.


 There is also this quest:

 http://www.gnu.org/software/recutils/


It seems to be missing built-in array types and nested maps/objects. It 
*looks* like it would require defining so many custom types that it 
would become a de-facto custom format. Still looks interesting in 
general, though.
Aug 27 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:

 That's justified, because SDL fails to not surprise. Curly 
 brace
 syntaxes are not line-delimited not requires backslash line 
 continuations.


 Like JavaScript for example?


You mean its feature where it can work without semicolons? Yeah, 
that's a silly feature, but it's not forced on everyone. I have 
never hit it in my code.


 The reason to search for an additional format is to make it 
 more convenient and readable for human interaction. XML 
 wouldn't structurally a bad choice, but is awful because of 
 it's syntactical overhead.


Aren't people more concerned with writing XML rather than 
reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
"menu": { "id": "file", "value": "File" }
<menu id="file" value="File"/>
It's even shorter!
Aug 27 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 27 August 2014 at 13:32:56 UTC, Kagamin wrote:

 On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig 
 wrote:

 That's justified, because SDL fails to not surprise. Curly 
 brace
 syntaxes are not line-delimited not requires backslash line 
 continuations.


 Like JavaScript for example?


 You mean its feature where it can work without semicolons? 
 Yeah, that's a silly feature, but it's not forced on everyone. 
 I have never hit it in my code.


 The reason to search for an additional format is to make it 
 more convenient and readable for human interaction. XML 
 wouldn't structurally a bad choice, but is awful because of 
 it's syntactical overhead.


 Aren't people more concerned with writing XML rather than 
 reading? Syntax makes for easier reading and tedious writing.
 And overhead is not really big:
 "menu": { "id": "file", "value": "File" }
 <menu id="file" value="File"/>
 It's even shorter!


Yes writing it is what I'm concerned about.  If you like XML 
though, you're gonna love SDL:)

menu id="file" value="File"

It's even shorter again!

There's 1 to 1 mapping between SDL and XML, SDL just uses 
curly-braces and newlines instead of the <angle-brackets>.
Aug 27 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/27/2014 5:27 AM, Sönke Ludwig wrote:

 Am 27.08.2014 10:02, schrieb Kagamin:

 On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:

 That's somewhat misleading.

 More accurately, SDL is newline-delimited (with backslash line
 continuation). That's pretty darn simple and has an age-old history.
 It's not like we're talking weird Python/JavaScript rules or anything
 here.

 The only thing that does trip people up is that the existence of { and
 } in the syntax makes people think "C-family and therefore freeform".
 And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!"
 Well...or something vaguely sorta kinda like that ;)


 That's justified, because SDL fails to not surprise. Curly brace
 syntaxes are not line-delimited not requires backslash line
 continuations.




Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I 
don't think it's a critical one.

Besides, this thread's (dare I say "bikeshedded"?) quest for an ideal 
data language seems doomed from the start: If we try to avoid the less 
common ones, and avoid inventing our own (which I think we have good 
reason to avoid), then everything left *does* have imperfections.

Therefore, I think the main critera we should be looking at here, for 
any of the possibilities, isn't "Does this language have flaws?" but 
rather "Is this language *good enough* to be supported by DUB as a JSON 
alternative?"


 Like JavaScript for example?


Heh, there is that.



 What's wrong with XML? I work with it daily and see no problem. The less
 syntax a language has, the worse it scales, and if it doesn't scale, its
 adoption creates a technical debt. 100 lines with 3 levels of nesting
 and JSON becomes hard to follow and TOML becomes simply unmanageable.


 The reason to search for an additional format is to make it more
 convenient and readable for human interaction. XML wouldn't structurally
 a bad choice, but is awful because of it's syntactical overhead.


That's a big one. *The* big one in my mind.

Additionally, despite XML's simplistic appearance, some of the details 
about it get disturbingly over-engineered. Heck, take a look at W3C's 
docs on it: for something that's *supposed* to be as simple as:

<tag1>
     <tag2 attr="value">blah</tag2>
     <tag3 />
</tag1>

For something that *appears* to be that simple, it's formal reality is 
horrifically complicated.

Besides, there's nothing stopping a good editor from taking this:

{
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }
}

And adding helper visuals (not part of the actual document) to display 
it as this:

{
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }  <i>"tag1"</i>
} <i>{root}</i>

(The <i></i> wouldn't be displayed, I just put them there to indicate 
the text inside would be visually distinguished so that the user finds 
it obvious it's not actually part of the document. Can't really emulate 
that in a NG post.)

I don't know why no editors ever do that.
Aug 27 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky 
wrote:

 Besides, there's nothing stopping a good editor from taking 
 this:

 {
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }
 }

 And adding helper visuals (not part of the actual document) to 
 display it as this:

 {
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }  <i>"tag1"</i>
 } <i>{root}</i>

 (The <i></i> wouldn't be displayed, I just put them there to 
 indicate the text inside would be visually distinguished so 
 that the user finds it obvious it's not actually part of the 
 document. Can't really emulate that in a NG post.)


You just acknowledged succinct languages don't scale, and the 
only way to make them scale is to turn them into syntactical 
equivalent of XML with closing tags. And even then more verbose 
than XML itself. So what's a difference from XML if good config 
language still must have XML syntax?


 I don't know why no editors ever do that.


The editors show only what's written and written is JSON, not 
JSON++.
Aug 28 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/28/2014 5:29 AM, Kagamin wrote:

 On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky wrote:

 Besides, there's nothing stopping a good editor from taking this:

 {
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }
 }

 And adding helper visuals (not part of the actual document) to display
 it as this:

 {
     "tag1" : {
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
         ...blah, blah, blah, blah...
     }  <i>"tag1"</i>
 } <i>{root}</i>

 (The <i></i> wouldn't be displayed, I just put them there to indicate
 the text inside would be visually distinguished so that the user finds
 it obvious it's not actually part of the document. Can't really
 emulate that in a NG post.)


 You just acknowledged succinct languages don't scale,


No, I've only acknowledged that they don't exhibit *perfect* scaling. 
They certainly still scale. And they can scale even better with a little 
editor help.


 and the only way
 to make them scale is to turn them into syntactical equivalent of XML
 with closing tags. And even then more verbose than XML itself. So what's
 a difference from XML if good config language still must have XML syntax?


The differences (off the top of my head, there may be more):

- Nobody has to actually write the closing
- Nobody had to keep the opening/closing in sync
- The closing takes up zero bytes
- Nobody has to actually look at the closing if they want to reduce the 
visual clutter: Ie, viewing it is an optional thing.


 I don't know why no editors ever do that.


 The editors show only what's written and written is JSON, not JSON++.


My editor shows all sorts of stuff that ain't written. Line numbers, 
80-col mark, visible whitespace/EOLs, indent guides, a horizontal line 
to denote folded code sections, etc. You're not going to split hairs and 
claim those are fundamentally/meaningfully different from what I'm 
suggesting are you?
Aug 28 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky 
wrote:

 On 8/28/2014 5:29 AM, Kagamin wrote:

 and the only way
 to make them scale is to turn them into syntactical equivalent 
 of XML
 with closing tags. And even then more verbose than XML itself. 
 So what's
 a difference from XML if good config language still must have 
 XML syntax?


 The differences (off the top of my head, there may be more):

 - Nobody has to actually write the closing
 - Nobody had to keep the opening/closing in sync
 - The closing takes up zero bytes
 - Nobody has to actually look at the closing if they want to 
 reduce the visual clutter: Ie, viewing it is an optional thing.


So it has no advantage over using a grammar-based XML editor, 
just less flexible and more clumsy… Sounds like the wrong 
trade-off.

(tags don't take much space when the file is compressed)
Aug 28 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/28/2014 5:07 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:

 On 8/28/2014 5:29 AM, Kagamin wrote:

 and the only way
 to make them scale is to turn them into syntactical equivalent of XML
 with closing tags. And even then more verbose than XML itself. So what's
 a difference from XML if good config language still must have XML
 syntax?


 The differences (off the top of my head, there may be more):

 - Nobody has to actually write the closing
 - Nobody had to keep the opening/closing in sync
 - The closing takes up zero bytes
 - Nobody has to actually look at the closing if they want to reduce
 the visual clutter: Ie, viewing it is an optional thing.


 So it has no advantage over using a grammar-based XML editor, just less
 flexible and more clumsy… Sounds like the wrong trade-off.


I could easily turn that around and say a grammar-based XML editor has 
no advantage over my suggestion. I certainly don't see what's "less 
flexible" about it. And I find some of the tricks that grammar-based XML 
editors do to be clumsy and in-my-way (specifically when they 
automagically insert text I didn't type).

*Without* any editor support, JSON-style and XML-style both have pro/con 
tradeoffs. I prefer the JSON-style tradeoffs.

*With* an ideal level of editor support, JSON-style and XML-style can 
pretty much reach feature parity.

I still hate dealing with XML though ;)


 (tags don't take much space when the file is compressed)


If it really needs to be compressed, then the format may be too verbose 
anyway. It doesn't really strike me as passing the "less clumsy" 
criteria either. Ehh, but I'm a fan of binary for interchange anyway, so 
whatever ;)
Aug 29 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky 
wrote:

 The differences (off the top of my head, there may be more):

 - Nobody has to actually write the closing


True for XML too:
1. many editors already autocomplete it, no need to wonder, why 
nobody implemented it;
2. if you need a new document fragment, you just copy existing 
one and tweak it to new needs; and it's easier and faster this 
way with succinct languages too;


 - Nobody had to keep the opening/closing in sync


Huh? Never needed that. And it's the same with json and sdl: if 
you add new brace you need to go find the appropriate brace, 
after which to insert new brace, and there you see lisp-style 
stairway of indiscernible braces (with commas, yay).


 - The closing takes up zero bytes


I'd say, it's dwarfed by everything else especially indentation.


 - Nobody has to actually look at the closing if they want to 
 reduce the visual clutter: Ie, viewing it is an optional thing.


And get lost, when it doesn't cut it.

Oh and it makes no sense to add a non-trivial editor support for 
json, because it's a format buried in a dark corner of javascript 
ecosystem, and even there it's used as a serialization format for 
data exchange (that's because it doesn't have comments) instead 
of long-living manually written documents.
Aug 29 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/29/2014 7:37 AM, Kagamin wrote:

 On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky wrote:

 The differences (off the top of my head, there may be more):

 - Nobody has to actually write the closing


 True for XML too:
 1. many editors already autocomplete it, no need to wonder, why nobody
 implemented it;


Personally, I don't like that auto-insert stuff, it just trips me up.

In any case, I don't see how that feature provides much benefit over my 
suggestion. If you don't mind the auto-inserted text, then it's pretty 
much on par with my suggestion.



 2. if you need a new document fragment, you just copy existing one and
 tweak it to new needs; and it's easier and faster this way with succinct
 languages too;


Yea, I do that to. But stuff, would you be ok with this (not rhetorical)?:

while(cond)
   if cond
     ...
   end if
end while

etc.

Yea, obviously I *can* use a language like that. I prefer not to.



 - Nobody had to keep the opening/closing in sync


 Huh? Never needed that.


(Just to be clear we're on the same page here, I'm not sure if I was 
clear enough) You've never needed to change the name of a tag? Change 
one, gotta change the other to match.


 And it's the same with json and sdl: if you add
 new brace you need to go find the appropriate brace,


Not what I'm talking about with "keep the opening/closing in sync"


 after which to
 insert new brace, and there you see lisp-style stairway of indiscernible
 braces (with commas, yay).


Didn't I just suggest a simple editor feature to eliminate that problem? 
Isn't that proposed feature exactly what we're currently debating?


 - The closing takes up zero bytes


 I'd say, it's dwarfed by everything else especially indentation.


Fine.


 - Nobody has to actually look at the closing if they want to reduce
 the visual clutter: Ie, viewing it is an optional thing.


 And get lost, when it doesn't cut it.


If that doesn't always cut it, then neither do XML-style matching end tags.


 Oh and it makes no sense to add a non-trivial editor support for json,
 because it's a format buried in a dark corner of javascript ecosystem,
 and even there it's used as a serialization format for data exchange
 (that's because it doesn't have comments) instead of long-living
 manually written documents.


JSON's extremely common, and I never intended the idea as being 
exclusively for JSON alone.

This is the part that I don't understand why people seem to be either 
missing or disagreeing with:

-----------------------------------
(XML-style) Matching end-tags:
     Have to type, always visible even when it's clutter.

(JSON-stye) Dedicated one-char end-tags:
     Visually indistinct, can't see which is which at a glance even when 
you want to.

Auto-inserted text (if you like that sort of thing), and a feature to 
optionally hide/collapse end tags:
     ***Eliminates cons of XML-style matching end-tags.***

Feature to optionally show the tag name at the closing brace:
     ***Eliminates cons of JSON-stye dedicated one-char end-tags.***

Result:
     ***Feature parity and everyone's happy.*** Except...somehow they're 
*not* and still complain and nitpick anyway...? I don't get it.
-----------------------------------
Aug 29 2014
parent reply "Kagamin" <spam here.lot> writes:
On Friday, 29 August 2014 at 19:53:26 UTC, Nick Sabalausky wrote:

 True for XML too:
 1. many editors already autocomplete it, no need to wonder, 
 why nobody
 implemented it;


 Personally, I don't like that auto-insert stuff, it just trips 
 me up.


Didn't you argue for autoinserting? If you don't want it, you can 
turn it off (it's implemented).


 2. if you need a new document fragment, you just copy existing 
 one and
 tweak it to new needs; and it's easier and faster this way 
 with succinct
 languages too;


 Yea, I do that to. But stuff, would you be ok with this (not 
 rhetorical)?:

 while(cond)
   if cond
     ...
   end if
 end while

 etc.

 Yea, obviously I *can* use a language like that. I prefer not 
 to.


General-purpose programming languages usually allow arbitrary 
code organization, documents don't. And nested blocks are usually 
nested ifs (or #ifs), so #endifs don't add lots of information, 
while in a document almost every element is unique.


 - Nobody has to actually look at the closing if they want to 
 reduce
 the visual clutter: Ie, viewing it is an optional thing.


 And get lost, when it doesn't cut it.


 If that doesn't always cut it, then neither do XML-style 
 matching end tags.


When they are invisible when you decided it's clutter.


 Oh and it makes no sense to add a non-trivial editor support 
 for json,
 because it's a format buried in a dark corner of javascript 
 ecosystem,
 and even there it's used as a serialization format for data 
 exchange
 (that's because it doesn't have comments) instead of 
 long-living
 manually written documents.


 JSON's extremely common, and I never intended the idea as being 
 exclusively for JSON alone.


Serialization format for web services is the only application I 
know.


 This is the part that I don't understand why people seem to be 
 either missing or disagreeing with:

 -----------------------------------
 (XML-style) Matching end-tags:
     Have to type, always visible even when it's clutter.


If you don't want to type or copy them, there's autocomplete. 
Small documents have no clutter because of their sheer size and 
simplicity, big documents need xml-style visualization anyway.


 (JSON-stye) Dedicated one-char end-tags:
     Visually indistinct, can't see which is which at a glance 
 even when you want to.



 Feature to optionally show the tag name at the closing brace:
     ***Eliminates cons of JSON-stye dedicated one-char 
 end-tags.***


BTW, json can simply reuse javascript lexer, which doesn't do 
anything json-specific. Maybe, json is just meant to be succinct 
and doing otherwise goes against its design?


 In any case, I don't see how that feature provides much benefit 
 over my suggestion. If you don't mind the auto-inserted text, 
 then it's pretty much on par with my suggestion.



 Result:
     ***Feature parity and everyone's happy.*** Except...somehow 
 they're *not* and still complain and nitpick anyway...? I don't 
 get it.
 -----------------------------------


Your suggestion is a hack and less popular than XML. Though, I 
don't see why create the problem with succinct language and then 
heroically solve it? (oh, wait, not yet)
Sep 02 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 9/2/2014 5:33 AM, Kagamin wrote:

 On Friday, 29 August 2014 at 19:53:26 UTC, Nick Sabalausky wrote:

 True for XML too:
 1. many editors already autocomplete it, no need to wonder, why nobody
 implemented it;


 Personally, I don't like that auto-insert stuff, it just trips me up.


 Didn't you argue for autoinserting? If you don't want it, you can turn
 it off (it's implemented).


I think it's great that it exists *for the people who DO like it*. I'm 
just not one of them. It conflicts with my automatic muscle memory and 
my deep-ingrained mental model of keyboard-based computer interaction. :/


 Your suggestion is a hack


It's no more of a hack than ANY modern editor feature.

Besides, that's not even an argument anyway, it's subjective bullshit.

I've pointed out over and over how this and other editor features 
effectively bring the two styles of closing tokens into parity (again, 
assuming one is ok with auto-insert, which many people are). Why are you 
so determined to completely ignore that argument?



 and less popular than XML.


That's even more nonsensical: You're not actually going to use popularly 
as an argument in a merit-oriented debate, are you?

"That's a flawed idea *because* it's not popular." See? Obviously 
doesn't work.



 Though, I don't see
 why create the problem with succinct language and then heroically solve
 it? (oh, wait, not yet)


Are you deliberately ignoring the part (which I've already pointed out) 
where this is obviously not limited to merely JSON alone, or even just 
data-formats, at all, but generally applicable to any language which 
uses a single same token to terminate all types of nested blocks?

If you're going to argue something, at least *attempt* to address the 
actual points that have been raised. Otherwise there's no point in 
discussing anything.
Sep 02 2014
prev sibling parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 Therefore, I think the main critera we should be looking at here, for any
 of the possibilities, isn't "Does this language have flaws?" but rather "Is
 this language *good enough* to be supported by DUB as a JSON alternative?"



The 'alternative' bit is the kicker.  Personally, I don't believe DUB can
succeed at having multiple supported config languages - one or the other
will win out over time, and users will diverge.  So no language would meet
that bar (in my opinion).

Mostly we are talking about JSON+stuff as an additional language... so can
it be reframed as 'additional features you can use in your dub config file,
that aren't strict JSON'?

Framing things this way, you could (for example) switch DUB entirely over
to ASON, and avoid the 'switching to a new language' arguments.  DUB takes
JSON, DUB also accepts not-strictly-JSON syntax like comments, etc.
Aug 27 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 29 August 2014 at 02:10:47 UTC, Jeremy Powers via 
Digitalmars-d wrote:

 On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via 
 Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 Therefore, I think the main critera we should be looking at 
 here, for any
 of the possibilities, isn't "Does this language have flaws?" 
 but rather "Is
 this language *good enough* to be supported by DUB as a JSON 
 alternative?"



 The 'alternative' bit is the kicker.  Personally, I don't 
 believe DUB can
 succeed at having multiple supported config languages - one or 
 the other
 will win out over time, and users will diverge.  So no language 
 would meet
 that bar (in my opinion).


I can totally see JSON format being used mostly by the tools and 
new one written by actual developers - everyone gets its niche.
Aug 28 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:

 On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some people's opinions on whether we should really use SDL.  
 I've posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 Please no custom markup languages when existing ones are good 
 enough.


 Are they good enough really? I've tested it all.

 - SDL is _whitespace sensitive_ and have a date data-type which 
 complicate the parser for little good. Lack of parsers ensues.


I believe whitespace sensitivity is a Good Thing for 
human-readable formats. Date type is annoying but simply omitting 
its support sounds more reasonable than going with brand new 
format.
Aug 26 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 27 August 2014 at 02:39:56 UTC, Dicebot wrote:

 I believe whitespace sensitivity is a Good Thing for 
 human-readable formats. Date type is annoying but simply 
 omitting its support sounds more reasonable than going with 
 brand new format.


To elaborate a bit more about whitespace and stuff - JSON is not 
going anywhere and will be available for those who prefer 
conservative syntax. From a new one I do indeed want minimal 
amount of formatting boilerplate and focus on content -> it 
_must_ be whitespace sensitive
Aug 26 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/26/2014 10:39 PM, Dicebot wrote:

 On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:

 - SDL is _whitespace sensitive_ and have a date data-type which
 complicate the parser for little good. Lack of parsers ensues.


 I believe whitespace sensitivity is a Good Thing for human-readable
 formats. Date type is annoying but simply omitting its support sounds
 more reasonable than going with brand new format.


Yea, I don't think anything in dub's configuration even involves 
date/time at all (aside from maybe copyright, but that'd need to be a 
string anyway), so the existence of a date type in SDL is entirely 
irrelevant.

It's not as if Sonke would actually need to write (or maintain) any date 
parsing code. There's already two SDL parsers for D. Dub would just be 
using one of those.
Aug 26 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/26/2014 3:12 AM, ponce wrote:

 - I've actually tested TOML. It has a weird edge case for tables of
 hashes and hashes of tables,


I'm not doubting you, but I'm curious about this. Can you elaborate?


 it's not composable syntax


This too?


 and the worst of
 the bunch as far as I'm concerned. TOML is also whitespace sensitive.


Hmm, ok now I'm wondering if we're even looking at the same TOML. I'm 
looking at this:

https://github.com/toml-lang/toml

Or by "whitespace sensitive" are you just talking about being 
newline-delimited? For a data language, that doesn't really bother me. 
Or have I overlooked something in TOML's description?
Aug 26 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-08-25 at 16:40 +0000, Jonathan Marler via Digitalmars-d
wrote:

 Hello everyone,
=20
 I've been working on SDL support for DUB and wanted to get some=20
 people's opinions on whether we should really use SDL.  I've=20
 posted my thoughts here:=20
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263=


/


With a bit more work this would be a good notation for a D plugin for
Gradle!

I can imagine with Groovy implementing this language would be trivial.

It would be splendid to have a build specification for Dub that also
worked with Gradle.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Aug 26 2014
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 25.08.2014 18:40, schrieb Jonathan Marler:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some people's
 opinions on whether we should really use SDL.  I've posted my thoughts
 here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


Just sharing my (overdue) more detailed view on this:

Pros:
  - Easier to parse
  - Slightly nicer handling of "enum" values due to quote-less strings
  - Whitespace insensitive

Cons:
  - I *really* dislike the "application specific"/"nameless tags" part
    of it, because generic handling always was one of the basic
    prerequisites for me
  - It's a still custom format in practice, even without the "application
    specific" part - except if it (ever) becomes more widespread
  - Confusing wealth of syntax possibilities when punctuation can be
    omitted, I'd very much prefer one way to express one thing
  - A language with neither newline sensitivity, nor required tag
    terminators, I think is bound to give very bad error message in
    certain situations
  - Quote-less strings, especially when mixed with nameless tags or
    omitted punctuation can be very confusing
  - Quote-less strings which are allowed to contain punctuation are
    confusing, because the punctuation can easily be confused as being
    part of the ASON syntax itself

To me, this currently outweighs by far the disadvantages that SDL has:

  - Sensitive to newlines, but not other whitespace. This is convenient,
    although I'd prefer a mandatory semicolon (which ASON doesn't have
    either)
  - Some parser complexities not needed for DUB (e.g. date/time types).
    I'm more or less "meh" about this. It can be nice to have for other
    uses (configuration files) and doesn't really hurt either.

But most important is that SDL is already in use for other (non-minor) 
projects [1] and thus has probably much better chances to become more 
widespread than "yet another JSON extension format" (this is not 
critique of the approach of extending JSON, but rather of how the 
average observer would likely perceive a format advertised that way).

Continuing on that point, an important point for choosing a format was 
to minimize the amount of DUB specific syntax to learn. So if somebody 
has to learn a new language for that, it should at least also be useful 
in other places and any newly invented format is just much less likely 
to generally useful than something that already has some level of 
popularity.

[1]: http://sdl.ikayzo.org/display/SDL/Projects+Using+SDL
Aug 26 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
I just had an "epiphany".  I believe that if I added attributes 
to ASON, it would be a true superset of SDL.  Meaning any SDL 
file would also be a valid ASON file.  What kind of monster did I 
create!  I accidently created a language that serves as both a 
superset of JSON and SDL?  I didn't think that would be possible, 
expecially with such a little amount of extensions to JSON.
Aug 27 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
wrote:

 I just had an "epiphany".  I believe that if I added attributes 
 to ASON, it would be a true superset of SDL.  Meaning any SDL 
 file would also be a valid ASON file.  What kind of monster did 
 I create!  I accidently created a language that serves as both 
 a superset of JSON and SDL?  I didn't think that would be 
 possible, expecially with such a little amount of extensions to 
 JSON.


Perfection is achieved, not when there is nothing more to add, 
but when there is nothing left to take away.
- Antoine de Saint-Exupery
Aug 27 2014
next sibling parent reply "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby 
wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
 wrote:



 Perfection is achieved, not when there is nothing more to add, 
 but when there is nothing left to take away.
 - Antoine de Saint-Exupery


Why to not use a classic?

"Within C++, there is a much smaller and cleaner language 
struggling to get out."

He meant, of course, D. We knew it all along.
Aug 27 2014
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 27 August 2014 at 12:44:00 UTC, eles wrote:

 On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby 
 wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
 wrote:



 Perfection is achieved, not when there is nothing more to add, 
 but when there is nothing left to take away.
 - Antoine de Saint-Exupery


 Why to not use a classic?

 "Within C++, there is a much smaller and cleaner language 
 struggling to get out."

 He meant, of course, D. We knew it all along.


This is why dforums needs a like button:)
Aug 27 2014
prev sibling next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby 
wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
 wrote:

 I just had an "epiphany".  I believe that if I added 
 attributes to ASON, it would be a true superset of SDL.  
 Meaning any SDL file would also be a valid ASON file.  What 
 kind of monster did I create!  I accidently created a language 
 that serves as both a superset of JSON and SDL?  I didn't 
 think that would be possible, expecially with such a little 
 amount of extensions to JSON.


 Perfection is achieved, not when there is nothing more to add, 
 but when there is nothing left to take away.
 - Antoine de Saint-Exupery


On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby 
wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
 wrote:

 I just had an "epiphany".  I believe that if I added 
 attributes to ASON, it would be a true superset of SDL.  
 Meaning any SDL file would also be a valid ASON file.  What 
 kind of monster did I create!  I accidently created a language 
 that serves as both a superset of JSON and SDL?  I didn't 
 think that would be possible, expecially with such a little 
 amount of extensions to JSON.


 Perfection is achieved, not when there is nothing more to add, 
 but when there is nothing left to take away.
 - Antoine de Saint-Exupery


Nice quote, but unfortunately there's no such thing as a perfect 
programming language or a perfect data format.  JSON is dirt 
simple and popular.  However using strict JSON for build 
configuration prevents users from commenting out sections 
temporarily, and also rejects text that can be understood by a 
human but doesn't follow JSON's strict rules.  It also becomes 
very unwieldy when any amount of nesting is involved.  Then 
again, when you start writing data formats that are easier to 
write for humans, you start getting complicated.

IMO, ASON has a nice balance between being very simple and very 
nice for humans to write/maintain.  I also think there are some 
JSON variants that do the same thing, json5 looks nice, but it 
doesn't support the SingularName feature that ASON does which 
would fix the nesting issue.
Aug 27 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler 
wrote:

 IMO, ASON has a nice balance between being very simple and very 
 nice for humans to write/maintain.  I also think there are some 
 JSON variants that do the same thing, json5 looks nice, but it 
 doesn't support the SingularName feature that ASON does which 
 would fix the nesting issue.


I'm not necessarily arguing that Json is great or flexible. I'm 
arguing, well maybe arguing is a strong word, i'm positing that 
something more complicated than Json isn't really needed at this 
time.

I understand the argument that it would be nice for 
human-friendly constructs to be present in the dub file but is 
this really a problem dub is facing at the minute? Are lots of 
devs venting their spleens over not being able to include 
comments, heredoc strings and such in dub files? The dub registry 
is gaining traction lets not throw an obstacle in the road now.

Also inventing a Frankenstein format that is both a superset of 
Json and SDL just sounds horrible and just sounds wrong. It's 
just too much. Your effort would be better directed to something 
which is an immediate problem. Not re-inventing this particular 
wheel.

Sonke has said Json will always be an option in dub. Which is 
fantastic because now that dub has reached an official level as 
the de-facto package manager we need to embrace stability and 
stop this needless change which has been plaguing D forever.

I honestly think Ason should be abandoned as an unneeded solution 
looking for a problem and something more stable and recognised 
like Yaml or XML, etc. implemented in future *if needed* and 
actually if requested by dub's users.
Aug 27 2014
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 27 August 2014 at 15:27:25 UTC, Gary Willoughby 
wrote:

 On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler 
 wrote:

 IMO, ASON has a nice balance between being very simple and 
 very nice for humans to write/maintain.  I also think there 
 are some JSON variants that do the same thing, json5 looks 
 nice, but it doesn't support the SingularName feature that 
 ASON does which would fix the nesting issue.


 I'm not necessarily arguing that Json is great or flexible. I'm 
 arguing, well maybe arguing is a strong word, i'm positing that 
 something more complicated than Json isn't really needed at 
 this time.

 I understand the argument that it would be nice for 
 human-friendly constructs to be present in the dub file but is 
 this really a problem dub is facing at the minute?


Yes. dub is most definitely facing this problem at this minute.


 Are lots of devs venting their spleens over not being able to 
 include comments, heredoc strings and such in dub files? The 
 dub registry is gaining traction lets not throw an obstacle in 
 the road now.


heredoc's is a new one, but comments/nesting/trailing 
commas/unquoted strings, yes, most assuredly yes. Have you not 
been reading people's concerns about JSON? How could you say that 
people aren't complaining?


 Also inventing a Frankenstein format that is both a superset of 
 Json and SDL just sounds horrible and just sounds wrong. It's 
 just too much. Your effort would be better directed to 
 something which is an immediate problem. Not re-inventing this 
 particular wheel.


I most definitely wouldn't call ASON a "Frankenstein" format.  I 
didn't design ASON to be a superset of SDL, that's just how it 
worked out.  Just like YAML happens to be a superset of JSON.  
Instead of saying it "sounds horrible and just sounds wrong", why 
don't you look at the language spec and say what is wrong about 
it.  It's fine if you think we shouldn't use a new language but 
even if no one ever uses it, it's helpful to know what features 
people think are good/bad so we can all learn something.


 Sonke has said Json will always be an option in dub. Which is 
 fantastic because now that dub has reached an official level as 
 the de-facto package manager we need to embrace stability and 
 stop this needless change which has been plaguing D forever.


Yes, JSON will always be used to represent the package format on 
the back-end.  So it makes sense to allow users to use it on the 
front-end if they wish.  And again, adding a new format isn't a 
"needless change", why do you think so many people have such 
strong opinions about what format to use.  You seem to be one of 
the only ones that thinks adding a new format (or using "lenient 
JSON") is a bad thing.


 I honestly think Ason should be abandoned as an unneeded 
 solution looking for a problem and something more stable and 
 recognised like Yaml or XML, etc. implemented in future *if 
 needed* and actually if requested by dub's users.


You seem to be stuck on the idea that I think DUB should use 
ASON. I created this thread so I could learn from other people 
what they think about this format and others.  Even though you 
haven't added anything helpful, after reading other people's 
posts I'm now leaning more towards SDl.  My biggest complaint is 
that it might be confusing for people to go between the SDL 
version and the JSON version.  However, Sonke thinks that he can 
make a much more friendly package format with SDL's extra 
features like tag values/attributes.
Aug 27 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 27 August 2014 at 15:57:41 UTC, Jonathan Marler 
wrote:

 Even though you haven't added anything helpful...


If you don't want input, don't publicly ask for it. Just because 
my input is not what you would deem helpful because it 
contradicts your view does not mean it's of no value. I always 
argue from a standpoint of zero change regarding anything to do 
with D and always will do.

D and its tools are crying out for stability right now. Change 
for change sake has seriously hurt D in the past.


 Yes. dub is most definitely facing this problem at this minute.


Where? in this *one* thread?
Aug 27 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/27/2014 12:57 PM, Gary Willoughby wrote:

 D and its tools are crying out for stability right now. Change for
 change sake has seriously hurt D in the past.


It's also been a critical factor in it's success.

Double-edged sword, admittedly.
Aug 27 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 27 Aug 2014 16:57:52 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 D and its tools are crying out for stability right now.


there is D1. stable as a doornail.
Aug 27 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/14, 5:25 AM, Gary Willoughby wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:

 I just had an "epiphany".  I believe that if I added attributes to
 ASON, it would be a true superset of SDL.  Meaning any SDL file would
 also be a valid ASON file.  What kind of monster did I create!  I
 accidently created a language that serves as both a superset of JSON
 and SDL?  I didn't think that would be possible, expecially with such
 a little amount of extensions to JSON.


 Perfection is achieved, not when there is nothing more to add, but when
 there is nothing left to take away.
 - Antoine de Saint-Exupery


Then perfection in personal finance is easy to achieve :o). -- Andrei
Aug 27 2014
parent "eles" <eles eles.com> writes:
On Thursday, 28 August 2014 at 03:38:25 UTC, Andrei Alexandrescu 
wrote:

 On 8/27/14, 5:25 AM, Gary Willoughby wrote:

 On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler 
 wrote:





 Then perfection in personal finance is easy to achieve :o). --


In corporate finance, too:

http://en.wikipedia.org/wiki/Accounting_scandals#List_of_reported_accounting_scandals
Aug 29 2014
prev sibling next sibling parent reply "Poyeyo" <poyeyo arcadechaser.com> writes:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


Wait, SDL is not Simple DirectMedia Layer ?

You broke my hope.
Aug 28 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/28/2014 9:57 PM, Poyeyo wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some
 people's opinions on whether we should really use SDL.  I've posted my
 thoughts here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 Wait, SDL is not Simple DirectMedia Layer ?

 You broke my hope.


Yea, that unfortunate little naming conflict is why I named my parser 
for it SDLang-D instead of SDL-D.
Aug 29 2014
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
I would now like to invoke the Zero One Infinity 
Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).

Supporting one format makes sense - DUB can simply use the set of 
functions and data structures provided by Phobos or by external 
libraries for using this format.

Supporting two formats will require two sets of functions and 
data structures, and to decide a point where the two code-paths 
will be joined to a single representation of the build 
configuration. According to the ZOI rule, you might as well take 
the extra step and support infinity formats!


This is my idea - the point of entry will remain "dub.json". For 
a project to use SDL for build configuration, "dub.json" will 
look something like this:

     {
         "import" : [
             {
                 "file": "dub.sdl",
                 "parser": "dub-sdl"
             }
         ]
     }

When DUB sees this, it'll download the "dub-sdl" package from the 
DUB repository(unless it already downloaded it) and use it to 
parse "dub.sdl".

There can be a number of ways to do this - maybe DUB will load a 
dynamic library from "dub-sdl" and use the functions directly, or 
maybe "dub-sdl" will convert "dub.sdl" into JSON format that DUB 
can parse directly, or maybe it'll parse it into a binary format 
so it'll be more efficient to serialize and parse it.

It doesn't matter how it ends up done - the point is that DUB 
will decide the method for getting that data and the parser 
packages will have to conform to it. Once the framework is in 
place, we can have "dub-sdl", "dub-ason", "dub-yaml" etc.


This mechanism can also be used for splitting the build file - 
which can be useful if you want to have parts of it updated 
regularly by automatic tools, or to put only parts of the build 
configuration under source control. For this, different file 
names can be put in the "file" field even if they all use the 
same format, and "parser" can be omitted to read JSON files.
Aug 29 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 29 August 2014 at 20:54:49 UTC, Idan Arye wrote:

 I would now like to invoke the Zero One Infinity 
 Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).

 Supporting one format makes sense - DUB can simply use the set 
 of functions and data structures provided by Phobos or by 
 external libraries for using this format.

 Supporting two formats will require two sets of functions and 
 data structures, and to decide a point where the two code-paths 
 will be joined to a single representation of the build 
 configuration. According to the ZOI rule, you might as well 
 take the extra step and support infinity formats!


This might make sense from a technical point of view, but do we 
want it? In the extreme case, we'd end up with a different format 
for each package, though more likely will be a distribution where 
most packages focus on one or two formats, but with a looooong 
tail...


 This mechanism can also be used for splitting the build file - 
 which can be useful if you want to have parts of it updated 
 regularly by automatic tools, or to put only parts of the build 
 configuration under source control. For this, different file 
 names can be put in the "file" field even if they all use the 
 same format, and "parser" can be omitted to read JSON files.


This is useful in any case, no matter how many formats we're 
going to support.
Aug 30 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Saturday, 30 August 2014 at 09:37:55 UTC, Marc Schütz wrote:

 On Friday, 29 August 2014 at 20:54:49 UTC, Idan Arye wrote:

 I would now like to invoke the Zero One Infinity 
 Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).

 Supporting one format makes sense - DUB can simply use the set 
 of functions and data structures provided by Phobos or by 
 external libraries for using this format.

 Supporting two formats will require two sets of functions and 
 data structures, and to decide a point where the two 
 code-paths will be joined to a single representation of the 
 build configuration. According to the ZOI rule, you might as 
 well take the extra step and support infinity formats!


 This might make sense from a technical point of view, but do we 
 want it? In the extreme case, we'd end up with a different 
 format for each package, though more likely will be a 
 distribution where most packages focus on one or two formats, 
 but with a looooong tail...


Well, since we are already talking about implementing a second 
format in addition to JSON, I figured we don't give a rat's ass 
about diversion in packages...
Aug 30 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/25/2014 12:40 PM, Jonathan Marler wrote:

 Hello everyone,

 [endless discussion]


Anyone seen the mystery/comedy/detective show "Monk"?

I've been watching it lately. One interesting quirk about the main 
character Adrian Monk (a character who's humorously *loaded* with 
quirks) is that one must NEVER present him with a choice, especially a 
trivial or inconsequential one. He will contemplate and second-guess it 
endlessly. *Make* the choice instead, without providing him an 
opportunity to debate it with himself, and things work out fine (at 
least until another quirk is triggered).

If Dub had gone the "badly-managed-project" route and unilaterally made 
the call to rip out JSON entirely, replacing it with SDL, back when it 
was first considered...I doubt very much it would have generated 
anywhere near the level of back-and-forth objections and unrest that 
it's now generated over several discussions since. We're designing by 
committee.

We are Adrian Monk. We can't handle choice. ;)
Aug 30 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Saturday, 30 August 2014 at 11:40:01 UTC, Nick Sabalausky 
wrote:

 On 8/25/2014 12:40 PM, Jonathan Marler wrote:



 We are Adrian Monk. We can't handle choice. ;)


You may say anything you want, but I love Monk. And the actor 
impersonating him is just either a genius, either suffer from teh 
same illnes... He's just too perfect.
Aug 30 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/30/2014 8:37 AM, eles wrote:

 On Saturday, 30 August 2014 at 11:40:01 UTC, Nick Sabalausky wrote:

 On 8/25/2014 12:40 PM, Jonathan Marler wrote:



 We are Adrian Monk. We can't handle choice. ;)


 You may say anything you want, but I love Monk.


I do too! I've seen every episode at least twice. Brilliant show, and 
some of the secondary characters are every bit as good as Monk himself, 
like Disher and the captain.

The bikeshedding here just reminded me of Monk's (amusing and endearing) 
inability to handle simple choices. I had to point out the parallel. As 
a collective, we kind of are Monk in some ways. Something worth bearing 
in mind.


 And the actor
 impersonating him is just either a genius, either suffer from teh same
 illnes... He's just too perfect.


Yea, Tony Shalhoub is an incredible actor. You can tell he really did 
his research on the part (although I think his role on Wings helped a 
lot, too. His cab driver role was sort of like an earlier, less extreme 
version of Adrian Monk).

He also did a great job in "Pain & Gain" in a completely polar opposite 
type of role (although very similar to an alternate "Mobster" persona he 
adopted in one episode of Monk, near the end of the series IIRC).
Aug 30 2014
prev sibling next sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 25/08/2014 17:40, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some people's
 opinions on whether we should really use SDL.  I've posted my thoughts
 here:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


My opinion on this subject had been a preference that we use an 
extension to JSON (something like lenient JSON, for example: 
http://developer.android.com/reference/android/util/JsonReader.html#set
enient%28boolean%29 
)
I don't like SDL much (because it's not that well-known, is whitespace 
sensitive, and other reasons). But that's mostly a personal preference, 
SDL is not a bad choice either.

Still, when I read that ASON was being developed, as a possible 
alternative, it looked good, since ASON seemed similar to lenient-JSON. 
But then things took a turn to the worse. Nameless fields, because it 
makes the parsing application specific, is a bad idea. The data format 
should be universal, not application specific. The table feature is 
another thing I think is unnecessary, we should try to the keep the data 
format fairly simple (there's only a few things over plain JSON that I 
think are worth improving). But I think the real dealbreaker is being 
application specific. Given this, I would prefer even SDL to ASON.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Sep 30 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/30/2014 08:15 AM, Bruno Medeiros wrote:

 I don't like SDL much (because it's not that well-known, is whitespace
 sensitive, and other reasons). But that's mostly a personal preference,
 SDL is not a bad choice either.


FWIW, the only "whitespace" sensitivity in SDL is just the fact that 
it's newline-terminated (with optional line-continuation). (Well, and 
the auto-unindending of string literals that use line-continuation.) 
That's really all there is. Again, just FWIW.
Sep 30 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get some 
 people's opinions on whether we should really use SDL.  I've 
 posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


So by ASON, do you mean:
http://www.americanteeth.org/libason/ason_spec.pdf ?  Weirdly
enough, this was published the same day you say you created ASON,
and yet my take on your ASON vs. this ASON is that they're very
different.
Sep 30 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 30 September 2014 at 22:41:15 UTC, Sean Kelly wrote:

 On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler 
 wrote:

 Hello everyone,

 I've been working on SDL support for DUB and wanted to get 
 some people's opinions on whether we should really use SDL.  
 I've posted my thoughts here: 
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


 So by ASON, do you mean:
 http://www.americanteeth.org/libason/ason_spec.pdf ?  Weirdly
 enough, this was published the same day you say you created 
 ASON,
 and yet my take on your ASON vs. this ASON is that they're very
 different.


Oops, for some reason I thought this was a new thread...
Sep 30 2014