Re: Vision document for H1 2017

[Martin Nowak via Digitalmars-d-announce]

On 01/05/2017 11:45 PM, Sönke Ludwig wrote:
> Am 05.01.2017 um 01:59 schrieb Paul O'Neil:
>> On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote:
>>> We release a brief Vision document summarizing the main goals we plan to
>>> pursue in the coming six months. This half we are focusing on three
>>> things: safety, lifetime management, and static introspection.
>>>
>>> https://wiki.dlang.org/Vision/2017H1
>>>
>>>
>>> Andrei
>>
>> What are the plans for the dub registry?  Have there been discussions
>> already?
> 
> I'm not aware of concrete discussions w.r.t. the vision document

I think there won't be much discussions about the goals (maybe about the
priorities). Many people come up with the same ideas to resolve the pain
points.

Actually I have a draft for a renewed site, will look at implementing
that (hopefully with Sebastian, Söhnke, and others) in the next few month.

So far haven't found an angle at breaking up the story though, it's
fairly intermingled. If we can't do it incrementally, that would require
a bit more orchestration for a major rerelease.

- better search, also on README bodies (e.g. sqlite FTS)
- tagging instead of hierarchical categories
- ranking (downloads, stars, dependents, testing...)
- better landing page (big search form and listing 10 top, 10 trending,
and 10 newest packages)
- better GH integration

Personally would approach this mid/end of March, but if enough people
have time we could do it earlier.

https://dlang.slack.com/messages/dub/

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Martin Nowak via Digitalmars-d-announce]

On 01/07/2017 05:12 PM, Andrei Alexandrescu wrote:
> Following https://github.com/dlang/dlang.org/pull/1532, the new-style
> docs now also allow editing and running examples. Start at
> http://dlang.org/library-prerelease/ and go anywhere to check it out.
> 
> Thanks are due to Sönke Ludwig and Sebastian Wilzbach!

Thanks, this is quite an amazing step towards more interactive
documentation.
Should we start to produce output as well, e.g. with some magic
`writeln` that's silent in actual tests?

Re: Vision document for H1 2017

[Martin Nowak via Digitalmars-d-announce]

On 01/06/2017 11:09 PM, Anton wrote:
> On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote:
>> We release a brief Vision document summarizing the main goals we plan
>> to pursue in the coming six months. This half we are focusing on three
>> things: safety, lifetime management, and static introspection.
>>
>> https://wiki.dlang.org/Vision/2017H1
>>
>>
>> Andrei
> 
> dub registry required review
> 1. By myself current page rename to "last updates", and "Main" may be
> (scoped) category view?
> IMHO main page currently unfriendly
> 
> 2. dub registry search unexpected
> i'm looking for network libs, entered "net" and take:
> ...
> freeimage
> dyaml
> ...

Thanks, we are aware of the various limitations, hence it'll be a major
priority to improve the site. Improving search and tagging is one bigger
aspect of that, distinguishing high quality packages another one.

-Martin

Re: Vision document for H1 2017

[Martin Nowak via Digitalmars-d-announce]

On 01/05/2017 11:00 AM, Basile B. wrote:
> I don't known what did you decide in intern but when the discussion
> between users was hot (just after version 2.071.1 I think) I've proposed
> that:
> https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md

This is superfluous by now. We figured that allowing access to private
fields wouldn't clash with important optimizations, so it can be allowed
via traits.
The visibility of allMembers was adjusted in
https://github.com/dlang/dmd/pull/6078.
All access checks will go away once the visibility changes have been
fully deprecated. So far those changes were adopted fairly slow (not
even phobos has fixed them all), hence we haven't yet switched over to
the new visibility semantics.

-Martin

Re: Vision document for H1 2017

[Martin Nowak via Digitalmars-d-announce]

On 01/05/2017 05:43 AM, Basile B. wrote:
> To simplify introspection with library traits that use the compiler
> "__traits()" someone has to remove the restrictions related to
> protection attributes. This is not a new topic. Without this, the new
> library traits won't work well and people won't use them.

That's already what we decided in September, so where is the problem?
http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org
https://github.com/dlang/dmd/pull/6111

Re: Beta 2.073.0-b1

[Martin Nowak via Digitalmars-d-announce]

On 01/07/2017 03:44 PM, biozic wrote:
> On Saturday, 7 January 2017 at 05:02:13 UTC, Martin Nowak wrote:
>> First beta for the 2.073.0 release.
>>
>> This release comes with a few phobos additions, a new -mcpu=avx
>> switch, an experimental safety checks (-transition=safe/-dip1000), and
>> several bugfixes.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.073.0.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
> 
> Thanks for the good work!
> 
> Are phobos unittests not passing when compiling with -dip1000 considered
> bugs or is it this experimental?

Most of phobos is currently not usable with DIP1000, partly because
safety checks are hard errors (instead of deprecations) and partly
because of implementation bugs.
You can try it experimentally with isolated code snippets.
Don't expect much documentation or help at this stage, the feature will
properly released when it's finished.

Any way to escape pointers in @safe code with -dip1000 enabled are
considered bugs and should be reported under issues.dlang.org using the
`safe` keyword and `[scope]` in the title.

https://issues.dlang.org/buglist.cgi?keywords=safe_type=allwords_format=advanced=---_desc=%5Bscope%5D_desc_type=substring

-Martin

Beta 2.073.0-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.073.0 release.

This release comes with a few phobos additions, a new -mcpu=avx switch,
an experimental safety checks (-transition=safe/-dip1000), and several
bugfixes.

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

Please report any bugs at https://issues.dlang.org

-Martin

Re: It is still not possible to use D on debian/ubuntu

[Martin Nowak via Digitalmars-d]

On Monday, 2 January 2017 at 18:18:33 UTC, deadalnix wrote:
Plus the fix was actually released yesterday, so it's not like 
I'm lagging by much. The internal meddling nonsense that's 
going on is none of any user business.


Bug reports are dealt with on Bugzilla, shouldn't be surprising.
It's also fairly reasonable to ask you to search the Forum and 
Bugzilla for your topic and progress on that before posting a 
rant.

Re: It is still not possible to use D on debian/ubuntu

[Martin Nowak via Digitalmars-d]

On Monday, 2 January 2017 at 15:11:42 UTC, Basile B. wrote:
Not to mention that not all linux distributions work this way. 
Even not all the debian -> unbntu ones (such as Mint), and 
certainly not the ones based on red hat.


The topic was fairly disputed for RH, but Jakub Jelinek is also 
the author of prelink, and seems a bit biased. There are also IRC 
logs available.

https://pagure.io/fesco/issue/1113
It's true that ASLR is only a small security improvement that's 
not even relevant to many programs.
I also ran several benchmarks and didn't found any measurable 
changes. So in the end going with PIC by default seemed OK.

Re: It is still not possible to use D on debian/ubuntu

[Martin Nowak via Digitalmars-d]

On Monday, 2 January 2017 at 02:31:16 UTC, H. S. Teoh wrote:
On Sun, Jan 01, 2017 at 11:55:37PM +, deadalnix via 
Digitalmars-d wrote:

But it is not clear if anyone cares at this stage...


I care. But I've been using custom-built DMD on Debian, and it 
has been working so far.


Of course, I don't know about the .deb distribution. A fix was 
recently pushed, but I don't know if that fixed the problem.  
My solution was basically to built druntime & phobos with -fPIC 
so that static libphobos.a is PIC. But my solution was declined 
in bugzilla and a different fix was opted for.


