log for complex

[J-S Caux via Digitalmars-d-learn]

Simple question: how do I get the log of a complex number?

If I try the simple
logtest = log(complex(1.0, 2.0))

I get the compiler error

Error: function core.stdc.math.log(double x) is not callable 
using argument types (Complex!double)


Some basic functions are described in 
https://dlang.org/phobos/std_complex.html, but not the log...

Re: Fetch and pre-build dub dependencies

[Tamas via Digitalmars-d]

On Wednesday, 7 March 2018 at 04:28:11 UTC, Seb wrote:
For run.dlang.io, I fetch all dependencies and build them into 
the Docker image. That has the advantage that executions with 
dub packages are a lot faster.

It's just dub fetch and dub build though. Take a look:

https://github.com/dlang-tour/core-exec/blob/master/Dockerfile


Thank you for showing your solution! Using dub --single is neat 
and works well for this!

Why not flag away the mistakes of the past?

[Taylor Hillegeist via Digitalmars-d]

So i've seen on the forum over the years arguments about 
auto-decoding (mostly) and some other things. Things that have 
been considered mistakes, and cannot be corrected because of the 
breaking changes it would create. And I always wonder why not 
make a solution to the tune of a flag that makes things work as 
they used too, and make the new behavior default.


dmd --UseAutoDecoding

That way the breaking change was easily fixable, and the mistakes 
of the past not forever. Is it just the cost of maintenance?

[Issue 14242] destruction of static arrays with elaborate destructor elements does not propagate attributes

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||slavo5...@yahoo.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Mike Franklin  ---
This appears to have been fixed in 2.068.2.  I cannot reproduce it in the
latest compiler (2.079.0) either.  Resolving as WORKSFORME.

--

