Re: Article about D in the iX magazine
On 2019-12-20 21:26:00 +, Andre Pany said: In the new iX (1 Januar 2020) there is also a Leserbrief for the article;) Even there are only few comments, every comment helps. It's very hard to convince programmers to give something else a try and stay to it long enough to see the light. Most of the time, evangelizing is very frustrating. The better strategy from my experience is: Deliver a cool product and than tell everyone "we are 10 times more productive than our competitors while delivering a better product." You can be sure, everyone wants to know how you do it. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Beta 2.090.0
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
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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.
Re: Beta 2.090.0
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?
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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.
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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.
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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
Re: Beta 2.090.0
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.
Re: Beta 2.090.0
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
Re: Article about D in the iX magazine
On Sunday, 22 December 2019 at 13:05:02 UTC, Robert M. Münch wrote: On 2019-12-20 21:26:00 +, Andre Pany said: In the new iX (1 Januar 2020) there is also a Leserbrief for the article;) Even there are only few comments, every comment helps. It's very hard to convince programmers to give something else a try and stay to it long enough to see the light. Most of the time, evangelizing is very frustrating. The better strategy from my experience is: Deliver a cool product and than tell everyone "we are 10 times more productive than our competitors while delivering a better product." You can be sure, everyone wants to know how you do it. I think it's much better to spend most time on those receptive to it anyway, which is a very small proportion of the programmers many people might know in real life. The beauty of being the challenger is you can keep growing by persuading only a small proportion of people who were already poised on the edge or would be if they knew of D. Yes - I agree that delivering value speaks the loudest. But of course in a competitive market it's not necessarily going to be something people discuss. It's outside the reality of many others, what can be achieved with D, and at the same time you don't necessarily want to actually make it vivid to your competitors how they could do what you did. I think also that enthusiasm and working code might be more effective than logic and feature comparison. The biggest asset the D community has might be the calibre of people that are drawn to it and that stick with it...