Linking against shared phobos was just mentioned as immediate 
workaround.


Changing over to -fPIC by default amd64 was one of multiple 
options that had to be carefully evaluated. It's fairly trivial 
to just demand a certain change without considering it's impact.

Re: It is still not possible to use D on debian/ubuntu

[Martin Nowak via Digitalmars-d]

On Sunday, 1 January 2017 at 23:55:37 UTC, deadalnix wrote:

But it is not clear if anyone cares at this stage...


It's fairly embarrassing to read so much uninformed noise.

https://trello.com/c/E1LU0SAe/269-issue-16794-deb-not-working-on-ubuntu-16-10-because-of-default-pie-linking
 (added 5 days after bug report)
http://forum.dlang.org/post/o3ogr0$27hu$1...@digitalmars.com
https://issues.dlang.org/show_bug.cgi?id=16794

Re: It is still not possible to use D on debian/ubuntu

[Martin Nowak via Digitalmars-d]

On Monday, 2 January 2017 at 13:51:15 UTC, Martin Nowak wrote:

On Sunday, 1 January 2017 at 23:55:37 UTC, deadalnix wrote:

But it is not clear if anyone cares at this stage...


It's fairly embarrassing to read so much uninformed noise.


Not to mention that everyone could have fixed this bug.

Re: Release 2.072.2

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 31 December 2016 at 23:49:20 UTC, Meta wrote:

Congratulations and thank you for your hard work.


Most prominently scope classes work again in @safe code


I haven't been following too closely. Does this mean that 
DIP1000 has been implemented and is behind a feature switch, or 
is the above entry just a small related bugfix?


We don't add features in point releases, this was just a bug fix 
where such code no longer compiled. Also see the changelog for 
all infos.

Re: Release 2.072.2

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 1 January 2017 at 01:47:17 UTC, Eugene Wissner wrote:
Can it be that freebsd64 dub is linked against wrong phobos? I 
get:

Shared object "libphobos2.so.0.71" not found, reuired by "dub".

The same was with 2.072.1.


It should be statically linked against phobos, please file a bug 
report at issues.dlang.org.

Release 2.072.2

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.072.2.

http://dlang.org/download.html

This version resolves a number of regressions and bugs in the 2.072.1
release. Most prominently scope classes work again in @safe code,
various rdmd bugs were fixed, and -fPIC became default for all linux
64-bit binaries and packages in order to support PIE (default on Ubuntu
16.10 and hardened Gentoo).

Also see the changelog for more details.

http://dlang.org/changelog/2.072.2.html

-Martin

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Martin Nowak via Digitalmars-d]

On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote:
If that were made more lazy, we could import half of the world 
with noticing impact.


(Which espcially in std.traits, would not make that much of a 
difference since every template in there depends on nearly 
every other template in there)


Also the established technique of serializing precompiled AST 
(after semantic3) of modules to a cache should be applicable as 
well.


Cross-posting from 
https://github.com/dlang/DIPs/pull/51#issuecomment-269107966, b/c 
it wasn't answered yet.


Were any other means considered? This is proposing to add plenty 
of additional annotations only to speed up compilation, but none 
of the classical tools for pre-compilation were assessed.
Since D's modules don't have the header problem, even 
pre-compilation and reuse of semantic3 should be possible, or not?

Re: Using dlopen/dlsym

[Martin Nowak via Digitalmars-d]

On Tuesday, 27 December 2016 at 18:12:42 UTC, Mike Wey wrote:
dmd will need to pass "--export-dynamic" to the linker, so that 
the symbol is actually exported.


Thanks, at least one useful answer out of nine!

Re: Using dlopen/dlsym

[Martin Nowak via Digitalmars-d]

On Tuesday, 27 December 2016 at 00:05:39 UTC, Andrei Alexandrescu 
wrote:

./test: undefined symbol: fun

I'm building with no flags using dmd. What could be the problem 
here?


Importing symbols from your executable requires to tell the 
linker to create a dynamic symbol table, i.e. using 
--export-dynamic for ld.
We also add that flag by default on many platforms because our 
exception backtraces still rely on the dynamic symbol tables, 
instead of exclusively using dedicated DWARF information.

Combining both effects might lead to confusing behavior.

Also see:

[Issue 11870 – replace dynamic symbol table (--export-dynamic) 
for backtraces](https://issues.dlang.org/show_bug.cgi?id=11870)

https://dlang.org/changelog/2.069.0.html#curl-dynamic-loading

Re: Silicon Valley D Meetup - December 22, 2016 - "The Curse of Knowledge: Et tu, D?" by Adam Wilson

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 25 December 2016 at 10:15:00 UTC, Adam Wilson wrote:
I would like to give this talk again as it generated some very 
good discussion on the topic. Hopefully, with someone else in 
charge of A/V, we will have more luck.


Great topic, would be glad to see this at DConf 2017.
http://dconf.org/2017/index.html

Beta D 2.072.2-b2

[Martin Nowak via Digitalmars-d-announce]

Second and last beta for the 2.072.2 point release.

This version adds a few more fixes and also comes with dub v1.1.2-beta.1.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.072.2.html
https://github.com/dlang/dub/blob/v1.1.2-beta.1/CHANGELOG.md

Please report any bugs at https://issues.dlang.org

-Martin

Re: Beta D 2.072.2-b1

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 27 December 2016 at 14:39:15 UTC, Dicebot wrote:
My understanding is that there is still a lot of manual labor 
in changelog generation


About to get fixed 
https://trello.com/c/WIwLjrPE/243-create-changelog-builder-from-files.

Re: Beta D 2.072.2-b1

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 27 December 2016 at 09:21:23 UTC, safety0ff wrote:
On Tuesday, 27 December 2016 at 04:36:54 UTC, Martin Nowak 
wrote:


This version resolves a number of regressions and bugs in the 
2.072.1 release.


I thought https://github.com/dlang/druntime/pull/1707 was in 
stable and slated for this point release.


Thanks for catching this.

I see at the bottom of: 
https://github.com/dlang/druntime/pull/1708

"@klickverbot klickverbot deleted the stable branch 18 days ago"


Yikes, indeed the stable branch was deleted and later recreated 
from a stale version (my local one IIRC). I did protect all 
stable branches for that to not happen again. Also I usually 
merge locally and make a PR from my own merge_stable branch.


https://github.com/dlang/druntime/pull/1727

Also, https://github.com/dlang/druntime/pull/1715/ should be 
included IMO in addition to PR 1707.


It's a bit unfortunate that PR creators w/o write access to a 
repo can't add milestones, or can they?

Beta D 2.072.2-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.072.2 point release.

This version resolves a number of regressions and bugs in the 2.072.1
release. Most prominently scope classes work again in @safe code,
various rdmd bugs were fixed, and -fPIC became default for all linux
64-bit binaries and packages in order to support PIE (default on Ubuntu
16.10 and hardened Gentoo).

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

Please report any bugs at https://issues.dlang.org

-Martin

Re: DMD travis-ci problems with new GDC toolchains

[Martin Nowak via Digitalmars-d]

On Sunday, 25 December 2016 at 19:25:40 UTC, Johannes Pfau wrote:

This is not place to post bug reports. It was only by chance that 
I read it.


Better file a Bugzilla Ticket, and notify the author of related 
tools/scripts. Since noone can monitor everything surrounding D, 
mailing the author would be appropriate if you can't fix the 
problem yourself and are stuck.


When DMD then compiles the C++ tests it uses the never C++ 
compiler shipped with the GDC toolchain. This compiler 
internally uses a new libstdc++ shippped in a toolchain 
subfolder. But when running the C++ programm it'll load the 
stdc++ library from /usr/lib and therefore complain about 
missing symbols.


This now happens even with the old GCC 4.9 so we have to 
downgrade travis-ci to GCC 4.8 based compilers for now. Looking 
at https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html it 
is just coincidence that GCC 4.8 works and 4.9.3 used to work 
before. As soon as we start testing more complicated C++ 
features the newer g++ is more likely to need a symbol not 
available in the old system stdc++ library.


Possible solutions include:
* Install a newer system GCC from a PPA. This will also update 
stdc++.

* Append the toolchain location to PATH instead of prepending


The goal of the activate scripts is to switch the current 
compiler, that includes hiding a system wide installation of dmd, 
so this wouldn't work.



* Add the location to the toolchain libstdc++ to LD_LIBRARY_PATH


Sounds like a reasonable solution to me, link with what you use 
for compiling.
We're already setting up LIBRARY_PATH and LD_LIBRARY_PATH for the 
selected version.

https://github.com/dlang/installer/blob/92315cdf58b32178f2c4865db87123d433f45406/script/install.sh#L575

In fact this looks like an incompatibility of the install.sh 
scripts with your new multilib gdc (using lib32/lib64 instead of 
lib).


Other solutions.

* We could hide g++/gcc/c++/cc from the gdc binary folder (or use 
a different folder containing only gdc/gdmd symlinks). But since 
gcc uses plenty of other tools, such as collect, gprof, et.al. it 
would ask for troubles.


* We could teach the dmd testsuite to use a specific c++/cc 
compiler, there is already HOST_CC (the c++/cc driver used for 
linking). The C++ compiler used for testing can be set here 
https://github.com/dlang/dmd/blob/dfde61a5b0d206b22be9fa72df7ac14826271eff/test/d_do_test.d#L31.

Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 25 December 2016 at 19:41:38 UTC, Johannes Pfau wrote:

Happy holidays everybody,

I'm happy to finally announce the release of new GDC binaries 
at https://gdcproject.org/downloads.


Congratulations!

massive internal changes in GDC in preparation for the DDMD 
frontend


Sounded very exiting what I heard from Iain recently.

* Shared library support: We added support for shared libraries 
to GDC


Great, might be time to revive 
https://github.com/dlang/druntime/pull/617 soon.


* New mechanism to link system dependencies: All system 
libraries

  needed by phobos (-ldl, -lrt, -latomic) are detected in the
  phobos ./configure script. The required dependencies are 
added to a
  libgphobos.spec file and installed along with the 
libgphobos.so/.a
  libraries. GDC then reads this file to detect the required 
libraries,

  so the libraries are no longer hard coded in GDC. Note for
  distribution packagers: You must make sure to manually 
install this

  file if you do not use the standard make install command.


Sounds interesting for dmd as well.


Travis-CI should pick up the new release from now on.


Thanks for updating :)