[Issue 17961] std.uni does not compile with -unittest -dip1000

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #11 from Carsten Blüggel  ---
(In reply to hsteoh from comment #10)
> Link: https://github.com/dlang/phobos/pull/6041

Due to lack of acceptance I closed PR
https://github.com/dlang/phobos/pull/6041.
Maybe https://github.com/dlang/phobos/pull/6212 will come to the rescue.

--

Re: Fetch and pre-build dub dependencies

[Seb via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:03:34 UTC, Tamas wrote:
I have a Dockerfile to build a vibe.d project. Docker has a 
nice caching system so it continues building the docker image 
from the step where it's needed when something changes. This is 
typically at the step of adding my source files, then building 
the binary.


The problem is that fetching and building vibe dependencies 
takes a lot of time every time some source files of mine 
changes.


I can pre-fetch dub dependencies, although it's a bit 
cumbersome as fetch doesn't load dependencies of the given 
package.


RUN dub fetch vibe-d --cache=system
RUN dub fetch vibe-core --cache=system
RUN dub fetch eventcore --cache=system


But there's no easy way to build these dependencies before I 
add my project source files to the docker image. If I could do 
that the docker build process would be tremendously faster, as 
it would be simply skipped automatically by the Docker cache 
system. Currently 99% of the time spent on building the 
dependencies when i am creating a docker image. (I have to use 
ldc for ARM, which is slower.)


Is there an easy way to fetch and prebuild a dub package 
dependencies?


something like "dub fetch-and-build vibe-d --recursive 
--cache=system"


For run.dlang.io, I fetch all dependencies and build them into 
the Docker image. That has the advantage that executions with dub 
packages are a lot faster.

It's just dub fetch and dub build though. Take a look:

https://github.com/dlang-tour/core-exec/blob/master/Dockerfile

dub fetch also fetches the dependencies of the package. The 
docker images don't have internet access on run.dlang.io, so it 
works fine for me. Maybe all you need is to disable the registry 
lookup?

Re: Release D 2.079.0

[Seb via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer 
wrote:

On 3/6/18 2:30 PM, Martin Nowak wrote:
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:


But if needed, you could have your dub package depend on a 
prior version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve


Vibe.d (and a lot of other projects) do depend on this package, 
see e.g.


https://github.com/vibe-d/vibe.d/pull/1983

Also many packages already depend on vibe.d-0.8.3, but it's in 
rc1 atm and not released as the latest stable tag yet, which is 
the reason for Atila's justified complaint.

Re: Release D 2.079.0

[rikki cattermole via Digitalmars-d-announce]

On 07/03/2018 2:54 PM, psychoticRabbit wrote:

On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:


Also, if you'll allow me to have crazy ideas for a moment, one wonders 
why we shouldn't just release Phobos itself through dub? Rust makes 
people use their build tool, why not us?


That's the day I stop using D.

I do not, and will not, use dub. Full stop.

Same goes for Rust ;-)


Under such arrangement nobody is forcing you to use dub.
We wouldn't break distribution or usage of dmd just because of changing 
a make file to dub. That's just silly.

Re: Release D 2.079.0

[psychoticRabbit via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote:


Also, if you'll allow me to have crazy ideas for a moment, one 
wonders why we shouldn't just release Phobos itself through 
dub? Rust makes people use their build tool, why not us?


That's the day I stop using D.

I do not, and will not, use dub. Full stop.

Same goes for Rust ;-)

Re: Advent of D

[Mike Parker via Digitalmars-d]

On Tuesday, 6 March 2018 at 21:09:06 UTC, Jordi Gutiérrez Hermoso 
wrote:




Posting to Reddit is easier, but I don't have a recognisable 
account on Reddit to post it from.


I'll post it. There are good times and bad times to post on 
/r/programming in terms of getting attention. A good time would 
be in about ~12 hours or so.

Re: can't build libuid examples

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 6 March 2018 at 19:19:05 UTC, greatsam4sure wrote:

Try to build libuid examples get the following error.
dub build, build successfully on the root folder. I will 
appreciate any help. Just try to build a gui app using dlang.



OPTLINK (R) for Win32  Release 8.00.17


Those "Undefined Symbol" errors all mean you aren't linking with 
the libui library. Looking at the dub.json for libuid, it 
obviously *is* configured to link with libui to build the 
examples:


https://github.com/mogud/libuid/blob/c36e994df238f03516abbb4a75ed054e44b602b5/dub.json#L21

However, if you read the project README, you'll see this:


libuid is a binding of libui. So you have to build libui first.


Did you do so? libuid provides the proper version of the libui 
source via a git submodule.


If you did build it, you probably used Visual Studio. In which 
case, you also see this in the README:


You can use --arch to specify architecture of you platform. 
Note in windows, use --arch=x86_mscoff to create 32bit binary.


By default, DMD uses the OPTLINK linker, which expects object 
files in the OMF format and is incompatible with binaries 
produced by Visual Studio (which uses the COFF format). Passing 
--arch=x86_mscoff on your dub command line will cause DMD to use 
the MS linker instead of OPTLINK.

Re: Vtable for virtual functions in D

[sarn via Digitalmars-d]

On Tuesday, 6 March 2018 at 21:20:22 UTC, Henrik wrote:
Does anyone know if D is using the vtable implementation for 
virtual functions just like most C++ compilers? If yes, can 
someone explain the advantages of this strategy? A function 
pointer in C is regarded as expensive because of missing 
inlining, but a double indirection through a vtable just looks 
insane - if there aren't really good reasons for such an 
implementation. Does it make class inheritance or class 
polymorphism much simpler to implement or what is the reason?


I have worked with C in embedded systems for many years now, 
and for our modern Linux systems we are using a combination of 
C and Java today. Java for parts where memory safety is more 
important than speed/determinism, and C for the critical real 
time parts. There should exist a language between these worlds, 
where we can achieve memory safety at relatively small costs. 
C++ is not really an alternative, and D looks much more 
pleasant for us C programmers than for example Rust.


D uses vtables.

It's a tradeoff between having double indirection and bloating 
each instance with the function pointers.  In cases where 
bloating isn't a problem, I just explicitly add normal function 
pointer members.

Re: DIP 1006 - Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 06.03.2018 19:49, Paolo Invernizzi wrote:


I simply don't understand why enforce or a custom check can't be used 
@safe code, if you want that behaviour.

...


I have explained why. UB is non-modular and you don't (want to) control 
all the code that you use. Also, enforce cannot be disabled. And no, 
keeping the check or introducing UB are not the only sensible options.

Re: Release D 2.079.0

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Mar 06, 2018 at 08:50:37PM +, Jack Stouffer via 
Digitalmars-d-announce wrote:
[...]
> Also, if you'll allow me to have crazy ideas for a moment, one wonders
> why we shouldn't just release Phobos itself through dub? Rust makes
> people use their build tool, why not us?

Please don't. I dread the day my daily dmd toolchain update script will
have to depend on dub just to be able to build a working compiler.

But personal preferences aside, one blocker to this is that dmd and
phobos (as well as druntime) development often go in lockstep, and
sometimes breaking transitions must be coordinated between them so that
git master is always buildable.  If dmd and phobos were separate repos,
it would make this coordination much, much, more difficult.

(Though, on second thoughts, that's not necessarily a bad thing, as it
will force us to actually face these issues and make Phobos buildable
with multiple compiler versions, which currently is not well supported,
if it works at all, because of said interdependence. This would also
force us to dogfood our release / deprecation processeses, which will
allow us to notice problems early and to experience what end users would
experience when transitioning between compiler versions. It *will* add
more workload to an already thin Phobos dev team, though. So there's
that.)


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

Re: DIP 1006 - Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 06.03.2018 11:17, Walter Bright wrote:

On 3/6/2018 1:58 AM, Jonathan M Davis wrote:

[...]


The entire point of making assert a core language feature was so that 
the compiler could take advantage of it to generate better code.


It does not need to be a core language feature for that.
It seems that you did the right thing for the wrong reasons.

It's 
been like that for D since day 1. It has always been documented to do 
that. It has been discussed many times in this n.g. over the years with 
lng threads. I designed it that way so that D could potentially 
produce better code than other languages in ways they could not match.


There is no other purpose to making it a core language feature.
...


Yes. The (only!) purpose is standardization. asserts and contracts are a 
core language feature for similar reasons why unit tests are a core 
language feature.



...

Or just don't turn off assert checking. Personally, I use asserts in a 
way that they add little overhead so they can remain active in the 
release build.

...


Not everybody runs only their own code.


It's entirely under your control.


It is not. Could we please make it that way?

Re: DIP 1006 - Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 06.03.2018 10:02, Walter Bright wrote:

On 3/6/2018 12:45 AM, Timon Gehr wrote:
Anyway, "do not use assert" is not the solution, as I have explained 
many times now.


My interpretation is you want D assert to behave like C assert.


This interpretation is wrong. I, as well as other people, want a 
compiler option to make the compiler ignore D asserts and contracts. Not 
more, not less.


C assert 
and enforce are purely creatures of the library, with semantics defined 
by their library implementation, and have no effect on the core language.

...


That's a meaningless proposition. The current D -release assert behavior 
can be implemented in a library (just trigger UB in the false branch).


I recommend creating your own library assert, call it 'check' for 
example, and give it the semantics you wish. You can even have it expand 
to nothing for release builds.

...


Well, awesome. Now I need to make everyone on the project as well as 
external libraries, such as Phobos, use my 'check' function, when the 
contract documentation tells them to use assert and does not even hint 
at the downsides. No, thanks. I'd rather fork the compiler.


But I have explained this (and further reasons) already. I suspect you 
did not read my posts. A few others have. I'll try to keep this one shorter.


Creating library asserts is why D has special support for __FILE__ and 
__LINE__ like C does, and for the same reasons.


What I want is special support for sane built-in assert semantics using 
a compiler flag. That does not mean that there cannot _also_ be a flag 
to unleash the nasal demons upon unworthy programmers who were stupid 
enough to collaborate with someone who imported an external library that 
was written by somebody who had a bad day one time and left in a wrong 
assertion.


Again: There is no reason why we need to force one behavior over the 
other. This should be configurable.

[Issue 18557] Types with 0 size should not be usable as aa key types

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #3 from Ketmar Dark  ---
this patch breaks Variant: it is legal to use `This[This]` as a placeholder
type in Variant, and with the patch applied that code doesn't compiles anymore
('cause `This` is defined as `struct This;`).

adding real definition to `This` doesn't help too, 'cause then dmd errored with
"recursive template expansion".

--

[Issue 18564] core.demangle exception Range violation

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Rainer Schuetze  ---
Did you try latest dmd master? There have been a couple of recent fixes that
look similar, e.g. https://issues.dlang.org/show_bug.cgi?id=18300 and
https://issues.dlang.org/show_bug.cgi?id=18208.

--

[Issue 18542] DMD could generate better assembly for common range check idioms

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Why does this not compile?

[Timon Gehr via Digitalmars-d]

On 06.03.2018 17:19, Steven Schveighoffer wrote:


unittest {
 int n = 0;
 struct S {
 int fun() const { return n; }
 }
 immutable S s;
 assert(s.fun == 0);
 n++;
 assert(s.fun == 1); // Not so immutable now, are you?
}


That's not a demonstration of breaking immutability. counter-proof:

struct S
{
    static int x;
    int fun() const { return x; }
}

immutable S s;
assert(s.fun == 0);
S.x++;
assert(s.fun == 1);

In other words, if the struct can access the data considered "outside 
it's instance", then it it can return it, change it even.


Here's how to break immutability:

void main(){
int i = 0;
struct S{
const(int)* fun()const pure{
return 
}
}
immutable S s;
static const(int)* foo(immutable(S) s)pure{
return s.fun();
}
immutable(int) *pi=foo(s);
import std.stdio;
writeln(*pi); // 0
i+=1;
writeln(*pi); // 1
}

The reasoning "the reference is stored in the type yet not part of the 
type" does not work for pure functions, as then you cannot offer an 
alternative explanation in terms of an external data store.


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

[Issue 18567] New: immutability hole related to context pointers accessed through const pure methods

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18567
   Summary: immutability hole related to context pointers accessed
through const pure methods
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD 2.079.0

void main(){
int i = 0;
struct S{
const(int)* fun()const pure{
return 
}
}
immutable S s;
static const(int)* foo(immutable(S) s)pure{
return s.fun();
}
immutable(int) *pi=foo(s);
import std.stdio;
writeln(*pi); // 0
i+=1;
writeln(*pi); // 1
}

I.e. the data *pi is typed as immutable(int), yet changes.

--

[Issue 18566] New: const on method of nested data type is not applied to variables in context

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18566
   Summary: const on method of nested data type is not applied to
variables in context
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

void main(){
int i = 0;
struct S{
int *fun()const pure{
return  // compiles, but shouldn't
}
}
}

The type of i within "fun" should be "const(int)".

--

[Issue 18563] context pointer inside structs constness problems

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from Ketmar Dark  ---
compiler transforms `==` for objects to virtual call, and dmd cannot
devirtualize calls (yet? ;-). so yeah, no inlining.

it is quite possible to rewrite the call into `e1 is e1 || .object.opEquals(e1,
e2)`, tho.


--- a/src/ddmd/opover.d
+++ b/src/ddmd/opover.d
@@ -30,6 +30,7 @@ import ddmd.globals;
 import ddmd.id;
 import ddmd.identifier;
 import ddmd.mtype;
+import ddmd.sideeffect;
 import ddmd.statement;
 import ddmd.tokens;
 import ddmd.visitor;
@@ -1162,7 +1163,7 @@ extern (C++) Expression op_overload(Expression e, Scope*
sc)
 if (!(cd1.cpp || cd2.cpp))
 {
 /* Rewrite as:
- *  .object.opEquals(e1, e2)
+ *  e1 is e2 || .object.opEquals(e1, e2)
  */
 Expression e1x = e.e1;
 Expression e2x = e.e2;
@@ -1176,12 +1177,38 @@ extern (C++) Expression op_overload(Expression e,
Scope* sc)
 if (cd2.isInterfaceDeclaration())
 e2x = new CastExp(e.loc, e.e2, t2.isMutable() ? to :
to.constOf());

+/* create temporaries, to avoid invalid rewriting of this:
+ *if (arr[i++] is obj || .object.opEquals(arr[i++],
obj)
+ * rewrite to:
+ *tmp1 = e1x, tmp2 = e2x, then use temps
+ */
+// load e1x to temporary
+auto tmp1 = copyToTemp(STCnodtor, "__opEqualsTmp1", e1x);
+auto e1xtmp = new CommaExp(e.loc, new
DeclarationExp(e.loc, tmp1), new VarExp(e.loc, tmp1));
+
+// load e2x to temporary
+auto tmp2 = copyToTemp(STCnodtor, "__opEqualsTmp2", e2x);
+auto e2xtmp = new CommaExp(e.loc, new
DeclarationExp(e.loc, tmp2), new VarExp(e.loc, tmp2));
+
+// e1 is e2
+auto expis = new IdentityExp(TOKidentity, e.loc, e1xtmp,
e2xtmp);
+
+// and use fresh varexps with temps (previous ones can be
changed by semanticing)
+e1x = new VarExp(e.loc, tmp1);
+e2x = new VarExp(e.loc, tmp2);
+
+// .object.opEquals(e1, e2)
 result = new IdentifierExp(e.loc, Id.empty);
 result = new DotIdExp(e.loc, result, Id.object);
 result = new DotIdExp(e.loc, result, Id.eq);
 result = new CallExp(e.loc, result, e1x, e2x);
+
+// expis || result
+result = new LogicalExp(e.loc, TOKoror, expis, result);
+
 if (e.op == TOKnotequal)
 result = new NotExp(e.loc, result);
+
 result = result.semantic(sc);
 return;
 }

--

[Issue 18562] expression is not evaluated when accessing manifest constant

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18560] find on infinite ranges is broken

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18565] New: std.regex Captures opAssign returns void since v2.079.0

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18565
   Summary: std.regex Captures opAssign returns void since
v2.079.0
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: d.b...@webfreak.org

Before commit 59520969ef73eaf0691972ee00b389e5bbc4c8fb this code used to work:

---
import std.regex;

void main()
{
string str;
Captures!string match;
if (cast(bool)(match = str.matchFirst("a"))
 || cast(bool)(match = str.matchFirst("b"))) {}
}
---

and it performed the expected operations. However now the compilation fails
with:

