www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta release DUB 1.0.0-beta.1

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support 
for single-file packages, which can be used to write shebang-style 
scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

     void main()
     {
         import std.stdio : writefln;
         import std.experimental.color.conv;
         import std.experimental.color.hsx;
         import std.experimental.color.rgb;

         auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
         writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
     }

With "chmod +x" it can then simply be run as ./colortest.d.

Apart from that, the release contains some bug fixes, most notably it 
doesn't query the registry for each build any more.

Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download
Jun 07 2016
next sibling parent Edwin van Leeuwen <edder tkwsping.nl> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/
I love that as a feature! Thanks for adding that.
Jun 07 2016
prev sibling next sibling parent wobbles <grogan.colin gmail.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

 [...]
This is great - very nice feature. That was one of the things I missed most when moving from rdmd to dub - so good to see it back!
Jun 07 2016
prev sibling next sibling parent Luis <luis.panadero gmail.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

     void main()
     {
         import std.stdio : writefln;
         import std.experimental.color.conv;
         import std.experimental.color.hsx;
         import std.experimental.color.rgb;

         auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
         writefln("Yellow in HSV: %s", 
 yellow.convertColor!(HSV!()));
     }

 With "chmod +x" it can then simply be run as ./colortest.d.

 Apart from that, the release contains some bug fixes, most 
 notably it doesn't query the registry for each build any more.

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
YES!
Jun 07 2016
prev sibling next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/
Hmm... `/++` is for DDoc. Is this a good idea? Does it matter?
Jun 07 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 07.06.2016 um 13:09 schrieb Marc Schütz:
 On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
 support for single-file packages, which can be used to write
 shebang-style scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/
Hmm... `/++` is for DDoc. Is this a good idea? Does it matter?
Oh, I typed that by accident, should be /+ dub.sdl: ... +/ BTW, /+ dub.json: ... +/ is also possible, of course.
Jun 07 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-07 13:22, Sönke Ludwig wrote:

 Oh, I typed that by accident, should be /+ dub.sdl: ... +/
 BTW, /+ dub.json: ... +/ is also possible, of course.
Does it work with all kind of comments D supports? -- /Jacob Carlborg
Jun 07 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 07.06.2016 um 15:45 schrieb Jacob Carlborg:
 On 2016-06-07 13:22, Sönke Ludwig wrote:

 Oh, I typed that by accident, should be /+ dub.sdl: ... +/
 BTW, /+ dub.json: ... +/ is also possible, of course.
Does it work with all kind of comments D supports?
No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
Jun 07 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-07 20:42, Sönke Ludwig wrote:

 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
That's unfortunate. -- /Jacob Carlborg
Jun 07 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
 On 2016-06-07 20:42, Sönke Ludwig wrote:

 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
That's unfortunate.
I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done.
Jun 08 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-08 11:15, Sönke Ludwig wrote:

 I generally really do appreciate your critique, but without backing
 reasons it doesn't really have a constructive effect.

 Two good properties about restricting to /+ +/ is that it's still
 possible to put something else in front of it, and that it stands out
 from the usual /* */ comments. Sure arguments can be made for supporting
 all comment types, but it shouldn't be forgotten that in the end this is
 a question of absolutely minimal impact.

 Just to be clear: If anyone has a good argument for supporting more/all
 comment types and there are no equally good arguments against it, please
 go ahead and implement it and it will be included. Let's just make this
 a quick decision, because changing it later on will mean breakage no
 matter how it's done.
It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. Otherwise it might be better to use a UDA, if possible. If one reads the documentation and copy pastes and example the user will most likely get it right. But if you have a conversation saying something like "it's possible to put the content of dub.json inline in the source code, just put it in a comment" then someone will for sure try using a comment style that is not supported. The documentation needs to be very clear that only one type comments are supported, if that's the conclusion. -- /Jacob Carlborg
Jun 08 2016
next sibling parent reply burjui <bytefu gmail.com> writes:
On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:

 It's just that since the language support other styles of 
 comments one could think that all comments are supported and it 
 will cause confusion if only one style is supported.
That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
Jun 08 2016
next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 08.06.2016 um 15:27 schrieb burjui:
 On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote:

 It's just that since the language support other styles of comments one
 could think that all comments are supported and it will cause
 confusion if only one style is supported.
That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
But the user *will* remember the filename + colon requirement? Or will remember yet another format to specify dependencies? What if something else, such as compiler flags or link libraries need to be specified? I'll stay out of this discussion until there is a conclusion now.
Jun 08 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 June 2016 at 13:27:31 UTC, burjui wrote:
 That reason alone is enough. Restricting DUB special comments 
 to only /++/ will put users off, because now they know that 
 there's a cool feature in DUB, but it only works with certain 
 types of comments, that nobody wants to remember (why should 
 they?), so they will decide that this feature is either broken 
 or unfinished and will hardly use it at all.

 We could make users' lives easier, if we allowed them to just 
 specify the dependencies in Gradle style on a single line:

 #!/usr/bin/env dub
 // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
