Re: A simplification of the RvalueRef idiom

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 22:03:14 UTC, Satoshi wrote:

or I have simple class

class View {
this(Rectangle frame) {...}
this(float, float, float, float) { ... }
this(Point, Size) { ... }
}

then struct Point, Size and Rectangle (Point, Size)

now I need to write 2 overloads for View class taking 4 floats 
or (Point, Size) and this must do in every descendant of View 
class.


This can be solved with string-mixins.

Re: {DMD-AST-Tool} For beginning DDMD hackers

[Stefan Koch via Digitalmars-d]

On Wednesday, 23 November 2016 at 07:11:56 UTC, ANtlord wrote:
On Saturday, 12 November 2016 at 10:26:53 UTC, Stefan Koch 
wrote:

Hi Guys,

I have written a small utility called dmd-ast-tool.
It can be used to quickly generate boilerplate code for 
dmd-ast-visitors.
Originally it was only written for my personal use, it used to 
work with a handwritten text-file representing dmds ast class 
hierarchy.


However I recently updated it construct the class hierarchy 
from ddmds source code.


It is pretty bare-boned, but maybe it can be useful to some of 
you :)


https://github.com/UplinkCoder/dmd-ast-tool.


Hello! Can you clarify? Does this program use ddmd or ddmd is 
just used as code sample for parsing?


It is a special purpose tool to get the AST-class-hierarchy of 
ddmd.
I would not even use the word parser, since it just matches a 
simple regex on ddmds source code.
It then does a correlation pass to determine parent-child 
relationships between the classes.
The resulting data-structure can then be used to display said 
hierarchy.

Re: Detect that a child is waiting for input

[Shachar Shemesh via Digitalmars-d]

On 20/11/16 14:21, unDEFER wrote:

Hello!
I'm using pipeProcess() to create a process:

pipes = pipeProcess(["bash", "-c", BASH_COMMAND], Redirect.stdin |
Redirect.stdout | Redirect.stderr);

Is it possible detect that the child is waiting for input on stdin?
I can't find decision even for C. I think it is impossible if the child
uses unblocking reading. But I want to detect blocking reading.


The shell does that for background processes. I think it takes away the 
TTY from its children, and this way, when they try to read from stdin, 
they get SIGSTOP from the system.


I'm not sure what the precise mechanism is.

There are flags passed to wait which will cause it to report when a 
child gets SIGSTOP.


Hope this helps,
Shachar

Re: {DMD-AST-Tool} For beginning DDMD hackers

[ANtlord via Digitalmars-d]

On Saturday, 12 November 2016 at 10:26:53 UTC, Stefan Koch wrote:

Hi Guys,

I have written a small utility called dmd-ast-tool.
It can be used to quickly generate boilerplate code for 
dmd-ast-visitors.
Originally it was only written for my personal use, it used to 
work with a handwritten text-file representing dmds ast class 
hierarchy.


However I recently updated it construct the class hierarchy 
from ddmds source code.


It is pretty bare-boned, but maybe it can be useful to some of 
you :)


https://github.com/UplinkCoder/dmd-ast-tool.


Hello! Can you clarify? Does this program use ddmd or ddmd is 
just used as code sample for parsing?

Re: A simplification of the RvalueRef idiom

[Era Scarecrow via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 16:05:35 UTC, Satoshi wrote:
Sorry, but D seems to be worse and worse day by day. This 
should be resolved by language and not doing it by template 
function.

Same thing should be applied for maybe monad and tuples.


 I'm reminded of trying to follow the rules and do both L 
types, and I came across unwanted behavior since the qualifiers 
would make something the wrong type because constness was closer 
matching, among other weird behavior.


 I'll hope more of this gets resolved, and then I can look at the 
language seriously and really do something with it.

Re: Mir Random [WIP]

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei 
Alexandrescu wrote:

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
 - `opCall` API instead of range interface is used (similar 
to C++)


This seems like a gratuitous departure from common D practice. 
Random number generators are most naturally modeled in D as 
infinite ranges. -- Andrei


It is safe low level architecture without performance and API 
issues. It prevents users to do stupid things implicitly (like 
copying RNGs). A hight level range interface can be added in 
the future (it will hold a _pointer_ to an RNG). In additional, 
when you need to write algorithms or distributions opCall is 
much more convenient than range API. In additions, users would 
not use Engine API in 99% cases: they will just want to call 
`rand` or `uniform`, or other distribution.


I am sure that almost any library should have low level API 
that is fits to its implementation first. Addition API levels 
also may be added. Current Phobos evolution is generic 
degradation: more generic and "universal" code hide more 
uncovered bugs in the code. The std.range is good example of 
degradation, it has a lot of API and implementation  bugs.




EDIT: std.range -> std.random

Re: Mir Random [WIP]

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu 
wrote:

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
 - `opCall` API instead of range interface is used (similar to 
C++)


This seems like a gratuitous departure from common D practice. 
Random number generators are most naturally modeled in D as 
infinite ranges. -- Andrei


It is safe low level architecture without performance and API 
issues. It prevents users to do stupid things implicitly (like 
copying RNGs). A hight level range interface can be added in the 
future (it will hold a _pointer_ to an RNG). In additional, when 
you need to write algorithms or distributions opCall is much more 
convenient than range API. In additions, users would not use 
Engine API in 99% cases: they will just want to call `rand` or 
`uniform`, or other distribution.


I am sure that almost any library should have low level API that 
is fits to its implementation first. Addition API levels also may 
be added. Current Phobos evolution is generic degradation: more 
generic and "universal" code hide more uncovered bugs in the 
code. The std.range is good example of degradation, it has a lot 
of API and implementation  bugs.


### Example of API+implementation bug:

 Bug: RNGs has min and max params (hello C++). But, they are 
not used when an uniform integer number is generated : 
`uniform!ulong` / `uniform!ulong(0, 100)`.


 Solution: In Mir Rundom any RNGs must generate all 
8/16/32/64 bits uniformly. It is RNG problem how to do it.


I will not fill this bug as well another dozen std.random bugs 
because the module should be rewritten anyway and I am working on 
it. std.random is a collection of bugs from C/C++ libraries 
extended with D generic idioms. For example, there is no reason 
in 64 bit Xorshift. It is 32 bit by design. Furthermore, 64 
expansion of 32 bit algorithms must be proved theoretically 
before we allow it for end users. 64 bit analogs are exists, but 
they have another implementations. Phobos degrades because we add 
a lot of generic specializations and small utilities without 
understanding use cases. Phobos really follows stupid idealistic 
idea: more generic is better, more API is better, more universal 
algorithms is better. The problems is that Phobos/DRuntime is 
soup where all (because its "universality") interacts with 
everything.

Re: How do we accelerate the development of precise GC, RC and so on?

[Adam Wilson via Digitalmars-d]

Dsby wrote:

On Tuesday, 22 November 2016 at 11:20:10 UTC, Jack Applegame wrote:

We look forward to sane GC over the years. How do we accelerate the
development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter or somewhere else?
I'm not ready to write precise GC, but I'm willing to donate to those
who are ready.


I want to know too.


Over the summer there was a GSoC project to implement a Precise GC in D. 
The bulk of the work was completed but we got bogged down by the need to 
test and fix it's performance characteristics over multiple CPU types.


If you want to help you can look at this github branch and test it on 
your box and let us know what your results are: 
https://github.com/dlang/druntime/pull/1603


You can also submit any fixes you come up with. That would be very helpful!

--
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

Re: Mir Random [WIP]

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 23 November 2016 at 00:44:26 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko 
wrote:

 - 64-bit Mt19937 is default for 64-bit targets


This means that seemingly identical code will produce different 
results depending on whether it's compiled for 64-bit or 
32-bit.  Is that really worth it, when anyone who cares about 
the difference between 32-bit vs. 64-bit random words is quite 
capable of specifying the RNG they want to use and not just 
relying on the default?


Having a different default RNG would make sense for targets 
where there are serious performance issues at stake (e.g. 
minimal memory available for RNG state) but just for the sake 
of 32- vs. 64-bit Mersenne Twister seems an unnecessary 
complication.


These days it's debatable whether Mersenne Twister of _any_ 
word size is the optimal choice for a default RNG, so if the 
default is going to be changed, it might as well be to 
something significantly better (rather than worrying about 
numbers of bits).


Mir Random is going to be a library with saturated uniform FP 
RNGs and almost saturated exponential FP RNGs. Comparing with all 
other libraries (any language) the basic uniform FP numbers will 
be generated in interval (-1, +1) and contains _all_ possible 
values including all subnormal numbers. 64 bit generators are 2 
times faster for this task if you need to generate a 64 bit 
floating point number. Explanation of technique will be in my 
post/article. --Ilya

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 23 November 2016 at 01:18:09 UTC, Walter Bright 
wrote:

On 11/22/2016 8:07 AM, Steven Schveighoffer wrote:

On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:

2. Why bsf and bsr do NOT use hardware instructions anymore?
They should unless there is no hardware instruction available. 
I believe the
software implementation is only a fallback when this is the 
case.


That's correct.


Thank you for the confirmation!

Re: D developer jobs

[Adam Wilson via Digitalmars-d]

eugene wrote:

hello everyone,
could you, please, tell do any jobs(full-time or freelance) exist for
junior D developers?


This page might be off assistance. These are all the known corps using 
D. Some have hiring links. https://dlang.org/orgs-using-d.html


--
Adam Wilson
IRC: LightBender
//quiet.dlang.dev

Re: How do we accelerate the development of precise GC, RC and so on?

[Dsby via Digitalmars-d]

On Tuesday, 22 November 2016 at 11:20:10 UTC, Jack Applegame 
wrote:
We look forward to sane GC over the years. How do we accelerate 
the development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter or 
somewhere else?
I'm not ready to write precise GC, but I'm willing to donate to 
those who are ready.


I want to know too.

Re: What is going on with the ubuntu/debian debacle ?

[deadalnix via Digitalmars-d]

On Tuesday, 22 November 2016 at 21:19:13 UTC, H. S. Teoh wrote:
On Sat, Nov 19, 2016 at 11:03:05PM +, deadalnix via 
Digitalmars-d wrote:
A lot of users are reporting errors on debian and ubuntu. .o 
generated by dmd do not link and libphobos.a is unusable.


This is very bad and we should consider a hotfix. Is someone 
on it ?


FWIW, I'm using Debian/unstable and compiling 
dmd/druntime/phobos directly from git HEAD, and it seems to 
work fine.


Does this problem only happen for the shipped .deb packages?


T


It happens with anything compiled without fPIC as far as I can 
tell. unless the relocation emission bug has been fixed in 
master, then that should happen as well.

[Issue 16724] New: RandomCover.popFront is a no-op for the first call

[via Digitalmars-d-bugs]

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

  Issue ID: 16724
   Summary: RandomCover.popFront is a no-op for the first call
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dl...@supradigital.org

I let the code speak for itself.


import std.random;
import std.range;
import std.algorithm;

void main ()
{
auto range = iota(10);

auto randy = range.randomCover;

//randy.front // uncomment this and the assert works

randy.popFront;

assert(randy.array.length == range.length - 1);
}

--

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

[Andrei Alexandrescu via Digitalmars-d-announce]

On 11/19/16 4:17 PM, Andy Smith wrote:


Until branding for the 2017 conf is sorted out/agreed would it be a big
deal to 'steal' the cool purple D rocket branding from the 2016 site?
(Changing the 6 to a 7 obviously). If you switch between the two pages (
2016 vs 2017 ). 2017 currently looks distinctly spartan :-(

http://dconf.org/2017

http://dconf.org/2016

Cheers,

A.


That would be great. Do you have time to volunteer a couple of PRs? -- 
Andrei

Re: Mir Random [WIP]

[ketmar via Digitalmars-d]

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

On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:
These days it's debatable whether Mersenne Twister of _any_ 
word size is

the optimal choice for a default RNG


Interesting. Could you please add a couple of links about that? 
-- Andrei


http://www.pcg-random.org/other-rngs.html

;-)

Re: Mir Random [WIP]

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/16 7:30 PM, John Colvin wrote:

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:

 - `opCall` API instead of range interface is used (similar to C++)


This seems like a gratuitous departure from common D practice. Random
number generators are most naturally modeled in D as infinite ranges.
-- Andrei


I'm pretty sure everyone *wants* it to be a range, but it turns out it's
a difficult design space. Lot's of nasty trade-offs that can be (and
have been) argued back and forth depending on your priorities.


