Re: Always false float comparisons

[Ecstatic Coder via Digitalmars-d]

On Thursday, 29 June 2017 at 19:12:24 UTC, ag0aep6g wrote:

On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
I often do code like "x < array.length" where x needs to be a 
long to be able to handle negative values.


I want my code to compile without warning, and therefore I'm 
against requiring "x < array.length.to!long()" to remove that 
warning.


`x < array.length` and `x < array.length.to!long` have 
different results when x is negative. That's why a 
warning/error is in order.


I can perfectly understand that others may want to check their 
code in a "strict" mode.


So actually I'm not against a warning for signed/unsigned 
implicit conversions.


I'm just against putting it on by default, so that the current 
behavior is kept, because I don't see where is the language 
improvement in having to put these ugly manual conversion 
everywhere just because the string/array length was made unsigned.


I always use signed integers for string/array indices because 
unsigned indices become dangerous as soon as your algorithm 
starts to decrement it...


And as I said, I compile my D code with the 64-bit compiler, and 
2^63 characters/items is much more than needed for my personal 
use cases.


So until the day I will have a computer which can store a string 
of 16 million terabytes, at the moment I prefer to use long 
values for indices, instead of ulong, because negative indices 
can already occur right now with my current algorithms.

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

Jon Degenhardt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jon Degenhardt  ---
Likely an LDC issue, so closing in favor of the LDC issue:
https://github.com/ldc-developers/ldc/issues/2168. Can be re-opened if this
turns out to be incorrect.

--

Re: Always false float comparisons

[Ecstatic Coder via Digitalmars-d]

On Thursday, 29 June 2017 at 19:12:24 UTC, ag0aep6g wrote:

On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
I often do code like "x < array.length" where x needs to be a 
long to be able to handle negative values.


I want my code to compile without warning, and therefore I'm 
against requiring "x < array.length.to!long()" to remove that 
warning.


`x < array.length` and `x < array.length.to!long` have 
different results when x is negative. That's why a 
warning/error is in order.


I often have array indices that go up and down (x++/x--) 
depending on the logic.


I find convenient to be able to test them (x >= 0, x < a.length) 
without having to manage the fact that the array stores its 
length as an unsigned integer to double its potential size, since 
anyway I never use arrays with 2^63 items.

Re: Overloading funtion templates.

