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.

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

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

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

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?

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

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

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

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.

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é