The proposed design has disabled copy ctor and uses opCall() for a new 
element. That seems to be a difference without a distinction from an 
input range that has disabled copy ctor and offers the input range 
primitives.



Perhaps you have an insight that has been missed that can make a good
rng range without causing less than optimal performance or statistically
unsafe default behaviour?


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



IIRC you think people are making too much fuss about the statistically
safe default behaviour, but it would be interesting to hear a more
expanded version of that view.


I'm unclear on what that statistically unsafe default behavior is - my 
understanding is it has to do with RNGs being inadvertently copied. It 
would be great to formalize that in a well-explained issue.



Andrei

Re: Mir Random [WIP]

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/16 7:36 PM, Joseph Rushton Wakeling wrote:


  * random _generators_, i.e. sources of uniformly distributed random bits:

- random _engines_ (seedable, pseudo-random algorithms)

- random _devices_ (non-deterministic sources of uniformly
distributed bits)

  * random _distributions_, which transform uniformly-distributed random
bits
into variates with some other type and distribution

- note _this includes uniformly-distributed integers_!

- also uniformly-distributed floats, enums, etc.

- and also non-uniform distributions

  * random _algorithms_, i.e. algorithms in the sense of std.random, but
where
their popFront() includes random decision-making

- randomCover, randomSample, etc.


Yah, I think that would be nice. -- Andrei

Re: Mir Random [WIP]

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:

These days it's debatable whether Mersenne Twister of _any_ word size is
the optimal choice for a default RNG


Interesting. Could you please add a couple of links about that? -- Andrei

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 8:07 AM, Steven Schveighoffer wrote:

On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:

2. Why bsf and bsr do NOT use hardware instructions anymore?

They should unless there is no hardware instruction available. I believe the
software implementation is only a fallback when this is the case.


That's correct.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 9:05 AM, Ilya Yaroshenko wrote:

In addition, i need to be sure that an intrinsics function is always inlined
(without -inline flag too).


If it is a supported intrinsic, it is always inlined. There'd be no purpose to 
it otherwise :-)

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 3:07 PM, Johan Engelen wrote:

On Tuesday, 22 November 2016 at 22:57:22 UTC, Iain Buclaw wrote:

It's a compilers job is to detect code patterns and emit suitable instructions
for them. :-)


None of the compilers detect the body code pattern.


That is correct as far as bsf/bsr are concerned. The trouble with detecting a 
coding pattern is there are an endless number of ways such can be coded, and the 
compiler cannot detect all of them. Worse, the only way you can tell if the 
compiler did detect it is to look at the assembler output.


Nevertheless, the compiler still does detect some patterns, like for rol() and 
ror(), and uses a built-in operator for them. So that people use the detectable 
patterns, use the rol() template in core.bitop. The reason the compiler attempts 
to detect them anyway is there's a ton of code out there that has specific code 
written for rol/ror, and it's unlikely that people will ever rewrite it to use 
the templates.


You'll find that C/C++ compilers behave similarly. Burt Regehr did a blog entry 
on that a while back.


The compiler will also detect common forms of little/big endian byte 
manipulation, again see Regehr. This is pretty much standard behavior for modern 
compilers.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[rikki cattermole via Digitalmars-d]

On 23/11/2016 1:46 PM, Walter Bright wrote:

On 11/22/2016 5:31 AM, Ilya Yaroshenko wrote:

Please add a module (core.intrinsics ?) which will contain all DMD
intrinsics
similar to ldc.intrinsics. After each DMD release it is not clear what is
intrinsics and what is not. I need BSF intrinsics for Better C library
Mir
Random [1], which should work without linking with DRuntime and
Phobos. I can
use ldc.intrinsics for LDC, but have no idea about DMD. I want BSR and
BSF
instructions to be generated instead of current _software_
implementation in
core.bitop.

==
Philosophical Questions:

1. Why hight level stuff like BitRange is in core.bitop, but not in
std.bitmanip? If it should be in core, why it is public?

2. Why bsf and bsr do NOT use hardware instructions anymore?
==

Please ping me for Phobos and DRuntime PRs if they are related to math
and
numeric issues.



The definitive list of dmd intrinsics is here:

  https://github.com/dlang/dmd/blob/master/src/toir.d#L349

It is definitive in the sense that it is what dmd actually does, rather
than what any documentation says it does :-)

There reason there isn't a specific core.intrinsics module is that
essentially any function in the library could be made an intrinsic by an
implementation, and it is up to the implementation to make such choices.
Therefore, making a function an intrinsic should not necessitate moving
its location.

The bodies of 'intrinsic' functions exist to:

1. provide a reference implementation that documents what it does

2. provide a fallback if some implementation decides to not make it an
intrinsic. Such decisions are left up to the implementation.

3. the bodies are needed if the address of an intrinsic function is taken.

If an implementation does decide to make a certain function an
intrinsic, the function is not referenced from the object file and the
library does not need to be linked to.

bsr and bsf are dmd intrinsics. It's easy enough to verify by running
obj2asm on a dmd generated object file, and then grepping it for bsr/bsf
instruction mnemonics.