---
a.d(7): Error: cannot cast expression match.opAssign(matchFirst(str, "a")) of
type void to bool
a.d(8): Error: cannot cast expression match.opAssign(matchFirst(str, "b")) of
type void to bool
---

--

Re: Advent of D

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 6 March 2018 at 21:09:06 UTC, Jordi Gutiérrez Hermoso 
wrote:

I did post it to Lobsters, though:


This is random but I have been thinking about asking for a 
lobsters invite... can you hook me up?

Vtable for virtual functions in D

[Henrik via Digitalmars-d]

Does anyone know if D is using the vtable implementation for 
virtual functions just like most C++ compilers? If yes, can 
someone explain the advantages of this strategy? A function 
pointer in C is regarded as expensive because of missing 
inlining, but a double indirection through a vtable just looks 
insane - if there aren't really good reasons for such an 
implementation. Does it make class inheritance or class 
polymorphism much simpler to implement or what is the reason?


I have worked with C in embedded systems for many years now, and 
for our modern Linux systems we are using a combination of C and 
Java today. Java for parts where memory safety is more important 
than speed/determinism, and C for the critical real time parts. 
There should exist a language between these worlds, where we can 
achieve memory safety at relatively small costs. C++ is not 
really an alternative, and D looks much more pleasant for us C 
programmers than for example Rust.

Re: Advent of D

[Jordi Gutiérrez Hermoso via Digitalmars-d]

On Tuesday, 6 March 2018 at 20:37:34 UTC, Steven Schveighoffer 
wrote:

On 3/6/18 1:09 PM, Jordi Gutiérrez Hermoso wrote:
I wrote a blog post about working on Advent of Code in D. You 
can read it here:


http://jordi.inversethought.com/blog/advent-of-d/


I'm enjoying this.

One thing jumped out at me: static does not mean execute at 
compile time (exactly), it really means allocate this data in 
thread-local storage.


Thanks for the explanation. I forgot about using enum instead. I 
think I've only briefly encountered it before. I'm aware of the 
global storage of static in this context. I like that it's the 
same keyword for static foreach; that's kind of what I was 
thinking when I wrote that just adding a static can result in 
compile-time execution.



BTW, that tour page needs updating, it has a few errors in it.


You mean the Dlang tour? I've been meaning for a while to be able 
to generate a url to its Gems section but I've never managed to 
untangle its Vibe.d structure enough to do so.

Re: Advent of D

[Jordi Gutiérrez Hermoso via Digitalmars-d]

On Tuesday, 6 March 2018 at 21:03:47 UTC, JN wrote:
On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez 
Hermoso wrote:
I wrote a blog post about working on Advent of Code in D. You 
can read it here:


http://jordi.inversethought.com/blog/advent-of-d/


on Day 8, I think the original "verbose" code is better in the 
end. Mixin at least for me makes it a bit less clear on what 
exactly is going on. On the other hand the latter version is 
probably easier to maintain and more copy-paste-error-proof.


Yeah, it's mostly the C that I wanted to get rid of. I do wish 
the static foreach had worked, though! It's odd that you can't 
have compile-time associative arrays.

Re: Advent of D

[Jordi Gutiérrez Hermoso via Digitalmars-d]

On Tuesday, 6 March 2018 at 20:09:58 UTC, Joakim wrote:

Nice write-up, worth sharing on reddit/HN.


Thanks. I tried posting it to HN, but it didn't pick up. If 
several of you try posting it too, it might pick up.


Posting to Reddit is easier, but I don't have a recognisable 
account on Reddit to post it from.


I did post it to Lobsters, though:

https://lobste.rs/s/b4qki7/advent_d

Setting executable's information by resources

[Marc via Digitalmars-d-learn]

I'm trying to use this resource to set executable's 
information/metadata but it fail to set anything but the icon, 
without any error message. Could anyone point out if there's 
anything wrong with my approach?
(if anyone use a different approach/toolset to set those data, 
your suggestion is very welcome)


commands:


C:\dm\bin\rcc.exe -32 -D__NT__ res.rc
dmd app.d res.res


resource file


IDI_ICON1   ICONDISCARDABLE "ico.ico"
#include "version.h"
VS_VERSION_INFO VERSIONINFO
FILEVERSION VER_FILEVERSION
PRODUCTVERSION  VER_PRODUCTVERSION
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
  BLOCK "040904E4"
  BEGIN
  VALUE "CompanyName",VER_COMPANYNAME_STR
  VALUE "FileDescription",VER_FILEDESCRIPTION_STR
  VALUE "FileVersion",VER_FILEVERSION_STR
  VALUE "InternalName",   VER_INTERNALNAME_STR
  VALUE "LegalCopyright", VER_LEGALCOPYRIGHT_STR
  VALUE "LegalTrademarks1",   VER_LEGALTRADEMARKS1_STR
  VALUE "LegalTrademarks2",   VER_LEGALTRADEMARKS2_STR
  VALUE "OriginalFilename",   VER_ORIGINALFILENAME_STR
  VALUE "ProductName",VER_PRODUCTNAME_STR
  VALUE "ProductVersion", VER_PRODUCTVERSION_STR
  END
  END
  BLOCK "VarFileInfo"
  BEGIN
  VALUE "Translation", 0x409, 1252
  END
END

Re: Advent of D