[vit via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 06:40:04 UTC, Balagopal Komarath 
wrote:

On Wednesday, 28 June 2017 at 12:19:31 UTC, vit wrote:

auto foo(alias F, T)(T x)
{
return x.foo();
}


With this definition foo!((x) => x+1)(3); doesn't work. Is 
there a way to solve this?


You don´t need overload templates:



import std.traits : isCallable;

auto foo(alias F, T)(T x)
if(isCallable!F)//this line is optional
{
return F(x);
}


int g(int x) { return x; }

struct G{
int i;
this(int i){
this.i = i;
}
int opCall(int x){return x*i;}  //int operator()(int x)
}

void main(){
foo!g(3);
foo!((int x) => x*2)(3);
auto g2 = G(4);
foo!g2(3);
foo!(G(5))(3);
}

Re: Win10 defender still sees dmd.exe and rdmd.exe as malicious

[Matt via Digitalmars-d]

On Wednesday, 28 June 2017 at 14:21:24 UTC, Mike Parker wrote:

On Monday, 26 June 2017 at 02:55:17 UTC, Matt wrote:
Which version of the compiler? Which version of Windows? I'm 
on Windows 10 with 2.074.1 currently and never seen it with 
any version of DMD.


DMD is 2.074.1, windows10 pro (10.0.14393)


Is it the same issue as the one reported at [1]? If so, please 
add a comment there specifying which download you used (the 
installer or the zip). If not, please file a new issue.


[1] https://issues.dlang.org/show_bug.cgi?id=16405


Yep. I used the installer from the downloads page. I'll file an 
issue

Bulk allocation and partial deallocation for tree data structures.

[Filip Bystricky via Digitalmars-d-learn]

Hello!

I'm implementing a persistent hash trie (like in clojure/scala). 
Every 'persisting' insertion involves allocating a fixed number 
(6) of nodes (each chunk is a fixed width ranging between 1 and 
~33 words).


Basically, this data structure always allocates a whole branch at 
a time, but then nodes are deallocated individually.


Is there a way to tell an allocator allocate n chunks at a time? 
Or, alternatively, is there a way to allocate all the memory 
needed at once, and then free just chunks of it at a time? It 
seems like this would provide at least some speed improvement. 
And it could also be useful for batch operations on other 
node-based data structures (such as adding ranges of nodes to a 
graph at a time).


Thanks!

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jon Degenhardt  ---
Properly adding -inline to the DMD compiler line eliminates the degradation in
the DMD builds, at least in 2.075.0-b1. (I deleted 2.074 when updating to
beta-1.)

The updated table:

|| Without   | With  |
| Compiler   | getopt import | getopt import |
|+---+---|
| DMD 2.075.0-b1 |  5.00 |  4.98 |
| LDC 1.2|  4.27 |  6.06 |
| LDC 1.3|  3.61 |  4.63 |

--

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

--- Comment #2 from Jon Degenhardt  ---
(In reply to Vladimir Panteleev from comment #1)
> Reproducible on Linux x86_64 (11.6 / 10.6 seconds with dmd)
> 
> (In reply to Jon Degenhardt from comment #0)
> > Implication so far is that
> > something is interfering with proper inlining.
> > [...]
> >   $ ldc2 -release -O3 -boundscheck=off -singleobj use_conv_to.d
> >   $ dmd -release -O -boundscheck=off use_conv_to.d
> 
> This command line does not include -inline.

Nice catch. I'll add -inline to the DMD command lines and retry. (It doesn't
apply to the LDC command line.) Thanks!

--

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
Reproducible on Linux x86_64 (11.6 / 10.6 seconds with dmd)

(In reply to Jon Degenhardt from comment #0)
> Implication so far is that
> something is interfering with proper inlining.
> [...]
>   $ ldc2 -release -O3 -boundscheck=off -singleobj use_conv_to.d
>   $ dmd -release -O -boundscheck=off use_conv_to.d

This command line does not include -inline.

--

mysql-native + vibe.d example

[crimaniak via Digitalmars-d-learn]

Hi!
Moving my project from mysql-lited to mysql-native I faced the 
problem with null pointer error inside of mysql-native:


Log:
SELECT id FROM versionupdate ORDER BY id
Task terminated with unhandled exception:
etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325)

??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*) 
[0x102ebad]

??:? void etc.linux.memoryerror.sigsegvDataHandler() [0x102eaee]
../../.dub/packages/mysql-native-1.1.0/mysql-native/source/mysql/result.d:466 
const(pure nothrow @property bool function()) mysql.result.ResultRange.isValid 
[0xdf1626]
../../.dub/packages/mysql-native-1.1.0/mysql-native/source/mysql/result.d:536 
void mysql.result.ResultRange.close() [0xdf1cb8]
../../.dub/packages/mysql-native-1.1.0/mysql-native/source/mysql/result.d:460 
void mysql.result.ResultRange.__dtor() [0xdf15cc]
../../.dub/packages/mysql-native-1.1.0/mysql-native/source/mysql/result.d:430 
ref return mysql.result.ResultRange 
mysql.result.ResultRange.opAssign(mysql.result.ResultRange) [0xdf1dba]
source/vcm/sqlWrapper.d:63 mysql.result.ResultRange 
vcm.sqlWrapper.SqlWrapper.query!().query(immutable(char)[]) 
[0xdd57e3]
source/updater/manager.d:92 void 
updater.manager.UpdateManager.update() [0xd74886]

source/app.d:81 void app.prepareDb().__lambda1() [0xcfe740]
../../.dub/packages/vibe-d-0.7.31/vibe-d/source/vibe/core/core.d:595 void 
vibe.core.core.makeTaskFuncInfo!(void delegate()).makeTaskFuncInfo(ref void 
delegate()).callDelegate(vibe.core.core.TaskFuncInfo*) [0xc5b703]
../../.dub/packages/vibe-d-0.7.31/vibe-d/source/vibe/core/core.d:1224 void 
vibe.core.core.CoreTask.run() [0xf6a916]
??:? void core.thread.Fiber.run() [0x107f17b]
??:? fiber_entryPoint [0x107eede]
??:? [0x]

Code fragment:
string s = Sql(sqlString, args).toString!MysqlDialect;
writeln(s);stdout.flush; // debugging...

if(conn.__conn() is null) // debugging...
throw new Exception("connection is null");

ResultRange result;
// synchronized (mutex)
result = conn.query(s);  // <-- sqlWrapper.d:63 is here

It seems I am doing something wrong so myself-native fails to 
detect it in isValid(). So I search for example how to use 
mysql-native in real multi-threaded vibe.d application with usage 
of MySQLPool. Please do not point me to basic example provided 
with package because it is single thread.

Thanks.

[Issue 17577] New: 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

  Issue ID: 17577
   Summary: 20%+ Performance degradation in std.conv.to due to
'import std.getopt'
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jrdemail2000-dl...@yahoo.com

Importing std.getopt causes a performance degradation in calls to std.conv.to.
This degradation occurs when simply importing std.getopt, it is not necessary
to use features from std.getopt. This has been observed DMD 2.074.0, DMD
2.075.0-beta1, LDC 1.2, and LDC 1.3-beta 1 and 2.

This was first encountered as a performance regression from LDC 1.2 to LDC 1.3
in several benchmarks used by the TSV Utilities library. The degradation in
these benchmarks is from 20-30%.

Narrowing down the case identified a much smaller example exhibiting the
problem. Simply importing std.getopt causes a performance degradation
converting char[] to double via std.conv.to. Implication so far is that
something is interfering with proper inlining.

An important behavior change for the smaller sample is that it affects LDC 1.2,
LDC 1.3, and DMD. In the TSV Utilities test, the degradation was seen in LDC
1.3, but not LDC 1.2. This could be due the larger size of the programs.

The LDC issue:  https://github.com/ldc-developers/ldc/issues/2168

A sample program illustrating the issue:

= use_conv_to.d ==
import std.conv : to;
import std.stdio;
import std.getopt;

void main()
{
string num = "0.108236736784";
size_t end = num.length;
double sum = 0.0;
foreach (i; 0 .. 100_000_000)
{
sum += num[0 .. end].to!double;
end = (end == num.length) ? 1 : end + 1;
}
writeln("sum: ", sum);
}
===

Here are timing differences with and without the 'import std.getopt;' line.
Times were on OS X (xcode 8.3.3), and are in seconds:

| Compiler   | Without getopt import | With getopt import |
|+---+|
| DMD 2.074.0| 12.30 |  13.02 |
| DMD 2.075.0-b1 | 12.72 |  13.19 |
| LDC 1.2|  4.27 |   6.06 |
| LDC 1.3|  3.61 |   4.63 |

Compilation lines:
  $ ldc2 -release -O3 -boundscheck=off -singleobj use_conv_to.d
  $ dmd -release -O -boundscheck=off use_conv_to.d

LDC 1.3 was based on commit 6c97a02, so it includes the fix for boundscheck=off
(https://github.com/ldc-developers/ldc/issues/2161)

It is not known if other facilities are affected, though if inlining is being
affected this seems likely.

I tried adding std.getopt to the compiler line as an additional file, but not
importing it. This did not produce the degradation, so it appears related to
import.

I tried importing a version of std.getopt with all the unit test blocks
removed. This still produced the degradation. Hypothesis was repeated parsing
of templates in the unittest blocks might causing an issue, but this does not
appear to be the case.

I tried importing a small file which did little besides import std.conv.to,
which std.getopt does. This did not produce the degradation.

--

[Issue 17576] mixin template cannot define alias

[via Digitalmars-d-bugs]

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

Bolpat  changed:

   What|Removed |Added

   Keywords||rejects-valid

--

[Issue 17576] New: mixin template cannot define alias

[via Digitalmars-d-bugs]

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

  Issue ID: 17576
   Summary: mixin template cannot define alias
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: qs.il.paperi...@gmail.com

mixin template Test(alias f)
{
import std.traits : ReturnType;
alias R = ReturnType!f;

R foo() { }
}

struct S
{
void foo(int) { }

mixin Test!foo T;
alias foo = T.foo;
}

gives me the error message "template instance std.traits.ReturnType!(foo) is
used as a type"

However, when R foo() { } is replaced with ReturnType!f foo() { } the error
message is "isCallable!(foo) is not an expression", and if one deletes the
alias for R, the error disappears.

Instead, if I precede the mixin template with "import std.traits : isCallable;"
and constrain it with "if (isCallable!f)", the error is "no property 'foo' for
type 'void'" essentially because it cannot instance isCallable!f for whatever
reason.

I suspect it is a bug in DMD. It could be in Phobos's ReturnType or isCallable.

--

Re: D and Meson

[Matthias Klumpp via Digitalmars-d]

On Monday, 19 June 2017 at 12:21:24 UTC, Mike B Johnson wrote:

[...]
Funny: "The main design point of Meson is that every moment a 
developer spends writing or debugging build definitions is a 
second wasted. So is every second spent waiting for the build 
system to actually start compiling code."


Which is in direct contradiction to what Walter has said... and 
yet Walter is suppose to be all about fast cars and hot women.


Walter said you should invest a lot of time waiting for the build 
process? :P


On Wednesday, 14 June 2017 at 15:25:55 UTC, Russel Winder wrote:

[...]
If the person running the D support for Meson is on this list 
please contact me privately to tell me what I can do to help 
progress that support further.


Any changes that upstream Meson is happy with are fine :-)
The best thing to help with improving Meson support one can 
possibly do at the moment would be fixing this DMDFE feature 
request: https://issues.dlang.org/show_bug.cgi?id=16746
This will also benefit a lot of other build systems that use 
incremental builds.

Re: dmd debian installation conflicts with debian-goodies

[Matthias Klumpp via Digitalmars-d]

On Wednesday, 28 June 2017 at 10:09:06 UTC, Ralph Amissah wrote:
Installing dmd if debian-goodies is installed fails. Both try 
to write a file named '/usr/bin/dman'


Debian Stretch is out, the freeze is over, perhaps now dmd will 
soon be
available as a package in Debian? Ldc2 does a great job but for 
testing
purposes and convenience it would be good to have the reference 
compiler.


Long-term, we will likely be using GDC in Debian as default D 
compiler, if that becomes viable. That GDC is in GCC now is a 
very big deal, which makes maintaining D in Debian and any Linux 
distribution (which uses GCC as system compiler) much easier.
Also, there is some company interest now, since it is expected 
that GCC/GDC will hit enterprise distributions such as RHEL as 
well, and thereby be widely available.


That being said, I want DMD to be available in Debian, and LDC is 
doing a very good job at the moment and is serving as our 
de-facto default D compiler.
Unfortunately now that the dman binary name is taken, DMD can't 
have it in Debian and that binary would have to be renamed, even 
if just temporarily in case we could convince the -goodies 
maintainer to change the name of the existing binary.


Is there likely to be D related activity at DebCamp and DebConf 
2017, Montreal?


Nothing is planned yet, but if there is interest in it, I would 
be happy to organize a BoF session there.


Cheers,
Matthias

[Issue 17574] Range violation in std.getopt:getopt AA parsing

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 17575] New: named mixin template error message

