Re: Optimisation possibilities: current, future and enhancements

[Basile B. via Digitalmars-d]

On Thursday, 25 August 2016 at 22:37:13 UTC, kinke wrote:

On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote:
From my perspective, the problem with this example isn't missed 
optimization potential. It's the code itself. Why waste 
implementation efforts for such optimizations, if that would 
only reward people writing such ugly code with an equal 
performance to a more sane `2 * foo.foo()`? The latter is a) 
shorter, b) also faster with optimizations turned off and c) 
IMO simply clearer.


You're too focused on the example itself (Let's find an non 
trivial example, but then the asm generated would be longer). The 
point you miss is that it just *illustrates* what should happend 
when many calls to a pure const function are occur in a single 
sub program.

[Issue 15703] @safe code should not allow certain types of array casts

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6086

--

Re: yet another event loop

[Bill Hicks via Digitalmars-d-announce]

On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner 
wrote:

https://github.com/caraus-ecms/tanya

Ok there are not so many event loops in D and here an another 
one and its name is "tanya".




Could you change the name to something more recognizable to help 
with D's popularity?  Something like 'kardashian' might be 
better.  Nobody really knows 'tanya', do you know what I mean?  
Maybe even 'madonna', so people will know that D is just as 
talented as others languages.


Marketing is going to be key for D, so let's do our best.

Re: Silicon Valley D Meetup August 25, 2016 - Fireside Chat with Andrei Alexandrescu

[Ali Çehreli via Digitalmars-d-announce]

https://hangouts.google.com/hangouts/_/mzzn5vtm4fd5diil6sx56eq244e?authuser=1=en

Ali

On 08/24/2016 12:17 PM, Ali Çehreli wrote:

We will post a Google Hangouts link here at the start at 19:00 (7pm)
Pacific time:

  http://www.meetup.com/D-Lang-Silicon-Valley/events/232970396/

Please try to come in person for free food and maybe a free copy of the
book "Programming in D".

The venue:

  Innowest
  764 San Aleso Ave, Sunnyvale, CA

Ali

[Issue 16424] No "DUB" component for bug reports

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from greensunn...@gmail.com ---
@Walter: You probably should ping the maintainer of Bugzilla directly, which is
Brad IIRC?

--

[Issue 16431] rdmd is slower than DUB

[via Digitalmars-d-bugs]

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

--- Comment #2 from greensunn...@gmail.com ---
> I don't think this is much of a surprise. rdmd detects dependencies. dub 
> doesn't seem to do that.

Well, it still seems unnecessary to me to run the full-blown CTFE compiler
twice on a file. I gave it a quick try with two hacks:

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

--

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/25/2016 06:37 PM, Chris Wright wrote:

On Tue, 23 Aug 2016 12:19:12 -0400, Nick Sabalausky wrote:

Couple very minor updates:


Please, for the love of potatoes, tell people what the project is for!



Oops, right, I did forget that this time, didn't I. Posted too hastily!

[Issue 15660] break "immutable" with pure function and mutable reference params

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #6 from Walter Bright  ---
(In reply to Steven Schveighoffer from comment #4)
> (In reply to Iakh from comment #3)
> > (In reply to Steven Schveighoffer from comment #2)
> > Even this works:
> > import std.stdio;
> > 
> > int[] f(void[] a) @safe pure
> > {
> > return cast(int[])a;
> > }
> 
> In this case, you are using a cast. The compiler pretty much gives up trying
> to ensure anything when you cast, so I think it's OK to allow that.
> 
> Although, I thought such a cast wouldn't work in @safe code.

And indeed, it no longer is compilable:

test.d(3): Error: cast from void[] to int[] not allowed in safe code

--

[Issue 14238] DIP25: escape checks can be circumvented with delegate

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--

Possible range idiom that I find useful, especially in @nogc

[Tofu Ninja via Digitalmars-d]

So this is a small thing but I find it definitely useful in my 
own ranges and wished the ranges in phobos did this.


A lot of ranges in phobos take an alias to a function and somehow 
use that to generate the output range, for example map. But it 
can be annoying when your map function needs extra data to 
perform the map. Example...


auto foo(R)(R range, int x) {
 return range.map!((v)=>(v+x));
}

That works perfectly well because it will allocate a closure and 
make it work. But if foo was @nogc then it would fail. If you are 
trying to avoid the gc, the basic range functions get pretty 
annoying to use.


One thing I have started doing with any of my range generators 
that take an alias to a function is to have an extra ARGS... 
argument tacked in on the end. Then the range that gets generated 
will save the extra args into the resulting range struct and pass 
them back into the alias function whenever it needs to be called.


Example:

auto RangeGenerator(alias pred, ARGS...)(ARGS args) {
// Range struct
struct Range {
private ARGS extra;
// range implementation that somehow calls pred
// If pred is normally takes a single argument, similar 
to map, like pred(item)

// then I would instead call pred(item, extra)
}
Range r;
r.extra = args;
/// any other setup
return r;
}


I use this alot, for example I have an octree implementation that 
provides range interface to iterate the items that lie in a 
specific region in space. The region is defined by a region 
function that takes an axis aligned bounding box and returns true 
or false if it lies in the region. But a lot of times the region 
function needs extra arguments to do the test, but I can't rely 
on gc allocated closures to make it possible. So instead I just 
pass the extra data into the range generator and have it saved 
into the resulting range struct. It works extremely well and 
means I don't need to use the GC.


I don't know if anyone else ever has this problem but I just 
thought I would share.

[Issue 16365] cannot allow calling function pointer from delegate in @safe code

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6085

--

[Issue 16365] cannot allow calling function pointer from delegate in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #4 from Walter Bright  ---
Related PR: https://github.com/dlang/dmd/pull/5860

--

[Issue 16365] cannot allow calling function pointer from delegate in @safe code

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |All
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=11176
 OS|Linux   |All

--

[Issue 11176] array.ptr in @safe code may point past end of array

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16365

--

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Chris Wright via Digitalmars-d-announce]

On Tue, 23 Aug 2016 12:19:12 -0400, Nick Sabalausky wrote:
> Couple very minor updates:

Please, for the love of potatoes, tell people what the project is for!

gen-package-version creates a package version string for D projects. Add 
a hook to your dub.json and then you can show off what version your 
binary was built from and when, eg:

module awesomeness.main;
void main(string[] args) {
  import awesomeness.packageVersion, std.stdio;
  if (args[1] == "--version") {
writefln("awesomeness version %s built %s",
packageVersion, packageTimestamp);
  }
}

Re: Optimisation possibilities: current, future and enhancements

[kinke via Digitalmars-d]

On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote:
The problem here that the example is bad with too agressive 
optimizations because the CALLs are eliminated despite of no 
inlining.


[...]

int use(const(Foo) foo)
{
return foo.foo() + foo.foo();
}


From my perspective, the problem with this example isn't missed 
optimization potential. It's the code itself. Why waste 
implementation efforts for such optimizations, if that would only 
reward people writing such ugly code with an equal performance to 
a more sane `2 * foo.foo()`? The latter is a) shorter, b) also 
faster with optimizations turned off and c) IMO simply clearer.

Re: [GSoC] std.experimental.xml is now a PR!

[Lurker via Digitalmars-d-announce]

On Wednesday, 24 August 2016 at 09:31:44 UTC, Lodovico Giaretta 
wrote:

Hi!

I'm pleased to announce that my GSoC project, a replacement for 
the outdated std.xml, is now a Phobos PR! [1] It is an (almost 
complete) mirror of my repository [2], which is also available 
on DUB [3].


I would like to thank my mentor Robert burner Schadek for his 
great support and everybody who already gave some feedback 
during these months.


The PR is not meant for immediate merging. Some things still 
need improvement (docs/unittests/...) while others will come in 
a second iteration (advanced DTD handling). It is meant to for 
some reviews, focusing mainly on the design and usability of 
the library.


In the PR description you will find all the details, including 
a nice "wishlist" of things that I found missing in D during 
the development and some open questions.


So, if you have any consideration/suggestion, drop a line here 
or on the PR, and if you find bugs, don't hesitate to file an 
issue on the issue tracker of my repository.


Thank you very much!

[1] https://github.com/dlang/phobos/pull/4741
[2] https://github.com/lodo1995/experimental.xml
[3] https://code.dlang.org/packages/std-experimental-xml


Looks good at first glance. How does it compare against 
established XML parsers performance-wise, e.g. Phobos XML, 
RapidXML, pugixml etc.


Tango claimed to be the fastest XML parser at some point in time, 
curious how it compares.


http://xmlbench.sourceforge.net/ might be a good start.

[Issue 16431] rdmd is slower than DUB

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
I don't think this is much of a surprise. rdmd detects dependencies. dub
doesn't seem to do that.

--

Re: Usability of D on windows?

[John Burton via Digitalmars-d]

On Thursday, 25 August 2016 at 20:47:28 UTC, David Nadlinger 
wrote:

