[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

--- Comment #9 from Nemanja Boric <4bur...@gmail.com> ---
Thanks to GitHub bot, I am reminded about this issue. I'm back and will start
looking next week.

--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|4bur...@gmail.com

--

[Issue 17224] Foreach documentation still refers to TypeTuples, rather than AliasSequences

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17224

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17224] Foreach documentation still refers to TypeTuples, rather than AliasSequences

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17224

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/2df413227674c312cd48100046472c220d51fac7
Fix Issue 17224 - Foreach documentation still refers to TypeTuples, rather than
AliasSequences

https://github.com/dlang/dlang.org/commit/456e5cd1da516683a90f4ff0a24d45f33f21196e
Merge pull request #1701 from wilzbach/fix-17224

Fix Issue 17224 - Foreach documentation still refers to TypeTuples, rather than
AliasSequences
merged-on-behalf-of: Vladimir Panteleev 

--

[Issue 17262] Better docs for rdmd

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17262

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/e11129de676d9c563476f44f60cc71c793dcb3ef
Issue 17262 - Better docs for rdmd

https://github.com/dlang/tools/commit/f01bcafa8cd8d6102cabc4f4aa9deca037e0231c
Merge pull request #232 from wilzbach/fix-17262

Issue 17262 - Better docs for rdmd
merged-on-behalf-of: Vladimir Panteleev 

--

Re: D Language Front-End Proposed For GCC 8, 800k Lines of Code

[Iain Buclaw via Digitalmars-d]

On Saturday, 17 June 2017 at 23:00:49 UTC, Joakim wrote:

On Saturday, 17 June 2017 at 21:48:31 UTC, Mark wrote:

On Sunday, 28 May 2017 at 19:23:04 UTC, Nordlöw wrote:

Does this, perchance, deserve a post in "Announce"? :)

http://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC


800k lines of code! Wow. Is this also how big the DMD frontend 
is?


No, Dscanner says the current ddmd frontend is about 84 klocs 
of D code, and I found last year that about 63 klocs of that 
was used by ldc, so that's what's really needed:


http://forum.dlang.org/thread/ovkhtsdzlfzqrqneo...@forum.dlang.org

I don't think this patch would be using the ddmd frontend 
though, as gdc was still using the older C++ frontend last I


Doesn't make much difference whether in C++ or D.

heard, but without having looked at the patch at all, the big 
difference is probably that they're counting druntime and


The link in the article is to the patch series posting, which 
includes only the patch summary and diff stat. If you haven't 
read it then I highly recommend that you do.



phobos also, and misrepresenting that as part of the frontend.


About 90% of that is the combination of dmd frontend, testsuite, 
druntime, phobos - i.e files that are copied verbatim from dlang 
on github.  Then half of the remainder is roughly auto generated 
content.



Regards,
Iain.

[Issue 17305] [SPEC] ABI page still has references to D1 Phobos

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17305

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/dc5e167b034348d80b8fdadbb149a2426930c8e4
Fix Issue 17305 - [SPEC] ABI page still has references to D1 Phobos

https://github.com/dlang/dlang.org/commit/a9b91a67f822f6febcd61698da61c5cb677a78e9
Merge pull request #1698 from wilzbach/fix-17305

Fix Issue 17305 - [SPEC] ABI page still has references to D1 Phobos
merged-on-behalf-of: Vladimir Panteleev 

--

[Issue 17305] [SPEC] ABI page still has references to D1 Phobos

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17305

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17322] Add Magikcraft to organizations using D

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17322

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
Josh, could you please provide some feedback in the PR linked above?

--

Re: Replacing Make for the DMD build

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 17 June 2017 at 21:49:29 UTC, Walter Bright wrote:
It's not quite the same. I spend 99.99% of my time programming 
working with code, not makefiles.


