www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I hate new DUB config format

reply Suliman <evermind live.ru> writes:
I think that using SDL format was big mistake. Not only I do not 
want to spend time in learning yet another dead config format 
that now use only one project -- DUB. In time when DUB used json 
it was not perfect, but at last it was standard and everybody can 
read it.

Now when I come to code.dlang.org I can't simply do copy-past of 
dependence. I need go to docs page, and read how to include it.

Also I do not see any projects that are migrate to SDL. Everybody 
continue to use JSON. So please, return JSON back as default, or 
very soon we will see that nobody do not submit packages to 
code.dlang.org and nobody do not use DUB for their own projects.

Please vote about SDL config format 
http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

If SDL will stay by default I will prefer to move to any other 
build system or will downgrade to old version of DUB.
Nov 25 2015
next sibling parent ponce <contact gamesfrommars.fr> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.


No hate for the new format there, have not switched because I 
extended dub.json for the purpose of a build system that is 
calling DUB itself. And there is no SDL parser in the standard 
library. No gain, no pain.
Nov 25 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


 From what I've read, the JSON format will always be supported, so 
there's no need to switch to SDLang if you don't want to. Just 
keep using what you're comfortable with.

Personally, I find the SDLang format much cleaner to use than 
JSON. I learned everything I needed to know about it in 15 
minutes. It's not rocket science. If you can understand the JSON 
format, you can understand SDLang. Any time I start a new project 
with DUB I use SDLang instead of JSON. I haven't switched the 
Derelict packages over to SDL because there's no real reason to 
do so, since JSON will always be supported. But if I add any new 
Derelict packages, they will use the new format instead.
Nov 25 2015
parent reply drug <drug2004 bk.ru> writes:
On 25.11.2015 13:28, Mike Parker wrote:>

  From what I've read, the JSON format will always be supported, so
 there's no need to switch to SDLang if you don't want to. Just keep
 using what you're comfortable with.

 Personally, I find the SDLang format much cleaner to use than JSON. I
 learned everything I needed to know about it in 15 minutes. It's not
 rocket science. If you can understand the JSON format, you can
 understand SDLang. Any time I start a new project with DUB I use SDLang
 instead of JSON. I haven't switched the Derelict packages over to SDL
 because there's no real reason to do so, since JSON will always be
 supported. But if I add any new Derelict packages, they will use the new
 format instead.


Totally agree with you.
Nov 25 2015
parent reply Suliman <evermind live.ru> writes:
I find the SDLang format much cleaner to use than JSON


But it's dead format! Nobody do not use it. JSON easy to read, 
there is a lot of it's checkers and formating tools.

Yes, it's not perfect, but now it's _standard_. Personally I'd 
prefer yaml, because it's much easier to read for humans.

But what we will do with SDL? Who know how to parse, validate it 
with D, and with another language? Even ini is better, because 
everybody know it.
Nov 25 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/11/15 12:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate it with D,
 and with another language? Even ini is better, because everybody know it.


I agree with you on all points, the best part is YAML is pretty standard 
now for Java. So lots and lots of familiarity there.

But at the end of the day. It was decided to go with SDL, even with its 
spec being incomplete and hardly anybody uses it.

So for the time being, I just use JSON as a form of protest.
After all, just because I don't like it, doesn't mean it should effect 
other people. Unless of course the decision is made to drop json. Then 
oh boy competition time!
Nov 25 2015
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 November 2015 at 11:57:30 UTC, Rikki Cattermole 
wrote:

 On 26/11/15 12:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, 
 there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd 
 prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate 
 it with D,
 and with another language? Even ini is better, because 
 everybody know it.


 I agree with you on all points, the best part is YAML is pretty 
 standard now for Java. So lots and lots of familiarity there.

 But at the end of the day. It was decided to go with SDL, even 
 with its spec being incomplete and hardly anybody uses it.


On what grounds?


 So for the time being, I just use JSON as a form of protest.
 After all, just because I don't like it, doesn't mean it should 
 effect other people. Unless of course the decision is made to 
 drop json. Then oh boy competition time!


Why was SDL agreed upon when it's a niche thing? Wouldn't it make 
more sense to have JSON that allows comments? Comments are 
something that's really missing in JSON. (Does SDL have them 
though?).

It'd be good to have a conversion tool JSON <=> SDL.
Nov 25 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/11/15 1:08 AM, Chris wrote:

 On Wednesday, 25 November 2015 at 11:57:30 UTC, Rikki Cattermole wrote:

 On 26/11/15 12:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate it with D,
 and with another language? Even ini is better, because everybody know
 it.


 I agree with you on all points, the best part is YAML is pretty
 standard now for Java. So lots and lots of familiarity there.

 But at the end of the day. It was decided to go with SDL, even with
 its spec being incomplete and hardly anybody uses it.


 On what grounds?


I've forgotten. But its in the N.G. and on Github.


 So for the time being, I just use JSON as a form of protest.
 After all, just because I don't like it, doesn't mean it should effect
 other people. Unless of course the decision is made to drop json. Then
 oh boy competition time!


 Why was SDL agreed upon when it's a niche thing? Wouldn't it make more
 sense to have JSON that allows comments? Comments are something that's
 really missing in JSON. (Does SDL have them though?).

 It'd be good to have a conversion tool JSON <=> SDL.


They looked at a lot of different options.
And yes SDL does have things like comments.

But it really doesn't matter now. This is the path that was chosen.
Either put up with it or code.
Nov 25 2015
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 25 November 2015 at 12:13:39 UTC, Rikki Cattermole 
wrote:

 On 26/11/15 1:08 AM, Chris wrote:

 On Wednesday, 25 November 2015 at 11:57:30 UTC, Rikki 
 Cattermole wrote:

 On 26/11/15 12:53 AM, Suliman wrote:

 [...]


 I agree with you on all points, the best part is YAML is 
 pretty
 standard now for Java. So lots and lots of familiarity there.

 But at the end of the day. It was decided to go with SDL, 
 even with
 its spec being incomplete and hardly anybody uses it.


 On what grounds?


 I've forgotten. But its in the N.G. and on Github.


 So for the time being, I just use JSON as a form of protest.
 After all, just because I don't like it, doesn't mean it 
 should effect
 other people. Unless of course the decision is made to drop 
 json. Then
 oh boy competition time!


 Why was SDL agreed upon when it's a niche thing? Wouldn't it 
 make more
 sense to have JSON that allows comments? Comments are 
 something that's
 really missing in JSON. (Does SDL have them though?).

 It'd be good to have a conversion tool JSON <=> SDL.


 They looked at a lot of different options.
 And yes SDL does have things like comments.

 But it really doesn't matter now. This is the path that was 
 chosen.
 Either put up with it or code.


I don't really mind. I already used SDL in a new test project and 
it has basically the same logic as JSON. The only thing I'd 
really like to have is an automatic converter JSON <=> SDL. In 
this way, I could port my old projects to SDL (and back again, if 
for some reason I have to).
Nov 25 2015
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 25 November 2015 at 12:08:46 UTC, Chris wrote:

 On what grounds?


Well, yaml is quiiite complex.
Nov 25 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 November 2015 at 12:39:47 UTC, Kagamin wrote:

 On Wednesday, 25 November 2015 at 12:08:46 UTC, Chris wrote:

 On what grounds?


 Well, yaml is quiiite complex.


What about JSON with comments? You could always strip them. But I 
admit that JSON becomes a bit messy after a while. It's not 
ideal. As I said, nothing against SDL as long as we can have a 
conversion tool.
Nov 25 2015
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 25 November 2015 at 12:43:01 UTC, Chris wrote:

 What about JSON with comments? You could always strip them. But 
 I admit that JSON becomes a bit messy after a while. It's not 
 ideal. As I said, nothing against SDL as long as we can have a 
 conversion tool.


There's no json5 D parser?
Nov 25 2015
parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 25 Nov 2015 12:48:51 +0000, Kagamin wrote:


 On Wednesday, 25 November 2015 at 12:43:01 UTC, Chris wrote:

 What about JSON with comments? You could always strip them. But I admit
 that JSON becomes a bit messy after a while. It's not ideal. As I said,
 nothing against SDL as long as we can have a conversion tool.


 
 There's no json5 D parser?


https://issues.dlang.org/show_bug.cgi?id=15303
Nov 27 2015
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 12:39:47 UTC, Kagamin wrote:

 On Wednesday, 25 November 2015 at 12:08:46 UTC, Chris wrote:

 On what grounds?


 Well, yaml is quiiite complex.


And hideous IMHO. The fact that it considers whitespace 
significant means that I will almost certainly never been in 
favor of using it for anything. I've been stuck using it before, 
and I'd much prefer to just use JSON.

- Jonathan M Davis
Nov 25 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-11-25 13:39, Kagamin wrote:


 Well, yaml is quiiite complex.


Most of that stuff are not needed for Dub config files. The features 
need for that are very simple and is mostly (except comments) covered by 
the JSON subset.

-- 
/Jacob Carlborg
Nov 25 2015
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 12:08:46 UTC, Chris wrote:

 Wouldn't it make more sense to have JSON that allows comments? 
 Comments are something that's really missing in JSON.