Most of those intrinsics are in std.math.
These things are why I failed to split std.math up.

Pretty please can we get them moved out?

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 10:57 AM, tsbockman wrote:

Your test fails because you aren't actually using `core.bitop`. Intrinsics are
detected based on fully qualified names. As soon as you copy `bsf()` and `bsr()`
outside of `core.bitop`, the FQN changes and they're not intrinsics anymore.



That is correct. From toir.d, this is what is detected:

  "_D4core5bitop3bsfFNaNbNiNfkZi"

i.e. the fully mangled name.

Detecting any function called "bsf" would be problematic because it would 
essentially add an arbitrary number of reserved words to the core language.


An alternative would be to name them with a prefix like:

  __intrinsic_bsf

but I see little advantage to that over core.bitop.bsf

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 9:07 AM, Ilya Yaroshenko wrote:

No, LDC and GDC cannot detect it. Proof - https://godbolt.org/g/bsAFU8 . Current
LDC DRuntime uses intrinsics instead of software implementation.


Consider the code:

  import core.bitop;

  int foo(int v) {
return core.bitop.bsf(v);
  }

Compiling:

  dmd foo.d -c
  obj2asm foo.obj

yields:

  _D5bug113fooFiZicomdat
bsf EAX,AL
ret

Meaning the bsf() intrinsic is properly detected and used.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Walter Bright via Digitalmars-d]

On 11/22/2016 5:31 AM, Ilya Yaroshenko wrote:

Please add a module (core.intrinsics ?) which will contain all DMD intrinsics
similar to ldc.intrinsics. After each DMD release it is not clear what is
intrinsics and what is not. I need BSF intrinsics for Better C library Mir
Random [1], which should work without linking with DRuntime and Phobos. I can
use ldc.intrinsics for LDC, but have no idea about DMD. I want BSR and BSF
instructions to be generated instead of current _software_ implementation in
core.bitop.

==
Philosophical Questions:

1. Why hight level stuff like BitRange is in core.bitop, but not in
std.bitmanip? If it should be in core, why it is public?

2. Why bsf and bsr do NOT use hardware instructions anymore?
==

Please ping me for Phobos and DRuntime PRs if they are related to math and
numeric issues.



The definitive list of dmd intrinsics is here:

  https://github.com/dlang/dmd/blob/master/src/toir.d#L349

It is definitive in the sense that it is what dmd actually does, rather than 
what any documentation says it does :-)


There reason there isn't a specific core.intrinsics module is that essentially 
any function in the library could be made an intrinsic by an implementation, and 
it is up to the implementation to make such choices. Therefore, making a 
function an intrinsic should not necessitate moving its location.


The bodies of 'intrinsic' functions exist to:

1. provide a reference implementation that documents what it does

2. provide a fallback if some implementation decides to not make it an 
intrinsic. Such decisions are left up to the implementation.


3. the bodies are needed if the address of an intrinsic function is taken.

If an implementation does decide to make a certain function an intrinsic, the 
function is not referenced from the object file and the library does not need to 
be linked to.


bsr and bsf are dmd intrinsics. It's easy enough to verify by running obj2asm on 
a dmd generated object file, and then grepping it for bsr/bsf instruction mnemonics.

Re: Mir Random [WIP]

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko 
wrote:

 - 64-bit Mt19937 is default for 64-bit targets


This means that seemingly identical code will produce different 
results depending on whether it's compiled for 64-bit or 32-bit.  
Is that really worth it, when anyone who cares about the 
difference between 32-bit vs. 64-bit random words is quite 
capable of specifying the RNG they want to use and not just 
relying on the default?


Having a different default RNG would make sense for targets where 
there are serious performance issues at stake (e.g. minimal 
memory available for RNG state) but just for the sake of 32- vs. 
64-bit Mersenne Twister seems an unnecessary complication.


These days it's debatable whether Mersenne Twister of _any_ word 
size is the optimal choice for a default RNG, so if the default 
is going to be changed, it might as well be to something 
significantly better (rather than worrying about numbers of bits).

Re: Mir Random [WIP]

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko 
wrote:

# Integer uniform generators
[WIP]

# Real uniform generators
[WIP]

# Nonuniform generators
[WIP]


As we discussed in relation to Seb's project, I think this is a 
problematic conceptualization of the best way to structure 
functionality related to randomness.


An arguably better way (as outlined in the C++11 standard) is to 
think in terms of:


  * random _generators_, i.e. sources of uniformly distributed 
random bits:


- random _engines_ (seedable, pseudo-random algorithms)

- random _devices_ (non-deterministic sources of uniformly 
distributed bits)


  * random _distributions_, which transform uniformly-distributed 
random bits

into variates with some other type and distribution

- note _this includes uniformly-distributed integers_!

- also uniformly-distributed floats, enums, etc.

- and also non-uniform distributions

  * random _algorithms_, i.e. algorithms in the sense of 
std.random, but where

their popFront() includes random decision-making

- randomCover, randomSample, etc.

The point of the above breakdown is that it gives a nice and 
clear separation of concerns that allows for easily replaceable 
components.  Separating out stuff just by the ultimate result you 
want (integers vs. floats, uniform vs. non-uniform, etc.) isn't 
helpful in that way.

Re: Mir Random [WIP]

[John Colvin via Digitalmars-d]

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu 
wrote:

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
 - `opCall` API instead of range interface is used (similar to 
C++)


This seems like a gratuitous departure from common D practice. 
Random number generators are most naturally modeled in D as 
infinite ranges. -- Andrei


I'm pretty sure everyone *wants* it to be a range, but it turns 
out it's a difficult design space. Lot's of nasty trade-offs that 
can be (and have been) argued back and forth depending on your 
priorities.


Perhaps you have an insight that has been missed that can make a 
good rng range without causing less than optimal performance or 
statistically unsafe default behaviour?


IIRC you think people are making too much fuss about the 
statistically safe default behaviour, but it would be interesting 
to hear a more expanded version of that view.

Re: Mir Random [WIP]

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu 
wrote:

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
 - `opCall` API instead of range interface is used (similar to 
C++)


This seems like a gratuitous departure from common D practice. 
Random number generators are most naturally modeled in D as 
infinite ranges. -- Andrei


Yes, I think this is avoiding the existing problems with RNGs and 
ranges rather than solving them.


I don't blame anyone for _wanting_ to avoid them; they are nasty, 
subtle issues that seem to keep getting more complex the more one 
looks at them (for example, after my DConf talk last year, I 
realized that there were a whole set of other potential 
complications related to how ranges typically treat laziness).  
But I think they can be solved, and should be.


OTOH, there's no reason per se why there should not be an 
`opCall` for random number generators along the lines of,


UIntType opCall()
{
this.popFront();
return this.front;
}

... just to provide options to the user.  (BTW, note the order 
there, which touches on the issues related to what lazy 
evaluation means not just for RNGs but for any non-deterministic 
IO.)

Re: Mir Random [WIP]

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:

 - `opCall` API instead of range interface is used (similar to C++)


This seems like a gratuitous departure from common D practice. Random 
number generators are most naturally modeled in D as infinite ranges. -- 
Andrei

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/16 1:57 PM, tsbockman wrote:

Your test fails because you aren't actually using `core.bitop`.
Intrinsics are detected based on fully qualified names. As soon as you
copy `bsf()` and `bsr()` outside of `core.bitop`, the FQN changes and
they're not intrinsics anymore.


Thanks, didn't know how it works. We should document that clearly so as 
to avoid confusions in the future. -- Andrei

Re: A simplification of the RvalueRef idiom

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 16:57:28 UTC, kink wrote:


I hate this 'idiom' too (just a clumsy workaround for something 
that should work out of the box), but the non-bindability of 
rvalues to ref params and the associated dispute is veeery old, 
nothing new, so I don't agree that the language gets worse 
every day. ;)


d-idioms doesn't always paint a rosy picture of D, that's true. 
It's about "what can we do now with D, whatever it takes". It 
turns out almost everything can be done, but some things are 
worse than in other languages of course.


The baby is too cute to throw with the bathwater ;)

D IDE - Coedit 3 first beta

[Basile B. via Digitalmars-d-announce]

- Changelog: 
https://gist.github.com/BBasile/5dfb21fd6bd5848922867633eb4136f5
- Github release page: 
https://github.com/BBasile/Coedit/releases/tag/3_beta_1


Note that this announce is short on purpose. It's a pre-release, 
however I've build the usual binaries, see second link.


You want to test, you see something not quite right ? The only 
way to get it handled is: https://github.com/BBasile/Coedit/issues


a+++

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Johan Engelen via Digitalmars-d]

On Tuesday, 22 November 2016 at 22:57:22 UTC, Iain Buclaw wrote:
On 22 November 2016 at 23:29, Daniel Kozak via Digitalmars-d 
 wrote:
Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d 
napsal(a):


