www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta 2.090.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 
contributors.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.090.0.html

As usual please report any bugs at
https://issues.dlang.org

-Martin
Dec 22 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 23/12/2019 4:23 AM, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 
 contributors.
 
 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html
 
 As usual please report any bugs at
 https://issues.dlang.org
 
 -Martin


404'ing
Dec 22 2019
parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 22 December 2019 at 15:27:15 UTC, rikki cattermole 
wrote:

 On 23/12/2019 4:23 AM, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.
 
 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html
 
 As usual please report any bugs at
 https://issues.dlang.org
 
 -Martin


 404'ing


The changelog, that is.
Dec 22 2019
prev sibling next sibling parent reply berni44 <dlang d-ecke.de> writes:
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.


I'm wondering, why I'm listed twice there (as Bernhard Seckinger 
and as berni44). IMHO berni44 should not have been listed 
there... Do I have to change something in my git settings to get 
this right?
Dec 22 2019
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Sunday, 22 December 2019 at 18:51:45 UTC, berni44 wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.


 I'm wondering, why I'm listed twice there (as Bernhard 
 Seckinger and as berni44). IMHO berni44 should not have been 
 listed there... Do I have to change something in my git 
 settings to get this right?


Probably differen email addresses. You can set an email address 
locally for the repository in .git/config. Or just add an alias: 
https://github.com/dlang/tools/blob/master/.mailmap
Dec 22 2019
parent reply berni44 <dlang d-ecke.de> writes:
On Sunday, 22 December 2019 at 19:00:15 UTC, Eugene Wissner wrote:

 Probably differen email addresses. You can set an email address 
 locally for the repository in .git/config. Or just add an 
 alias: https://github.com/dlang/tools/blob/master/.mailmap


git config -l reveals only one address (which is set at global 
level; there is no local and no systemwide email address). It's 
the same I use in github. In bugzilla I use a different one, but 
I guess, that this is not relevant.
Dec 22 2019
parent Seb <seb wilzba.ch> writes:
On Sunday, 22 December 2019 at 20:30:06 UTC, berni44 wrote:

 On Sunday, 22 December 2019 at 19:00:15 UTC, Eugene Wissner 
 wrote:

 Probably differen email addresses. You can set an email 
 address locally for the repository in .git/config. Or just add 
 an alias: https://github.com/dlang/tools/blob/master/.mailmap


 git config -l reveals only one address (which is set at global 
 level; there is no local and no systemwide email address). It's 
 the same I use in github. In bugzilla I use a different one, 
 but I guess, that this is not relevant.


It looks like you made a commit via the GitHub UI. By default it 
uses a default generated (<...> users.noreply.github.com) email 
address. You can change this in your GitHub user settings.

Anyhow, I went ahead and made a PR to "reduce" you to only one 
person ;-)

https://github.com/dlang/tools/pull/388

For future readers, here's how I found out the other email 
address:

$ ./contributors.d -f git "v2.075.0..master" | grep -i berni
Dec 23 2019
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 22 December 2019 at 18:51:45 UTC, berni44 wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.


 I'm wondering, why I'm listed twice there (as Bernhard 
 Seckinger and as berni44). IMHO berni44 should not have been 
 listed there... Do I have to change something in my git 
 settings to get this right?


You can submit a PR to add a mapping to tools/.mailmap:

https://github.com/dlang/tools/blob/master/.mailmap
https://github.com/git/git/blob/master/Documentation/mailmap.txt
Dec 22 2019
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org

 -Martin


The unittest default mode might cause some issues for unittest 
frameworks like d-unit. They need a main but due to a dub bug, 
passing DRT affects the Dub executable but not the spawned 
application. Open bug issue 
https://github.com/dlang/dub/issues/1280

Kind regards
Andre
Dec 22 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/22/19 2:17 PM, Andre Pany wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 
 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org


 
 The unittest default mode might cause some issues for unittest 
 frameworks like d-unit. They need a main but due to a dub bug, passing 
 DRT affects the Dub executable but not the spawned application. Open bug 
 issue https://github.com/dlang/dub/issues/1280
 


I haven't tested, but the frameworks should be fine. They override the 
behavior (i.e. register a different handler for unittests)

The switch only affects vanilla D unittest handler behavior.

In other words, if you use e.g. unitthreaded or dub's test build, the 
switch is of no consequence.

-Steve
Dec 22 2019
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/22/19 4:04 PM, Steven Schveighoffer wrote:

 I haven't tested, but the frameworks should be fine.


FYI, here is where d-unit overrides the behavior:

https://github.com/linkrope/dunit/blob/e78971a27395169158458e3ab1c35b61c67079f4/src/dunit/framework.d#L772-L775

Doing this prevents any unittest from being run before main, so the 
default behavior will be ignored.

-Steve
Dec 22 2019
prev sibling next sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org

 -Martin