On Thursday, 25 August 2016 at 20:31:59 UTC, John Burton wrote:

I'll try to get a self contained report tomorrow.


Please do – the -deps switch is certainly not the most 
well-tested part of LDC. It mostly inherits this part of the 
code from DMD, but there might be a subtle, unintentional 
difference hiding somewhere.


(There is also 
https://github.com/ldc-developers/ldc/issues/1625.)


 — David


If I try to compile this :-

import std.stdio;

void process(ref float[1] data)
{
for(int i = 0; i < 1; i++)
data[i] = data[i] + 1.0f;
}

void main()
{
float[1] data;
readf("%s", [0]);
process(data);
writefln("The answer is %s\n", data[0]);
}

using the command line :-

ldc2 -O -deps=out.txt test.d

Then sometimes it works and sometimes it crashes with a traceback 
(but without useful symbols for most of it).

Sounds like it could be that bug that was linked.

I don't care about the deps myself but the visual D seems to add 
it.

Re: std.functional.compose compilation error

[Antonio Corbi via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 14:30:00 UTC, Meta wrote:
On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi 
wrote:

Hello,

Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;

void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0));  // 1.4 == (2.0/3.0)^^2 + 1.0
}


I get this error (with DMD64 D Compiler v2.071.1 in linux):

compose.d(8): Error: template instance compose!(div3, sq, 
pls1) compose is not a template declaration, it is a module


But the error disappears if I use this import:
   import std.functional:compose,pipe;

Is this a bug or is it the expected behaviour under the recent 
'import' changes?

Thanks!


Try renaming your source file to something other than 
compose.d, I think that's confusing the compiler.


Yep, that did the trick!

I also noticed that 'old' compilers like:

- gdc: gdc (GCC) 6.1.1 20160501
- ldc: LDC - the LLVM D compiler (1.0.0):  based on DMD v2.070.2 
and LLVM 3.8.0


*do* compile the original code posted without error.

Thank's to all of you for your answers.

[Issue 16431] New: rdmd is slower than DUB

[via Digitalmars-d-bugs]

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

  Issue ID: 16431
   Summary: rdmd is slower than DUB
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

> python -m timeit -v -n 10 -s 'import os' 'os.system("dub run --single --force 
> foo.d")'

10 loops, best of 3: 578 msec per loop

> python -m timeit -v -n 10 -s 'import os' 'os.system("rdmd --force foo.d")'

10 loops, best of 3: 730 msec per loop