The intent is to have the compiler detect the pattern and 
insert the code. dmd does that IIRC (why is asm.dlang.org not 
working again?) and so does gdc: 
https://godbolt.org/g/WspkIX. -- Andrei



WTF? I hope you are not serious?


Ilya, Andrei, or both?

It's a compilers job is to detect code patterns and emit 
suitable instructions for them. :-)


None of the compilers detect the body code pattern. I believe DMD 
and GDC just detect the mangled function name. Indeed, changing 
the function body to something else will still emit a "bsr" asm 
instruction: https://godbolt.org/g/x3WiEt

LDC chose to reimplement the functions using intrinsics.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Iain Buclaw via Digitalmars-d]

On 22 November 2016 at 23:29, Daniel Kozak via Digitalmars-d
 wrote:
> Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d napsal(a):
>
>
>> On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:
>>>
>>> They are always software
>>> https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
>>
>>
>> The intent is to have the compiler detect the pattern and insert the code.
>> dmd does that IIRC (why is asm.dlang.org not working again?) and so does
>> gdc: https://godbolt.org/g/WspkIX. -- Andrei
>>
> WTF? I hope you are not serious?

Ilya, Andrei, or both?

It's a compilers job is to detect code patterns and emit suitable
instructions for them. :-)

Re: DIP 1003: remove `body` as a keyword

[Timon Gehr via Digitalmars-d-announce]

On 22.11.2016 20:05, Meta wrote:

On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:

Am 21.11.2016 um 22:19 schrieb Timon Gehr:

3 is ambiguous.


Can you give an example?


I'm curious as well. I considered that option 3 might be ambiguous but I
managed to convince myself that it wouldn't be. I'm guessing you're
referring to the fact that:

{
//function body
}

Is a delegate literal, which could conceivably conflict with Option 3's
syntax?

void fun(ref int n)
in { assert(n > 0); }
out { assert(n > 0); }
{ //Is this a syntax error or an immediately executed delegate literal?
n += 1;
}()



Function declarations don't necessarily have a body, but they might have 
contracts. (This is currently not allowed for technical reasons, but it 
should/will be.) But this is a rather minor point (usually you don't 
want to have contracts without implementation in a context where 
something starting with '{' is allowed).


The more important point is that there is no precedent where {...}{...} 
are two components of the same entity, it looks ugly even with the 
space-wasting convention where '{' is put on its own line. Not all 
contracts are one-liners like in your example above (which looks almost 
tolerable).

Re: Detect that a child is waiting for input

[wobbles via Digitalmars-d]

On Monday, 21 November 2016 at 07:29:55 UTC, unDEFER wrote:

On Sunday, 20 November 2016 at 21:03:57 UTC, John Colvin wrote:
If blocking is an error, you could close stdin and assuming 
the process checks the error codes correctly


No, I mean blocking is not error.
One method to find it, run gdb or strace and see where the 
process stopped, or which syscall was last. But I believe that 
must be other way.


Easier said than done as there's no signal the child sends to say 
"OK, I'm waiting now".


You can use expect to do this, if you know what the output of the 
child will be just before it's waiting for IO.


This is the D lib I've written to do this:
https://github.com/grogancolin/dexpect

It's not wonderful or anything, but it works :)

D developer jobs

[eugene via Digitalmars-d]

hello everyone,
could you, please, tell do any jobs(full-time or freelance) exist 
for junior D developers?

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Daniel Kozak via Digitalmars-d]

Dne 22.11.2016 v 17:36 Andrei Alexandrescu via Digitalmars-d napsal(a):


On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

They are always software
https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya


The intent is to have the compiler detect the pattern and insert the 
code. dmd does that IIRC (why is asm.dlang.org not working again?) and 
so does gdc: https://godbolt.org/g/WspkIX. -- Andrei



WTF? I hope you are not serious?

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #19 from Ketmar Dark  ---
actually, i believe that no merges from stable to master should be done at all.
if hotfix is applicable to both branches, it should go to both branches, first
in master, and then, possibly with another PR, in stable. not the other way
around. if autotester is the blocker, then something should be done with
autotester. but in no way master aka "dev" should be behind stable in terms of
bugfixes.

all the new developement is done on master, so master should have all bugs
fixed first, so people won't spend time chasing the bug that may be fixed in
stable, but not merged to master yet. actually, i think that PRs against stable
should be rejected if there is no equivalent PR against master, or link to
already existing PR that fixed the bug.

sure, this may add some burden on devs, but i believe that it is better and
helthier way to do developement work. for now it is unclear which branch has
bug fixed, for example. it is marked as fixed in bugzilla? ok, i'll go with my
dev work the... oh, wait! it is not fixed in master! so i have to rebase my
work on stab... oh, wait! we aren't doing dev against stable! ok, i'll
cherry-pick it myse... oh, wait, merge arrived! ah, fsck all that mess, i
already lost the motivation.

--

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Iain Buclaw via Digitalmars-d]

On 22 November 2016 at 18:07, Ilya Yaroshenko via Digitalmars-d
 wrote:
> On Tuesday, 22 November 2016 at 16:52:40 UTC, Johan Engelen wrote:
>>
>> On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu wrote:
>>>
>>> On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

 They are always software
 https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya
>>>
>>>
>>> The intent is to have the compiler detect the pattern and insert the
>>> code. dmd does that IIRC (why is asm.dlang.org not working again?) and so
>>> does gdc: https://godbolt.org/g/WspkIX.
>>
>>
>> LDC too. https://godbolt.org/g/S83b30
>> (note that cross-module inlining is off by default, something to work on
>> for 1.2.0!)
>
>
> No, LDC and GDC cannot detect it. Proof - https://godbolt.org/g/bsAFU8 .
> Current LDC DRuntime uses intrinsics instead of software implementation.
>
> Ilya

Fixed that for you.  Unfortunately it seems LDC just isn't clever enough.

https://godbolt.org/g/quBpEq

Iain

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #18 from hst...@quickfur.ath.cx ---
@Steven: I see your point about preventing redundant fixes. But it's still
confusing that a bug has been resolved as fixed, yet the bug persists in
master. :-)

Is there a way for bugzilla to indicate which branch(es) a bug has been fixed
in?  Debian's Bug Tracking System, for example, in the recent years got a new
feature where it keeps track of all the releases
(experimental/unstable/testing/stable) that a bug has been fixed in, so that
you can tell at a glance whether or not the fix is in the release you're
interested in.

Debian's BTS also tracks the package version number that a fix was first
implemented in, so you can check whether you have the fix by looking at the
version string, even if you're not using the official .deb repositories.
Although, this is probably not applicable in our case.

--

Re: A simplification of the RvalueRef idiom

[Satoshi via Digitalmars-d-learn]

or I have simple class

class View {
this(Rectangle frame) {...}
this(float, float, float, float) { ... }
this(Point, Size) { ... }
}

then struct Point, Size and Rectangle (Point, Size)

now I need to write 2 overloads for View class taking 4 floats or 
(Point, Size) and this must do in every descendant of View class.

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #17 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #15)
> the whole process is broken: under no circumstances any hotfix that is
> applicable both to master and to stable can land in stable first.

Oh, I may have misread your point. It has to go into stable first, because you
can't merge master into stable. Only the other way around. What I thought you
were asking is for stable to be merged into master every time a fix is pulled.

--

Re: A simplification of the RvalueRef idiom

[Satoshi via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 19:16:56 UTC, Ali Çehreli wrote:

On 11/22/2016 08:05 AM, Satoshi wrote:


I don't have extensive experience with other languages. In 
fact, the only other languages that I can claim proficiency are 
C and C++. (I also know Python just enough to find it 
incredible how it's used in the industry. Let's not get in to 
that discussion but I really tried and failed... in industry... 
:) ) Given that experience, I still find D a very useful tool.




D is one o the best languages what exists, it's reason why I'm 
using it. But some issues are solved better in other languages 
like rust, go or swift.




Agreed but it opens the door for bugs. Assuming

struct A { int a; }
struct B { int b; int c; }

void foo(int, int, int);

If foo(1, 2, 3) meant foo(A(1), B(2, 3)) today, it could 
silently mean foo(A(1, 2), B(3)) if one moved one member from 
one struct to the other.


Then there are other corner cases:

writeln(1, 2, 3);

Should that print the integers or A(1) and B(2, 3)? It's always 
better to be explicit.




argument expand should be applied only to the last argument and 
cannot be used in variadic templates. Like in my simple example 
where I exactly know what function will do, but I want to call it 
by simplest way.


It actually works with classes, but no with structs.



import std.stdio;

struct Point {
int x;
int y;
}

struct GraphicsContext {
static GraphicsContext current() {
return GraphicsContext();
}

void moveTo(Point point) {
writefln("Moving to %s", point);
}

void lineTo(Point point) {
writefln("Drawing line to %s", point);
}
}