It's actually all handled by the install.sh script, so you'll 
also get the latest gdc with `curl -fsS 
https://dlang.org/install.sh | bash -s gdc` and anything else 
using that script, e.g. Travis-CI and the Heroku buildpack.

Re: Blog Post - profiling with perf and friends

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 25 December 2016 at 20:45:13 UTC, Andrei Alexandrescu 
wrote:
The tracker would be easily accessible and would flag PRs that 
decrease compilation speed by more than a tolerance. One OS 
should be enough for now. We need a clean machine (not shared 
for many other tasks). The Foundation can provide a Linux 
machine in my basement. Looking at our A-Team Seb, Vladimir, 
Martin please let me know if this is something you'd pursue.


Added as feature to our CI ideas.
https://trello.com/c/zSnpnhrz/68-benchmark-ci
This would be really easy to integrate as separate executor in a 
reworked Jenkins setup. It would be quite a lot of effort as 
separate project though.


As said in the 17th planning, that's up for January, then we 
might revisit this in Feb or so. Since benchmarks aren't that 
critical the slightly reduced reliability of a home server might 
suffice, performant servers are really cheap though.

Blog Post - profiling with perf and friends

[Martin Nowak via Digitalmars-d-announce]

Just a few infos on using perf and related tools for profiling on 
linux.


https://code.dawg.eu/profiling-with-perf-and-friends.html

Re: Silicon Valley D Meetup - December 22, 2016 - "The Curse of Knowledge: Et tu, D?" by Adam Wilson

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 15 December 2016 at 08:20:37 UTC, Ali Çehreli wrote:
Come in-person at 6:30pm for food and drinks but plea^H^H^H^H 
RSVP so we know how much to order:


  https://www.meetup.com/D-Lang-Silicon-Valley/events/236253882/


Nice! Could you please add those Meetups to the dlang calendar?
http://forum.dlang.org/post/rsxfyebqlrryoblhy...@forum.dlang.org 
(see public calendar)

Re: Optimization problem: bulk Boolean operations on vectors

[Martin Nowak via Digitalmars-d]

On Friday, 23 December 2016 at 18:33:52 UTC, Seb wrote:
So the asm is about 40% faster than the best of the 
alternatives. The point being that it's the generated code not 
the source that's the problem.


Has anyone considered using ldc for DMD release compilations?


We considered using gdc (or ldc) to compensate for the slowdown 
after the ddmd transition, but nobody complained enough for that 
to happen ;). Also Windows users were stuck with dmd at that 
point.
Using a proper optimizer, profiles, and LTO it was fairly simple 
to speedup dmd by some 20+% (IIRC).


Unfortunately wasn't considered before 2.069.0, but that's one of 
the main reasons why we setup Travis-CI to test gdc/ldc builds.

https://trello.com/c/OT6jlFNa/85-rebench-ddmd-vs-dmd-compiler-speed

Release D 2.072.1

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.072.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.072.0, see the changelog
for more details.

http://dlang.org/changelog/2.072.1.html

-Martin

Re: Beta D 2.072.1-b1

[Martin Nowak via Digitalmars-d-announce]

On 11/30/2016 08:09 PM, Jonathan M Davis via Digitalmars-d-announce wrote:
>> Is it going to happen this release or only 2.073?

Rather in a 2.072.2 if we can find a reasonably simple fix.

> AFAIK, zero work has been done on it.

How much overview do we really have into other people's work?
It's true that nothing landed in the repos, there a simple fix for the
problem though, use -fPIC -defaultlib=libphobos2.so
https://issues.dlang.org/show_bug.cgi?id=5278#c32

-Martin

Re: DUB 1.1.1-beta.1

[Martin Nowak via Digitalmars-d-announce]

On Wednesday, 23 November 2016 at 16:55:47 UTC, Sönke Ludwig 
wrote:
I've also added a beta release tag for DUB (the same version as 
included in the DMD beta package).


Separate download of pre-compiled binaries:
https://code.dlang.org/download


Sorry, seems like I forgot to push the dub tag to upatream, still 
tweaking the dub integration a bit.

Will do the release tomorrow morning.

Fixing implicit copies of InputRanges [was: Re: Mir Random [WIP]]

[Martin Nowak via Digitalmars-d]

On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
Maybe non-copyability needs to become a requirement for 
InputRanges.


Could have an optional .clone if copying is supported.
What would be an InputRange where copying is correct?


We already have refRange for that, no?
Also refCounted(Random(unpredictableSeed)) should work.


Same scheme works for files with only plain int fds streams, 
non-copyable/unique ownership, and move, refRange, or refCounted 
for passing and sharing.


