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.

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.

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.

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?

Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:
> DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
> for single-file packages, which can be used to write shebang-style
> scripts on Posix systems:
>
>      #!/usr/bin/env dub
>      /+ dub.sdl:
>          name "colortest"
>          dependency "color" version="~>0.0.3"
>      +/
>
>      void main()
>      {
>          import std.stdio : writefln;
>          import std.experimental.color.conv;
>          import std.experimental.color.hsx;
>          import std.experimental.color.rgb;
>
>          auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
>          writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
>      }
>
> With "chmod +x" it can then simply be run as ./colortest.d.
>
> Apart from that, the release contains some bug fixes, most notably it
> doesn't query the registry for each build any more.
>
> Full change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> Download (Latest Preview):
> http://code.dlang.org/download

The first release candidate is out now! If nothing else comes up, the release is scheduled for next Monday.

For this release, I've restricted the recipe comments to the /+ +/ style and to be the first thing in the file apart from the optional shebang line. This leaves all options open to relax the rules later without losing backwards compatibility and allows #872 [1] to be finished with less time pressure.

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

On Wednesday, 15 June 2016 at 17:54:00 UTC, Sönke Ludwig wrote:
> Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:
>> [...]
>
> The first release candidate is out now! If nothing else comes up, the release is scheduled for next Monday.
>
> For this release, I've restricted the recipe comments to the /+ +/ style and to be the first thing in the file apart from the optional shebang line. This leaves all options open to relax the rules later without losing backwards compatibility and allows #872 [1] to be finished with less time pressure.
>
> [1]: https://github.com/dlang/dub/pull/872

I think that's a good choice. +1

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
> DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for single-file packages, which can be used to write shebang-style scripts on Posix systems:
>
>     #!/usr/bin/env dub
>     /++ dub.sdl:
>         name "colortest"
>         dependency "color" version="~>0.0.3"
>     +/
>
>     void main()
>     {
>         import std.stdio : writefln;
>         import std.experimental.color.conv;
>         import std.experimental.color.hsx;
>         import std.experimental.color.rgb;
>
>         auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
>         writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
>     }
>
> With "chmod +x" it can then simply be run as ./colortest.d.
>
> Apart from that, the release contains some bug fixes, most notably it doesn't query the registry for each build any more.
>
> Full change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> Download (Latest Preview):
> http://code.dlang.org/download

I'm not sure if this is a defect or a conscious decision so I thought I'd ask the question first. Is there a reason why Dub on Windows uses the APPDATA environment variable, rather than LOCALAPPDATA? The APPDATA variable points to the roaming profile directory which means that my entire Dub cache is uploaded when I log out, then downloaded again when I log back in. Should I raise a github issue for this? Seems like an easy fix for a 1.0.0 release.

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.