void goTo(GraphicsContext gc, int x, int y) {
gc.moveTo(Point(x, y));
}

void drawTo(GraphicsContext gc, int x, int y) {
gc.lineTo(Point(x, y));
}

void main() {
auto gc = GraphicsContext.current;
gc.goTo(70, 70);// <-- Clean syntax
gc.drawTo(70, 170);
}


But I need to write overload function for every function taking 
simple messengers like Point/Size/Rectangle

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #16 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #15)
> the whole process is broken: under no circumstances any hotfix that is
> applicable both to master and to stable can land in stable first.

It's advantageous to do it "all at once" instead of one at a time.

Keep in mind that the auto tester needs to test all these. I'd rather have it
test the "whole thing" at once one time rather than test each hotfix as it's
produced when it's already been tested on stable.

In addition, the PRs for merging stable to master are not always
straightforward. Less work if you do it all at once.

(In reply to hsteoh from comment #10)
> Is it customary to close bugs once they are fixed in stable, even though the
> fix has not yet been merged to git HEAD?

Yes, once a commit happens, the issue should be closed, as long as it's going
to go into master. Imagine if someone notices this is not fixed, and creates a
PR for master without realizing it's already fixed :) Not that I've ever done
that...

Note that anyone can create a PR to merge stable to master. It's just another
PR.

--

[Issue 16611] std.traits.fullyQualifiedName fails with error 'Unrecognized type const(void)'

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/a636bb6bb00e54fda367bd3c452db2ced0ca9df6
Fix Issue 16611 - 'Unrecognized type const(void)' error for
std.traits.fullyQualifiedName

https://github.com/dlang/phobos/commit/3fec190b7ff1274dc7b1339f161b09027145
Merge pull request #4916 from Darredevil/issue-16611

Fix Issue 16611 - 'Unrecognized type const(void)' error for std.trait…

--

[Issue 16611] std.traits.fullyQualifiedName fails with error 'Unrecognized type const(void)'

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: What is going on with the ubuntu/debian debacle ?

[H. S. Teoh via Digitalmars-d]

On Sat, Nov 19, 2016 at 11:03:05PM +, deadalnix via Digitalmars-d wrote:
> A lot of users are reporting errors on debian and ubuntu. .o generated
> by dmd do not link and libphobos.a is unusable.
> 
> This is very bad and we should consider a hotfix. Is someone on it ?

FWIW, I'm using Debian/unstable and compiling dmd/druntime/phobos
directly from git HEAD, and it seems to work fine.

Does this problem only happen for the shipped .deb packages?


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and 
over.

Re: PDF generation in D?

[o3o via Digitalmars-d]

On Thursday, 10 November 2016 at 22:30:34 UTC, Karabuta wrote:
Hello community, does anyone have on something for PDF 
generation in D? I may need a PDF generation library in a 
vibe.d project I'm working on. :)


Try http://code.dlang.org/packages/harud, a D binding to libharu.

Re: Char representation

[RazvanN via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 14:23:28 UTC, Jonathan M Davis 
wrote:
On Tuesday, November 22, 2016 13:29:47 RazvanN via 
Digitalmars-d-learn wrote:

[...]


You misunderstand. char[] is a dynamic array of char, wchar[] 
is a dynamic array of wchar[], and dchar[] is a dynamic array 
of dchar. There is nothing funny going on with the internal 
representation. Rather, the problem is with the range API and 
the traits that go with it. And it's not a bug; it's a design 
mistake.


[...]


Thank you very much for this great explanation. Things are 
starting to make sense now.


Razvan Nitu

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[ketmar via Digitalmars-d]

On Tuesday, 22 November 2016 at 19:43:14 UTC, Ilya Yaroshenko 
wrote:

Why do you think it can?

'cause it is in compiler sources.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 19:29:30 UTC, tsbockman wrote:
On Tuesday, 22 November 2016 at 19:27:11 UTC, Ilya Yaroshenko 
wrote:

On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
Your test fails because you aren't actually using 
`core.bitop`. Intrinsics are detected based on fully 
qualified names. As soon as you copy `bsf()` and `bsr()` 
outside of `core.bitop`, the FQN changes and they're not 
intrinsics anymore.


Does DMD overrides bodies for bsf and bsr? It would be 
surprised to me.


That's how (almost) ALL of the intrinsics in `core.bitop` and 
`core.math` are supposed to work. If it's not overriding the 
bodies, that's a bug.


DMD can recognise code patterns and replace them with hardware 
functions. I never seen that it can replace bodies. Why do you 
think it can? Have you disassembler DMD the code with your PR?

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[tsbockman via Digitalmars-d]

On Tuesday, 22 November 2016 at 19:27:11 UTC, Ilya Yaroshenko 
wrote:

On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
Your test fails because you aren't actually using 
`core.bitop`. Intrinsics are detected based on fully qualified 
names. As soon as you copy `bsf()` and `bsr()` outside of 
`core.bitop`, the FQN changes and they're not intrinsics 
anymore.


Does DMD overrides bodies for bsf and bsr? It would be 
surprised to me.


That's how (almost) ALL of the intrinsics in `core.bitop` and 
`core.math` are supposed to work. If it's not overriding the 
bodies, that's a bug.

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 18:57:59 UTC, tsbockman wrote:
On Tuesday, 22 November 2016 at 17:07:08 UTC, Ilya Yaroshenko 
wrote:
No, LDC and GDC cannot detect it. Proof - 
https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses 
intrinsics instead of software implementation.


Ilya


Your test fails because you aren't actually using `core.bitop`. 
Intrinsics are detected based on fully qualified names. As soon 
as you copy `bsf()` and `bsr()` outside of `core.bitop`, the 
FQN changes and they're not intrinsics anymore.


Does DMD overrides bodies for bsf and bsr? It would be surprised 
to me.

Re: A simplification of the RvalueRef idiom

[Ali Çehreli via Digitalmars-d-learn]

On 11/22/2016 08:05 AM, Satoshi wrote:

> Sorry, but D seems to be worse and worse day by day.

I don't have extensive experience with other languages. In fact, the 
only other languages that I can claim proficiency are C and C++. (I also 
know Python just enough to find it incredible how it's used in the 
industry. Let's not get in to that discussion but I really tried and 
failed... in industry... :) ) Given that experience, I still find D a 
very useful tool.


> This should be resolved by language and not doing it by template 
function.


byRef() is not implicit due to a deliberae design decision. Walter talks 
about why the language lacks ref variables in his recent talk. No, I was 
not there and the audio is lost, so all we have at this point are the 
slides. It's the "Memory Safety and the D Programming Languge" presentation


  http://www.walterbright.com/

Slide 26 starts talking about ref and why it's only for parameters and 
returns.


> Same thing should be applied for maybe monad and tuples.
>
> e.g. When I want to create simple function for drawing
>
> void lineTo(auto ref Point point...) {
> //...
> }
>
> It's easier to call it like:
> Point p = Point(42, 42);
>
> lineTo(p);
> lineTo(42, 42);

Agreed but it opens the door for bugs. Assuming

struct A { int a; }
struct B { int b; int c; }

void foo(int, int, int);

If foo(1, 2, 3) meant foo(A(1), B(2, 3)) today, it could silently mean 
foo(A(1, 2), B(3)) if one moved one member from one struct to the other.


Then there are other corner cases:

writeln(1, 2, 3);

Should that print the integers or A(1) and B(2, 3)? It's always better 
to be explicit.


> lineTo(Point(42, 42)); // this
> lineTo(Point(42, 42).byRef); // and this is just overhead

I don't agree with those two examples but e.g. I find the following 
cumbersome:


A[] arr = [ A(1), A(2) ];

> Sorry, but I want to write fast and safe programs in the fastest
> possible way

I think in these examples 'fast' and 'safe' don't work together.

> and writing Point(...) or Point(...).byRef every time is
> redundant overhead.
>
> Like http://pix.toile-libre.org/upload/original/1479816672.png
>
>
> PS: sorry for sarcasm
> - Satoshi
>

Agreed but I find solutions like the following acceptable. Yes, function 
names must be different but it's usually fine.


import std.stdio;

struct Point {
int x;
int y;
}

struct GraphicsContext {
static GraphicsContext current() {
return GraphicsContext();
}

void moveTo(Point point) {
writefln("Moving to %s", point);
}

void lineTo(Point point) {
writefln("Drawing line to %s", point);
}
}

void goTo(GraphicsContext gc, int x, int y) {
gc.moveTo(Point(x, y));
}

void drawTo(GraphicsContext gc, int x, int y) {
gc.lineTo(Point(x, y));
}

void main() {
auto gc = GraphicsContext.current;
gc.goTo(70, 70);// <-- Clean syntax
gc.drawTo(70, 170);
}

Ali

Re: DIP 1003: remove `body` as a keyword

[Meta via Digitalmars-d-announce]

On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:

Am 21.11.2016 um 22:19 schrieb Timon Gehr:

3 is ambiguous.


Can you give an example?


I'm curious as well. I considered that option 3 might be 
ambiguous but I managed to convince myself that it wouldn't be. 
I'm guessing you're referring to the fact that:


{
//function body
}

Is a delegate literal, which could conceivably conflict with 
Option 3's syntax?


void fun(ref int n)
in { assert(n > 0); }
out { assert(n > 0); }
{ //Is this a syntax error or an immediately executed delegate 
literal?

n += 1;
}()

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[tsbockman via Digitalmars-d]

On Tuesday, 22 November 2016 at 17:07:08 UTC, Ilya Yaroshenko 
wrote:
No, LDC and GDC cannot detect it. Proof - 
https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses 
intrinsics instead of software implementation.


Ilya


Your test fails because you aren't actually using `core.bitop`. 
Intrinsics are detected based on fully qualified names. As soon 
as you copy `bsf()` and `bsr()` outside of `core.bitop`, the FQN 
changes and they're not intrinsics anymore.

Re: PDF generation in D?

[Vasudev Ram via Digitalmars-d]

On Tuesday, 22 November 2016 at 18:49:51 UTC, Vasudev Ram wrote:


- check out libharu - it is an open source C library for PDF


P.S. I just saw here:

http://code.dlang.org/packages/fpdf

that they say "If you don't need to be able to import PDFs, you 
may want to check out harud"  - which by the name is probably a D 
wrapper for libharu.

Re: Complex numbers are harder to use than in C

[Marduk via Digitalmars-d-learn]

On Sunday, 20 November 2016 at 11:46:04 UTC, Marc Schütz wrote:

Try placing it outside the function. Method call syntax doesn't 
work with nested functions, see here:


https://dlang.org/spec/function.html#pseudo-member

"The reason why local symbols are not considered by UFCS, is to 
avoid unexpected name conflicts."


Aha! Now it works. Thank you for the explanation.

Re: Complex numbers are harder to use than in C

[Marduk via Digitalmars-d-learn]

On Sunday, 20 November 2016 at 12:08:23 UTC, Ilya Yaroshenko 
wrote:


You can use builtin complex numbers (cfloat/cdouble/creal). The 
idea of std.complex is wrong . Mir GLAS uses builtin complex 
numbers and I don't think they will be really deprecated. --Ilya


Good to know! The builtin syntax is more reasonable than 
std.complex.

Re: PDF generation in D?

[Vasudev Ram via Digitalmars-d]

On Thursday, 10 November 2016 at 22:30:34 UTC, Karabuta wrote:
Hello community, does anyone have on something for PDF 
generation in D? I may need a PDF generation library in a 
vibe.d project I'm working on. :)


Hi,

I did read all the replies posted up to now. Posting a few 
alternative methods I thought of, some of which involve calling C 
libraries from D - not sure how suitable they will be for your 
specific needs, some checking will be required:


- check out libharu - it is an open source C library for PDF 
generation. If you can call it from D, it may work for your needs.


http://libharu.org/ . Libharu needs a new maintainer now, but the 
site says it still works.


- check out PDFlib(.com). PDFlib is a paid product, and the core 
is a C library. However it has an open source version IIRC, and 
may be free for personal use (not sure if you want this for 
personal or commercial use). Again, would need to call it's (C) 
functions from D. PDFlib is a mature product which has been 
around for many years. It also has binding to some other 
languages.


(I've tried both the above libs at least a bit, and they do work.)

- this one is an obvious, though roundabout method: if the D- and 
C-based ones are not suitable for whatever reason, there are 
generic methods applicable to calling (a program that uses) a 
PDF-generation library (or any library for that matter) in any 
other language, such as via XML-RPC (if D has a client library 
for that, or if D can call a C client XML-RPC library), REST or 
sockets.


- an even simpler method than above (though, of course, less 
efficient for multiple calls) may be to shell out to some 
executable [1] written in another language which has a PDF 
generation library, pass the necessary inputs on the command line 
(as command-line options,  an input file name, and an output PDF 
filename.


[1] By executable here, I don't only mean a compiled user 
executable such as a C or C++ or Java app. It could also be a 
call to a language interpreter (the executable) taking a script 
in that language, as an argument to run, and the script name 
could be followed by arguments for the script itself (e.g. python 
pdf_gen_prog.py arg1 arg2 ...) . Using this approach, for 
example, one could shell out to Python, run a Python script that 
uses ReportLab, and use that to do the job, since ReportLab is 
fairly powerful for PDF generation, though a bit low-level. 
However, it does have things like Paragraphs, Stories, Styles, 
and Platypus which are a bit higher-level. And if your PDF output 
involves only text (i.e. no images, charts, varying fonts, etc.), 
then you can even consider shelling out to a Python program you 
write, that uses xtopdf - which is my PDF generation toolkit 
written in Python, which uses ReportLab internally, and provides 
a somewhat higher abstraction for a subset of ReportLab's 
functionality, namely generation of text-only line-oriented PDF 
output, with automatic headers, footers, page numbering and 
pagination). xtopdf is quite easy to use: With low-level 
Reportlab features, you have to write your PDF generation logic 
in terms of operations on a Canvas object, not lines of text, so 
you have to say things like writeString(x, y, string), and 
calculate each x and y, reset the font to the same value after 
each new page (a limitation), but with xtopdf you get the higher 
level abstraction of something like a text file (a PDFWriter 
object), and you just write lines of text to the PDFWriter object 
using its writeLine(string) method, until you are done. Just have 
to set the header and footer and font once, first (3 lines for 
that). Total for a simple file is under 10 or so lines of Python 
code, to generate a PDF from text input, using xtopdf - with some 
amount of simple customized formatting of the text possible, in 
terms of left-or-right-justifying, centering, etc., using 
Python's easy string handling, with a few more lines of code.


ReportLab main site: http://reportlab.com

ReportLab open source version: http://reportlab.com/ftp

Good high-level overview of xtopdf: 
http://slides.com/vasudevram/xtopdf (including uses, users, 
supported input formats, supported platforms, example programs, 
etc.)


xtopdf on Bitbucket: https://bitbucket.org/vasudevram/xtopdf

xtopdf examples on my blog: 
http://jugad2.blogspot.com/search/label/xtopdf


Guide to installing and using xtopdf:

http://jugad2.blogspot.in/2012/07/guide-to-installing-and-using-xtopdf.html

HTH,
Vasudev
jugad2.blogspot.com
vasudevram.github.io

Re: implementing --version?

[mab-on via Digitalmars-d-learn]

Thanks! These tips are exactly what i needed :)