[JN via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso 
wrote:
I wrote a blog post about working on Advent of Code in D. You 
can read it here:


http://jordi.inversethought.com/blog/advent-of-d/


on Day 8, I think the original "verbose" code is better in the 
end. Mixin at least for me makes it a bit less clear on what 
exactly is going on. On the other hand the latter version is 
probably easier to maintain and more copy-paste-error-proof.

Re: Release D 2.079.0

[Random D user via Digitalmars-d-announce]

On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
I'd have a snowball's chance in hell convincing anyone at a 
"regular" company of adopting D if anyone there even imagined 
any of the above could happen.


We have to do better than this.

Atila


I don't think this is unusual even outside of D.
At least Microsoft seems to be willing to break your build if it 
moves things forward. For example, there are projects that worked 
fine on MSVC 15.4 (VS2017), but broke if you installed the update 
to 15.5 (or auto-updated in Visual Studio).

You can't test everything.

A lot of the "regular" companies, that desire high stability, 
typically use very old compilers and just workaround the bugs 
they know.
For a D example, I think Sociomantic was using D1 for a long time 
just because it was stable for them.


And if you need stability, why would you update the compiler 
without local testing and reserving time to fix any issues?

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #30 from Andrei Alexandrescu  ---
Indeed it seems we are not supporting registration by address with ease for D
value types.

There are good reasons for that; by allowing value types to be moved around we
avoid a swath of complications and difficulties that C++ encounters with their
definition of rvalue references and move constructors. That C++ feature
complicates all code considerably and still has a variety of safety,
correctness, and efficiency issues (I am not exaggerating; all three problems
are present) that make the bread and butter of advanced C++ instructors
worldwide, including myself. I think we got the better deal there.

The disadvantage is that indeed an object can be born and die at different
addresses. So self-registering objects by address, or objects holding internal
pointers, do not work with automatic allocation. Such is the nature of
automatic allocation in D. 

(It should be noted that C++ has its own, distinct issues with self-registering
objects, to which I dedicate several slides in
http://erdani.com/index.php/training/mc1xd.)

Allow me to make a few suggestions for workarounds:

* Avoid automatic/stack allocation and also return by value. A struct may hold
internal pointers and a constant address as long as the memory it's in is not
automatic/stack. If you use raw memory in conjunction with functions such as
emplace and destroy, you have good control. As a perk, you avoid the creation,
copying, and destruction of spurious objects - which comes along with calls to
register/unregister, which I assume has a significant cost.

* Use a "cookie", not an address, in the registration. A classic registration
pattern returns a cookie/handle, usually an integer, which the object stores.
Then, the object passes that cookie back to the unregister function. In other
words, if the address of an object isn't invariant, let's define something that
is.

* Use dynamic allocation in conjunction with reference counting. I know this
has been mentioned and dismissed as too expensive, but I'm mentioning it for
completeness. Also, it's one of those cases in which engineering can go a long
way: use a high-performance allocator (for which we have a solid framework in
the standard library), duplicate objects lazily, etc.

If after exploring these and other solutions you come to the conclusion they
are not satisfactory, I encourage you to create a DIP. Two possible lines of
attack are:

(1) Allow specifying that an object can't be moved
(2) Allow a type to intercept its move by means of a nothrow hook

Drawing from extensive experience with Phobos and its very generic code, I can
tell you I foresee difficulties with (1). Anything that makes types "more
special than others" is bound to cause a smorgasbord of special handling in the
library. I think (2) would be a better angle because it encapsulates the
handling with the type.

Thanks!

--

Re: Release D 2.079.0

[Jack Stouffer via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:
That being said, I'm wondering if it wouldn't be better to have 
std.experimental be in its own repository. This allows 
selection of the dependency on std.experimental separate from 
phobos. It still would be an "official" dlang package, and 
might even be included in the distribution (the latest version 
anyway), and docs included on the website. But if needed, you 
could have your dub package depend on a prior version.


The entire concept needs a reexamination IMO. I just checked the 
git history, and not one module has graduated from 
std.experimental to mainline Phobos since the idea's inception in 
2014. While it's possible that none of the modules are ready, 
logger has been there for four years now. I was against changing 
how experimental is handled in the past, but I recently have 
started to rethink how we promote modules.


Also, if you'll allow me to have crazy ideas for a moment, one 
wonders why we shouldn't just release Phobos itself through dub? 
Rust makes people use their build tool, why not us?

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Advent of D

[Steven Schveighoffer via Digitalmars-d]

On 3/6/18 1:09 PM, Jordi Gutiérrez Hermoso wrote:
I wrote a blog post about working on Advent of Code in D. You can read 
it here:


http://jordi.inversethought.com/blog/advent-of-d/


I'm enjoying this.

One thing jumped out at me: static does not mean execute at compile time 
(exactly), it really means allocate this data in thread-local storage.


What triggers the compile-time execution is the fact that static 
*initializers* need to be decided at compile time.


So while it is executing the regex building at compile time in your 
example, there are other ways to do it, and in this case, I'd prefer 
using an enum. You can also use ctRegex.


The drawback of using static is that it keeps its value between function 
calls:


int bar() { return 42; }

void foo()
{
   static x = bar();
   x += 5;
   writeln(x);
}

void main()
{
   foo(); // 47
   foo(); // 52
}

So it may not be what you are looking for.

Whereas if you use:

void foo()
{
enum x = bar();
writeln(x + 5);
}

it will always write the same answer (and not allocate global space for it).

BTW, that tour page needs updating, it has a few errors in it.

-Steve

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Johan Engelen via Digitalmars-d]

On Tuesday, 6 March 2018 at 20:25:10 UTC, Johan Engelen wrote:

On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote:
On my LLVM fork for RISC-V and MSP430 work it doesn't build 
(no llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake 
fails to configure (Unknown CMake command 
"add_llvm_install_targets").


LLDB and LLVM need to be version synchronized. Did you checkout 
LLVM and LLDB both from their respective same-named release 
branches?


I'm pretty sure Timothee based his patch onto LLDB/LLVM trunk.

-Johan

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Johan Engelen via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote:
On my LLVM fork for RISC-V and MSP430 work it doesn't build (no 
llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake 
fails to configure (Unknown CMake command 
"add_llvm_install_targets").


LLDB and LLVM need to be version synchronized. Did you checkout 
LLVM and LLDB both from their respective same-named release 
branches?


-Johan

Re: Profiling after exit()

[Martin Nowak via Digitalmars-d-learn]

On Thursday, 27 July 2017 at 15:16:35 UTC, Eugene Wissner wrote:

Are there profilers that work well with dmd? valgrind? OProfile?


Yes, any sampling profiler works fine, e.g. perf on linux, Intel 
VTune/AMD CodeXL on Windows.
Those directly monitor CPU performance counters and have a 
negligible performance overhead compared with dmd's instrumenting 
profiler, also they don't require rebuilding of binaries.

[Issue 18564] core.demangle exception Range violation

[d-bugmail--- via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||mangling

--

[Issue 18564] core.demangle exception Range violation

[d-bugmail--- via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry
 CC||r.sagita...@gmx.de

--

[Issue 18564] New: core.demangle exception Range violation

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18564
   Summary: core.demangle exception Range violation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

Testcase:
```
import core.demangle;
import std.stdio;

void main() {
enum str =
"UVVUYUUY";

writeln(demangleType(str));
}
```

Instead of outputting the string, we get:
`core.exception.RangeError@core/demangle.d(230): Range violation`

(found by fuzz testing, but I get a range violation on the same line with a
real world type mangle too)

--

Re: Advent of D

[Patrick Schluter via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso 
wrote:
I wrote a blog post about working on Advent of Code in D. You 
can read it here:


http://jordi.inversethought.com/blog/advent-of-d/


Really nice, thank you.

Re: How to use globals correctly?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 06, 2018 11:52:05 H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Tue, Mar 06, 2018 at 11:46:04AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> > On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote:
> [...]
>
> > > Singletons are always smelly code tbh.
> > >
> > > Especially in D with thread-local storage.
> > >
> > > I can't think of a situation where you truly need singletons in D.
> >
> > I confess that I've never really understood why some folks dislike
> > singletons so much, but then again, I've only rarely found cases where
> > I thought that they made sense, and I gather that some folks out there
> > use the singleton pattern way too much (I've heard it suggested that
> > it's because it was one of the few design patterns from the design
> > pattern book that was easy).
>
> [...]
>
> To me, a singleton is a symptom of excessive dogmatic adherence to the
> OO religion where Everything Must Be A Class No Matter What. When there
> can only be one of something, it's clearly no longer a *class*, but is
> either a module, a global variable, or a (set of) global function(s).
>
> I'm curious to know what are the few cases where you think a singleton
> made sense, where it wouldn't be more appropriately implemented as a
> module, global variable, or global function(s).

It makes sense whenever it doesn't make sense to have multiple instances of
a particular class, and it makes sense to enforce that. As I explained,
LocalTime and UTC from std.datetime do that for exactly that reason. Cases
like that are rare, but they do exist. However, they also exist rarely
enough that it's going to be hard to come up with more examples.

I judge whether singletons makes sense on a case-by-case basis. Sometimes,
they do make sense, so I wouldn't say that they're necessarily a code smell,
but I also completely agree that they rarely make sense. So, I don't
disagree that singletons should rarely be used. I just disagree with the
idea that they should never be used.

And for better or worse, singletons are one of those things that seems to me
like it should usually be obvious whether they make sense in a particular
case, but that doesn't seem to be true for everyone, otherwise there
wouldn't be as much of a dislike of singletons as there seems to be, since
they wouldn't come up very often.

- Jonathan M Davis

Re: Advent of D

[Joakim via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso 
wrote:
I wrote a blog post about working on Advent of Code in D. You 
can read it here:


http://jordi.inversethought.com/blog/advent-of-d/


What's with the mammoth D blog posts lately? Nice write-up, worth 
sharing on reddit/HN.

[Issue 18561] postblit should allow writing const/immutable members just like constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Steven Schveighoffer  ---
(In reply to anonymous4 from comment #3)
> a.__ctor(1);

This is another bug. One should only be able to call const __ctor on a struct
once, before using it.

--

Re: 5000 Merged Phobos Pull Requests

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 06, 2018 at 07:21:10PM +, Jack Stouffer via Digitalmars-d wrote:
> Nine days ago, Phobos hit 5000 merged pull requests:
> 
> https://github.com/dlang/phobos/pulls?page=201=is%3Apr+is%3Amerged+sort%3Amerged-desc=✓
> 
> Thats an average of 1.93 merged PRs per day (first PR merged on Jan
> 31, 2011).
> 
> A huge thank you to everyone who made this happen.

Very nice!

One thing I would really like to see, though, is the reduction of the
average size of the Phobos PR queue. Last month when I had a spot of
free time I was diving into the deep end of the "cesspool", so to speak,
of old Phobos PRs that have been languishing in the queue for far too
long.  With some effort, we managed to get the queue down to <100.  I
wanted to drive it down further, but then got busy with other things and
haven't been able to work on Phobos PRs much since.  Sadly, the queue
has clogged back up to the 100+'s, with no end in sight. :-(

It would be nice if somebody, or preferably a group of somebodies, would
take on the task of digging into the deep end of the Phobos PR queue and
either kick them back to life, revive them, or decide they're not worth
the effort and close them.  Having a PR sit in there forever with no
sign of when / whether it will ever be merged is a big morale killer.

You don't need commit privileges to contribute; there are plenty of
other ways to help, like pinging the submitter if he's gone missing, or
pinging Phobos devs if people seem to have forgotten about perfectly
good work, or taking a look at the code and pointing out obvious / not
so obvious issues.  Or simply just pinging people (esp. @andralex :-D)
and making yourself a nuisance if a PR seems stuck for no good reason.

While understandably Andrei would hesitate handing out commit rights too
easily, having a larger group of people help in these other ways would
greatly help improve Phobos. (And if you get busy enough, Andrei might
notice and give you commit rights. ;-) Which would help with our
manpower problem.)


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George 
Orwell

Re: See docs compiler message

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/6/18 9:50 AM, ixid wrote:

On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote:
Now, there aren't actually docs for Transposed, but you can find it if 
you look at std.range.transposed:


https://dlang.org/phobos/std_range.html#transposed



Thanks, I had found that but that is not an explanation unless you have 
a lot of prior technical understanding of what save is and why it's not 
working. I guess it's a general doc quality issue - unless you're 
already very knowledgeable it's pretty much useless to understand the 
problem you have.


There are 2 problems. One is that Transposed offered .save as a member, 
when it shouldn't have (it's not a valid forward range). This is clear 
from trying to even use it as a forward range. Even when you call save, 
it destroys the original.


The other problem is that I think algorithms are seeing that .save is 
there, and thinking it's a forward range, so using it that way.


I transposed a range of ranges to pass to a function to get the distance 
between characters in strings. That works fine, as does printing the 
result. But it then complains if I try to do anything like fold with the 
result.


I have no idea how save is called, but apparently it is somewhere in there.

-Steve

[Issue 18561] postblit should allow writing const/immutable members just like constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from ajiesk...@gmail.com ---
(In reply to anonymous4 from comment #3)
> This passes:
> ---
> struct A
> {
> int a;
> this(int b) const { a=b; }
> }
> int main()
> {
> const A a;
> assert(a.a==0,"0");
> a.__ctor(1);
> assert(a.a==1,"1");
> return 0;
> }
> ---

I believe it should not. Yes, constructor should be able to do that, but only
when used as a constructor. But it is a separate issue from this one.

--

Re: DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis via Digitalmars-d]

On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via Digitalmars-d 
wrote:
> I simply don't understand why enforce or a custom check can't be
> used @safe code, if you want that behaviour.
>
> If the program must HALT on this or that, well, what is better
> than an explicit piece of unremovable code that do that? Instead
> of writing 'assert', one should write 'enforce'.

1. It's quite common for folks to want to add debugging checks that are
compiled out in -release. That's exactly what assert is for in pretty much
every lanugage that has it. It's what folks expect to use and what your
average programmer will use without thinking about @safety issues at all.
It's what everyone uses right now, and I'm pretty sure that almost everyone
using it has no clue that Walter considers it okay for assertions to
introduce optimizations which are not memory safe, and if/when he does do
so, a lot of D code will suddenly have @safe code which is not memory safe.
Such problems will hopefully be hit rarely, because hopefully, the code will
have been well-tested, and the assertions will have found all of the related
bugs, but there's every possibility that some bugs will manage to not be
caught, thereby resulting in @safe code being unsafe. No one is going to be
looking to use solutions other than assertions for what assertions are for
unless we start telling everyone to avoid assertions, because they make
@safe code unsafe. And honestly, if assertions make @safe code unsafe, I
don't see a good argument for using them at all. If I didn't care about code
being @safe, I wouldn't be using @safe. @safe is supposed to guarantee that
the code is memory safe.

2. I think that it's fundamentally a terrible idea to allow built-in
language features to violate @safe. Aside from issues related to @trusted
being misused, @safe code should be guaranteed to be memory safe, and it
should be considered a bug any time that it isn't. That's why @safe exists.
No one should have to be looking at @safe code to track down memory safety
problems. And if they do, then @safe is not doing it's job. Array bounds
checks are left in @safe code for exactly these reasons.

I'm all for introducing optimizations that do not violate @safe, but if we
allow @safe code to be unsafe, then why do we even have it?

- Jonathan M Davis

Re: Release D 2.079.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/6/18 2:30 PM, Martin Nowak wrote:

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:



But if needed, you could have your dub package depend on a prior version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve

Re: How to use globals correctly?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 06, 2018 at 11:46:04AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote:
[...]
> > Singletons are always smelly code tbh.
> >
> > Especially in D with thread-local storage.
> >
> > I can't think of a situation where you truly need singletons in D.
> 
> I confess that I've never really understood why some folks dislike
> singletons so much, but then again, I've only rarely found cases where
> I thought that they made sense, and I gather that some folks out there
> use the singleton pattern way too much (I've heard it suggested that
> it's because it was one of the few design patterns from the design
> pattern book that was easy).
[...]

To me, a singleton is a symptom of excessive dogmatic adherence to the
OO religion where Everything Must Be A Class No Matter What. When there
can only be one of something, it's clearly no longer a *class*, but is
either a module, a global variable, or a (set of) global function(s).

I'm curious to know what are the few cases where you think a singleton
made sense, where it wouldn't be more appropriately implemented as a
module, global variable, or global function(s).


T

-- 
Старый друг лучше новых двух.

[OT] Gaming Meetup

[WebFreak001 via Digitalmars-d]

Hi, I was planning on going to what is basically a LAN Party in 
the Netherlands near Venlo and was wondering if anyone in this 
community also went or would want to go. It is themed after a 
certain computer game called osu! which probably not a lot of you 
play, but it might still be a nice opportunity to meet up and 
after all that's not all we will be playing there.


Not sure how many gamers there are in this community but maybe 
someone will go too and we could meet. It's around end of July 
and you can go for up to 10 days (I will probably be there 9 days 
starting saturday), details can be found on https://cavoeboy.com/

Re: DIP 1006 - Preliminary Review Round 1

[12345swordy via Digitalmars-d]

On Tuesday, 6 March 2018 at 18:49:42 UTC, Paolo Invernizzi wrote:
I simply don't understand why enforce or a custom check can't 
be used @safe code, if you want that behaviour.


/Paolo


Easy:
the custom check itself could be wrong
the custom check itself is right, but the implementation is wrong 
even though it may passed your unit tests.

Re: Release D 2.079.0

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
Can somebody explain how [0] is more safe than array.ptr? 
Just want to understand why second statement isn't allowed in 
safe anymore.


[0] is runtime bounds-checked
array.ptr is unchecked and might return an out-of-bounds pointer 
(to the first element)

Re: Release D 2.079.0

[Martin Nowak via Digitalmars-d-announce]

On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote:
Good stuff. Still bothers me that we had to special case "throw 
new Exception();" in order to make it nogc. I can't think of 
any better ways right now


Implementing EH for values (instead of class references) would 
have been a lot more complex.



but I wish it was more explicit.


Initially people always want more explicitness for new, not yet 
too well known, features, while later opting for terser syntax 
for commonly used things.
Exceptions are supposed to be rare and deleting them directly 
after being catched seemed like a reasonable enough default to go 
with the specialization.

After all it solves a huge problem, error handling in @nogc code.
Maybe we'll find a better/cleaner solution when more of the 
language has been transitioned to @safe @nogc.

Re: Release D 2.079.0

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote:
The problem with that is I was waiting for 2.079.0 since it 
fixes a bug that prevented me from upgrading to any of the 
2.078.x releases on Windows.


I think 2.078 would make an excellent starting point for a LTS 
because of the important fixes that only made it to 2.079. If 
anyone is interested to backport fixes and maintain such a 
source-branch, please contact me.

Re: Release D 2.079.0

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer 
wrote:
That being said, I'm wondering if it wouldn't be better to have 
std.experimental be in its own repository.


Just showing that phobos is not the right place to develop 
modules/packages, also mir.
IMO std.experimental provides little benefit over dub, but comes 
with many downsides.


This allows selection of the dependency on std.experimental 
separate from phobos.


You cannot link against diamond dependencies of different 
versions though, so we'd have to exclude it from libphobos and 
put it separately.


It still would be an "official" dlang package, and might even 
be included in the distribution (the latest version anyway), 
and docs included on the website.


Not sure why inclusion in distribution is often mentioned as such 
a thing.
It's trivial and common to have separate libraries/dependencies 
in every language with a healthy ecosystem.


But if needed, you could have your dub package depend on a 
prior version.


http://code.dlang.org/packages/stdx-allocator ;)

Re: Speed of math function atan: comparison D and C++

[jmh530 via Digitalmars-d-learn]

On Tuesday, 6 March 2018 at 18:41:15 UTC, H. S. Teoh wrote:


The fix itself may be straightforward, but how to do it without 
breaking tons of existing code and provoking user backlash is 
the tricky part.

[snip]


Ah, I see what you're saying. People may be depending on the 
extra accuracy for these functions.


Would just require something like

double sin(double x) @safe pure nothrow @nogc
{
version (FP_Math) {
///double sin implementation
} else {
return sin(cast(real) x);
}
}

5000 Merged Phobos Pull Requests

[Jack Stouffer via Digitalmars-d]

Nine days ago, Phobos hit 5000 merged pull requests:

https://github.com/dlang/phobos/pulls?page=201=is%3Apr+is%3Amerged+sort%3Amerged-desc=✓

Thats an average of 1.93 merged PRs per day (first PR merged on 
Jan 31, 2011).


A huge thank you to everyone who made this happen.

Re: Article: Why Const Sucks

[Martin Nowak via Digitalmars-d-announce]

On Monday, 5 March 2018 at 17:38:52 UTC, H. S. Teoh wrote:

struct Container {
auto opSlice() const {
static struct Result {
private Container impl;
private int n; // internal mutable state
@property bool empty() { ... }
... // rest of range API
}
return Result(this);
}
}


That's definitely a know problem with ranges that hasn't yet been 
solved.

The known workaround is to implement Range and ConstRange.
This idiom could prolly be encapsulated in a safe and generic 
template type to avoid boilerplate.

If we had some covariant mechansim to implement sth. similar to

struct Range(T) if (is(T InoutT == inout))
{
inout(InoutT) opIndex(size_t i) inout;
}

that would be ideal, but that isn't exactly trivial.
I think we had a better issue for this topic, but here is one 
ticket asking for this feat.
[9983 – inout type can not be used as a parameter for structure 
template](https://issues.dlang.org/show_bug.cgi?id=9983)

[Issue 9983] inout type can not be used as a parameter for structure template

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Severity|normal  |enhancement

--

can't build libuid examples

[greatsam4sure via Digitalmars-d-learn]

Try to build libuid examples get the following error.
dub build, build successfully on the root folder. I will 
appreciate any help. Just try to build a gui app using dlang.



OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App)
 Error 42: Symbol Undefined _uiControlDestroy
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App)
 Error 42: Symbol Undefined _uiMain
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowTitle
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetTitle
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowPosition
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetPosition
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowCenter
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowContentSize
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetContentSize
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowFullscreen
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetFullscreen
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowBorderless
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetBorderless
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetChild
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowMargined
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowSetMargined
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiOpenFile
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiSaveFile
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiMsgBox
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiMsgBoxError
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiNewWindow
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowOnPositionChanged
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowOnContentSizeChanged
..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window)
 Error 42: Symbol Undefined _uiWindowOnClosing

Re: Article: Why Const Sucks

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, March 06, 2018 19:06:25 Martin Nowak via Digitalmars-d-announce 
wrote:
> On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote:
> > I'm not actually convinced that killing auto-decoding is really
> > much better.
>
> I don't think the problem is auto-decoding in string range
> adapters, but repeated validation.
> https://issues.dlang.org/show_bug.cgi?id=14519#c32
> If you know that sth. works on code units just use
> .representation.
>
> There is the related annoyance when the user of a function
> presumably knows to only deal with ASCII strings but algorithms
> fail, e.g. splitter.popBack or binary search. This one is tricky
> because broken unicode support is often rooted in ignoring it's
> existence.

Yes, using stuff like representation or byCodeUnit helps to work around the
auto-decoding, but as long as it's there, you have to constantly work around
it if you care about efficiency with strings and/or want to be able to
retain the original string type where possible. At this point, I think that
it's pretty clear that we wouldn't have it if we could do stuff from
scratch, but of course, we can't do stuff from scratch, because that would
break everything.

- Jonathan M Davis

[Issue 18134] BitArray >>= broken when length % (8 * size_t.sizeof) == 0

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 18134] BitArray >>= broken when length % (8 * size_t.sizeof) == 0

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b211347454b70fdb5a539f3fd8bc82fcec846e70
Fix issue 18134 - BitArray right shift broken if length is multiple of
8*size_t.sizeof

https://github.com/dlang/phobos/commit/6264e40d8abbb411d4391b3cf8c4d2d4c69423e1
Merge pull request #6110 from byebye/issue_18134

Fix issue 18134 - BitArray right shift broken if length is multiple of
8*size_t.sizeof
merged-on-behalf-of: Jack Stouffer 

--

Re: Article: Why Const Sucks

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote:
I'm not actually convinced that killing auto-decoding is really 
much better.


I don't think the problem is auto-decoding in string range 
adapters, but repeated validation.

https://issues.dlang.org/show_bug.cgi?id=14519#c32
If you know that sth. works on code units just use 
.representation.


There is the related annoyance when the user of a function 
presumably knows to only deal with ASCII strings but algorithms 
fail, e.g. splitter.popBack or binary search. This one is tricky 
because broken unicode support is often rooted in ignoring it's 
existence.

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #29 from Jonathan M Davis  ---
(In reply to Tomer Filiba (weka) from comment #27)
> I don't suppose this would help. It seems the & operator is just not allowed
> in safe code:
> 
> void main() @safe {
> int x;
> auto tmp = // Error: cannot take address of local x in @safe
> function
> }

That code becomes @safe with -dip1000, because then it's inferred as scope, and
the compiler verifies that it doesn't escape, whereas without DIP 1000 and its
improvements to scope, the compiler doesn't have any way to ensure that the
resulting pointer is used in an @safe manner. So, DIP 1000 should have a fairly
large impact on how @safe certain operations are.

(In reply to Tomer Filiba (weka) from comment #28)
> My point is, @safe is so constrained that it's practically unusable, so I
> don't consider it a viable solution for this problem.

That would be highly dependent on what your code is doing and how willing you
are to vet code and mark functions @trusted where appropriate or use @trusted
lambdas to mark sections of code as @trusted (which isn't the most ideal
solution for marking a section of code as @trusted, but it's the best we have
right now).

 If you're constantly doing stuff like taking the address of a local variable,
then yes, @safe is going to be a miserable mess (though DIP 1000 may fix that).
But a lot of code can be @safe with no problem. It really depends on the type
of stuff your code is doing.

--

Re: mysql-native v2.1.0

[bauss via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote:

On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote:
On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky 
(Abscissa) wrote:

[...]


I'm unsure how I'd go about implementing prepared statements 
in a vibe.d application correctly.


[...]


Like more specifically do I still call lockConnection() on a 
MySQLPool?


I think it would be easier to help me if I put some examples.

I just tried changing stuff and I can't seem to get it working.

I kept using lockConnection() as before, I assume it's the right 
way.


Then I changed the way I retrieve prepared statements from:

  auto prepared = prepare(connection, sql);
  prepared.setArgs(params);

to:

  auto prepared = connection.prepare(sql);
  prepared.setArgs(params);

Then ex. for reading many entries:

From:

  return prepared.querySet().map!((row)
  {
auto model = new TModel;
model.row = row;
model.readModel();
return model;
  });

To:

  return connection.query(prepared).map!((row)
  {
auto model = new TModel;
model.row = row;
model.readModel();
return model;
  });

But it doesn't seem to work.

I get the following exception:

"Attempting to popFront an empty map" which I assume is because 
the result is empty.


So what am I doing wrong in using prepared statements with the 
new updates?

Re: Article: Why Const Sucks

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, March 06, 2018 10:47:36 H. S. Teoh via Digitalmars-d-announce 
wrote:
> On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via 
Digitalmars-d-announce wrote:
> > On 3/6/18 10:39 AM, Jonathan M Davis wrote:
> > > Yeah. If you're dealing with generic code rather than a specific
> > > range type that you know is implicitly saved when copied, you have
> > > to use save so often that it's painful, and almost no one does it.
> > > e.g.
> > >
> > > equal(lhs.save, rhs.save)
> > >
> > > or
> > >
> > > immutable result = range.save.startsWith(needle.save);
> >
> > Yep. The most frustrating thing about .save to me is that .save is
> > nearly always implemented as:
> >
> > auto save() { return this; }
> >
> > This just screams "I really meant just copying".
>
> Yeah, and also:
>
>   auto save() {
>   auto copy = this;
>   copy.blah = blah.dup;
>   return this;
>   }
>
> Which just screams "I'm really just a postblit in disguise".

That's exactly what it is. It's a postblit constructor that you have to call
manually and which works for classes and dynamic arrays in addition to
structs.

- Jonathan M Davis

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #28 from Tomer Filiba (weka)  ---
My point is, @safe is so constrained that it's practically unusable, so I don't
consider it a viable solution for this problem.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #27 from Tomer Filiba (weka)  ---
(In reply to Andrei Alexandrescu from comment #25)
> > So... more special cases?
> 
> That's a straight use of scope per DIP 1000, in fact the very design intent:
> scope in a function signature specifies the function won't escape the
> parameter.

I don't suppose this would help. It seems the & operator is just not allowed in
safe code:

void main() @safe {
int x;
auto tmp = // Error: cannot take address of local x in @safe
function
}

--

Re: DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi via Digitalmars-d]

On Tuesday, 6 March 2018 at 17:34:08 UTC, 12345swordy wrote:
On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis 
wrote:
On Tuesday, March 06, 2018 16:30:09 John Colvin via 
Digitalmars-d wrote:

On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote:
> [...]

So, to clarify, adding asserts to my code makes my release 
builds violate @safe?


If the compiler actually optimized based on assertions, then 
yes, but not right now. As I understand it, the problem is 
theoretical at the moment, because the compiler does not yet 
optimize based on assertions, but once it does, if it's 
allowed to introduce optimizations that would be not be memory 
safe if the assertion would have failed if it hadn't been 
compiled out, then @safe will be violated, and at that point, 
I would be telling everyone to never use assertions, because 
they're too dangerous.


If we can restrict the compiler to optimizations that are 
memory safe, then I don't see a problem, but clearly, Walter 
is not in agreement that the optimizations should be 
restricted in that manner.


- Jonathan M Davis


I think a reasonable compromise is to introduce a new system 
attribute such as @unsafeoptimize to tell the programmer that 
this function may have it's @safe attribute removed when making 
optimizations based on the asserts. We have @trusted attribute 
for a good reason here.


I simply don't understand why enforce or a custom check can't be 
used @safe code, if you want that behaviour.


If the program must HALT on this or that, well, what is better 
than an explicit piece of unremovable code that do that? Instead 
of writing 'assert', one should write 'enforce'.


/Paolo

Re: Article: Why Const Sucks

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via 
Digitalmars-d-announce wrote:
> On 3/6/18 10:39 AM, Jonathan M Davis wrote:
> > Yeah. If you're dealing with generic code rather than a specific
> > range type that you know is implicitly saved when copied, you have
> > to use save so often that it's painful, and almost no one does it.
> > e.g.
> > 
> > equal(lhs.save, rhs.save)
> > 
> > or
> > 
> > immutable result = range.save.startsWith(needle.save);
> 
> Yep. The most frustrating thing about .save to me is that .save is
> nearly always implemented as:
> 
> auto save() { return this; }
> 
> This just screams "I really meant just copying".

Yeah, and also:

auto save() {
auto copy = this;
copy.blah = blah.dup;
return this;
}

Which just screams "I'm really just a postblit in disguise".


T

-- 
This is not a sentence.

Re: How to use globals correctly?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote:
> On Monday, 5 March 2018 at 19:51:33 UTC, Steven Schveighoffer
>
> wrote:
> > On 3/5/18 2:25 PM, Marc wrote:
> >> Can __gshared be used instead of static in the singleton
> >> pattern? I, comming from C++, ignorantly, have never used
> >> _gshared so I went to static instead of (being static also
> >> means thread-safe, as far I know)...
> >
> > static in D is thread safe, because it's thread-local.
> > __gshared is shared between threads, so it's not thread safe,
> > but has the exact same type as just static data.
> >
> > Can you use it for singleton? Sure, classic singleton is shared
> > between threads. But using thread-local data, you can solve the
> > singleton problem in a better way:
> >
> > https://wiki.dlang.org/Low-Lock_Singleton_Pattern
> >
> > Note, it still uses __gshared, which means it doesn't protect
> > you from race conditions when you actually USE the singleton
> > object. This means you need some synchronization inside the
> > methods.
> >
> > -Steve
>
> Singletons are always smelly code tbh.
>
> Especially in D with thread-local storage.
>
> I can't think of a situation where you truly need singletons in D.

I confess that I've never really understood why some folks dislike
singletons so much, but then again, I've only rarely found cases where I
thought that they made sense, and I gather that some folks out there use the
singleton pattern way too much (I've heard it suggested that it's because it
was one of the few design patterns from the design pattern book that was
easy). In fact, one of my coworkers was telling me at one point about how
someone had argued to him about how a "doubleton" pattern made sense, which
just seems crazy to me, but I've found that a disturbingly large percentage
of programmers are not what I would consider competent.

I think that the singleton pattern should be used when it really makes sense
to use it, but in most cases, there's no reason to restrict the type to a
singleton. And I expect that the dislike for singletons comes from them
being used far too often when it clearly made no sense.

The one place that I can think of that I've used singletons in the last
decade or so is with the LocalTime and UTC classes for time zones (both in
std.datetime and in the C++ version that I wrote for work at one point).
Having multiple instances of those classes made no sense and would have been
pointlessly inefficient. But at the moment, that's the only case I can think
of where I've used singletons. They just don't make sense very often.

- Jonathan M Davis

Replace import expression with intrinsic

[Kagamin via Digitalmars-d]

In case it didn't get enough visibility: 
https://issues.dlang.org/show_bug.cgi?id=1985#c11 give your 
opinion. Not sure if a better disruption management is desired 
for a possibly low profit change, e.g. it can have a long grace 
period.

Re: Speed of math function atan: comparison D and C++

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 06, 2018 at 06:05:59PM +, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
> > [snip]
> > 
> > I'm not advocating for getting *rid* of 80-bit float support, but
> > only to make it *optional* rather than the default, as currently
> > done in std.math.
[...]
> Aren't there two issues: 1) std.math functions that cast to real to
> perform calculations, 2) the compiler sometimes converts things to
> real in the background when people don't want it to.
> 
> Number 1 seems straightforward to fix. Introduce new versions of the
> std.math functions for float/double and the user can cast to real if
> the additional accuracy is necessary.

The fix itself may be straightforward, but how to do it without breaking
tons of existing code and provoking user backlash is the tricky part.


> Number 2 would require a compiler switch, I imagine.

It may not always be the compiler's fault. In the case of x87, it's the
hardware itself that internally promotes to 80-bit and truncates later.
IIRC, the original intent was that user code would only deal with
64-bit, and the 80-bit stuff would only happen inside the x87 (C, for
example, does not provide direct access to this type, except via vendor
extensions). However, due to the necessity to be able to save
intermediate computational states, there are instructions that can
load/extract 80-bit intermediate values to/from the x87, and eventually
people ended up just using these instructions for working with the
80-bit type directly.  You can suppress the compiler from issuing these
instructions, but 64-bit doubles may still be internally converted by
the hardware to 80-bit intermediate values during computation.

But I suppose you could force the compiler to use SSE instructions for
double operations instead of x87, then it would bypass the 80-bit
intermediate values completely.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater 
learning.

Re: mysql-native v2.1.0

[bauss via Digitalmars-d-announce]

On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote:
On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky 
(Abscissa) wrote:

[...]


I'm unsure how I'd go about implementing prepared statements in 
a vibe.d application correctly.


[...]


Like more specifically do I still call lockConnection() on a 
MySQLPool?

Re: How to use globals correctly?

[bauss via Digitalmars-d-learn]

On Monday, 5 March 2018 at 19:51:33 UTC, Steven Schveighoffer 
wrote:

On 3/5/18 2:25 PM, Marc wrote:


Can __gshared be used instead of static in the singleton 
pattern? I, comming from C++, ignorantly, have never used 
_gshared so I went to static instead of (being static also 
means thread-safe, as far I know)...


static in D is thread safe, because it's thread-local. 
__gshared is shared between threads, so it's not thread safe, 
but has the exact same type as just static data.


Can you use it for singleton? Sure, classic singleton is shared 
between threads. But using thread-local data, you can solve the 
singleton problem in a better way:


https://wiki.dlang.org/Low-Lock_Singleton_Pattern

Note, it still uses __gshared, which means it doesn't protect 
you from race conditions when you actually USE the singleton 
object. This means you need some synchronization inside the 
methods.


-Steve


Singletons are always smelly code tbh.

Especially in D with thread-local storage.

I can't think of a situation where you truly need singletons in D.

Re: Advent of D

[David Gileadi via Digitalmars-d]

On 3/6/18 11:09 AM, Jordi Gutiérrez Hermoso wrote:
I wrote a blog post about working on Advent of Code in D. You can read 
it here:


http://jordi.inversethought.com/blog/advent-of-d/


I really enjoyed this. Thank you!

Re: Article: Why Const Sucks

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/6/18 10:39 AM, Jonathan M Davis wrote:


Yeah. If you're dealing with generic code rather than a specific range type
that you know is implicitly saved when copied, you have to use save so often
that it's painful, and almost no one does it. e.g.

equal(lhs.save, rhs.save)

or

immutable result = range.save.startsWith(needle.save);


Yep. The most frustrating thing about .save to me is that .save is 
nearly always implemented as:


auto save() { return this; }

This just screams "I really meant just copying".

-Steve

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||spec

--

[Issue 1985] import expression should return ubyte[] not string

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #11 from anonymous4  ---
I think it's better to replace import expression with intrinsic, say,
importText (like std.file.readText). This will also reduce grammar complexity
and remove second and rarely used meaning from the import keyword. Due to how
rarely import expression is used it confuses newcomers that are used only to
it's usage as module import statement.

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #26 from Eyal  ---
What solution is there for this use-case then?

We need objects to register themselves (i.e: set out-of-scope pointers to point
at them) and RAII-wise have them de-register themselves.  While they are
registered, we need a guarantee that they won't be moved.

Doesn't sound like D has any solution for us here?

1) We can't use classes, because:
1.A) they are hard to use without GC
1.B) cannot reasonably nest classes so they re-use the same allocation as the
container class
1.C) cannot easily allocate them on the stack

2) We can't use structs, because there's no way to make sure structs aren't
moved when they're registered.

