If no regressions show up in this RC, the final release will be made on the upcoming Sunday. The main additions are support for SDLang [1] package recipes [2] and a vastly improved "dub describe".

Download:
http://code.dlang.org/download

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

[1]: http://sdl.ikayzo.org/display/SDL/Home
[2]: http://code.dlang.org/package-format?lang=sdl

On Monday, 14 September 2015 at 11:45:13 UTC, Sönke Ludwig wrote:
> If no regressions show up in this RC, the final release will be made on the upcoming Sunday. The main additions are support for SDLang [1] package recipes [2] and a vastly improved "dub describe".
>
> Download:
> http://code.dlang.org/download
>
> Change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> [1]: http://sdl.ikayzo.org/display/SDL/Home
> [2]: http://code.dlang.org/package-format?lang=sdl

It would be great if https://github.com/D-Programming-Language/dub/pull/638 would be merged, it contains multiple fixes for being able to use LDC.

One of the commit here is controversial, but it wouldn't happen if DUB wouldn't pass multiple -march flags to compilers (DMD support redundant -m32/-m64, LDC doesn't).

Am 14.09.2015 um 13:59 schrieb ponce:
> It would be great if
> https://github.com/D-Programming-Language/dub/pull/638 would be merged,
> it contains multiple fixes for being able to use LDC.
>
> One of the commit here is controversial, but it wouldn't happen if DUB
> wouldn't pass multiple -march flags to compilers (DMD support redundant
> -m32/-m64, LDC doesn't).

It's probably a good idea to leave this for a quick follow-up release, some questions are still open and the fix will require some more through testing, which would further delay this release.

BTW, it's rc.4, not rc.3.

On 09/14/2015 07:45 AM, Sönke Ludwig wrote:
> If no regressions show up in this RC, the final release will be made on
> the upcoming Sunday. The main additions are support for SDLang [1]
> package recipes [2] and a vastly improved "dub describe".

This one really should be included so it doesn't end up as a breaking change later on:

https://github.com/D-Programming-Language/dub/pull/644

And not having this one would be problematic for me, although you mentioned a possible quick follow-up release, which I guess would be fine if really, really necessary:

https://github.com/D-Programming-Language/dub/pull/633

On Monday, 14 September 2015 at 11:45:13 UTC, Sönke Ludwig wrote:
> If no regressions show up in this RC, the final release will be made on the upcoming Sunday. The main additions are support for SDLang [1] package recipes [2] and a vastly improved "dub describe".
>
> Download:
> http://code.dlang.org/download
>
> Change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> [1]: http://sdl.ikayzo.org/display/SDL/Home
> [2]: http://code.dlang.org/package-format?lang=sdl

Looking forward to having a stable release of dub that compiles with 2.068.x

On 09/14/2015 07:45 AM, Sönke Ludwig wrote:
> SDLang [1]
> [...]
> [1]: http://sdl.ikayzo.org/display/SDL/Home

That site is down at the moment (I've contacted the owner). But in the meantime, a mirror of the site is available at The Wayback Machine (web.archive.org):

https://web.archive.org/web/20150511173850/http://sdl.ikayzo.org/display/SDL/Home

On Monday, 14 September 2015 at 11:45:13 UTC, Sönke Ludwig wrote:
> If no regressions show up in this RC, the final release will be made on the upcoming Sunday. The main additions are support for SDLang [1] package recipes [2] and a vastly improved "dub describe".
>
> Download:
> http://code.dlang.org/download
>
> Change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> [1]: http://sdl.ikayzo.org/display/SDL/Home
> [2]: http://code.dlang.org/package-format?lang=sdl

I find that the feature to get a particular property (`--data=X`) is very slow, is it normal ? On a decently recent machine it takes something like 3 or 4 seconds. Maybe it downloads or check the deps while it's not necessary ?

On 09/18/2015 04:37 AM, BBasile wrote:
>
> I find that the feature to get a particular property (`--data=X`) is
> very slow, is it normal ? On a decently recent machine it takes
> something like 3 or 4 seconds. Maybe it downloads or check the deps
> while it's not necessary ?

It still has to do all the usual processing to read dub.json/dub.sdl and build up all the package information for the current package and all dependencies. Should be about the same as plain old "dub describe".

I suppose for some information that might not be strictly necessary, but I suspect that adjusting dub's package-information-gathering to be more lazy might take some major refactoring. And I'm not sure how much that would realistically gain in typical real-world scenarios.

If you need multiple pieces of information, you can specify `--data=X` multiple times in the same call to dub. Or a comma-separated list: `--data=X,Y,X`. That way the up-front processing would only be needed once, and not repeated for each piece of data.

On Friday, 18 September 2015 at 14:59:34 UTC, Nick Sabalausky wrote:
> On 09/18/2015 04:37 AM, BBasile wrote:
>>
>> I find that the feature to get a particular property (`--data=X`) is
>> very slow, is it normal ? On a decently recent machine it takes
>> something like 3 or 4 seconds. Maybe it downloads or check the deps
>> while it's not necessary ?
>
> It still has to do all the usual processing to read dub.json/dub.sdl and build up all the package information for the current package and all dependencies. Should be about the same as plain old "dub describe".
>
> I suppose for some information that might not be strictly necessary, but I suspect that adjusting dub's package-information-gathering to be more lazy might take some major refactoring. And I'm not sure how much that would realistically gain in typical real-world scenarios.
>
> If you need multiple pieces of information, you can specify `--data=X` multiple times in the same call to dub. Or a comma-separated list: `--data=X,Y,X`. That way the up-front processing would only be needed once, and not repeated for each piece of data.

I see. This extra latency also exists when we build but usually people don't notice it because they would think it's due to compilation.

I thought I could use this feature in Coedit (https://github.com/BBasile/Coedit/issues/10) rather than making a custom (and possibly erroneous) interpretation of a DUB project file but honestly with this problem I don't see how this switch can be used.