[Issue 16705] TaskPool.reduce fails to compile "cannot get frame pointer to D main"

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

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

--- Comment #3 from ZombineDev  ---
The documentation fix is in, but I want to investigate further this regression,
so I will reopen it.

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #15 from Ketmar Dark  ---
the whole process is broken: under no circumstances any hotfix that is
applicable both to master and to stable can land in stable first.

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #14 from hst...@quickfur.ath.cx ---
Eventually all fixes in stable get merged to master. It's just that in the
interim, I'm wondering whether bugs that still exist in master should be kept
open until the merge happens, or as soon as stable gets the fix.

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

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

--- Comment #13 from Ketmar Dark  ---
any such fix should go to master *too*, in the same time. it is... strange to
have a developement version with bugs that was fixed in release version,
considering that master is what people is using to develop/test new features.

--

[Issue 16102] [REG2.070] struct dtor replace value on stack

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

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

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #10 from hst...@quickfur.ath.cx ---
Is it customary to close bugs once they are fixed in stable, even though the
fix has not yet been merged to git HEAD?

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #11 from hst...@quickfur.ath.cx ---
'cos this is not yet working in git HEAD.

--

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 16:52:40 UTC, Johan Engelen wrote:
On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei 
Alexandrescu wrote:

On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

They are always software
https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya


The intent is to have the compiler detect the pattern and 
insert the code. dmd does that IIRC (why is asm.dlang.org not 
working again?) and so does gdc: https://godbolt.org/g/WspkIX.


LDC too. https://godbolt.org/g/S83b30
(note that cross-module inlining is off by default, something 
to work on for 1.2.0!)


No, LDC and GDC cannot detect it. Proof - 
https://godbolt.org/g/bsAFU8 . Current LDC DRuntime uses 
intrinsics instead of software implementation.


Ilya

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu 
wrote:

On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

They are always software
https://github.com/dlang/druntime/blob/master/src/core/bitop.d 
--Ilya