I used an example from the DLang Tour (see below or
http://tour.dlang.io/tour/en/gems/template-meta-programming) and tested with
more and the overhead seems to stay there:

== Associative arrays ==

http://tour.dlang.io/tour/en/basics/associative-arrays

rdmd 5 loops, best of 3: 637 msec per loop
dub: 5 loops, best of 3: 584 msec per loop

== Loops ==

http://tour.dlang.io/tour/en/basics/loops

rdmd: 5 loops, best of 3: 488 msec per loop
dub: 5 loops, best of 3: 373 msec per loop


#!/usr/bin/env rdmd
/+ dub.sdl:
name "foo"
+/

import std.traits: isFloatingPoint;
import std.uni: toUpper;
import std.string: format;
import std.stdio: writeln;

/// A Vector that just works for
/// numbers, integers or floating points.
struct Vector3(T)
  if (is(T: real))
{
private:
T x,y,z;

/// Generator for getter and setter because
/// we really hate boiler plate!
///
/// var -> T getVAR() and void setVAR(T)
mixin template GetterSetter(string var) {
// Use mixin to construct function
// names
mixin("T get%s() const { return %s; }"
  .format(var.toUpper, var));

mixin("void set%s(T v) { %s = v; }"
  .format(var.toUpper, var));
}

// Easily generate our getX, setX etc.
// functions with a mixin template.
mixin GetterSetter!"x";
mixin GetterSetter!"y";
mixin GetterSetter!"z";

public:
// We don't allow the dot function
// for anything but floating points
static if (isFloatingPoint!T) {
T dot(Vector3!T rhs) {
return x*rhs.x + y*rhs.y +
z*rhs.z;
}
}
}

void main()
{
auto vec = Vector3!double(3,3,3);
// That doesn't work because of the template
// constraint!
// Vector3!string illegal;

auto vec2 = Vector3!double(4,4,4);
writeln("vec dot vec2 = ", vec.dot(vec2));

auto vecInt = Vector3!int(1,2,3);
// doesn't have the function dot because
// we statically enabled it only for float's
// vecInt.dot(Vector3!int(0,0,0));

// generated getter and setters!
vecInt.setX(3);
vecInt.setZ(1);
writeln(vecInt.getX, ",",
  vecInt.getY, ",", vecInt.getZ);
}

--

Re: Usability of D on windows?

[David Nadlinger via Digitalmars-d]

On Thursday, 25 August 2016 at 20:31:59 UTC, John Burton wrote:

I'll try to get a self contained report tomorrow.


Please do – the -deps switch is certainly not the most 
well-tested part of LDC. It mostly inherits this part of the code 
from DMD, but there might be a subtle, unintentional difference 
hiding somewhere.


(There is also https://github.com/ldc-developers/ldc/issues/1625.)

 — David

Re: Judy Arrays

[Illuminati via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 20:42:42 UTC, Illuminati wrote:

http://judy.sourceforge.net/downloads/10minutes.htm

Would be nice to have such an implementation. Supposedly one of 
the best all around data structures in existence? Maybe D could 
be used to make them work with arbitrary cache-sizes?


Anyone up for the challenge?


Also, I think it would be best to avoid the GC, so it works in 
both GC code and non-gc code.

Judy Arrays

[Illuminati via Digitalmars-d-learn]

http://judy.sourceforge.net/downloads/10minutes.htm

Would be nice to have such an implementation. Supposedly one of 
the best all around data structures in existence? Maybe D could 
be used to make them work with arbitrary cache-sizes?


Anyone up for the challenge?

Re: Nogc Associative Array?

[Illuminati via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 20:11:32 UTC, Laeeth Isharc wrote:

On Thursday, 25 August 2016 at 18:14:42 UTC, Illuminati wrote:

Does D have a non-gc based associative array?

If not, what would be a good way to go about creating one?


See EMSI containers in code.dlang.org


Thanks.

Re: Usability of D on windows?

[John Burton via Digitalmars-d]

On Thursday, 25 August 2016 at 11:52:51 UTC, Kagamin wrote:

On Thursday, 25 August 2016 at 09:57:28 UTC, John Burrton wrote:
I'll try to find a small test case that crashes the compiler 
in visual D and check out what version I'm using etc, and 
submit a bug report if I am able.


Did you try to get error messages from LDC? IIRC it will print 
colored text, which may not work with a pipe.


I will try to get the exact messages tomorrow but I found that 
the difference is that under visual D it adds (amongst others) 
the -O and -deps filename options. If I add _both_ of those on 
the ldc2.exe command line it often crashes. without either it's 
stable.


I'll try to get a self contained report tomorrow.

Re: union mutability

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, August 25, 2016 19:43:49 Jack Applegame via Digitalmars-d-learn 
wrote:
> Also I hate Rebindable.

Yeah, well, without a language change, it's the best that we have for
dealing with the problem that it's designed to solve. D just isn't designed
with the idea that there's any distinction between the type of a class
reference and the type of the class it refers to.

- Jonathan M Davis

[Issue 16365] cannot allow calling function pointer from delegate in @safe code

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/3eece2fe875d35db428229b1121eda13e85b3883
partial solution for Issue 16365 - cannot allow calling function pointer from
delegate in @safe code

https://github.com/dlang/dmd/commit/627e96b986c9d94feefa5145a077eb2f820a3bef
Merge pull request #6072 from WalterBright/fix16365-1

partial solution for Issue 16365 - cannot allow calling function poin…

--

Re: Nogc Associative Array?

[Laeeth Isharc via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 18:14:42 UTC, Illuminati wrote:

Does D have a non-gc based associative array?

If not, what would be a good way to go about creating one?


See EMSI containers in code.dlang.org

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Seb via Digitalmars-d-announce]

On Thursday, 25 August 2016 at 18:05:13 UTC, Nick Sabalausky 
wrote:

On 08/24/2016 11:16 AM, Martin Nowak wrote:

[...]


I have nothing against it, I think it would be a fine optional 
feature for dub. I won't be putting together a PR for it 
though, and I don't think there's all that much of a need for 
it since gen-package-version already exists and works AND 
doesn't require dub to be used as a project's build system.


[...]


Please post your feedback to the DUB issue tracker. Ideally you 
directly group it off into multiple, actionable issues ;-)


https://github.com/dlang/dub/issues

Re: union mutability

[Jack Applegame via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 19:19:49 UTC, Jonathan M Davis 
wrote:
Why? I don't know exactly what that PR is supposed to do, but 
std.datetime uses immutable time zone objects, and if that PR 
made it so that you couldn't have an immutable instance of a 
class, then it would have failed the auto-tester. And it 
clearly doesn't stop having unions with immutable members, or 
it would have failed to compile because of Rebindable (though 
it may be that Rebindable can no longer be used in @safe code).


- Jonathan M Davis


Because lack of mutable references to immutable classes in @safe 
code is big PITA for me. It is easier to not use immutable 
classes at all.

Re: union mutability

[Jack Applegame via Digitalmars-d-learn]

Also I hate Rebindable.

Re: union mutability

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, August 25, 2016 18:27:25 Jack Applegame via Digitalmars-d-learn 
wrote:
> On Thursday, 25 August 2016 at 17:01:40 UTC, Meta wrote:
> > This should be fixed pretty soon:
> > https://github.com/dlang/dmd/pull/5940
>
> Bye-bye immutable classes. :'(

Why? I don't know exactly what that PR is supposed to do, but std.datetime
uses immutable time zone objects, and if that PR made it so that you
couldn't have an immutable instance of a class, then it would have failed
the auto-tester. And it clearly doesn't stop having unions with immutable
members, or it would have failed to compile because of Rebindable (though it
may be that Rebindable can no longer be used in @safe code).

- Jonathan M Davis

[Issue 5172] ModuleInfo's flags not correct WRT class static ctor/dtor when compiled with -lib

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Steven Schveighoffer  ---
This appears to be fixed in the latest version of the compiler, not sure when
it was fixed.

--

Re: Optimisation possibilities: current, future and enhancements

[kinke via Digitalmars-d]

On Thursday, 25 August 2016 at 18:09:14 UTC, Cecil Ward wrote:

On Thursday, 25 August 2016 at 18:07:14 UTC, Cecil Ward wrote:

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote:

[...]


I think that here the optimisation is only because LDC can 
“see” the text of the method. When expansion is not possible, 
that would be the real test.


(Assuming LDC behaves like GDC. I'm unfamiliar with LDC, I'm 
ashamed to admit.)


You're right. The question is whether it pays off to optimize 
heavily for externals. If you build all modules of a binary at 
once via `ldmd2 m1.d m2.d ...` or via `ldc2 -singleobj m1.d m2.d 
...`, LDC emits all the code into a single LLVM module, which can 
then be optimized very aggressively. So call graphs inside the 
binary are taken care of, so if it's a well encapsulated library 
with few (or expensive) calls to externals, it doesn't matter 
much.


druntime and Phobos are treated as externals. But Johan Engelen 
already pointed out that LDC could ship with them as LLVM bitcode 
libraries and then link them in before machine code generation...

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 18:17:21 UTC, Cecil Ward wrote:

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:


* special values of objects such zero, and one, so that that (x 
⊛ zero) ≡ x, and that (zero ⊛ x) ≡ x


(Should of course read
(x ⊛ zero) ≡ zero, and that (one ⊛ x) ≡ x
if you take the operator as being like multiplication.)

Re: union mutability

[Jack Applegame via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 17:01:40 UTC, Meta wrote:
This should be fixed pretty soon: 
https://github.com/dlang/dmd/pull/5940

Bye-bye immutable classes. :'(

Re: Optimisation possibilities: current, future and enhancements

[ag0aep6g via Digitalmars-d]

On 08/25/2016 08:15 PM, Basile B. wrote:

Here's a better code to illustrate the idea:

°°
interface Foo
{
int foo() const;
}

int use(const(Foo) foo)
{
return foo.foo() + foo.foo();
}
°°


And I'd expect this asm for a 'const optimization' in use():

push rbp
push rbx
push rax
mov rbx, rdi
mov rax, qword ptr [rbx]
call qword ptr [rax+08h]
add eax, eax // const funct = no side effect, so add the 1st result =
save a CALL
add rsp, 08h
pop rbx
pop rbp
ret


At least, foo needs to be `pure` for that.

Re: Optimisation possibilities: current, future and enhancements

[Basile B. via Digitalmars-d]

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote:

I found it hard to believe LDC generates such crappy code when


Yes that's right, there was an error in my script! What I've 
posted is actually the asm without -O.


Sure, Foo.foo() and use() could return a constant, but 
otherwise it can't get much better than this.


The problem here that the example is bad with too agressive 
optimizations because the CALLs are eliminated despite of no 
inlining.


Here's a better code to illustrate the idea:

°°
interface Foo
{
int foo() const;
}

int use(const(Foo) foo)
{
return foo.foo() + foo.foo();
}
°°


And I'd expect this asm for a 'const optimization' in use():

push rbp
push rbx
push rax
mov rbx, rdi
mov rax, qword ptr [rbx]
call qword ptr [rax+08h]
add eax, eax // const funct = no side effect, so add the 1st 
result = save a CALL

add rsp, 08h
pop rbx
pop rbp
ret

Re: nested enum

[Illuminati via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 01:37:05 UTC, Mike Parker wrote:

On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:

How can I create nested enum like structures?

instead of Enum.X_Y I would like to access like Enum.X.Y

Yet I want it to behave exactly as an enum.  I just want to 
not use _ as .'s are better as they express more clearly what 
I want.


struct MyEnum {
enum X { Y = 10, Z = 20 }
}

void main() {
import std.stdio;
int y = MyEnum.X.Y;
writeln(y);
}


Thanks. I should have thought of that.

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:
...
A useful phrase I saw today: “declaration of intent given by 
the programmer to the compiler”.


Particular dream wish-list items of mine: some kind of mechanism 
that could express  possible operator properties, classes 
properties and arithmetic identities, identity operations. 
Examples:

* commutativity;
* 1.0 / (1.0 / x) ≡ x, with or without ignoring of zero and 
ignoring of IEEE-weirdos; or

* sin²(x) +cos²(x) ≡ 1
* special values of objects such zero, and one, so that that (x ⊛ 
zero) ≡ x, and that (zero ⊛ x) ≡ x

* D strings can be first, so that x ~ "" ≡  x, arrays too
* arithmetic operators’ properties and identities a they apply to 
complex numbers


Another dream: Strength reductions so that sequences / patterns 
of operators (back to identities again, sort-of) could be mapped 
to named helper functions or operators. For example, with 
strings: s1 ~ s2 ~ s3 ~ … → StringArrayConcat( [] )

Re: C# 7 Features - Tuples

[rumbu via Digitalmars-d]

On Thursday, 25 August 2016 at 14:43:35 UTC, Dominikus Dittes 
Scherkl wrote:




But I dislike the named tuple members.
Why not declare them at the calling site?

(int, int, int, string) fn()
{
   return (3, 2, 1, "meins");
}

int x, y, z;
string s;
(x, y, z, s) = fn();


This is possible:

"
(string, string, string) LookupName(long id) // tuple return type
{
... // retrieve first, middle and last from data storage
return (first, middle, last); // tuple literal
}

...

"You can also deconstruct into existing variables with a 
deconstructing assignment:


(first, middle, last) = LookupName(id2); // deconstructing 
assignment"

Re: std.functional.compose compilation error

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, August 25, 2016 17:50:44 bachmeier via Digitalmars-d-learn wrote:
> On Thursday, 25 August 2016 at 17:49:26 UTC, bachmeier wrote:
> > On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis
> >
> > wrote:
> >> Yes. Because the module is compose, within that file, compose
> >> will refer to the module, not anything you import. The
> >> selective import essentially creates a local alias like
> >>
> >> alias compose = std.functional.compose;
> >>
> >> as part of the import, so then within that scope, compose
> >> refers to that alias and not to the module. You'll run into
> >> the same problem any time that you give a module the same name
> >> as a symbol that you're importing.
> >>
> >> - Jonathan M Davis
> >
> > Is there a reason there is not a warning for this when
> > compiling? I think it explains a problem I had some time ago
> > that cost me a lot of time.
>
> I mean there should be a better message.

If you have a suggestion for a better message, then feel free to open a bug
report for it - https://issues.dlang.org - or even create a pull request to
fix it if you're feeling ambitious. But shadowing like this is a normal part
of the module system. You'd get the same problem if your module was named
something else, and you declared a function named compose in your module and
then tried to use the compose from std.functional without fully qualifying
it. It can certainly be annoying if you don't realize that that's what's
happening, but how is the compiler going to know that what you meant to use
the version of compose from another module rather than the one in the
current module? All it knows is that you're using it wrong.

- Jonathan M Davis

Nogc Associative Array?

[Illuminati via Digitalmars-d-learn]

Does D have a non-gc based associative array?

If not, what would be a good way to go about creating one?

Re: C# 7 Features - Tuples

[Timon Gehr via Digitalmars-d]

On 25.08.2016 16:43, Dominikus Dittes Scherkl wrote:

On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote:

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/


came across the new c# features today. I really liked the syntax for
Tuples (and deconstructors), would be great to have a similar syntax
in D :)


Pretty obvious syntax, but would require the comma operator to be
removed. Isn't it deprecated long enough meanwhile, so we finally can
kill it?

But I dislike the named tuple members.
Why not declare them at the calling site?

(int, int, int, string) fn()
{
   return (3, 2, 1, "meins");
}

int x, y, z;
string s;
(x, y, z, s) = fn();


I don't understand. What is the issue here?

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote:
I found it hard to believe LDC generates such crappy code when 
optimizing. These are my results using LDC master on Win64 
(`ldc2 -O -release -output-s`):


struct Foo
{
immutable _u = 8;
int foo() const
{
return 8 * _u;
}
}
int use(ref const(Foo) foo)
{
return foo.foo() + foo.foo();
}

int main()
{
Foo f;
return use(f);
}


_D7current3Foo3fooMxFZi:
movl(%rcx), %eax
shll$3, %eax
retq

_D7current3useFKxS7current3FooZi:
movl(%rcx), %eax
shll$4, %eax
retq

_Dmain:
movl$128, %eax
retq

Sure, Foo.foo() and use() could return a constant, but 
otherwise it can't get much better than this.


I think that here the optimisation is only because LDC can “see” 
the text of the method. When expansion is not possible, that 
would be the real test.

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 18:07:14 UTC, Cecil Ward wrote:

On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote:

[...]


I think that here the optimisation is only because LDC can 
“see” the text of the method. When expansion is not possible, 
that would be the real test.


(Assuming LDC behaves like GDC. I'm unfamiliar with LDC, I'm 
ashamed to admit.)

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 14:42:28 UTC, Basile B. wrote:

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:

[...]


I'll add

* create temporaries based on the const function attribute.

I don't know why but I believed that it was already the case. 
After disassembling a short test with DMD and LDMD2 it appears 
clearly that this is not true:


°°
struct Foo
{
immutable _u = 8;
int foo() const
{
return 8 * _u;
}
}
int use(ref const(Foo) foo)
{
return foo.foo() + foo.foo();
}
°°

disasm of use (LDC2 via LDMD2, -O -release)

00402930h  sub rsp, 18h
00402934h  mov qword ptr [rsp+10h], rdi
00402939h  call 004028F0h ; (Foo.foo)
0040293Eh  mov rdi, qword ptr [rsp+10h]
00402943h  mov dword ptr [rsp+0Ch], eax
00402947h  call 004028F0h ; (Foo.foo)
0040294Ch  mov ecx, dword ptr [rsp+0Ch]
00402950h  add ecx, eax
00402952h  mov eax, ecx
00402954h  add rsp, 18h
00402958h  ret

But Foo.foo constness guarantees that Foo state is not 
modified. So the result of the first CALL could be cached in a 
temporary and reused instead of the second CALL. This would 
help for example in loops when a getter function is called to 
know the iteration count.


The problem of the non-caching of appropriate function calls is 
not confined to methods. It also is observable when calling 
explicitly pure-marked external functions, eg. my_pure() + 
my_pure() makes two calls. (Checked in GCC -O3, with an extern 
pure-marked function.)


This is often covered up by inlining with full expansion, as 
non-extern functions don't show this.

Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6

[Nick Sabalausky via Digitalmars-d-announce]

On 08/24/2016 11:16 AM, Martin Nowak wrote:

On Tuesday, 23 August 2016 at 16:19:12 UTC, Nick Sabalausky wrote:


gen-package-version v1.0.4:


What's your stance on including that functionality into dub?


I have nothing against it, I think it would be a fine optional feature 
for dub. I won't be putting together a PR for it though, and I don't 
think there's all that much of a need for it since gen-package-version 
already exists and works AND doesn't require dub to be used as a 
project's build system.


(As much as I love dub for package management, and having the *option* 
of using dub as a build system, dub's built-in build system just isn't 
always the best fit for all projects. Pet peeve: I still find it very 
problematic that there's really no good way to tell dub "don't attempt 
to build this project yourself as this project uses a different build 
system, so just run the following command INSTEAD of directly attempting 
to build". I've tried to fool it into not actually doing the build 
itself, but it's quite messy and problematic. It claims to be usable as 
a package-manager-only, but realistically, that's still only true for 
top-level projects that are never, ever used as a dependency, and not 
for library projects or tools that other projects may wish to rely on.)

Re: Do you like bounded integrals?

[Andrei Alexandrescu via Digitalmars-d]

Update: I've taken a shot at adding bounds, see 
https://github.com/dlang/phobos/pull/4613/commits/bbdcea723e3dd98a979ae3f06a6786645647a778. 
Here are a few notes:


* The Hook API works nicely with built-in or custom hooks, so no change 
there was necessary.


* The constructor got quite a bit more complicated because it needs to 
evaluate statically the bounds, which in turn evaluate the constructor 
statically. My solution was to define minRep and maxRep as the built-in 
representations of the min and max, and use those inside the constructor.


* There's trouble about choosing between a conservative and a statically 
precise approach to bounds computation. The simplest example is 
computing -x where x has type Checked!int. The precise result type is 
Checked!(int, int.min + 1, int.max). (If x == int.min, attempting to 
evaluate -x aborts the program.) The precise type is technically 
correct, but I assume in practice it'll just create a lot of annoyance 
due to the fact that x and -x have "slightly" different types.


* It gets worse with binary operators. Implementing the precise limits 
is a mini-project of its own (akin to the VRP algorithms). Going 
conservative (as the current work does) is annoying in a different way - 
any binary operator loses the custom limits information that the user in 
all likelihood had carefully planted.


My decision following this experiment is to drop support for custom 
limits in Checked. The complexity/power balance is untenable.


However, the hooks should be reusable with a different artifact called e.g.:

struct Bounded(T, T min, T max, Hook);

That should do precise static bounds computation in all VRP glory and 
interact well with Checked so the two can be composed.



Andrei

Re: std.functional.compose compilation error

[bachmeier via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 17:49:26 UTC, bachmeier wrote:
On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis 
wrote:


Yes. Because the module is compose, within that file, compose 
will refer to the module, not anything you import. The 
selective import essentially creates a local alias like


alias compose = std.functional.compose;

as part of the import, so then within that scope, compose 
refers to that alias and not to the module. You'll run into 
the same problem any time that you give a module the same name 
as a symbol that you're importing.


- Jonathan M Davis


Is there a reason there is not a warning for this when 
compiling? I think it explains a problem I had some time ago 
that cost me a lot of time.


I mean there should be a better message.

Re: std.functional.compose compilation error

[bachmeier via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis 
wrote:


Yes. Because the module is compose, within that file, compose 
will refer to the module, not anything you import. The 
selective import essentially creates a local alias like


alias compose = std.functional.compose;

as part of the import, so then within that scope, compose 
refers to that alias and not to the module. You'll run into the 
same problem any time that you give a module the same name as a 
symbol that you're importing.


- Jonathan M Davis


Is there a reason there is not a warning for this when compiling? 
I think it explains a problem I had some time ago that cost me a 
lot of time.

[Issue 16430] Show a warning when a semicolon is used after a struct or enum definition

[via Digitalmars-d-bugs]

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

--- Comment #4 from ag0ae...@gmail.com ---
(In reply to Steven Schveighoffer from comment #3)
> (In reply to ag0aep6g from comment #2)
> > I'd suggest warning on every empty DeclDef and not only on those behind
> > structs/enums.
> 
> for(;;)

According to , those
semicolons are part of the 'for' syntax. That is, they're not empty 'DeclDef's
(and they're not empty statements either). So they shouldn't be affected.

--

Re: 16MB static arrays again...

[Tomer Filiba via Digitalmars-d]

On Wednesday, 24 August 2016 at 18:16:01 UTC, Walter Bright wrote:

On 8/24/2016 3:35 AM, Tomer Filiba wrote:

...
Our configuration is a struct of several static hash tables 
(allocated in-place, not via GC). So the entire configuration 
is contiguous in memory

...
If I understand you correctly, removing the size limitation on 
the type will resolve the issue for you? Even though allocating 
static data of such a size will still not be allowed?


(1) Why won't allocating such static data be allowed? Gold has no 
such limitations
(2) Why do linker limitations have to do with the inner working 
on types?
(3) I may very well allocate the entire config using malloc, or 
on the stack (given a huge stack). The linker has nothing to do 
with it



BTW, given globals in C++:

   int a[100];
   float b[200];
   long c;

there actually is no guarantee that they are allocated 
contiguously, ... They'd have to be put into a struct to get a 
guarantee.


As I said (quoted above), the configuration is a struct. It looks 
like


struct Config {
Table!(K1, V1, 1) myTable;
Table!(K2, V2, 1) yourTable;
Table!(K3, V3, 1) hisTable;
Table!(K4, V4, 1) herTable;
}

So it is surely contiguous.

Table is a static hash table built on top of a static array, 
since it has a known capacity. When `V1.sizeof * 10_000 > 16MB`, 
it fails to compile


Btw, I set declare everything with `field = void` to prevent the 
struct from having a huge init symbol. I take care of 
initialization in runtime.


-tomer

Re: Optimisation possibilities: current, future and enhancements

[kinke via Digitalmars-d]

I found it hard to believe LDC generates such crappy code when 
optimizing. These are my results using LDC master on Win64 (`ldc2 
-O -release -output-s`):


struct Foo
{
immutable _u = 8;
int foo() const
{
return 8 * _u;
}
}
int use(ref const(Foo) foo)
{
return foo.foo() + foo.foo();
}

int main()
{
Foo f;
return use(f);
}


_D7current3Foo3fooMxFZi:
movl(%rcx), %eax
shll$3, %eax
retq

_D7current3useFKxS7current3FooZi:
movl(%rcx), %eax
shll$4, %eax
retq

_Dmain:
movl$128, %eax
retq

Sure, Foo.foo() and use() could return a constant, but otherwise 
it can't get much better than this.

[Issue 16430] Show a warning when a semicolon is used after a struct or enum definition

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
(In reply to ag0aep6g from comment #2)
> I'd suggest warning on every empty DeclDef and not only on those behind
> structs/enums.

for(;;)

--

Re: union mutability

[Meta via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 15:22:23 UTC, Jack Applegame wrote:

Code:

union A {
immutable int f;
}

union B {
immutable int f;
int e;
}

void main() {
A a = A(1);
//a = A(2); // a.f is immutable, fails to compile as 
expected


B b = B(1);
b = B(2); // compiles!!!
}

It turns out that if the union contains at least one mutable 
member, then the entire union is considered to be mutable.
It's logical, but does it meet the specs? I couldn't find 
description of this behavior.


This should be fixed pretty soon: 
https://github.com/dlang/dmd/pull/5940

[Issue 16430] Show a warning when a semicolon is used after a struct or enum definition

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to greensunny12 from comment #0)
> but I
> guess there are more cases where the DMD frontend accepts a lot more than
> defined by the spec.

The spec recognizes those semicolons. They're empty 'DeclDef's as per
 (at the bottom of the list).

I'd suggest warning on every empty DeclDef and not only on those behind
structs/enums.

--

Re: union mutability

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, August 25, 2016 15:22:23 Jack Applegame via Digitalmars-d-learn 
wrote:
> Code:
>
> union A {
>  immutable int f;
> }
>
> union B {
>  immutable int f;
>  int e;
> }
>
> void main() {
>  A a = A(1);
>  //a = A(2); // a.f is immutable, fails to compile as expected
>
>  B b = B(1);
>  b = B(2); // compiles!!!
> }
>
> It turns out that if the union contains at least one mutable
> member, then the entire union is considered to be mutable.
> It's logical, but does it meet the specs? I couldn't find
> description of this behavior.

Well, Rebindable depends on it (though Rebindable is in a legal grey area at
best and technically in violation of the rules at worst). It's basically the
same as when you cast away const or immutable - it's fine as long as you
don't mutate the variable and thus break the guarantees that compiler has
for const or immutable objects. But I don't know how you can really do
anything with it without violating immutable. Certainly, in any case other
than what Rebindable is up to, I wouldn't do it, and even then, I suspect
that Rebindable is in a situation where it's technically violating the
compiler's guarantees but does so in a way that will never actually result
in problems in practice.

But yes, this behavior is known, albeit questionable.

- Jonathan M Davis

[Issue 16430] Show a warning when a semicolon is used after a struct or enum definition

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
https://issues.dlang.org/show_bug.cgi?id=16378

--

Re: C# 7 Features - Tuples

[jmh530 via Digitalmars-d]

On Thursday, 25 August 2016 at 15:50:09 UTC, Seb wrote:


https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression
https://github.com/dlang/dmd/pull/5737

However working out the rules and changes for a Tuple syntax 
would be a great topic for a DIP:


https://github.com/dlang/DIPs

Btw there has been previous work on this topic, so this could 
be used as a base:


https://wiki.dlang.org/DIP32


I like DIP32, but I wouldn't be that bothered if it took until 
2018 to get something like it in D.

Re: Avoid zombie processes with std.process

[FreeSlave via Digitalmars-d]

On Thursday, 25 August 2016 at 14:53:30 UTC, Shachar Shemesh 
wrote:

On 25/08/16 11:46, FreeSlave wrote:
On Thursday, 25 August 2016 at 07:32:29 UTC, Shachar Shemesh 
wrote:

On 24/08/16 14:04, FreeSlave wrote:
Are there plans on adding something like 
spawnProcessDetached that would
start processes completely independent from parent? I.e. in 
other

process group and, what is important, with no need for wait.

On Posix that could be done via double fork technique. Not 
sure about

Windows.


Double fork on Posix is, usually, used for something slightly
different. In particular, since you bring up the process 
group, I

think you mean daemonization.

Daemonization, however, does a bit more than create a new 
process

group and double forking.

http://forum.dlang.org/thread/d83ugn$265f$1...@digitaldaemon.com 
has

discussion and some code regarding this issue.

Shachar


It's not about daemonization only. Different process group is 
needed to
prevent signal distribution. Again, e.g. file manager and 
launched

application may want to not be connected in any way.


Yes, that's part of daemonization. So is chdir somewhere else 
and closing all open file descriptors, including stdin/out/err.


http://0pointer.de/public/systemd-man/daemon.html#SysV%20Daemons


It's part of daemonization, but again, I'm not talking 
specifically about daemons. I'm talking about spawning of 
detached process (you may think about it as daemonization, but 
with less/different requirements)


Of course chdir and file descriptors should be configurable.

E.g. file managers usually set working directory of process to 
the path of executable.


When launching usual applications it's better to not close 
standard file descriptors, but redirect them to /dev/null, since 
real closing may break some apps.


Currently spawnProcess allows to set working directory and fds, 
but it implies you call wait afterwards. It would be cool if 
standard library provided the way to spawn process without 
worrying about zombies. And yes, with enough options it could 
provide support for full daemonization too (i.e. including 
closing standard fds).

Re: nested enum

[Seb via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 11:09:43 UTC, Cauterite wrote:

On Thursday, 25 August 2016 at 10:36:21 UTC, Daniel Kozak wrote:
Btw, tehre is no need for extra semicolon (`;`) after enum and 
struct definition


Thanks. This forum insists on reminding me every time I write 
code here.


Warning about this is now an enhancement request: 
https://issues.dlang.org/show_bug.cgi?id=16430

[Issue 16430] New: Show a warning when a semicolon is used after a struct or enum definition

[via Digitalmars-d-bugs]

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

  Issue ID: 16430
   Summary: Show a warning when a semicolon is used after a struct
or enum definition
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

It's probably better to issue a warning than repeating the comment over and
over in D.learn. So at least these two cases could issue a warning, but I guess
there are more cases where the DMD frontend accepts a lot more than defined by
the spec.

enum Z { one, two };

struct { int a = 1 }; 

http://forum.dlang.org/post/jwydhcjnjlhbmedwo...@forum.dlang.org

--

[Issue 16428] Better error message for pattern matching of value template parameters

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

Summary|Cannot pattern match value  |Better error message for
   |template parameter  |pattern matching of value
   ||template parameters
   Severity|normal  |enhancement

--- Comment #2 from Andrei Alexandrescu  ---
Eh, "alias" is the way, not just a workaround. Thanks! I'll repurpose this.

--

Re: C# 7 Features - Tuples

[Seb via Digitalmars-d]

On Thursday, 25 August 2016 at 15:02:06 UTC, Steven Schveighoffer 
wrote:

On 8/25/16 10:43 AM, Dominikus Dittes Scherkl wrote:

On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote:

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/


came across the new c# features today. I really liked the 
syntax for
Tuples (and deconstructors), would be great to have a similar 
syntax

in D :)


Pretty obvious syntax, but would require the comma operator to 
be
removed. Isn't it deprecated long enough meanwhile, so we 
finally can

kill it?


It was *just* deprecated, I don't think even in a released 
version yet!


-Steve


Yep,

https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression
https://github.com/dlang/dmd/pull/5737

However working out the rules and changes for a Tuple syntax 
would be a great topic for a DIP:


https://github.com/dlang/DIPs

Btw there has been previous work on this topic, so this could be 
used as a base:


https://wiki.dlang.org/DIP32

[Issue 16428] Better error message for pattern matching of value template parameters

[via Digitalmars-d-bugs]

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

--- Comment #3 from Andrei Alexandrescu  ---
The error message should be better. Currently:

static assert(is(A!(int, 42) == A!(T, x), __isexp_id52, T, x)) is false

Proposed:

static assert(is(A!(int, 42) == A!(T, x), T, x)) is false (did you mean "alias
x"?)

--

[Issue 16429] New: Sorted multimap data structure based on std.container.rbtree

[via Digitalmars-d-bugs]

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

  Issue ID: 16429
   Summary: Sorted multimap data structure based on
std.container.rbtree
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

It's not unusual to need a sorted map or multimap. For instance, a sparse event
queue is easily implemented as a sorted multimap.

While it's not exactly difficult to implement that using std.container.rbtree,
you need to know the trick of creating a struct that only uses one member in
its comparator, implement that struct, then make a wrapper around the redblack
tree implementation.

And that's assuming you know that a redblack tree can support the required
operations before looking at the module names in std.container, and you're not
tired or stressed enough to miss that the implementation presents an interface
appropriate for the purpose of finding the lowest element etc.

It would be nicer to present a module 'std.container.sortedmap' that does the
work for you, presents the interface you expect, and has a name that tells you
it does what you're after. The module could present map and multimap variants.

--

union mutability

[Jack Applegame via Digitalmars-d-learn]

Code:

union A {
immutable int f;
}

union B {
immutable int f;
int e;
}

void main() {
A a = A(1);
//a = A(2); // a.f is immutable, fails to compile as expected

B b = B(1);
b = B(2); // compiles!!!
}

It turns out that if the union contains at least one mutable 
member, then the entire union is considered to be mutable.
It's logical, but does it meet the specs? I couldn't find 
description of this behavior.

[Issue 16428] Cannot pattern match value template parameter

[via Digitalmars-d-bugs]

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
Shouldn't that be:
static assert(is(typeof(a) == A!(T, x), T, T x));
? It still fails though :(

Workaround:
static assert(is(typeof(a) == A!(T, x), T, alias x));

--

Re: std.functional.compose compilation error

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, August 25, 2016 14:30:00 Meta via Digitalmars-d-learn wrote:
> On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi wrote:
> > Hello,
> >
> > Trying to compile this example from Chuck Allison:
> > ---
> > import std.stdio;
> > import std.functional;
> >
> > void main() {
> >
> > auto div3 = (double x) => x/3.0;
> > auto sq = (double x) => x*x;
> > auto pls1 = (double x) => x+1.0;
> > alias compose!(div3,sq,pls1) comp;
> > writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
> > alias pipe!(div3,sq,pls1) pip;
> > writeln(pip(2.0));  // 1.4 == (2.0/3.0)^^2 + 1.0
> >
> > }
> > 
> >
> > I get this error (with DMD64 D Compiler v2.071.1 in linux):
> >
> > compose.d(8): Error: template instance compose!(div3, sq, pls1)
> > compose is not a template declaration, it is a module
> >
> > But the error disappears if I use this import:
> >import std.functional:compose,pipe;
> >
> > Is this a bug or is it the expected behaviour under the recent
> > 'import' changes?
> > Thanks!
>
> Try renaming your source file to something other than compose.d,
> I think that's confusing the compiler.

Yes. Because the module is compose, within that file, compose will refer to
the module, not anything you import. The selective import essentially
creates a local alias like

alias compose = std.functional.compose;

as part of the import, so then within that scope, compose refers to that
alias and not to the module. You'll run into the same problem any time that
you give a module the same name as a symbol that you're importing.

- Jonathan M Davis

Re: Pattern matching value template parameters

[Andrei Alexandrescu via Digitalmars-d]

On 08/25/2016 10:56 AM, Meta wrote:

On Thursday, 25 August 2016 at 14:53:46 UTC, Meta wrote:

On Thursday, 25 August 2016 at 14:35:06 UTC, Andrei Alexandrescu wrote:

Does anyone have a workaround for
https://issues.dlang.org/show_bug.cgi?id=16428? Thanks! -- Andrei


I don't get that error message, surprisingly. For your example code
from that bug report, I get this error message using 2.071.1:

test.d(4): Error: static assert  (is(A!(int, 42) == A!(T, x),
__isexp_id52, T, x)) is false

Which certainly looks like a bug to me.


Sorry, I misunderstood and thought you were getting an error message
about matching value parameters from a template declaration. I can
confirm that I am experiencing the *same* issue with the assert failing.


Yah, that's right. The _isexp_id52 is an additional sign something odd 
is happening. -- Andrei

Re: C# 7 Features - Tuples

[Steven Schveighoffer via Digitalmars-d]

On 8/25/16 10:43 AM, Dominikus Dittes Scherkl wrote:

On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote:

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/


came across the new c# features today. I really liked the syntax for
Tuples (and deconstructors), would be great to have a similar syntax
in D :)


Pretty obvious syntax, but would require the comma operator to be
removed. Isn't it deprecated long enough meanwhile, so we finally can
kill it?


It was *just* deprecated, I don't think even in a released version yet!

-Steve

Re: Pattern matching value template parameters

[Meta via Digitalmars-d]

On Thursday, 25 August 2016 at 14:53:46 UTC, Meta wrote:
On Thursday, 25 August 2016 at 14:35:06 UTC, Andrei 
Alexandrescu wrote:
Does anyone have a workaround for 
https://issues.dlang.org/show_bug.cgi?id=16428? Thanks! -- 
Andrei


I don't get that error message, surprisingly. For your example 
code from that bug report, I get this error message using 
2.071.1:


test.d(4): Error: static assert  (is(A!(int, 42) == A!(T, x), 
__isexp_id52, T, x)) is false


Which certainly looks like a bug to me.


Sorry, I misunderstood and thought you were getting an error 
message about matching value parameters from a template 
declaration. I can confirm that I am experiencing the *same* 
issue with the assert failing.

Re: Pattern matching value template parameters

[Meta via Digitalmars-d]

On Thursday, 25 August 2016 at 14:35:06 UTC, Andrei Alexandrescu 
wrote:
Does anyone have a workaround for 
https://issues.dlang.org/show_bug.cgi?id=16428? Thanks! -- 
Andrei


I don't get that error message, surprisingly. For your example 
code from that bug report, I get this error message using 2.071.1:


test.d(4): Error: static assert  (is(A!(int, 42) == A!(T, x), 
__isexp_id52, T, x)) is false


Which certainly looks like a bug to me.

Re: Avoid zombie processes with std.process

[Shachar Shemesh via Digitalmars-d]

On 25/08/16 11:46, FreeSlave wrote:

On Thursday, 25 August 2016 at 07:32:29 UTC, Shachar Shemesh wrote:

On 24/08/16 14:04, FreeSlave wrote:

Are there plans on adding something like spawnProcessDetached that would
start processes completely independent from parent? I.e. in other
process group and, what is important, with no need for wait.

On Posix that could be done via double fork technique. Not sure about
Windows.


Double fork on Posix is, usually, used for something slightly
different. In particular, since you bring up the process group, I
think you mean daemonization.

Daemonization, however, does a bit more than create a new process
group and double forking.

http://forum.dlang.org/thread/d83ugn$265f$1...@digitaldaemon.com has
discussion and some code regarding this issue.

Shachar


It's not about daemonization only. Different process group is needed to
prevent signal distribution. Again, e.g. file manager and launched
application may want to not be connected in any way.


Yes, that's part of daemonization. So is chdir somewhere else and 
closing all open file descriptors, including stdin/out/err.


http://0pointer.de/public/systemd-man/daemon.html#SysV%20Daemons

Re: Optimisation possibilities: current, future and enhancements

[Basile B. via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:
I'm wondering if there are more opportunities in D for 
increased optimization in compilers that have not been mined 
yet. I'm specifically interested in the possibilities of D over 
and above what is possible in C and C++ because of the 
characteristics of D or because of our freedom to change 
compared with the inertia in the C/C++ world.


[...]
Sorry it's such a paltry list. However discussion will I'm sure 
expand it.


I'll add

* create temporaries based on the const function attribute.

I don't know why but I believed that it was already the case. 
After disassembling a short test with DMD and LDMD2 it appears 
clearly that this is not true:


°°
struct Foo
{
immutable _u = 8;
int foo() const
{
return 8 * _u;
}
}
int use(ref const(Foo) foo)
{
return foo.foo() + foo.foo();
}
°°

disasm of use (LDC2 via LDMD2, -O -release)

00402930h  sub rsp, 18h
00402934h  mov qword ptr [rsp+10h], rdi
00402939h  call 004028F0h ; (Foo.foo)
0040293Eh  mov rdi, qword ptr [rsp+10h]
00402943h  mov dword ptr [rsp+0Ch], eax
00402947h  call 004028F0h ; (Foo.foo)
0040294Ch  mov ecx, dword ptr [rsp+0Ch]
00402950h  add ecx, eax
00402952h  mov eax, ecx
00402954h  add rsp, 18h
00402958h  ret

But Foo.foo constness guarantees that Foo state is not modified. 
So the result of the first CALL could be cached in a temporary 
and reused instead of the second CALL. This would help for 
example in loops when a getter function is called to know the 
iteration count.

Re: C# 7 Features - Tuples

[Dominikus Dittes Scherkl via Digitalmars-d]

On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote:

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/

came across the new c# features today. I really liked the 
syntax for Tuples (and deconstructors), would be great to have 
a similar syntax in D :)


Pretty obvious syntax, but would require the comma operator to be 
removed. Isn't it deprecated long enough meanwhile, so we finally 
can kill it?


But I dislike the named tuple members.
Why not declare them at the calling site?

(int, int, int, string) fn()
{
   return (3, 2, 1, "meins");
}

int x, y, z;
string s;
(x, y, z, s) = fn();

Re: std.functional.compose compilation error

[Meta via Digitalmars-d-learn]

On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi wrote:

Hello,

Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;

void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0));  // 1.4 == (2.0/3.0)^^2 + 1.0
}


I get this error (with DMD64 D Compiler v2.071.1 in linux):

compose.d(8): Error: template instance compose!(div3, sq, pls1) 
compose is not a template declaration, it is a module


But the error disappears if I use this import:
   import std.functional:compose,pipe;

Is this a bug or is it the expected behaviour under the recent 
'import' changes?

Thanks!


Try renaming your source file to something other than compose.d, 
I think that's confusing the compiler.

Re: Functions cannot be interpreted while being compiled

[Andrei Alexandrescu via Digitalmars-d]

On 08/25/2016 02:10 AM, Walter Bright wrote:

On 8/24/2016 10:51 PM, ketmar wrote:

p.s. i just thought that Andrei hits this somewhere in his own code,
so i asked
for a sample.


It's fine if Andrei produces a sample, and it can be compared with the
existing stuff in the test suite to see if it is fundamentally different.


It's similar. I got convinced my code was attempting something 
unreasonable. Thanks! -- Andrei

Pattern matching value template parameters

[Andrei Alexandrescu via Digitalmars-d]

Does anyone have a workaround for 
https://issues.dlang.org/show_bug.cgi?id=16428? Thanks! -- Andrei

[Issue 16428] New: Cannot pattern match value template parameter

[via Digitalmars-d-bugs]

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

  Issue ID: 16428
   Summary: Cannot pattern match value template parameter
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

struct A(T, T x = 42) {}
A!(int, 42) a;
static assert(is(typeof(a) == A!(T), T));
static assert(is(typeof(a) == A!(T, x), T, x));

The second assertion fails.

--

Re: Silicon Valley D Meetup August 25, 2016 - Fireside Chat with Andrei Alexandrescu

[Luís Marques via Digitalmars-d-announce]

On Wednesday, 24 August 2016 at 19:17:19 UTC, Ali Çehreli wrote:
We will post a Google Hangouts link here at the start at 19:00 
(7pm) Pacific time:


  http://www.meetup.com/D-Lang-Silicon-Valley/events/232970396/

Please try to come in person for free food and maybe a free 
copy of the book "Programming in D".


If I'm not too sleepy at that time (3 AM) I'll join online!

std.functional.compose compilation error

[Antonio Corbi via Digitalmars-d-learn]

Hello,

Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;

void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0));  // 1.4 == (2.0/3.0)^^2 + 1.0
}


I get this error (with DMD64 D Compiler v2.071.1 in linux):

compose.d(8): Error: template instance compose!(div3, sq, pls1) 
compose is not a template declaration, it is a module


But the error disappears if I use this import:
   import std.functional:compose,pipe;

Is this a bug or is it the expected behaviour under the recent 
'import' changes?

Thanks!

Re: C# 7 Features - Tuples

[Suliman via Digitalmars-d]

On Thursday, 25 August 2016 at 13:41:29 UTC, dom wrote:

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/

came across the new c# features today. I really liked the 
syntax for Tuples (and deconstructors), would be great to have 
a similar syntax in D :)


Yeah, it's looks very cool!

C# 7 Features - Tuples

[dom via Digitalmars-d]

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/

came across the new c# features today. I really liked the syntax 
for Tuples (and deconstructors), would be great to have a similar 
syntax in D :)

Re: yet another event loop

[Eugene Wissner via Digitalmars-d-announce]

On Thursday, 25 August 2016 at 00:24:59 UTC, mogu wrote:
On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner 
wrote:

https://github.com/caraus-ecms/tanya

Ok there are not so many event loops in D and here an another 
one and its name is "tanya".

...


Nice works, thanks.


Hey,

Thanks for your feedback. I'm very interested if someone would 
like the idea and maybe participate.


It would be also nice to have some benchmarking but I couldn't 
find an appropriate tool for this. I found some small programs 
but everything in languages I don't know, so I couldn't find out 
if my implementation doesn't work in some cases or the 
benchmarking tool. Writing an own bencmarking suite would take 
some time that I would better spend writing the library.
Maybe I should have first a simple http server. There a lot of 
matured tools for testing http.

Re: Simple GEdit .lang & github color scheme

[Matthias Klumpp via Digitalmars-d-announce]

On Wednesday, 24 August 2016 at 14:38:48 UTC, floare wrote:

Dead link (dlang gedit color highlighting)

http://reign-studios.com/d-downloads/d.lang.tar.gz


Would you mind uploading on github for instance ?


Also, if someone would simply update this with GNOMEs default 
color scheme, I could push it upstream so we wouldn't need to use 
external stuff anymore for proper D support...

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

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

--- Comment #27 from Steven Schveighoffer  ---
(In reply to Sobirari Muhomori from comment #26)
> So all this is because encoding is a part of an unknown module cycle?

It's a known module cycle (cycle is printed when it's found).

However, I think the cycle only happens when unit testing phobos. I created
another related issue to solve that problem:
https://issues.dlang.org/show_bug.cgi?id=16265

But I keep finding other bugs when trying to fix this. Which is, in a way, a
good thing.

--

Re: Optimisation possibilities: current, future and enhancements

[Andrea Fontana via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:
* Non-return-function marking, first in GCC and then in C 
itself. (iirc. And in C++?)


Maybe it could be implemented as

int blah()
out(result)
{
   assert(0);
}
body
{

}

instead of marking the function itself.

[Issue 16427] alias to typecons.Rebindable depends on lexical order

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ag0ae...@gmail.com

--

Re: The unittests are failing (individually)

[Seb via Digitalmars-d]

On Thursday, 25 August 2016 at 12:03:08 UTC, John Colvin wrote:

Try this:

git clone https://github.com/dlang/dmd
cd dmd
make -f posix.mak -j
cd ..

git clone https://github.com/dlang/druntime
cd druntime
make -f posix.mak -j
cd ..

git clone https://github.com/dlang/phobos
cd phobos
for fn in `find std -name \*.d`; do make -f posix.mak 
"${fn%.d}.test" ; done


Enjoy all those failing tests.

What's going on here?!?


P.S. here's the failing tests for me on OS X 
(std.algorithm.sorting, std.encoding, std.file, std.net.curl, 
std.process, std.zip)





As mentioned on your PR, that's a known issue/regression as 
phobosinit fails to register std.encoding for individual tests:


https://issues.dlang.org/show_bug.cgi?id=16291
https://github.com/dlang/phobos/pull/4493

Quite recently Steven fixed the cycle detection in druntime:

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

and a fix by Steven for Phobos is already in the queue:

https://github.com/dlang/phobos/pull/4744

For std.algorithm.sorting, it's a different issue (that's caused 
by a weird behavior in std.numeric entropy), but also known:


http://forum.dlang.org/post/nol5h2$lj$1...@digitalmars.com
https://github.com/dlang/phobos/pull/4587
https://issues.dlang.org/show_bug.cgi?id=16227

Once fixed, we will enable all individual tests in our CircleCi 
setup to prevent more regressions.

[Issue 16227] std.numeric unit tests fail when run in isolation

[via Digitalmars-d-bugs]

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

--- Comment #4 from greensunn...@gmail.com ---
Just for completeness this also affects std.algorithm.sorting and has been
reported by Andrei in the NG:

http://forum.dlang.org/post/nol5h2$lj$1...@digitalmars.com

And a bit later by John:

http://forum.dlang.org/post/nggdlqrbtdwikklot...@forum.dlang.org

For the code coverage we temporarily exclude std.algorithm.sorting:

https://github.com/dlang/phobos/pull/4587

--

Re: Optimisation possibilities: current, future and enhancements

[Cauterite via Digitalmars-d]

On Thursday, 25 August 2016 at 12:27:20 UTC, Cecil Ward wrote:




When I said GCC/LLVM I meant GDC(GNU D Compiler)/LDC(LLVM D 
Compiler). I might have caused some confusion there.

Re: Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

On Thursday, 25 August 2016 at 11:55:08 UTC, Cauterite wrote:

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:

* the GCC "__builtin_expect()"


Instead of adding individual micro-optimisation features like 
this, I'd be more interested in the potential for 
profile-guided optimisation (which *ideally* can make these 
micro-optimisation decisions automatically). Since DMD already 
has some framework in place to support code profiling, I 
suspect this is at least a feasible enhancement.


On the other hand, it might not be worth trying to play 
catch-up with existing PGO features in GCC/LLVM. If you're 
using PGO, you're probably already using these other backends 
for their more advanced static optimisers.


One killer reason for me to use D rather than C or C++ would be 
if it either has or could be enhanced to have greater code 
optimisation possibilities. LTO isn't relevant here because it's 
equally applicable to other languages (in GCC at any rate, as I 
understand it). Aside from its own properties, D might have an 
advantage over C because its spec development could possibly be 
more agile, well, compared with C _standards_ anyway. GCC has 
kept innovating with non-standard features, to its credit. I 
think it's desirable for D not to fall _behind_ GCC's 
non-standard powerful and ingenious tricks.

The unittests are failing (individually)

[John Colvin via Digitalmars-d]

Try this:

git clone https://github.com/dlang/dmd
cd dmd
make -f posix.mak -j
cd ..

git clone https://github.com/dlang/druntime
cd druntime
make -f posix.mak -j
cd ..

git clone https://github.com/dlang/phobos
cd phobos
for fn in `find std -name \*.d`; do make -f posix.mak 
"${fn%.d}.test" ; done


Enjoy all those failing tests.

What's going on here?!?


P.S. here's the failing tests for me on OS X 
(std.algorithm.sorting, std.encoding, std.file, std.net.curl, 
std.process, std.zip)


T=`mktemp -d /tmp/.dmd-run-test.XX` && \
	  ../dmd/src/dmd -od$T -conf= -I../druntime/import  -w -dip25 
-m64  -O -release -main -unittest 
generated/osx/release/64/libphobos2.a -defaultlib= -debuglib=  
-cov -run std/algorithm/sorting.d && \

  rm -rf $T
core.exception.AssertError@std/algorithm/sorting.d(2265): 
unittest failure


4   dmd_runbQnZeS   0x0001080cf43c 
_d_unittest + 152
5   dmd_runbQnZeS   0x000108046052 void 
std.algorithm.sorting.__unittest_fail(int) + 38
6   dmd_runbQnZeS   0x000108049bef @safe 
void std.algorithm.sorting.__unittestL2237_55() + 487
7   dmd_runbQnZeS   0x000108045748 void 
std.algorithm.sorting.__modtest() + 148
8   dmd_runbQnZeS   0x0001080cfdc0 int 
core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) + 44
9   dmd_runbQnZeS   0x0001080c82c2 int 
object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) + 34
10  dmd_runbQnZeS   0x0001080e9745 int 
rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref 
rt.sections_osx_x86_64.SectionGroup) + 85
11  dmd_runbQnZeS   0x0001080e96d0 int 
rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))) + 32
12  dmd_runbQnZeS   0x0001080c8299 int 
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) 
+ 33
13  dmd_runbQnZeS   0x0001080cfcaa 
runModuleUnitTests + 126
14  dmd_runbQnZeS   0x0001080e210e void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() + 22
15  dmd_runbQnZeS   0x0001080e20ab void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 35
16  dmd_runbQnZeS   0x0001080e2011 
_d_run_main + 497
17  dmd_runbQnZeS   0x000108046153 main + 
15
18  dmd_runbQnZeS   0x000108045653 start 
+ 51