[via Digitalmars-d-bugs]

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

  Issue ID: 17575
   Summary: named mixin template error message
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: qs.il.paperi...@gmail.com

Consider

mixin template Foo() { }

void main()
{
mixin Foo F;
F.x;
}

It gives: Error: no property 'x' for type 'void'

The error message should be like: 'x' is not a member of template 'Foo!()'

--

Re: dub seems to have forgotten my versions

[jmh530 via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 21:25:18 UTC, jmh530 wrote:

On Wednesday, 28 June 2017 at 20:18:20 UTC, jmh530 wrote:

On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:

[snip]


Does not seem to be a problem for another project using dub 
with dmd and similar dependencies...


After spending some time looking through the dub issues, I 
found that you can use
the option --nodeps effectively as an offline mode. The code 
compiles with --nodeps, but still fails without it.


I discovered that this issue was that I imported one package in 
the main function and then another package had a dependency on a 
lower version of that package.

Re: Alias template parameter to a private function

[Sebastien Alaiwan via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 20:21:13 UTC, Ali Çehreli wrote:

A workaround is to use a lambda:

  filter!(a => isValid(a))(array)


Thanks! Nice trick, this is definitely going into my company's 
codebase :-)


Such limitations are pretty annoying. There were a number of 
similar issues in recent dmd releases. Please file a bug if 
it's not already there:


Thanks, will do!

[Issue 17574] New: Range violation in std.getopt:getopt AA parsing

[via Digitalmars-d-bugs]

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

  Issue ID: 17574
   Summary: Range violation in std.getopt:getopt AA parsing
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: briancsch...@gmail.com

I discovered this while trying to figure out how to include commas in argument
values:

```
import std.getopt;
import std.stdio;

void main()
{
string[string] mapping;
arraySep = ",";
string[] args = [
"testProgram",
"-m",
"a=b,c=\"d,e,f\""
];
args.getopt("m", );
writeln(mapping);
}

```

--

Re: Checked vs unchecked exceptions

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
Checked exceptions are a horrible idea because they leak 
internal implementation details as part of the signature of a 
method directly and in a transitive manner, which of course is 
one huge aberration!


What do you mean? Exceptions that leave a module clearly aren't 
internal implementation details…

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Meta via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 15:55:41 UTC, John Burton wrote:

On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to 
garbage collection and it's implications. I have a function 
that creates a std.socket.Socket using new and connects to a 
tcp server, and writes some stuff to it. I then explicitly 
close the socket, and the socket object goes out of scope.




Am I doing this right? Or is there a better way to do this in 
D?


Thanks.



For my use case here, I'm increasingly thinking that just 
calling the underlying 'C' socket and send calls is better. No 
need for anything complicated at all for my actual program :)