I don't understand this argument. There are two options: /++/ and /**/. If a user can't remember which one it is, it's a matter of a few seconds to find out. With all the things we need to remember about a language when programming, I hardly think something of this nature is going to put anyone off. And if they *are* put off by it, they've got bigger issues than trying to remember which comment style to use.
Jun 08 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/8/16 8:21 AM, Jacob Carlborg wrote:
 On 2016-06-08 11:15, Sönke Ludwig wrote:

 I generally really do appreciate your critique, but without backing
 reasons it doesn't really have a constructive effect.

 Two good properties about restricting to /+ +/ is that it's still
 possible to put something else in front of it, and that it stands out
 from the usual /* */ comments. Sure arguments can be made for supporting
 all comment types, but it shouldn't be forgotten that in the end this is
 a question of absolutely minimal impact.

 Just to be clear: If anyone has a good argument for supporting more/all
 comment types and there are no equally good arguments against it, please
 go ahead and implement it and it will be included. Let's just make this
 a quick decision, because changing it later on will mean breakage no
 matter how it's done.
It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. Otherwise it might be better to use a UDA, if possible. If one reads the documentation and copy pastes and example the user will most likely get it right. But if you have a conversation saying something like "it's possible to put the content of dub.json inline in the source code, just put it in a comment" then someone will for sure try using a comment style that is not supported. The documentation needs to be very clear that only one type comments are supported, if that's the conclusion.
I agree with Jacob. A comment is a comment. There is no reason one needs to use specifically /+. In fact the only reason for the existence of /+ is to allow nesting of comments -- which doesn't apply here. I'd say you should support // comments as well. There's another aspect here, in that most people (even core D developers) use the /* comment style */. So someone seeing the /+ comment might think this is a specialized dub thing. I will finally say this: if such an implementation update existed, what would be the reason NOT to pull it? That is, I think literally the only reason not to support /* for this purpose is that nobody has done the work. If you can give no better reason, it should take away any barriers for anyone wishing to create this improvement. -Steve
Jun 08 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-06-08 16:58, Steven Schveighoffer wrote:

 I agree with Jacob. A comment is a comment. There is no reason one needs
 to use specifically /+. In fact the only reason for the existence of /+
 is to allow nesting of comments -- which doesn't apply here.
And basically the only reason why /+ exists and /* doesn't allow nesting is to be compatible with C. -- /Jacob Carlborg
Jun 08 2016
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:
 I agree with Jacob. A comment is a comment.
Well, there are normal comments, doc comments and now DUB recipe comments. But at least if doc comments serve as an analogy, those are possible with all three comment styles, so that could be taken as a consistency argument.
 There is no reason one needs
 to use specifically /+. In fact the only reason for the existence of /+
 is to allow nesting of comments -- which doesn't apply here. I'd say you
 should support // comments as well.
SDLang supports C and C++ style comments as well, so could in fact apply here. But probably you'd usually use // style comments in that case.
 There's another aspect here, in that most people (even core D
 developers) use the /* comment style */. So someone seeing the /+
 comment might think this is a specialized dub thing.
Would there be any harm? Looking it up in either DUB's or DMD's documentation would clarify that.
 I will finally say this: if such an implementation update existed, what
 would be the reason NOT to pull it? That is, I think literally the only
 reason not to support /* for this purpose is that nobody has done the
 work. If you can give no better reason, it should take away any barriers
 for anyone wishing to create this improvement.
Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case. Okay, so at least 3 people favor supporting other comment styles, while I'm not convinced that supporting all comment styles is necessarily better, I wouldn't mind pulling an update. The relevant code section is here: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288 It would probably make sense to unify the comment matcher with the one here, which currently doesn't support /+ +/ comments: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/internal/utils.d#L430 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to avoid stretching the release schedule (it's technically a breaking change!).
Jun 08 2016
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Wed, Jun 8, 2016 at 8:45 PM, Sönke Ludwig
<digitalmars-d-announce puremagic.com> wrote:
...
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to
 avoid stretching the release schedule (it's technically a breaking change!).
I just tried this inside a directory that happened to be a dub project, it seemed like dub tried to build both the test file and the dub project as one. I see that it puts the compiled binary in the same directory as the .d file. This makes it not possible to deploy to e.g. /usr/local/bin/. What is the expected isolation of a single file dub project?
Jun 08 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 08.06.2016 um 21:20 schrieb Rory McGuire via Digitalmars-d-announce:
 On Wed, Jun 8, 2016 at 8:45 PM, Sönke Ludwig
 <digitalmars-d-announce puremagic.com> wrote:
 ...
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to
 avoid stretching the release schedule (it's technically a breaking change!).
I just tried this inside a directory that happened to be a dub project, it seemed like dub tried to build both the test file and the dub project as one. I see that it puts the compiled binary in the same directory as the .d file. This makes it not possible to deploy to e.g. /usr/local/bin/. What is the expected isolation of a single file dub project?
Everything regarding the single-file package is supposed to stay in the temp directory and only the file itself is supposed to be considered as a source file. Fix: https://github.com/dlang/dub/pull/870
Jun 08 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:
 I agree with Jacob. A comment is a comment.
Well, there are normal comments, doc comments and now DUB recipe comments. But at least if doc comments serve as an analogy, those are possible with all three comment styles, so that could be taken as a consistency argument.
 There is no reason one needs
 to use specifically /+. In fact the only reason for the existence of /+
 is to allow nesting of comments -- which doesn't apply here. I'd say you
 should support // comments as well.
SDLang supports C and C++ style comments as well, so could in fact apply here. But probably you'd usually use // style comments in that case.
So this is definitely something concerning for allowing all comment styles. If one wants to put comments in their sdl file, then one must use an alternate style of commenting inside their sdl file. This makes /+ much more attractive than the other styles. But I think this is really just a documentation issue. The biggest problem I would see is if someone used /* style comments in their sdl file definition, but wanted to use /* style comments to include it, the parser would prematurely close the whole comment block.
 There's another aspect here, in that most people (even core D
 developers) use the /* comment style */. So someone seeing the /+
 comment might think this is a specialized dub thing.