My one real complaint with JSON at this point (regardless of 
dub's situation) is the fact that it doesn't support comments. 
I'd probably have more complaints if I used it more, but in 
general, it works well - except for the lack of comments (which 
can be particularly annoying in something like a configuration 
file, though I don't know how much that influence the decision to 
switch the SDL for dub).

- Jonathan M Davis
Nov 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 7:15 AM, Jonathan M Davis wrote:

 My one real complaint with JSON at this point (regardless of dub's situation)
is
 the fact that it doesn't support comments.


Sure it does:

	"comment" : "This is a comment",

I do something analogous in Ddoc files:

	$(COMMENT This is a comment)
Nov 25 2015
parent reply David Nadlinger <code klickverbot.at> writes:
On Wednesday, 25 November 2015 at 19:04:19 UTC, Walter Bright 
wrote:

 Sure it does:

 	"comment" : "This is a comment",


That only works in contexts where a dictionary is used, and also 
neither stands out visually by itself nor can be rendered 
differently by syntax highlighting.

  — David
Nov 25 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 11:11 AM, David Nadlinger wrote:

 On Wednesday, 25 November 2015 at 19:04:19 UTC, Walter Bright wrote:

 Sure it does:

     "comment" : "This is a comment",


 That only works in contexts where a dictionary is used,


You can always add a dictionary anywhere in json.



 and also neither stands
 out visually by itself nor can be rendered differently by syntax highlighting.


Not a big problem. I still don't use a syntax highlighting code editor. I 
probably should, but I seem to somehow get by without it :-). Small files like 
DUB files hardly need syntax highlighting.
Nov 25 2015
prev sibling next sibling parent Mengu <mengukagan gmail.com> writes:
On Wednesday, 25 November 2015 at 11:54:00 UTC, Suliman wrote:

I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, 
 there is a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd 
 prefer yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate 
 it with D, and with another language? Even ini is better, 
 because everybody know it.


it can be dead but AFAIK it is complete. if we were to face any 
problems with it, we would fork it and fix it.
Nov 25 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/25/2015 06:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate it with D,
 and with another language? Even ini is better, because everybody know it.


This whole debate is completely moronic.

1. With DUB, which format is "default" means next to nothing.

2. I don't know where in the world you've gotten the idea you can no 
longer just copy-paste deps. That's patently BS.

3. SDLang is fucking trivial. Any programmer worth at least half their 
salt (ie anyone here, including you) could've learned it in same time 
you've already spent bellyaching about it.

4. Fuck "standard/popular/common". Seriously, fuck it. That sort of 
bullshit nonsense attitude is EXACTLY why half our industry is as 
completely fucked as it is with complete and total shit like PHP, JS, 
Node, JVM, Angular, JS Toolkit #five-billion-and-one, gaudy metro 
colors, meaningless hieroglyphs, walled gardens, web pages with 
near-zero content just empty space and screen-sized images with a quick 
slogan or two, text entry boxes that are *literally* slower than a 
goddamn Apple II, etc, etc etc... Seriously, enough of this goddamn 
"fashion before engineering" bullshit. That load of crap is why I'm 
right on the verge of completely jumping ship from what's left of this 
goddamn industry. If we start pulling that shit as a matter of course 
here too, I'm fucking gone, good riddance.
Dec 02 2015
parent reply Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 2 December 2015 at 16:15:04 UTC, Nick Sabalausky 
wrote:

 On 11/25/2015 06:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to read, 
 there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally I'd 
 prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate 
 it with D,
 and with another language? Even ini is better, because 
 everybody know it.


 This whole debate is completely moronic.

 1. With DUB, which format is "default" means next to nothing.

 2. I don't know where in the world you've gotten the idea you 
 can no longer just copy-paste deps. That's patently BS.

 3. SDLang is fucking trivial. Any programmer worth at least 
 half their salt (ie anyone here, including you) could've 
 learned it in same time you've already spent bellyaching about 
 it.

 4. Fuck "standard/popular/common". Seriously, fuck it. That 
 sort of bullshit nonsense attitude is EXACTLY why half our 
 industry is as completely fucked as it is with complete and 
 total shit like PHP, JS, Node, JVM, Angular, JS Toolkit 
 #five-billion-and-one, gaudy metro colors, meaningless 
 hieroglyphs, walled gardens, web pages with near-zero content 
 just empty space and screen-sized images with a quick slogan or 
 two, text entry boxes that are *literally* slower than a 
 goddamn Apple II, etc, etc etc... Seriously, enough of this 
 goddamn "fashion before engineering" bullshit. That load of 
 crap is why I'm right on the verge of completely jumping ship 
 from what's left of this goddamn industry. If we start pulling 
 that shit as a matter of course here too, I'm fucking gone, 
 good riddance.


The issue is not with humans reading and writing SDLang files - 
like you said, the syntax is not hard, and besides - the default 
should be enough for most of the basic learning projects one can 
make, so by the time you actually need to edit dub.sdl you should 
know enough D to not be learning two things at once.

No - the problem is with making tools(IDEs/editor 
plugins/scripts) parse and emit it. Yes, computers can read&write 
SDLang files - but you need to find a library(or write one 
yourself) that fits your language of choice.


I, for example, have a Ruby script that creates small DUB 
projects for me when I want to test stuff. Since usually I want 
to interact with small parts of the huge application, I need to 
do some specific configuration on the DUB project file so I have 
my Ruby script load it with it's JSON module, perform the 
necessary changes, and save over the original file.

Back then, when DUB moved to SDLang, obviously my script crashed 
because `dub init` now creates SDLang config files by default. 
This can be changed, but I thought I would go with the flow and 
modify my script to edit the SDLang file. I'm always eager to 
test new technologies(not adapt - test. I want to experience them 
before I decide whether to adapt them or not).

So, the first step was to google for a Ruby Gem that deals with 
SDLang. Should be easy, right? Wrong! Neither "Ruby SDL" nor 
"Ruby SDLang" yielded any relevant results(at least not in the 
first pages of google), and only recently, when this thread 
started and I decided to attempt again, I figured out you need to 
search for "Ruby Simple Declarative Language". Or to use 
rubygems.org's search engine. But that doesn't matter - back then 
I couldn't find it so instead just set my script to run `dub 
init` with `--format=json`, and now I no longer feel motivated to 
convert my script to use SDLang...


If you try to push a new technology, and when people complain 
about problems of that technology your reply is that they can 
simply use the better alternative instead - well, if you think 
this is good for the ecosystem let me tell you about a project 
called Tango...
Dec 02 2015
next sibling parent terchestor <terchestor gmail.com> writes:
On Wednesday, 2 December 2015 at 20:45:33 UTC, Idan Arye wrote:

 On Wednesday, 2 December 2015 at 16:15:04 UTC, Nick Sabalausky 
 wrote:

 On 11/25/2015 06:53 AM, Suliman wrote:

 I find the SDLang format much cleaner to use than JSON


 But it's dead format! Nobody do not use it. JSON easy to 
 read, there is
 a lot of it's checkers and formating tools.

 Yes, it's not perfect, but now it's _standard_. Personally 
 I'd prefer
 yaml, because it's much easier to read for humans.

 But what we will do with SDL? Who know how to parse, validate 
 it with D,
 and with another language? Even ini is better, because 
 everybody know it.


 This whole debate is completely moronic.

 1. With DUB, which format is "default" means next to nothing.

 2. I don't know where in the world you've gotten the idea you 
 can no longer just copy-paste deps. That's patently BS.

 3. SDLang is fucking trivial. Any programmer worth at least 
 half their salt (ie anyone here, including you) could've 
 learned it in same time you've already spent bellyaching about 
 it.

 4. Fuck "standard/popular/common". Seriously, fuck it. That 
 sort of bullshit nonsense attitude is EXACTLY why half our 
 industry is as completely fucked as it is with complete and 
 total shit like PHP, JS, Node, JVM, Angular, JS Toolkit 
 #five-billion-and-one, gaudy metro colors, meaningless 
 hieroglyphs, walled gardens, web pages with near-zero content 
 just empty space and screen-sized images with a quick slogan 
 or two, text entry boxes that are *literally* slower than a 
 goddamn Apple II, etc, etc etc... Seriously, enough of this 
 goddamn "fashion before engineering" bullshit. That load of 
 crap is why I'm right on the verge of completely jumping ship 
 from what's left of this goddamn industry. If we start pulling 
 that shit as a matter of course here too, I'm fucking gone, 
 good riddance.


 The issue is not with humans reading and writing SDLang files - 
 like you said, the syntax is not hard, and besides - the 
 default should be enough for most of the basic learning 
 projects one can make, so by the time you actually need to edit 
 dub.sdl you should know enough D to not be learning two things 
 at once.

 No - the problem is with making tools(IDEs/editor 
 plugins/scripts) parse and emit it. Yes, computers can 
 read&write SDLang files - but you need to find a library(or 
 write one yourself) that fits your language of choice.


 I, for example, have a Ruby script that creates small DUB 
 projects for me when I want to test stuff. Since usually I want 
 to interact with small parts of the huge application, I need to 
 do some specific configuration on the DUB project file so I 
 have my Ruby script load it with it's JSON module, perform the 
 necessary changes, and save over the original file.

 Back then, when DUB moved to SDLang, obviously my script 
 crashed because `dub init` now creates SDLang config files by 
 default. This can be changed, but I thought I would go with the 
 flow and modify my script to edit the SDLang file. I'm always 
 eager to test new technologies(not adapt - test. I want to 
 experience them before I decide whether to adapt them or not).

 So, the first step was to google for a Ruby Gem that deals with 
 SDLang. Should be easy, right? Wrong! Neither "Ruby SDL" nor 
 "Ruby SDLang" yielded any relevant results(at least not in the 
 first pages of google), and only recently, when this thread 
 started and I decided to attempt again, I figured out you need 
 to search for "Ruby Simple Declarative Language". Or to use 
 rubygems.org's search engine. But that doesn't matter - back 
 then I couldn't find it so instead just set my script to run 
 `dub init` with `--format=json`, and now I no longer feel 
 motivated to convert my script to use SDLang...


 If you try to push a new technology, and when people complain 
 about problems of that technology your reply is that they can 
 simply use the better alternative instead - well, if you think 
 this is good for the ecosystem let me tell you about a project 
 called Tango...


I am most worried that Sonke refuses to respond to very 
reasonable arguments like this. He seems to dismiss the entire 
discussion as a troll. Clearly that is in part true but we have a 
right to hear his response on the valid points. And no, sorry but 
just because he has already done the work we won't suck it. At 
least please revert the default back to json.

Sonke, please reply.
Dec 02 2015
prev sibling parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Wednesday, 2 December 2015 at 20:45:33 UTC, Idan Arye wrote:

 On Wednesday, 2 December 2015 at 16:15:04 UTC, Nick Sabalausky 
 wrote:

 [...]


 The issue is not with humans reading and writing SDLang files - 
 like you said, the syntax is not hard, and besides - the 
 default should be enough for most of the basic learning 
 projects one can make, so by the time you actually need to edit 
 dub.sdl you should know enough D to not be learning two things 
 at once.

 [...]


Where you looking for this:

https://github.com/ikayzo/SDL.rb
Dec 02 2015
parent reply Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 2 December 2015 at 22:57:31 UTC, CraigDillabaugh 
wrote:

 On Wednesday, 2 December 2015 at 20:45:33 UTC, Idan Arye wrote:

 On Wednesday, 2 December 2015 at 16:15:04 UTC, Nick Sabalausky 
 wrote:

 [...]


 The issue is not with humans reading and writing SDLang files 
 - like you said, the syntax is not hard, and besides - the 
 default should be enough for most of the basic learning 
 projects one can make, so by the time you actually need to 
 edit dub.sdl you should know enough D to not be learning two 
 things at once.

 [...]


 Where you looking for this:

 https://github.com/ikayzo/SDL.rb


Yes, and eventually I found it - when I searched with "Ruby 
Simple Declarative Language". My point was not that it doesn't 
exist, but that it much harder than it should have been to search 
for it.


BTW - I tried, just to see what I get, to search for a Python 
implementation:

"Python SDL", as expected, yields only results related to Simple 
DirectMedia Layer.

"Python Simple Declarative Language" the only related thing I 
find ikayzo's github page(which contains SDLang implementations 
for Java, .NET and Ruby - but not for Python).


And here comes the fun part:

"Python SDLang" does not find the SDLang implementation for 
Python - at least not on the first page.

But - the first 3 results are about an SDL implementation...

... it's SDLang-D!

Yes, you got that right - I searched for something related to 
Python(!!!) and got a result for D. So yea, maybe SDLang wasn't 
created specifically for DUB, but it might as well have been. 
Either that, or D suddenly became more popular than Python. I'll 
let you judge which of these two alternatives is more probable.
Dec 02 2015
parent Matt Soucy <msoucy csh.rit.edu> writes:
On 12/02/2015 07:29 PM, Idan Arye wrote:

 On Wednesday, 2 December 2015 at 22:57:31 UTC, CraigDillabaugh wrote:

 On Wednesday, 2 December 2015 at 20:45:33 UTC, Idan Arye wrote:

 On Wednesday, 2 December 2015 at 16:15:04 UTC, Nick Sabalausky wrote:=







 [...]


 The issue is not with humans reading and writing SDLang files - like =






you said, the syntax is not hard, and besides - the default should be eno=
ugh for most of the basic learning projects one can make, so by the time =
you actually need to edit dub.sdl you should know enough D to not be lear=
ning two things at once.

 [...]


 Where you looking for this:

 https://github.com/ikayzo/SDL.rb


=20
 Yes, and eventually I found it - when I searched with "Ruby Simple Decl=


arative Language". My point was not that it doesn't exist, but that it mu=
ch harder than it should have been to search for it.

=20
=20
 BTW - I tried, just to see what I get, to search for a Python implement=


ation:

=20
 "Python SDL", as expected, yields only results related to Simple Direct=


Media Layer.

=20
 "Python Simple Declarative Language" the only related thing I find ikay=


zo's github page(which contains SDLang implementations for Java, .NET and=
 Ruby - but not for Python).

=20
=20
 And here comes the fun part:
=20
 "Python SDLang" does not find the SDLang implementation for Python - at=


 least not on the first page.

=20
 But - the first 3 results are about an SDL implementation...
=20
 ... it's SDLang-D!
=20
 Yes, you got that right - I searched for something related to Python(!!=


!) and got a result for D. So yea, maybe SDLang wasn't created specifical=
ly for DUB, but it might as well have been. Either that, or D suddenly be=
came more popular than Python. I'll let you judge which of these two alte=
rnatives is more probable.

The fact that sdl shares its name with the Simple DirectMedia Language do=
esn't really help matters...

--=20
Matt Soucy
http://msoucy.me/
Dec 02 2015
prev sibling next sibling parent reply Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


The main problem with SDL is it's name. It's not an overly 
popular project - it doesn't even have an article in Wikipedia. 
That alone is not a problem - if we had something against 
non-mainstream project we wouldn't be using D - the problem with 
SDL's lack of popularity shares it's initials with "Simple 
DirectMedia Layer" - a super-popular project with binding for 
most languages. This makes it very hard to google for Dimple 
Declarative Languae - because most of the things you'll find are 
about Simple DirectMedia Layer.
Nov 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
 The main problem with SDL is it's name. It's not an overly popular project - it
 doesn't even have an article in Wikipedia. That alone is not a problem - if we
 had something against non-mainstream project we wouldn't be using D - the
 problem with SDL's lack of popularity shares it's initials with "Simple
 DirectMedia Layer" - a super-popular project with binding for most languages.
 This makes it very hard to google for Dimple Declarative Languae - because most
 of the things you'll find are about Simple DirectMedia Layer.



If you google "D programming language SDL" you'll find it.
Nov 25 2015
next sibling parent Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 25 November 2015 at 19:05:15 UTC, Walter Bright 
wrote:

 The main problem with SDL is it's name. It's not an overly 
 popular project - it
 doesn't even have an article in Wikipedia. That alone is not a 
 problem - if we
 had something against non-mainstream project we wouldn't be 
 using D - the
 problem with SDL's lack of popularity shares it's initials 
 with "Simple
 DirectMedia Layer" - a super-popular project with binding for 
 most languages.
 This makes it very hard to google for Dimple Declarative 
 Languae - because most
 of the things you'll find are about Simple DirectMedia Layer.



 If you google "D programming language SDL" you'll find it.


I just did - and all the first page results were about "Simple 
DirectMedia Layer". The second page had two results that have 
something to do with "Simple Declarative Language" - but they 
weren't landing pages or anything, just source codes that 
happened to deal with 
DUB(https://travis-ci.org/D-Programming-Language/dub-registry and 
https://coveralls.io/files/917374709).

Google search results are a bit customized, so other people might 
get better results, but I still believe SDL is extremely 
unsearchable.
Nov 25 2015
prev sibling parent reply Poyeyo <poyeyo arcadechaser.com> writes:
On Wednesday, 25 November 2015 at 19:05:15 UTC, Walter Bright 
wrote:

 The main problem with SDL is it's name. It's not an overly 
 popular project - it
 doesn't even have an article in Wikipedia. That alone is not a 
 problem - if we
 had something against non-mainstream project we wouldn't be 
 using D - the
 problem with SDL's lack of popularity shares it's initials 
 with "Simple
 DirectMedia Layer" - a super-popular project with binding for 
 most languages.
 This makes it very hard to google for Dimple Declarative 
 Languae - because most
 of the things you'll find are about Simple DirectMedia Layer.



 If you google "D programming language SDL" you'll find it.


That takes me here: https://github.com/DerelictOrg/DerelictSDL2
and some other related projects.
In fact, I can't easily find documentation about this SDL from 
google.

Dubconf seems to me a good replacement name for the format.

Regards,
Nov 28 2015
parent reply UserAbcabc123 <UserAbcabc123 ab.ba> writes:
On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


Hilarous, I guess you didn't read the topic at all...
Nov 28 2015
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Saturday, 28 November 2015 at 23:38:35 UTC, UserAbcabc123 
wrote:

 On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


 Hilarous, I guess you didn't read the topic at all...


To be fair, it's 20 pages long.
Nov 28 2015
prev sibling parent reply Poyeyo <poyeyo arcadechaser.com> writes:
On Saturday, 28 November 2015 at 23:38:35 UTC, UserAbcabc123 
wrote:

 On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


 Hilarous, I guess you didn't read the topic at all...


I've read it all. But I'm not joining the group in arguing 
against the format. And yes, someone said .dubconf should be an 
analog for .gitconfig. Hilarious.

Just to focus on my objection: the actual new name is not as 
important as picking something that's not SDL.

SDL and D already give plenty of useful search results for game 
programming.

Please change the name.

Regards,
Nov 28 2015
next sibling parent tired_eyes <pastuhov85 gmail.com> writes:
On Sunday, 29 November 2015 at 06:03:21 UTC, Poyeyo wrote:

 Please change the name.


"SDLang" gives good google results
Nov 29 2015
prev sibling parent reply UserAbcabc123 <UserAbcabc123 ab.ba> writes:
On Sunday, 29 November 2015 at 06:03:21 UTC, Poyeyo wrote:

 On Saturday, 28 November 2015 at 23:38:35 UTC, UserAbcabc123 
 wrote:

 On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


 Hilarous, I guess you didn't read the topic at all...


 I've read it all. But I'm not joining the group in arguing 
 against the format. And yes, someone said .dubconf should be an 
 analog for.


DUB people can't change the format name. They are not the SDL 
authors.
This is what I find hilarous because let's say 12 pages before 
there's been a misunderstanding caused by the fact that some 
people thought the format is propietary, thus DUB people have 
have been unfairly blamed...

The whole discussion is not about the file extention. The File 
extention is not a problem at all, the discussion was more about 
the format itself.
Nov 29 2015
next sibling parent reply UserAbcabc123 <UserAbcabc123 ab.ba> writes:
On Sunday, 29 November 2015 at 16:07:05 UTC, UserAbcabc123 wrote:

 On Sunday, 29 November 2015 at 06:03:21 UTC, Poyeyo wrote:

 On Saturday, 28 November 2015 at 23:38:35 UTC, UserAbcabc123 
 wrote:

 On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


 Hilarous, I guess you didn't read the topic at all...


 I've read it all. But I'm not joining the group in arguing 
 against the format. And yes, someone said .dubconf should be 
 an analog for.


 DUB people can't change the format name. They are not the SDL 
 authors.
 This is what I find hilarous because let's say 12 pages before 
 there's been a misunderstanding caused by the fact that some 
 people thought the format is propietary, thus DUB people have 
 have been unfairly blamed...

 The whole discussion is not about the file extention. The File 
 extention is not a problem at all, the discussion was more 
 about the format itself.


By the way, I'm curious to see if A.D.Ruppe will summarize the 
whole topic in the "signifiant NG discussion" section in the next 
"this week in D" issue...

I you do so, good luck !
Nov 29 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 29 November 2015 at 16:19:11 UTC, UserAbcabc123 wrote:

 By the way, I'm curious to see if A.D.Ruppe will summarize the 
 whole topic in the "signifiant NG discussion" section in the 
 next "this week in D" issue...


I'm catching up on the email for today then going to write it.

Actually, my summary of this will probably be just a couple 
sentences. I doubt much will actually change after this thread.
Nov 29 2015
prev sibling parent reply Poyeyo <poyeyo arcadechaser.com> writes:
On Sunday, 29 November 2015 at 16:07:05 UTC, UserAbcabc123 wrote:

 On Sunday, 29 November 2015 at 06:03:21 UTC, Poyeyo wrote:

 On Saturday, 28 November 2015 at 23:38:35 UTC, UserAbcabc123 
 wrote:

 On Saturday, 28 November 2015 at 22:00:32 UTC, Poyeyo wrote:

 Dubconf seems to me a good replacement name for the format.


 Hilarous, I guess you didn't read the topic at all...


 I've read it all. But I'm not joining the group in arguing 
 against the format. And yes, someone said .dubconf should be 
 an analog for.


 DUB people can't change the format name. They are not the SDL 
 authors.


Of course they can, it's called a fork. It's even logical to 
change the name if they choose to add features to it. Examples of 
forks: Iceweasel and Pale Moon are forks of Firefox.


 This is what I find hilarous because let's say 12 pages before 
 there's been a misunderstanding caused by the fact that some 
 people thought the format is propietary, thus DUB people have 
 have been unfairly blamed...

 The whole discussion is not about the file extention. The File 
 extention is not a problem at all, the discussion was more 
 about the format itself.


Well, I'm not the only one to mention that the only really bad 
thing about sdlang is the name.

Let's go back to a general point of view.

As far as dependency managers go, the language used varies 
greatly:

C/C++ make/cmake/nmake -> here be dragons
perl CPANfile -> something perly
java maven -> xml
ruby gemfile -> ruby
python pip -> python egg
php composer -> json
node.js npm -> json
go godep -> json
rust cargo -> rust manifest
d dub -> json and sdlang

Looking at the two main D competitors, go uses json and rust uses 
a proprietary format.

Both languages seem to be used without issues in each project, 
may be the only issue for dub is supporting two formats instead 
of one.

Regards,
Nov 29 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 29 November 2015 at 17:25:04 UTC, Poyeyo wrote:

 Looking at the two main D competitors, go uses json and rust 
 uses a proprietary format.


Tangential to your point, but both Go and Rust suffers from "our 
policy is to be weird" in many ways that are "off-putting", and D 
also suffers from a rather broad stroke of not-invented-here.

Wouldn't it be refreshingly progressive if D just picked _one_ 
canonical format for _all metadata_ that isn't D code as a policy?

Something flexible like XML? That way you could wrap up all meta 
for an entire project and extract information from it using 
widespread standards like XPath and XQuery.

One problem with JSON is that it depends on meta information 
being relayed in HTTP headers. It is not a file format. Given a 
bunch of JSON files, you can't really tell what they are...

JSON is suitable as an alternative formulation, but not for a 
canonical format. Both JSON and YAML can be translated into 
corresponding XML too. Just provide tooling for JSON->XML and 
YAML->XML.
Nov 29 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2015-11-29 at 17:25 +0000, Poyeyo via Digitalmars-d wrote:

=20


[=E2=80=A6]

 C/C++ make/cmake/nmake -> here be dragons


Or SCons if you want to be cool. I guess Bazel (and maybe Tup) might
become trendy.
=C2=A0

 perl CPANfile -> something perly
 java maven -> xml


Does anyone still use Maven =E2=80=93 surely the world has moved to Gradle =
with
it's Groovy scripts using the Gradle DSL.


 ruby gemfile -> ruby
 python pip -> python egg


Python has moved to wheels, eggs were always crap.


 php composer -> json
 node.js npm -> json
 go godep -> json


I am not sure this as as mainstream as this comment implies. Also a lot
of people are using gb.


 rust cargo -> rust manifest


Which is TOML.


 d dub -> json and sdlang


Personally I abhor JSON for this kind of specification, it a transfer
notation between computers, cf. XML. On the other hand I couldn't get
SDL specs working. I will undoubtedly try again as SDL is just so much
nicer than JSON for this. On the third hand lots of people seem
addicted to JSON. On the fourth hand I cannot get worked up about this,
it is just a build specification script which really ought to be
written in D. cf. SBT for Scala uses Scala. Leiningen for Clojure uses
Clojure. These languages have the right idea.

Oh, I just got worked up about this.

--=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
Nov 29 2015
next sibling parent Idan Arye <GenericNPC gmail.com> writes:
On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:

 Does anyone still use Maven – surely the world has moved to 
 Gradle with it's Groovy scripts using the Gradle DSL.


If I had a silver coin for every time the world should have moved 
to a better technology...
Nov 29 2015
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:

 On Sun, 2015-11-29 at 17:25 +0000, Poyeyo via Digitalmars-d 
 wrote:

 


 […]

 C/C++ make/cmake/nmake -> here be dragons


 Or SCons if you want to be cool. I guess Bazel (and maybe Tup) 
 might
 become trendy.


 perl CPANfile -> something perly
 java maven -> xml


 Does anyone still use Maven – surely the world has moved to 
 Gradle with it's Groovy scripts using the Gradle DSL.


Only those that are required to use it for Android and suffer the 
pain of slow builds yet to be fixed as announced on Google IO 
2015.

I have seen zero projects move to it, otherwise.

All our customers are on Ant and Maven.

Personally I don't see any value on Gradle, besides having more 
time to fetch coffee.

--
Paulo
Nov 29 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2015-11-29 at 22:38 +0000, Paulo Pinto via Digitalmars-d wrote:

=20


[=E2=80=A6]

 Only those that are required to use it for Android and suffer the=20
 pain of slow builds yet to be fixed as announced on Google IO=20
 2015.
=20
 I have seen zero projects move to it, otherwise.


On the other hand I have seen none stay with Ant or Maven given the
option of Gradle. Those that stayed were told they didn't have an
option =E2=80=93 for no good technical reason, just management "don't touch
anything" attitude.


 All our customers are on Ant and Maven.


Maven I can sort of live with but only on double pay. Ant is beyond the
pale in 2015. It was a late 1990s hack due to Make hatred.


 Personally I don't see any value on Gradle, besides having more=20
 time to fetch coffee.


I see huge value in Gradle as a replacement for Maven (and Ant of
course). I have never seen the massive slow downs you intimate, for
projects I have seen with both Maven and Gradle builds, the Gradle
builds were a little slower, but the scripts were far, far easier to
maintain since al the imperative things were in the build scripts not
in additional Java plugins.

But this might be just a bikeshed issue. I have no intention of giving
up on Gradle and SCons, I am intransigent. :-)

--=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
Nov 30 2015
parent CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Monday, 30 November 2015 at 18:56:58 UTC, Russel Winder wrote:

 On Sun, 2015-11-29 at 22:38 +0000, Paulo Pinto via 
 Digitalmars-d wrote:

 


 

 But this might be just a bikeshed issue. I have no intention of 
 giving up on Gradle and SCons, I am intransigent. :-)


If it is a bikeshed issue then it will feel right at home in this 
thread.
Nov 30 2015
prev sibling next sibling parent reply Ola Fosheim Gr <ola.fosheim.grostad+dlang gmail.com> writes:
On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:

 hand lots of people seem addicted to JSON. On the fourth hand I 
 cannot get worked up about this, it is just a build 
 specification script which really ought to be written in D. cf.


What is the advantage of having it in an imperative language, 
though? Isn't a concurrent deductive language better and faster?

Then again, what is the point of every language inventing their 
own eco system as an island...
Nov 29 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Sunday, 29 November 2015 at 22:52:20 UTC, Ola Fosheim Gr wrote:

 What is the advantage of having it in an imperative language, 
 though? Isn't a concurrent deductive language better and faster?


In doesn't need to work like D, it only needs to parse like D. 
After all, configuration is just data.


 Then again, what is the point of every language inventing their 
 own eco system as an island...


Dogfooding?
Nov 30 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 08:45:30 UTC, Kagamin wrote:

 Then again, what is the point of every language inventing 
 their own eco system as an island...


 Dogfooding?


Marketing making people reinventing the wheel over and over...
Nov 30 2015
parent Kagamin <spam here.lot> writes:
On Monday, 30 November 2015 at 10:36:23 UTC, Ola Fosheim Grøstad 
wrote:

 Marketing making people reinventing the wheel over and over...


Welcome to post-facebook social internet :( we don't have 
technical meritocracy anymore.
Nov 30 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2015-11-29 at 22:52 +0000, Ola Fosheim Gr via Digitalmars-d
wrote:

=20


[=E2=80=A6]

 What is the advantage of having it in an imperative language,=20
 though? Isn't a concurrent deductive language better and faster?


Project definitions should be declarative, definitely. Proejcts should
then have a default laying and naming scheme so that with convention
over configuration you need say nothing else. THis was the hope of
Maven and it chose XML. Then it became obvious that if you wanted even
a little non-standard behaviour you had to write you own Java coded
Maven plugin. So having a language which can offer a declarative DSL
and the ability to do a bit of imperative stuff if it is needed, you
get a good system. SCons and Gradle both do this: mostly declarative
with bits as needed.


 Then again, what is the point of every language inventing their=20
 own eco system as an island...


Because, progress.

OK so there is the pissing contest of "my language makes a better build
system than any other" so every language has to have its own build
system. (Even Go switched from make to go.) However in doing this there
is often forward progress in build. Maven beats Ant. SCons and CMake
beat Make. etc., etc.

In the end though Lisp is the one true language, so we should all just
write in Lisp.

--=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
Nov 30 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 18:50:57 UTC, Russel Winder wrote:

 you had to write you own Java coded Maven plugin. So having a 
 language which can offer a declarative DSL and the ability to 
 do a bit of imperative stuff if it is needed, you get a good 
 system. SCons and Gradle both do this: mostly declarative with 
 bits as needed.


I don't know them, I am sure you have a point :).  But 
intuitively I think that modern build systems _ought_ to use a 
constraints-based language and be geared towards distributed 
builds... take that as an heartfelt opinion, not a fact.



 However in doing this there is often forward progress in build.


GNU make is good enough for my own stuff, but probably not so 
good for cross platform builds.

As for package managers, I'd much rather have a really good 
generic repository (like Debian) with precompiled vetted and 
patched quality libraries than all these language specific ones 
where 99% is useless/unfinished/unmaintained.

Take a look at node.js: 210820 packages. How do you find new gems 
in that mess? It is also becoming increasingly difficult to find 
quality stuff on github by searching IMO. Too much dead 
unfinished stuff. Maybe that's why Open Source repository sites 
die. They drown in dead code.

Besides, dealing with 10 different packaging systems, potential 
security risks and potential configuration conflicts is not 
entertaining.


 In the end though Lisp is the one true language, so we should 
 all just write in Lisp.


Yes, keep it simple and do numbers in unary notation.
Nov 30 2015
parent reply Suliman <evermind live.ru> writes:
Should we try to implement yet another language for writing 
building config? Maybe we should use any of existence language 
that may be very good for it, like Red. It have very small foot 
prints so it can be easy to embeded to build system.
Nov 30 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 Should we try to implement yet another language for writing 
 building config?


No, I wasn't really talking about a build system for D, more like 
a hypothetic generic distributed build system for all languages. 
But I've read that Google uses a distributed build system for 
their big C++ applications. So people are working on such 
solutions already.


 Maybe we should use any of existence language that may be very 
 good for it, like Red. It have very small foot prints so it can 
 be easy to embeded to build system.


I've never heard of Red, do you have a link?
Nov 30 2015
next sibling parent reply lobo <swamplobo gmail.com> writes:
On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 Should we try to implement yet another language for writing 
 building config?


 No, I wasn't really talking about a build system for D, more 
 like a hypothetic generic distributed build system for all 
 languages. But I've read that Google uses a distributed build 
 system for their big C++ applications. So people are working on 
 such solutions already.


 Maybe we should use any of existence language that may be very 
 good for it, like Red. It have very small foot prints so it 
 can be easy to embeded to build system.


 I've never heard of Red, do you have a link?


Red started out as a Rebol 2 clone and last I checked (18 months 
ago) it was still is Rebol 2 compatible.

http://www.red-lang.org/

bye,
lobo
Nov 30 2015
next sibling parent lobo <swamplobo gmail.com> writes:
On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:

 On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 [...]


 No, I wasn't really talking about a build system for D, more 
 like a hypothetic generic distributed build system for all 
 languages. But I've read that Google uses a distributed build 
 system for their big C++ applications. So people are working 
 on such solutions already.


 [...]


 I've never heard of Red, do you have a link?


 Red started out as a Rebol 2 clone and last I checked (18 
 months ago) it was still is Rebol 2 compatible.

 http://www.red-lang.org/

 bye,
 lobo


I believe the main difference between Red and Rebol2 is that Red 
exposes more of the H/W driver and OS layers.
Nov 30 2015
prev sibling next sibling parent reply Idan Arye <GenericNPC gmail.com> writes:
On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:

 On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 Should we try to implement yet another language for writing 
 building config?


 No, I wasn't really talking about a build system for D, more 
 like a hypothetic generic distributed build system for all 
 languages. But I've read that Google uses a distributed build 
 system for their big C++ applications. So people are working 
 on such solutions already.


 Maybe we should use any of existence language that may be 
 very good for it, like Red. It have very small foot prints so 
 it can be easy to embeded to build system.


 I've never heard of Red, do you have a link?


 Red started out as a Rebol 2 clone and last I checked (18 
 months ago) it was still is Rebol 2 compatible.

 http://www.red-lang.org/

 bye,
 lobo


Red is not Rebol2 compatible - it's outright impossible to have a 
single script file that'll run without errors on both Rebol2 and 
Red. The reason is that Rebol2 requires the first thing in the 
file to be a `REBOL` preamble, while Red requires it to be a 
`Red` preamble(though it's generous enough to allow a shebang 
before it). Since you can only have one preamble, and it can't be 
both `REBOL` and `Red`, I refuse to call them compatible even if 
every Rebol2 command can be copied to a Red script and run in 
there!

At any rate, please don't use any Rebol dialect in DUB(or for 
anything else, in that matter. Just - don't use it). Many 
languages have awkward quirks, but Rebol seems to be a collection 
of awkward quirks with a programming language somtimes 
accidentally hiding in between, created by someone who thought 
Perl is too readable and shell scripts have too strict type 
systems.
Dec 01 2015
parent lobo <swamplobo gmail.com> writes:
On Tuesday, 1 December 2015 at 09:43:24 UTC, Idan Arye wrote:

 Red is not Rebol2 compatible - it's outright impossible to have 
 a single script file that'll run without errors on both Rebol2 
 and Red. The reason is that Rebol2 requires the first thing in 
 the file to be a `REBOL` preamble, while Red requires it to be 
 a `Red` preamble(though it's generous enough to allow a shebang 
 before it). Since you can only have one preamble, and it can't 
 be both `REBOL` and `Red`, I refuse to call them compatible 
 even if every Rebol2 command can be copied to a Red script and 
 run in there!


Meh, beyond s/Rebol/Red all my R2 code runs with Red.


 At any rate, please don't use any Rebol dialect in DUB(or for 
 anything else, in that matter. Just - don't use it). Many 
 languages have awkward quirks, but Rebol seems to be a 
 collection of awkward quirks with a programming language 
 somtimes accidentally hiding in between, created by someone who 
 thought Perl is too readable and shell scripts have too strict 
 type systems.


Actually I find Rebol has less quirks than most languages. It 
does have one alien looking syntax though.

bye,
lobo
Dec 01 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:

 Red started out as a Rebol 2 clone and last I checked (18 
 months ago) it was still is Rebol 2 compatible.

 http://www.red-lang.org/


Thanks!
Dec 01 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-11-30 at 21:05 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:

=20


[=E2=80=A6]

 No, I wasn't really talking about a build system for D, more like=20
 a hypothetic generic distributed build system for all languages.=20
 But I've read that Google uses a distributed build system for=20
 their big C++ applications. So people are working on such=20
 solutions already.


I think you are meaning Bazel here.=C2=A0http://bazel.io/

I haven't had chance to play with it as yet, and it changes massively
every day =E2=80=93 though I suspect it is the internal of the satisfaction
engine that change not the specification notation (which looks a bit
like a Python/SCons/Waf type thing). I will be playing with it over the
next few weeks, so more news later.

--=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
Dec 01 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 1 December 2015 at 12:07:51 UTC, Russel Winder wrote:

 I think you are meaning Bazel here. http://bazel.io/

 I haven't had chance to play with it as yet, and it changes 
 massively every day – though I suspect it is the internal of 
 the satisfaction engine that change not the specification 
 notation (which looks a bit like a Python/SCons/Waf type 
 thing). I will be playing with it over the next few weeks, so 
 more news later.



That's interesting, I didn't know they were going to make it 
publicly available. The FAQ says it supports Java, Objective-C 
and C++ out of the box. So I guess that means there is 
infrastructure for adding other languages too.
Dec 01 2015
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 01 Dec 2015 12:22:32 +0000, Ola Fosheim Grøstad wrote:


 On Tuesday, 1 December 2015 at 12:07:51 UTC, Russel Winder wrote:

 I think you are meaning Bazel here. http://bazel.io/

 I haven't had chance to play with it as yet, and it changes massively
 every day – though I suspect it is the internal of the satisfaction
 engine that change not the specification notation (which looks a bit
 like a Python/SCons/Waf type thing). I will be playing with it over the
 next few weeks, so more news later.


 
 
 That's interesting, I didn't know they were going to make it publicly
 available. The FAQ says it supports Java, Objective-C and C++ out of the
 box. So I guess that means there is infrastructure for adding other
 languages too.


So they open sourced Blaze. Interesting, but not very useful.

Bazel, like Blaze, wants to keep a very granular build unit with explicit 
dependencies. It aims to keep very little per-language logic in the build 
system. The tradeoff is that humans have to supply it all.

DUB aims to have very tight integration with D, and build granularity 
isn't a large goal. This means it's nearly useless for building any other 
language, and it would probably die if you tried to build a project with 
a million lines of code with it. But on the other hand, I can write a 
build file that just contains the project name and what dependencies it 
has and I'm off to the races.

Amazon internally has a build system called Brazil. (My information is 
probably four years out of date now.) It's basically a multilanguage 
Maven, hampered by an ugly web interface and a concept of "version sets" 
-- which is essentially the same as dub.selections.json, but you have to 
maintain it manually. That model, minus the web interface and manually 
curating version selections, would work much better with most small to 
medium projects in the wild. Add a source distribution option (to avoid 
having to build N versions of the same library; we're not all on JIT) and 
Bob's your uncle.
Dec 01 2015
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-12-01 at 17:24 +0000, Chris Wright via Digitalmars-d
wrote:

 [=E2=80=A6]
 Bob's your uncle.


Is Uncle Bob your uncle?


PS Sorry for that, I am in a weird state just now.

--=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
Dec 01 2015
prev sibling parent reply Matt Soucy <msoucy csh.rit.edu> writes:
On 12/01/2015 07:22 AM, Ola Fosheim Gr=C3=B8stad wrote:

 On Tuesday, 1 December 2015 at 12:07:51 UTC, Russel Winder wrote:

 I think you are meaning Bazel here. http://bazel.io/

 I haven't had chance to play with it as yet, and it changes massively =




every day =E2=80=93 though I suspect it is the internal of the satisfacti=
on engine that change not the specification notation (which looks a bit l=
ike a Python/SCons/Waf type thing). I will be playing with it over the ne=
xt few weeks, so more news later.

=20
=20
 That's interesting, I didn't know they were going to make it publicly a=


vailable. The FAQ says it supports Java, Objective-C and C++ out of the b=
ox. So I guess that means there is infrastructure for adding other langua=
ges too.

=20
=20
=20


Interestingly, bazel has D mentioned in its docs:

http://bazel.io/docs/be/d.html

--=20
Matt Soucy
http://msoucy.me/
Dec 02 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 3 December 2015 at 01:40:12 UTC, Matt Soucy wrote:

 Interestingly, bazel has D mentioned in its docs:

 http://bazel.io/docs/be/d.html


Hah, yes! And Dub too, but they link to the json page...
Dec 03 2015
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 Should we try to implement yet another language for writing 
 building config? Maybe we should use any of existence language 
 that may be very good for it, like Red. It have very small foot 
 prints so it can be easy to embeded to build system.


I really don't think so. There are plenty of perfectly good 
languages available, D being one of them. The other ones you can 
write reggae builds in are Python, Ruby, Javascript and Lua.

Atila
Nov 30 2015
prev sibling next sibling parent Daniel N <ufo orbiting.us> writes:
On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote:

 Should we try to implement yet another language for writing 
 building config? Maybe we should use any of existence language 
 that may be very good for it, like Red. It have very small foot 
 prints so it can be easy to embeded to build system.


-The only winning choice is not to choose.

I'm kinda spoiled by rdmd, I honestly don't see why I should go 
back to using config files again, pragma(lib) already exists and 
one could extend it with UDA:s for more advanced use-cases. Well, 
never mind. Most ppl seem happy with DUB:s approach though, so I 
guess it's just me.
Nov 30 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-11-30 at 20:42 +0000, Suliman via Digitalmars-d wrote:

 Should we try to implement yet another language for writing=20
 building config? Maybe we should use any of existence language=20
 that may be very good for it, like Red. It have very small foot=20
 prints so it can be easy to embeded to build system.


Writing a build system in a languages such as Python, Scala,
Java/Groovy or even D, is not writing a new language, it is writing an
internal DSL in that language. Make and CMake are new languages, they
are external DSLs with compilers, etc.

In all cases the DSL is a front to a constraint-based system with
resolution: Make, SCons, CMake, Gradle, SBT are all the same in this
respect. Maven is somewhat different but only somewhat.

What we currently have with Dub as I understand it is a constraint
satisfaction engine with two front ends. I am not sure why this causes
such warfare. Ant is a build engine with an XML and a Groovy front end,
those that like XML use that, those that do not can use Groovy. I am
unaware of any warfare in the Ant community about this choice.

--=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
Dec 01 2015
parent BBaz <2b.temp gmx.com> writes:
On Tuesday, 1 December 2015 at 12:03:35 UTC, Russel Winder wrote:

 I am not sure why this causes such warfare. Ant is a build 
 engine with an XML and a Groovy front end, those that like XML 
 use that, those that do not can use Groovy. I am unaware of any 
 warfare in the Ant community about this choice.


For me the only valid reason to drop SDL would be the IDE 
integration. This is not what had triggered the "war" but 
anyway...It seems that most of the D people don't use an IDE, so 
they don't get the problem. But they should (use an IDE and get 
why two formats is a problem).

Do you want to see the problem with people who don't use an IDE:

https://github.com/D-Programming-Language/phobos/pull/3821/files#diff-52580fb75b304ba7b04a6b178fe6cdf4L3085

with completion, the author would not import a module that does 
not exist: std -> dot -> list popup...

;)
Dec 01 2015
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Sunday, 29 November 2015 at 22:52:20 UTC, Ola Fosheim Gr wrote:

 On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder 
 wrote:

 hand lots of people seem addicted to JSON. On the fourth hand 
 I cannot get worked up about this, it is just a build 
 specification script which really ought to be written in D. cf.


 What is the advantage of having it in an imperative language, 
 though? Isn't a concurrent deductive language better and faster?


As much as possible, yes. But non-trivial builds require a DAG, 
ordering, and plain just telling the computer what to do.

I've written quite a bit of CMake script to handle complicated 
builds. When you need it, you want a full language. I've heard 
horror stories of people doing boolean logic and loops in XML for 
Ant. CMake script is bad enough, I can't imagine how much I'd 
bang my head against the wall trying to contort XML into a bad 
version of Lisp.

The truth is, for most projects a `dub build` will do, and that's 
fine. Declarative is the way to go then. But when you have 
binaries reading files to auto-generate code that then gets 
compiled in two different ways, one of which is copied... you get 
the idea.

Atila
Nov 30 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 19:36:18 UTC, Atila Neves wrote:

 As much as possible, yes. But non-trivial builds require a DAG, 
 ordering, and plain just telling the computer what to do.


Representing a DAG in a logic language is not a problem. The 
biggest problem is probably that most programmers (myself 
included) have an imperative mindset.


 for Ant. CMake script is bad enough, I can't imagine how much 
 I'd bang my head against the wall trying to contort XML into a 
 bad version of Lisp.


I don't know much about CMake, only given it a glance as 
make+Python is good enough for me. But I see your point. I don't 
know how expressive CMake is, but it does take quite a bit of 
adjustment to express oneself in a deductive (logic) language.


 The truth is, for most projects a `dub build` will do, and 
 that's fine. Declarative is the way to go then. But when you 
 have binaries reading files to auto-generate code that then 
 gets compiled in two different ways, one of which is copied... 
 you get the idea.


Hmm, yes, but if we (in fantasy land) start from scratch and have 
a generic distributed build system with a shared nosql database 
for the intermediate results and some kind of linda-like tuple 
space to back it up with meta data. Then a deductive language to 
update the tuple space. Then you have regular executable workers 
pull stuff out of the linda-space, and put the results back in. 
Unlike a file system, it would be transactional.
Nov 30 2015
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Sunday, 29 November 2015 at 18:54:04 UTC, Russel Winder wrote:

 On Sun, 2015-11-29 at 17:25 +0000, Poyeyo via Digitalmars-d 
 wrote:

 


 […]

 C/C++ make/cmake/nmake -> here be dragons


 Or SCons if you want to be cool. I guess Bazel (and maybe Tup) 
 might
 become trendy.


 perl CPANfile -> something perly
 java maven -> xml


 Does anyone still use Maven – surely the world has moved to 
 Gradle with it's Groovy scripts using the Gradle DSL.


 ruby gemfile -> ruby
 python pip -> python egg


 Python has moved to wheels, eggs were always crap.


 php composer -> json
 node.js npm -> json
 go godep -> json


 I am not sure this as as mainstream as this comment implies. 
 Also a lot of people are using gb.


 rust cargo -> rust manifest


 Which is TOML.


 d dub -> json and sdlang


 Personally I abhor JSON for this kind of specification, it a 
 transfer notation between computers, cf. XML. On the other hand 
 I couldn't get SDL specs working. I will undoubtedly try again 
 as SDL is just so much nicer than JSON for this. On the third 
 hand lots of people seem addicted to JSON. On the fourth hand I 
 cannot get worked up about this, it is just a build 
 specification script which really ought to be written in D. cf. 
 SBT for Scala uses Scala. Leiningen for Clojure uses Clojure. 
 These languages have the right idea.

 Oh, I just got worked up about this.


You can write build descriptions in D today:

http://code.dlang.org/packages/reggae

Package dependencies still comes from dub, so JSON or SDL are 
needed for that. Any project that needs an imperative language to 
describe its build can use reggae for the heavy lifting and dub 
to specify dependencies. You don't even have to use dub if you 
don't want to.

Atila
Nov 30 2015
prev sibling parent Luis <luis.panadero gmail.com> writes:
On Sunday, 29 November 2015 at 17:25:04 UTC, Poyeyo wrote:


 rust cargo -> rust manifest



rust cargo -> toml
Nov 30 2015
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
SDL has been chosen in a very simple manner - comparing samples 
of same project description in different formats and informally 
voting which one is cleaner and more straightforward to read. 
Probably people who voted at that point were not representative 
selection but it hardly matters as conservative crowd can awlays 
stick with old json. As project description files are only parsed 
internally by dub, it is irrelevant how widespread and 
well-supported format is as long as it is easy to read and does 
the job.
Nov 25 2015
prev sibling next sibling parent Basile <bb.temp gmx.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


Voted no. About SDL, i think that the comment summarizes 
everthing: not popular, bad name. One last detail:

http://sdl.ikayzo.org/

It looks like it's even not worth fixing it for the author(s). 
(But of course I apologize in case of the problem would be 
related to the guy(s) being sick or worth).

Also neither VisualD nor MonoD support SDL. My IDE will never, 
but that's less a problem since it's not published anymore.

And by the way what the problem the JSON format had that gets 
solved by SDL ?
Nov 25 2015
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


I don't really like SDL from the little I've messed around with 
it (it's too much like the INI format for my taste), but we're 
talking about simple build configuration files here. It's not 
like this is an actual build script like you get with cmake or 
make. It's pretty much just a list of key-value pairs used to 
tell the build tool what to do. The files are very short, and you 
don't have to deal with them much. So, ultimately, while I don't 
really like SDL, I'm not sure that it's worth caring much about 
either.

That being said, the JSON format isn't going anywhere, so you can 
just use that if you prefer. In most cases, you shouldn't need to 
read any dub config files, unless you're working on the project 
that the config file is for, and in many (most?) of those cases, 
it'll probably be your own project. So, you can just use the 
format that prefer and ignore the other. Worst case, you can't 
use the default-generated dub config file when you start your 
project and have to copy a JSON one from elsewhere or write it 
from scratch, but if doesn't already, I'm sure that dub init 
could be changed to take a flag indicating the config format to 
use if enough folks prefer JSON.

- Jonathan M Davis
Nov 25 2015
next sibling parent David DeWitt <dkdewitt gmail.com> writes:
On Wednesday, 25 November 2015 at 15:25:32 UTC, Jonathan M Davis 
wrote:


 That being said, the JSON format isn't going anywhere, so you 
 can just use that if you prefer. In most cases, you shouldn't 
 need to read any dub config files, unless you're working on the 
 project that the config file is for, and in many (most?) of 
 those cases, it'll probably be your own project. So, you can 
 just use the format that prefer and ignore the other. Worst 
 case, you can't use the default-generated dub config file when 
 you start your project and have to copy a JSON one from 
 elsewhere or write it from scratch, but if doesn't already, I'm 
 sure that dub init could be changed to take a flag indicating 
 the config format to use if enough folks prefer JSON.

 - Jonathan M Davis


Is it possible to default dub to json w/o using a flag in init?  
I'd rather dub init default to json for myself and anyone who 
prefers otherwise can stay with SDL.
Nov 25 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with them much.


That makes for an even less of a case for inventing a new file format. I
suppose 
it's water under the bridge, though.

I've written a lot of parsers for various niche file formats. I have come to 
realize that this is an utter waste of time, when there's an off-the-shelf 
format that can be pressed into service.

With a standard json parser in Phobos, zip zap boom you're done. You don't have 
to design it, argue about it, build it, document it, debug it, test it,
optimize 
it, explain it, deal with bug requests, deal with enhancement requests, deal 
with legacy compatibility, build a converter, etc. It's a huge win.

Note 1: json does support comments:

     "comment" : "this is a comment",

Note 2: I intend to migrate the dmd.conf file format to json.
Nov 25 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright 
wrote:

 Note 1: json does support comments:

     "comment" : "this is a comment",


That doesn't work in the majority of contexts (it is illegal in 
an array, for example) nor is it supported by standard tools.

Imagine if D didn't have comments and someone said "you could 
always write string comment = `foo`;". We'd laugh at the idea.
Nov 25 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 02:10 PM, Adam D. Ruppe wrote:

 On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright wrote:

 Note 1: json does support comments:

     "comment" : "this is a comment",


 That doesn't work in the majority of contexts (it is illegal in an
 array, for example) nor is it supported by standard tools.

 Imagine if D didn't have comments and someone said "you could always
 write string comment = `foo`;". We'd laugh at the idea.


As you should. But the comparison is an exaggeration. -- Andrei
Nov 25 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 11:10 AM, Adam D. Ruppe wrote:

 On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright wrote:

 Note 1: json does support comments:

     "comment" : "this is a comment",


 That doesn't work in the majority of contexts (it is illegal in an array, for
 example) nor is it supported by standard tools.


The array thing is not a big problem. If it's a small array, just precede it 
with the comment. If it is a large array, the individual entries are hardly 
going to be commented.

It's not a problem with the standard tools, as the standard tools don't do 
semantic processing. The semantic part, which would be custom to DUB (or the 
app) can just ignore it.

JSON is not a perfect match for every application. But it is close enough, and 
certainly close enough for small files like DUB files.
Nov 25 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 02:02 PM, Walter Bright wrote:

 On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with them much.


 That makes for an even less of a case for inventing a new file format. I
 suppose it's water under the bridge, though.


It's not. To DUB maintainers: this is a strategic error. Please throw 
SDL away and use a standardized file format. -- Andrei
Nov 25 2015
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei 
Alexandrescu wrote:

 On 11/25/2015 02:02 PM, Walter Bright wrote:

 On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with 
 them much.


 That makes for an even less of a case for inventing a new file 
 format. I
 suppose it's water under the bridge, though.


 It's not. To DUB maintainers: this is a strategic error. Please 
 throw SDL away and use a standardized file format. -- Andrei


You'll have to explain why you think it's a strategic error 
instead of decree it that it is.
Nov 25 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 02:19 PM, Brad Anderson wrote:

 On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei Alexandrescu wrote:

 On 11/25/2015 02:02 PM, Walter Bright wrote:

 On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with them much.


 That makes for an even less of a case for inventing a new file format. I
 suppose it's water under the bridge, though.


 It's not. To DUB maintainers: this is a strategic error. Please throw
 SDL away and use a standardized file format. -- Andrei


 You'll have to explain why you think it's a strategic error instead of
 decree it that it is.


As Walter said a few times by now, inventing new languages is an 
endeavor of high fixed cost for everyone involved (including users) and 
shouldn't be done casually.

Please don't reply to this. Just throw SDL away and use JSON. Please 
don't waste time discussing it.


Thanks,

Andrei
Nov 25 2015
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 25 November 2015 at 19:25:18 UTC, Andrei 
Alexandrescu wrote:

 As Walter said a few times by now, inventing new languages is 
 an endeavor of high fixed cost for everyone involved (including 
 users) and shouldn't be done casually.

 Please don't reply to this. Just throw SDL away and use JSON. 
 Please don't waste time discussing it.


While I agree with you, we shouldn't become the Go community 
either. Saying "let's not discuss this" seems very against the 
values of the D community.
Nov 25 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 03:06 PM, Jack Stouffer wrote:

 On Wednesday, 25 November 2015 at 19:25:18 UTC, Andrei Alexandrescu wrote:

 As Walter said a few times by now, inventing new languages is an
 endeavor of high fixed cost for everyone involved (including users)
 and shouldn't be done casually.

 Please don't reply to this. Just throw SDL away and use JSON. Please
 don't waste time discussing it.


 While I agree with you, we shouldn't become the Go community either.
 Saying "let's not discuss this" seems very against the values of the D
 community.


That's right, but we're kind of in the other extreme of the spectrum so 
a bit of pressure is in order.

FWIW I'm more curt and a bit less active in forums because I'm working 
on the new containers library. Design by Introspection is beyond 
exhilarating. If things are turning the way I hope, it will be the best 
container library ever.

I need to trust our core contributors here to make the right high-level 
decisions and execute them accurately when I'm not looking. Hence my 
brief comment that inventing a new file format should not have happened 
and must be now undone. If Walter or I were paying attention, that 
wouldn't have been initiated in the first place. But we can't pay 
attention to everything at all time. Please exercise good judgment and 
focused execution at all times. If it offers no leverage, entails boring 
work, requires a manual, or doesn't look good on the page - it's 
probably wrong.

Feel free to email Walter and me if you need executive decisions (I have 
a few in my queue, thanks to those who wrote). I answer all, just 
slowly. If too slow, email me again.

Happy Thanksgiving to whom it applies!


Andrei
Nov 25 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei 
Alexandrescu wrote:

 I need to trust our core contributors here to make the right 
 high-level decisions and execute them accurately when I'm not 
 looking. Hence my brief comment that inventing a new file 
 format should not have happened and must be now undone. If 
 Walter or I were paying attention, that wouldn't have been 
 initiated in the first place.


To be fair, they _didn't_ invent a new format. They just picked 
one that's far less well-known than what they were using before. 
Now, arguably, it's still a bad idea, because SDL is nowhere near 
as well-known as JSON, but they didn't invent it.

Though the fact that the site that seems to be the main site for 
SDL is down right now, isn't exactly encouraging:

http://sdl.ikayzo.org

So, while SDL wasn't invented by the dub team, its reach beyond 
them does not appear to be large.

- Jonathan M Davis
Nov 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 12:39 PM, Jonathan M Davis wrote:

 To be fair, they _didn't_ invent a new format. They just picked one that's far
 less well-known than what they were using before.


The energy poured into SDL would be more profitably directed towards improving 
Phobos' json support.
Nov 25 2015
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Thursday, 26 November 2015 at 01:14:11 UTC, Walter Bright 
wrote:

 On 11/25/2015 12:39 PM, Jonathan M Davis wrote:

 To be fair, they _didn't_ invent a new format. They just 
 picked one that's far
 less well-known than what they were using before.


 The energy poured into SDL would be more profitably directed 
 towards improving Phobos' json support.


Maybe you somehow missed it but Sonke has already spent a lot of 
energy on a new JSON module for Phobos:

http://forum.dlang.org/thread/lt5s76$is$1 digitalmars.com
Nov 25 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 5:24 PM, Brad Anderson wrote:

 On Thursday, 26 November 2015 at 01:14:11 UTC, Walter Bright wrote:

 On 11/25/2015 12:39 PM, Jonathan M Davis wrote:

 To be fair, they _didn't_ invent a new format. They just picked one that's far
 less well-known than what they were using before.


 The energy poured into SDL would be more profitably directed towards improving
 Phobos' json support.


 Maybe you somehow missed it but Sonke has already spent a lot of energy on a
new
 JSON module for Phobos:

 http://forum.dlang.org/thread/lt5s76$is$1 digitalmars.com


I know he has. There's nothing that cannot be improved :-)
Nov 25 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 01:14:11 UTC, Walter Bright 
wrote:

 On 11/25/2015 12:39 PM, Jonathan M Davis wrote:

 To be fair, they _didn't_ invent a new format. They just 
 picked one that's far
 less well-known than what they were using before.


 The energy poured into SDL would be more profitably directed 
 towards improving Phobos' json support.


The energy has already been spent. It's already supported. 
Projects are already using it. This isn't something new.

Regarding other comments in this thread, *JSON support is not 
going away.* If you prefer to use JSON, use it. There's no 
problem here.

As for searchability, you'll find discussions in the vibe.d 
forums where people refer to it as SDLang now rather than SDL to 
avoid confusion with the game library. Type that into Google and 
you're golden. It's no different than encouraging people to 
search for DLang instead of D, so it's not a big deal.

There are plenty of us who prefer to use SDLang over JSON for our 
config files. We do not want to see support for it taken away 
when there's no need for it. It's a much cleaner format, IMO, 
popular or not. Anyone who finds SDLang somehow abhorrent can 
just use JSON and move on.
Nov 25 2015
next sibling parent reply David DeWitt <dkdewitt gmail.com> writes:
On Thursday, 26 November 2015 at 04:29:20 UTC, Mike Parker wrote:


 The energy poured into SDL would be more profitably directed 
 towards improving Phobos' json support.


 The energy has already been spent. It's already supported. 
 Projects are already using it. This isn't something new.

 Regarding other comments in this thread, *JSON support is not 
 going away.* If you prefer to use JSON, use it. There's no 
 problem here.

 As for searchability, you'll find discussions in the vibe.d 
 forums where people refer to it as SDLang now rather than SDL 
 to avoid confusion with the game library. Type that into Google 
 and you're golden. It's no different than encouraging people to 
 search for DLang instead of D, so it's not a big deal.

 There are plenty of us who prefer to use SDLang over JSON for 
 our config files. We do not want to see support for it taken 
 away when there's no need for it. It's a much cleaner format, 
 IMO, popular or not. Anyone who finds SDLang somehow abhorrent 
 can just use JSON and move on.


Is there any document explaining how to default to JSON so it 
isn't necessary to specify each time? Also SDL isn't the default 
so if they both stay shouldn't the discussion be which is the 
default or if the user chooses their preference at sometime after 
install (maybe first project)?
Nov 25 2015
next sibling parent David DeWitt <dkdewitt gmail.com> writes:
On Thursday, 26 November 2015 at 04:42:14 UTC, David DeWitt wrote:


 Is there any document explaining how to default to JSON so it 
 isn't necessary to specify each time? Also SDL isn't the 
 default so if they both stay shouldn't the discussion be which 
 is the default or if the user chooses their preference at 
 sometime after install (maybe first project)?


Correction:
Should be "SDL is the default so...."
Nov 25 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 04:42:14 UTC, David DeWitt wrote:


 Is there any document explaining how to default to JSON so it 
 isn't necessary to specify each time? Also SDL isn't the 
 default so if they both stay shouldn't the discussion be which 
 is the default or if the user chooses their preference at 
 sometime after install (maybe first project)?


If it's really so painful to type 'dub init -fjson', then sure, 
let's revert to JSON as the default and the rest of us can type 
-fsdl. I never use 'dub init' anyway, so I have no personal stake 
in which is the default.
Nov 25 2015
parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 26 Nov 2015 05:45:56 +0000
Mike Parker via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 04:42:14 UTC, David DeWitt wrote:
 

 Is there any document explaining how to default to JSON so it 
 isn't necessary to specify each time? Also SDL isn't the 
 default so if they both stay shouldn't the discussion be which 
 is the default or if the user chooses their preference at 
 sometime after install (maybe first project)?  


 
 If it's really so painful to type 'dub init -fjson', then sure, 
 let's revert to JSON as the default and the rest of us can type 
 -fsdl. I never use 'dub init' anyway, so I have no personal stake 
 in which is the default.


Thats not a problem. What I dont like is to have two formats for one
thing. I don't care which one will be used (OK I maybe prefere JSON
because of tooling and SDL because of syntax :)), but there should be
only one format. Having more formats complicates everything.

1) You have to describe both variants

2) People using dub probably need to know both formats

3) When writing some tool or IDE you need to support both variants (no
dub describe does not solve this)

Btw. when your book will be published? :)
Nov 26 2015
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 12:11:25 UTC, Daniel Kozak wrote:


 Btw. when your book will be published? :)


Soon. The schedule slipped a bit on the publisher's end, but I 
don't know how it will affect the release date. I submitted my 
copy edits of the prefinals last week, so now I'm just waiting 
for a status update.
Nov 26 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 11:29 PM, Mike Parker wrote:

 On Thursday, 26 November 2015 at 01:14:11 UTC, Walter Bright wrote:

 On 11/25/2015 12:39 PM, Jonathan M Davis wrote:

 To be fair, they _didn't_ invent a new format. They just picked one
 that's far
 less well-known than what they were using before.


 The energy poured into SDL would be more profitably directed towards
 improving Phobos' json support.


 The energy has already been spent. It's already supported. Projects are
 already using it. This isn't something new.

 Regarding other comments in this thread, *JSON support is not going
 away.* If you prefer to use JSON, use it. There's no problem here.

 As for searchability, you'll find discussions in the vibe.d forums where
 people refer to it as SDLang now rather than SDL to avoid confusion with
 the game library. Type that into Google and you're golden. It's no
 different than encouraging people to search for DLang instead of D, so
 it's not a big deal.

 There are plenty of us who prefer to use SDLang over JSON for our config
 files. We do not want to see support for it taken away when there's no
 need for it. It's a much cleaner format, IMO, popular or not. Anyone who
 finds SDLang somehow abhorrent can just use JSON and move on.


This would be a lot more sensible if dub were not the official package 
and build manager. The way I look at it, it's a manifestation of a 
systemic problem: I can't work on dub and I can't monitor decisions 
regarding it. Yet that doesn't make it less official. So I need to trust 
other people to mind it in a way that is aligned in broad strokes with 
my view. If I say "well but that's very unlike my view" and I get back 
"some of us prefer it a different way and that's the way it is" then 
that trust is affected. -- Andrei
Nov 25 2015
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 05:25:46 UTC, Andrei 
Alexandrescu wrote:


 There are plenty of us who prefer to use SDLang over JSON for 
 our config
 files. We do not want to see support for it taken away when 
 there's no
 need for it. It's a much cleaner format, IMO, popular or not. 
 Anyone who
 finds SDLang somehow abhorrent can just use JSON and move on.


 This would be a lot more sensible if dub were not the official 
 package and build manager. The way I look at it, it's a 
 manifestation of a systemic problem: I can't work on dub and I 
 can't monitor decisions regarding it. Yet that doesn't make it 
 less official. So I need to trust other people to mind it in a 
 way that is aligned in broad strokes with my view. If I say 
 "well but that's very unlike my view" and I get back "some of 
 us prefer it a different way and that's the way it is" then 
 that trust is affected. -- Andrei


If there's an issue with having SDLang as the default for 'dub 
init', then I don't see a problem with reverting to JSON as the 
default. And I say that despite having revised the book I just 
completed to reflect the latest DUB release, which does use 
SDLang by default for 'dub init'. But I cannot see any 
justification for removing support for it. Tools that need 
information about a project's dub configuration should be using 
the output of 'dub describe' anyway, which is and will always be 
JSON. The format used by the project maintainer in the source 
tree is irrelevant.

I also don't see how there is any trust being broken here. The 
decision to add support for SDL was made long before DUB became 
"official".
Nov 25 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/26/2015 12:40 AM, Mike Parker wrote:

 If there's an issue with having SDLang as the default for 'dub init',
 then I don't see a problem with reverting to JSON as the default.


That would be great, thanks! -- Andrei P.S. "confidence" is more 
descriptive than "trust".
Nov 25 2015
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 05:56:41 UTC, Andrei 
Alexandrescu wrote:

 On 11/26/2015 12:40 AM, Mike Parker wrote:

 If there's an issue with having SDLang as the default for 'dub 
 init',
 then I don't see a problem with reverting to JSON as the 
 default.


 That would be great, thanks! -- Andrei P.S. "confidence" is 
 more descriptive than "trust".


I would say, "You're welcome", but that's Sönke's decision :)
Nov 25 2015
prev sibling next sibling parent Jakob Ovrum <jakobovrum gmail.com> writes:
On Thursday, 26 November 2015 at 05:25:46 UTC, Andrei 
Alexandrescu wrote:

 This would be a lot more sensible if dub were not the official 
 package and build manager. The way I look at it, it's a 
 manifestation of a systemic problem: I can't work on dub and I 
 can't monitor decisions regarding it. Yet that doesn't make it 
 less official. So I need to trust other people to mind it in a 
 way that is aligned in broad strokes with my view. If I say 
 "well but that's very unlike my view" and I get back "some of 
 us prefer it a different way and that's the way it is" then 
 that trust is affected. -- Andrei


Then I think you should trust Sönke with the decision.

It's trivial to choose JSON when creating a new dub project and 
there's a link to the JSON version of dub's documentation in bold 
at the top of the SDLang version. SDLang is not a creation of the 
D community; is a *much better format* for dub package 
description files; and is plenty intuitive so that it's readily 
readable to people who don't know the language.

When I first saw this thread I was hoping it would be ignored for 
the massive bikeshed timesink that it is (with added spice of 
vitriol by the OP), so I'm really surprised core contributors 
would see fit to reply. `dub init` is something you almost never 
have to type and it takes all of three seconds to redo if you 
didn't get the result you wanted.

So much fuss over absolutely nothing.
Nov 25 2015
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 06:25 schrieb Andrei Alexandrescu:

 This would be a lot more sensible if dub were not the official package
 and build manager. The way I look at it, it's a manifestation of a
 systemic problem: I can't work on dub and I can't monitor decisions
 regarding it. Yet that doesn't make it less official. So I need to trust
 other people to mind it in a way that is aligned in broad strokes with
 my view. If I say "well but that's very unlike my view" and I get back
 "some of us prefer it a different way and that's the way it is" then
 that trust is affected. -- Andrei


Let me remind you that confidence and especially trust is usually a 
mutual thing. I don't want to join this discussion of personal matters 
on a public forum, but I feel that I have to say that there have been 
numerous occasions where it went the opposite direction.

Furthermore, just to give you a brief overview of history:

Mar. 09, 2013: First call for comments for a new package format
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

May 24, 2013: Concrete DUB enhancement proposal (DEP)
https://github.com/D-Programming-Language/dub/wiki/DEP1

Jun. 12, 2013: Request for creating code.dlang.org

Sep. 26, 2013: Sub discussion about the choice of a JSON alternative in 
the "dub: should we make it the de jure package manager for D?" thread, 
started by you
http://forum.dlang.org/post/tuvtennjkvfnnyxmohzx forum.dlang.org

Jun. 17, 2014: Opened a ticket for adding SDLang support (1.0.0 milestone)

Aug. 08, 2014: Initial implementation as a PR
https://github.com/D-Programming-Language/dub/pull/392

Sep. 22, 2014: Announcement of 0.9.22 and official status of DUB
http://forum.dlang.org/post/lvoqdv$2m78$1 digitalmars.com

Jun. 17, 2015: Announcement of the first beta version with SDLang support
http://forum.dlang.org/post/mlr7g5$ss1$1 digitalmars.com

Jul. 02, 2015: Announcement of the second beta
http://forum.dlang.org/post/mn47ih$2cp1$1 digitalmars.com

Jul. 13, 2015: Announcement of the first release candidate
http://forum.dlang.org/post/mo1gga$1dn5$1 digitalmars.com

Sep. 14, 2015: Announcement of the final release candidate
http://forum.dlang.org/post/mt6c09$2n33$1 digitalmars.com

Sep. 20, 2015: Announcement of the final release
http://forum.dlang.org/post/mtn1rd$2fa5$1 digitalmars.com

Nov. 25, 2015: This thread


As you can see, not only does all major work/discussions/decisions 
pre-date the decisions and announcements for making DUB official, but 
there have been plenty of occasions afterwards where you could have 
noticed and commented the developments. I can understand that you don't 
have time to join each discussion, but shouldn't you at least read the 
announcements on D.announce? Should I contact you privately about each 
decision? Even for those in the past? Or do you expect me to just know 
what your opinion is?

The kind of surprised reaction to a stupid bikeshed thread (sorry, but 
it really is), but no reaction at all to all earlier, much more 
substantial, threads, just leaves me wondering.
Nov 26 2015
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Thursday, 26 November 2015 at 08:47:41 UTC, Sönke Ludwig wrote:

 ...


Just wanted to say thanks for SDLang support in dub Sönke, I 
personally prefer it over json.

Bye.
Nov 26 2015
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 26 November 2015 at 08:47:41 UTC, Sönke Ludwig wrote:

 Mar. 09, 2013: First call for comments for a new package format
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

 May 24, 2013: Concrete DUB enhancement proposal (DEP)
 https://github.com/D-Programming-Language/dub/wiki/DEP1

 Jun. 12, 2013: Request for creating code.dlang.org

 Sep. 26, 2013: Sub discussion about the choice of a JSON 
 alternative in the "dub: should we make it the de jure package 
 manager for D?" thread, started by you
 http://forum.dlang.org/post/tuvtennjkvfnnyxmohzx forum.dlang.org

 Jun. 17, 2014: Opened a ticket for adding SDLang support (1.0.0 
 milestone)

 Aug. 08, 2014: Initial implementation as a PR
 https://github.com/D-Programming-Language/dub/pull/392

 Sep. 22, 2014: Announcement of 0.9.22 and official status of DUB
 http://forum.dlang.org/post/lvoqdv$2m78$1 digitalmars.com

 Jun. 17, 2015: Announcement of the first beta version with 
 SDLang support
 http://forum.dlang.org/post/mlr7g5$ss1$1 digitalmars.com

 Jul. 02, 2015: Announcement of the second beta
 http://forum.dlang.org/post/mn47ih$2cp1$1 digitalmars.com

 Jul. 13, 2015: Announcement of the first release candidate
 http://forum.dlang.org/post/mo1gga$1dn5$1 digitalmars.com

 Sep. 14, 2015: Announcement of the final release candidate
 http://forum.dlang.org/post/mt6c09$2n33$1 digitalmars.com

 Sep. 20, 2015: Announcement of the final release
 http://forum.dlang.org/post/mtn1rd$2fa5$1 digitalmars.com

 Nov. 25, 2015: This thread


This really puts things in perspective.

What I got from this thread is that the only things worth 
worrying about are:

1. code.dlang.org presents dub configuration snippets in a format 
that doesn't match dub's default configuration format

2. dub could use a way to specify the default configuration 
format.

IMHO what would also be great is make the default dub.sdl larger, 
with comments explaining options, and commented-out examples of 
other common options. This should make trips to dub's package 
format's and SDL's reference necessary much less often.
Nov 27 2015
prev sibling next sibling parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei 
Alexandrescu wrote:

 If it offers no leverage, entails boring work, requires a 
 manual, or doesn't look good on the page - it's probably wrong.


Interestingly, this applies to the JSON-based DUB configuration 
format much more so than to the SDL-based one.

  — David
Nov 25 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei 
Alexandrescu wrote:

 I need to trust our core contributors here to make the right 
 high-level decisions and execute them accurately when I'm not 
 looking.


I believe people do try to account for your possible opinion when 
making decisions, but your opinion is too inconsistent to be 
predictable, instead you always make judgement calls. You can't 
trust people because they don't know what is the right decision 
in your opinion.
Nov 26 2015
parent reply Dicebot <public dicebot.lv> writes:
On Thursday, 26 November 2015 at 09:21:33 UTC, Kagamin wrote:

 On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei 
 Alexandrescu wrote:

 I need to trust our core contributors here to make the right 
 high-level decisions and execute them accurately when I'm not 
 looking.


 I believe people do try to account for your possible opinion 
 when making decisions, but your opinion is too inconsistent to 
 be predictable, instead you always make judgement calls. You 
 can't trust people because they don't know what is the right 
 decision in your opinion.


This.

Sorry, Andrei, but you are absolutely terrible at management, at 
least at managing open-source project. Especially when compared 
to how brilliant you are as engineer and computer scientist.

I wouldn't normally bring attention to this topic to avoid 
starting yet another flame exchange but insulting Sonke in this 
thread was really pushing the limit. Especially considering it is 
_your_ personal failure as a leader to not react to one of 
announcements and discussions in time. With such attitude you 
will only alienate few hard working contributors which make D 
happen.
Nov 26 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 26, 2015 at 11:08:29AM +0000, Dicebot via Digitalmars-d wrote:

 On Thursday, 26 November 2015 at 09:21:33 UTC, Kagamin wrote:

On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei Alexandrescu
wrote:

I need to trust our core contributors here to make the right
high-level decisions and execute them accurately when I'm not
looking.


I believe people do try to account for your possible opinion when
making decisions, but your opinion is too inconsistent to be
predictable, instead you always make judgement calls. You can't trust
people because they don't know what is the right decision in your
opinion.


 
 This.
 
 Sorry, Andrei, but you are absolutely terrible at management, at least
 at managing open-source project. Especially when compared to how
 brilliant you are as engineer and computer scientist.
 
 I wouldn't normally bring attention to this topic to avoid starting
 yet another flame exchange but insulting Sonke in this thread was
 really pushing the limit. Especially considering it is _your_ personal
 failure as a leader to not react to one of announcements and
 discussions in time. With such attitude you will only alienate few
 hard working contributors which make D happen.


Not to mention each time this happens (and it has happened more than
once, to say the least) it kills morale, one of the most important
things in an open source project, because unlike a proprietary project,
there is no (or very little) financial motivation to keep going.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Nov 26 2015
prev sibling next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Wednesday, 25 November 2015 at 19:25:18 UTC, Andrei 
Alexandrescu wrote:

 As Walter said a few times by now, inventing new languages is 
 an endeavor of high fixed cost for everyone involved (including 
 users) and shouldn't be done casually.

 Please don't reply to this. Just throw SDL away and use JSON. 
 Please don't waste time discussing it.


I just about decided to quietly move on and not let this get to 
me but I can't seem to. I think it's important to say that I 
found this comment rude and highly atypical of this community at 
large. "Shut up and do what I say" from the language architect 
doesn't exactly foster an excited and healthy community.

This is the second time I've seen you do this recently[1] and 
both have been very disheartening to read.

1. 
https://github.com/D-Programming-Language/dmd/pull/5239#issuecomment-157031984
Nov 25 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 04:39 PM, Brad Anderson wrote:

 "Shut up and do what I say" from the language architect doesn't exactly
 foster an excited and healthy community.


It's more like "Do this, no need to argue". There's really no need, and 
we're arguing too much over too little. -- Andrei
Nov 25 2015
parent reply BLM768 <blm768 gmail.com> writes:
On Wednesday, 25 November 2015 at 22:20:39 UTC, Andrei 
Alexandrescu wrote:

 It's more like "Do this, no need to argue". There's really no 
 need, and we're arguing too much over too little. -- Andrei


Is anyone else having flashbacks to Phobos vs. Tango?

In this case, as much as I like how the SDL syntax is more 
readable (at least to me), the history of Phobos shows that 
standardization wins in most cases. I don't know if we want to 
yank the syntax right out of DUB, but we could at least deprecate 
it until things settle out.

Or, hey, we could use XML. ;)
Nov 25 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Nov 25, 2015 at 11:04:35PM +0000, BLM768 via Digitalmars-d wrote:

 On Wednesday, 25 November 2015 at 22:20:39 UTC, Andrei Alexandrescu wrote:

It's more like "Do this, no need to argue". There's really no need,
and we're arguing too much over too little. -- Andrei


 
 Is anyone else having flashbacks to Phobos vs. Tango?
 
 In this case, as much as I like how the SDL syntax is more readable
 (at least to me), the history of Phobos shows that standardization
 wins in most cases. I don't know if we want to yank the syntax right
 out of DUB, but we could at least deprecate it until things settle
 out.
 
 Or, hey, we could use XML. ;)


[...]

Please, no. XML is unreadable write-only stuff that should only be
read/written by machine, it's not suitable as a *user* interface.


T

-- 
Customer support: the art of getting your clients to pay for your own
incompetence.
Nov 25 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 26 November 2015 at 00:04:49 UTC, H. S. Teoh wrote:

 Please, no. XML is unreadable write-only stuff that should only 
 be read/written by machine, it's not suitable as a *user* 
 interface.


XML is perfectly fine for hand editing if the grammar is well 
designed. You even have IDEs that can do grammar based editing 
which means you only can write valid documents.

It doesn't matter what format you use for this simple 
application, though.
Nov 26 2015
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 25.11.2015 um 20:25 schrieb Andrei Alexandrescu:

 As Walter said a few times by now, inventing new languages is an
 endeavor of high fixed cost for everyone involved (including users) and
 shouldn't be done casually.

 Please don't reply to this. Just throw SDL away and use JSON. Please
 don't waste time discussing it.


 Thanks,

 Andrei


Nobody has invented anything here. Please at least get your facts 
straight before ending discussions in this tone and manner.

Thanks,

Sönke
Nov 26 2015
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:

 Am 25.11.2015 um 20:25 schrieb Andrei Alexandrescu:

 As Walter said a few times by now, inventing new languages is 
 an
 endeavor of high fixed cost for everyone involved (including 
 users) and
 shouldn't be done casually.

 Please don't reply to this. Just throw SDL away and use JSON. 
 Please
 don't waste time discussing it.


 Thanks,

 Andrei


 Nobody has invented anything here. Please at least get your 
 facts straight before ending discussions in this tone and 
 manner.

 Thanks,

 Sönke


Single language, json based configuration engine is simpler for 
IDE development and configuration tools. For example, Sublime 
Text.This is very important to make language used by big amount 
of users.

Ilya
Nov 26 2015
next sibling parent reply ponce <contact gamesfrommars.fr> writes:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko 
wrote:

 Single language, json based configuration engine is simpler for 
 IDE development and configuration tools. For example, Sublime 
 Text.This is very important to make language used by big amount 
 of users.

 Ilya


Sublime Text configuration has no comments and this kind of sucks 
compared to eg. a webserver key-value configuration file, or 
sc.ini, so I'm not sure you chose the best example.
Nov 26 2015
parent reply Jack Applegame <japplegame gmail.com> writes:
On Thursday, 26 November 2015 at 09:41:38 UTC, ponce wrote:

 On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko 
 wrote:

 Single language, json based configuration engine is simpler 
 for IDE development and configuration tools. For example, 
 Sublime Text.This is very important to make language used by 
 big amount of users.

 Ilya


 Sublime Text configuration has no comments and this kind of 
 sucks compared to eg. a webserver key-value configuration file, 
 or sc.ini, so I'm not sure you chose the best example.


Sublime Text configuration has a lot of comments:

// Place your settings in the file 
"User/Preferences.sublime-settings", which
// overrides the settings in here.
//
// Settings may also be placed in file type specific options 
files, for
// example, in Packages/Python/Python.sublime-settings for python 
files.
{
     // Sets the colors used within the text area
     "color_scheme": "Packages/Color Scheme - 
Default/Monokai.tmTheme",

     // Note that the font_face and font_size are overridden in 
the platform
     // specific settings file, for example, "Preferences 
(Linux).sublime-settings".
     // Because of this, setting them here will have no effect: 
you must set them
     // in your User File Preferences.
     "font_face": "",
     "font_size": 10,

     // Valid options are "no_bold", "no_italic", "no_antialias", 
"gray_antialias",
     // "subpixel_antialias", "no_round" (OS X only), "gdi" 
(Windows only) and
     // "directwrite" (Windows only)
     "font_options": [],
Nov 26 2015
parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 27 November 2015 at 07:31:35 UTC, Jack Applegame wrote:

 Sublime Text configuration has a lot of comments:

 // Place your settings in the file 
 "User/Preferences.sublime-settings", which
 // overrides the settings in here.
 //
 // Settings may also be placed in file type specific options 
 files, for


Didn't know that.
Well it's not JSON then. It's a niche JSON-derivative.
Nov 27 2015
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko 
wrote:


 Single language, json based configuration engine is simpler for 
 IDE development and configuration tools. For example, Sublime 
 Text.This is very important to make language used by big amount 
 of users.

 Ilya


This is not even an issue. IDEs can create a dub.json for all new 
projects and call 'dub describe' on imported projects without 
ever touching SDLang. Again, *there is no problem here*.
Nov 26 2015
next sibling parent reply Dragos Carp <dragoscarp gmail.com> writes:
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:

 This is not even an issue. IDEs can create a dub.json for all 
 new projects and call 'dub describe' on imported projects 
 without ever touching SDLang. Again, *there is no problem here*.


'dub describe' has one big issue. It works only if you manage 
your packages in $HOME/.dub. Integrating 'dub describe' in 
another build tool with a different directory layout is currently 
impossible.

Parsing the dub.json files directly from the external build tool 
('rake' in my case) was doable and reasonably easy, with dub.sdl 
not anymore.
Nov 26 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 26 November 2015 at 10:28:15 UTC, Dragos Carp wrote:

 On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker 
 wrote:

 This is not even an issue. IDEs can create a dub.json for all 
 new projects and call 'dub describe' on imported projects 
 without ever touching SDLang. Again, *there is no problem 
 here*.


 'dub describe' has one big issue. It works only if you manage 
 your packages in $HOME/.dub. Integrating 'dub describe' in 
 another build tool with a different directory layout is 
 currently impossible.

 Parsing the dub.json files directly from the external build 
 tool ('rake' in my case) was doable and reasonably easy, with 
 dub.sdl not anymore.


Pretty sure it works fine with anything that dub knows about.

dub add-path or dub add-local should put things on an even 
footing with ~/.dub in that regard.
Nov 26 2015
parent Dragos Carp <dragoscarp gmail.com> writes:
On Thursday, 26 November 2015 at 11:49:25 UTC, John Colvin wrote:

 Pretty sure it works fine with anything that dub knows about.

 dub add-path or dub add-local should put things on an even 
 footing with ~/.dub in that regard.


`dub add-path` and `dub add-local` permanently add the specified 
paths to `~/.dub/packages/local-packages.json`. So this means 
that `~/.dub` is still special. and additional steps are 
necessary to keep this file clean.

Better it would be to able to specify this path on calling `dub 
describe`.
Nov 26 2015
prev sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:

 On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko 
 wrote:


 Single language, json based configuration engine is simpler 
 for IDE development and configuration tools. For example, 
 Sublime Text.This is very important to make language used by 
 big amount of users.

 Ilya


 This is not even an issue. IDEs can create a dub.json for all 
 new projects and call 'dub describe' on imported projects 
 without ever touching SDLang. Again, *there is no problem here*.


The problem is dependency from dub because some dependencies of a 
project can have SDL configs.
Nov 26 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 16:43 schrieb Ilya Yaroshenko:

 On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:

 On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko wrote:


 Single language, json based configuration engine is simpler for IDE
 development and configuration tools. For example, Sublime Text.This
 is very important to make language used by big amount of users.

 Ilya


 This is not even an issue. IDEs can create a dub.json for all new
 projects and call 'dub describe' on imported projects without ever
 touching SDLang. Again, *there is no problem here*.


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


The only valid reason for an IDE to directly parse the package 
description is basically if it wants to provide a custom UI for editing 
it. If the IDE is written in D, it can easily use DUB as a library and 
not only get the package description in a common format, but also nicely 
statically typed. If not, the conversion feature that was planned for 
the next version would trivially solve that, too.
Nov 26 2015
next sibling parent reply B.Basile <bb.temp gmx.com> writes:
On Thursday, 26 November 2015 at 16:10:10 UTC, Sönke Ludwig wrote:

 [...]
 The only valid reason for an IDE to directly parse the package 
 description is basically if it wants to provide a custom UI for 
 editing it. If the IDE is written in D, it can easily use DUB 
 as a library and not only get the package description in a 
 common format, but also nicely statically typed. If not, the 
 conversion feature that was planned for the next version would 
 trivially solve that, too.


No, there's also a problem of latency caused by dependency 
checking (and if there are any). But that's actually linked: if 
an IDE wants to make a UI editor for a DUB description it's 
faster to parse directly the description...Maybe you'll remember 
a brief discussion about this (at the end of summer when you 
released latest DUB version, maybe in the NG discussion created 
for the RC).

But that's a only personnal concern. Since SDL is not popular, 
there is no SDL library for the language used to write the IDE, 
so it sucks a bit...The day it'll become unsustainable I'll write 
a SDL parser for this lang, but so far it only happend **once** 
to find an online package that was in SDL and that I ve ignored 
because I knew I couln't easily inspect the sources, modify them 
or recompile.
Nov 26 2015
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 18:16 schrieb B.Basile:

 On Thursday, 26 November 2015 at 16:10:10 UTC, Sönke Ludwig wrote:

 [...]
 The only valid reason for an IDE to directly parse the package
 description is basically if it wants to provide a custom UI for
 editing it. If the IDE is written in D, it can easily use DUB as a
 library and not only get the package description in a common format,
 but also nicely statically typed. If not, the conversion feature that
 was planned for the next version would trivially solve that, too.


 No, there's also a problem of latency caused by dependency checking (and
 if there are any).


But that won't happen in case of the conversion feature (and neither 
when parsing it using the DUB library). My point is that everything 
apart from a simple package recipe editor UI basically has to 
reimplement large parts of DUB, which makes it rather impractical.
Nov 26 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 26/11/2015 16:10, Sönke Ludwig wrote:

 The only valid reason for an IDE to directly parse the package
 description is basically if it wants to provide a custom UI for editing
 it. If the IDE is written in D, it can easily use DUB as a library and
 not only get the package description in a common format, but also nicely
 statically typed. If not, the conversion feature that was planned for
 the next version would trivially solve that, too.


This is isn't true. There are things that an IDE might want to do, that 
"dub describe" doesn't currently account for. The DDT IDE is an example 
of that, and I've raised these issues before with DUB. For example:

  * dub describe fails if dependency resolution fails, yet there is 
still partial information about the DUB package that would be of use.
  * dub describe does not provide information for all build 
configurations, only the default one. As such the IDE has to parse the 
json to find out all available configurations itself. (This is used in 
the DDT IDE to show a list of "Build Targets" in the UI)


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Nov 26 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 21:41 schrieb Bruno Medeiros:

 On 26/11/2015 16:10, Sönke Ludwig wrote:

 The only valid reason for an IDE to directly parse the package
 description is basically if it wants to provide a custom UI for editing
 it. If the IDE is written in D, it can easily use DUB as a library and
 not only get the package description in a common format, but also nicely
 statically typed. If not, the conversion feature that was planned for
 the next version would trivially solve that, too.


 This is isn't true. There are things that an IDE might want to do, that
 "dub describe" doesn't currently account for. The DDT IDE is an example
 of that, and I've raised these issues before with DUB. For example:

   * dub describe fails if dependency resolution fails, yet there is
 still partial information about the DUB package that would be of use.


Good point. I'd say "dub describe" should simply fail gracefully and 
just skip the "targets" and "dependencies" fields.


   * dub describe does not provide information for all build
 configurations, only the default one. As such the IDE has to parse the
 json to find out all available configurations itself. (This is used in
 the DDT IDE to show a list of "Build Targets" in the UI)


You can do "dub --print-builds --print-configs --annotate"

But it's currently uselessly bound to the build/run commands. Should 
definitely be part of "dub describe"'s output.
Nov 27 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 27/11/2015 12:33, Sönke Ludwig wrote:

 * dub describe does not provide information for all build
 configurations, only the default one. As such the IDE has to parse the
 json to find out all available configurations itself. (This is used in
 the DDT IDE to show a list of "Build Targets" in the UI)


 You can do "dub --print-builds --print-configs --annotate"

 But it's currently uselessly bound to the build/run commands. Should
 definitely be part of "dub describe"'s output.


Thanks, this seems like it should be useful.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Dec 07 2015
parent reply Suliman <evermind live.ru> writes:
Sönke Ludwig, really sorry. It's look my big mistake. I looked at 
SDL more detail, and this format is much better than JSON.

I hope a lot of people is changed their position too.
Sep 14 2016
next sibling parent Basile B <b2.temp gmx.com> writes:
On Wednesday, 14 September 2016 at 11:54:56 UTC, Suliman wrote:

 Sönke Ludwig, really sorry. It's look my big mistake. I looked 
 at SDL more detail, and this format is much better than JSON.

 I hope a lot of people is changed their position too.


The main diff I see is that in JSON you can have arbitrary 
property names

e.g: dflags-windows-x86

while in SDL the arch and system parts are defined as attribute. 
This is clearly cleaner and it probably prevents a lot of 
lookup...but

I still prefer JSON because of CE even if SDL is supported now in 
Coedit upstream.
Sep 16 2016
prev sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Wednesday, 14 September 2016 at 11:54:56 UTC, Suliman wrote:

 Sönke Ludwig, really sorry. It's look my big mistake. I looked 
 at SDL more detail, and this format is much better than JSON.

 I hope a lot of people is changed their position too.


There is a superset of Json that could of been used instead.
Sep 16 2016
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 16 September 2016 at 14:44:18 UTC, Gary Willoughby 
wrote:

 On Wednesday, 14 September 2016 at 11:54:56 UTC, Suliman wrote:

 Sönke Ludwig, really sorry. It's look my big mistake. I looked 
 at SDL more detail, and this format is much better than JSON.

 I hope a lot of people is changed their position too.


 There is a superset of Json that could of been used instead.


When starting a project with `dub` you are given the choice 
between SDL and JSON. No need to worry:

$ dub init sample
Package recipe format (sdl/json) [json]:

Do we have a converter tool by now?
Sep 16 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 17/09/2016 2:48 AM, Chris wrote:

 On Friday, 16 September 2016 at 14:44:18 UTC, Gary Willoughby wrote:

 On Wednesday, 14 September 2016 at 11:54:56 UTC, Suliman wrote:

 Sönke Ludwig, really sorry. It's look my big mistake. I looked at SDL
 more detail, and this format is much better than JSON.

 I hope a lot of people is changed their position too.


 There is a superset of Json that could of been used instead.


 When starting a project with `dub` you are given the choice between SDL
 and JSON. No need to worry:

 $ dub init sample
 Package recipe format (sdl/json) [json]:

 Do we have a converter tool by now?


$ dub convert
Sep 16 2016
parent Chris <wendlec tcd.ie> writes:
On Friday, 16 September 2016 at 14:54:20 UTC, rikki cattermole 
wrote:

 On 17/09/2016 2:48 AM, Chris wrote:

 On Friday, 16 September 2016 at 14:44:18 UTC, Gary Willoughby 
 wrote:

 When starting a project with `dub` you are given the choice 
 between SDL
 and JSON. No need to worry:

 $ dub init sample
 Package recipe format (sdl/json) [json]:

 Do we have a converter tool by now?


 $ dub convert


Cool. So all good.
Sep 16 2016
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 16 September 2016 at 14:48:30 UTC, Chris wrote:

 Do we have a converter tool by now?


SDL to JSON is available in the results of `dub describe` (in the 
"packages" array, usually the first item is the JSON for the SDL 
you describe).
Sep 16 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko 
wrote:

 On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig



 Single language, json based configuration engine is simpler for 
 IDE development and configuration tools. For example, Sublime 
 Text.This is very important to make language used by big amount 
 of users.

 Ilya


This is an important point. JSON can be used by tools other than 
DUB (IDEs etc.)

Let me suggest the following:

1. JSON as default format in DUB when you type `dub init`; SDL as 
second option
2. a JSON <=> SDL converter (will be needed for community 
projects)
3. add the ability to add comments to JSON files in DUB, so DUB 
can handle comments in JSON and JSON's biggest disadvantage 
disappears (as does the bikeshed)
Nov 26 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2015 12:50 AM, Sönke Ludwig wrote:

 Nobody has invented anything here. Please at least get your facts straight
 before ending discussions in this tone and manner.


I told Andrei it was invented, so I take the blame for that. I was wrong. 
Jonathan has since corrected me.
Nov 26 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 18:10 schrieb Walter Bright:

 On 11/26/2015 12:50 AM, Sönke Ludwig wrote:

 Nobody has invented anything here. Please at least get your facts
 straight
 before ending discussions in this tone and manner.


 I told Andrei it was invented, so I take the blame for that. I was
 wrong. Jonathan has since corrected me.


Sorry, I had not read the whole thread at that time, so I missed that. 
But still this thread has overall been very irritating to me (that 
doesn't quite describe it). Maybe I should better have replied 
immediately and anticipate some of the statements that followed, but I 
have discussed this topic countless times and I'm getting seriously 
tired of it (because it is the _prototype of a bikeshedding topic_). 
Combine that with a hardly motivated and inflammatory initial post, I 
was hoping that this would just quickly die off - obviously a very naive 
thought.

Just to mention one additional reason for choosing SDLang over one of 
the more popular formats that shared some of the advantages, there is an 
idea to add limited support for (declarative) procedural statements: 
https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
The representation possible with SDLang is not as good as in an actual 
programming language, but far better than with any of the JSON-like 
languages.

Otherwise, the language syntax is also quite a natural fit for a 
curly-brace based language. And its simplicity basically renders the 
"learn" argument moot - what you really have to learn is the set of 
directives that DUB recognizes.

Overall, I don't think the popularity argument actually has much weight, 
but there are indeed a lot of arguments for a better format in general. 
BTW, around 20 of the packages registered on code.dlang.org since the 
release of the 0.9.24 version have SDLang based package descriptions 
(about 50%). I haven't checked the already existing packages.
Nov 26 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-26 20:05, Sönke Ludwig wrote:


 Just to mention one additional reason for choosing SDLang over one of
 the more popular formats that shared some of the advantages, there is an
 idea to add limited support for (declarative) procedural statements:
 https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
 The representation possible with SDLang is not as good as in an actual
 programming language, but far better than with any of the JSON-like
 languages.


Everyone will hate me for saying this, but in that case, just go with 
Ruby (or some other similar language)

-- 
/Jacob Carlborg
Nov 26 2015
next sibling parent reply Suliman <evermind live.ru> writes:
On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg 
wrote:

 On 2015-11-26 20:05, Sönke Ludwig wrote:


 Just to mention one additional reason for choosing SDLang over 
 one of
 the more popular formats that shared some of the advantages, 
 there is an
 idea to add limited support for (declarative) procedural 
 statements:
 https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
 The representation possible with SDLang is not as good as in 
 an actual
 programming language, but far better than with any of the 
 JSON-like
 languages.


 Everyone will hate me for saying this, but in that case, just 
 go with Ruby (or some other similar language)


Why?
Nov 26 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-11-26 21:03, Suliman wrote:


 Why?


This is why [1]. Also, many developers here seem to have something 
against Ruby, in general. Or at least they don't want a single piece of 
Ruby code near D.

I contributed a build script for the OS X installer, written in Ruby. 
Eventually it was converted to shell script.

[1] http://forum.dlang.org/post/n38vv7$lnf$1 digitalmars.com

-- 
/Jacob Carlborg
Nov 26 2015
prev sibling parent reply BLM768 <blm768 gmail.com> writes:
On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg 
wrote:

 Everyone will hate me for saying this, but in that case, just 
 go with Ruby (or some other similar language)


That was actually one of my first thoughts. It would be pretty, 
but we'd have another dependency then. Also, Ruby doesn't embed 
well into other applications, and if we're using another 
general-purpose programming language for our config format, what 
kind of impression does that give others about our confidence in 
D?

That said, I found a neat language today, and it might be usable 
for config files. See nim-lang.org.
Nov 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-26 23:38, BLM768 wrote:


 That was actually one of my first thoughts. It would be pretty, but we'd
 have another dependency then. Also, Ruby doesn't embed well into other
 applications


I has worked fine for me.


 and if we're using another general-purpose programming
 language for our config format, what kind of impression does that give
 others about our confidence in D?


This is (one of the reasons) why people complain. The problem with D is 
that it won't be pretty.

-- 
/Jacob Carlborg
Nov 26 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 07:15:51 UTC, Jacob Carlborg wrote:

 This is (one of the reasons) why people complain. The problem 
 with D is that it won't be pretty.


Well, I usually don't use package managers for source code, but 
if I did I would not consider using one that can write to random 
directories.

So if one uses Ruby, Python or D, the package manager has to make 
sure it executes in a "jail filesystem sandbox" that only can 
touch a specific subtree.
Nov 27 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-11-27 10:24, Ola Fosheim Grøstad wrote:


 Well, I usually don't use package managers for source code, but if I did
 I would not consider using one that can write to random directories.

 So if one uses Ruby, Python or D, the package manager has to make sure
 it executes in a "jail filesystem sandbox" that only can touch a
 specific subtree.


RubyGems works like this:

1. The author of a tool writes the package description in Ruby
2. The author then builds a gem (package) using the tool
3. The tool serializes/converts the Ruby code to YAML in the gem
4. The author uploads the gem using the tool

Then when a gem is installed the tool will only have access to the YAML 
file and reads that. The only one that have access to and need to run 
the Ruby code is the author.

-- 
/Jacob Carlborg
Nov 27 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2015 11:05 AM, Sönke Ludwig wrote:

 But still
 this thread has overall been very irritating to me (that doesn't quite describe
 it). Maybe I should better have replied immediately and anticipate some of the
 statements that followed, but I have discussed this topic countless times and
 I'm getting seriously tired of it (because it is the _prototype of a
 bikeshedding topic_). Combine that with a hardly motivated and inflammatory
 initial post, I was hoping that this would just quickly die off - obviously a
 very naive thought.


I understand you being angry about this. It would be hard not to be. It would 
have been a lot better if Andrei and I had noticed this before much was
invested 
in it.



 Just to mention one additional reason for choosing SDLang over one of the more
 popular formats that shared some of the advantages, there is an idea to add
 limited support for (declarative) procedural statements:
 https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
 The representation possible with SDLang is not as good as in an actual
 programming language, but far better than with any of the JSON-like languages.


This looks like it's creeping towards inventing a new script programming 
language. Adding loops, switch statements, functions, etc., can't be far off. 
Before you get too far down this path, consider:

1. JSON has a superset programming language - Javascript - which has 
conventional syntax rather than the DEP4 proposal for odd syntax like

     if dub-version="<0.9.24"

which I would strongly recommend against. And, we already have a Javascript 
engine written in D:

     https://github.com/DigitalMars/DMDScript


in the source code). Having DUB use this might be quite interesting.



 Otherwise, the language syntax is also quite a natural fit for a curly-brace
 based language. And its simplicity basically renders the "learn" argument moot
-
 what you really have to learn is the set of directives that DUB recognizes.

 Overall, I don't think the popularity argument actually has much weight, but
 there are indeed a lot of arguments for a better format in general.


 From my other post in this thread about all the problems with going with SDL:

"With a standard json parser in Phobos, zip zap boom you're done. You don't
have 
to design it, argue about it, build it, document it, debug it, test it,
optimize 
it, explain it, deal with bug requests, deal with enhancement requests, deal 
with legacy compatibility, build a converter, build a gui tool for it, etc."
Nov 26 2015
next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 26.11.2015 um 23:47 schrieb Walter Bright:

 On 11/26/2015 11:05 AM, Sönke Ludwig wrote:

 But still
 this thread has overall been very irritating to me (that doesn't quite
 describe
 it). Maybe I should better have replied immediately and anticipate
 some of the
 statements that followed, but I have discussed this topic countless
 times and
 I'm getting seriously tired of it (because it is the _prototype of a
 bikeshedding topic_). Combine that with a hardly motivated and
 inflammatory
 initial post, I was hoping that this would just quickly die off -
 obviously a
 very naive thought.


 I understand you being angry about this. It would be hard not to be. It
 would have been a lot better if Andrei and I had noticed this before
 much was invested in it.


It's not so much about the objective topic, but about how this was 
handled - on a methodical/factual level, but mostly on the personal level.


 Just to mention one additional reason for choosing SDLang over one of
 the more
 popular formats that shared some of the advantages, there is an idea
 to add
 limited support for (declarative) procedural statements:
 https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
 The representation possible with SDLang is not as good as in an actual
 programming language, but far better than with any of the JSON-like
 languages.


 This looks like it's creeping towards inventing a new script programming
 language. Adding loops, switch statements, functions, etc., can't be far
 off. Before you get too far down this path, consider:


Actually, no! Conditionals and loops are the only constructs - switch is 
a possibility, but basically nothing else. There will also never be 
variables, just constants. There is a definitive limit, namely when it 
becomes impossible to reason about the code in a generic way, without 
"executing" it, so in particular anything that would make it touring 
complete is a no-go - no recursion, no loop flow control statements, no 
goto. In fact, there are no "statements" at all, these are all purely 
declarative "directives".


 1. JSON has a superset programming language - Javascript - which has
 conventional syntax rather than the DEP4 proposal for odd syntax like

      if dub-version="<0.9.24"

 which I would strongly recommend against. And, we already have a
 Javascript engine written in D:

      https://github.com/DigitalMars/DMDScript


 character in the source code). Having DUB use this might be quite
 interesting.


On one hand that means that now you have to take care of security issues 
(holes in the scripting engine/compiler or DoS attacks of various sorts) 
when you want to use this on a server (code.dlang.org). Once there are 
big numbers of packages, this could also mean that the hardware 
eventually needs to be upgraded when it would have done fine for a long 
time with a tiny declarative parser.

On the other hand, it's not possible with a script to make general 
predictions of how a package would behave, for example the script could 
select a dependency based on some environment variable or a file that is 
only defined on the target system.

A personal example is a CI system that I have that collects the proper 
dependencies and schedules builds on worker machines. With a script 
based package recipe that would mean that I'd have to implement 
complicated roundtrips to the target machines, which don't have the 
necessary knowledge to select the dependencies themselves (they'd need 
the full git history of each project). Not only would that mean a lot 
more work and a lot more failure points, but it also means that the 
workers become much more complex and will probably have to be updated 
regularly, meaning also more work for those who maintain them.

Finally, it's always possible to switch from declarative to script 
without loosing expressive power, but not necessarily the other way around.


 Otherwise, the language syntax is also quite a natural fit for a
 curly-brace
 based language. And its simplicity basically renders the "learn"
 argument moot -
 what you really have to learn is the set of directives that DUB
 recognizes.

 Overall, I don't think the popularity argument actually has much
 weight, but
 there are indeed a lot of arguments for a better format in general.


  From my other post in this thread about all the problems with going
 with SDL:

 "With a standard json parser in Phobos, zip zap boom you're done. You
 don't have to design it, argue about it, build it, document it, debug
 it, test it, optimize it, explain it, deal with bug requests, deal with
 enhancement requests, deal with legacy compatibility, build a converter,
 build a gui tool for it, etc."


Let's say this isn't really an argument anymore now that it has already 
been done, but it wouldn't have been a strong argument anyway, because 
the SDLang parser is actually in use for other projects as well, so it 
has to be maintained anyway. There really is very little investment 
necessary development-wise, I think it took me maybe three to four hours 
total to implement it, including the support on code.dlang.org. Creating 
the sdlang-d library itself (by Nick Sabalausky) was of course a bigger 
task, as were the discussions and the design process.

But apart from that, finding a format that a) allows (real) comments and 
b) has less syntax noise was necessary in any case. Sure, JSON *works*, 
but it becomes really unpleasant with more complicated files, and the 
whole {"comment": "..."} approach is nothing but an ugly and highly 
inconvenient hack, both when writing and when reading it. And the fact 
is that no matter which other format we would have chosen (JSON with 
comments is also another language) we'd have these bikeshedding discussions.
Nov 26 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-27 08:08, Sönke Ludwig wrote:


 Actually, no! Conditionals and loops are the only constructs - switch is
 a possibility, but basically nothing else. There will also never be
 variables, just constants. There is a definitive limit, namely when it
 becomes impossible to reason about the code in a generic way, without
 "executing" it, so in particular anything that would make it touring
 complete is a no-go - no recursion, no loop flow control statements, no
 goto. In fact, there are no "statements" at all, these are all purely
 declarative "directives".



 On one hand that means that now you have to take care of security issues
 (holes in the scripting engine/compiler or DoS attacks of various sorts)
 when you want to use this on a server (code.dlang.org). Once there are
 big numbers of packages, this could also mean that the hardware
 eventually needs to be upgraded when it would have done fine for a long
 time with a tiny declarative parser.


Personally I think Dub and code.dlang.org is designed completely wrong. 
Currently Dub works by the user pushing new code to the repository on 
GitHub and code.dlang.org watching for changes. If the user instead 
would use Dub to build a package locally which is then uploaded to 
code.dlang.org you would have less of these issues. The code would be 
executed on the client and serialized to a data format (JSON, XML, YAML, 
whatever) that no person will ever see. code.dlang.org would then read 
this data format, instead of executing the code, just like it's doing now.

-- 
/Jacob Carlborg
Nov 26 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 27.11.2015 um 08:29 schrieb Jacob Carlborg:

 Personally I think Dub and code.dlang.org is designed completely wrong.
 Currently Dub works by the user pushing new code to the repository on
 GitHub and code.dlang.org watching for changes. If the user instead
 would use Dub to build a package locally which is then uploaded to
 code.dlang.org you would have less of these issues. The code would be
 executed on the client and serialized to a data format (JSON, XML, YAML,
 whatever) that no person will ever see. code.dlang.org would then read
 this data format, instead of executing the code, just like it's doing now.


That would mean more work for everyone and consequently less adoption. 
Seriously, I think it's the best approach possible and really couldn't 
imagine using a more manual system to the extend that I do now. But more 
importantly, it would mean that we have a problem with cross-platform 
packages. You can't expect everyone to be able to build for all 
platforms. But if they don't, you can't know the dependencies or 
whatever else for those other platforms, even if the code would in 
theory compile fine.
Nov 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-27 08:55, Sönke Ludwig wrote:


 That would mean more work for everyone and consequently less adoption.


How so? It's the same amount of commands, maybe one extra.


 Seriously, I think it's the best approach possible and really couldn't
 imagine using a more manual system to the extend that I do now. But more
 importantly, it would mean that we have a problem with cross-platform
 packages. You can't expect everyone to be able to build for all
 platforms. But if they don't, you can't know the dependencies or
 whatever else for those other platforms, even if the code would in
 theory compile fine.


The packages don't need to contain compiled binaries. It could still be 
source distribution.

-- 
/Jacob Carlborg
Nov 27 2015
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.11.2015 um 20:25 schrieb Jacob Carlborg:

 On 2015-11-27 08:55, Sönke Ludwig wrote:


 That would mean more work for everyone and consequently less adoption.


 How so? It's the same amount of commands, maybe one extra.


Granted, with a CLI it's not that bad. Although then you also have to 
manage user credentials. So it just means a bit more to learn and 
remember. That alone is not much, but it adds another bit to the barrier 
of entry - something that may be irrelevant if the barrier is low 
enough, but it may make a difference once things start to feel complicated.


 Seriously, I think it's the best approach possible and really couldn't
 imagine using a more manual system to the extend that I do now. But more
 importantly, it would mean that we have a problem with cross-platform
 packages. You can't expect everyone to be able to build for all
 platforms. But if they don't, you can't know the dependencies or
 whatever else for those other platforms, even if the code would in
 theory compile fine.


 The packages don't need to contain compiled binaries. It could still be
 source distribution.


What I mean is that the script will have to be run for each target 
platform just to know the final settings (e.g. dependencies) that it 
generates.
Nov 30 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Friday, 27 November 2015 at 07:08:40 UTC, Sönke Ludwig wrote:

 Actually, no! Conditionals and loops are the only constructs - 
 switch is a possibility, but basically nothing else. There will 
 also never be variables, just constants. There is a definitive 
 limit, namely when it becomes impossible to reason about the 
 code in a generic way, without "executing" it, so in particular 
 anything that would make it touring complete is a no-go - no 
 recursion, no loop flow control statements, no goto. In fact, 
 there are no "statements" at all, these are all purely 
 declarative "directives".


I think conditions in msbuild are neat:
<PropertyGroup Condition="'$(StyleCopEnabled)' == ''">
   <StyleCopEnabled>true</StyleCopEnabled>
</PropertyGroup>
You can make any tag conditional by adding a Condition attribute 
to it without creating an additional nesting level. Though it has 
condition grammar.
It has variables too:
<CreateItem
   Include=" (Compile)"
   Exclude="
   %(Project.RootDir)%(Project.Directory)**\*Test.cs;
   %(Project.RootDir)%(Project.Directory)**\*.Designer.cs">
   <Output TaskParameter="Include" ItemName="StyleCopFiles"/>
</CreateItem>
This takes compiled files, removes unneeded ones and subsequently 
the resulting files (StyleCopFiles) are fed to a style analyzer 
tool.


 Sure, JSON *works*, but it becomes really unpleasant with more 
 complicated files, and the whole {"comment": "..."} approach is 
 nothing but an ugly and highly inconvenient hack, both when 
 writing and when reading it.


Also in the dependencies map keys are package names so 
{"comment": "..."} will be a dependency on a comment package.
Nov 27 2015
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 07:08:40 UTC, Sönke Ludwig wrote:

 Actually, no! Conditionals and loops are the only constructs - 
 switch is a possibility, but basically nothing else. There will 
 also never be variables, just constants. There is a definitive 
 limit, namely when it becomes impossible to reason about the 
 code in a generic way, without "executing" it, so in particular 
 anything that would make it touring complete is a no-go - no 
 recursion, no loop flow control statements, no goto. In fact, 
 there are no "statements" at all, these are all purely 
 declarative "directives".


Sounds like you should consider using a datalog engine. Good 
inference power and performance, but not turing complete.

Ola.
Nov 27 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2015 11:08 PM, Sönke Ludwig wrote:

 This looks like it's creeping towards inventing a new script programming
 language. Adding loops, switch statements, functions, etc., can't be far
 off. Before you get too far down this path, consider:


 Actually, no! Conditionals and loops are the only constructs - switch is a
 possibility, but basically nothing else. There will also never be variables,
 just constants. There is a definitive limit, namely when it becomes impossible
 to reason about the code in a generic way, without "executing" it, so in
 particular anything that would make it touring complete is a no-go - no
 recursion, no loop flow control statements, no goto. In fact, there are no
 "statements" at all, these are all purely declarative "directives".


I would say to that: "famous last words". As Exhibit A, I submit 'static if', 
which has been getting increasing pressure to augment with loops.



 1. JSON has a superset programming language - Javascript - which has
 conventional syntax rather than the DEP4 proposal for odd syntax like

      if dub-version="<0.9.24"

 which I would strongly recommend against. And, we already have a
 Javascript engine written in D:

      https://github.com/DigitalMars/DMDScript


 character in the source code). Having DUB use this might be quite
 interesting.


 On one hand that means that now you have to take care of security issues (holes
 in the scripting engine/compiler or DoS attacks of various sorts) when you want
 to use this on a server (code.dlang.org).


You have to deal with that even if just plain json or sdl. After all, the 
implementation of those formats could be susceptible to buffer overflow or DoS 
as well. But this is less likely with json, because you'd be using a well-used 
json parser rather than your own sdl parser that is only used for Dub. (Yes I 
saw later that you use it in some other projects, but does it see use outside
of 
your own things?)

Javascript can only interact with its environment using the DOM. If Dub 
presented its own DOM to the js engine, there isn't much the js code can do 
other than go into an infinite loop, recursive overflow, or exploit a buffer 
overflow.


 Once there are big numbers of
 packages, this could also mean that the hardware eventually needs to be
upgraded
 when it would have done fine for a long time with a tiny declarative parser.


I would think these problems have all been solved with Javascript, since it is 
used so extensively. Javascript is also a lightweight scripting language.



 On the other hand, it's not possible with a script to make general predictions
 of how a package would behave, for example the script could select a dependency
 based on some environment variable or a file that is only defined on the target
 system.


That goes back to restricting the DOM.



 Finally, it's always possible to switch from declarative to script without
 loosing expressive power, but not necessarily the other way around.


True, but consider this. JSON is a subset of Javascript. That means you could 
add a subset of Javascript to JSON, i.e. just the if statements. You'll have a 
clear design for it, and a clear path for how to do further enhancements.



 "With a standard json parser in Phobos, zip zap boom you're done. You
 don't have to design it, argue about it, build it, document it, debug
 it, test it, optimize it, explain it, deal with bug requests, deal with
 enhancement requests, deal with legacy compatibility, build a converter,
 build a gui tool for it, etc."


 Let's say this isn't really an argument anymore now that it has already been
 done,


The existence of the DEPs suggest otherwise, the number of posts in this thread 
suggest otherwise, the calls for a gui editor suggest otherwise, the customer 
"should I use json or sdl" makes for an ongoing support problem, no current 
means to convert between the two, etc.



 but it wouldn't have been a strong argument anyway, because the SDLang
 parser is actually in use for other projects as well, so it has to be
maintained
 anyway. There really is very little investment necessary development-wise, I
 think it took me maybe three to four hours total to implement it, including the
 support on code.dlang.org. Creating the sdlang-d library itself (by Nick
 Sabalausky) was of course a bigger task, as were the discussions and the design
 process.


The time for JSON was zero. You're a key developer here, and your time is very 
valuable. I can't tell you what to work on, but I can't be quiet about spending 
time on things with such marginal utility (and yes, I waste time, too). By
using 
sdl, though, you're also spending other peoples' time, even if it's just "which 
format should I use for my project?" and then the D forum members have to
advise 
them.



 But apart from that, finding a format that a) allows (real) comments and b) has
 less syntax noise was necessary in any case. Sure, JSON *works*, but it becomes
 really unpleasant with more complicated files, and the whole {"comment": "..."}
 approach is nothing but an ugly and highly inconvenient hack, both when writing
 and when reading it.


I'm not accepting the "ugly and highly inconvenient hack" argument in the light 
of the DEP4 proposal for conditional syntax that I already commented on. And,
as 
mentioned before, I use $(COMMENT ...) in Ddoc and it works out quite nicely, 
even though Ddoc has no syntax for comments.

And if comments were the only reason to use sdl, and a solid case was made for 
them vs my suggestion, I'd vastly prefer adding /**/ to the json support rather 
than switching to an apparently dead format.



 And the fact is that no matter which other format we would
 have chosen (JSON with comments is also another language) we'd have these
 bikeshedding discussions.


Sticking with json would enable you to simply ignore it. But you've been pretty 
much forced to engage in this one.
Nov 27 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.11.2015 um 16:23 schrieb Walter Bright:

 On 11/26/2015 11:08 PM, Sönke Ludwig wrote:

 This looks like it's creeping towards inventing a new script programming
 language. Adding loops, switch statements, functions, etc., can't be far
 off. Before you get too far down this path, consider:


 Actually, no! Conditionals and loops are the only constructs - switch
 is a
 possibility, but basically nothing else. There will also never be
 variables,
 just constants. There is a definitive limit, namely when it becomes
 impossible
 to reason about the code in a generic way, without "executing" it, so in
 particular anything that would make it touring complete is a no-go - no
 recursion, no loop flow control statements, no goto. In fact, there
 are no
 "statements" at all, these are all purely declarative "directives".


 I would say to that: "famous last words". As Exhibit A, I submit 'static
 if', which has been getting increasing pressure to augment with loops.


It's hard to make guarantees, true. But at least "static foreach" has 
always been a relatively obvious candidate, and at the same time there 
is a well defined limit in case of the package recipe format.


 1. JSON has a superset programming language - Javascript - which has
 conventional syntax rather than the DEP4 proposal for odd syntax like

      if dub-version="<0.9.24"

 which I would strongly recommend against. And, we already have a
 Javascript engine written in D:

      https://github.com/DigitalMars/DMDScript


 character in the source code). Having DUB use this might be quite
 interesting.


 On one hand that means that now you have to take care of security
 issues (holes
 in the scripting engine/compiler or DoS attacks of various sorts) when
 you want
 to use this on a server (code.dlang.org).


 You have to deal with that even if just plain json or sdl. After all,
 the implementation of those formats could be susceptible to buffer
 overflow or DoS as well. But this is less likely with json, because
 you'd be using a well-used json parser rather than your own sdl parser
 that is only used for Dub.


The important difference is that a JSON/SDL parser has a vastly lower 
complexity than a scripting engine and, more importantly, the source 
file is just parsed in a linear fashion, without any arbitrary runtime 
execution. So when just parsing the format, making sure that the file is 
below a certain maximum size is enough to prevent typical DoS vectors.

For scripts, you'd at least have to be able to terminate after a certain 
time (but even with a relatively low timeout, say 5 seconds, it would be 
easy to bring the system down temporarily, by e.g. publishing a bunch of 
package versions at once). And if things like file system or network 
access are possible, the execution would realistically have to be moved 
to a sandbox (VM/chroot) environment to be safe.


 (Yes I saw later that you use it in some

 other projects, but does it see use outside of your own things?)




The current version of the sdlang-d package has been downloaded 83 times 
(DUB not counted) and there are GitHub issues opened by about 13 
different people, so it's definitely used for other projects, even if 
not yet hugely popular.


 Javascript can only interact with its environment using the DOM. If Dub
 presented its own DOM to the js engine, there isn't much the js code can
 do other than go into an infinite loop, recursive overflow, or exploit a
 buffer overflow.


This is where I'd see a similar problem to the "static foreach" one 
above. I'm pretty sure that people would start to ask for functions to 
access the file system, or to run arbitrary commands (which is fine on a 
local developer machine). It will be hard to argue against adding 
features that are so straight forward to implement.


 Once there are big numbers of
 packages, this could also mean that the hardware eventually needs to
 be upgraded
 when it would have done fine for a long time with a tiny declarative
 parser.


 I would think these problems have all been solved with Javascript, since
 it is used so extensively. Javascript is also a lightweight scripting
 language.


If the script is just a linear setup of the same fields as the current 
JSON/SDLang recipe then yes. But it's hard to predict what people will 
do with it. They might well go crazy and generate source code or other 
things that could take quite some time. It's just speculation, but the 
risk is there that this might considerably increase the load in the long 
run.


 On the other hand, it's not possible with a script to make general
 predictions
 of how a package would behave, for example the script could select a
 dependency
 based on some environment variable or a file that is only defined on
 the target
 system.


 That goes back to restricting the DOM.


True, but the pressure to add more power to the DOM will most likely be 
high.


 Finally, it's always possible to switch from declarative to script
 without
 loosing expressive power, but not necessarily the other way around.


 True, but consider this. JSON is a subset of Javascript. That means you
 could add a subset of Javascript to JSON, i.e. just the if statements.
 You'll have a clear design for it, and a clear path for how to do
 further enhancements.


The fundamental difference is that JSON just describes a single value, 
while a JS file describes a program. So while a subset of JS would be an 
option, it would still mean a completely different appearance for the 
package recipe files. And of course this really is inventing a new 
language ("why doesn't ... work if this is JS?").


 "With a standard json parser in Phobos, zip zap boom you're done. You
 don't have to design it, argue about it, build it, document it, debug
 it, test it, optimize it, explain it, deal with bug requests, deal with
 enhancement requests, deal with legacy compatibility, build a converter,
 build a gui tool for it, etc."


 Let's say this isn't really an argument anymore now that it has
 already been
 done,


 The existence of the DEPs suggest otherwise,


The SDLang format is just affected as a side-effect of 2 of those DEPs - 
just like the JSON format is. So, of course all supported formats have 
to be maintained and extended over time, but those are really quite rare 
occasions and the big majority of work is agnostic to the file format.


 the number of posts in this
 thread suggest otherwise,


The number of posts in this thread has multiple reasons, I'd argue that 
it's questionable to draw conclusions from that. Also, you need to 
contrast this to the amount of posts that complained about JSON, or 
those that would have happened for a different format choice.


 the calls for a gui editor suggest otherwise,


That has nothing to do with SDLang or not (at least as far as I 
understand it).


 the customer "should I use json or sdl" makes for an ongoing support
 problem,


I can't remember that that has happened. The current situation is that 
SDLang is endorsed as the recommended format and those who are used to 
the JSON one can just continue to use it if they want.


 no current means to convert between the two, etc.


That's really trivial to add, though. There is a generic internal 
representation and the only thing missing is the conversion back to SDLang.


 but it wouldn't have been a strong argument anyway, because the SDLang
 parser is actually in use for other projects as well, so it has to be
 maintained
 anyway. There really is very little investment necessary
 development-wise, I
 think it took me maybe three to four hours total to implement it,
 including the
 support on code.dlang.org. Creating the sdlang-d library itself (by Nick
 Sabalausky) was of course a bigger task, as were the discussions and
 the design
 process.


 The time for JSON was zero. You're a key developer here, and your time
 is very valuable. I can't tell you what to work on, but I can't be quiet
 about spending time on things with such marginal utility (and yes, I
 waste time, too). By using sdl, though, you're also spending other
 peoples' time, even if it's just "which format should I use for my
 project?" and then the D forum members have to advise them.


Again, I haven't seen that question so far if I remember right. But this 
also leaves out the reason why SDLang support was added in the first 
place: To improve the experience of working with package recipes. A lot 
more people are going to do that a lot more frequently, so that even a 
small amount of reduced friction is going to be likely to save overall time.

And sometimes small things can have a great impact. (The original) D is 
a good example, a lot of its appeal came from seemingly trivial syntax 
changes, but those actually often make a big difference in readability 
and developer focus.

Of course that computation may not hold if we just compare the time that 
it saves/costs the D contributors alone. But I wonder how many new 
features in general will actually save overall time if you just look at 
the core contributors.


 But apart from that, finding a format that a) allows (real) comments
 and b) has
 less syntax noise was necessary in any case. Sure, JSON *works*, but
 it becomes
 really unpleasant with more complicated files, and the whole
 {"comment": "..."}
 approach is nothing but an ugly and highly inconvenient hack, both
 when writing
 and when reading it.


 I'm not accepting the "ugly and highly inconvenient hack" argument in
 the light of the DEP4 proposal for conditional syntax that I already
 commented on. And, as mentioned before, I use $(COMMENT ...) in Ddoc and
 it works out quite nicely, even though Ddoc has no syntax for comments.


True, DEP4 definitely pushes the boundary of what is naturally 
representable with SDLang. But JSON files generally already have such a 
convoluted appearance that it simply becomes painfully involved and 
error prone to maintain them starting from a certain size. Since 
comments are mainly useful for larger documents, in the form of 
"comment" fields, they would make it even harder to read and maintain those.

If we are talking about how DEP4 looks for SDLang, just imagine how it 
would look for JSON...


 And if comments were the only reason to use sdl, and a solid case was
 made for them vs my suggestion, I'd vastly prefer adding /**/ to the
 json support rather than switching to an apparently dead format.


It just has to be clear that it's not JSON anymore what we use then 
(interoperability). Of course comments are not the only reason, but I 
think it's safe to say that they are one of the two most important ones. 
The other one is that the XML-like structure of SDLang lends itself much 
better for the task (unfortunately XML is even more involved to 
read/write than JSON).


 And the fact is that no matter which other format we would
 have chosen (JSON with comments is also another language) we'd have these
 bikeshedding discussions.


 Sticking with json would enable you to simply ignore it. But you've been
 pretty much forced to engage in this one.


Maybe it would have, maybe certain actions would still require to react. 
I don't have absolute numbers, but the complaints against JSON so far 
can probably easily rival those against SDL.


The way I see it:
  - It's clear that no solution will make everybody happy
  - The number of opponents for each format has shown to be in the same 
order of magnitude
  - The number of proponents is always hard to judge, because most of 
them usually stay quiet
  - Talking about purely declarative formats, popularity is hardly a 
strong argument anyway, because most people will still have to learn a 
new format (outside of JSON or XML)
  - SDLang is so simple and intuitive to C-family developers that there 
is almost nothing to learn

Based on this I'd rather concentrate at how well a format is suited for 
the particular task. Ideally that will result in a good format gaining 
some popularity (seems to be the case with TOML and Rust).
Nov 30 2015
parent reply Tourist <gravatar gravatar.com> writes:
On Monday, 30 November 2015 at 15:12:13 UTC, Sönke Ludwig wrote:

 The number of posts in this thread has multiple reasons, I'd 
 argue that it's questionable to draw conclusions from that.


Don't fool yourself. You made a mistake. That's fine. Own and fix 
it. Trying to make it look good is only making everything worse.

Any idea in this group will have a few enthusiasts, but here you 
have the majority of the community complaining and the three 
leaders Walter, Andrei, Martin tell you clear as rain you are 
wrong. What and why are you arguing?


 Also, you need to contrast this to the amount of posts that 
 complained about JSON, or those that would have happened for a 
 different format choice.


So let's add more. How does that logic work?

Do you have an answer to the comment that the file format is dead?
Nov 30 2015
parent reply ZombineDev <valid_email he.re> writes:
On Monday, 30 November 2015 at 15:41:39 UTC, Tourist wrote:

 On Monday, 30 November 2015 at 15:12:13 UTC, Sönke Ludwig wrote:

 The number of posts in this thread has multiple reasons, I'd 
 argue that it's questionable to draw conclusions from that.


 Don't fool yourself. You made a mistake. That's fine. Own and 
 fix it. Trying to make it look good is only making everything 
 worse.

 Any idea in this group will have a few enthusiasts, but here 
 you have the majority of the community complaining and the 
 three leaders Walter, Andrei, Martin tell you clear as rain you 
 are wrong. What and why are you arguing?


 Also, you need to contrast this to the amount of posts that 
 complained about JSON, or those that would have happened for a 
 different format choice.


 So let's add more. How does that logic work?

 Do you have an answer to the comment that the file format is 
 dead?


No he didn't make a mistake. He added a better alternative to 
JSON, because other people demanded. SDLang is very good format I 
prefer it to all other formats for this purpose. It is more 
readable than JSON and this ***all*** that matters.
I don't even know why people complain about it. No one forces 
them to use it.
The whole argument that you shouldn't use something, just because 
it is not popular is stupid. After all why are you even on this 
forum? D is not the most popular language. Other programming 
communities invent new DSLs everyday and this doesn't stop people 
from using those languages/libaries. Just look at the ruby 
ecosystem.
Nov 30 2015
parent reply terchestor <terchestor gmail.com> writes:
On Monday, 30 November 2015 at 17:06:56 UTC, ZombineDev wrote:

 On Monday, 30 November 2015 at 15:41:39 UTC, Tourist wrote:

 On Monday, 30 November 2015 at 15:12:13 UTC, Sönke Ludwig 
 wrote:

 The number of posts in this thread has multiple reasons, I'd 
 argue that it's questionable to draw conclusions from that.


 Don't fool yourself. You made a mistake. That's fine. Own and 
 fix it. Trying to make it look good is only making everything 
 worse.

 Any idea in this group will have a few enthusiasts, but here 
 you have the majority of the community complaining and the 
 three leaders Walter, Andrei, Martin tell you clear as rain 
 you are wrong. What and why are you arguing?


 Also, you need to contrast this to the amount of posts that 
 complained about JSON, or those that would have happened for 
 a different format choice.


 So let's add more. How does that logic work?

 Do you have an answer to the comment that the file format is 
 dead?


 No he didn't make a mistake. He added a better alternative to 
 JSON, because other people demanded.


The poll 
http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 
shows right now that 70% of 98 voters DISILIKE SDL.


 SDLang is very good format


Why does nobody use it then? Not even the peoples who introduced 
it use it.


 I prefer it to all other formats for this purpose. It is more 
 readable than JSON and this ***all*** that matters.


What is your largest SDL file? Please paste it so we can look for 
ourselves?


 I don't even know why people complain about it. No one forces 
 them to use it.


They complain because it's there and it should not be.


 The whole argument that you shouldn't use something, just 
 because it is not popular is stupid. After all why are you even 
 on this forum? D is not the most popular language. Other 
 programming communities invent new DSLs everyday and this 
 doesn't stop people from using those languages/libaries. Just 
 look at the ruby ecosystem.


Popularity is not the first argument.
Nov 30 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 17:18:50 UTC, terchestor wrote:

 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 
 shows right now that 70% of 98 voters DISILIKE SDL.


Well, most people who didn't object probably didn't bother to 
vote... What about just hashing it out in YAML? It would look 
like this:




name: my project
description: A little web service of mine.
authors:
     - Peter Parker
     - Spiderman
homepage: http://myproject.example.com
license: GPL-2.0
dependencies:
     vibe-d: ~>0.7.23
Nov 30 2015
next sibling parent terchestor <terchestor gmail.com> writes:
On Monday, 30 November 2015 at 17:53:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 30 November 2015 at 17:18:50 UTC, terchestor wrote:

 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 
 shows right now that 70% of 98 voters DISILIKE SDL.


 Well, most people who didn't object probably didn't bother to 
 vote... What about just hashing it out in YAML? It would look 
 like this:




 name: my project
 description: A little web service of mine.
 authors:
     - Peter Parker
     - Spiderman
 homepage: http://myproject.example.com
 license: GPL-2.0
 dependencies:
     vibe-d: ~>0.7.23


10 lines? I rest my case.
Nov 30 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 30 November 2015 at 17:53:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 30 November 2015 at 17:18:50 UTC, terchestor wrote:

 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 
 shows right now that 70% of 98 voters DISILIKE SDL.


 Well, most people who didn't object probably didn't bother to 
 vote... What about just hashing it out in YAML? It would look 
 like this:




 name: my project
 description: A little web service of mine.
 authors:
     - Peter Parker
     - Spiderman
 homepage: http://myproject.example.com
 license: GPL-2.0
 dependencies:
     vibe-d: ~>0.7.23


YAML takes spaces into account, doesn't it? That's a source of 
unnecessary, Pythonesque bugs.
Nov 30 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 18:02:34 UTC, Chris wrote:

 YAML takes spaces into account, doesn't it? That's a source of 
 unnecessary, Pythonesque bugs.


Most editors support YAML so you should get no Pythonesque bugs 
since they enforce WYSIWYG.  I have more issues with my 
handwritten JSON than YAML.

But there is nothing wrong in constraining the format as long as 
the resulting file is compatible.

http://www.yaml.org/spec/1.2/spec.html#Basic
Nov 30 2015
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 30 November 2015 at 18:13:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 30 November 2015 at 18:02:34 UTC, Chris wrote:

 YAML takes spaces into account, doesn't it? That's a source of 
 unnecessary, Pythonesque bugs.


 Most editors support YAML so you should get no Pythonesque bugs 
 since they enforce WYSIWYG.  I have more issues with my 
 handwritten JSON than YAML.

 But there is nothing wrong in constraining the format as long 
 as the resulting file is compatible.

 http://www.yaml.org/spec/1.2/spec.html#Basic


I once wrote a description in YAML. Spaces (or lack of them) lead 
to stupid errors. Not to mention the pain of copying and pasting 
with different indentation levels. If you have to use an editor 
to help you with indentation levels, there's something wrong, it 
means that it's not trivially easy.

When will people understand that indentation should not be part 
of a language's syntax?
Nov 30 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 18:23:08 UTC, Chris wrote:

 When will people understand that indentation should not be part 
 of a language's syntax?


Where is that norm coming from? :-) I my experience YAML is a 
very visually clean format for configuration. I use it for 
configuration files for websites.

As I mentioned, if you don't want tab issues, then just restrict 
the grammar so you have uniform indentation.
Nov 30 2015
prev sibling parent reply Luis <luis.panadero gmail.com> writes:
On Monday, 30 November 2015 at 17:53:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 30 November 2015 at 17:18:50 UTC, terchestor wrote:

 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 
 shows right now that 70% of 98 voters DISILIKE SDL.


 Well, most people who didn't object probably didn't bother to 
 vote... What about just hashing it out in YAML? It would look 
 like this:




 name: my project
 description: A little web service of mine.
 authors:
     - Peter Parker
     - Spiderman
 homepage: http://myproject.example.com
 license: GPL-2.0
 dependencies:
     vibe-d: ~>0.7.23


How do translate this example on SDLang ?

name "dedcpu"
authors "Luis Panadero Guardeño"
targetType "none"
license "BSD 3-clause"
description "DCPU-16 tools"

subPackage {
    name "lem1802"
    description "Visual LEM1802 font editor"
    targetType "executable"
    targetName "lem1802"
    excludedSourceFiles "src/bconv.d"
    excludedSourceFiles "src/ddis.d"
    libs "gtkd" platform="windows"

    configuration "nogtk" {
       platforms "windows"
    }

    configuration "gtk" {
       platforms "posix"
       dependency "gtk-d:gtkd" version="~>3.2.0"
    }
}
Nov 30 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 30 November 2015 at 18:07:20 UTC, Luis wrote:

 How do translate this example on SDLang ?


You can translate it by following these patterns:

http://www.yaml.org/spec/1.2/spec.html#Preview

As you see, you have some room for making it more dense if you 
want to. So you can tailor it a bit to your own taste.
Nov 30 2015
prev sibling parent Matt Soucy <msoucy csh.rit.edu> writes:
On 11/30/2015 01:07 PM, Luis wrote:

 name "dedcpu"
 authors "Luis Panadero Guarde=C3=B1o"
 targetType "none"
 license "BSD 3-clause"
 description "DCPU-16 tools"
=20
 subPackage {
    name "lem1802"
    description "Visual LEM1802 font editor"
    targetType "executable"
    targetName "lem1802"
    excludedSourceFiles "src/bconv.d"
    excludedSourceFiles "src/ddis.d"
    libs "gtkd" platform=3D"windows"
=20
    configuration "nogtk" {
       platforms "windows"
    }
=20
    configuration "gtk" {
       platforms "posix"
       dependency "gtk-d:gtkd" version=3D"~>3.2.0"
    }
 }


name: "dedcpu"
authors: "Luis Panadero Guarde=C3=B1o"
targetType: "none"
license: "BSD 3-clause"
description: "DCPU-16 tools"

subPackages:
  - name: "lem1802"
    description: "Visual LEM1802 font editor"
    targetType: "executable"
    targetName: "lem1802"
    excludedSourceFiles:
      - "src/bconv.d"
      - "src/ddis.d"
    libs:
      "gtkd": {"platform": "windows"}
    configurations:
      - name: "nogtk"
        platforms: ["windows"]
      - name: "gtk"
        platforms: ["posix"]
        dependencies:
          "gtk-d:gtkd": {"version": "~>3.2.0"}

One important thing to note is that any valid JSON object is also valid Y=
AML. This would have allowed a much cleaner upgrade path.

I have to argue this point nearly every semester - the courseware for cer=
tain courses here (disclaimer: I'm one of the maintainers) is open source=
 and relies on students submitting assignment links into a YAML file.

--=20
Matt Soucy
http://msoucy.me/
Dec 02 2015
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright 
wrote:


 1. JSON has a superset programming language - Javascript - 
 which has conventional syntax rather than the DEP4 proposal for 
 odd syntax like

     if dub-version="<0.9.24"

 which I would strongly recommend against. And, we already have 
 a Javascript engine written in D:

     https://github.com/DigitalMars/DMDScript


How do I make it work? DUB gives me errors.
Nov 27 2015
prev sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright 
wrote:

 "With a standard json parser in Phobos, zip zap boom you're 
 done. You don't have to design it, argue about it, build it, 
 document it, debug it, test it, optimize it, explain it, deal 
 with bug requests, deal with enhancement requests, deal with 
 legacy compatibility, build a converter, build a gui tool for 
 it, etc."


Believe it or not they we're designing their own. Ason, a 
superset of Json. Madness!

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
Nov 27 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 12:19:14 UTC, Gary Willoughby 
wrote:

 On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright 
 wrote:

 "With a standard json parser in Phobos, zip zap boom you're 
 done. You don't have to design it, argue about it, build it, 
 document it, debug it, test it, optimize it, explain it, deal 
 with bug requests, deal with enhancement requests, deal with 
 legacy compatibility, build a converter, build a gui tool for 
 it, etc."


 Believe it or not they we're designing their own. Ason, a 
 superset of Json. Madness!

 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


How many year can you get for ason*?

* The crime of maliciously, voluntarily, and willfully inventing 
a markup language.

:)))

Couldn't resist!
Nov 27 2015
prev sibling parent B.Basile <bb.temp gmx.com> writes:
On Thursday, 26 November 2015 at 19:05:46 UTC, Sönke Ludwig wrote:

 Just to mention one additional reason for choosing SDLang over 
 one of the more popular formats that shared some of the 
 advantages, there is an idea to add limited support for 
 (declarative) procedural statements: 
 https://github.com/D-Programming-Language/dub/wiki/DEP4#synopsis
 The representation possible with SDLang is not as good as in an 
 actual programming language, but far better than with any of 
 the JSON-like languages.


Awesome, it looks like a great idea. Particularly when DUB tends 
to already suck a bit to as for being handled by an IDE, this 
will probably solve everything !

Do you think that those that can't already use the describe 
command will ever be compatible with this ?
Nov 27 2015
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:

 Thanks,

 Sönke


Thank you (and others) for your time developing dub.

I don't understand any feelings for or against the 
configuration's format. From a maintainability perspective JSON 
wins, from readability SDL wins. Pick _one_. Move on.

Anytime I need to set some build settings for a project I need to 
lookup the options either way - then do copy paste.

The only thing missing is: `dub install package[ version]`; I 
never understood the absence of that feature.
Nov 26 2015
parent reply mattcoder <stop spam.com> writes:
On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe 
wrote:

 On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig 
 wrote:

 Thanks,

 Sönke


 Thank you (and others) for your time developing dub.

 I don't understand any feelings for or against the 
 configuration's format. From a maintainability perspective JSON 
 wins, from readability SDL wins. Pick _one_. Move on.
 ...


Yes man and like I said previously, this should be settled 
directly with developer, it is too much drama for such a small 
thing.

And thinking more about it, now I start to understand Linus 
Torvalds rants on code and I really think this community needs 
someone like him to shake up things, and stopping those nonsense 
complaints. :)

Matheus.
Nov 26 2015
parent reply wobbles <grogan.colin gmail.com> writes:
On Thursday, 26 November 2015 at 20:35:28 UTC, mattcoder wrote:

 On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe 
 wrote:

 On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig 
 wrote:

 Thanks,

 Sönke


 Thank you (and others) for your time developing dub.

 I don't understand any feelings for or against the 
 configuration's format. From a maintainability perspective 
 JSON wins, from readability SDL wins. Pick _one_. Move on.
 ...


 Yes man and like I said previously, this should be settled 
 directly with developer, it is too much drama for such a small 
 thing.

 And thinking more about it, now I start to understand Linus 
 Torvalds rants on code and I really think this community needs 
 someone like him to shake up things, and stopping those 
 nonsense complaints. :)

 Matheus.


We do, he's called Andrei!
Nov 26 2015
parent mattocoder <stop spam.com> writes:
On Thursday, 26 November 2015 at 20:47:18 UTC, wobbles wrote:

 On Thursday, 26 November 2015 at 20:35:28 UTC, mattcoder wrote:

 On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan 
 Koppe wrote:

 On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig 
 wrote:

 Thanks,

 Sönke


 Thank you (and others) for your time developing dub.

 I don't understand any feelings for or against the 
 configuration's format. From a maintainability perspective 
 JSON wins, from readability SDL wins. Pick _one_. Move on.
 ...


 Yes man and like I said previously, this should be settled 
 directly with developer, it is too much drama for such a small 
 thing.

 And thinking more about it, now I start to understand Linus 
 Torvalds rants on code and I really think this community needs 
 someone like him to shake up things, and stopping those 
 nonsense complaints. :)

 Matheus.


 We do, he's called Andrei!


Andrei is a gentleman compared to Linus in this case. :)

Matheus.
Nov 26 2015
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei 
Alexandrescu wrote:

 On 11/25/2015 02:02 PM, Walter Bright wrote:

 On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with 
 them much.


 That makes for an even less of a case for inventing a new file 
 format. I
 suppose it's water under the bridge, though.


 It's not. To DUB maintainers: this is a strategic error. Please 
 throw SDL away and use a standardized file format. -- Andrei


And in what domain is json considered a standardized 
-configuration- file format?
Nov 25 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 22:51:28 UTC, rsw0x wrote:

 On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei 
 Alexandrescu wrote:

 It's not. To DUB maintainers: this is a strategic error. 
 Please throw SDL away and use a standardized file format. -- 
 Andrei


 And in what domain is json considered a standardized 
 -configuration- file format?


I don't think that there's really _any_ format that qualifies as 
a standardized configuration file format, but JSON is a 
well-known, standardized format, whereas SDL really isn't. Plenty 
of programmers will be familiar with JSON even if they aren't 
familiar with what fields belong in a dub configuration file and 
what goes in them, but pretty much no one is going to know SDL. 
So, while SDL was not invented for dub, in terms of how 
well-known it will be to those new to dub, it might as well have 
been invented specifically for dub. With JSON, however, what will 
be new to most folks is what fields and values go in the 
configuration file, not the format that it's in.

So, from the standpoint of whether folks new to dub will have to 
learn a new file format, JSON is clearly better than SDL, though 
SDL may in fact be a better file format for a configuration file 
if you know both.

- Jonathan M Davis
Nov 25 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/2015 06:37 PM, Jonathan M Davis wrote:

 So, from the standpoint of whether folks new to dub will have to learn a
 new file format, JSON is clearly better than SDL, though SDL may in fact
 be a better file format for a configuration file if you know both.


That sums it up nicely.

I am sorry for being curt, but I really need to get work done and this 
is not getting work done. I could argue my point about SDL vs. JSON and 
explain at length what I think; then I could reply to folks who 
decompose my own points down to misplaced commas and attempt to do the 
same to them; and 300 posts later essentially nothing got done and 
everybody wasted a bunch of time.

Folks. Things could go either way, and there's pros and cons to every 
engineering decision. But we don't need to make this a debate. It took 
me 5 seconds to figure this was a strategy mistake. I clearly see how it 
could take someone else 5 seconds to figure this was a strategy win. 
They call those judgment calls because there's no clear cut. To the 
extent I've accumulated some street cred and karma in our community, I 
hope it can be traded for some saying in what the strategy should be. If 
that's the case, please let's get it carried. I can't afford to debate 
this tooth and nail because it takes me away from things that matter more.


Andrei
Nov 25 2015
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2015-11-25 at 19:06 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
[=E2=80=A6]

Re JSON vs SDL, switch to TOML, Rust did and it solved the Cargo
configuration situation "at a stroke".

--=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
Nov 27 2015
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 25 November 2015 at 23:37:20 UTC, Jonathan M Davis 
wrote:

 On Wednesday, 25 November 2015 at 22:51:28 UTC, rsw0x wrote:

 On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei 
 Alexandrescu wrote:

 It's not. To DUB maintainers: this is a strategic error. 
 Please throw SDL away and use a standardized file format. -- 
 Andrei


 And in what domain is json considered a standardized 
 -configuration- file format?


 I don't think that there's really _any_ format that qualifies 
 as a standardized configuration file format,


INI files are the closest thing to that. You probably have a lot 
of INI-like files in your /etc/.

Rust's Cargo uses TOML, which is a structured extension of INI.
Nov 26 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-11-26 09:33, Vladimir Panteleev wrote:


 INI files are the closest thing to that. You probably have a lot of
 INI-like files in your /etc/.

 Rust's Cargo uses TOML, which is a structured extension of INI.


I think Go uses TOML. I have at least seen several Go projects who're 
using. GitLab CI multi runner, for example.

[1] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner

-- 
/Jacob Carlborg
Nov 26 2015
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei 
Alexandrescu wrote:

 It's not. To DUB maintainers: this is a strategic error. Please 
 throw SDL away and use a standardized file format. -- Andrei


It's indeed a strategic error to bet on an arcane format, and the 
fact that the SDL website went down soon after adding SDL support 
just proves the point. But I don't think it's a big problem, we 
should simply add more parsers, e.g. yaml and toml, and let 
people use what they're comfortable with. Of course we'd still 
need to choose a default.
Nov 30 2015
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright 
wrote:

 On 11/25/2015 7:25 AM, Jonathan M Davis wrote:

 The files are very short, and you don't have to deal with them 
 much.


 That makes for an even less of a case for inventing a new file 
 format. I suppose it's water under the bridge, though.


I'm certainly not in favor of inventing a new file format, but 
since it _is_ used in a restricted context, even if it's a 
mistake, I don't expect that it'll cost us much. Honestly, if 
anything, I think that having multiple formats for dub config 
like we do is more confusing than using SDL.


 Note 1: json does support comments:

     "comment" : "this is a comment",


Well, that's potentially a good workaround, but it still isn't 
really a comment, and it assumes both that that's valid that part 
of the json file and that there isn't an actual field called 
comment that an application reading the file would expect. It 
likely works in most cases, but it is a hack brought on by a 
major defect in the JSON spec.

- Jonathan M Davis
Nov 25 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-25 20:02, Walter Bright wrote:


 Note 2: I intend to migrate the dmd.conf file format to json.


What's the gain here compared to the breakage it will cause?

-- 
/Jacob Carlborg
Nov 25 2015
next sibling parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 26/11/2015 6:45 PM, Jacob Carlborg wrote:

 On 2015-11-25 20:02, Walter Bright wrote:


 Note 2: I intend to migrate the dmd.conf file format to json.


 What's the gain here compared to the breakage it will cause?


We get to delete the non-boost INI parser from the frontend!
Nov 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-26 12:47, Daniel Murphy wrote:


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


How much trouble is that causing?

-- 
/Jacob Carlborg
Nov 26 2015
parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 27/11/2015 1:37 AM, Jacob Carlborg wrote:

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


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


 How much trouble is that causing?


None, it just annoys me.
Nov 26 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2015 7:49 AM, Daniel Murphy wrote:

 On 27/11/2015 1:37 AM, Jacob Carlborg wrote:

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


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


 How much trouble is that causing?


 None, it just annoys me.


I agree with Daniel on that point.
Nov 26 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 11:45 PM, Jacob Carlborg wrote:

 On 2015-11-25 20:02, Walter Bright wrote:

 Note 2: I intend to migrate the dmd.conf file format to json.


 What's the gain here compared to the breakage it will cause?


I recently spent some effort extending that format to support needed features. 
It would not have been necessary if it was in json. (The dmd.conf format has 
been extended multiple times in the past, and I expect it to be in the future. 
The extensions have also tended to be quick and dirty (and buggy) hackish 
changes because nobody wanted to spend any real time on it. Again, a problem 
solved by using json.)

The old format would still be read, it would just no longer get any
improvements.
Nov 26 2015
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright 
wrote:

 Note 2: I intend to migrate the dmd.conf file format to json.


Use D instead: 
http://forum.dlang.org/post/vjipqkoiktkfvmnbsfmv forum.dlang.org
The compiler already has everything to parse it.

As a side note json contains a fork of the unicode standard: 
disallows BOM. If you're looking for an invention, that would be 
json (worse, it's subtly incompatible).
Nov 26 2015
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


I say the bikeshed should be painted red! ;)

Seriously, it's a simple config format, who cares.  SDL looks 
just fine to me.

It would be nice if there was a converter that would translate 
all the config files from one format to the other and people like 
you could just set an option to have all your dub configs shown 
to you as json files.  You'd lose the comments, but you don't 
care for them anyway.

Converters like these would banish all these bikeshed arguments 
about code formatting or config formats, but what would we argue 
about then?  We'd have to start debating religion or politics. :)
Nov 25 2015
next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 25 November 2015 at 16:22:59 UTC, Joakim wrote:

 On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 [...]


 I say the bikeshed should be painted red! ;)

 Seriously, it's a simple config format, who cares.  SDL looks 
 just fine to me.

 It would be nice if there was a converter that would translate 
 all the config files from one format to the other and people 
 like you could just set an option to have all your dub configs 
 shown to you as json files.  You'd lose the comments, but you 
 don't care for them anyway.

 Converters like these would banish all these bikeshed arguments 
 about code formatting or config formats,


I agree.


 but what would we argue about then?  We'd have to start 
 debating religion or politics. :)


No, not here, please :-) If a programming concept turns out to be 
crap, at least no-one got killed because of it! Only some egos 
got hurt here and there.
Nov 25 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-11-25 17:22, Joakim wrote:


 Converters like these would banish all these bikeshed arguments about
 code formatting or config formats, but what would we argue about then?
 We'd have to start debating religion or politics. :)


I'm sure there are a lot of other bikesheds that need (re)painting :)

-- 
/Jacob Carlborg
Nov 26 2015
prev sibling next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


I very much prefer SDLang. It's more intuitive, easier to read, 
less verbose, and supports real comments.

Here's a link to the original discussion: 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

The examples of JSON vs YAML vs SDLang immediately convinced me 
SDLang was the way to go. It doesn't make sense to force everyone 
to use the worst of the three just because it's popular in web 
development. Further, JSON is still supported and will continue 
to be supported. Tools should be querying dub directly instead of 
trying to read the package format.
Nov 25 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson 
wrote:

 Tools should be querying dub directly instead of trying to read 
 the package format.


Shouldn't this be true of writing it too? Like I said on irc 
earlier today, I actually kinda think we should have some kind of 
gui for it, or at least a command suite (like `dub add-dependency 
foo` maybe, idk) so the file itself never needs to be touched 
directly by users for common tasks.
Nov 25 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 25 November 2015 at 19:29:43 UTC, Adam D. Ruppe 
wrote:

 On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson 
 wrote:

 Tools should be querying dub directly instead of trying to 
 read the package format.


 Shouldn't this be true of writing it too? Like I said on irc 
 earlier today, I actually kinda think we should have some kind 
 of gui for it, or at least a command suite (like `dub 
 add-dependency foo` maybe, idk) so the file itself never needs 
 to be touched directly by users for common tasks.


While having a GUI might be nice, we're talking about a config 
file here. This is exactly the sort of thing that's normally 
edited by hand. It should be both writable and readable by both 
programmers and programs.

- Jonathan M Davis
Nov 25 2015
parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/25/15 11:40 AM, Jonathan M Davis via Digitalmars-d wrote:

 On Wednesday, 25 November 2015 at 19:29:43 UTC, Adam D. Ruppe wrote:

 On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson wrote:

 Tools should be querying dub directly instead of trying to read the package
format.


 Shouldn't this be true of writing it too? Like I said on irc earlier today, I
actually kinda think
 we should have some kind of gui for it, or at least a command suite (like `dub
add-dependency foo`
 maybe, idk) so the file itself never needs to be touched directly by users for
common tasks.


 While having a GUI might be nice, we're talking about a config file here. This
is exactly the sort
 of thing that's normally edited by hand. It should be both writable and
readable by both programmers
 and programs.

 - Jonathan M Davis


I'm not well steeped in the DUB eco-system, but isn't it more than just a
config file?  It's really 
more of an interface file, right?  Config files are internal to apps, and this
is shared between 
packages and the central registry.

For those saying that one should use DUB as the only access method to this
date, are you serious? 
People (and applications) should have to execute an app to interrogate the data
store?  Can you name 
a few other config files you do that with?  One of the only ones I can think of
is the windows 
registry, and that's an api, not an app.

Later,
Brad
Nov 25 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 11:29 AM, Adam D. Ruppe wrote:

 On Wednesday, 25 November 2015 at 19:18:25 UTC, Brad Anderson wrote:

 Tools should be querying dub directly instead of trying to read the package
 format.


 Shouldn't this be true of writing it too? Like I said on irc earlier today, I
 actually kinda think we should have some kind of gui for it, or at least a
 command suite (like `dub add-dependency foo` maybe, idk) so the file itself
 never needs to be touched directly by users for common tasks.


And the cost of inventing a new file format just grew by another order of
magnitude.

I should add "need a special gui editing tool" to my list of reasons not to 
invent another file format.
Nov 25 2015
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 November 2015 at 20:08:13 UTC, Walter Bright 
wrote:

 And the cost of inventing a new file format just grew by 
 another order of magnitude.

 I should add "need a special gui editing tool" to my list of 
 reasons not to invent another file format.


The benefits of a gui are separate from the physical file format. 
It helps you get the semantics right primarily, secondarily it 
helps you navigate the ecosystem (the code.dlang.org website does 
this too). Only tertiary does it makes the file format 
irrelevant, but the main goal of them is to guide you through the 
process of creating a valid configuration that makes sense for 
you.
Nov 25 2015
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 November 2015 at 20:08:13 UTC, Walter Bright 
wrote:

 reasons not to invent another file format.


BTW this is really a straw-man: the SDLang was *not* invented by 
the vibe.d team.
Nov 25 2015
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


I made my thoughts clear in the original discussion. Please dump 
SDL and just use Json.

Json is clear, concise, everyone and his dog knows it and their 
IDE recognises it.
Nov 25 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/25/2015 1:03 PM, Gary Willoughby wrote:

 Json is clear, concise, everyone and his dog knows it and their IDE recognises
it.


Yes. Trying to convince people to use D is hard enough without dumping a whole 
bunch of other unfamiliar formats on them.
Nov 25 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-25 11:17, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do not want to
 spend time in learning yet another dead config format that now use only
 one project -- DUB. In time when DUB used json it was not perfect, but
 at last it was standard and everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past of
 dependence. I need go to docs page, and read how to include it.

 Also I do not see any projects that are migrate to SDL. Everybody
 continue to use JSON. So please, return JSON back as default, or very
 soon we will see that nobody do not submit packages to code.dlang.org
 and nobody do not use DUB for their own projects.

 Please vote about SDL config format
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other build
 system or will downgrade to old version of DUB.


BTW, why was not TOML [1] chosen? I know it was discussed but I can't 
remember why SDL was preferred. I think TOML is more widely used than 
SDL [2]. GitLib CI multi runner is also using it.

[1] https://github.com/toml-lang/toml
[2] https://github.com/toml-lang/toml#projects-using-toml

-- 
/Jacob Carlborg
Nov 26 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg 
wrote:

 On 2015-11-25 11:17, Suliman wrote:

 [...]


 BTW, why was not TOML [1] chosen? I know it was discussed but I 
 can't remember why SDL was preferred. I think TOML is more 
 widely used than SDL [2]. GitLib CI multi runner is also using 
 it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
maintain a parser for a format that hasn't "settled down" yet.
Nov 26 2015
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 26 Nov 2015 12:43:52 +0000
Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg 
 wrote:

 On 2015-11-25 11:17, Suliman wrote:  

 [...]  


 BTW, why was not TOML [1] chosen? I know it was discussed but I 
 can't remember why SDL was preferred. I think TOML is more 
 widely used than SDL [2]. GitLib CI multi runner is also using 
 it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml  


 
 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
 maintain a parser for a format that hasn't "settled down" yet.


Ok, but we can afford to mantain a parser for a dead format?
https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
Nov 26 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
 wrote:

 On 2015-11-25 11:17, Suliman wrote:

 [...]


 BTW, why was not TOML [1] chosen? I know it was discussed but I
 can't remember why SDL was preferred. I think TOML is more
 widely used than SDL [2]. GitLib CI multi runner is also using
 it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
 maintain a parser for a format that hasn't "settled down" yet.


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language


BAM!! *Daniel drops mike, walks way*


(well said)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Nov 26 2015
next sibling parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros 
wrote:

 On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
 wrote:

 [...]


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
 maintain a parser for a format that hasn't "settled down" yet.


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language


 BAM!! *Daniel drops mike, walks way*


 (well said)


Isn't it easier to maintain a parser for a dead format than a 
living one? You know it won't change ... after all, its dead!
Nov 26 2015
next sibling parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
V Thu, 26 Nov 2015 22:27:06 +0000
CraigDillabaugh via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros 
 wrote:

 On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:  

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:
  

 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
 wrote:  

 [...]  


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
 maintain a parser for a format that hasn't "settled down" yet.  


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
  


 BAM!! *Daniel drops mike, walks way*


 (well said)  


 
 Isn't it easier to maintain a parser for a dead format than a 
 living one? You know it won't change ... after all, its dead!


You can still maintain  selected version (0.4 in toml for example).

Maintaining parser for dead language where is not easy to find out specs
is definitely not easier :).
Nov 26 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 00:39:12 UTC, Daniel Kozák wrote:

 V Thu, 26 Nov 2015 22:27:06 +0000
 CraigDillabaugh via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:


 On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros 
 wrote:

 On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:
 

 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob 
 Carlborg wrote:

 [...]


 TOML looks nice, _but_ it's version 0.4.0. We cannot 
 afford to maintain a parser for a format that hasn't 
 "settled down" yet.


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
 


 BAM!! *Daniel drops mike, walks way*


 (well said)


 
 Isn't it easier to maintain a parser for a dead format than a 
 living one? You know it won't change ... after all, its dead!


 You can still maintain  selected version (0.4 in toml for 
 example).


Yes. I thought about that too. But guess what happens next. 
People will say "TOML 0.5 has this really nice feature, why don't 
we have it in DUB yet?" and "Why is DUB still at TOML 0.4 while 
we already have TOML 0.6? No wonder D will never be as successful 
as PHP/Java/Ruby/Python!"

Be realistic. It sounds great in theory, but we will play catch 
up just like we do with DMD vs. GDC/LDC. And for a what?

As I said TOML looks good, but it's not worth the hassle at the 
moment. It can still be done further down the road.


 Maintaining parser for dead language where is not easy to find 
 out specs is definitely not easier :).


If it's dead, it won't change.
Nov 27 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 26 November 2015 at 22:27:08 UTC, CraigDillabaugh 
wrote:

 On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros 
 wrote:

 On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
 wrote:

 [...]


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford 
 to
 maintain a parser for a format that hasn't "settled down" 
 yet.


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language


 BAM!! *Daniel drops mike, walks way*


 (well said)


 Isn't it easier to maintain a parser for a dead format than a 
 living one? You know it won't change ... after all, its dead!


Err, that's what I thought too. It won't change anymore, if it's 
dead, right? Also, in the case of SDL, the parser has already 
been written, for better or worse. But in the case of TOML, time 
would be spent on _yet another markup language_, and for what? 
Once D takes off we can think about these things. Atm, they're 
not really important. Our house doesn't stand properly yet and 
we're discussing effin bikesheds.
Nov 27 2015
parent reply wobbles <grogan.colin gmail.com> writes:
On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:

 Our house doesn't stand properly yet and we're discussing effin 
 bikesheds.


+10

Everyones opinion is different, no one is right, no one is wrong 
- It's all just opinion.

The only thing it's served to do is piss off a very important 
contributor to the D ecosystem.

None of this thread matters - can we move on?
Nov 27 2015
parent reply wobbles <grogan.colin gmail.com> writes:
On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:

 On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:

 Our house doesn't stand properly yet and we're discussing 
 effin bikesheds.


 +10

 Everyones opinion is different, no one is right, no one is 
 wrong - It's all just opinion.

 The only thing it's served to do is piss off a very important 
 contributor to the D ecosystem.

 None of this thread matters - can we move on?


"It" being this thread.
Nov 27 2015
parent reply B.Basile <bb.temp gmx.com> writes:
On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:

 On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:

 On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:

 Our house doesn't stand properly yet and we're discussing 
 effin bikesheds.


 +10

 Everyones opinion is different, no one is right, no one is 
 wrong - It's all just opinion.

 The only thing it's served to do is piss off a very important 
 contributor to the D ecosystem.

 None of this thread matters - can we move on?


 "It" being this thread.


It also unleashes some critism people wouldn't have formulate 
otherwise.

And contrary to what people say, I think such topics give a 
dynamic aspect to the NG. Such topics are in a sense recreative 
and pleasant (fun) to read. The only thing to get is that this is 
not so serious.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 14:04:26 UTC, B.Basile wrote:

 On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:

 On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:

 On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:

 Our house doesn't stand properly yet and we're discussing 
 effin bikesheds.


 +10

 Everyones opinion is different, no one is right, no one is 
 wrong - It's all just opinion.

 The only thing it's served to do is piss off a very important 
 contributor to the D ecosystem.

 None of this thread matters - can we move on?


 "It" being this thread.


 It also unleashes some critism people wouldn't have formulate 
 otherwise.

 And contrary to what people say, I think such topics give a 
 dynamic aspect to the NG. Such topics are in a sense recreative 
 and pleasant (fun) to read. The only thing to get is that this 
 is not so serious.


If anything, this thread shows that there has to be more 
communication between the developers. It's detrimental, when 
discontent builds up behind the scenes only to erupt suddenly 
over a minor issue.

There are two things at loggerheads here: a) the call for strong 
leadership and b) the desire to make decisions based on open 
discussions within the community.

It's certainly not easy to find the right balance, which is why 
better communication is of utmost importance. The odd email might 
help to get people out of their bikesheds to discuss the color of 
the door.
Nov 27 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:

 There are two things at loggerheads here: a) the call for 
 strong leadership and b) the desire to make decisions based on 
 open discussions within the community.

 It's certainly not easy to find the right balance, which is why 
 better communication is of utmost importance.


What balance? Discussion is the way to communicate leadership, 
i.e. to make things work without micromanagement.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 15:04:15 UTC, Kagamin wrote:

 On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:

 There are two things at loggerheads here: a) the call for 
 strong leadership and b) the desire to make decisions based on 
 open discussions within the community.

 It's certainly not easy to find the right balance, which is 
 why better communication is of utmost importance.


 What balance? Discussion is the way to communicate leadership, 
 i.e. to make things work without micromanagement.


Yes. But a (well-informed) decision has to be made at some point. 
And it's the leaders who have to make them. I often find myself 
agreeing with both sides, I'd be terrible at making decisions.
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:

 Yes. But a (well-informed) decision has to be made at some 
 point. And it's the leaders who have to make them. I often find 
 myself agreeing with both sides, I'd be terrible at making 
 decisions.


It is terribly expensive to postpone the decision making to after 
the design process.

If you didn't participate in the design process... then you 
essentially delegated responsibility, and then it is your own 
responsibility to back whatever they did as long as it isn't 
completely unreasonable.

Or else your own ass are on fire because you failed to 
participate and lead (and you should be dismantled as a leader).

Right?
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 15:29:38 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:

 Yes. But a (well-informed) decision has to be made at some 
 point. And it's the leaders who have to make them. I often 
 find myself agreeing with both sides, I'd be terrible at 
 making decisions.


 It is terribly expensive to postpone the decision making to 
 after the design process.


That's why I said that (timely) communication is of utmost 
importance. Post factum decisions are bound to cause trouble.


 If you didn't participate in the design process... then you 
 essentially delegated responsibility, and then it is your own 
 responsibility to back whatever they did as long as it isn't 
 completely unreasonable.

 Or else your own ass are on fire because you failed to 
 participate and lead (and you should be dismantled as a leader).

 Right?
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:

 That's why I said that (timely) communication is of utmost 
 importance. Post factum decisions are bound to cause trouble.


Yes, I agree. So then one should just stand by whatever the 
maintainer has chosen, because he is more likely to have 
considered what is needed in terms of current and future needs.

What do people need to write their puny config files? A webpage 
with typical examples, commented and explained. Cut'n'paste.

Besides that, javascript is a horrible format for hand editing. 
In fact, any curly braced format is bad. Misplace one brace and 
things break in hard to figure out ways.

This is what is good about XML, the end markers are clear and 
makes automatic resolution possible even in loose grammars. I'll 
never really understand why people consistently fail to 
understand why SGML is designed the way it is.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 15:49:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:

 That's why I said that (timely) communication is of utmost 
 importance. Post factum decisions are bound to cause trouble.


 Yes, I agree. So then one should just stand by whatever the 
 maintainer has chosen, because he is more likely to have 
 considered what is needed in terms of current and future needs.


Basically yes. But if it concerns "offical D" things should be 
synchronized better.


 What do people need to write their puny config files? A webpage 
 with typical examples, commented and explained. Cut'n'paste.

 Besides that, javascript is a horrible format for hand editing. 
 In fact, any curly braced format is bad. Misplace one brace and 
 things break in hard to figure out ways.

 This is what is good about XML, the end markers are clear and 
 makes automatic resolution possible even in loose grammars. 
 I'll never really understand why people consistently fail to 
 understand why SGML is designed the way it is.
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:

 Basically yes. But if it concerns "offical D" things should be 
 synchronized better.


Maybe defining what the inclusion process for "official D" is and 
set down policies for decision making processes and quality 
assurance for those projects that are included, then?

But what D really needs is to complete the language spec and 
clean up the core language.

No other activity will matter in the long run, IMO.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 16:27:07 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:

 Basically yes. But if it concerns "offical D" things should be 
 synchronized better.


 Maybe defining what the inclusion process for "official D" is 
 and set down policies for decision making processes and quality 
 assurance for those projects that are included, then?


Yep. Something along these lines.


 But what D really needs is to complete the language spec and 
 clean up the core language.

 No other activity will matter in the long run, IMO.


DUB does matter, because it's the official package manager and is 
used by developers and will likely be used by newcomers too. It 
should offer as good a user experience as possible.
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 16:32:57 UTC, Chris wrote:

 DUB does matter, because it's the official package manager and 
 is used by developers and will likely be used by newcomers too. 
 It should offer as good a user experience as possible.


Yes, it isn't irrelevant and end users should of course express 
where it cause them head aches it it does.

However, it does not affect adoption. I don't think high quality 
libraries will be held back from publication over a config 
format. Maybe some shitty ones with an uncertain lifespan (and 
good riddance for that).

A config format is not difficult to replace or convert into 
another format at a later stage, especially if it is hosted 
centrally (just have a different request protocol for the new 
format).

---

The real question is: how much money (time) can one afford to 
spend on fringe activities and mutation when the core issues that 
need attention are costly (time) to fix?

Priorities.

I've noticed that non-commercial Open Source projects often 
appear to not understand that they have a limited implicit budget 
(hours and goodwill).

C++, Go, Rust, Swift, TypeScript and Dart are all pretty 
commercially driven projects. They can waste volunteer resources 
without consequences.

The current D priorities seems to be:
- C++ exception handling
- More containers
- Config file format

Neither are likely to have a significant impact.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 16:48:26 UTC, Ola Fosheim Grøstad 
wrote:


 Yes, it isn't irrelevant and end users should of course express 
 where it cause them head aches it it does.

 However, it does not affect adoption. I don't think high 
 quality libraries will be held back from publication over a 
 config format. Maybe some shitty ones with an uncertain 
 lifespan (and good riddance for that).


I don't agree. It might really affect adoption. Mind you, people 
are easily put off, if things don't work out of the box, 
especially in the case of D. "Weird config format" would be one 
of those reasons / excuses not to use D. I bet you! It would 
certainly get mentioned in some tech article about D.


[snip]
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 16:53:35 UTC, Chris wrote:

 especially in the case of D. "Weird config format" would be one 
 of those reasons / excuses not to use D. I bet you! It would 
 certainly get mentioned in some tech article about D.


JSON falls into the same category.

Newbies want things to work out of the box, as in "make all" 
without errors. When you need to figure out a config format then 
you are already entrenched.
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 17:05:18 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 16:53:35 UTC, Chris wrote:

 especially in the case of D. "Weird config format" would be 
 one of those reasons / excuses not to use D. I bet you! It 
 would certainly get mentioned in some tech article about D.


 JSON falls into the same category.

 Newbies want things to work out of the box, as in "make all" 
 without errors. When you need to figure out a config format 
 then you are already entrenched.


DUB works out of the box. dub init myproject.
Nov 27 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:

 DUB works out of the box. dub init myproject.


Wasn't smack-talking DUB. Just pointing out that any type of 
modification of a config file is a turnoff for a newbie, no 
matter what format it is in.

(and for me and many others JSON would be a massive turn-off)
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:

 DUB works out of the box. dub init myproject.


 Wasn't smack-talking DUB. Just pointing out that any type of 
 modification of a config file is a turnoff for a newbie, no 
 matter what format it is in.

 (and for me and many others JSON would be a massive turn-off)


But JSON is widely used and chances are that people are already 
familiar with it. If not, it's easy to learn, there are loads of 
resources. 3rd party tools can easily parse it. And hey, it's not 
that bad. XML is a lot worse as regards human readability. 
However, I will for the life of me never understand why comments 
were not included.
Nov 27 2015
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:

 On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim 
 Grøstad wrote:

 On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:

 DUB works out of the box. dub init myproject.


 Wasn't smack-talking DUB. Just pointing out that any type of 
 modification of a config file is a turnoff for a newbie, no 
 matter what format it is in.

 (and for me and many others JSON would be a massive turn-off)


 But JSON is widely used and chances are that people are already 
 familiar with it. If not, it's easy to learn, there are loads 
 of resources. 3rd party tools can easily parse it. And hey, 
 it's not that bad. XML is a lot worse as regards human 
 readability. However, I will for the life of me never 
 understand why comments were not included.


json is not a configuration file format
Nov 27 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 18:31:19 UTC, rsw0x wrote:

 On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:

 On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim 
 Grøstad wrote:

 [...]


 But JSON is widely used and chances are that people are 
 already familiar with it. If not, it's easy to learn, there 
 are loads of resources. 3rd party tools can easily parse it. 
 And hey, it's not that bad. XML is a lot worse as regards 
 human readability. However, I will for the life of me never 
 understand why comments were not included.


 json is not a configuration file format


It's a data exchange format, and it can be used for many purposes.
Nov 27 2015
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:

 But JSON is widely used and chances are that people are already 
 familiar with it. If not, it's easy to learn, there are loads 
 of resources. 3rd party tools can easily parse it. And hey, 
 it's not that bad.


Well, many are familiar with JSON, and I use it all the time, but 
it is not a good or readable format. It is just something 
browsers have builtin, that's the only thing it has going for it.


 XML is a lot worse as regards human readability.


I think not. It is all about familiarity and if the grammar has 
been designed for it. I find my own XML _much_ more readable than 
JSON. And much easier to eXtend.

If you use a decent XML editor and have a schema for the grammar 
then you get a really nice generic editing solution with 
auto-completion.

Here is one very real advantage of XML: the ability to embed 
standard markup in descriptions and use one "container format" 
for all future non-D data.

I think the animosity against XML is misguided.

But if XML is out, then YAML is a good expressive alternative 
(that can be translated into XML, so you can use both if you want 
to).

JSON is very limiting and not a future proof solution. People who 
pick JSON for configuration, probably also pick Php for their 
website. ;^)
Nov 27 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 18:58:12 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:

 But JSON is widely used and chances are that people are 
 already familiar with it. If not, it's easy to learn, there 
 are loads of resources. 3rd party tools can easily parse it. 
 And hey, it's not that bad.


 Well, many are familiar with JSON, and I use it all the time, 
 but it is not a good or readable format. It is just something 
 browsers have builtin, that's the only thing it has going for 
 it.


 XML is a lot worse as regards human readability.


 I think not. It is all about familiarity and if the grammar has 
 been designed for it. I find my own XML _much_ more readable 
 than JSON. And much easier to eXtend.

 If you use a decent XML editor and have a schema for the 
 grammar then you get a really nice generic editing solution 
 with auto-completion.

 Here is one very real advantage of XML: the ability to embed 
 standard markup in descriptions and use one "container format" 
 for all future non-D data.

 I think the animosity against XML is misguided.

 But if XML is out, then YAML is a good expressive alternative 
 (that can be translated into XML, so you can use both if you 
 want to).

 JSON is very limiting and not a future proof solution. People 
 who pick JSON for configuration, probably also pick Php for 
 their website. ;^)


At the end of the day, all markup, data exchange or description 
languages are not easy on the eye. It's a question of "which is 
worse", and that's often a question of personal taste.

I'm sure that we would have a similar discussion, if we had YAML, 
XML, TOML or whatever. It doesn't really matter. But what does 
matter is that we use a well known standardized format.

I think the point to take home is that communication has to work 
better between the D core and its (official) satellites.
Nov 27 2015
next sibling parent reply Minas Mina <minas_0 hotmail.co.uk> writes:
SDLang is fine. If someone wants to use D, it won't be SDLang 
that will stop him.

Keep calm and use SDLang.
Nov 27 2015
parent reply terchestor <terchestor gmail.com> writes:
On Friday, 27 November 2015 at 20:16:20 UTC, Minas Mina wrote:

 SDLang is fine. If someone wants to use D, it won't be SDLang 
 that will stop him.

 Keep calm and use SDLang.


No. STDLang is a terrible idea. Walter's arguments are right on. 
Drop the drama and stop complaining you are not micromanaged out 
of terrible ideas.
Nov 27 2015
parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Friday, 27 November 2015 at 22:05:05 UTC, terchestor wrote:

 On Friday, 27 November 2015 at 20:16:20 UTC, Minas Mina wrote:

 SDLang is fine. If someone wants to use D, it won't be SDLang 
 that will stop him.

 Keep calm and use SDLang.


 No. STDLang is a terrible idea. Walter's arguments are right on.


He argued that {"comment":"blabla"} is a comment, and the sad 
thing is he's serious. That's a really shocking thing from 
someone like him!

And then he suggested we could just use a standard JSON parses, 
totally ignoring the reasons SDL was introduced in the first 
place, namely that comments can't be used in standard JSON, and 
it forces commas and braces all over the place while disallowing 
trailing commas.

The third argument I've seen from him boils down to that it's an 
uncommon format (although at first he claimed it was invented for 
DUB, which is clearly wrong). While this may be a legitimate 
concern, it is a very minor one IMO.

So, how can you conclude these arguments "are right on"? In fact, 
they're at best unimportant, but mostly non-sensical or based on 
wrong assumptions.
Nov 29 2015
next sibling parent reply bubbasaur <bubbasaul hotmail.com> writes:
So we reached +200 replies...

I'm here wondering if you will keep going with all this drama 
about this config format, remembering that you can choose one if 
you don't like the other.

And all this drama while this group is small, I'm imagining what 
happens on a large group or language like the C++...

Bubba.
Nov 29 2015
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Again, it is not only about selecting config format. For me the main
problem is to have more than one format.
Dne 29. 11. 2015 16:51 napsal u=C5=BEivatel "bubbasaur via Digitalmars-d" <
digitalmars-d puremagic.com>:


 So we reached +200 replies...

 I'm here wondering if you will keep going with all this drama about this
 config format, remembering that you can choose one if you don't like the
 other.

 And all this drama while this group is small, I'm imagining what happens
 on a large group or language like the C++...

 Bubba.
Nov 29 2015
prev sibling parent Gordon <me home.com> writes:
On Sunday, 29 November 2015 at 13:21:33 UTC, Marc Schütz wrote:

 On Friday, 27 November 2015 at 22:05:05 UTC, terchestor wrote:

 On Friday, 27 November 2015 at 20:16:20 UTC, Minas Mina wrote:

 SDLang is fine. If someone wants to use D, it won't be SDLang 
 that will stop him.

 Keep calm and use SDLang.


 No. STDLang is a terrible idea. Walter's arguments are right 
 on.


 He argued that {"comment":"blabla"} is a comment, and the sad 
 thing is he's serious. That's a really shocking thing from 
 someone like him!


This argument make perfect sense. It's 30 freaking lines. A 
simple workaround is just enough. It is shocking you don't get it.


 And then he suggested we could just use a standard JSON parses, 
 totally ignoring the reasons SDL was introduced in the first 
 place, namely that comments can't be used in standard JSON, and 
 it forces commas and braces all over the place while 
 disallowing trailing commas.


Yeah, totally great reasons those were. We don't have nice 
comments for this *very* *small* file. I know! I know! Let's use 
a different language, preferably one that nobody else cares to!


 The third argument I've seen from him boils down to that it's 
 an uncommon format (although at first he claimed it was 
 invented for DUB, which is clearly wrong). While this may be a 
 legitimate concern, it is a very minor one IMO.

 So, how can you conclude these arguments "are right on"? In 
 fact, they're at best unimportant, but mostly non-sensical or 
 based on wrong assumptions.


Your lack of common sense and basic engineering mindset is 
appaling.
Nov 29 2015
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 19:42:43 UTC, Chris wrote:

 At the end of the day, all markup, data exchange or description 
 languages are not easy on the eye. It's a question of "which is 
 worse", and that's often a question of personal taste.


Yes, syntax is rather personal! Some GNU people want Lisp as the 
universal config format + scripting language (guile)... I 
understand their motivation and reasoning, but I don't want it... 
8-)

But technical merits and tooling is  a more objective criteria, 
and right now XML and all the associated standards provides best 
interop, ability to describe the content to non DUB tools on a 
meta level, transforms, queries, etc.


 I'm sure that we would have a similar discussion, if we had 
 YAML, XML, TOML or whatever. It doesn't really matter. But what 
 does matter is that we use a well known standardized format.


Just define a canonical XML format for advanced use, which is 
used internally and for interchange, then provide the common 
stuff as easy-to-read YAML / JSON. That way 90% can use the easy 
version, and all advanced or experimental 
shoot-yourself-in-the-foot functionality is hidden from newbies.

The DUB tooling would just generate the XML from the newbie 
format.

One can have it both ways. :)
Nov 27 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 27 November 2015 at 19:42:43 UTC, Chris wrote:

 I'm sure that we would have a similar discussion, if we had 
 YAML, XML, TOML or whatever. It doesn't really matter. But what 
 does matter is that we use a well known standardized format.


Then XML is clear winner, its support, spread, availability and 
tooling is unmatched.
Nov 28 2015
parent reply BLM768 <blm768 gmail.com> writes:
On Saturday, 28 November 2015 at 18:13:51 UTC, Kagamin wrote:

 Then XML is clear winner, its support, spread, availability and 
 tooling is unmatched.


So is its complexity. ;)

Do we even have a good standard XML parser? std.xml has been 
languishing for years...
Nov 28 2015
parent Kagamin <spam here.lot> writes:
On Saturday, 28 November 2015 at 21:49:07 UTC, BLM768 wrote:

 Do we even have a good standard XML parser? std.xml has been 
 languishing for years...


AFAIK, good json parser is still in a review queue together with 
std.xml2 :)
Nov 28 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:


 If anything, this thread shows that there has to be more 
 communication between the developers. It's detrimental, when 
 discontent builds up behind the scenes only to erupt suddenly 
 over a minor issue.

 There are two things at loggerheads here: a) the call for 
 strong leadership and b) the desire to make decisions based on 
 open discussions within the community.

 It's certainly not easy to find the right balance, which is why 
 better communication is of utmost importance. The odd email 
 might help to get people out of their bikesheds to discuss the 
 color of the door.


My _personal_ impression is that projects like DUB that are not 
part of DLang, but are part of "offical D", are not tied fast 
enough to official D. If we find a strategy to tie anything that 
is part of "official D", but may live in a separate repos, faster 
to D, threads like this can be avoided.

Peace pipe?
Nov 27 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2015 2:27 PM, CraigDillabaugh wrote:

 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language


 BAM!! *Daniel drops mike, walks way*
 (well said)


 Isn't it easier to maintain a parser for a dead format than a living one? You
 know it won't change ... after all, its dead!



https://www.youtube.com/watch?v=Jdf5EXo6I68&feature=player_detailpage#t=50
Nov 27 2015
prev sibling parent reply Gordon <me home.com> writes:
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros 
wrote:

 On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:

 V Thu, 26 Nov 2015 12:43:52 +0000
 Chris via Digitalmars-d <digitalmars-d puremagic.com> napsáno:


 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
 wrote:

 On 2015-11-25 11:17, Suliman wrote:

 [...]


 BTW, why was not TOML [1] chosen? I know it was discussed 
 but I
 can't remember why SDL was preferred. I think TOML is more
 widely used than SDL [2]. GitLib CI multi runner is also 
 using
 it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
 maintain a parser for a format that hasn't "settled down" yet.


 Ok, but we can afford to mantain a parser for a dead format?
 https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language


 BAM!! *Daniel drops mike, walks way*


 (well said)


Very well indeed. Sonke needs to respond to this.

By Sonkes own admission json does everything we need except 
comments. These configuration files are what 50 lines long? And 
there is an easy workaround. Seriously our problem we dont have 
nice comments for tiny files? So lets use a language nobody else 
wants to use? How dod we get to this point?

Andrei is an ass sometimes. But his point is valid. Now we have 
Sonke all offended but do not mix it the technical point. And of 
course Douchebot had to come out of the woodwork. Worst thing 
about D leadership is they didn't rid the community of persons 
like him. But that should not detract from the main point - SDL 
is a bad decision any way you look at it. It should be undone.
Nov 27 2015
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 27 November 2015 at 16:23:46 UTC, Gordon wrote:

 [snip]


Please no personal attacks on these forums. Keep it civil.
Nov 27 2015
parent terchestor <terchestor gmail.com> writes:
On Saturday, 28 November 2015 at 02:01:36 UTC, Vladimir Panteleev 
wrote:

 On Friday, 27 November 2015 at 16:23:46 UTC, Gordon wrote:

 [snip]


 Please no personal attacks on these forums. Keep it civil.


Why not tell that to Dicebot? He spends half his time being a 
drama queen and spends the other half attacking other people.
Nov 27 2015
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:

 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
 maintain a parser for a format that hasn't "settled down" yet.


Why not use a well defined subset of YAML then?
Nov 26 2015
next sibling parent Suliman <evermind live.ru> writes:
On Thursday, 26 November 2015 at 13:10:30 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:

 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
 maintain a parser for a format that hasn't "settled down" yet.


 Why not use a well defined subset of YAML then?


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

TOML is harder to read, and write bu hands.
Nov 26 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-11-26 14:10, Ola Fosheim Grøstad wrote:


 Why not use a well defined subset of YAML then?


I think that's perfectly fine as well.

-- 
/Jacob Carlborg
Nov 26 2015
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:

 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg 
 wrote:

 On 2015-11-25 11:17, Suliman wrote:

 [...]


 BTW, why was not TOML [1] chosen? I know it was discussed but 
 I can't remember why SDL was preferred. I think TOML is more 
 widely used than SDL [2]. GitLib CI multi runner is also using 
 it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
 maintain a parser for a format that hasn't "settled down" yet.


If it's good enough for Rust, it's good enough for us.
Nov 26 2015
parent Chris <wendlec tcd.ie> writes:
On Thursday, 26 November 2015 at 13:44:48 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:

 On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg 
 wrote:

 On 2015-11-25 11:17, Suliman wrote:

 [...]


 BTW, why was not TOML [1] chosen? I know it was discussed but 
 I can't remember why SDL was preferred. I think TOML is more 
 widely used than SDL [2]. GitLib CI multi runner is also 
 using it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


 TOML looks nice, _but_ it's version 0.4.0. We cannot afford to 
 maintain a parser for a format that hasn't "settled down" yet.


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


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

It's weird how the minor issues that could be fixed in an instant 
always cause flamewars. I say, let's just revert to JSON as 
standard format and provide a converter (as I and others have 
suggested). That should end the discussion.
Nov 26 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 26/11/2015 12:29, Jacob Carlborg wrote:

 BTW, why was not TOML [1] chosen? I know it was discussed but I can't
 remember why SDL was preferred. I think TOML is more widely used than
 SDL [2]. GitLib CI multi runner is also using it.

 [1] https://github.com/toml-lang/toml
 [2] https://github.com/toml-lang/toml#projects-using-toml


I was wondering the same. I actually think JSON would be just fine since 
the dub.json manifest is usually quite small, and edited very seldomly, 
so no worries to have the slightly verbose JSON as a format.

But if we really wanted a more succinct format, why not go with TOML 
instead of SDL?!? TOML actually has some widespread support (even if not 
as much as JSON), and has parsers written in several languages already! 
SDL on the other hand always looked like a out-of-nowhere, 
no-one-ever-heard-of-it-project.
Like the Lincoln Chafee of US Democratic presidental candidates... I 
mean, there are probably ultra weird, obscure japanese fetishes that are 
more well-known than SDL!

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Nov 26 2015
parent Kagamin <spam here.lot> writes:
On Thursday, 26 November 2015 at 20:54:27 UTC, Bruno Medeiros 
wrote:

 But if we really wanted a more succinct format, why not go with 
 TOML instead of SDL?


AFAIK the author of SDL is a java programmer and Oracle licensed 
SDL for internal use.
Nov 27 2015
prev sibling next sibling parent reply mattcoder <stop spam.com> writes:
Sorry but for me this is another "HOT" thread for a sh*t problem. 
The OP dislikes SDL, so use JSON. What's the big deal, and as 
Sönke Ludwig said, it was announced before 
(http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/) and
most agree with this change.

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

Matheus.
Nov 26 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 26, 2015 at 01:43:13PM +0000, mattcoder via Digitalmars-d wrote:

 Sorry but for me this is another "HOT" thread for a sh*t problem. The
 OP dislikes SDL, so use JSON. What's the big deal, and as Sönke Ludwig
 said, it was announced before
 (http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/)
 and most agree with this change.
 
 I'm here almost every day reading the topics. And is weird to see how
 the sh*t ones usually got attraction.


[...]

It's an internet phenomenon. Online forums tend to be short and sweet
when it comes to important discussions, but trivial discussions tend to
flourish, attract lots of attention, and, if they happen to touch on an
especially sensitive or controversial topic, rapidly grow out of
proportion and threaten to take over the entire forum and become the
biggest topic of the day, even though in the grand scheme of things it's
really not that important.

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality


T

-- 
That's not a bug; that's a feature!
Nov 26 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-11-25 11:17, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do not want to
 spend time in learning yet another dead config format that now use only
 one project -- DUB. In time when DUB used json it was not perfect, but
 at last it was standard and everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past of
 dependence. I need go to docs page, and read how to include it.

 Also I do not see any projects that are migrate to SDL. Everybody
 continue to use JSON. So please, return JSON back as default, or very
 soon we will see that nobody do not submit packages to code.dlang.org
 and nobody do not use DUB for their own projects.

 Please vote about SDL config format
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other build
 system or will downgrade to old version of DUB.


Just throwing it out there: CSON [1]. "CoffeeScript-Object-Notation. 
Same as JSON but for CoffeeScript objects". It's used by the Atom editor.

[1] https://github.com/bevry/cson

-- 
/Jacob Carlborg
Nov 27 2015
parent reply BLM768 <blm768 gmail.com> writes:
On Friday, 27 November 2015 at 19:29:48 UTC, Jacob Carlborg wrote:

 Just throwing it out there: CSON [1]. 
 "CoffeeScript-Object-Notation. Same as JSON but for 
 CoffeeScript objects". It's used by the Atom editor.

 [1] https://github.com/bevry/cson


Hmm. Pretty, standardized, similar to JSON. I like it!

...but we don't have a parser yet, do we? That might be an 
obstacle.
Nov 28 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-11-28 18:29, BLM768 wrote:


 Hmm. Pretty, standardized, similar to JSON. I like it!

 ...but we don't have a parser yet, do we? That might be an obstacle.


Not as far as I know.

-- 
/Jacob Carlborg
Nov 29 2015
prev sibling next sibling parent reply Mathias Lang <pro.mathias.lang gmail.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.


I think the only mistake here (beside this whole thread) was that 
SDL was made the default config format as soon as it was 
introduced ( Sonke: .

What is the problem in having multiple formats as long as:
- they work together;
- they exhibit the same set of properties;
- you can easily convert from one to another;
- you are not forced to use one or the other;

ATM, it seems that only the third and possibly fourth points are 
missing. IMO dub really needs a `.dubconfig` (a la .gitconfig) 
for various thing, like default compiler to use, default format 
to use in dub init, as well as default value for certain field 
(I'm really tired of it using my username ;) ).

 Walter: Your comments on maintaining your own parser are 
somewhat ironic, considering Sonke did write not one, but two 
JSON parsers already, including one that has been under review 
for months.

Overall, it's really disappointing to see the management 
sometimes jumping the gun over a reddit/hackernews comment or a 
post here, and totally dismissing days, weeks, or in this case, 
years of progress.
Nov 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2015 11:41 AM, Mathias Lang wrote:

 What is the problem in having multiple formats


I posted a list twice upthread.
Nov 27 2015
parent reply bubbasaur <bubba hotmail.com> writes:
On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright wrote:

 On 11/27/2015 11:41 AM, Mathias Lang wrote:

 What is the problem in having multiple formats


 I posted a list twice upthread.


Do you mind to link? This is a huge thread now!
Nov 27 2015
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:

 On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright 
 wrote:

 On 11/27/2015 11:41 AM, Mathias Lang wrote:

 What is the problem in having multiple formats


 I posted a list twice upthread.


 Do you mind to link? This is a huge thread now!


175 posts. We're mad!
Nov 27 2015
prev sibling parent reply terchestor <terchestor gmail.com> writes:
On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:

 On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright 
 wrote:

 On 11/27/2015 11:41 AM, Mathias Lang wrote:

 What is the problem in having multiple formats


 I posted a list twice upthread.


 Do you mind to link? This is a huge thread now!


No trouble with multiple languages but can't run a search...

http://forum.dlang.org/post/n39sgu$1iio$1 digitalmars.com
Nov 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2015 2:10 PM, terchestor wrote:

 On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:

 On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright wrote:

 On 11/27/2015 11:41 AM, Mathias Lang wrote:

 What is the problem in having multiple formats


 I posted a list twice upthread.


 Do you mind to link? This is a huge thread now!


 No trouble with multiple languages but can't run a search...

 http://forum.dlang.org/post/n39sgu$1iio$1 digitalmars.com


I meant:

"With a standard json parser in Phobos, zip zap boom you're done. You don't
have 
to design it, argue about it, build it, document it, debug it, test it,
optimize 
it, explain it, deal with bug requests, deal with enhancement requests, deal 
with legacy compatibility, build a converter, build a gui tool for it, etc."
Nov 27 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 27 November 2015 at 22:18:28 UTC, Walter Bright wrote:

 "With a standard json parser in Phobos, zip zap boom you're 
 done. You don't have to design it, argue about it, build it, 
 document it, debug it, test it, optimize it, explain it, deal 
 with bug requests, deal with enhancement requests, deal with 
 legacy compatibility, build a converter, build a gui tool for 
 it, etc."


But surly the D standard libray needs support for XML, YAML and 
other widespread formats too, so you would want the most suitable 
format rather than the most limited one?
Nov 27 2015
prev sibling next sibling parent reply ChangLong <changlon gmail.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


JSON +1
Nov 27 2015
parent reply Gordon <me home.com> writes:
On Saturday, 28 November 2015 at 05:09:48 UTC, ChangLong wrote:

 On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


 JSON +1


JSON +1
Douchebot -∞
Nov 28 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
We don't do name calling here. Please stop it.
Nov 28 2015
prev sibling next sibling parent krzaq <dlangmailinglist krzaq.cc> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


To be honest, the use of json for *config* has always stumped me. 
This may be a very minor thing, but I don't want to refer to my 
settings as strings. "version" is not version. Even xml doesn't 
do that.

Because of the above, when the new DUB came with a new config 
format, I just said "finally!".

I hope you stick with it, or at least with a sane config format.
Nov 28 2015
prev sibling next sibling parent reply lobo <swamplobo gmail.com> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.

 Also I do not see any projects that are migrate to SDL. 
 Everybody continue to use JSON. So please, return JSON back as 
 default, or very soon we will see that nobody do not submit 
 packages to code.dlang.org and nobody do not use DUB for their 
 own projects.

 Please vote about SDL config format 
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other 
 build system or will downgrade to old version of DUB.


A 20-page bikeshedding bonanza! Atypical D forums...and a pity 
that the priorities of core D devs is diverted to this spittle of 
a forum post when D has much bigger fish to fry.

JSON/SDLang both have zero friction; if you use Dub+JSON you can 
become fluent Dub+SDLang in less than 1 minute for the first 
time. Pick one for your project and move on, both are supported.

bye,
lobo
Nov 28 2015
parent lobo <swamplobo gmail.com> writes:
On Sunday, 29 November 2015 at 01:20:41 UTC, lobo wrote:

 On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 [...]


 A 20-page bikeshedding bonanza! Atypical D forums...and a pity 
 that the priorities of core D devs is diverted to this spittle 
 of a forum post when D has much bigger fish to fry.

 JSON/SDLang both have zero friction; if you use Dub+JSON you 
 can become fluent Dub+SDLang in less than 1 minute for the 
 first time. Pick one for your project and move on, both are 
 supported.

 bye,
 lobo


Gah!

s/Atypical/A typical
Nov 28 2015
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/25/15 5:17 AM, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do not want to
 spend time in learning yet another dead config format that now use only
 one project -- DUB. In time when DUB used json it was not perfect, but
 at last it was standard and everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past of
 dependence. I need go to docs page, and read how to include it.

 Also I do not see any projects that are migrate to SDL. Everybody
 continue to use JSON. So please, return JSON back as default, or very
 soon we will see that nobody do not submit packages to code.dlang.org
 and nobody do not use DUB for their own projects.

 Please vote about SDL config format
 http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67

 If SDL will stay by default I will prefer to move to any other build
 system or will downgrade to old version of DUB.


After reading the discussion here, I can safely conclude that I should 
have better spent the time picking lint out of my navel.

Killing thread...

-Steve
Nov 30 2015
prev sibling next sibling parent reply James Hofmann <jhofmann 321f.net> writes:
Although I admit to coming in late to a big bikeshed-fest, I have 
some opinions on configuration file formats from having seen 
younger, non-technical end users try to configure their own game 
servers. The support cost of misconfiguration due to syntax error 
is enormous. Gob-stoppingly huge. It is day after day of

Q: hey it's broke fix it
A: you forgot to add a double quote in your config file

And so when the file format is pressed into the role of primary 
UI, and is touched directly by hundreds or thousands of people, 
who want to write things that are more than a few trivial lines, 
relying only on JSON, which biases towards parser and programmer 
friendliness, not towards forgiving syntax, is not the right 
trade-off for total human effort and the stress levels of project 
maintainers. Those files are source code and need the additional 
care and forgiving structure of a source code language. If you 
want externally-generated configurations, then JSON is the right 
move, but it is not a complete design - it's passing the buck to 
users.

For similar reasons there are a lot of interfaces and formats for 
writing documents and nobody is entirely happy with any of them. 
It's easy to write simple things in Markdown variants, but 
complex material pushes against the feature boundaries. You can 
do pretty much everything with DocBook or TeX, but they're a 
chore. Word processing tools can smooth out the problem of 
discovering features, but again restrict your control and emit 
weird markup in the process. The happy medium workflow tends to 
involve writing in a "light" format and then transferring content 
to the "heavy" one to merge it and add finishing touches.

A year or two ago I spent a lot of time thinking about 
source-vs-serialization trade-offs. When you can get 
bi-directional serialization and ensure that pretty-printed 
output looks like the original input, you lose some freedom on 
the end of the user being allowed to make mistakes or change up 
their style partway through. Sometimes you want that, and 
sometimes you don't, and it really does depend on the context 
you're putting that format into.

If you look at Lisp family languages, for example, they take an 
extreme posture on bi-di behavior in that "code is data and data 
is code", but that also means that their ecosystem is defined 
around having s-expression-friendly editors and a coding style 
that biases a bit more towards using powerful language extension 
tools. And it's another valid way to go with configuration 
formats, of course. It would make sense to jump all the way over 
to a script interpreter if, as got mentioned earlier in this 
thread, SDL were to start being extended to do "programming-like" 
things.

FWIW, I'm tempted to take the side of "make JS the default, 
compile existing SDL and JSON to JS when run, add compilers for 
TOML or YAML if there's demand". If you make code your lowest 
common denominator, nothing else matters, and JS is the de-facto 
lowest common denominator of code, today. Someone presented with 
a config whose syntax they don't know can tell Dub to port it to 
JS and edit that instead, and so over time all configs end up 
being a blob of JS code, in the same way that the "light"/"heavy" 
markup situation is resolved by gradually converting everything 
into the heavy format even if it didn't start there. That is OK. 
Dub might run a bit slower, and there are some security issues 
raised from it, but the world is unlikely to blow up because 
someone wrote "clever" JS in their Dub config.

Also, people will see the option of coding JS and go, "Now I can 
write a build system on top of Dub, and it can use my own config 
format, way better than SDL or YAML or TOML! Everyone's gonna 
love this!" The D and Dub maintainers smile innocently and say 
nothing...
Nov 30 2015
next sibling parent reply Craig Dillabaugh <craig.dillabaugh gmail.com> writes:
On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:

 FWIW, I'm tempted to take the side of "make JS the default, 
 compile existing SDL and JSON to JS when run, add compilers for 
 TOML or YAML if there's demand". If you make code your lowest 
 common denominator, nothing else matters, and JS is the 
 de-facto lowest common denominator of code, today. Someone 
 presented with a config whose syntax they don't know can tell 
 Dub to port it to JS and edit that instead, and so over time 
 all configs end up being a blob of JS code, in the same way 
 that the "light"/"heavy" markup situation is resolved by 
 gradually converting everything into the heavy format even if 
 it didn't start there. That is OK. Dub might run a bit slower, 
 and there are some security issues raised from it, but the 
 world is unlikely to blow up because someone wrote "clever" JS 
 in their Dub config.

 Also, people will see the option of coding JS and go, "Now I 
 can write a build system on top of Dub, and it can use my own 
 config format, way better than SDL or YAML or TOML! Everyone's 
 gonna love this!" The D and Dub maintainers smile innocently 
 and say nothing...


Sorry, I think that most of what you said made good sense, but I 
am a bit confused by the quoted bit.  So you want the DUB config 
files written in full-blown JavaScript? Then DUB and the other 
tools would need a JavaScript compiler built-in.
Nov 30 2015
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh 
wrote:

 On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann 
 wrote:

 [...]


 Sorry, I think that most of what you said made good sense, but 
 I am a bit confused by the quoted bit.  So you want the DUB 
 config files written in full-blown JavaScript? Then DUB and the 
 other tools would need a JavaScript compiler built-in.


You can use dub packages and write descriptions of how to build 
them in Javascript with reggae. Today.

Atila
Dec 01 2015
parent reply Luis <luis.panadero gmail.com> writes:
On Tuesday, 1 December 2015 at 10:27:45 UTC, Atila Neves wrote:

 On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh 
 wrote:

 On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann 
 wrote:

 [...]


 Sorry, I think that most of what you said made good sense, but 
 I am a bit confused by the quoted bit.  So you want the DUB 
 config files written in full-blown JavaScript? Then DUB and 
 the other tools would need a JavaScript compiler built-in.


 You can use dub packages and write descriptions of how to build 
 them in Javascript with reggae. Today.

 Atila


A example of this would be nice. Also... you can grab with dub a 
dependency package that is build with reggae ?
Dec 01 2015
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 1 December 2015 at 10:33:05 UTC, Luis wrote:

 On Tuesday, 1 December 2015 at 10:27:45 UTC, Atila Neves wrote:

 On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh 
 wrote:

 On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann 
 wrote:

 [...]


 Sorry, I think that most of what you said made good sense, 
 but I am a bit confused by the quoted bit.  So you want the 
 DUB config files written in full-blown JavaScript? Then DUB 
 and the other tools would need a JavaScript compiler built-in.


 You can use dub packages and write descriptions of how to 
 build them in Javascript with reggae. Today.

 Atila


 A example of this would be nice. Also... you can grab with dub 
 a dependency package that is build with reggae ?


Modulo bugs, it's no different than writing it in D. The git 
repository has documentation, and the JS-specific part is handled 
by reggae-js.

Atila
Dec 01 2015
prev sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:

 Although I admit to coming in late to a big bikeshed-fest, I 
 have some opinions on configuration file formats from having 
 seen younger, non-technical end users try to configure their 
 own game servers. The support cost of misconfiguration due to 
 syntax error is enormous. Gob-stoppingly huge. It is day after 
 day of

 Q: hey it's broke fix it
 A: you forgot to add a double quote in your config file

 And so when the file format is pressed into the role of primary 
 UI, and is touched directly by hundreds or thousands of people, 
 who want to write things that are more than a few trivial 
 lines, relying only on JSON, which biases towards parser and 
 programmer friendliness, not towards forgiving syntax, is not 
 the right trade-off for total human effort and the stress 
 levels of project maintainers. Those files are source code and 
 need the additional care and forgiving structure of a source 
 code language. If you want externally-generated configurations, 
 then JSON is the right move, but it is not a complete design - 
 it's passing the buck to users.


Yes, _all_ configuration file formats become a mess once you do 
non-trivial stuff. However, for what you describe above, you 
shouldn't have users edit JSON directly. If you deal with UI 
stuff, have hundreds and thousands of people working on it, 
people who are non-technical, you should use automated WYSIWYG 
tools like Glade. Even a technical person might have difficulties 
making non-trivial changes to huge configuration files manually.

[snip]


 FWIW, I'm tempted to take the side of "make JS the default, 
 compile existing SDL and JSON to JS when run, add compilers for 
 TOML or YAML if there's demand". If you make code your lowest 
 common denominator, nothing else matters, and JS is the 
 de-facto lowest common denominator of code, today. Someone 
 presented with a config whose syntax they don't know can tell 
 Dub to port it to JS and edit that instead, and so over time 
 all configs end up being a blob of JS code, in the same way 
 that the "light"/"heavy" markup situation is resolved by 
 gradually converting everything into the heavy format even if 
 it didn't start there. That is OK. Dub might run a bit slower, 
 and there are some security issues raised from it, but the 
 world is unlikely to blow up because someone wrote "clever" JS 
 in their Dub config.

 Also, people will see the option of coding JS and go, "Now I 
 can write a build system on top of Dub, and it can use my own 
 config format, way better than SDL or YAML or TOML! Everyone's 
 gonna love this!" The D and Dub maintainers smile innocently 
 and say nothing...


Ain't gonna happen. I don't think anyone is interested in making 
DUB dependent on JS or any other 3rd party scripting language, 
e.g. Lua (which I like) or Ruby. I suppose DUB will always rely 
on home made D solutions, and it should.
Dec 01 2015
prev sibling next sibling parent reply Jin <nin-jin ya.ru> writes:
How about this format? https://github.com/nin-jin/tree.d
Dec 06 2015
parent Jin <nin-jin ya.ru> writes:
Example:

name =dedcpu
author =Luis Panadero Guardeño
author =Jin
targetType =none
license =BSD 3-clause
description
     =DCPU-16 tools
     =and other staff
subPackage
     name =lem1802
     description =Visual LEM1802 font editor
     targetType =executable
     targetName =lem1802
     excludedSourceFile =src/bconv.d
     excludedSourceFile =src/ddis.d
     lib
         name =gtkd
         platform =windows
     config
         name =nogtk
         platform =windows
     config
         name =gtk
         platform =posix
         dependency
             name =gtk-d:gtkd
             version ~> 3.2.0
Dec 06 2015
prev sibling parent Gary Willoughby <dev nomad.so> writes:
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:

 I think that using SDL format was big mistake. Not only I do 
 not want to spend time in learning yet another dead config 
 format that now use only one project -- DUB. In time when DUB 
 used json it was not perfect, but at last it was standard and 
 everybody can read it.

 Now when I come to code.dlang.org I can't simply do copy-past 
 of dependence. I need go to docs page, and read how to include 
 it.


This is exactly why I (and many others) spoke up against it and 
why Andrei said had he of known sooner, he would have stopped it! 
It is a terrible decision especially as SDL is so obscure.
Sep 16 2016