Martin and Sebastian can correct me if I'm wrong, but unless I 
am, Martin, Sebastian, and myself spend a scary amount of time 
wrestling with makefiles. We have had bad production issues due 
to makefiles, such as missing dependencies causing inconsistent 
or broken builds (notably observable when something works only 
without -j), typos or undefined variables resulting in bugs being 
silently ignored (hey, I filed a PR to fix one of those not half 
an hour ago - dmd#6916), CI checks being accidentally completely 
switched off (which happened more than once!), the win32.mak / 
win64.mak / posix.mak mess, super-ugly hacks due to limitations 
of Make that slow down the build unconditionally and/or make 
everything much more fragile and complicated... and I could go on.


Which is not to say that I think we need to get off makefiles 
ASAP. Migrating to anything else is going to undoubtedly incur a 
massive migration cost and for a long time, a big maintenance 
cost (especially if it involves dogfooding). I agree with many of 
your arguments as well.


I think you're not encountering much of the problems with 
makefiles because you're mainly dealing with DMD, whose build 
process is relatively simple - and even there, the build process 
is mostly maintained these days by other people. In comparison, 
the build process for dlang.org has been getting much more 
complicated with time (partially because of some technical debt 
and fragmentation, but also simply because we want to do more 
things like nice runnable examples, various pre-processing / 
post-processing / validation, building the spec from the compiler 
source, etc.


If anyone wants to SERIOUSLY propose a plan to migrate from 
makefiles, I'd be interested to look at it. However, its benefits 
obviously must outweigh the maintenance costs of current 
makefiles, as well as not raising the contribution barrier too 
much.


Some requirements would be:

- Obvious syntax - making a change such as adding a new target or 
dependency should be obvious just from looking at the existing 
code.


- Performance - shouldn't have considerable overhead; but also, 
it shouldn't take 10 seconds to "rebuild" the build tool itself 
after every modification.


- Cross-platform support - this may seem obvious, but it should 
support at least all platforms DMD supports. One of the 
suggestions for replacement in a similar recent thread 
(http://forum.dlang.org/post/ohkkqj$21lg$1...@digitalmars.com), 
buildsome, shows no indication of any Windows support at all, not 
even plans to work on it.


- Minimal dependencies - ideally it should work with as few as 
possible external dependencies that one would typically need to 
install to build D. Windows is very often overlooked when 
evaluating this requirement, for example although Python is 
ubiquitous on POSIX systems, it's much less so on Windows.


That doesn't leave many candidates. reggae might be the closest 
to satisfying all of the above, though I haven't looked too 
closely at it. For one thing, I don't really understand the need 
for build system generators - seems like an extra step and 
imposing an implementation detail on the user.

Re: Isn't it about time for D3?

[Liam McGillivray via Digitalmars-d]

Removing all C++ compatibility is a death sentence for D.  This 
may not be apparent to some people that already program in D, but 
it is downright critical to potential D users.  Zero C++ 
compatibility means that D can no longer interface with C++ 
libraries such as Qt, putting a severe limitation on it's uses.


At the very least, dropping C++ compatibility is not for D3.  If 
ever, it should happen when D is already as popular as C++.  I 
brought up this whole D3 idea because I feel like D just needs 
one more wave of breaking changes to the language and library to 
be brought to perfection.  There are many C++ programmers out 
there who looked into/tried D and felt like it was almost good 
enough.  I think it will just take one major breaking version to 
make them jump, but not if it's totally incompatible with C++.


D3 should make the changes that can be agreed between proud D 
users and C++ users who have hopes for D.


On Saturday, 17 June 2017 at 06:23:08 UTC, Suliman wrote:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray 
wrote:

On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

> THINGS TO DROP
--
* C++ interoperabiliy
Walter's right:  memory safety is going to kill C and C++ 
will go with it.  Don't waste time on this; it's not going to 
matter in 10 or 20 years.
Totally agree! C++ now in 90% of cases is legacy projects. At 
current time is more important to out of the box 
interoperability with Rust or Julia. Time show that C++ do not 
want to migrate to D. Only few people come from C++ world, 
because all of them waiting of new C++ standard c++x2035 (or 
whatever)
Please don't quote me just to say "Totally agree!" to someone 
that I quoted and disagree with.


A prediction that C++ is going to be dead in 10 years is not good 
enough.  C++ is very active, not just legacy like you say.  As I 
said, D should not drop compatibility until it's ALREADY clear 
that it's getting surpassed by D.
I support interoperability with Rust if it's doable.  I barely 
know about Julia.


Like I said, there are actually many C++ programmers out there 
who feel like D2 has promise, but not quite there.  THIS is why I 
brought up this D3 idea.  I really do think that D3 could bring 
quite some excitement to the programming community if it's coming 
along well.  After a few of the more open-minded C++ programmers 
adopt D, it will trickle up to more and more.

Re: D needs to get its shit together!

[Mark via Digitalmars-d]

On Saturday, 17 June 2017 at 23:14:24 UTC, Moritz Maxeiner wrote:
IANAL, but if you tie a monetary exchange to a specific 
service, it's not a donation, but payment for services (to be) 
rendered.




Good point.

People who work on/with something in their free time for their 
own purposes are imho (rightfully) unlikely to care about 
catering to third party corporate interests.


Okay. Fair enough.

Re: D needs to get its shit together!

[Moritz Maxeiner via Digitalmars-d]

On Saturday, 17 June 2017 at 22:57:46 UTC, Mark wrote:

On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
If you are interested in donations, there is such 
infrastructure, it's called the D Foundation.


I imagine that it's not possible to make donations to the 
foundation that are restricted for the use of advancing a 
specific aspect of the language (e.g. tooling).


IANAL, but if you tie a monetary exchange to a specific service, 
it's not a donation, but payment for services (to be) rendered.




I don't know if anyone is looking at the state of the ecosystem 
from the persepctive of a corporation considering whether or 
not to use D for some project.


I would imagine the people at Sociomantic do.

Of course, such a perspective is immaterial if there is little 
community interest in corporate adaption of D...


People who work on/with something in their free time for their 
own purposes are imho (rightfully) unlikely to care about 
catering to third party corporate interests.

Re: Replacing Make for the DMD build

[Joakim via Digitalmars-d]

On Saturday, 17 June 2017 at 21:49:29 UTC, Walter Bright wrote:

On 6/17/2017 1:25 PM, Joakim wrote:
A lot of this is simply saying Make is popular so we should 
just stick with it: I hate that mindset.  It is the same 
mindset D has to combat with C or C++, and that was exhibited 
when you spoke against the SDL format for dub.


It's not quite the same. I spend 99.99% of my time programming 
working with code, not makefiles. Productivity gains from using 
a better language have a major effect. A better make simply 
does not.


I agree that most time spent coding doesn't involve the build 
system, but as Adam says, you say that as someone with a long 
history with Make.  For noobs, it represents a barrier to 
contributing, one that we should strive to lower as much as 
possible.



D should pick its battles,


That's a good summary of the situation.


All that said, I'll reiterate what I said earlier to Russel, 
and what I'd say to Atila too: don't aim to replace Make, just 
aim to provide an alternative in the dmd/phobos repos.  If we 
find that everybody is using that instead of Make, we'll just 
switch over to it naturally someday.


Maintaining two parallel build systems is having the downsides 
of both and the benefits of neither. Then there's the endless 
vim-vs-emacs debate about which alternative build system is 
better. It's not a battle we need to or can afford to invest in.


Let's please stay focused on things that will move the needle.


There's an easy way out of that morass.  Anybody who wants to 
submit an alternate build file for their build system must also 
provide a point of contact/support for that build system, so that 
any questions or update requests would be directed at them.


Make would remain the default and you make clear that it's the 
_only_ one officially supported.  Eventually, you prune out all 
the build files that don't work that well and aren't being 
supported by their proponents.  If they like, the project 
contributors can eventually decide to switch over to the new 
build system as the default, if it has been proven for some time 
to both work better and be well-supported.


All this would require you to do nothing, just perhaps make a 
decision someday down the line if and when a build system has 
been proven and others want to make it the default.  Would you be 
okay with starting this pragmatic approach, by okaying the commit 
of a Meson or Reggae build file to these repos and seeing where 
it goes?

Re: D Language Front-End Proposed For GCC 8, 800k Lines of Code

[Joakim via Digitalmars-d]

On Saturday, 17 June 2017 at 21:48:31 UTC, Mark wrote:

On Sunday, 28 May 2017 at 19:23:04 UTC, Nordlöw wrote:

Does this, perchance, deserve a post in "Announce"? :)

http://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC


800k lines of code! Wow. Is this also how big the DMD frontend 
is?


No, Dscanner says the current ddmd frontend is about 84 klocs of 
D code, and I found last year that about 63 klocs of that was 
used by ldc, so that's what's really needed:


http://forum.dlang.org/thread/ovkhtsdzlfzqrqneo...@forum.dlang.org

I don't think this patch would be using the ddmd frontend though, 
as gdc was still using the older C++ frontend last I heard, but 
without having looked at the patch at all, the big difference is 
probably that they're counting druntime and phobos also, and 
misrepresenting that as part of the frontend.

Re: D needs to get its shit together!

[Mark via Digitalmars-d]

On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
If you are interested in donations, there is such 
infrastructure, it's called the D Foundation.


I imagine that it's not possible to make donations to the 
foundation that are restricted for the use of advancing a 
specific aspect of the language (e.g. tooling).


I don't know if anyone is looking at the state of the ecosystem 
from the persepctive of a corporation considering whether or not 
to use D for some project. Of course, such a perspective is 
immaterial if there is little community interest in corporate 
adaption of D...

[Issue 17519] RedBlackTree doesn't like const/immutable elements

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17519

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
   Assignee|nob...@puremagic.com|ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
https://github.com/dlang/phobos/pull/5492

--

Re: Replacing Make for the DMD build

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 17 June 2017 at 21:49:29 UTC, Walter Bright wrote:
It's not quite the same. I spend 99.99% of my time programming 
working with code, not makefiles.


I'd say somewhere around 10% of the time I've spent on D pull 
requests has been wasted because of the makefiles. It is a 
barrier to entry in new contributors adding new modules.


Though, I think it is just because the ones in there are 
overcomplicated and crappy. My ideal makefile is less than ten 
lines long and I see no reason why dmd, phobos, druntime, and the 
 dlang.org website can't get close to that. Heck, `dmd **/*.d` 
almost actually works...

[Issue 17519] New: RedBlackTree doesn't like const/immutable elements

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17519

  Issue ID: 17519
   Summary: RedBlackTree doesn't like const/immutable elements
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Simple examples where immutable/const is meaningless:


import std.container.rbtree: RedBlackTree;
void main()
{
RedBlackTree!(immutable int) t1; /* fails; should compile */
RedBlackTree!(const int) t2; /* fails; should compile */
}


It matters when the element type has indirections:


import std.algorithm: map;
import std.container.rbtree: RedBlackTree;
void main()
{
static struct S { int* p; }
auto t3 = new RedBlackTree!(immutable S, (a, b) => *a.p < *b.p);
/* fails; should compile */
t3.insert([1, 2, 3].map!(x => immutable S(new int(x;
static assert(!__traits(compiles, *t3.front.p = 4));
}


--

Re: Ali's slides from his C++Now talk

[Mark via Digitalmars-d]

On Tuesday, 23 May 2017 at 23:31:48 UTC, Joakim wrote:

Enjoying going through these:

http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantage_with_D.no_pause.pdf

Ali really has a gift for explaining stuff, we're lucky to have 
him.


Yes, the slides are great. And I think "compilable Python" is a 
very good way of advertising D.

Re: Replacing Make for the DMD build

[Walter Bright via Digitalmars-d]

On 6/17/2017 1:25 PM, Joakim wrote:
A lot of this is simply saying Make is popular so we should just stick with it: 
I hate that mindset.  It is the same mindset D has to combat with C or C++, and 
that was exhibited when you spoke against the SDL format for dub.


It's not quite the same. I spend 99.99% of my time programming working with 
code, not makefiles. Productivity gains from using a better language have a 
major effect. A better make simply does not.




D should pick its battles,


That's a good summary of the situation.


All that said, I'll reiterate what I said earlier to Russel, and what I'd say to 
Atila too: don't aim to replace Make, just aim to provide an alternative in the 
dmd/phobos repos.  If we find that everybody is using that instead of Make, 
we'll just switch over to it naturally someday.


Maintaining two parallel build systems is having the downsides of both and the 
benefits of neither. Then there's the endless vim-vs-emacs debate about which 
alternative build system is better. It's not a battle we need to or can afford 
to invest in.


Let's please stay focused on things that will move the needle.

Re: D Language Front-End Proposed For GCC 8, 800k Lines of Code

[Mark via Digitalmars-d]

On Sunday, 28 May 2017 at 19:23:04 UTC, Nordlöw wrote:

Does this, perchance, deserve a post in "Announce"? :)

http://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC


800k lines of code! Wow. Is this also how big the DMD frontend is?

Re: Replacing Make for the DMD build

[Joakim via Digitalmars-d]

On Saturday, 17 June 2017 at 19:20:54 UTC, Walter Bright wrote:

On 6/15/2017 11:30 PM, Russel Winder via Digitalmars-d wrote:

A direct question to Walter and Andrei really.

If someone, let us say Russel Winder, create a CMake/Ninja 
and/or
Meson/Ninja build for DMD, is there any chance of it being 
allowed to

replace the Make system?

If the answer is no, then Russel will obviously not waste his 
time

doing something that will not be accepted.


It's highly unlikely it would be accepted:

1. make is ubiquitous. It's not something we have to scrounge 
to find on platform X, it's already there. People already are 
familiar with it (even if they hate it).


2. we're in the D business, not the project build business. 
It's easier to get past that "first 5 minutes" if everything 
about D other than D itself is familiar and conventional.


3. to steal from Churchill, `make` is the worst form of build 
system except for all the others


4. much as I dislike make, the time spent wrestling with it is 
a vanishingly tiny slice of time compared to what spent on the 
rest of D. Getting that time slice to zero will have no effect 
on productivity, and I'm not convinced that a newer build 
system will even reduce that time slice at all (see point 5).


5. D has a more complex build process than it should. Using 
another build system won't make that complexity go away.


6. unlike the choice to use github, there is no clear winner in 
the `make` category of build tools. If the industry has moved 
on from make to X, then we should, too. But it has not.


7. the current makefiles for DMD suffer from over-engineering, 
i.e. making simple things complicated and excessively using 
obscure features of make. This isn't really the fault of make.


A lot of this is simply saying Make is popular so we should just 
stick with it: I hate that mindset.  It is the same mindset D has 
to combat with C or C++, and that was exhibited when you spoke 
against the SDL format for dub.


I understand what you're saying, that D should pick its battles, 
but it's possible to do that and not just go with the status quo 
for everything other than D.  It is often necessary to get rid of 
defaults in many other categories, like Make or XML, and where 
possible D should try to make the best choices, without getting 
too far out there in NIH-land or its own D island.


I don't think choosing an outside Python build system that GNOME 
is in the process of switching to qualifies as either of those, 
as Python is almost as ubiquitous as make.  If we were to use 
Meson, we'd gain a lot in ease of use and lose almost nothing in 
platform availability.


All that said, I'll reiterate what I said earlier to Russel, and 
what I'd say to Atila too: don't aim to replace Make, just aim to 
provide an alternative in the dmd/phobos repos.  If we find that 
everybody is using that instead of Make, we'll just switch over 
to it naturally someday.

Nullable with auto-allocation on access

[Timothee Cour via Digitalmars-d]

Is there a construct similar to Nullable that would auto-allocate upon
access (set/get) if isNull is true?

Use case: https://github.com/msoucy/dproto/issues/117 [getters and
setters should work without calling `init` on Nullable fields, as in
C++ #117]

copied inline for easy reference:

```
in C++ we can write:

message MyMessage{
  optional Foo foo=1;
}
message Foo{
  optional Bar bar=1;
}
message Bar{
  optional string baz=1;
}

MyMessage a;
a.mutable_foo()->mutable_bar()->set_baz("hello");

in dproto we need to call init on the intermediate fields foo, bar

auto initialize_nullable(T:Nullable!U, U)(ref T a){ a=U.init; }

MyMessage a;
a.foo.initialize_nullable;
a.foo.bar.initialize_nullable;
a.foo.bar.baz="hello";

Would be nice to not have to call init and allow this:

MyMessage a;
a.foo.bar.baz="hello";

I believe this could be implemented via a modification of Nullable
that would call init on 1st access to a setter.
```

Re: Life in the Fast Lane (@nogc blog post)

[Joakim via Digitalmars-d-announce]

On Friday, 16 June 2017 at 18:26:15 UTC, Joakim wrote:

On Friday, 16 June 2017 at 13:51:18 UTC, Mike Parker wrote:
I've been meaning to get this done for weeks but have had a 
severe case of writer's block. The fact that I had no other 
posts ready to go this week and no time to write anything at 
all motivated me to make time for it and get it done anyway. 
My wife didn't complain when I told her I had to abandon our 
regular bedtime Netflix time block (though she did extract a 
concession that I have no vote in the next series we watch). 
Thanks to Vladimir, Guillaume, and Steve, for their great 
feedback on such short notice. Their assistance kept the blog 
from going quiet this week.


The blog:
https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

Reddit:
https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/


Nicely written.  I never bothered to look into this GC 
fine-tuning, as I don't need that level of optimization, but I 
finally have some idea of how this works.


And people have noticed, it's about to hit the top 10 most-liked 
proggit links of the last 7 days:


https://www.reddit.com/r/programming/top/?sort=top=week

One typo I forgot to mention earlier, where you wrote "aren't 
likey."

Re: Replacing Make for the DMD build

[Walter Bright via Digitalmars-d]

On 6/15/2017 11:30 PM, Russel Winder via Digitalmars-d wrote:

A direct question to Walter and Andrei really.

If someone, let us say Russel Winder, create a CMake/Ninja and/or
Meson/Ninja build for DMD, is there any chance of it being allowed to
replace the Make system?

If the answer is no, then Russel will obviously not waste his time
doing something that will not be accepted.


It's highly unlikely it would be accepted:

1. make is ubiquitous. It's not something we have to scrounge to find on 
platform X, it's already there. People already are familiar with it (even if 
they hate it).


2. we're in the D business, not the project build business. It's easier to get 
past that "first 5 minutes" if everything about D other than D itself is 
familiar and conventional.


3. to steal from Churchill, `make` is the worst form of build system except for 
all the others


4. much as I dislike make, the time spent wrestling with it is a vanishingly 
tiny slice of time compared to what spent on the rest of D. Getting that time 
slice to zero will have no effect on productivity, and I'm not convinced that a 
newer build system will even reduce that time slice at all (see point 5).


5. D has a more complex build process than it should. Using another build system 
won't make that complexity go away.


6. unlike the choice to use github, there is no clear winner in the `make` 
category of build tools. If the industry has moved on from make to X, then we 
should, too. But it has not.


7. the current makefiles for DMD suffer from over-engineering, i.e. making 
simple things complicated and excessively using obscure features of make. This 
isn't really the fault of make.

Re: Lubeck: Hight Level Linear Algebra for Dlang

[data pulverizer via Digitalmars-d-announce]

On Tuesday, 13 June 2017 at 08:26:20 UTC, 9il wrote:

Hi

I am pleased to announce the Lubeck [1] linear algebra library 
for Dlang.

It is very easy to use and it has been tested in real world.

The following functionality is implemented:

1. `mtimes` - General matrix-matrix, row-matrix, matrix-column, 
and row-column multiplications.


2. `mldivide` - Solve systems of linear equations AX = B for X. 
Computes minimum-norm solution to a linear least squares problem

if A is not a square matrix.

3. `inv` - Inverse of matrix.

4. `svd` - Singular value decomposition.

5. `pca` - Principal component analysis of raw data.

6. `pinv` - Moore-Penrose pseudoinverse of matrix.

7. `det`/`detSymmetric` - General/symmetric matrix determinant.

8. `eigSymmetric` - Eigenvalues and eigenvectors of symmetric 
matrix.



The package depends on mir-blas, mir-lapack, and mir-algorithm.


This work has been sponsored by Symmetry Investments[7] and 
Kaleidic Associates[8].


Best regards,
Ilya


This is great news! as I said in a previous discussion 
(https://forum.dlang.org/post/nrbcrpnvcrlqvpqho...@forum.dlang.org) a library like this is pretty important for numerical computing in D and together with Mir can form the basis of implementing algorithms for a myriad of applications in analysis.


Many thanks to all those involved!

Re: Garbage collection and closures.

[ANtlord via Digitalmars-d-learn]

On Saturday, 17 June 2017 at 17:15:50 UTC, Adam D. Ruppe wrote:

On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced". 
What the deep you mean? The deep of a closure or deep of the 
function where the variable is defined. Can you give an 
example code?


Where the variable is defined that is referenced in the closure.

So:

---
void uses(void delegate() dg);

void foo() {
   int a;
   foreach(b; 0 .. 10) {
  uses( () { a++; } ); // #1
  uses( () { b++; } ); // #2
   }
}
---


In that case, #1 would only be allocated once, at the start of 
the foo() function. It only uses `a`, so it doesn't have to 
allocate again after the point a is defined.


But #2 might allocate each time through the loop. (It currently 
doesn't, but this is filed as an open bug because it is 
supposed to.) Since it uses `b` which is defined inside the 
loop, it will have to allocate a new copy for each iteration.


Is this function called every time when allocation happens in 
a heap?


Not any allocation, it is just the function the compiler uses 
when it needs to make a closure.


Thanks a lot, Adam! Everything is clear. Except for the bug. I've 
got an expected result of a value of the variable from #2. The 
value equals to number from sequence plus one in each iteration. 
There are ten iterations.


What's wrong? Are there should be five iterations? It doesn't 
make sense for me due to the variable assigned value from the 
sequence 0..10. Or do I look at the wrong place? Can you give me 
a link to the bug?


Thank you again!

[Issue 17518] New: confusing error message with inout constructor/ctor

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17518

  Issue ID: 17518
   Summary: confusing error message with inout constructor/ctor
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
struct S
{
this(inout Correct) inout
{
}
}

struct Correct {}
struct Wrong {}

S bug()
{
return S(Wrong());
}
CODE
dmd -c bug

bug.d(13): Error: inout method bug.S.this is not callable using a mutable
object


The error should point out that the wrong type is passed, not that it's
mutable.

--

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 16:59:56 UTC, Dukc wrote:
If that Walter's DIP about reference-counted exceptions gets 
trough it should ease problem like that quite a bit.


Possibly. There's a lot of solutions to the exception thing 
though, and it doesn't actually bother me if you see @nogc as 
being very niche because you can just use one of those solutions 
today. (most of them depend simply on the catching code calling 
some disposal function, or living with a (possibly temporary) 
leak. Aside from that, the *most* you have to do is just `throw 
make!Exception` instead of `throw new Exception` and problem 
solved).


Didn't Don Clugston say about something at some Dconf that it 
must trigger allocation "not hardly ever, NEVER"? So there's a 
real need even for the rigid @nogc, albeit a niche one.


Yes, there are a few cases for it, but most people on reddit 
aren't one of them.


It reminds me of the "web scale" thing. "but can this handle 1 
million hits per second?" Probably not, but you also almost 
certainly going to need to... and if you do, the company will 
surely have the budget to hire a whole team of full time people 
to develop some specialized solution to their problem.


The D language should certainly never get in the way of those 
specialized solutions, whether scaling, or low latency 
audio/bidding, or whatever else, but I'm not convinced it needs 
to support them all out of the box either - and the average D 
user (or web developer in general) certainly doesn't have to 
worry.

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:09:42 UTC, Guillaume Piolat wrote:
As a counterpoint: It's true that it's a bit niche, but when 
you have "no gc" then @nogc really helps with peace of mind 
(only one allocation and you may crash).


Yes, when you actually need it it might be helpful, and then the 
associated niche libraries might use it too.


Of course, you can still lie about the attributes...

Re: Garbage collection and closures.

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 17 June 2017 at 14:19:34 UTC, ANtlord wrote:
Excuse me, I can't get what does it mean "deepest-referenced". 
What the deep you mean? The deep of a closure or deep of the 
function where the variable is defined. Can you give an example 
code?


Where the variable is defined that is referenced in the closure.

So:

---
void uses(void delegate() dg);

void foo() {
   int a;
   foreach(b; 0 .. 10) {
  uses( () { a++; } ); // #1
  uses( () { b++; } ); // #2
   }
}
---


In that case, #1 would only be allocated once, at the start of 
the foo() function. It only uses `a`, so it doesn't have to 
allocate again after the point a is defined.


But #2 might allocate each time through the loop. (It currently 
doesn't, but this is filed as an open bug because it is supposed 
to.) Since it uses `b` which is defined inside the loop, it will 
have to allocate a new copy for each iteration.


Is this function called every time when allocation happens in a 
heap?


Not any allocation, it is just the function the compiler uses 
when it needs to make a closure.

Re: Life in the Fast Lane (@nogc blog post)

[Dukc via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
The reason writeln fails @nogc is that it *might* throw an 
exception with most args if stdout is closed or something.


Perfect example of an *extremely* rare case failing @nogc's 
ridiculously strict requirements.


If that Walter's DIP about reference-counted exceptions gets 
trough it should ease problem like that quite a bit.


And as he said, memory-safe programming is not the problem 
-verifying the safety is. I think it is the same with GC.


Didn't Don Clugston say about something at some Dconf that it 
must trigger allocation "not hardly ever, NEVER"? So there's a 
real need even for the rigid @nogc, albeit a niche one.

Re: D Language Front-End Proposed For GCC 8, 800k Lines of Code

[Iain Buclaw via Digitalmars-d]

On Sunday, 28 May 2017 at 19:23:04 UTC, Nordlöw wrote:

Does this, perchance, deserve a post in "Announce"? :)

http://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC


I thought, Sunday evening, no chance of that Phoronix guy posting 
a news item until Monday morning.  How wrong I was.


I've drafted up a wiki page to keep track of current tasks.

https://wiki.dlang.org/GDC/GCCSubmission

Now that I think about it, maybe trello would be better.


Iain.

Re: Isn't it about time for D3?

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:

On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:

> THINGS TO DROP
--
* C++ interoperabiliy
Walter's right:  memory safety is going to kill C and C++ will 
go with it.  Don't waste time on this; it's not going to 
matter in 10 or 20 years.
Thank you for making a list to give people an idea of what D3 
could be, but I definitely don't support less interoperability 
with C++. I want D3 to have a better argument to transition 
from C++ than D2 has.  With all the C++ API's out there, making 
D incompatible would be a ginormous deal-breaker for a 
ridiculous number of projects.  D3 should seek to be worth the 
transition from C++.


Seems like there is a split right down the middle. The problem is 
of course that going down the middle is neither satisfactory nor 
innovative.


I agree with you, but I think the C++ compatibility is a lost 
game and increasingly so without aligning the core semantics. C++ 
is changing too...

Re: Life in the Fast Lane (@nogc blog post)

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 16 Jun 2017 13:51:18 +
schrieb Mike Parker :

> I've been meaning to get this done for weeks but have had a 
> severe case of writer's block. The fact that I had no other posts 
> ready to go this week and no time to write anything at all 
> motivated me to make time for it and get it done anyway. My wife 
> didn't complain when I told her I had to abandon our regular 
> bedtime Netflix time block (though she did extract a concession 
> that I have no vote in the next series we watch). Thanks to 
> Vladimir, Guillaume, and Steve, for their great feedback on such 
> short notice. Their assistance kept the blog from going quiet 
> this week.
> 
> The blog:
> https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
> 
> Reddit:
> https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/
> 
> 

Nice blog post!

> Let’s imagine a hypothetical programmer named J.P. who, for reasons
> he considers valid, has decided he would like to avoid garbage
> collection completely in his D program. He has two immediate options.

I think I might know that hypothetical programmer ;-)

-- Johannes

Re: D needs to get its shit together!

[Mike Parker via Digitalmars-d]

On Saturday, 17 June 2017 at 14:01:38 UTC, Mike B Johnson wrote:



You realize your mentality is like a dead rat? It just stinks. 
Your solutions are not solutions. They are patches. I wouldn't 
hire you to fix my plumbing because in a few months I'll have 
to fix it again. You are ok with that, because you get paid 
either way.  Keep kicking the can down the road... It may get 
you a bit of exercise but in the long run you are just wasting 
everyone's time. I also suggest you get out of the 1970's. 
Software and computers have come a long way. We shouldn't have 
to resort to the same mind set 40+ years ago. I shouldn't have 
to backup sc.ini, just because you think it is the way doesn't 
mean it is. That mindset for sc.ini pervades all your so called 
solutions. There are better ways, too bad you don't care or are 
too ignorant to see them.


That's fine. One more piece of advice I have for you. If you want 
anyone to take you seriously, check the attitude at the gate. 
Good luck!

Re: Garbage collection and closures.

[ANtlord via Digitalmars-d-learn]

On Saturday, 17 June 2017 at 13:13:17 UTC, Adam D. Ruppe wrote:

On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote:

Is GC called every iteration of this loop?


No, it will once on scope entry; where the deepest-referenced 
variable that is actually captured is defined. The compiler 
allocates heap space instead of stack space for the locals, 
then runs the function normally using that space.


Excuse me, I can't get what does it mean "deepest-referenced". 
What the deep you mean? The deep of a closure or deep of the 
function where the variable is defined. Can you give an example 
code?


It will only alloc once. You can prove this with a debugger 
btw, set a breakpoint on `_d_allocmemory`.


Is this function called every time when allocation happens in a 
heap?


Thank you. Sorry if my English is not clear.

Re: D needs to get its shit together!

[Mike B Johnson via Digitalmars-d]

On Saturday, 17 June 2017 at 13:23:06 UTC, Mike Parker wrote:

On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote:


[...]


This isn't as severe as you make it sound. If the latest 
version of VS doesn't work, the one before will. It's easy to 
prevent such issues in the future. Since we never know if a new 
version of VS will break things, this can be solved by one 
person who can monitor the beta releases of VS and submit PRs 
to the appropriate repositories if the paths change, or (as 
happened with VS 2015) the C runtime library changes, or some 
other breakage arises. Then DMD can get support for the new 
version before it's released. Could that person be you?




[...]


What I've done in the past is to keep the latest DMD on the 
system path, then set up Command Prompt shortcuts initialized 
with a different batch file to set override it with paths to 
different compilers/versions. If DVM could get support for LDC 
and GDC, then you'd have everything in one convenient app.



[...]


Backup the sc.ini file.


[...]


Like what?


[...]


So, what are you proposing here? Educate us. What are we 
supposed to take into account? I use my computer also for 
graphics, music, programming, document editing, all sorts of 
stuff. The only breakage I've ever had has usually been related 
to anti-virus software, though in the past there was an 
occasional issue with things like SecuRom. What exactly should 
the D community to in order to alleviate these major breakages 
you have on your system?



[...]


I would like to reiterate here what I mentioned earlier in this 
thread -- people in the D community are currently fixing flaws 
all the time. That we aren't fixing the flaws that particularly 
peeve you does not mean nothing is being done. I would also 
like to reiterate that if something is important enough to you, 
then you could do something about it besides coming to the 
forums and calling the rest of us ignorant. Write a DIP. File 
issues on Bugzilla. Submit pull requests. Take on 
responsibility for ensuring Visual Studio compatibility. Or do 
nothing, but please don't act as if we're all just sitting here 
twiddling our thumbs.


You realize your mentality is like a dead rat? It just stinks. 
Your solutions are not solutions. They are patches. I wouldn't 
hire you to fix my plumbing because in a few months I'll have to 
fix it again. You are ok with that, because you get paid either 
way.  Keep kicking the can down the road... It may get you a bit 
of exercise but in the long run you are just wasting everyone's 
time. I also suggest you get out of the 1970's. Software and 
computers have come a long way. We shouldn't have to resort to 
the same mind set 40+ years ago. I shouldn't have to backup 
sc.ini, just because you think it is the way doesn't mean it is. 
That mindset for sc.ini pervades all your so called solutions. 
There are better ways, too bad you don't care or are too ignorant 
to see them.

Re: Life in the Fast Lane (@nogc blog post)

[ketmar via Digitalmars-d-announce]

Guillaume Piolat wrote:


On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:


This is why I consider @nogc to be an *extremely* niche feature and 
generally harmful. It makes things look a lot harder than it really is - 
people confuse `@nogc` with "no gc". Instead, I suggest just minding the 
list and using runtime profiling and debugging to ensure your needs are 
met in actual practice.




As a counterpoint: It's true that it's a bit niche, but when you have "no 
gc" then @nogc really helps with peace of mind (only one allocation and 
you may crash).


yeah, it helps a little... in (let's be honest) rare situations where you 
really want to be *completely* free of any possible gc allocation. in most 
real-life scenarios you're ok with "mostly gc-free, except for exceptional 
cases" (like writeln, for example), and you have no way to express it. i 
end up not using @nogc at all (except on simple `return a` getters), 
despite the fact that many of my code rarely allocates.


there should be a way to say "i don't want gc on this code path, but it is 
ok for this one" (like throwing), without resorting to dirty tricks with 
casting and lambdas. something like `@raregc` ;-).


but then, how we should define "rare"? that attribute will quickly become 
useless, as people will mark arbitrary code with it.


so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and 
`@raregc` will become useless if introduced. and the sole reason (as i see 
it) of introducing `@nogc` was to please people complaining about gc 
allocations, no matter how often they're done, and on which code path. i 
myself see it as "PR design", which attracts people only to make them find 
that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive.


what `@nogc` *really* does now is dividing codebases into "i will do all 
kind of dirty tricks to avoid GC at all costs, even if it is not really 
necessary", and into "ah, screw it, i don't care". to me, it looks like 
`@nogc` does more bad than good now.

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

Jonathan M Davis  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--

Re: D needs to get its shit together!

[Mike Parker via Digitalmars-d]

On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote:

1. coff/omf. Requires use of windows and visual studio/C stuff 
who's locations and versions change over the years. This can be 
a major headache finding the right version. Mainly because the 
error messages, when using the wrong version, do not suggest 
that it is a versioning error.


This isn't as severe as you make it sound. If the latest version 
of VS doesn't work, the one before will. It's easy to prevent 
such issues in the future. Since we never know if a new version 
of VS will break things, this can be solved by one person who can 
monitor the beta releases of VS and submit PRs to the appropriate 
repositories if the paths change, or (as happened with VS 2015) 
the C runtime library changes, or some other breakage arises. 
Then DMD can get support for the new version before it's 
released. Could that person be you?





2. Managing different compilers: Not too bad but if you end up 
with some problems here, then it gets multiplied by the factor 
of the number of issues with each compiler. if LDC has an issue 
with the x64 dlls and dmd with the x32 and they are always 
looking in the same place because the versions are different 
and wrong, then it becomes a issue with a "factor of 4" 
problem. This can become even worse when you try cross 
compiling and such.


What I've done in the past is to keep the latest DMD on the 
system path, then set up Command Prompt shortcuts initialized 
with a different batch file to set override it with paths to 
different compilers/versions. If DVM could get support for LDC 
and GDC, then you'd have everything in one convenient app.




3. Re-installation can be problematic. sci.ini is overwritten. 
If you hand coded the paths to get everything to work, guess 
what? Well, who cares? You have plenty of time to waste, right?


Backup the sc.ini file.



4. Reinstalling one thing can break something else. This 
depends on how fragile the setup was at the start.


Like what?



5. I have over 1 billion files on my system, I use it for 
around 20 different non-complementary subjects(graphics, music, 
programming, etc). When everything is "competing for space" and 
things are not set up to work together, one seemingly unrelated 
program and effect every other one. (e.g., simply by adding to 
the path variable and break things with error messages that are 
meaningless to the real problem)


Most ignorant people do not take those things in to account 
because they oversimplify... and that usually causes problems 
down the road for the rest of us.


So, what are you proposing here? Educate us. What are we supposed 
to take into account? I use my computer also for graphics, music, 
programming, document editing, all sorts of stuff. The only 
breakage I've ever had has usually been related to anti-virus 
software, though in the past there was an occasional issue with 
things like SecuRom. What exactly should the D community to in 
order to alleviate these major breakages you have on your system?




As D becomes increasing popular, there are going to be more 
variation in the system and the flaws in it will become larger 
and larger.  It's best to start working on fixing those flaws 
before they become too large to manage and weaken the whole 
structure.


I would like to reiterate here what I mentioned earlier in this 
thread -- people in the D community are currently fixing flaws 
all the time. That we aren't fixing the flaws that particularly 
peeve you does not mean nothing is being done. I would also like 
to reiterate that if something is important enough to you, then 
you could do something about it besides coming to the forums and 
calling the rest of us ignorant. Write a DIP. File issues on 
Bugzilla. Submit pull requests. Take on responsibility for 
ensuring Visual Studio compatibility. Or do nothing, but please 
don't act as if we're all just sitting here twiddling our thumbs.

Re: Garbage collection and closures.

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 17 June 2017 at 13:03:28 UTC, ANtlord wrote:

Is GC called every iteration of this loop?


No, it will once on scope entry; where the deepest-referenced 
variable that is actually captured is defined. The compiler 
allocates heap space instead of stack space for the locals, then 
runs the function normally using that space.


The current implementation doesn't quite do this - it actually 
will alloc only once, on function entry, even when there's a 
variable inside a loop that is supposed to be independent. This 
is the cause of the commonly-referenced bug with foreach(i; 
whatever) capture(i); all showing the same number.


When that bug is fixed, it is possible to allocate on each 
loop... but your code doesn't anyway, so you're ok.


It will only alloc once. You can prove this with a debugger btw, 
set a breakpoint on `_d_allocmemory`.

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov 
[ZombineDev] wrote:
2. However, there's this long list of things that you have to 
avoid.


There's like 10 things to avoid in the language itself: 
http://dlang.org/spec/garbage.html#op_involving_gc


and most of them are obviously array stuff so it is easy to 
remember - and easy to skip with a simple array helper... which 
is often a useful optimization too, make one that uses stack 
space! You can write one in about 15 minutes.



Now, @nogc is a bit more restrictive since it isn't just avoiding 
GC calls it avoids the *possibility* of GC calls. Even if it 
would only actually run one in a million times at which point you 
want the program to die anyway @nogc still bans it. Even if 
it would never actually run, but some leaf function somewhere 
wrote `int getLength() { return _length; }` instead of `int 
getLength() @nogc pure const @safe nothrow { return _length; 
}`... it obviously doesn't run the gc, but still fails @nogc for 
its entire call tree.



This is why I consider @nogc to be an *extremely* niche feature 
and generally harmful. It makes things look a lot harder than it 
really is - people confuse `@nogc` with "no gc". Instead, I 
suggest just minding the list and using runtime profiling and 
debugging to ensure your needs are met in actual practice.


3. So while this "@nogc" is technically possible you loose so 
much of the language that you're better of with C++ (where e.g. 
"cout" just works*).