Would there be any harm? Looking it up in either DUB's or DMD's documentation would clarify that.
Not "harm", but confusion. I can see someone never looking this up, because it may seem "obvious" the /+ is dub special. It's very minimal impact, but something I just thought of.
 I will finally say this: if such an implementation update existed, what
 would be the reason NOT to pull it? That is, I think literally the only
 reason not to support /* for this purpose is that nobody has done the
 work. If you can give no better reason, it should take away any barriers
 for anyone wishing to create this improvement.
Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case.
"It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting.
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:
 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :)
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release. -Steve
Jun 09 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
"It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting.
I mean together with the restriction that it has to be the first /+ +/ comment, it is possible to put // and /* style comments in front of it without interference.
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:
 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872 But this has brought up another issue. The idea was to allow the recipe comment to be anywhere in the file and be of any comment style. However, that basically almost requires a full D lexer (at least string literals need to be parsed in addition to the comment styles). I'm reluctant to include this in the current state, because the results for a program such as the following will be very confusing: bool foo(string str) { return str.startsWith("/*"); } /* dub.sdl: ... */ void main() { } The string literal will be recognized as the start of a comment and thus the real comment below will not be recognized. So I think we should either have a generic and correct version, or one that is restricted similar to the current one to sidestep such issues.
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now not considered as a recipe comment candidate. Depending on its contents, the behavior could change once /* */ is also recognized. However, that case would be easily detectable and a warning could be emitted instead, while falling back to the old behavior. So it's not really an issue after all.
Jun 09 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/9/16 4:37 PM, Sönke Ludwig wrote:
 Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
"It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting.
I mean together with the restriction that it has to be the first /+ +/ comment, it is possible to put // and /* style comments in front of it without interference.
Oh, didn't see that aspect. I'll answer this with your last point.
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:
 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872 But this has brought up another issue. The idea was to allow the recipe comment to be anywhere in the file and be of any comment style. However, that basically almost requires a full D lexer (at least string literals need to be parsed in addition to the comment styles). I'm reluctant to include this in the current state, because the results for a program such as the following will be very confusing: bool foo(string str) { return str.startsWith("/*"); } /* dub.sdl: ... */ void main() { } The string literal will be recognized as the start of a comment and thus the real comment below will not be recognized. So I think we should either have a generic and correct version, or one that is restricted similar to the current one to sidestep such issues.
I think the idea to include it anywhere in the file is not worth the trouble. I also wouldn't want to scroll through an entire file for such a thing. But it also brings up the point, what if the first /+ comes after: return str.startsWith("/+");
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now not considered as a recipe comment candidate. Depending on its contents, the behavior could change once /* */ is also recognized. However, that case would be easily detectable and a warning could be emitted instead, while falling back to the old behavior. So it's not really an issue after all.
Yeah, comments are not hard to parse, if they are the first thing you are expecting. I would say it doesn't have to be the first comment, but it has to be one of the first things in the file. You can simply throw away other comments. You may want to just tell the user: look, this isn't perfect, it's not a D parser. Expect reasonable results for reasonable situations :) If you have a line of code that looks like it could match the sdl file, then put the true sdl file above it. -Steve
Jun 09 2016
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On 6/9/16 4:37 PM, Sönke Ludwig wrote:
 Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
"It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting.
I mean together with the restriction that it has to be the first /+ +/ comment, it is possible to put // and /* style comments in front of it without interference.
Oh, didn't see that aspect. I'll answer this with your last point.
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:

 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872 But this has brought up another issue. The idea was to allow the recipe comment to be anywhere in the file and be of any comment style. However, that basically almost requires a full D lexer (at least string literals need to be parsed in addition to the comment styles). I'm reluctant to include this in the current state, because the results for a program such as the following will be very confusing: bool foo(string str) { return str.startsWith("/*"); } /* dub.sdl: ... */ void main() { } The string literal will be recognized as the start of a comment and thus the real comment below will not be recognized. So I think we should either have a generic and correct version, or one that is restricted similar to the current one to sidestep such issues.
