www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DUB release candidate 0.9.24-rc.3 ready for testing

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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
Sep 14 2015
next sibling parent reply ponce <contact gam3sfrommars.fr> writes:
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).
Sep 14 2015
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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.
Sep 14 2015
prev sibling next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
BTW, it's rc.4, not rc.3.
Sep 14 2015
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
Sep 14 2015
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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
Sep 15 2015
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
Sep 15 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 15.09.2015 um 18:56 schrieb Nick Sabalausky:

 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


Unfortunately the mirror is not available anymore, because /robots.txt 
also yields garbage and web.archive.org takes that as "no crawling 
allowed"...
Sep 21 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/21/2015 05:44 AM, Sönke Ludwig wrote:

 Am 15.09.2015 um 18:56 schrieb Nick Sabalausky:

 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


 Unfortunately the mirror is not available anymore, because /robots.txt
 also yields garbage and web.archive.org takes that as "no crawling
 allowed"...


Luckily, I'd grabbed a copy of the mirror before it went down from 
web.archive.org. I've now fixed the internal linking and put it up on my 
server:

http://semitwist.com/sdl-mirror/Home.html

I'd still like to put together my own description of the spec when I can 
get to it:

https://github.com/Abscissa/SDLang-D/issues/32
Sep 23 2015
prev sibling parent reply BBasile <bb.temp gmx.com> writes:
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 ?
Sep 18 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 18 2015
parent BBasile <bb.temp gmx.com> writes:
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.
Sep 18 2015
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 18.09.2015 um 10:37 schrieb BBasile:

 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 ?


In the context of an IDE, I'd strongly recommend to use the normal "dub 
describe" functionality. The "packages" field will list the logical 
packages, suitable for display in the IDE's project tree and the 
"targets" field will contain the list of binary targets, suitable as the 
input for external build tools. All of this comes at once with a single 
process invocation.

The --data= functionality is more useful for shell scripts and the like, 
where data is needed in condensed form. I'm also pretty sure that there 
are still some issues to work out in the way the --data switch works, 
because in its current form it simply cannot represent everything. So 
I'd label this feature as experimental for now.

There are some things that may take time during a DUB run:
  - Determining the versions of local GIT working copies that are 
registered with "add-path" or "add-local". "git" is invoked for that for 
each working copy, which simply takes time if there are many of those 
registered. I'm currently looking into a version cache feature that 
would make this faster.
  - Querying code.dlang.org for new package versions to display upgrade 
suggestions. This takes a moment, but is only done at most once a day.
  - Resolving dependencies currently suffers from a performance bug that 
can cause the resolution time to grow almost indefinitely.

To see which of those is responsible, running with the -v switch may 
give some insights.
Sep 21 2015
parent BBasile <bb.temp gmx.com> writes:
On Monday, 21 September 2015 at 09:42:44 UTC, Sönke Ludwig wrote:

 Am 18.09.2015 um 10:37 schrieb BBasile:

 [...]


 In the context of an IDE, I'd strongly recommend to use the 
 normal "dub describe" functionality. The "packages" field will 
 list the logical packages, suitable for display in the IDE's 
 project tree and the "targets" field will contain the list of 
 binary targets, suitable as the input for external build tools. 
 All of this comes at once with a single process invocation.

 The --data= functionality is more useful for shell scripts and 
 the like, where data is needed in condensed form. I'm also 
 pretty sure that there are still some issues to work out in the 
 way the --data switch works, because in its current form it 
 simply cannot represent everything. So I'd label this feature 
 as experimental for now.

 There are some things that may take time during a DUB run:
  - Determining the versions of local GIT working copies that 
 are registered with "add-path" or "add-local". "git" is invoked 
 for that for each working copy, which simply takes time if 
 there are many of those registered. I'm currently looking into 
 a version cache feature that would make this faster.
  - Querying code.dlang.org for new package versions to display 
 upgrade suggestions. This takes a moment, but is only done at 
 most once a day.
  - Resolving dependencies currently suffers from a performance 
 bug that can cause the resolution time to grow almost 
 indefinitely.

 To see which of those is responsible, running with the -v 
 switch may give some insights.


Don't bother with this problem if there is only one complain.

Finally my IDE fully interprets the JSON. I think that even if 
you would manage to make the process faster there's still be this 
*little too much* that makes it unsable in Coedit because in the 
dedicated widget DUB properties are modifiable, can be added or 
removed from the GUI.
Sep 21 2015