One final piece of advice as this thread seemed to have gone off 
the rails a bit. You can always put a `scope(exit) 
socket.close();` after you create the socket. This will ensure 
that the socket will be closed once the scope is exited no matter 
what... almost, anyway. If an Error is thrown no stack unwinding 
is done but at this point your program is in an unrecoverable 
state anyway and you have a lot more to worry about than a socket 
that hasn't been closed.

Re: Alias template parameter to a private function

[Ali Çehreli via Digitalmars-d-learn]

On 06/24/2017 02:04 AM, Sebastien Alaiwan wrote:

> private:
>
> void privateFunction1()
> {
>   auto array = [0, 1, 2, 3, 4, 5];
>   auto result = filter!isValid(array); // error: 'isValid' is private
> }

> bool isValid(int i)
> {
>   return i % 2 == 0;
> }

A workaround is to use a lambda:

  filter!(a => isValid(a))(array)

Such limitations are pretty annoying. There were a number of similar 
issues in recent dmd releases. Please file a bug if it's not already there:


  https://issues.dlang.org/

Ali

[Issue 17572] unrestricted union erroneously invokes postblit

[via Digitalmars-d-bugs]

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

--- Comment #1 from ki...@gmx.net ---
Not a bug, as the copy and postblit happens correctly when constructing the
`cast(POD!Node)val` rvalue, see
https://github.com/ldc-developers/ldc/issues/2185.

--

Re: Checked vs unchecked exceptions

[Crayo List via Digitalmars-d]

On Monday, 26 June 2017 at 15:40:19 UTC, mckoder wrote:


Here's the point: with checked exceptions good programmers can 
write good code. Without checked exceptions even good 
programmers are forced to write bad code.


This statement is logically equivalent to "good code can only be 
written with checked exceptions (presumably using Java), all 
other code is bad".


Checked exceptions are a horrible idea because they leak internal 
implementation details as part of the signature of a method 
directly and in a transitive manner, which of course is one huge 
aberration!

Re: Beta 2.075.0-b1

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

On Thu, Jun 29, 2017 at 12:27:33AM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 6/28/2017 7:02 PM, H. S. Teoh via Digitalmars-d-announce wrote:
> > I've been seeing occasional linker errors when compiling with
> > -dip1000 that go away when I drop -dip1000. However, I haven't had
> > the time to reduce the code sufficiently to file a bug.  Is this a
> > known issue, or should I schedule some time to reduce my code and
> > file a bug?
> 
> There was a known problem with that that was corrected by Rainer. I
> don't know if this means you've found another case or not.

FYI I tried compiling with -dip1000 again on git HEAD, and it seems that
the linker errors have gone away. So probably it was the same problem.
If I see it again next time, I'll try to find some time to reduce it and
file a bug.


T

-- 
In theory, software is implemented according to the design that has been 
carefully worked out beforehand. In practice, design documents are written 
after the fact to describe the sorry mess that has gone on before.