I think the idea to include it anywhere in the file is not worth the trouble. I also wouldn't want to scroll through an entire file for such a thing. But it also brings up the point, what if the first /+ comes after: return str.startsWith("/+");
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now not considered as a recipe comment candidate. Depending on its contents, the behavior could change once /* */ is also recognized. However, that case would be easily detectable and a warning could be emitted instead, while falling back to the old behavior. So it's not really an issue after all.
Yeah, comments are not hard to parse, if they are the first thing you are expecting. I would say it doesn't have to be the first comment, but it has to be one of the first things in the file. You can simply throw away other comments. You may want to just tell the user: look, this isn't perfect, it's not a D parser. Expect reasonable results for reasonable situations :) If you have a line of code that looks like it could match the sdl file, then put the true sdl file above it. -Steve
Could we not just make it a requirement that if the file starts with #!... on the first line then the second line _must_ be a comment with the dub file definition? It will be frustrating to try find the dub definition if its not near the top and if the definition starts to be complicated so that you can't see the copyright or whatever would usually be in the first comment then you probably shouldn't be using a single file dub project anyway. If that is released with dub 1.0 then the restriction can always be loosened up if there is enough demand.
Jun 09 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/10/16 2:30 AM, Rory McGuire via Digitalmars-d-announce wrote:

 Could we not just make it a requirement that if the file starts with
 #!... on the first line then the second line _must_ be a comment with
 the dub file definition?
I think this is fine as a requirement. -Steve
Jun 10 2016
prev sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Fri, Jun 10, 2016 at 8:30 AM, Rory McGuire <rjmcguire gmail.com> wrote:
 On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On 6/9/16 4:37 PM, Sönke Ludwig wrote:
 Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
"It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting.
I mean together with the restriction that it has to be the first /+ +/ comment, it is possible to put // and /* style comments in front of it without interference.
Oh, didn't see that aspect. I'll answer this with your last point.
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:

 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872 But this has brought up another issue. The idea was to allow the recipe comment to be anywhere in the file and be of any comment style. However, that basically almost requires a full D lexer (at least string literals need to be parsed in addition to the comment styles). I'm reluctant to include this in the current state, because the results for a program such as the following will be very confusing: bool foo(string str) { return str.startsWith("/*"); } /* dub.sdl: ... */ void main() { } The string literal will be recognized as the start of a comment and thus the real comment below will not be recognized. So I think we should either have a generic and correct version, or one that is restricted similar to the current one to sidestep such issues.