19  ??? 0x 0x0 + 0
make: *** [std/algorithm/sorting.test] Error 1


T=`mktemp -d /tmp/.dmd-run-test.XX` && \
	  ../dmd/src/dmd -od$T -conf= -I../druntime/import  -w -dip25 
-m64  -O -release -main -unittest 
generated/osx/release/64/libphobos2.a -defaultlib= -debuglib=  
-cov -run std/encoding.d && \

  rm -rf $T
std.encoding.EncodingException@std/encoding.d(2345): Unrecognized 
Encoding: utf-16le


4   dmd_runEo4fii   0x00010bdbbd7b 
std.encoding.EncodingScheme 
std.encoding.EncodingScheme.create(immutable(char)[]) + 171
5   dmd_runEo4fii   0x00010bdbd2dd void 
std.encoding.__unittestL3186_18() + 37
6   dmd_runEo4fii   0x00010bdb4a4c void 
std.encoding.__modtest() + 88
7   dmd_runEo4fii   0x00010bdfa070 int 
core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) + 44
8   dmd_runEo4fii   0x00010bdf25f2 int 
object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) + 34
9   dmd_runEo4fii   0x00010be137cd int 
rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref 
rt.sections_osx_x86_64.SectionGroup) + 85
10  dmd_runEo4fii   0x00010be13758 int 
rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))) + 32
11  dmd_runEo4fii   0x00010bdf25c9 int 
object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) 
+ 33
12  dmd_runEo4fii   0x00010bdf9f5a 
runModuleUnitTests + 126
13  dmd_runEo4fii   0x00010be0c1ce void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() + 22
14  dmd_runEo4fii   0x00010be0c16b void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 35
15  dmd_runEo4fii   0x00010be0c0d1 
_d_run_main + 497
16  dmd_runEo4fii   0x00010bdb4e5b main + 
15
17  dmd_runEo4fii   0x00010bdb4993 start 
+ 51