I've gotten very used to running my app via

     dub run --compiler=dmd --build=unittest

in order to, with short iterations, run tests and the application 
at the same time.

Changing this behaviour via

https://dlang.org/changelog/2.090.0.html#unittest-default

is, to me, an usually disruptive change.

I tried changing to

     dub run --compiler=dmd --build=unittest -- 
--DRT-testmode=run-main

but it still doesn't run the application after the unittests are 
run.

Have I missed something or is this a known problem with dub? If 
so, do I have any alternative to brute-forcing the problem with

     dub run --compiler=dmd --build=unittest
     dub run --compiler=dmd --build=debug

which, for me, doubles my development iteration time.
Dec 22 2019
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/22/19 5:22 PM, Per Nordlöw wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 
 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org


 
 I've gotten very used to running my app via
 
      dub run --compiler=dmd --build=unittest
 
 in order to, with short iterations, run tests and the application at the 
 same time.
 
 Changing this behaviour via
 
 https://dlang.org/changelog/2.090.0.html#unittest-default
 
 is, to me, an usually disruptive change.


It's a long overdue change IMO. The original intention was to have it 
switched on version 2.080, but I forgot about it. Most of the time, if 
you are unittesting, you aren't building exactly production code, so 
there's no reason to run the main function.

Most people used to do this:

```
version(unittest) void main() {}
else
int main(string[] args) {
    ... // normal application
}
```

Which is somewhat embarrassing for the language to have to do this.


 
 I tried changing to
 
      dub run --compiler=dmd --build=unittest -- --DRT-testmode=run-main
 
 but it still doesn't run the application after the unittests are run.


The issue is that dub is built with D! So dub is actually consuming that 
option without trying to.

There's an open bug on it: https://github.com/dlang/dub/issues/1280


 Have I missed something or is this a known problem with dub? If so, do I 
 have any alternative to brute-forcing the problem with
 
      dub run --compiler=dmd --build=unittest
      dub run --compiler=dmd --build=debug
 
 which, for me, doubles my development iteration time.


Option a: don't use dub run.

dub build --compiler=dmd --build=unittest && ./application 
--DRT-testmode=run-main

Option b: you can also set a DRT switch inside your code:

https://dlang.org/phobos/rt_config.html

e.g.:

extern(C) __gshared string[] rt_options = [ "testmode=run-main"];

There are far more people who run unittests as a separate step from 
running their application. If unittests pass, then there's no 
distinguishable output from a build without unittests. I can totally 
imagine accidentally shipping code with unittests in it without 
intending to.

But I can totally see your use case during development. It should work 
with dub run, I hope it gets fixed.

-Steve
Dec 22 2019
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer 
wrote:

 extern(C) __gshared string[] rt_options = [ 
 "testmode=run-main"];

 There are far more people who run unittests as a separate step 
 from running their application. If unittests pass, then there's 
 no distinguishable output from a build without unittests. I can 
 totally imagine accidentally shipping code with unittests in it 
 without intending to.


Thanks.

So what is now the difference between

     dub run --build=unittest

and

     dub test

?
Dec 23 2019
next sibling parent reply Soulsbane <paul acheronsoft.com> writes:
On Monday, 23 December 2019 at 21:59:42 UTC, Per Nordlöw wrote:

 On Sunday, 22 December 2019 at 23:05:20 UTC, Steven 
 Schveighoffer wrote:

 extern(C) __gshared string[] rt_options = [ 
 "testmode=run-main"];

 There are far more people who run unittests as a separate step 
 from running their application. If unittests pass, then 
 there's no distinguishable output from a build without 
 unittests. I can totally imagine accidentally shipping code 
 with unittests in it without intending to.


 Thanks.

 So what is now the difference between

     dub run --build=unittest

 and

     dub test

 ?


dub test doesn't run the actual program only unittests are far as 
I can tell.
Dec 23 2019
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 24 December 2019 at 05:59:35 UTC, Soulsbane wrote:

 dub test doesn't run the actual program only unittests are far 
 as I can tell.


Correct, but that is from 2.090 the behaviour of

     dub run --build=unittest

aswell. This seems strange to me.

I would like to see a new built-in build target in dub, say

     dub run --build=unittest-debug

, that mimics the behaviour of

     dub run --build=unittest

prior to 2.090.
Dec 24 2019
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/23/19 4:59 PM, Per Nordlöw wrote:

 On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer wrote:

 extern(C) __gshared string[] rt_options = [ "testmode=run-main"];

 There are far more people who run unittests as a separate step from 
 running their application. If unittests pass, then there's no 
 distinguishable output from a build without unittests. I can totally 
 imagine accidentally shipping code with unittests in it without 
 intending to.


 
 Thanks.
 
 So what is now the difference between
 
      dub run --build=unittest
 
 and
 
      dub test
 
 ?