I think the idea to include it anywhere in the file is not worth the trouble. I also wouldn't want to scroll through an entire file for such a thing. But it also brings up the point, what if the first /+ comes after: return str.startsWith("/+");
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now not considered as a recipe comment candidate. Depending on its contents, the behavior could change once /* */ is also recognized. However, that case would be easily detectable and a warning could be emitted instead, while falling back to the old behavior. So it's not really an issue after all.
Yeah, comments are not hard to parse, if they are the first thing you are expecting. I would say it doesn't have to be the first comment, but it has to be one of the first things in the file. You can simply throw away other comments. You may want to just tell the user: look, this isn't perfect, it's not a D parser. Expect reasonable results for reasonable situations :) If you have a line of code that looks like it could match the sdl file, then put the true sdl file above it. -Steve
Could we not just make it a requirement that if the file starts with #!... on the first line then the second line _must_ be a comment with the dub file definition? It will be frustrating to try find the dub definition if its not near the top and if the definition starts to be complicated so that you can't see the copyright or whatever would usually be in the first comment then you probably shouldn't be using a single file dub project anyway. If that is released with dub 1.0 then the restriction can always be loosened up if there is enough demand.
I made a version that ignores comment like characters in strings. I've also made a version that requires the recipe to be on the second line. Both are in my fork of dub. I can fix my pull request to which ever one you guys prefer. The one that handles recipe anywhere has a flaw where it will still recognize a dub recipe even if the recipe is inside a nested comment (one would expect that to be commented out. The one that handles recipe on second line only passes the following unittest: unittest { // first line must be #! assertThrown!Exception(SingleFilePackage("/* dub.json: {} */void main(){}")); // missing dub recipe assertThrown!Exception(SingleFilePackage("#!/asdf\n/* dub: {} */void main(){}")); // single file package must contain code assertThrown!Exception(SingleFilePackage("#!/asdf\n/* dub.sdl: */")); // documentation style comments not supported for dub recipe comment assertThrown!Exception(SingleFilePackage("#!/asdf\n/** dub.json: {} */void main(){}")); // documentation style comments not supported for dub recipe comment assertThrown!Exception(SingleFilePackage("#!/asdf\n/++ dub.json: {} +/void main(){}")); // unclosed dub recipe comment assertThrown!Exception(SingleFilePackage("#!/asdf\n/* dub.json: {} * /void main(){}")); assertNotThrown!Exception(SingleFilePackage("#!/asdf\n/* dub.sdl: {name:\"*\"} */void main(){}")); assertNotThrown!Exception(SingleFilePackage("#!/asdf\n/+ dub.json: /* some sdl comment */ +/void main(){}")); assertNotThrown!Exception(SingleFilePackage("#!/asdf\n/* dub.json: {} */void main(){}")); assertNotThrown!Exception(SingleFilePackage("#!/asdf\n/* dub.sdl: {} */void main(){}")); }
Jun 10 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:
 I made a version that ignores comment like characters in strings.
 I've also made a version that requires the recipe to be on the second line.

 Both are in my fork of dub. I can fix my pull request to which ever
 one you guys prefer.

 The one that handles recipe anywhere has a flaw where it will still
 recognize a dub recipe even
 if the recipe is inside a nested comment (one would expect that to be
 commented out.

 (...)
My preference would be to use the one that requires the recipe to be at the top for 1.0.0 and to get the generic version flawless for 1.1.0.
Jun 10 2016
next sibling parent Rory McGuire via Digitalmars-d-announce writes:
BTW: One other question, do you know of a bug where relative paths in
dub packages have stopped working in recent versions?

It seems like it always uses the path of the package being built
rather than the dependencies own directory. I currently have to use
0.9.24.

On Fri, Jun 10, 2016 at 11:00 AM, Sönke Ludwig
<digitalmars-d-announce puremagic.com> wrote:
 Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:
 I made a version that ignores comment like characters in strings.
 I've also made a version that requires the recipe to be on the second
 line.

 Both are in my fork of dub. I can fix my pull request to which ever
 one you guys prefer.

 The one that handles recipe anywhere has a flaw where it will still
 recognize a dub recipe even
 if the recipe is inside a nested comment (one would expect that to be
 commented out.

 (...)
My preference would be to use the one that requires the recipe to be at the top for 1.0.0 and to get the generic version flawless for 1.1.0.
Jun 10 2016
prev sibling parent Rory McGuire via Digitalmars-d-announce writes:
hmm, actually thats not quite the issue, I made a mock set of projects
and it works with both versions.
With 0.9.25 I get:
Sub package onyx-config: doesn't exist.

Whereas with 0.9.24 my package compiles. I'll see if I can figure out
why, sorry for the noise.

On Fri, Jun 10, 2016 at 11:53 AM, Rory McGuire <rjmcguire gmail.com> wrote:
 BTW: One other question, do you know of a bug where relative paths in
 dub packages have stopped working in recent versions?

 It seems like it always uses the path of the package being built
 rather than the dependencies own directory. I currently have to use
 0.9.24.

 On Fri, Jun 10, 2016 at 11:00 AM, Sönke Ludwig
 <digitalmars-d-announce puremagic.com> wrote:
 Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:
 I made a version that ignores comment like characters in strings.
 I've also made a version that requires the recipe to be on the second
 line.

 Both are in my fork of dub. I can fix my pull request to which ever
 one you guys prefer.

 The one that handles recipe anywhere has a flaw where it will still
 recognize a dub recipe even
 if the recipe is inside a nested comment (one would expect that to be
 commented out.

 (...)
My preference would be to use the one that requires the recipe to be at the top for 1.0.0 and to get the generic version flawless for 1.1.0.
Jun 10 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 8 June 2016 at 09:15:09 UTC, Sönke Ludwig wrote:
 Two good properties about restricting to /+ +/ is that it's 
 still possible to put something else in front of it, and that 
 it stands out from the usual /* */ comments.
It stands out because we don't have a recognizable convention for such... processing instructions, every tool uses its own. BTW do people find nested comments particularly useful?
Jun 08 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote:
 BTW do people find nested comments particularly useful?
Yes for: A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */) B) code examples inside comments
Jun 08 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 15:21:08 UTC, John Colvin wrote:
 On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote:
 BTW do people find nested comments particularly useful?
Yes for: A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */) B) code examples inside comments
same two points for me too.
Jun 08 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/08/2016 11:04 AM, Kagamin wrote:
 BTW do people find nested comments particularly useful?
God yes. It's the *only* block comment I ever use. Non-nesting comment blocks are a worthless PITA with no real benefit: You can't comment out a block if the block already contains a block comment. You can't include a block comment inside documentation's sample code. All for...why? The only real reason is C-compatibility, which I don't see much of a benefit in either - if you're porting C code to D that actually *relies* on the goofy behavior of /* */, then the C code's comments are a terrible mess and need fixing anyway. I wish we could just abolish non-nesting comment syntax entirely.
Jun 10 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:
 On 06/08/2016 11:04 AM, Kagamin wrote:
 BTW do people find nested comments particularly useful?