In my experience, this use-case of registered objects is extremely common.

Immovable structs, even if those require some effort, sound like they should be
well worth virtually any effort they'd require.

In practice, we use structs for this, and we don't really have a choice so
we'll keep using structs. But D is fighting us here, instead of helping us.

--

Re: Article: Why Const Sucks

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Mar 06, 2018 at 11:20:56AM -0700, Jonathan M Davis via 
Digitalmars-d-announce wrote:
> On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce 
> wrote:
> > As they say, hindsight is always 20/20.  But it wasn't so easy to
> > foresee the consequences at the time when the very concept of ranges
> > was still brand new.
> 
> Except that even worse, I'd argue that hindsight really isn't 20/20.
> We can see a lot of the mistakes that were made, and if we were
> starting from scratch or otherwise willing to break a lot of code, we
> could change stuff like the range API based on the lessons learned.
> But we'd probably still screw it up, because we wouldn't have the
> experience with the new API to know where it was wrong.
[...]

Well, that means *hind*sight is still 20/20: we see where we went wrong,
but *fore*sight is still blurry, because what we think is the solution
to that wrong may not turn out to be a good solution later. :-D


T

-- 
Question authority. Don't ask why, just do it.

Re: Article: Why Const Sucks

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce 
wrote:
> As they say, hindsight is always 20/20.  But it wasn't so easy to
> foresee the consequences at the time when the very concept of ranges was
> still brand new.