[Issue 17573] New: Make opCmp more flexible

[via Digitalmars-d-bugs]

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

  Issue ID: 17573
   Summary: Make opCmp more flexible
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hala...@gmail.com

The way custom comparisons are currently implemented force you to always return
an integer and doesn't tell you what operation you are doing.

An example of how it can bite is that mir can't do elementwise comparisons
similar to how it does addition or multiplication since it has to return an int
for comparisons.
So a + a == [2, 2, 2] and a * a == [1, 1, 1] but you can't express a < a ==
[false, false, false].


I get the logic of only making the user create a single comparison function but
maybe a possible fix would be to check if there is an opBinary for the relevant
comparison operator before doing the usual opCmp logic.

--

What are your hopes for the future D GC

[Random D user via Digitalmars-d]

I just got curious, after reading the GC analysis blog post. What 
kind of features people generally would want for the GC (in the 
distant murky future of 1999)?


Here's some of my nice to haves:

1. Thread local GCs. D is by default thread local, so it kind of 
would make sense and goodbye stop everything GC.


2. Composable custom memory block GC. The ability to mallocate 
128MB memory block and create a new GC instance to manage that 
block. It would only need to scan that 128MB block and not worry 
about rest of memory and resources (with complex destruction 
orders) in 16GB heap. This way you probably could guarantee good 
collection times for some subsystems in your program and use your 
favorite allocator for others.