The intent is to have the compiler detect the pattern and 
insert the code. dmd does that IIRC (why is asm.dlang.org not 
working again?) and so does gdc: https://godbolt.org/g/WspkIX. 
-- Andrei


GDC and LDC can not detect it, I don't think DMD can. Proof - 
https://godbolt.org/g/bsAFU8 .
Your link refers to GDC with an old DRuntime, which have bsr 
intrinsics instead of current software code.


In addition, i need to be sure that an intrinsics function is 
always inlined (without -inline flag too).

--Ilya

Re: A simplification of the RvalueRef idiom

[kink via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 16:05:35 UTC, Satoshi wrote:

Sorry, but D seems to be worse and worse day by day.
This should be resolved by language and not doing it by 
template function.


I hate this 'idiom' too (just a clumsy workaround for something 
that should work out of the box), but the non-bindability of 
rvalues to ref params and the associated dispute is veeery old, 
nothing new, so I don't agree that the language gets worse every 
day. ;)

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

--- Comment #17 from Steven Schveighoffer  ---
There are two problems, one is that the OP's code compiles, the other is that
it segfaults. Arguably, fixing the first problem will fix the second. But just
fixing the second leaves other problems still intact.

Also, note that this succeeds, but likely does not do what the writer wants:

string s = "123456";
s ~= 7;

Guess what this does (yes, it compiles)?

s ~= 123456;

--

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Johan Engelen via Digitalmars-d]

On Tuesday, 22 November 2016 at 16:36:13 UTC, Andrei Alexandrescu 
wrote:

On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

They are always software
https://github.com/dlang/druntime/blob/master/src/core/bitop.d 
--Ilya


The intent is to have the compiler detect the pattern and 
insert the code. dmd does that IIRC (why is asm.dlang.org not 
working again?) and so does gdc: https://godbolt.org/g/WspkIX.


LDC too. https://godbolt.org/g/S83b30
(note that cross-module inlining is off by default, something to 
work on for 1.2.0!)

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Andrei Alexandrescu via Digitalmars-d]

On 11/22/2016 11:28 AM, Ilya Yaroshenko wrote:

They are always software
https://github.com/dlang/druntime/blob/master/src/core/bitop.d --Ilya


The intent is to have the compiler detect the pattern and insert the 
code. dmd does that IIRC (why is asm.dlang.org not working again?) and 
so does gdc: https://godbolt.org/g/WspkIX. -- Andrei

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 22 November 2016 at 16:07:39 UTC, Steven 
Schveighoffer wrote:

On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:

Philosophical Questions:

1. Why hight level stuff like BitRange is in core.bitop, but 
not in

std.bitmanip? If it should be in core, why it is public?


I wrote BitRange to help with cycle detection. It was related 
to using the btc/btr/bt functions on bit arrays (it's meant to 
wrap such a bit array), so that seemed like a natural place for 
it. Putting it in std.bitmanip would make it unavailable to 
druntime.


Why shouldn't it be public?



2. Why bsf and bsr do NOT use hardware instructions anymore?


They should unless there is no hardware instruction available. 
I believe the software implementation is only a fallback when 
this is the case.


-Steve


They are always software  
https://github.com/dlang/druntime/blob/master/src/core/bitop.d 
--Ilya

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

--- Comment #16 from Andrei Alexandrescu  ---
This bug has a simple fix - throw a runtime exception (e.g. by onUnicodeError)
instead of assert(0). We shouldn't change language rules on account of this.
Thanks!

--

Re: !!!Please add intrinsics module for DMD DRuntime!!!

[Steven Schveighoffer via Digitalmars-d]

On 11/22/16 8:31 AM, Ilya Yaroshenko wrote:

Philosophical Questions:

1. Why hight level stuff like BitRange is in core.bitop, but not in
std.bitmanip? If it should be in core, why it is public?


I wrote BitRange to help with cycle detection. It was related to using 
the btc/btr/bt functions on bit arrays (it's meant to wrap such a bit 
array), so that seemed like a natural place for it. Putting it in 
std.bitmanip would make it unavailable to druntime.


Why shouldn't it be public?



2. Why bsf and bsr do NOT use hardware instructions anymore?


They should unless there is no hardware instruction available. I believe 
the software implementation is only a fallback when this is the case.


-Steve

Re: A simplification of the RvalueRef idiom

[Satoshi via Digitalmars-d-learn]

On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:

First, a reminder that we have this great resource of D idioms:


https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it

The link above has an idiom of mixing in a byRef() member 
function to a struct. I think I've simplified the template by 
moving typeof(this) inside it:


mixin template RvalueRef()// <-- DOES NOT TAKE A PARAMETER 
ANY MORE

{
alias T = typeof(this);
static assert (is(T == struct));

@nogc @safe
ref const(T) byRef() const pure nothrow return
{
return this;
}
}

struct Vector2f
{
float x, y;

this(float x, float y) pure nothrow
{
this.x = x;
this.y = y;
}

mixin RvalueRef;// <-- SIMPLER USE
}

void foo(ref const Vector2f pos)
{
writefln("(%.2f|%.2f)", pos.x, pos.y);
}

void main()
{
Vector2f v = Vector2f(42, 23);
foo(v);   // Works
foo(Vector2f(42, 23).byRef);  // Works as well, and use 
the same function

}

Let me know if it's not the equivalent of the original.

Ali



Sorry, but D seems to be worse and worse day by day.
This should be resolved by language and not doing it by template 
function.

Same thing should be applied for maybe monad and tuples.

e.g. When I want to create simple function for drawing

void lineTo(auto ref Point point...) {
//...
}

It's easier to call it like:
Point p = Point(42, 42);

lineTo(p);
lineTo(42, 42);


lineTo(Point(42, 42)); // this
lineTo(Point(42, 42).byRef); // and this is just overhead


Everything possible should be solved by syntactic sugar rather 
than implementing it as template func.


Or just remove shared, TLS and other stuff from D and implement 
it as templates like in C++. Then you can write much more longer 
and uglier stuffs as you trying.


void lineTo(std::shared_ptr point) {
// ...
}

lineTo(std::make(42, 42));

should be ideal way how to complicate programming for other users.



Sorry, but I want to write fast and safe programs in the fastest 
possible way and writing Point(...) or Point(...).byRef every 
time is redundant overhead.


Like http://pix.toile-libre.org/upload/original/1479816672.png


PS: sorry for sarcasm
- Satoshi

Re: Memory allocation failed. Why?

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/21/16 11:53 AM, ag0aep6g wrote:

On Monday, 21 November 2016 at 16:37:32 UTC, Kagamin wrote:

Anything in .data and .bss sections and stack. See
https://issues.dlang.org/show_bug.cgi?id=15723


Ok, not an actual reference then, but a false pointer.


Yes. 100 million bytes is 1/40 of all addressable space on 32-bits. 
There only needs to be one 4-byte segment somewhere on the stack that 
points at this, and it won't be collected.


Assuming you have a quite large segment that can't be extended or 
collected (due to false pointer), this means you have to allocate 
another large one to satisfy the next allocation (which then could be 
pinned). And it gets worse from there.


-Steve

Re: Is there a way to identfy Windows version?

[rumbu via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 11:00:52 UTC, Bauss wrote:
On Monday, 21 November 2016 at 09:11:39 UTC, Jonathan M Davis 
wrote:
On Monday, November 21, 2016 08:57:11 Bauss via 
Digitalmars-d-learn wrote:

[...]


Phobos doesn't have anything like that, but you can use the C 
functions from the Windows API to do it. A quick search turned 
up GetVersion and GetVersionExA/W:


[...]


Thank you, I thought I would end up with something like that! :)


Obtaining the true Windows version is tricky starting with 
Windows 8.


Be careful when using GetVersionEx, it's deprecated. 
VerifyVersionInfo is more reliable, but it will not return a 
version greater than Windows 8 if your application does not embed 
a specific manifest. The dirty way to obtain the true Windows 
version without embedding a manifest, it's to check for the 
availability of specific functions.


Another way is to parse HLKM\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\Product Name.


And finally NetServerGetInfo is your best bet, but it's not 
guaranteed to work in the future version of Windows.

Re: Char representation

[Kagamin via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 13:29:47 UTC, RazvanN wrote:

Given the following code:

 char[5] a = ['a', 'b', 'c', 'd', 'e'];
 alias Range = char[];
 writeln(is(ElementType!Range == char));

One would expect that the program will print true. In fact, it 
prints false and I noticed that if Range is char[], wchar[], 
dchar[], string, wstring, dstring
Unqual!(ElementType!Range) is dchar. I find it odd that the 
internal representation for char and string is dchar. Is this a 
bug?


Here's the reading: 
https://forum.dlang.org/post/nh2o9i$hr0$1...@digitalmars.com

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

--- Comment #15 from Steven Schveighoffer  ---
Lucia, I think nothing should implicitly cast to dchar. Not bool, int, or even
char or wchar. But something this drastic needs approval from Walter and
Andrei.

Of course, we definitely need a deprecation step before completely banning it
-- this will certainly break a lot of code.

--

Re: DIP 1003: remove `body` as a keyword

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.11.2016 um 22:19 schrieb Timon Gehr:

3 is ambiguous.


Can you give an example?

Re: D with CygWin

[Adam D. Ruppe via Digitalmars-d]

On Monday, 21 November 2016 at 06:38:00 UTC, unDEFER wrote:
1) recompile all dmd libraries including snn.lib with replacing 
open->_open, close->_close, remove->_remove.