dub test adds its own main function and unittest handler (and actually 
the function is based on the old unittest system, so it won't print the 
tests run or number of failures. It usually only works for libraries 
which don't have a main function.

-Steve
Dec 25 2019
prev sibling parent reply Mathias Lang <pro.mathias.lang gmail.com> writes:
On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote:

 Have I missed something or is this a known problem with dub? If 
 so, do I have any alternative to brute-forcing the problem with

     dub run --compiler=dmd --build=unittest
     dub run --compiler=dmd --build=debug

 which, for me, doubles my development iteration time.


If it's something common enough, I suggest just creating an alias 
such as `dubtest` which does `dub test --compiler=dmd && dub run 
--compiler --build=debug`.
Should you want to change compiler, you can make it a function 
that takes an argument.

The druntime issue with `--DRT` is something that is on the map, 
and should be fixed soon, but I can't promise it will be fixed 
before the release, as it requires a druntime fix.
Alternatively, some other bugs need to be fixed for the druntime 
fix to be truly efficient.
Dec 22 2019
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/22/19 8:23 PM, Mathias Lang wrote:

 On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote:

 Have I missed something or is this a known problem with dub? If so, do 
 I have any alternative to brute-forcing the problem with

     dub run --compiler=dmd --build=unittest
     dub run --compiler=dmd --build=debug

 which, for me, doubles my development iteration time.


 
 If it's something common enough, I suggest just creating an alias such 
 as `dubtest` which does `dub test --compiler=dmd && dub run --compiler 
 --build=debug`.
 Should you want to change compiler, you can make it a function that 
 takes an argument.
 
 The druntime issue with `--DRT` is something that is on the map, and 
 should be fixed soon, but I can't promise it will be fixed before the 
 release, as it requires a druntime fix.
 Alternatively, some other bugs need to be fixed for the druntime fix to 
 be truly efficient.


The solution is already available since 2.084. Dub just needs to ignore 
DRT options.

See info about rt_cmdline_enabled here: 
https://dlang.org/phobos/rt_config.html

-Steve
Dec 22 2019
prev sibling next sibling parent reply berni44 <dlang d-ecke.de> writes:
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 As usual please report any bugs at
 https://issues.dlang.org


Not sure, if this is a bug, but --DRT-testmode=run-main seems to 
have no effect here.

Example:

---
import std.stdio;

unittest
{
     assert(1==1);
}

void main(string[] argv)
{
     writeln("X");
}
---

$> dmd -unittest -g -run test.d
1 unittests passed
$> dmd -unittest --DRT-testmode=run-main -g -run test.d
1 unittests passed

In both cases main is not executed. I thought, in the second one 
it should...
Dec 26 2019
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On Thursday, 26 December 2019 at 10:20:27 UTC, berni44 wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 As usual please report any bugs at
 https://issues.dlang.org


 Not sure, if this is a bug, but --DRT-testmode=run-main seems 
 to have no effect here.

 Example:

 ---
 import std.stdio;

 unittest
 {
     assert(1==1);
 }

 void main(string[] argv)
 {
     writeln("X");
 }
 ---

 $> dmd -unittest -g -run test.d
 1 unittests passed
 $> dmd -unittest --DRT-testmode=run-main -g -run test.d


DRT switches are runtime switches

./test --DRT-testmode=run-main

What you did was to pass the DRT switch to DMD itself.

-Steve
Dec 26 2019
parent berni44 <dlang d-ecke.de> writes:
On Thursday, 26 December 2019 at 14:16:50 UTC, Steven 
Schveighoffer wrote:

 DRT switches are runtime switches

 ./test --DRT-testmode=run-main


Aaah. Did not know about runtime switches...
Dec 26 2019
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to 
 the 48 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org

 -Martin


Release candidate is live now.
Dec 30 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30/12/2019 12:07, Martin Nowak wrote:

 On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote:

 Glad to announce the first beta for the 2.090.0 release, ♥ to the 48
 contributors.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.090.0.html

 As usual please report any bugs at
 https://issues.dlang.org

 -Martin


 
 Release candidate is live now.


The windows build is still considered "dirty", i.e.it reports version
DMD32 D Compiler v2.090.0-rc.1-dirty.

Is there something that can be done about that?
Dec 30 2019
parent berni44 <dlang d-ecke.de> writes:
On Monday, 30 December 2019 at 22:41:51 UTC, Rainer Schuetze 
wrote:

 The windows build is still considered "dirty", i.e.it reports 
 version DMD32 D Compiler v2.090.0-rc.1-dirty.

 Is there something that can be done about that?


Not sure, if that's the reason, but:

Merge https://github.com/dlang/phobos/pull/7331. This PR is 
allready merged into master (the wrong target was my mistake) and 
should have been merged into stable. This PR corrects this. (It 
fixes an issue on machines, where real==double).
Jan 01 2020