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 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
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 2. D itself can be used as a scripting language (when # is the first character 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

 2. D itself can be used as a scripting language (when # is the first
 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

 2. D itself can be used as a scripting language (when # is the first
 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

 2. D itself can be used as a scripting language (when # is the first
 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: # this is a comment 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: # this is a comment 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: # this is a comment 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: # this is a comment 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 Snke 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 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