God yes. It's the *only* block comment I ever use. Non-nesting comment blocks are a worthless PITA with no real benefit: You can't comment out a block if the block already contains a block comment.
Block comments are low-level: the commented code changes its lexical structure completely, but you probably don't expect it and want it to behave and be properly commented at a higher level, which is provided by version statement.
Jun 13 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/13/2016 07:31 AM, Kagamin wrote:
 On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:
 On 06/08/2016 11:04 AM, Kagamin wrote:
 BTW do people find nested comments particularly useful?
God yes. It's the *only* block comment I ever use. Non-nesting comment blocks are a worthless PITA with no real benefit: You can't comment out a block if the block already contains a block comment.
Block comments are low-level: the commented code changes its lexical structure completely, but you probably don't expect it and want it to behave and be properly commented at a higher level, which is provided by version statement.
No, I WANT commenting-out to be low-level, but just not have a stupid, useless, badly-chosen rule for when the block ends. Version(none) is too high-level. I can't use it *within* a statement, which means I'd have to use one method to "comment-out" blocks of code and a different method when I comment out ex., params, args, or parts of an expression (all of which I occasionally do). But why would I want to do that when there's one construct (nesting block comments) that works perfectly for both AND actually gets highlighted as "disabled" in every editor and HTML highlighter out there so I can actually see at a glance what's disabled?
Jun 15 2016
prev sibling next sibling parent Rory McGuire via Digitalmars-d-announce writes:
On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
<digitalmars-d-announce puremagic.com> wrote:
 Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
 On 2016-06-07 20:42, Sönke Ludwig wrote:

 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
That's unfortunate.
I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done.
The only thing I can think to change would be that it doesn't have to be the _first_ '/+...' but rather the first regex: \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n See [0] for regex in action on the code below. Sometimes we might want to put the dub config just above the main function, and a lot of people like that to be at the bottom of the file (who knows what comments might be above that and we wouldn't want to break the way /+ ... +/ can be used anywhere to comment out code / comments. concrete example: #!/usr/bin/env dub /** * Copyright (C) blah blah blah * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice */ /+ // Example and/or documentation on changing this program Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * Note that when doing the below !not threadsafe!... * see next example for threadsafe version. */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * This is the threadsafe version of above both are provided. * threadsafe version is not quite as fast */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code // this line has to be here Some codeSome codeSome codeSome code +/ /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ // implementation of support functions void main(string[] args) { ... } [0] https://regex101.com/r/dR7xY1/1
Jun 08 2016
prev sibling next sibling parent Rory McGuire via Digitalmars-d-announce writes:
regex version pull request:
https://github.com/dlang/dub/pull/869

On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire <rjmcguire gmail.com> wrote:
 On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
 <digitalmars-d-announce puremagic.com> wrote:
 Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
 On 2016-06-07 20:42, Sönke Ludwig wrote:

 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
That's unfortunate.
I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done.
The only thing I can think to change would be that it doesn't have to be the _first_ '/+...' but rather the first regex: \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n See [0] for regex in action on the code below. Sometimes we might want to put the dub config just above the main function, and a lot of people like that to be at the bottom of the file (who knows what comments might be above that and we wouldn't want to break the way /+ ... +/ can be used anywhere to comment out code / comments. concrete example: #!/usr/bin/env dub /** * Copyright (C) blah blah blah * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice */ /+ // Example and/or documentation on changing this program Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * Note that when doing the below !not threadsafe!... * see next example for threadsafe version. */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * This is the threadsafe version of above both are provided. * threadsafe version is not quite as fast */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code // this line has to be here Some codeSome codeSome codeSome code +/ /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ // implementation of support functions void main(string[] args) { ... } [0] https://regex101.com/r/dR7xY1/1
Jun 08 2016
prev sibling parent Rory McGuire via Digitalmars-d-announce writes:
I made a little parser, it doesn't handle nested + comments (just
needs a depth check).
https://github.com/dlang/dub/pull/871


On Wed, Jun 8, 2016 at 9:44 PM, Rory McGuire <rjmcguire gmail.com> wrote:
 regex version pull request:
 https://github.com/dlang/dub/pull/869

 On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire <rjmcguire gmail.com> wrote:
 On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
 <digitalmars-d-announce puremagic.com> wrote:
 Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
 On 2016-06-07 20:42, Sönke Ludwig wrote:

 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
