Re: Release D 2.072.0
On Thursday, 10 November 2016 at 23:02:09 UTC, Soulsbane wrote:
On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
On 11/05/2016 06:04 AM, Soulsbane wrote:
[...]
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
Sorry I hadn't gotten back on this. Isolating the code like you
did doesn't produce the error. It only fails in my larger
project(same code). It's strange.
The code is in
https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d
Using struct TocParser in an empty project(just main) works
just fine. But as part of my later project(skeletor) it fails
to compile.
Thanks.
Linked wrong file.
https://github.com/Soulsbane/luaaddon/blob/7d60711b7b733144f3925a57380e58eb2aab997e/source/luaaddon/tocparser.d is the correct one.
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
On 11/05/2016 06:04 AM, Soulsbane wrote:
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
Glad to announce D 2.072.0.
http://dlang.org/changelog/2.072.0.html
-Martin
I've run into a problem with code using ctRegex that fails to
compile only in release build.
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
Sorry I hadn't gotten back on this. Isolating the code like you
did doesn't produce the error. It only fails in my larger
project(same code). It's strange.
The code is in
https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d
Using struct TocParser in an empty project(just main) works just
fine. But as part of my later project(skeletor) it fails to
compile.
Thanks.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 17:32:36 UTC, Russel Winder wrote: On Thu, 2016-11-10 at 06:52 +, Olivier Pisano via Digitalmars-d- announce wrote: I cannot read your website on Firefox 45 (no text is displayed). It works on chromium anyway. I see only some (bold?) test items, the basic text is not visible. I am using Chrome Stable 54.0.2840.90 (64-bit) on Debian Sid. This seems to be https://github.com/google/fonts/issues/206 Can't reproduce on FF 47 + Ubuntu, will probably change the font...
Re: Article: Running D without its runtime
On Thu, 2016-11-10 at 06:52 +, Olivier Pisano via Digitalmars-d- announce wrote: > I cannot read your website on Firefox 45 (no text is displayed). > It works on chromium anyway. I see only some (bold?) test items, the basic text is not visible. I am using Chrome Stable 54.0.2840.90 (64-bit) on Debian Sid. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Link Time Optimization in LDC
On Thursday, 10 November 2016 at 16:23:03 UTC, Dicebot wrote: Does that mean that cross-module/cross-package inlining with separate compilation now works? When all is compiled with `-flto=...`, yes. -Johan
Re: Link Time Optimization in LDC
On Thursday, 10 November 2016 at 16:20:33 UTC, Johan Engelen wrote: Hi all, Yesterday I merged LTO capability into LDC. Here a short article about it: https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html And the reddit thread: https://www.reddit.com/r/programming/comments/5c8p58/link_time_optimization_cd_crosslanguage/
Re: Link Time Optimization in LDC
On Thursday, 10 November 2016 at 16:20:33 UTC, Johan Engelen wrote: Hi all, Yesterday I merged LTO capability into LDC. Here a short article about it: https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html For the folks building LDC themselves: let me know your issues :) cheers, Johan Does that mean that cross-module/cross-package inlining with separate compilation now works?
Link Time Optimization in LDC
Hi all, Yesterday I merged LTO capability into LDC. Here a short article about it: https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html For the folks building LDC themselves: let me know your issues :) cheers, Johan
Re: Release D 2.072.0
On 11/05/2016 06:04 AM, Soulsbane wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
>
> I've run into a problem with code using ctRegex that fails to compile
> only in release build.
Can't reproduce:
$ cat sample.d
unittest
{
import std.regex;
static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P.*):\s*(?P.*)`;
auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}
$ dmd-dev -release -O -inline -unittest -main -run sample.d
Can you provide more details?
signature.asc
Description: OpenPGP digital signature
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote: This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there). Only possibility is just to ignore ALL cycles, and print them if any are detected. I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? The PR for this was here: https://github.com/dlang/druntime/pull/1668 Thanks! I'll have to check the code first :)
Re: Release D 2.072.0
On 11/10/16 8:26 AM, Dicebot wrote: On 11/03/2016 05:51 PM, Steven Schveighoffer wrote: On 11/3/16 10:49 AM, Johan Engelen wrote: On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle. Thanks for the detective work. I wonder where the bug is: in 2.071 or in 2.072 :) Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. It does not justify immediate breaking change. What should have been done instead: - Keep old behavior by default by default but print non-fatal runtime message that cycles are detected. This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there). Only possibility is just to ignore ALL cycles, and print them if any are detected. I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? The PR for this was here: https://github.com/dlang/druntime/pull/1668 -Steve
Re: Release D 2.072.0
On 11/03/2016 05:51 PM, Steven Schveighoffer wrote: > On 11/3/16 10:49 AM, Johan Engelen wrote: >> On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: >>> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... >>> >>> Maybe after this: >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 >>> >>> >>> >>> ddmd.attribs was removed >>> >>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 >>> >>> >>> >>> and it was also part of the cycle. >> >> Thanks for the detective work. >> I wonder where the bug is: in 2.071 or in 2.072 :) > > Any cycles that are "newly discovered" were already there. What was > happening is that the runtime did not detect the cycle, and was > arbitrarily choosing an order for initializing these modules. It does not justify immediate breaking change. What should have been done instead: - Keep old behavior by default by default but print non-fatal runtime message that cycles are detected. - Provide options both to make cycle detection fatal and to suppress message completely. - Make fatal one the default one release later I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this? signature.asc Description: OpenPGP digital signature
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 11:11:17 UTC, Guillaume Piolat wrote: On Thursday, 10 November 2016 at 06:52:12 UTC, Olivier Pisano wrote: I cannot read your website on Firefox 45 (no text is displayed). It works on chromium anyway. I develop it on Firefox. What is your OS? I am on Debian Jessie, with Firefox ESR 45.4.0.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 11:31:43 UTC, ag0aep6g wrote: On 11/10/2016 12:21 PM, Guillaume Piolat wrote: Thanks. Are you behind a proxy? I've had such reports before. Nope. No proxy. I'll check with Ubuntu + Firefox in about 10 hours
Re: Article: Running D without its runtime
On 11/10/2016 12:21 PM, Guillaume Piolat wrote: Thanks. Are you behind a proxy? I've had such reports before. Nope. No proxy.
Re: Article: Running D without its runtime
Thanks for reading! On Thursday, 10 November 2016 at 06:08:22 UTC, thedeemon wrote: This is the schizophrenic part of D, since allocations inside destructors are not allowed by its own runtime and cause immediate stop of the program. But this restriction is only there when called by the GC. If you have GC and a deterministic object graph, it can be completely safe to allocate in destructor. I feel this is a separate problem, "GC calling destructors". And exceptions in destructors should not be allowed: there is no sane place to catch and handle exceptions arising during the GC phase (which can be triggered by arbitrary allocation anywhere in the code), so if we can't reason about them and handle them we shouldn't allow them. Good point.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 11:20:38 UTC, ag0aep6g wrote: On 11/10/2016 12:11 PM, Guillaume Piolat wrote: On Thursday, 10 November 2016 at 06:52:12 UTC, Olivier Pisano wrote: I cannot read your website on Firefox 45 (no text is displayed). It works on chromium anyway. I develop it on Firefox. What is your OS? I'm on Ubuntu 16.04 and the text is missing for me too. Seems to be an issue with the Fira Sans font. Thanks. Are you behind a proxy? I've had such reports before.
Re: Article: Running D without its runtime
On 11/10/2016 12:11 PM, Guillaume Piolat wrote: On Thursday, 10 November 2016 at 06:52:12 UTC, Olivier Pisano wrote: I cannot read your website on Firefox 45 (no text is displayed). It works on chromium anyway. I develop it on Firefox. What is your OS? I'm on Ubuntu 16.04 and the text is missing for me too. Seems to be an issue with the Fira Sans font.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 10:30:36 UTC, qznc wrote: On Thursday, 10 November 2016 at 00:56:02 UTC, Guillaume Piolat wrote: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html "Our products now run with the D language runtime disabled. This post is both a post-mortem and tutorial on how to live without the D runtime. " For runtime users the good news is that speed is already fine. :) The hacks you needed to go through are ugly. Any ideas how this could be improved? Barely. I'm not wise enough to know what this would imply. In my uninformed opinion, making attribute inference work on destroy() and making class destructors "nothrow @nogc" would go a long way. As it is, doing D without the runtime isolates you in a tiny universe. About exceptions, if we modify Throwable to have a "release()" virtual function called (or better own an allocator?), then we could have the caller catch exception regardless of how they are allocated.
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 06:52:12 UTC, Olivier Pisano wrote: I cannot read your website on Firefox 45 (no text is displayed). It works on chromium anyway. I develop it on Firefox. What is your OS?
Re: Article: Running D without its runtime
On Thursday, 10 November 2016 at 00:56:02 UTC, Guillaume Piolat wrote: https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html "Our products now run with the D language runtime disabled. This post is both a post-mortem and tutorial on how to live without the D runtime. " For runtime users the good news is that speed is already fine. :) The hacks you needed to go through are ugly. Any ideas how this could be improved? (animated background ag...)