What if you just wrote wrapper functions or better yet, linker 
aliases?

Re: Dlang dynamic compilation

[Faux Amis via Digitalmars-d-announce]

On 2016-11-22 12:51, Nordlöw wrote:

On Monday, 21 November 2016 at 18:59:17 UTC, Ivan Butygin wrote:

Hacked ldc sources are here:
https://github.com/Hardcode84/ldc/tree/runtime_compile


This could be used to accelerate genetic algorithms at run-time.


https://en.wikipedia.org/wiki/Genetic_algorithm

;)

[Issue 16698] std.regex.matchFirst corrupts stack

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from ag0ae...@gmail.com ---
Issue 16699 has been fixed and the code here works as expected now. I don't
think we need to add the regex code to the test suite (feel free to do that,
though). Closing as duplicate of 16699.

*** This issue has been marked as a duplicate of issue 16699 ***

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #9 from ag0ae...@gmail.com ---
*** Issue 16698 has been marked as a duplicate of this issue. ***

--

Re: A simplification of the RvalueRef idiom

[Guillaume Piolat via Digitalmars-d-learn]

On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:


Let me know if it's not the equivalent of the original.

Ali


I've changed the idiom, thanks. The place to discuss this is the 
d-idioms bugtracker, else I would have skipped this message.

Re: Char representation

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 22, 2016 13:29:47 RazvanN via Digitalmars-d-learn 
wrote:
> Given the following code:
>
>   char[5] a = ['a', 'b', 'c', 'd', 'e'];
>   alias Range = char[];
>   writeln(is(ElementType!Range == char));
>
> One would expect that the program will print true. In fact, it
> prints false and I noticed that if Range is char[], wchar[],
> dchar[], string, wstring, dstring
> Unqual!(ElementType!Range) is dchar. I find it odd that the
> internal representation for char and string is dchar. Is this a
> bug?

You misunderstand. char[] is a dynamic array of char, wchar[] is a dynamic
array of wchar[], and dchar[] is a dynamic array of dchar. There is nothing
funny going on with the internal representation. Rather, the problem is with
the range API and the traits that go with it. And it's not a bug; it's a
design mistake.

I don't know how much you know about Unicode, but for a quick explanation,
you have code units, code points, and graphemes. A grapheme is made up of
one or more code points, and  a code point is made up of one or more code
units. In the case of UTF-8, a code unit is 8 bits; in UTF-16, a code unit
is 16 bits; and in UTF-32, a code unit is 32 bits. Those are represented in
D by char, wchar, dchar respectively. There is no guarantee that a char,
wchar, or dchar is a representable character. A code unit is just a piece of
a character except in the cases where it happens to be a full character. :|

A code point, on the other hand, actually makes up something composable and
printable. It's something like the letter A, or é, or, の, etc. It could
also be an accent, a superscript, subscript, etc. In the case of UTF-8 and
UTF-16, it can take several code units to form a single code point. In the
case of UTF-32, a single code unit is always a code point, because code
points take up 32 bits.

However, that's still not necessarily a full character. After all, an accent
or a superscript is not really a character. Rather, it's a modifier for a
character. So, one or more code points can be combined to form graphemes
which _are_ actual characters. Unfortunately, there are several
normalization schemes for the order of code points in a grapheme, and some
graphemes can be represented as a single code point or as several (most
notably, the characters which commonly have accents on them such as é come
both as single code points and as combined code points). So, this whole
thing gets stupidly complicated. It's even worse when you want to handle it
all _efficiently_.

Well, when Andrei added ranges to D, he tried to simplify things so that the
default was correct and reasonably efficient while allowing for code to
specialize where appropriate to get the full efficiency. That's a noble
goal, but unfortunately, he didn't know about graphemes at the time. He
thought that code points were guaranteed to be full characters and that if
you operated at the code point level, you were guaranteed full correctness.
So, in order to avoid errors related to chopping up strings of char or wchar
in the middle of code points, he came up with the concept of "narrow"
strings - i.e. strings which are made up of char or wchar rather than dchar
(so strings where each code unit is not guaranteed to be a code point), and
he restricted what narrow strings could do by default per the range API and
its associated traits. So, we get fun like this.

assert(!hasLength!string);
assert(!hasLength!wstring);
assert(hasLength!dstring);

assert(!isRandomAccessRange!string);
assert(!isRandomAccessRange!wstring);
assert(isRandomAccessRange!dstring);

assert(is(ElementType!string == dchar));
assert(is(ElementType!wstring == dchar));
assert(is(ElementType!dstring == dchar));

And front, popFront, back, and popBack all automatically decode the code
units in a string to code points. So, front and back both return dchar even
if the string is a string of char or wchar. The arrays themselves do not
change. However, the way that the traits in std.range.primitives treat them
is then fundamentally different from how the language treats them. So, even
though

string str = "hello world";
for(auto r = str; !r.empty; r.popFront())
{
auto e = range.front;
}

will iterate by dchar

string str = "hello world";
foreach(e; str)
{
}

will iterate by char. If you want it to iterate by dchar, then you make it
explicit.

string str = "hello world";
foreach(dchar e; str)
{
}

The result of all of this is that by default, when you treat strings as
ranges, you operate at the code point level. This avoids certain bugs where
code would otherwise chop up code points by operating on code units, but
since it doesn't actually go to the grapheme level, it still isn't actually
correct, and it's easier to miss the fact that it's wrong, since more cases
work. It's also inefficient, because the code units are always decoded to
code points regardless of whether the algorithm in question actually needs
to do that or not. It also creates confusion and questions like yours.

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

Lucia Cojocaru  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com

--

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

Lucia Cojocaru  changed:

   What|Removed |Added

  Component|druntime|dmd

--

[Issue 5995] string append negative integer causes segfault

[via Digitalmars-d-bugs]

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

Lucia Cojocaru  changed:

   What|Removed |Added

 CC||lucia.mcojoc...@gmail.com

--- Comment #14 from Lucia Cojocaru  ---
This is a problem in the compiler.

https://github.com/dlang/dmd/blob/master/src/dcast.d#L66
https://github.com/dlang/dmd/blob/master/src/mtype.d#L4150

I will open a PR shortly to disable implicit cast of int -> dchar.
Should we disable the implicit cast of all integral types to chars? For
example, is it expected to make an implicit cast from uint to dchar?

(The compiler itself seems to rely on implicit casts of unit -> dchar.
Compiling the compiler with this cast disabled produces some errors.)


This is also enabled: bool -> dchar. Not sure if it is desirable.
Expression.implicitCastTo(z of type bool) => dchar

--

[Issue 13927] optimizer hangs in optelem with SIMD initialization

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull
   Severity|normal  |major

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

--

Re: Get return type of a template function without instantiating it

[Meta via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 12:21:18 UTC, Yuxuan Shui wrote:
Is there a way to get a template function return type with 
instantiating it? The return type is independent of the 
template arguments.


I'm asking because there's potentially recursive template 
instantiation if I do try to instantiate it.


What you want cannot work in the general case. The template 
function must be instantiated.


T identity(T)(T t)
{
return t;
}

It's not possible to calculate the type of the return value of 
`identity` until it is instantiated with a type.

Re: A simplification of the RvalueRef idiom

[Namespace via Digitalmars-d-learn]

On Tuesday, 22 November 2016 at 13:06:27 UTC, Nordlöw wrote:

On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:
mixin template RvalueRef()// <-- DOES NOT TAKE A PARAMETER 
ANY MORE

{
alias T = typeof(this);
static assert (is(T == struct));

@nogc @safe
ref const(T) byRef() const pure nothrow return


Why do you need to qualify `byRef` as pure nothrow when it's a 
template?


No need for these, but I did it out of habit ;)

Re: A simplification of the RvalueRef idiom

[Nordlöw via Digitalmars-d-learn]

On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:

ref const(T) byRef() const pure nothrow return


Add when DIP-1000 has been implemented into compiler this should 
be `scope`-qualified aswell, right?

Re: Char representation

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

On Tuesday, 22 November 2016 at 13:29:47 UTC, RazvanN wrote:

Is this a bug?


The language is sane. The standard library is not alas, it is 
insane by design, so not a bug.