Should we split off this discussion to a dlang-study thread?

Re: Mir Random [WIP]

[Martin Nowak via Digitalmars-d]

On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei 
Alexandrescu wrote:

On 11/22/16 7:30 PM, John Colvin wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei 
Alexandrescu wrote:
The proposed design has disabled copy ctor and uses opCall() 
for a new element. That seems to be a difference without a 
distinction from an input range that has disabled copy ctor and 
offers the input range primitives.


Yes the problems are inadvertent copies and a disabled this(this) 
would prevent that. RNGs should have unique ownership of their 
internal state.
Using InputRanges with phobos is somewhat clumsy. Maybe people 
have been burned by those and now generally consider InputRanges 
as broken.
Maybe non-copyability needs to become a requirement for 
InputRanges.


We should add a reference RNG that transforms any other RNG 
into an input range that shares the actual RNG.


We already have refRange for that, no?
Also refCounted(Random(unpredictableSeed)) should work.

Beta D 2.072.1-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.072.1 point release.

This version resolves a number of regressions and bugs in the 2.072.0
release.

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

Please report any bugs at https://issues.dlang.org

-Martin

Re: Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

On 10/31/2016 08:45 AM, Sönke Ludwig wrote:
> BTW, I was really surprised that there was not at least one release
> candidate. There is a forward reference regression that happened after
> the last beta and affects vibe.d. I'll see if I can find a workaround.

There weren't any open regressions left in Bugzilla blocking this
release, and I did take care of that forward reference bug (Issue 16607).
I did not want to delay the release any further. We can always follow up
with point releases if more fixes come in.
I hope https://ci.dawg.eu/ helps to avoid accumulating so many issues in
the first place.

-Martin

Re: Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

On 10/31/2016 08:24 AM, Sönke Ludwig wrote:
> Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which
> means that some fixes are missing and some changes haven't gone through
> a testing phase. Can we still fix this for this release?

Shoot, sorry for that. We still need to integrate dub into
http://wiki.dlang.org/DMD_Release_Building.

Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin

Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10

[Martin Nowak via Digitalmars-d-learn]

On Monday, 17 October 2016 at 11:55:03 UTC, Martin Nowak wrote:

Please update the bug report.
https://issues.dlang.org/show_bug.cgi?id=5278


Updated, but do I seriously have to do everything? I'm not even 
an Ubuntu user.

Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10

[Martin Nowak via Digitalmars-d-learn]

On Thursday, 13 October 2016 at 18:35:43 UTC, Matthias Klumpp 
wrote:
The new toolchains of Ubuntu (and Debian soon too) default to 
PIE code, so in order to link correctly, the project needs to 
be compiled with PIE/PIC to work.


Please update the bug report.
https://issues.dlang.org/show_bug.cgi?id=5278

Re: Code signing to help with Windows virus false positives

[Martin Nowak via Digitalmars-d]

On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote:

"to MSI using innosetup" ?

There's a misunderstanding here. Inno setup doesn't compile to 
MS installer, it's a complete independant solution.


Whatever makes more sense. From my very limited understanding 
.msi installers are natively understood installers in Windows, 
and the weapon of choice for robust and more professional 
installers.
If innosetup is just another NSIS like tool, it might not solve 
all our problems.


We're fairly clueless here and could really use help here.

Just signing the NSIS installers could work for now, any support 
for this hypothesis.
I tried to submit the latest release as sample to Microsoft but 
their file upload had a size limit smaller than the binary.

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 10:45:37 UTC, Sönke Ludwig wrote:
Would have been nice in theory to have real void initialization 
of course, plus it was there for working around that (fixed?) 
issue with slow compilation times for large static arrays, but 
there is probably no real reason now to keep it.


Here is the ER for using `= void` field initializers.
[Issue 11331 – Inefficient initialization of struct with members 
= void](https://issues.dlang.org/show_bug.cgi?id=11331)

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 10:06:25 UTC, Basile B. wrote:
Any news on the front of 
https://issues.dlang.org/show_bug.cgi?id=16574 ?


It's on our heap and will be addressed soon.
Please look at our trello board.
https://trello.com/b/XoFjxiqG/active

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:
Of course, the new error is more restrictive than it should be, 
namely if the uninitialized pointer field gets written before 
the first read, it would still be safe.


That's surprising b/c void initializers for struct fields didn't 
use to work.
I need to research the intent behind this to say sth. detailed, 
though usually an shouldn't break working code, only deprecate it.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:
(after thinking a bit more) ... but Mir seems to rely in good 
part on templates, which makes pre-compiled libraries less 
effective. -- Andrei


On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:

Ilya's answer
http://forum.dlang.org/post/rexuwvohqceaglcbr...@forum.dlang.org

Sounds like a feasible approach for phobos inclusion w/ prolly 
very little usability restrictions on the generic API wrapping 
those.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Saturday, 8 October 2016 at 18:10:14 UTC, Ilya Yaroshenko 
wrote:

https://github.com/MartinNowak/druntime/blob/23373260e65af5edea989b61d6660832fedbec15/src/core/internal/arrayop.d#L78.

Could you please give an example how it works for user?
I mean aligned vs unaligned.


???

You could pack them like so.
float4 vec = loadUnaligned!float4(ptrToFloats);
float4 vec = loadAligned!float4(ptrToFloats);

The wrappers are only necessary because DMD/GDC/ldc have 
different SIMD implementations. Would be great if someone wrote a 
common basis library, unfortunately Manu's std.simd got stuck in 
progress.


Does this is always inlined intrinsic (i mean this function has 
not any its machine code in the object file / library e.g. 
always inlined into the function body even in debug 
compilaiton)?


D doesn't have macros and can't force inline, to inline w/o 
inliner you could use mixin templates, but relying on the inliner 
to do it's job would be cleaner.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Monday, 10 October 2016 at 05:20:56 UTC, Martin Nowak wrote:
(after thinking a bit more) ... but Mir seems to rely in good 
part on templates, which makes pre-compiled libraries less 
effective. -- Andrei


Exactly, this is what I was wondering. Maybe it uses a finite 
set of precompilable kernels?


Well at least for gemm pointers to kernels are used, but they are 
still templated atm.

https://github.com/libmir/mir/blob/f7a904161df7af0a8443a0237a958460432f980c/source/mir/glas/internal/gemm.d#L97

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:
You mean dmd/ldc/etc interop at binary level? Yes, that would 
be pretty


Should already work, but of courses isn't well tested.

(after thinking a bit more) ... but Mir seems to rely in good 
part on templates, which makes pre-compiled libraries less 
effective. -- Andrei


Exactly, this is what I was wondering. Maybe it uses a finite set 
of precompilable kernels?

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote:

Which branch changelog content is generated from?


Stable, the changelog is also included in the docs that are in 
the packages.

I do merge stable back into master to publish them though.

Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

Second beta for the 2.072.0 release.

We've fixed quite a few regressions, but some issues are still open and
there will be third beta before the release.
Most notably we've fixed building of dmd on OSX, so you should now be
able to test the beta using brew.

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

See the following links for all changes between 2.072.0-b1 and 2.072.0-b2.

https://github.com/D-Programming-Language/dmd/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/druntime/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/phobos/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/dlang.org/compare/v2.072.0-b1...v2.072.0-b2

Please report any bugs at https://issues.dlang.org.

-Martin

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Monday, 26 September 2016 at 20:11:19 UTC, Ilya Yaroshenko 
wrote:
Yes, the same true for Mir too. A precompiled library based on 
top of Mir GLAS can be used with DMD.


Is this feasible, i.e. is there a finite amount of kernels that 
we can precompile and use?
I thought the kernels were fully template generated, but your 
idea suggests sth. different.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko 
wrote:
4. Generic unaligned load/store like (like LDC loadUnaligned 
and storeUnaligned)


See 
https://github.com/MartinNowak/druntime/blob/23373260e65af5edea989b61d6660832fedbec15/src/core/internal/arrayop.d#L78.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Thursday, 29 September 2016 at 09:22:56 UTC, Martin Nowak 
wrote:
On Monday, 26 September 2016 at 22:34:59 UTC, Andrei 
Alexandrescu wrote:
That would work out as long as interaction is seamless. Please 
advise. Overall: I think Ilya's work can make a real 
difference for D, and we can't afford it to not work with the 
reference implementation. -- Andrei


Yes agreed, we don't want this to become the reference 
implementation.
But just as the OP mentioned I think the cost for a workable dmd 
support is fairly high, in terms of missing dmd features and 
porting mir to dmd.


Integrating this with a pre-compiled ldc library is a fantastic 
idea OTOH.
If we can make this work, it will be much less effort and yield 
the fastest implementation. Also would speed up the development 
cycle a bit b/c the kernels don't need to be recompiled/optimized.

Re: How to debug (potential) GC bugs?

[Martin Nowak via Digitalmars-d-learn]

On Saturday, 1 October 2016 at 00:06:05 UTC, Matthias Klumpp 
wrote:

So, this problem is:
 A) A compiler / DRuntime bug, or
 B) A bug in my code (not) triggered by a certain compiler / 