18  ???

Re: Optimisation possibilities: current, future and enhancements

[Cauterite via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:

* the GCC "__builtin_expect()"


Instead of adding individual micro-optimisation features like 
this, I'd be more interested in the potential for profile-guided 
optimisation (which *ideally* can make these micro-optimisation 
decisions automatically). Since DMD already has some framework in 
place to support code profiling, I suspect this is at least a 
feasible enhancement.


On the other hand, it might not be worth trying to play catch-up 
with existing PGO features in GCC/LLVM. If you're using PGO, 
you're probably already using these other backends for their more 
advanced static optimisers.

Re: Usability of D on windows?

[Kagamin via Digitalmars-d]

On Thursday, 25 August 2016 at 09:57:28 UTC, John Burrton wrote:
I'll try to find a small test case that crashes the compiler in 
visual D and check out what version I'm using etc, and submit a 
bug report if I am able.


Did you try to get error messages from LDC? IIRC it will print 
colored text, which may not work with a pipe.

Re: Optimisation possibilities: current, future and enhancements

[Cauterite via Digitalmars-d]

On Thursday, 25 August 2016 at 11:16:52 UTC, Cecil Ward wrote:




I long for the day we ditch signalling NaNs — they would surely 
prevent `-ffast-math` from being effective.


I have a couple more ideas, here's one of them:
- if a function is pure and called with constexpr parameters, the 
compiler could potentially execute that call in the CTFE engine 
(automatically), as part of the constant-folding phase I guess. 
Such a technique will hopefully one day be practical, once the 
CTFE engine's performance improves.

Optimisation possibilities: current, future and enhancements

[Cecil Ward via Digitalmars-d]

I'm wondering if there are more opportunities in D for increased 
optimization in compilers that have not been mined yet. I'm 
specifically interested in the possibilities of D over and above 
what is possible in C and C++ because of the characteristics of D 
or because of our freedom to change compared with the inertia in 
the C/C++ world.


A useful phrase I saw today: “declaration of intent given by the 
programmer to the compiler”.


As well as the opportunities that exist in D as it stands and as 
it is _used_ currently,
I wonder what could be achieved by enhancing the language or its 
usage patterns
with new semantic restrictive markings that could be implemented 
with varying degrees of disruptiveness (from zero, up to idiom 
bans or even minor grammar changes [gulp!]). New attributes or 
property markings have already been added, I believe, during the 
history of D, which fall into this category. I'm also thinking of 
things like pragmas, functions with magic names and so forth.


Examples from the wider world, for discussion, no guarantees they 
allow increased optimisation:


* In C, the “restrict” marker
* In C++, the mechanism that makes possible optimised 
move-constructors and a solution to temporary-object hell
* assert()’s possibilities: but only if it is native and not 
deleted too early in the compiler stack - guarantees of the truth 
of predicates and restriction of values to be in known ranges, 
just as compilers can exploit prior truth of if-statements. Same 
for static assert of course
* Contracts, invariants, pre- and postconditions’ many, many 
delicious possibilities. Ideally, they need to be published, at 
two extra levels: within the same module and globally so that 
callers even from other translation units who have only the 
prototype can have a richer spec to guide inlining with truly 
first-class optimisation

* Custom calling conventions
* Some C compilers have magic to allow the declaration of an ISR. 
Stretching the category of optimisation a bit perhaps, but 
certainly does aid optimisation in the widest sense, because you 
don't then have to have unnecessary extra function-calls just to 
bolt assembler to a routine in C

* Similarly, inter-language calling mechanisms in general
* GCC and LDC’s extended asm interfacing specs, constraints and 
other magic
* Non-return-function marking, first in GCC and then in C itself. 
(iirc. And in C++?)
* the GCC "__builtin_expect()" / "likely()" and "unlikely()" 
magic marker functions to aid branch-prediction, code layout, etc

* GCC’s “builtin_assume_aligned()” function
* The GCC -ffast-math switch allows (if I understand correctly) 
the compiler to assume there are no IEEE floating-point 
weirdnesses such as infinities, NaNs, denormals anywhere, or to 
assume that the programmer just doesn't care. What if there were 
a mechanism to give kind of control down to a much more 
fine-grained level? (Such as 
per-function/operator/block/expression/object/variable.)


Sorry it's such a paltry list. However discussion will I'm sure 
expand it.