of course you could always `printf` lol.

The reason writeln fails @nogc is that it *might* throw an 
exception with most args if stdout is closed or something.


Perfect example of an *extremely* rare case failing @nogc's 
ridiculously strict requirements.

Re: Life in the Fast Lane (@nogc blog post)

[Guillaume Piolat via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:


This is why I consider @nogc to be an *extremely* niche feature 
and generally harmful. It makes things look a lot harder than 
it really is - people confuse `@nogc` with "no gc". Instead, I 
suggest just minding the list and using runtime profiling and 
debugging to ensure your needs are met in actual practice.




As a counterpoint: It's true that it's a bit niche, but when you 
have "no gc" then @nogc really helps with peace of mind (only one 
allocation and you may crash).

Garbage collection and closures.

[ANtlord via Digitalmars-d-learn]

Hello! I can't understand one thing related to closures and 
calling of GC. I have the following demo snippet, where a closure 
is passed to `receive` function in a loop.


bool isDone = false;
while(!isDone)
receive((bool val){ isDone = val });

Is GC called every iteration of this loop?

I know that I can move the code to a method of a struct and make 
the closure and variable "isDone" as fields of the struct. It 
avoids GC calling definitely. But I want to get how many times GC 
is called in case of a closure in a loop.


Thanks.

Re: D needs to get its shit together!

[Jacob Carlborg via Digitalmars-d]

On 2017-06-17 08:06, Mike B Johnson wrote:


Thanks. At least D has something going on correctly here.

My feeling is, unless DVM works well with windows, that it probably
currently doesn't offer much help. If it does manage the versioning well
and can deal with the environmental issues well then it is close to what
I am asking. If that's the case, it should be polished off and used as
the main front end and hosted by D.

You didn't state if it works congruently with all the major compilers.


No, unfortunately it only allows to install DMD.


The issues in windows are:

1. coff/omf. Requires use of windows and visual studio/C stuff who's
locations and versions change over the years. This can be a major
headache finding the right version. Mainly because the error messages,
when using the wrong version, do not suggest that it is a versioning error.

dvm could have the option to search the entire system for the files it
needs(e.g., link.exe, various dlls that are generally used, etc) and
attempt get things to work.


No, DVM doesn't do anything to try to find the installation of Visual 
Studio. Unless the compiler already can find it, it won't help. DVM was 
created before the compiler supported Visual Studio and I haven't kept 
the tool up to date to match that.



3. Re-installation can be problematic. sci.ini is overwritten. If you
hand coded the paths to get everything to work, guess what? Well, who
cares? You have plenty of time to waste, right?


That's a difficult problem. What if you messed up sc.ini and that's the 
reason you want to reinstall?


--
/Jacob Carlborg

[Issue 17516] std.regex doesn't recognize \e (for ANSI escape character), unlike boost.regex

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17516

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
   Severity|normal  |enhancement

--- Comment #1 from ag0ae...@gmail.com ---
Changing to 'enhancement' as compatibility with boost.regex is not a stated
goal for std.regex.

--

Re: Isn't it about time for D3?

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
I hope that Walter and Andrei give a proper response to this 
thread.  I wonder why they haven't.


They rarely give definitive answers... except after the fact, 
once it is already in master.

[Issue 17501] Runnable unittest problem with AST rewrite

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17501

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/eae2ed4075709164d7d2de1682970f9b1c1a2d9a
Fix Issue 17501 - Runnable unittest problem with AST rewrite

https://github.com/dlang/dlang.org/commit/5bebaa7421e3cdb543c3d1f90c6856902a3fc561
Merge pull request #1693 from wilzbach/enable-tests

--

[Issue 15945] sizeof on an invalid type seems to compile.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15945

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|CLOSED  |RESOLVED
 Resolution|INVALID |FIXED

--

[Issue 15517] std.experimental.logger: using 'sharedLog' to change to file logging for default logger does not work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15517

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/27b6122d942e17edeb7db6aafd148f6ab88a1f19
fix Issue 15517

https://github.com/dlang/phobos/commit/07e0293dbafdb9a9574509e3d5d12cda0603f690
Merge pull request #5371 from burner/issue15517

--

[Issue 17469] View source code

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17469

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/d02045747db953d021649f222e07c71c0705dbb0
Fix Issue 17469 - View source code for object.d is broken

--

[Issue 17419] add __traits(getLinkage, s) to the the linkage of symbol s

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17419

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/7b1e803bc1489573f70da214e173dd5e282f8ea5
Issue 17419 - add __traits(getLinkage, s) to the the linkage of symbol s

https://github.com/dlang/dlang.org/commit/db60ee382b924de9e3f59954c3beb4e47370083e
Merge pull request #1659 from WalterBright/getLinkage

--

[Issue 9275] [GC] removeRoot hits assert(0) instead of being a no-op (as documented)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9275

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/a1fb3915f562428741324ac5b319d9316fb57231
Fix issue 9275: Add test for removeRoot

--

[Issue 17472] [Reg 2.075] typeof(stdin) is no longer a File

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17472

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3caa34f219cebaf37b75ce7384a3a40dbb87fe1e
fix Issue 17472 - typeof(stdin) is no longer a File

https://github.com/dlang/phobos/commit/ff3c3dfb00d0db8cfb0c6571ad689a9e6080bfd7
Merge pull request #5454 from MartinNowak/fix17472

--

[Issue 16566] hasLength should enforce that length has type size_t

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16566

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/72f395084373b8c15518def33216485301e8de8a
Fix Issue 16566 - hasLength should enforce that length has type size_t

--

[Issue 17452] Undefined references in std.container.array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17452

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e162658601c930748440957561aca47abda5fc41
Fix Issue 17452 - Undefined references in std.container.array

https://github.com/dlang/phobos/commit/d4cb5e6cbc44914421a9fe991ffa5c7d83501808
Merge pull request #5432 from wilzbach/fix-17452

--

Re: For.Bin or.Exe files, how does a linker generate line numbers in debug information?

[Rainer Schuetze via Digitalmars-d-debugger]

On 17.06.2017 04:17, moecmks wrote:

I come from China, my English is not very high. Please forgive me.

First provide the context

@：debugger，IDA 6.8
@：this is my source file , only this one.

import std.stdio;

void main () {

   writeln ("Hello World");
}

I've found that for.Obj, using the -c -debug -gc -m32 command always 
generates line number information that is seen by the debugger


However, as long as the connection is exe or bin, the debugger can only 
see variable symbols, but no line numbers can be seen,I don't know if 
I've done anything wrong 0_0


this is my linker's command:$(LINK) /CO:4/DEBUG /CODEVIEW /DEBUGLINES 
/DEBUGMODULES:$(OBJPATH)\hello.obj $(OBJPATH)\hello.obj


The debug information emitted by compiling with -m32 follows a very old 
CodeView 4 specification that isn't well understood by current debuggers.


With cv2pdb (https://github.com/rainers/cv2pdb/releases) you can convert 
this debug information into a PDB file following newer standards but 
you'll need some components from the Microsoft tool chain to execute it.


Alternatively you can compile with -m32mscoff or -m64 that will use the 
Microsoft linker and the MS C runtime. This will generate a PDB file 
directly.

[Issue 17337] SIGILL for AVX vector initialization

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17337

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/3a2b76115bb7727652b6505898594b8c8e6a57d7
fix Issue 17337 - SIGILL for AVX vector initialization

https://github.com/dlang/dmd/commit/e84e711be771bce8156512f6af2ac5cd02f606b3
Merge pull request #6714 from MartinNowak/fix17337

--

[Issue 17293] "Using C++ Classes From D" example no longer works

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17293

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/4ec66653c62e9842f253bc4365faac47df876cc0
fix Issue 17293 - 'Using C++ Classes From D' example no longer works

https://github.com/dlang/dlang.org/commit/e544828c41840e7fd2424cb331304bbb2903a155
Merge pull request #1631 from WalterBright/fix17293

--

[Issue 17511] [REG 2.075a] std.xml puts grand-children into items

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17511

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/c7b6b87333fe731962f38a8a6ac0a3b5f675be06
test against regression

--

[Issue 8107] Float literals are not specified as they are implemented

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8107

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/cc7880723c224d8b11428f1f157b80cbb69054fa
Fix Issue 8107 - Float literals are not specified as they are implemented

https://github.com/dlang/dlang.org/commit/69b903342ac2f3b0625e318c3ba5102c1b50b2e9
Merge pull request #1705 from wilzbach/fix-8107

--

[Issue 16615] std.process is missing functionality for child processes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16615

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/71ca4c5b1428e6b4a9b2d89586cd8851c48619a6
Partial Fix For Issue 16615 - convert os pid to std.process Pid

https://github.com/dlang/phobos/commit/15a5a4898c67d0ecb7c7d2a5d9e744eeaf188ca1
Merge pull request #5086 from edi33416/process_enhancement

https://github.com/dlang/phobos/commit/07602da6334fa250032d302c777b75d17b0e4379
Revert "Partial Fix Issue 16615 - convert os pid to std.process Pid"

https://github.com/dlang/phobos/commit/9bfc82130c0e4af4d1dc95bb261570c6e4f6f5d8
Merge pull request #5456 from dlang/revert-5086-process_enhancement

--

[Issue 16256] std.experimental.logger cant log a dstring properly

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16256

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9e6759995a1502dbd92a05b4d0a8b662f1c6032b
fix issue 15945, 16256, 17328

--

Re: D needs to get its shit together!

[Mike B Johnson via Digitalmars-d]

On Saturday, 17 June 2017 at 08:27:33 UTC, Sebastien Alaiwan 
wrote:

On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
When a new user goes to start using D for the first time, D is 
a PITA to get working! Don't believe me?!?!


I'm running Debian GNU/Linux (testing). Here's the installation 
process for the 3 major D compilers.


$ apt install gdc
$ gdc my_first_program.d

GDC is too old for you? Fine, let's use ldc:

$ apt install ldc
$ ldc2 my_first_program.d

Or if you want the bleeding edge version of D:

(download dmd .deb package from dlang.org)
$ dpkg -i dmd_***.deb
$ rdmd my_first_program.d

Debian maintainers, one word: Thank you!


Sorry, doesn't help me or people in general. Also, simple 
examples are not proof that the solutions are general. It may be 
that easy on linux or it may not be, but it's definitely not that 
case on windows FOR almost ALL installations.

[Issue 17283] std.experimental.typecons uses private module members

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17283

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/df400d9dff930a804998ba5ea8536ea312b8ca76
Fix Issue 17283 - std.experimental.typecons uses private module members

https://github.com/dlang/phobos/commit/69f437a50200bcda63c67e221df210175204076e
Merge pull request #5319 from RazvanN7/Issue_17283

--

[Issue 16246] cannot call iota with 3 [u]bytes or 3 [u]shorts

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16246

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/6ff81f14057530484249dd4055e19c996b0485a7
Fix issue 16246 - cannot call iota with 3 [u]bytes or 3 [u]shorts

https://github.com/dlang/phobos/commit/79edc62e8ff6ed5292fbc40e09cd944fb436740a
Merge pull request #5391 from andralex/16246

--

[Issue 15945] sizeof on an invalid type seems to compile.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15945

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9e6759995a1502dbd92a05b4d0a8b662f1c6032b
fix issue 15945, 16256, 17328

--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/4d69c1abd487319f274b11a44b833e165c57946d
Fix Issue 17391 - SECURITY: XSS through DDOC comments

https://github.com/dlang/dlang.org/commit/c1d57d6182e8f012122d44479f2168545af9470a
Merge pull request #1649 from CyberShadow/pull-20170510-220714

--

[Issue 17303] type error in the href url under the link Systems Programming

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17303

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/f3f173bce3b27e7c81ee8a73383e052f593bf889
Fix Issue 17303 - type error in the href url under the link Systems Programming

https://github.com/dlang/dlang.org/commit/048ba72a63aae266557625b14dbc92b8ef1f2d9b
Merge pull request #1623 from alouanchi/patch-1

--

[Issue 7016] local import does not create -deps dependency

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7016

--- Comment #32 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/29273f261c94e1bbe1042ec58a362d70cb344188
remove .deps file generation

--

[Issue 17328] std.experimental.logger: wrong hex formatting for zeros

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17328

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9e6759995a1502dbd92a05b4d0a8b662f1c6032b
fix issue 15945, 16256, 17328

https://github.com/dlang/phobos/commit/86d500972b7ddb0251f836e07ffdcd01ca10bfa2
Merge pull request #5373 from burner/issue17328

--

[Issue 17314] BinaryHeap crashes upon insertion if heapified with an array of length 1

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17314

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/0912b243026e733db3b18c2c650d1809e5cb52dc
fix issue 17314

https://github.com/dlang/phobos/commit/ef9f4b9fee9277dfb0ad049a1806579eeaaa2042
fix issue 17314

https://github.com/dlang/phobos/commit/3b5ab7bec230b0d15d4fbd233323997291039040
Merge pull request #5329 from kirsybuu/issue_17314

--

[Issue 17394] std.file.mkdirRecurse isn't @safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17394

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e50531d921b368e26e5fca0ebce053c3e5454d23
Fix issue 17394 - mkdirRecurse isn't @safe

https://github.com/dlang/phobos/commit/22799fffa0f279d62574e3ea20efccaf5c0b1f05
Merge pull request #5386 from wilzbach/safe-file

Fix issue 17394 - mkdirRecurse isn't @safe
merged-on-behalf-of: Steven Schveighoffer 

--

[Issue 16108] `to!string` fails on struct with disabled postblit

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16108

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3d80936f0b1e56418d6826180a7a9dbb29e01b7f
Fix Issue 16108: tostrings fails on struct with disabled postblit

https://github.com/dlang/phobos/commit/4f2d89bc5721a2fbc75ca167b304c70fa8e81ba3
Merge pull request #5425 from JackStouffer/issue16108

--

[Issue 7102] std.numeric.gcd with BigInts too

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7102

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/35bbd3611ee4a977f2bedf98e8b15160eb01fd11
Merge pull request #5350 from quickfur/issue7102a

--

[Issue 15720] iota(long.max, long.min, step) does not work properly

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15720

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/49ee158a9e5887ad835dc0f04c0309adf22ff965
Fix Issue 15720 - iota(long.max, long.min, step) does not work properly

https://github.com/dlang/phobos/commit/138d9b91284bba8da3ceb9e5da2f52fea85db1c9
Merge pull request #5397 from andralex/15720

--

[Issue 17251] Appender.put errors out with const input range elements

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17251

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/c770fb481218e6eb2cd32363ce96de816dc6bdcf
Fix issue 17251 - Appender.put doesn't accept const input range elements.

https://github.com/dlang/phobos/commit/23726d63308c97799c6b356be392b466804be1f5
Merge pull request #5264 from s-ludwig/master

--

[Issue 16326] filter is not lazy enough & has weird save behavior

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16326

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/0e441a9d9e0f56b7a69d2c3fa4e157857239ee35
Fix Issue 16326 - filter is not lazy enough & has weird save behavior

https://github.com/dlang/phobos/commit/d6b55f840fab8aa9981e18dae2e25e0fe71dd346
Merge pull request #5392 from andralex/16326

--

[Issue 16053] SysTime.fromIsoExtString don't work if nanoseconds are presented

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16053

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/21c09f18d33b65475a89c7d6ec75d87556e6c1e5
Issue 16053: Fix it so that SysTime's from*String supports more than 7 digits.

--

[Issue 17327] std.getopt: repeated options unrecognised

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17327

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/c1d49fc4948977239fa4ed8c15b3d318b3e60ca9
Fix issue 17327 - std.getopt: Repeated boolean command option fails.

https://github.com/dlang/phobos/commit/684f41b64ee96a35bd9fba3aca95e5cdbf99d09c
Fix issue 17327. Review comments: drop continue statement.

https://github.com/dlang/phobos/commit/5aad85503a8bfb96dbf357af2758f01dc64cba60
Merge pull request #5334 from jondegenhardt/getopt-repeated-options-fix

--

[Issue 15645] Tuple.slice() causes memory corruption.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15645

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e63c620433f51da97a45e5400ca0a71202d7b129
issue 15645 - Prevent unsafe usage of Tuple.slice

https://github.com/dlang/phobos/commit/a45dc664a94cdfa7931b55b111d03ecf9afb83fa
Merge pull request #5342 from tsbockman/issue_15645

--

[Issue 13186] core/sys/posix/sys/uio.d is not linked into the standard lib

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13186

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/11ac522f4386fb02dbf0d601a1b36e3180c826bb
fix Issue 13186 - core/sys/posix/sys/uio.d is not linked into the standard lib

https://github.com/dlang/druntime/commit/2144f2f721bf3248350771e0ac89ee97ccc3ff63
Merge pull request #1827 from WalterBright/fix13186

--

[Issue 17286] A function for comparing two digests securely

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17286

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/290447ead429608c818db8c263c4df9b722c37c2
Fix Issue 17286 - A function for comparing two digests securely

https://github.com/dlang/phobos/commit/30b9da518941e2dfad18acbc1d99a2a2790d996a
Merge pull request #5312 from JackStouffer/secureCompare

--

[Issue 10001] string formatting with underscores

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10001

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5de9af20ad07ebe485394309867073baa53b627b
Merge pull request #5303 from burner/origin/formatunderscore

--

[Issue 17288] formattedWrite error when width/precision provided and no value to format

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17288

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b09ad9aeeaed177ca1fa2721d36064b4c00d3fe6
Fix Issue 17288 - formattedWrite with width/precision and no value

--

[Issue 15534] [std.experimental.logger.core] Documentation mismatch

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15534

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/3f0daf00b6e47c33b58a45375561d7db523e62a2
Fix issue 15534 - Rework constructor docs, removing reference to string
parameter that

https://github.com/dlang/phobos/commit/046bbbd59f92fc67dbde8ef04bdb16397ab1a9b3
Merge pull request #5315 from schveiguy/fix15534

--

[Issue 16232] std.experimental.logger.core.sharedLog isn't thread-safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16232

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/7d7ce4a5ebaca7155e754b1bf7b45366e87d0194
Logger sharedLog comment on thread-safety

--

[Issue 12233] Attempting to use TypeInfo.init results in a compiler error due to lack of 'this'.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12233

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/dc7d312b7f22835d8211c0f680fab1088a839324
remove TypeInfo.init

--

[Issue 17270] std.experimental.Final fails on pointers

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17270

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/05620ead4b7b80984afb44fb5aa64528baa2fdca
Fix issue 17270

https://github.com/dlang/phobos/commit/2e33404b8182ced214c47fcd02812549cbfe9f5f
Merge pull request #5302 from Bolpat/Final

--

[Issue 17372] function 'std.algorithm.searching.skipOver!(Result, dstring).skipOver' is not nothrow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17372

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/27330e76b72393ebb611176ea5600c94e447f067
issue# 17372: icmp chokes on a lambda that can throw.

https://github.com/dlang/phobos/commit/0b1f13fd517cf8b7bb26042e07cd920480215e74
Merge pull request #5361 from jmdavis/issue_17372

--

[Issue 16197] Constructors/postblits and destructors don't match up for array initialisation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16197

--- Comment #16 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/10c4f4acb524940cf5747bf6406dd51a13e7fbd2
fix Issue 16197 - Constructors/postblits and destructors don't match up for
array initialisation

https://github.com/dlang/dmd/commit/ca5a785e5ebe56a1019189801002ea214362a1f6
Merge pull request #6774 from WalterBright/fix16197

--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16856

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/c56e8e0d8d599b1742fe85210f07adacf07e5e2a
Fix issue 16856: Apply correct alignment on the Unwind_Exception structure

https://github.com/dlang/druntime/commit/c7182eb2ef3d6cc57c3e3366028753306b4dceb7
Merge pull request #1823 from Burgos/exception_alignment

--

[Issue 7016] local import does not create -deps dependency

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7016

--- Comment #31 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6be32270b411d13f49ffccaa055b2cb13060c495
Fix Issue 7016

https://github.com/dlang/dmd/commit/afebe0c2ba89594b434d676fbe0c050389a5b48c
Merge pull request #6748 from RazvanN7/Fix_Issue_7016

--

[Issue 17356] [Reg 2.075] __simd_sto no longer executed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17356

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/894d9950f4ff996e1342242e7e51953ac718fc01
fix Issue 17356 - [Reg 2.075] __simd_sto no longer executed

https://github.com/dlang/dmd/commit/1d29b792fe7fd2694d25544179021976e2e81184
Merge pull request #6763 from WalterBright/fix17356

--

[Issue 15763] std.math.approxEqual is not symmetric

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15763

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9b4ae1e779a0d086b5e07c76df99f3c097884f5f
fix issue 15763 - Document behavior of relative difference. Also fix

https://github.com/dlang/phobos/commit/74a339ea51fc8d568152be7bde1eb46d2e6df4d3
Merge pull request #5316 from schveiguy/fix15763

--

[Issue 16600] Wrong error message for ambiguous mutable/immutable constructor

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16600

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/bb2e552c567e70c501cc411af0ba9e74acc2c8c9
Fix Issue 16600 - Wrong error message for ambiguous mutable/immutable
constructor

https://github.com/dlang/dmd/commit/fbddd24bcc5544d9fa6b736c42348cd3b1e4d5c9
Merge pull request #6662 from RazvanN7/Issue_16600

--

[Issue 15896] private ignored when import bindings are used

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15896

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/ffcc380b9c06785b32c9db4eb2d392d89dcc661c
Fix Issue 15896 - private ignored when import bindings are used

https://github.com/dlang/dmd/commit/7d934731c124d70afaf7f795db039a6a887b46fd
Merge pull request #6660 from RazvanN7/Issue_15896

https://github.com/dlang/dmd/commit/423c52204b45e5e01f17c106d1f254cdaa6c7a50
Revert "Fix Issue 15896 - private ignored when import bindings are used"

https://github.com/dlang/dmd/commit/8d0fce421b1b55921c9827ac1d89633560a3c0a7
Merge pull request #6673 from dlang/revert-6660-Issue_15896

--