DRuntime


We actually did change druntime recently to no longer fail when 
using GC.free from a finalizer (will get ignored now). Maybe 
that's what fixed it for you w/ a newer version, but at a quick 
glance I haven't seen any freeing code in destructors.

Re: How to debug (potential) GC bugs?

[Martin Nowak via Digitalmars-d-learn]

On Tuesday, 4 October 2016 at 08:14:37 UTC, Ilya Yaroshenko wrote:
Probably related issue: 
https://issues.dlang.org/show_bug.cgi?id=15939


Crashes in a finalizer, likely not related to the dead-lock bug.

Re: What exactly does the compiler switch -betterC do?

[Martin Nowak via Digitalmars-d-learn]

On Wednesday, 5 October 2016 at 12:42:14 UTC
On Wednesday, 5 October 2016 at 12:42:14 UTC, Jacob Carlborg 
wrote:

No. There's a difference between DMD 2.070.0 and 2.071.0:


OK, I'll retry on OSX, the bug report said Linux though. Seems 
like we're dragging in all of the _Dmain stuff. IIRC _Dmain is 
marked as weak in some extra C file, but the problem might be 
unrelated to that.

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

Re: What exactly does the compiler switch -betterC do?

[Martin Nowak via Digitalmars-d-learn]

On Monday, 19 September 2016 at 21:09:39 UTC, Gary Willoughby 
wrote:

On Monday, 20 June 2016 at 06:35:32 UTC, Jacob Carlborg wrote:

On 2016-06-19 21:53, Gary Willoughby wrote:
If compiled with -betterC, it contains these:

 T _main
 U _printf


I get significantly more symbols than that when compiling the 
following program any idea why?


Because you're linking with druntime/phobos which drags in plenty 
of symbols (including a GC). Also Jakob is showing the symbols of 
the object file, not executable.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 2 October 2016 at 15:36:58 UTC, Jacob Carlborg wrote:
I think it could be more clear why it's deprecated and what to 
do instead:


Language construct A is deprecated.

A is bad because: ...
Do this instead: ...


Yes agreed, will try to establish a more formal format.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 2 October 2016 at 13:33:58 UTC, Basile B. wrote:
Does any change related to protection attributes would be able 
to trigger them ?
Such a breakage is really hardly believable (it's very basic 
OOP).


Please file a bug report with a code example reproducing the 
problem.

If you can't reduce the code, a big example is better than none.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 2 October 2016 at 06:13:34 UTC, Suliman wrote:

Sorry, but when new libs will be included?


We try to release regular and often (roughly every two month) to 
avoid such catch the train releases. Things should get released 
when they're ready, and only then.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 2 October 2016 at 00:18:23 UTC, Basile B. wrote:
It was compiling fine with 2.071.2. I cant say if this is a 
regression or not.
If not it would mean that the previous management of the static 
ctor hided a problem ?


Yes, previously cyclic dependencies through a third module 
without ctor were not detected correctly. Therefore it was 
possible to use a module before it was initialized.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 2 October 2016 at 11:12:41 UTC, Jacob Carlborg wrote:
It would be nice if the changelog, for the deprecated language 
constructs, contained information on what to use instead, if 
one is using them.


Yes, that's how it should be, but don't both deprecations contain 
enough information to replace old code?

Also here is the changelog if you want to improve it.
https://github.com/dlang/dlang.org/blob/6c63ab22204e4363b2ea939a090c3f8bd3e5dbed/changelog/2.072.0_pre.dd

Re: Anyone relying on signaling NaNs?

[Martin Nowak via Digitalmars-d]

On Saturday, 1 October 2016 at 19:35:54 UTC, Ilya Yaroshenko 
wrote:

Not Mir. Furthermore, default zero initialisation is better.


Yes, initializing floats to a value that is useless, requiring 
additional setting before usage is a weird design, but such a big 
change is out of scope and you can provide the init value.

Re: Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 1 October 2016 at 23:27:57 UTC, Daniel Kozak wrote:
Nice work. One small issue link to Unrestricted Unions 



It does work, there are simply no details.
Needs a bit more explanation though 
https://github.com/dlang/dmd/commit/3725a663d8aeec3350e81728173d76f429481fef#commitcomment-19255521.

Beta 2.072.0-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.072.0 release.

This release comes with many new phobos features, native TLS support on
OSX, the first bunch of @safety enhancements (try -transition=safe), and
a few smaller language and compiler additions.

This is also the first dmd release to include dub.

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

