=?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:


     /++ 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

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:


     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

I love that as a feature! Thanks for adding that.

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!

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:


     /++ 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!

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:


     /++ dub.sdl:
         name "colortest"
         dependency "color" version="~>0.0.3"
     +/

Hmm... `/++` is for DDoc. Is this a good idea? Does it matter?

=?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:


     /++ 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.

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

=?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).

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

=?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.

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

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:


// dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"

=?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:


 // 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.

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:


 // 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.

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

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

=?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!).

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?

=?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

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

=?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.

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

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

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.

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

 the dub file definition?

I think this is fine as a requirement.

-Steve

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

 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 {

assertThrown!Exception(SingleFilePackage("/* dub.json: {} */void main(){}"));
// missing dub recipe

main(){}"));
// single file package must contain code

// documentation style comments not supported for dub recipe comment

*/void main(){}"));
// documentation style comments not supported for dub recipe comment

+/void main(){}"));
// unclosed dub recipe comment

/void main(){}"));


{name:\"*\"} */void main(){}"));

some sdl comment */ +/void main(){}"));

*/void main(){}"));

*/void main(){}"));
}

=?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.

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.

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.

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?

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

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.

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.

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.

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?

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:

/**
 * 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

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:

 /**
  * 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

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:

 /**
  * 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

meppl <mephisto nordhoff-online.de> writes:

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:

     /++ 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

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!

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:

     /++ 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.

=?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.

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é

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.

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é

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é

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
```

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é

=?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.

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 :)

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é

=?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.

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

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:


     /++ 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

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.

=?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:


      /+ 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 

less time pressure.

[1]: https://github.com/dlang/dub/pull/872

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 


 [1]: https://github.com/dlang/dub/pull/872

I think that's a good choice. +1

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:


     /++ 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.

=?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.