Except that even worse, I'd argue that hindsight really isn't 20/20. We can
see a lot of the mistakes that were made, and if we were starting from
scratch or otherwise willing to break a lot of code, we could change stuff
like the range API based on the lessons learned. But we'd probably still
screw it up, because we wouldn't have the experience with the new API to
know where it was wrong. Consider all of the stuff that was improved in D
over C++ but which still has problems in D (like const). We build on
experience to make the new stuff better and frequently lament that we didn't
know better in the past, but we still make mistakes when we do new stuff or
redesign old stuff. Frequently, the end result is better, but it's rarely
perfect.

- Jonathan M Davis

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Luís Marques via Digitalmars-d]

On Friday, 2 March 2018 at 00:17:13 UTC, Timothee Cour wrote:
yes, I've fixed the issue with crashes on large symbols using a 
patched `demangle` ; will update code soon; but feel free to 
take a look at lldb side of things


What version of LLVM did you base it on? On my LLVM fork for 
RISC-V and MSP430 work it doesn't build (no llvm/Support/DJB.h) 
and on the latest stable, 5.0.1, cmake fails to configure 
(Unknown CMake command "add_llvm_install_targets").

Re: Article: Why Const Sucks

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, March 06, 2018 09:36:43 H. S. Teoh via Digitalmars-d-announce 
wrote:
> Andrei has said before, and probably on more than one occasion, that if
> he were to redesign ranges today, one of the things he would do
> differently was to change the definition of forward range so that .save
> is basically implicit on copying the range object, and non-forward input
> ranges would just be reference / non-copyable types.
>
> But that boat has long sailed, and we just have to make do with what we
> have today. Changing this now will literally break just about *every* D
> program that uses ranges, which is breakage of an ecosystem-killing
> magnitude that I can't even contemplate.  I would much rather go with a
> less intrusive breakage like killing autodecoding with fire, than with
> something that will basically require me to rewrite practically every D
> program I ever wrote.