3. Callbacks to GC operations. I have timeline profiler 
implemented for my project. It would be quite cool to have GC 
collection starts and stops record a timestamp for the timeline.
(Can this be done already? Hopefully without recompiling the GC. 
I tried to look but I couldn't find any hooks in the docs.)


4. Incremental GC with collection time limit. Is this even viable 
for D?

Re: Always false float comparisons

[ag0aep6g via Digitalmars-d]

On Thursday, 29 June 2017 at 18:03:39 UTC, Ecstatic Coder wrote:
I often do code like "x < array.length" where x needs to be a 
long to be able to handle negative values.


I want my code to compile without warning, and therefore I'm 
against requiring "x < array.length.to!long()" to remove that 
warning.


`x < array.length` and `x < array.length.to!long` have different 
results when x is negative. That's why a warning/error is in 
order.

Re: Always false float comparisons

[Ecstatic Coder via Digitalmars-d]

On Monday, 9 May 2016 at 11:16:53 UTC, ZombineDev wrote:

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:

Don Clugston pointed out in his DConf 2016 talk that:

float f = 1.30;
assert(f == 1.30);

will always be false since 1.30 is not representable as a 
float. However,


float f = 1.30;
assert(f == cast(float)1.30);

will be true.

So, should the compiler emit a warning for the former case?


Yes, I think it is a good idea, just like emitting a warning 
for mismatched signed/unsigned comparison.


I agree for the float but not for the long/ulong comparisons.

I often do code like "x < array.length" where x needs to be a 
long to be able to handle negative values.


I want my code to compile without warning, and therefore I'm 
against requiring "x < array.length.to!long()" to remove that 
warning.

Re: Alias template parameter to a private function

[Sebastien Alaiwan via Digitalmars-d-learn]

up please!

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 29, 2017 at 08:22:50AM +, via Digitalmars-d wrote:
> On Thursday, 29 June 2017 at 01:37:17 UTC, H. S. Teoh wrote:
[...]
> > One idea I have is that the compiler could recognize certain
> > straightforward contracts (like int < value) and use VRP (value
> > range propagation) to detect cases where it's clear that the
> > contract would be violated.
[...]
> https://github.com/dlang/dmd/pull/3799

Haha, funny, I've seen that PR before but totally forgot about it.
Seems to have reached an impasse, unfortunately.  Seems that Walter and
other are not perfectly happy with it, and handing contracts off to CTFE
raises other issues.


T

-- 
Some days you win; most days you lose.

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #3 from Vladimir Panteleev  ---
It is a limitation of the current grammar. It's probably fixable by changing
the grammar, which I think would make sense.

--

Re: CTFE Status 2

[Steven Schveighoffer via Digitalmars-d]

On 6/29/17 4:24 AM, Stefan Koch wrote:

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


I just "discovered" a bug in my debugging system.
Which caused me to debug the wrong function for about 5 hours.
Since I really could not see why the codegen would produce such vastly 
different code.

(Almost as if it were generating code for a different function :/ )

The takeaway: Better Debuggers only safe you time if they are actually 
showing you correct information.


If your debugger is buggy then your are in a world of hurts.
I had my share of pain for today.


The same is true for compilers that are buggy. Debugging code is 
horrible when the compiled code isn't doing what the source says. I've 
seen my share of that as well...


The good thing is however, that the floating point stuff is going smooth 
so far.
The x87 can be persuaded to almost obey the ieee standard if you issue a 
write after every operation.


The better option would be to just use sse2 all the way. But whatever.


I'm looking very much forward to newCTFE. Keep up the good work!

-Steve

Re: Serialization/deserialization of templated class

[Steven Schveighoffer via Digitalmars-d]

On 6/28/17 1:52 AM, Dmitry Solomennikov wrote:

On Wednesday, 28 June 2017 at 05:01:17 UTC, Eugene Wissner wrote:

On Wednesday, 28 June 2017 at 04:41:25 UTC, Dmitry Solomennikov wrote:



Probably if you have serialized data, you convert strings to other 
types, so it may be possible to perfom if-checks:

if (myDataIsStringAndDouble(data))
{
  auto var = new Some!(Pair!(string, double))(new Pair!(string, 
double)("df", 5.0));

}
else if (myDataIsStringAndInt(data))
{
  auto var = new Some!(Pair!(string, int))(new Pair!(string, 
int)("df", 5));

}


It is possible, but it is not a general solution. I've posted couple of 
sample classes, but there are more complicated cases, of course, and it 
well be combinatorial explosion here.


I got the Variant idea, I'll give it a try.
 From other point of view, is there a reflection, say

auto i = newInstance("Pair!(int, string)(10, \"asdf\")"),


No, because the class itself doesn't eixst until you instantiate it.

Certainly if you want to write out all the possible instantiations, it's 
possible, via the mechanisms already specified above. What I would do is 
create a newInstance *template* that takes a string and generates a 
function that would build it from that string. Then you can feed a 
sample file that contains all the possible instantiations to it at 
*compile time* (via import strings), and then you can automatically 
build the code that would be able to parse it. Finally, send the real 
file at runtime.



something like in Java?


It's important to realize that Java's generics are completely different 
than D's templates. They are a compile-time wrapping around a runtime 
construct. Of course, it's possible to mimic Java, but you won't get 
templates out of it, more like Variant holders.


-Steve

Re: Let's paint those bikesheds^Werror messages!

[bauss via Digitalmars-d]

On Thursday, 29 June 2017 at 14:35:00 UTC, Vladimir Panteleev 
wrote:

On Thursday, 29 June 2017 at 14:33:19 UTC, bauss wrote:
On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.


Which is?


-color=off

As with almost any other program, you can get a list of 
switches by running dmd --help. -color=[on|off] is the 7th 
switch listed.


Thanks mate

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 29 June 2017 at 14:33:19 UTC, bauss wrote:
On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.


Which is?


-color=off

As with almost any other program, you can get a list of switches 
by running dmd --help. -color=[on|off] is the 7th switch listed.

Re: Let's paint those bikesheds^Werror messages!

[bauss via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.


Which is?

[Issue 17564] std.experimental.allocator.theAllocator is null within shared static this

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/4a5d2b3b189f072e9bd0b1779a7d585e3945921b
Fix issue 17564: Eliminate "static this" for theAllocator

This switches to lazy initialization of theAllocator, so that accessing it form
within `shared static this` works as expected.

https://github.com/dlang/phobos/commit/2e0a49cd397ea1bdb993e3a9271193cf6051b8ce
Merge pull request #5519 from s-ludwig/lazy_the_allocator

Issue 17564: Eliminate "static this" for theAllocator
merged-on-behalf-of: Martin Nowak 

--

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

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

--- Comment #2 from Shachar Shemesh  ---
(In reply to Vladimir Panteleev from comment #1)
> It is a syntax issue. See:
> https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-
> nothing/

I'm sorry, I don't understand. Are you saying that because it is a syntax issue
it is not a bug?

Shachar

--

[Issue 17572] New: unrestricted union erroneously invokes postblit

[via Digitalmars-d-bugs]

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

  Issue ID: 17572
   Summary: unrestricted union erroneously invokes postblit
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: wyr...@gmx.net

Expected Behavior:
prints 0
Observed Behavior:
prints 1

import std.stdio;

long post = 0;

struct Node
{
  uint val;

  this(this) { ++post; }
}

union POD(T)
{
  T val;
}

POD!Node g;

void Put(ref Node val)
{
  g = cast(POD!Node)val;
}

void main()
{
  auto x = Node(5);
  x.Put();
  post.writeln;
}

--

Re: How to partially apply member functions?

[ct via Digitalmars-d-learn]

I was only able to do it this way:

auto on_next_previous = 
entry_.addOnNextMatch(!(on_next_previous, true));
entry_.addOnPreviousMatch(!(on_next_previous, false));

Re: Force usage of double (instead of higher precision)

[Stefan Koch via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 12:02:48 UTC, Simon Bürger wrote:

On Thursday, 29 June 2017 at 00:07:35 UTC, kinke wrote:

On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:

I am currently using LDC on 64-bit-Linux if that is relevant.


It is, as LDC on Windows/MSVC would use 64-bit compile-time 
reals. ;)


Changing it to double on other platforms is trivial if you 
compile LDC yourself. You'll want to use this alias: 
https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19


Huh, I will definitely look into this. This might be the most 
elegant solution. Thanks for the suggestion.


Required a custom build of the compiler for the library to work 
is rather inelegant imo.

However It might allow you to make progress the quickest.
Note that this only changes the type all ct-float-math is done at 
to double.

which means that know float and real will be double.
(Which is probably better then having float and double transform 
into 80bit reals)

[Issue 17571] Cannot create alias of __traits(getMember, ...)

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
Summary|Cannot create alias of  |Cannot create alias of
   |__traits(getMember  |__traits(getMember, ...)
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
It is a syntax issue. See:
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

--

[Issue 17570] Misleading error message illegal conditional function definition

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P1  |P3
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: How to partially apply member functions?

[ct via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 12:31:58 UTC, ct wrote:

I have something similar to the following:

class Editor {
  void OnNextPreviousMatch(bool is_forward, SearchEntry entry) {
}
}


I pressed send by mistake. Again, I have something similar to the 
following:


class Editor {
  void OnNextPreviousMatch(bool is_forward, SearchEntry entry) {
// ...
  }
}

In another member function, I want to partially apply a delegate:

class Editor {
  void OnNextPreviousMatch(bool is_forward, SearchEntry entry) {
// ...
  }

  void InstallHandlers() {
entry_.addOnNextMatch(partial!(, 
true));
entry_.addOnPreviousMatch(partial!(, 
false));

  }
}

I tried several things, but I keep getting compiler errors:

Error: value of 'this' is not known at compile time
/usr/include/dmd/phobos/std/functional.d(664,23): Error: need 
'this' for 'OnNextPreviousMatch' of type 'void(bool is_forward, 
SearchEntry entry)'

How to partially apply member functions?

[ct via Digitalmars-d-learn]

I have something similar to the following:

class Editor {
  void OnNextPreviousMatch(bool is_forward, SearchEntry entry) {
}
}

Re: Force usage of double (instead of higher precision)

[Simon Bürger via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 00:07:35 UTC, kinke wrote:

On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:

I am currently using LDC on 64-bit-Linux if that is relevant.


It is, as LDC on Windows/MSVC would use 64-bit compile-time 
reals. ;)


Changing it to double on other platforms is trivial if you 
compile LDC yourself. You'll want to use this alias: 
https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19


Huh, I will definitely look into this. This might be the most 
elegant solution. Thanks for the suggestion.

Re: Force usage of double (instead of higher precision)

[Simon Bürger via Digitalmars-d-learn]

Thanks a lot for your comments.

On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:

[...]

Nice work can you re or dual license under the boost license ?
I'd like to incorporate the qd type into newCTFE.


The original work is not mine but traces back to 
http://crd-legacy.lbl.gov/~dhbailey/mpdist/ which is under a 
(modified) BSD license. I just posted the link for context, sorry 
for the confusion. Doing a port to D does not allow me to change 
the license even though I not a single line from the original 
would remain (I think?).


I might do a completely new D implementation (still based on the 
original authors research paper, not on the details of their 
code). But
1. I probably would only do a subset of functions I need for my 
work (i.e. double-double only, no quad-double, and only a limited 
set of trancendental functions).
2. Given that I have seen the original code, this might still be 
considered a "derivative work". I'm not sure, copyright-law is 
kinda confusing to me in these cases.


Indeed you'll have no way to get rid of the excess precision 
except for creating a function per sub-expression.


No, doesn't seem to work. Here is a minimal breaking example:

double sum(double x, double y) { return x + y; }
bool equals(double x, double y) { return x == y; }

enum pi = ddouble(3.141592653589793116e+00, 
1.224646799147353207e-16);


struct ddouble
{
double hi, lo;

invariant
{
if(!isNaN(hi) && !isNaN(lo))
assert(equals(sum(hi, lo),  hi));
}

this(double hi, double lo)
{
this.hi = hi;
this.lo = lo;
}
}

But there are workarounds that seem to work:
1. remove the constructor (I think this means the invariant is 
not checked anymore?)

2. disable the invariant in ctfe (using "if(__ctfe) return;")
3. Don't use any ctfe (by replacing enum with immutable globals, 
initialized in "static this").



I was using the newCTFE fork which fixes this.


Does this mean your new CTFE code (which is quite impressive work 
as far as I can tell), floating point no longer gets promoted to 
higher precision? That would be really good news for hackish 
floating-point code.


Honestly, this whole "compiler gets to decide which type to 
actually use" thing really bugs me. Kinda reminiscent of C/C++ 
integer types which could in principle be anything at all. I 
thought D had fixed this by specifying "int = 32-bit, long = 
64-bit, float = IEEE-single-precision, double = 
IEEE-double-precision". Apparently not.


If I write "double", I would like to get IEEE-conform 
double-precision operations. If I wanted something depending on 
target-platform and compiler-optimization-level I would have used 
"real". Also this 80-bit-extended type is just a bad idea in 
general and should never be used (IMHO). Even on x86 processors, 
it only exists for backward-compatibility. No current instruction 
set (like SEE/AVX) supports it. Sorry for the long rant. But I am 
puzzled that the spec (https://dlang.org/spec/float.html) 
actually encourages double<->real convertions while at the same 
time it (rightfully) disallows "unsafe math optimizations" such 
as "x-x=0".

Re: Let's paint those bikesheds^Werror messages!

[Danni Coy via Digitalmars-d]

This times 1000

On Wed, Jun 28, 2017 at 3:11 AM, H. S. Teoh via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Tue, Jun 27, 2017 at 02:32:28PM +, Vladimir Panteleev via
> Digitalmars-d wrote:
> > As has been announced, DMD now has colorized syntax highlighting in
> > error messages:
> >
> > http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com
> >
> > With 2.075's release near, now would be a good time to decide on a
> > nice color palette that looks fine on most terminals. So, please vote:
> >
> > https://github.com/dlang/dmd/pull/6943
> >
> > Obligatory:
> > - Yes, not everyone likes colors. You can turn all colors off with a
> > command-line switch.
> > - Yes, everyone agrees that having all colors be configurable would be
> > good.  We still need defaults that are going to look OK on most
> > terminals.
> > - Yes, no matter what colors we choose, they're going to look bad on
> > some terminal somewhere. Let's worry about the major platforms' most
> > common terminals for now.
>
> The cardinal rule of color selection: NEVER only set the foreground
> color or the background color alone. ALWAYS set both, otherwise you will
> get invisible text (or barely-visible text, like yellow on white) on
> somebody's terminal, and they will be very, very angry.
>
>
> T
>
> --
> Marketing: the art of convincing people to pay for what they didn't need
> before which you fail to deliver after.
>

Re: Can't get UDAs of constants (enums) !

[Walter Bright via Digitalmars-d]

On 6/24/2017 10:42 AM, Johan Engelen wrote:

[1]  https://issues.dlang.org/show_bug.cgi?id=17545


https://github.com/dlang/dmd/pull/6949

[Issue 17545] [REG2.072] __traits(getAttributes, name) evaluates name to value prematurely

[via Digitalmars-d-bugs]

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

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

--

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


I just "discovered" a bug in my debugging system.
Which caused me to debug the wrong function for about 5 hours.
Since I really could not see why the codegen would produce such 
vastly different code.
(Almost as if it were generating code for a different function :/ 
)


The takeaway: Better Debuggers only safe you time if they are 
actually showing you correct information.


If your debugger is buggy then your are in a world of hurts.
I had my share of pain for today.

The good thing is however, that the floating point stuff is going 
smooth so far.
The x87 can be persuaded to almost obey the ieee standard if you 
issue a write after every operation.


The better option would be to just use sse2 all the way. But 
whatever.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[via Digitalmars-d]

On Thursday, 29 June 2017 at 01:37:17 UTC, H. S. Teoh wrote:
On Thu, Jun 29, 2017 at 01:22:31AM +, Mark via 
Digitalmars-d wrote: [...]
So basically, I'd like the ability to implement fairly simple 
contracts (with a similar level of sophistication to the above 
examples) that the compiler can check for me. I don't know, 
maybe this is easier to implement using UDAs...


One idea I have is that the compiler could recognize certain 
straightforward contracts (like int < value) and use VRP (value 
range propagation) to detect cases where it's clear that the 
contract would be violated.


However, this can only be done in a very rudimentary fashion, 
because:


(1) DbC contracts pertain to *runtime* argument values, so while
checking for simple cases at compile-time is nice, it isn't 
really in

the charter of (D's implementation of) DbC.

(2) VRP in the compiler currently only works within a very 
limited
scope, IIRC within a single expression. So while it may detect 
the
`foo(bar())` case, it probably won't detect the `x=bar(); 
foo(x);` case.

Ostensibly the scope of VRP ought to be expanded, however:

(3) In the past Walter has shown some reluctance in adding 
features that hurt compilation time; if a more sophisticated 
implementation of VRP is required and it's deemed too expensive 
in terms of compilation time, Walter may veto it.


(4) Arbitrarily complex boolean conditions are undecidable in 
general, so unless you have a way to solve the halting problem, 
a general solution is intractible.  Of course, the kind of 
conditions you find in contracts generally ought to be nowhere 
near the halting problem in complexity, but it's not clear how 
far one can go without running the risk of (3).  My guess is 
that something based on VRP is the most likely to materialize 
in the foreseeable future.



T


https://github.com/dlang/dmd/pull/3799

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 29 June 2017 at 01:45:11 UTC, Nick Sabalausky 
(Abscissa) wrote:
Hasn't DMD already been coloring error messages for about the 
past year? Or is it DUB that's been doing that to DMD's output? 
Or are we talking about something different then what was 
already there?


Please, click, the, link. Screenshots and details inside.

https://github.com/dlang/dmd/pull/6943

[Issue 17545] [REG2.072] __traits(getAttributes, name) evaluates name to value prematurely

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
(In reply to Vladimir Panteleev from comment #3)
> Introduced in https://github.com/dlang/dmd/pull/5588

Timon Gehr notes that it was this diff that caused the issue:

https://github.com/dlang/dmd/compare/master...tgehr:fix17545

--

Re: Beta 2.075.0-b1

[Walter Bright via Digitalmars-d-announce]

On 6/28/2017 7:09 PM, Dsby wrote:

On Thursday, 29 June 2017 at 01:44:10 UTC, Walter Bright wrote:

On 6/27/2017 12:51 AM, Dsby wrote:

what about DIP1000? Is it default?


No.


When will it be default? 2.076 or 2.077?


I don't know at the moment. Currently, Phobos doesn't compile with it on because 
Phobos has some safety violations in it that need correction.


I expect a lot of existing code will have similar issues, and so we'll need a 
long period before making it the default.

Re: Beta 2.075.0-b1

[Walter Bright via Digitalmars-d-announce]

On 6/28/2017 7:02 PM, H. S. Teoh via Digitalmars-d-announce wrote:

I've been seeing occasional linker errors when compiling with -dip1000
that go away when I drop -dip1000. However, I haven't had the time to
reduce the code sufficiently to file a bug.  Is this a known issue, or
should I schedule some time to reduce my code and file a bug?


There was a known problem with that that was corrected by Rainer. I don't know 
if this means you've found another case or not.