That's unfortunate.
I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done.
The only thing I can think to change would be that it doesn't have to be the _first_ '/+...' but rather the first regex: \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n See [0] for regex in action on the code below. Sometimes we might want to put the dub config just above the main function, and a lot of people like that to be at the bottom of the file (who knows what comments might be above that and we wouldn't want to break the way /+ ... +/ can be used anywhere to comment out code / comments. concrete example: #!/usr/bin/env dub /** * Copyright (C) blah blah blah * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice */ /+ // Example and/or documentation on changing this program Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * Note that when doing the below !not threadsafe!... * see next example for threadsafe version. */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * This is the threadsafe version of above both are provided. * threadsafe version is not quite as fast */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code // this line has to be here Some codeSome codeSome codeSome code +/ /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ // implementation of support functions void main(string[] args) { ... } [0] https://regex101.com/r/dR7xY1/1
Jun 08 2016
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/
this is exactly what i could make good use of for my scripting stuff. thank you for implementing
Jun 07 2016
prev sibling next sibling parent earthfront <earthfront safetymail.info> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages
So nice. Thanks so much! This is great for solutions to project euler problems!
Jun 07 2016
prev sibling next sibling parent Rory McGuire via Digitalmars-d-announce writes:
On 07 Jun 2016 11:56, "S=C3=B6nke Ludwig" <digitalmars-d-announce puremagic=
.com>
wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
for single-file packages, which can be used to write shebang-style scripts on Posix systems:
     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version=3D"~>0.0.3"
     +/

     void main()
     {
         import std.stdio : writefln;
         import std.experimental.color.conv;
         import std.experimental.color.hsx;
         import std.experimental.color.rgb;

         auto yellow =3D RGB!("rgb", float)(1.0, 1.0, 0.0);
         writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
     }

 With "chmod +x" it can then simply be run as ./colortest.d.

 Apart from that, the release contains some bug fixes, most notably it
doesn't query the registry for each build any more.
 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Awesome! Now we can do quick vibe test snippets without having to make a dub project.
Jun 07 2016
prev sibling next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 
 is...
Great work! I've spread the news to all my hackish friends.
Jun 08 2016
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Hi, I have some issue get it working on windows. I created a simple file app.d with following content: /+ dub.sdl: name "hello_world" +/ void main() { import std.stdio; writeln("Hello World!"); } while calling dub within the directory containing app.d I receive following error: Neither a package description file, nor source/app.d was found in C:\D\projects\unofficial\examples\cf-example-hello-d_sapnet - Copy Please run DUB from the root directory of an existing package, or run "dub init --help" to get information on creating a new package. No valid root package found - aborting. Kind regards André
Jun 09 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote:

 while calling dub within the directory containing app.d I
dub app.d Without passing a file name, dub will look for a project configuration.
Jun 09 2016
parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 9 June 2016 at 08:02:21 UTC, Mike Parker wrote:
 On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote:

 while calling dub within the directory containing app.d I
dub app.d Without passing a file name, dub will look for a project configuration.
Thanks for the info. In my use case this behavior is cumbersome. I created a build script for cloud foundry. Command "dub" is called for the source files uploaded to cloud foundry. This command is buried in the build script. While seeing this new feature I thought I can develop a file app.d instead of dub.json/source folder/app.d I would vote for a fallback of command dub. If there is no dub.json/dub.sdl & source folder but a app.d (convention) then as fallback dub is called with this file. Any chance for this feature request? :) As workaround I can adapt the build script to check for the files mentioned and call dub one way or the other way. Kind regards André
Jun 09 2016
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André
Jun 09 2016
next sibling parent reply drug <drug2004 bk.ru> writes:
09.06.2016 13:23, Andre Pany пишет:
 On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
 support for single-file packages, which can be used to write
 shebang-style scripts on Posix systems:

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André
Untested, but try ``` dub build app.d --build=release ```
Jun 09 2016
parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 9 June 2016 at 10:43:31 UTC, drug wrote:
 09.06.2016 13:23, Andre Pany пишет:
 Untested, but try
 ```
 dub build app.d --build=release
 ```
Unfortunately it is not working: dub answers: Failed to find a package named 'app.d'. Kind regards André
Jun 09 2016
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 09.06.2016 um 12:23 schrieb Andre Pany:
 On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is
 support for single-file packages, which can be used to write
 shebang-style scripts on Posix systems:

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André
You need to use the --single switch: dub build --single=app.d --build=release For the commandline that you have used, the arguments "build --build=release" will be passed to the compiled app.d executable instead. I'll deploy proper documentation together with the release.
Jun 09 2016
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:
 You need to use the --single switch:

 dub build --single=app.d --build=release

 For the commandline that you have used, the arguments "build 
 --build=release" will be passed to the compiled app.d 
 executable instead. I'll deploy proper documentation together 
 with the release.
Thanks :)
Jun 09 2016
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:
 You need to use the --single switch:

 dub build --single=app.d --build=release

 For the commandline that you have used, the arguments "build 
 --build=release" will be passed to the compiled app.d 
 executable instead. I'll deploy proper documentation together 
 with the release.
It is still not working. I have an easy example: ------------ file app.d --------------- /+ dub.sdl: name "app" +/ void main() { import std.stdio; writeln("ABC"); } ------------ file app.d --------------- While executing command: dub --single=app.d there is the error: Error processing arguments: Can't parse string: bool should be case-insensitive 'true' or 'false' Is this a bug? Kind regards André
Jun 13 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 13.06.2016 um 11:21 schrieb Andre Pany:
 On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:
 You need to use the --single switch:

 dub build --single=app.d --build=release

 For the commandline that you have used, the arguments "build
 --build=release" will be passed to the compiled app.d executable
 instead. I'll deploy proper documentation together with the release.