I'm not actually convinced that killing auto-decoding is really much better.
As it stands, changing it would break a large percentage of string-based
code, and the functions in question sit in std.range.primitives along with
all of the other core range stuff such that I don't see how we can change
them any more than we can change the basic range API. I would love to be
proven wrong, but I don't know how we could change it at this point without
code breakage that comes pretty close to the breakage that changing the
range API would cause.

- Jonathan M Davis

[Issue 18561] postblit should allow writing const/immutable members just like constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from anonymous4  ---
This passes:
---
struct A
{
int a;
this(int b) const { a=b; }
}
int main()
{
const A a;
assert(a.a==0,"0");
a.__ctor(1);
assert(a.a==1,"1");
return 0;
}
---

--

Advent of D

[Jordi Gutiérrez Hermoso via Digitalmars-d]

I wrote a blog post about working on Advent of Code in D. You can 
read it here:


http://jordi.inversethought.com/blog/advent-of-d/

Re: Speed of math function atan: comparison D and C++

[jmh530 via Digitalmars-d-learn]

On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:

[snip]

I'm not advocating for getting *rid* of 80-bit float support, 
but only to make it *optional* rather than the default, as 
currently done in std.math.



T


Aren't there two issues: 1) std.math functions that cast to real 
to perform calculations, 2) the compiler sometimes converts 
things to real in the background when people don't want it to.