Unfortunately we still need to resolve a regression that causes issues
with EncodingScheme.create
(https://issues.dlang.org/show_bug.cgi?id=16291), you might run into
problems when using std.net.curl.

In case you run into a yet unknown module cycle, this is
likely due to the fixed cycle detection.
We're still working on a -DRT-cyclecheck=printonly switch to allow
making those non-fatal.
https://github.com/dlang/druntime/pull/1602#issuecomment-248447332

Please report any bugs at https://issues.dlang.org

-Martin

Anyone relying on signaling NaNs?

[Martin Nowak via Digitalmars-d]

Just tried to fix the float/double initialization w/ signaling NaNs [¹],
but it seems we can't reliably do that for all backends/architectures.
Any additional move of float might convert SNaNs to QNaNs (quiet NaNs).
This has also been the finding of other people [²][³].

The biggest problem w/ the current situation is that float fields of a
struct sometimes are initialized to QNaNs and fail `s.field is float.init`.

We thought about giving up on SNaNs as default float init values. Is
anyone relying on them?

-Martin

[¹]: [fix Issue 15316 - different NaN value in struct
initializer](https://github.com/dlang/dmd/pull/6163#issuecomment-250929498)
[²]: [Issue 9813 – Signalling NaN initialization does not always work
correctly on x86](https://issues.dlang.org/show_bug.cgi?id=9813)
[³]: [Coding Castles: NaNs, Uninitialized Variables, and
C++](http://codingcastles.blogspot.de/2008/12/nans-in-c.html)

Re: Release candidate vibe.d 0.7.30-rc.1

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 29 September 2016 at 13:44:53 UTC, Sönke Ludwig 
wrote:
If no new issues come up, the 0.7.30 release is scheduled for 
the 9th of October.


We want to release 2.072.0 on October 13th, will build the first 
beta today, let's aim for 0.7.30 compatibility.

Re: Overloading relational operators separately; thoughts?

[Martin Nowak via Digitalmars-d]

On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright 
wrote:

On 9/28/2016 6:58 AM, Timon Gehr wrote:

An excellent example of that is the std.regex package.
It's actually a bad example, because it is irrelevant: it is 
obviously a bad
idea to implement regex using operator overloading, because 
the regex operators

have no D equivalent.


Yet this "obviously bad" idea regularly resurfaces as a cool 
use of expression templates and respected people in the 
industry like it and advocate it.




Assume I have two symbolic expressions a and b:

Expression a=variable("a"), b=variable("b");

Why should I be allowed to do

auto c = a + b; // symbolic value a + b

but not

auto d = a <= b; // symbolic value a <= b


Because there is no way to stop the former but still have 
operator overloading.


The fact that it's not possible to overload < but have to use the 
ternary opCmp is even a performance problem. All std algorithms 
only use less as a predicate, leading to lots of unnecessary 
cycles when e.g. sorting UDTs.


While I agree with your point on expression templates, 
overloading comparison operators has valid use cases.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Monday, 26 September 2016 at 22:34:59 UTC, Andrei Alexandrescu 
wrote:
That would work out as long as interaction is seamless. Please 
advise. Overall: I think Ilya's work can make a real difference 
for D, and we can't afford it to not work with the reference 
implementation. -- Andrei


There is no point in running number crunching with a crappy 
optimizer.
The time to make it somehow still work, albeit slow, is much 
better spent on completing the science ecosystem.

Re: Interesting talk about language design and evolution

[Martin Nowak via Digitalmars-d]

On Saturday, 24 September 2016 at 18:11:25 UTC, Brad Anderson 
wrote:
On Saturday, 24 September 2016 at 03:39:00 UTC, Martin Nowak 
wrote:
A somewhat lengthy but very interesting talk about the 
tradeoffs for language design and evolution.


[CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, 
Present and 
Future"](https://www.youtube.com/watch?v=_wzc7a3McOs)


In particular the part about direction
https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about 
tradeoffs

for new features
https://youtu.be/_wzc7a3McOs?t=30m16s.


Relevant is this list of C++17 features (many of which already 
work in popular compilers).


http://stackoverflow.com/a/38060437/216300


Well if you follow the argumentation of the talk, they are not 
relevant, none of them are enabling features, most are syntax 
sugar.


I've got to admit, the D side of me is jealous of a few things 
on this list.


Comparing pointless feature lists really isn't that interesting, 
but figuring out how to do relevant features is.



Structured bindings


Somewhat undecided about this. Better support for multiple return 
values would be nice, but tuple fixes most of the needs.
Kenji's full tuple proposal also included pattern matching, but 
is that more than a functional programming abbreviation of 
if-else?


init ifs (one of those "why did it take so long to come up with 
this?" ideas)


We removed those from D, didn't we?


stackless coroutines look nice too.


They aren't, but they are indeed nice, and we should consider 
some async/await support for D as well. For I/O bound stuff 
Fibers are performant/resource-friendly enough though.
Cheap coroutines can efficiently connect ranges with trees, very 
nice

Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS

[Martin Nowak via Digitalmars-d-announce]

On Friday, 23 September 2016 at 13:25:30 UTC, Ilya Yaroshenko 
wrote:
Mir is LLVM-accelerated Generic Numerical Library for Science 
and Machine Learning.


Benchmark:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html


Still time for a few edits of that post?

Please emphasize the equally impressive comparison of the code 
necessary for the matrix multiplication.


glas.gemm(alpha, a, b, beta, c);

vs.

cblas.gemm(
cblas.Order.RowMajor,
cblas.Transpose.NoTrans,
cblas.Transpose.NoTrans,
cast(cblas.blasint) m,
cast(cblas.blasint) n,
cast(cblas.blasint) k,
& alpha,
a.ptr,
cast(cblas.blasint) a.stride,
b.ptr,
cast(cblas.blasint) b.stride,
& beta,
d.ptr,
cast(cblas.blasint) d.stride);

Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 24 September 2016 at 16:55:04 UTC, Martin Nowak 
wrote:
On Saturday, 24 September 2016 at 13:18:45 UTC, Ilya Yaroshenko 
wrote:
Thank you. Lets wait until Martin submit benchmark results too 
https://forum.dlang.org/post/mkmjxwilpvsggobak...@forum.dlang.org


Working on it in an hour, with such a strong headline we should 
avoid mistakes.


Number somewhat confirmed w/ a Skylake Core i7-6700 and DDR4 RAM, 
slight advantage for Intel.


For Intel MKL 2017.0.098
```
m=n=k,GLAS(thread_count=1),OpenBLAS(thread_count=?)
10,20,20
20,32,40
30,38.5714,60
40,64,80
50,59.5238,73.5294
60,69.6774,65.4545
70,63.5185,72.2105
80,84.6281,82.5806
90,74.0102,81
100,85.8369,81.6327
200,98.8264,98.401
300,102.079,95.7277
500,108.15,110.727
600,110.334,112.301
700,109.637,112.022
800,110.13,111.309
900,110.491,110.983
1000,109.634,111.374
1200,108.937,111.677
1400,109.837,111.249
1600,108.661,112.19
1800,109.626,112.124
2000,109.748,111.693
```
And OpenBLAS 0.2.18 (openblas-0.2.18-5.fc24.x86_64)
```
m=n=k,GLAS(thread_count=1),OpenBLAS(thread_count=?)
10,20,10
20,32,20
30,36,24.5455
40,64,37.6471
50,58.1395,40.3226
60,69.6774,46.9565
70,63.5185,45.1316
80,84.6281,58.5143
90,74.7692,53.6029
100,85.8369,62.3053
200,99.3789,80.8489
300,103.211,89.478
500,108.169,98.5416
600,110.367,101.678
700,109.49,101.634
800,110.014,100.123
900,110.266,101.126
1000,109.964,100.336
1200,109.113,101.378
1400,110.003,101.907
1600,108.596,101.66
1800,109.734,102.706
2000,109.742,103.167
```

Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 24 September 2016 at 13:18:45 UTC, Ilya Yaroshenko 
wrote:
Thank you. Lets wait until Martin submit benchmark results too 
https://forum.dlang.org/post/mkmjxwilpvsggobak...@forum.dlang.org


Working on it in an hour, with such a strong headline we should 
avoid mistakes.

Re: Argumnentation against external function operator overloading is unconvincing

[Martin Nowak via Digitalmars-d]

On Thursday, 22 September 2016 at 14:33:36 UTC, Andrei 
Alexandrescu wrote:

On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
The main problem with moving them there is auto-decoding. 
front and popFront

for strings require std.utf in order to do their thing.


Druntime has it's own utf decoding code, necessary for foreach 
auto transcoding.
Moving that to a template and syncing it with the better 
optimized Phobos implementation would be a good thing.



Yah, that's a little hurdle. -- Andrei


At least empty should go to object, could help to solve part of 
the wrong if (arr) usage.

Re: Mir GLAS vs Intel MKL: which is faster?

[Martin Nowak via Digitalmars-d]

On Saturday, 24 September 2016 at 07:20:25 UTC, Ilya Yaroshenko 
wrote:
Yesterday I announced [1] blog post [2]  about Mir [3] 
benchmark. Intel MKL and Apple Accelerate was added to the 
benchmark today.


Please help to improve the blog post during this weekend. It 
will be announced in the Reddit.


Let me run that on a desktop machine before you publish the 
results, I have a Core i7-6700 w/ 2133 MHz DDR4 RAM here.
Mobile CPU often don't reproduce the same numbers, e.g. 
https://github.com/dlang/druntime/pull/1603#issuecomment-231543115.

Re: What's up with the assert enhancements proposed years ago?

[Martin Nowak via Digitalmars-d]

On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky 
wrote:
were rejected because it was deemed both easy enough and 
preferable to get these features by modifying DMD to add 
behind-the-scenes AST magic to "assert".


So...umm...yea...whatever happened to that beefed-up "assert" 
feature?


assertPred!"=="(a, b);
assertPred!"!"(a);
assertPred!(std.range.equal)(a, b);

Seems to do most of what DIP83 does w/ expensive feature design, 
and compiler implementation work.
Also http://code.dlang.org/packages/unit-threaded comes with a 
couple of test comparators, though it follows ruby rspec's bad 
idea of giving every comparator a name (which has to be learnt 
and documented).

Interesting talk about language design and evolution

[Martin Nowak via Digitalmars-d]

A somewhat lengthy but very interesting talk about the tradeoffs for
language design and evolution.

[CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and
Future"](https://www.youtube.com/watch?v=_wzc7a3McOs)

In particular the part about direction
https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about tradeoffs
for new features
https://youtu.be/_wzc7a3McOs?t=30m16s.

Re: Diet-NG 1.0.0 released

[Martin Nowak via Digitalmars-d-announce]

On Friday, 23 September 2016 at 11:47:23 UTC, Sönke Ludwig wrote:
The Diet template language is aimed at providing a way to 
define procedurally generated HTML/XML pages (or other output 
formats), with minimal visual noise. Syntax and feature set are 
heavily inspired by pug , but instead of 
JavaScript, all expressions and statements are D statements, 
and everything that can be done at compile-time is done at 
compile-time.


Great news, in particular I like @safe, the new compile-time 
plugin, inline nested tags, and range support.

Also having it idependent of vibe.d will be useful.

Re: Proof of concept - library AA

[Martin Nowak via Digitalmars-d]

On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote:
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak 
wrote:
Is there any benefit to adding new operator overloading to 
handle this case, like a opValueAssign instead of opIndexAssign 
?


Maybe, making the two implementations behave identical can be 
done from both sides, i.e. we'll definitely make literals work 
for UDTs at some point, and given how widespread aa[key1][key2]++ 
is used we might want to come up with a UDT solution as well, but 
we can discuss this as a detail when we're at it.


One nice property of the plan is that it's already broken down 
into digestible changes, might get stuck or fail at any point, 
but still provides value from the first step on.

Re: Member not accessible in delegate body

[Martin Nowak via Digitalmars-d-learn]

On Friday, 23 September 2016 at 07:54:15 UTC, John C wrote:
If I try to call the protected method of a superclass from 
inside the body of a delegate, the compiler won't allow it.


void layoutTransaction(Control c, void delegate() action) {
  // do stuff
  action();
  // do more stuff
}

class Control {
  protected void onTextChanged() {}
}

class Label : Control {
  protected override void onTextChanged() {
layoutTransaction(this, {
  super.onTextChanged(); // <--- Error here
  changeSize();
});
  }
  private void changeSize() {}
}

Output: class Control member onTextChanged is not accessible.

How is it possible that "onTextChanged" isn't accessible but 
the private method "changeSize" *is*?


Please file a bug report issues.dlang.org, shouldn't be difficult 
to fix.

Re: Proof of concept - library AA

[Martin Nowak via Digitalmars-d]

On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:

Would be interesting to get some opinions on this.

https://github.com/D-Programming-Language/druntime/pull/1282


Bringing up this topic again b/c there was still almost no 
feedback on the actual plan. Here is a summary.


- built-in AA is too magic to be replaced by library AA
- provide a general purpose library AA with enough benefits for 
people to live with incompatibilities
- add a cheap toBuiltinAA adapter for compatibility of the 
library AA with existing code

- make array and AA literals usable with UDTs
- slowly deprecated magic behavior of the built-in AA
- switch built-in AA to library AA

Also we should plan for a std.container.aa to deal w/ all the 
fancy generic/specialized stuff.

Re: Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 20 September 2016 at 14:41:19 UTC, Bastiaan Veelo 
wrote:

The entry for 2.071.2 seems to be missing in the side panel.


Right, my mistake, even more manual maintenance.
We should really finish the tooling support for changelogs.

https://github.com/dlang/dlang.org/pull/1483

BTW, everyone is free to submit fixes for such issues, in the 
longterm this scales much better than having many people tell me 
what to do ;).

Re: Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 19 September 2016 at 12:26:21 UTC, Jack Stouffer wrote:
On a slightly related note, I think it would be a good idea to 
branch off 2.072 and start beta testing right away, as it's 
been five months since the last point release, and A LOT has 
changed since then.  I fear that we may see a huge number of 
regressions for this beta cycle because they've just been 
compounding over this time.


Yes, that was my intention as well. We'll discuss how to proceed 
in the next few days.
On the good side those have mostly been phobos instead of 
language changes.

https://github.com/dlang/dmd/compare/stable...master
AFAIK the dmd work was mostly on C->D conversion and a few 
smaller fixes for @safe and @nogc.
On the bad side phobos changes had the tendency to not care too 
much about compatibility in the past.


As I've been on vacation the past 3-4 weeks, I still need to 
catch up and get a better overview.

Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.071.2.

http://dlang.org/download.html

This point release fixes many issues with the new lookup and import
rules. It should be used as a stopgap version when updating older code.
The deprecations, the old access checks, and the
-transition=import/checkimports switches are planned to be removed with
2.073.x.

Those new rules should now be finalized and semantic changes,
deprecations, as well as the -transition=import and
-transition=checkimports switches should work as expected.
Please file a bug if you have any problems.

Also see the changelog for more details.

http://dlang.org/changelog/2.071.2.html

-Martin

Re: LDC: Speed up incremental builds with object file caching

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 18 September 2016 at 09:10:41 UTC, Johan Engelen wrote:
I think LDC has the same problems (template instances are 
emitted in the first module not the one that needed the 
instantiation?). Knowing this, you may be able to set up a case 
where things break, but I think it would have to involve 
recompilation with a different set of sources than the first 
compile. E.g. `ldc2 -c a.d b.d c.d` first, then `ldc2 -c b.d 
c.d`, and then trying to link. Which probably doesn't work well 
without caching either... We should deprecate non-singleobj 
compiles.


Yes, it's difficult to make that work correctly when the object 
cache is outside of the compiler. Maybe archives would provide a 
good way to build a better incremental rebuild support into the 
compiler.
At least with dmd's multiobj archives, template instances become 
their own object file.
It's definitely worth to put some more thought into how we can 
leverage parallel builds and incremental rebuilds.


https://trello.com/c/dBfiJHEM/72-spec-better-parallel-incremental-build-strategies-for-bigger-projects

Re: LDC: Speed up incremental builds with object file caching

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 17 September 2016 at 18:46:26 UTC, Johan Engelen 
wrote:

I just finished another post about LDC:
https://johanengelen.github.io/ldc/2016/09/17/LDC-object-file-caching.html

Thanks in advance for letting me know about any bugs you find, 
in the text or in the code :)


Interesting approach to speed up compilation without running into 
dmd's problems of template instance emission when compiling 
multiple modules to multiple objects.


Many people use noatime or relatime when mounting their 
filesystems, so access time isn't the best eviction strategy 
unless you touch the files.

Beta D 2.071.2-b6

[Martin Nowak via Digitalmars-d-announce]

Yet another beta for 2.071.2 to fix -transition=checkimports for
overload sets.

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

Please report any bugs at https://issues.dlang.org

-Martin

Beta D 2.071.2-b5

[Martin Nowak via Digitalmars-d-announce]

Fifth and hopefully last beta for the 2.071.2 release.

This comes with two more fixes for Issue 16031 and 16460.

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

Please report any bugs at https://issues.dlang.org

-Martin

Re: Release D 2.071.0

[Martin Nowak via Digitalmars-d-announce]

On Monday, 2 May 2016 at 16:47:13 UTC, Márcio Martins wrote:
Since this release is not critical for us, despite including 
many great changes, we will also stick to DMD 2.070.2 and hope 
for a fix in a future release, if at all possible.


There is an issue by now 
https://issues.dlang.org/show_bug.cgi?id=15988, but I can't 
reproduce any serious slowdowns with vibe-d, Higgs, or dcd 
comparing 2.069.2, 2.070.2, and 2.071.2-b4.

Re: Beta D 2.071.2-b4

[Martin Nowak via Digitalmars-d-announce]

On Monday, 12 September 2016 at 07:47:19 UTC, Martin Nowak wrote:

This comes with a different fix for Issue 15907 than 2.071.2-b3.


There will be another beta tomorrow or so to include at least one 
more fix (for Issue 16460) and we'll soon release 2.071.2.
This is a good moment to double check whether all the deprecation 
warnings for your project caused by the import changes are 
justified.


-Martin

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Martin Nowak via Digitalmars-d]

On Wednesday, 7 September 2016 at 19:29:05 UTC, Ali Çehreli wrote:

On 09/03/2016 09:37 AM, Martin Nowak wrote:
> On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli
wrote:

>> The recommended solution of mixing in every template
instance is not a
>> viable solution because that would effectively remove IFTI
from D.
>> What a huge loss that would be. We can't afford that.
>
> Exaggeration won't help us to find good solutions. Remember
that private
> fields never were accessible, so only some edge cases will be
affected.
> The need for mixin templates will remain rare.

I don't see how the user of a template library can decide 
whether to mixin or not without knowing the current 
implementation if of the library.


For that reason, I must mixin. For example, the following 
program is broken because I don't know whether writeln uses 
allMembers or not:


// BROKEN CODE:
MyStruct s;
writeln(s);

Do you see the problem? I can't leave that code that way. I 
have to figure out mixin writeln's instantiation. As you see, 
mixins will not be rare. Every template use must be mixed in.


Well, I can only repeat what I stated several times before, 
private members were never accessible by name (via getMember or 
.name). So either writeln uses .tupleof (unnamed) or ignores 
private members.


This is the pre 2.071 state.

method| visible | accessible

.name |y|n
getMember |y|n
.tupleof  |y|y

This was the 2.071.1 state (for which the allMembers fix was a 
valid solution).


method| visible | accessible

.name |n|n
getMember |n|n
.tupleof  |y|y

This is what we're now doing in 2.071.2 (see 
https://github.com/dlang/dmd/pull/6111),


method| visible | accessible

.name |n|n
getMember |y|n
.tupleof  |y|y

and what we plan to do with 2.072 or 2.073.

method| visible | accessible

.name |n|n
getMember |y|y
.tupleof  |y|y

In fact access checks will get removed soon.

Re: Beta D 2.071.2-b4

[Martin Nowak via Digitalmars-d-announce]

On Monday, 12 September 2016 at 08:01:00 UTC, Johan Engelen wrote:

http://dlang.org/changelog/2.071.2.html


I think the changelog has not been updated yet?


The PR is already merged. Anything wrong with the auto-deploy of 
dlang.org?

https://github.com/dlang/dlang.org/pull/1471

Beta D 2.071.2-b4

[Martin Nowak via Digitalmars-d-announce]

Fourth beta for the 2.071.2 release.

This comes with a different fix for Issue 15907 than 2.071.2-b3.

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

Please report any bugs at https://issues.dlang.org

-Martin

Re: CompileTime performance measurement

[Martin Nowak via Digitalmars-d]

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:

Hi Guys.

I recently implemented __ctfeWriteln.
Based on that experience I have now implemented another pseudo 
function called __ctfeTicksMs.
That evaluates to a uint representing the number of 
milliseconds elapsed between the start of dmd and the time of 
semantic evaluation of this expression.


For bigger CTFE programs it might be helpful.
Milliseconds are a fairly low resolution, would think with hnsec 
or so makes a better unit. Using core.time.TickDuration for that 
would make sense.

Re: CompileTime performance measurement

[Martin Nowak via Digitalmars-d]

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:

I recently implemented __ctfeWriteln.


Nice, is it only for your interpreter or can we move 
https://trello.com/c/6nU0lbl2/24-ctfewrite to done? I think 
__ctfeWrite would be a better primitive. And we could actually 
consider to specialize std.stdio.write* for CTFE.

Re: CompileTime performance measurement

[Martin Nowak via Digitalmars-d]

On Sunday, 4 September 2016 at 00:08:14 UTC, David Nadlinger 
wrote:

Please don't. This makes CTFE indeterministic.


Well we already have __TIMESTAMP__, though I think it doesn't 
change during compilation.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Martin Nowak via Digitalmars-d]

On Sunday, 4 September 2016 at 12:51:05 UTC, Andrei Alexandrescu 
wrote:
See 
http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org


There are a few cases I can think of:


The classical ones, but again the question was for introspection 
without access (b/c named access through getMember was never 
allowed, only .tupleof).
As the trade-offs for allowing access to private members don't 
seem that bad, we'll now try to go in the other direction, 
skipping visibility checks now and removing the access checks in 
a later release.

Re: Beta D 2.071.2-b3

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:

On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
There are enough ways to leak access to private entity (alias, 
template argument, taking address, some compile-time 
introspection) to make such optimizations impossible without 
extensive program analysis.


OK, anything else that would be impaired by allowing access to 
private members?
I think the unsafe requirement Walter asked for would be too 
much for the point release.
We could create an intermediate solution that ignores 
visibility but still keep the access checks around (basically 
the old behavior) until most of them will get removed in a 
later release.


I'm on vacation and travelling at the moment, so it might take a 
few days until I find time for the implementation.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Martin Nowak via Digitalmars-d]

On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
Well let's come up with a better solution then.
Let's start by finding some proper use-cases that require 
introspection on private members w/o having access to them.


Still haven't heard really good use cases for the above, but the 
trade-offs for also allowing access to private members aren't 
that bad, thus it seems like the better path forward.
See 
http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org

Re: Beta D 2.071.2-b3

[Martin Nowak via Digitalmars-d-announce]

On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:

On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
There are enough ways to leak access to private entity (alias, 
template argument, taking address, some compile-time 
introspection) to make such optimizations impossible without 
extensive program analysis.


OK


Agreed that such optimizations would require quite some front-end 
additions (keeping track if anything aliases or escapes the 
symbol), so it might not be worth with the current state of LTO.