It is still not working. I have an easy example: ------------ file app.d --------------- /+ dub.sdl: name "app" +/ void main() { import std.stdio; writeln("ABC"); } ------------ file app.d --------------- While executing command: dub --single=app.d there is the error: Error processing arguments: Can't parse string: bool should be case-insensitive 'true' or 'false' Is this a bug? Kind regards André
Oh sorry, I misremembered the type of the --single switch. Should be "dub --single app.d" instead, because it's actually a boolean switch. BTW, it would be nice if std.getopt.getopt() would print the name of the argument in the error message.
Jun 13 2016
prev sibling next sibling parent Dechcaudron <no-reply no-email.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

 [...]
I've barely started using D, but dub works like a charm and makes development so easy! Thank you for creating such a great tool! :D
Jun 09 2016
prev sibling next sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 7 June 2016 at 19:54, Sönke Ludwig
<digitalmars-d-announce puremagic.com> wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for
 single-file packages, which can be used to write shebang-style scripts on
 Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

     void main()
     {
         import std.stdio : writefln;
         import std.experimental.color.conv;
         import std.experimental.color.hsx;
         import std.experimental.color.rgb;

         auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
         writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
     }

 With "chmod +x" it can then simply be run as ./colortest.d.

 Apart from that, the release contains some bug fixes, most notably it
 doesn't query the registry for each build any more.

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
Hey cool, thanks for the endorsement in your example! :P
Jun 10 2016
prev sibling next sibling parent Saurabh Das <saurabh.das gmail.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

 [...]
That is really useful! Thanks again for all the work you put into dub and Vibe.
Jun 13 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
 for single-file packages, which can be used to write shebang-style
 scripts on Posix systems:

      #!/usr/bin/env dub
      /+ dub.sdl:
          name "colortest"
          dependency "color" version="~>0.0.3"
      +/

      void main()
      {
          import std.stdio : writefln;
          import std.experimental.color.conv;
          import std.experimental.color.hsx;
          import std.experimental.color.rgb;

          auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
          writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
      }

 With "chmod +x" it can then simply be run as ./colortest.d.

 Apart from that, the release contains some bug fixes, most notably it
 doesn't query the registry for each build any more.

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
The first release candidate is out now! If nothing else comes up, the release is scheduled for next Monday. For this release, I've restricted the recipe comments to the /+ +/ style and to be the first thing in the file apart from the optional shebang line. This leaves all options open to relax the rules later without losing backwards compatibility and allows #872 [1] to be finished with less time pressure. [1]: https://github.com/dlang/dub/pull/872
Jun 15 2016
parent wobbles <grogan.colin gmail.com> writes:
On Wednesday, 15 June 2016 at 17:54:00 UTC, Sönke Ludwig wrote:
 Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:
 [...]
The first release candidate is out now! If nothing else comes up, the release is scheduled for next Monday. For this release, I've restricted the recipe comments to the /+ +/ style and to be the first thing in the file apart from the optional shebang line. This leaves all options open to relax the rules later without losing backwards compatibility and allows #872 [1] to be finished with less time pressure. [1]: https://github.com/dlang/dub/pull/872
I think that's a good choice. +1
Jun 16 2016
prev sibling parent reply mark_mcs <mark mnetcs.com> writes:
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
 DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
 support for single-file packages, which can be used to write 
 shebang-style scripts on Posix systems:

     #!/usr/bin/env dub
     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

     void main()
     {
         import std.stdio : writefln;
         import std.experimental.color.conv;
         import std.experimental.color.hsx;
         import std.experimental.color.rgb;

         auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
         writefln("Yellow in HSV: %s", 
 yellow.convertColor!(HSV!()));
     }

 With "chmod +x" it can then simply be run as ./colortest.d.

 Apart from that, the release contains some bug fixes, most 
 notably it doesn't query the registry for each build any more.

 Full change log:
 https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

 Download (Latest Preview):
 http://code.dlang.org/download
I'm not sure if this is a defect or a conscious decision so I thought I'd ask the question first. Is there a reason why Dub on Windows uses the APPDATA environment variable, rather than LOCALAPPDATA? The APPDATA variable points to the roaming profile directory which means that my entire Dub cache is uploaded when I log out, then downloaded again when I log back in. Should I raise a github issue for this? Seems like an easy fix for a 1.0.0 release.
Jun 17 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 17.06.2016 um 13:06 schrieb mark_mcs:
 I'm not sure if this is a defect or a conscious decision so I thought
 I'd ask the question first. Is there a reason why Dub on Windows uses
 the APPDATA environment variable, rather than LOCALAPPDATA? The APPDATA
 variable points to the roaming profile directory which means that my
 entire Dub cache is uploaded when I log out, then downloaded again when
 I log back in. Should I raise a github issue for this? Seems like an
 easy fix for a 1.0.0 release.
It currently stores both, the configuration and cached packages in the same folder, while it should put the configuration in APPDATA and the cached packages in LOCALAPPDATA (so it's indeed a defect). It's an easy fix, but too late in the release process now. It could go into 1.0.1, though.
Jun 17 2016