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.

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é

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é

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

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é

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.

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

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

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.

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