Number 1 seems straightforward to fix. Introduce new versions of 
the std.math functions for float/double and the user can cast to 
real if the additional accuracy is necessary.


Number 2 would require a compiler switch, I imagine.

Fetch and pre-build dub dependencies

[Tamas via Digitalmars-d]

I have a Dockerfile to build a vibe.d project. Docker has a nice 
caching system so it continues building the docker image from the 
step where it's needed when something changes. This is typically 
at the step of adding my source files, then building the binary.


The problem is that fetching and building vibe dependencies takes 
a lot of time every time some source files of mine changes.


I can pre-fetch dub dependencies, although it's a bit cumbersome 
as fetch doesn't load dependencies of the given package.


RUN dub fetch vibe-d --cache=system
RUN dub fetch vibe-core --cache=system
RUN dub fetch eventcore --cache=system


But there's no easy way to build these dependencies before I add 
my project source files to the docker image. If I could do that 
the docker build process would be tremendously faster, as it 
would be simply skipped automatically by the Docker cache system. 
Currently 99% of the time spent on building the dependencies when 
i am creating a docker image. (I have to use ldc for ARM, which 
is slower.)


Is there an easy way to fetch and prebuild a dub package 
dependencies?


something like "dub fetch-and-build vibe-d --recursive 
--cache=system"

Re: What's the proper way to add a local file dependence to dub?

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-04 17:46, Marc wrote:

then copy it to sources folder?

let's say I have a small library folder at C:\mylibrary\D where I want
to use dir.d from it. How do I add that file dependence to dub? But I do
not want to that file be passed directly to dmd, I want to that file be
copied to application's source folder (so it's easy to distribuite, with
the dependences together as possible) then compiled. So, what I want to
some extension is dub work with loca files.
Is this possible to do solely with dub? I know I can easily write a
script to run before dub which copies the dependence files from
C:\mylibrary to application's source but I'm looking for a more elegant
  approach as possible; I'm afraid of rewriting a makefile-like soon (I
find cmake/make/makefiles just ugly).


You can use "preGenerateCommands" or "preBuildCommands" to run arbitrary 
commands before Dub builds the project [1]. Alternativly you can use the 
"import" expression [2], together with the "stringImportPaths" Dub build 
setting. The "import" expression will embed the file into the executable 
as a string literal.


[1] https://code.dlang.org/package-format?lang=sdl#build-settings
[2] https://dlang.org/spec/expression.html#import_expressions

--
/Jacob Carlborg

Re: Is it possible to return the subclass from a method of the parent class in dlang?

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-02 21:23, Christian Köstlin wrote:

To give an example:

class Thread {
   ...
   Thread start() {...}
}

class Timer : Thread {
   ...
}


void main() {
   // Timer timer = new Timer().start;  // this does not work
   auto timer = new Timer().start; // because timer is of type Thread
}


You can also try a template this parameter [1] in the base class:

class Thread
{
T start(this T) () { ... }
}

But if this "Thread" is core.thread.Thread that won't work.

[1] https://dlang.org/spec/template.html#template_this_parameter

--
/Jacob Carlborg

Re: Speed of math function atan: comparison D and C++

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Mar 06, 2018 at 08:12:57AM +0100, Robert M. Münch via 
Digitalmars-d-learn wrote:
> On 2018-03-05 20:11:06 +, H. S. Teoh said:
> 
> > Walter has been adamant that we should always compute std.math.*
> > functions with the `real` type, which on x86 maps to the non-IEEE
> > 80-bit floats.  However, 80-bit floats have been deprecated for a
> > while now,
> 
> Hi, do you have a reference for this? I can't believe this, as the
> 80-bit are pretty important for a lot of optimization algorithms. We
> use it all the time and it's absolutly necessary.
[...]

http://www.zdnet.com/article/nvidia-de-optimizes-physx-for-the-cpu/?tag=nl.e539

Quotation:

Intel started discouraging the use of x87 with the introduction
of the P4 in late 2000. AMD deprecated x87 since the K8 in 2003,
as x86-64 is defined with SSE2 support; VIA’s C7 has supported
SSE2 since 2005. In 64-bit versions of Windows, x87 is
deprecated for user-mode, and prohibited entirely in
kernel-mode. Pretty much everyone in the industry has
recommended SSE over x87 since 2005 and there are no reasons to
use x87, unless software has to run on an embedded Pentium or
486. 

I'm not advocating for getting *rid* of 80-bit float support, but only
to make it *optional* rather than the default, as currently done in
std.math.


T

-- 
Once bitten, twice cry...

Re: Article: Why Const Sucks

[H. S. Teoh via Digitalmars-d-announce]

On Mon, Mar 05, 2018 at 10:21:47PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d-announce wrote:
> On 03/05/2018 12:38 PM, H. S. Teoh wrote:
> > 
> > This broke the by-value assumption inherent in much of Phobos code,
> 
> Wait, seriously? Phobos frequently passes ranges by value? I sincerely
> hope that's only true for class-based ranges and forward-ranges (and
> more specifically, only forward ranges where copying the range and
> calling .save are designed to do the exact same thing). Otherwise,
> that's really, *REALLY* bad since non-forward ranges *by definition*
> cannot be duplicated.

I think you misunderstood. :-D  Passing ranges by value means passing
the range itself, usually a struct, which is a value type.  I did *not*
say the *content* of ranges are *copied* -- that would be so horribly
wrong that I would be thinking twice about using D for my projects. :-D


[...]
> The definition of "what is a forward/non-forward range" for
> struct-based ranges should have been "is this() @disabled (non-forward
> range), or is this() enabled *and* does the same thing as .save
> (forward range)?"
[...]

Yeah, Andrei has admitted before that this is probably what he would do
today, if he were given a second chance to design ranges.  But at the
time, the landscape of D was rather different, and certain language
features didn't exist yet (sorry, can't recall exactly which off the top
of my head), so he settled with the compromise that we have today.

As they say, hindsight is always 20/20.  But it wasn't so easy to
foresee the consequences at the time when the very concept of ranges was
still brand new.


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.

#dbugfix Issue 15984

[Mario Kröplin via Digitalmars-d]

[REG2.071] Interface contracts retrieve garbage instead of 
parameters

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

This regression from 2016 causes random crashes if you use one of 
the key features of D - Contract Programming.