[Issue 15849] New: change in std.ui test leads to magic linking error for d_do_test

[via Digitalmars-d-bugs]

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

  Issue ID: 15849
   Summary: change in std.ui test leads to magic linking error for
d_do_test
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

How to reproduce?

```
git remote add greenify git://github.com:greenify/phobos.git
git fetch greenify
git checkout --track greenify/examples_to_unittest5
```

Now rebuild Phobos and run in dmd

```
make -f posix.mak clean && make -f posix.mak auto-tester-build && make -f
posix.mak auto-tester-test
```

It will result a long error (see below).
The line that toggles the error is 

```
assert(set.byInterval.equal([tuple('A','E'), tuple('a','e')]));
```

It is in a unittest, so it shouldn't affect any script.
Running all tests in Phobos works fine.
It is reproducible on all platforms of autotester. See also the regarding PR:
https://github.com/D-Programming-Language/phobos/pull/4049

```
make -C test -f Makefile
make[1]: Entering directory '/home/xsebi/projects/dlang/dmd/test'
Creating output directory: test_results
Building d_do_test tool
OS: linux
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T6ParserTAyaZ6Parser11charsetToIrMFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZv:
error: undefined reference to
'_D3std5regex8internal2ir10getMatcherFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T6ParserTAyaZ6Parser11charsetToIrMFNeS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZv:
error: undefined reference to '_D3std5regex8internal2ir11CharMatcher6__initZ'
d_do_test.o:d_do_test.d:_D45TypeInfo_S3std5regex8internal2ir11CharMatcher6__initZ:
error: undefined reference to
'_D3std5regex8internal2ir11CharMatcher9__xtoHashFNbNeKxS3std5regex8internal2ir11CharMatcherZm'
d_do_test.o:d_do_test.d:_D45TypeInfo_S3std5regex8internal2ir11CharMatcher6__initZ:
error: undefined reference to
'_D3std5regex8internal2ir11CharMatcher11__xopEqualsFKxS3std5regex8internal2ir11CharMatcherKxS3std5regex8internal2ir11CharMatcherZb'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal6parser15__T8optimizeTaZ8optimizeFKS3std5regex8internal2ir12__T5RegexTaZ5RegexZv:
error: undefined reference to
'_D3std5regex8internal2ir8BitTable6__ctorMFNcS3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionListZS3std5regex8internal2ir8BitTable'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function
_D3std5regex8internal8thompson260__T11ThompsonOpsTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherTS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateHVbi1Z39__T2opHVE3std5regex8internal2ir2IRi164Z2opFNePS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcherPS3std5regex8internal8thompson67__T15ThompsonMatcherTaTS3std5regex8internal2ir12__T5InputTaZ5InputZ15ThompsonMatcher5StateZb:
error: undefined reference to
'_D3std5regex8internal2ir11wordMatcherFNdZS3std5regex8internal2ir11CharMatcher'
d_do_test.o:d_do_test.d:function

Re: char array weirdness

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

On Tue, Mar 29, 2016 at 08:05:29PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]
> Phobos treats narrow strings (wchar[], char[]) as ranges of dchar. It
> was discovered that auto decoding strings isn't always the smartest
> thing to do, especially for performance.
> 
> So you get things like this: 
> https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/searching.d#L1622
> 
> That's right. Phobos insists that auto decoding must happen for narrow
> strings. Except that's not the best thing to do so it inserts lots of
> exceptions -- for narrow strings.
> 
> Mind blown?
[...]

Mind not blown. Mostly because I've seen many, many instances of similar
code in Phobos. It's what I was alluding to when I said that
special-casing strings has caused a ripple of exceptional cases to
percolate throughout Phobos, increasing code complexity and making
things very hard to maintain.  I mean, honestly, just look at that code
as linked above.  Can anyone honestly claim that this is maintainable
code?  For something so trivial as linear search of strings, that's some
heavy hackery just to make strings work, as contrasted with, say, the
one-line call to simpleMindedFind(). Who would have thought linear
string searching would require a typecast, a @trusted hack, and
templates named "force" just to make things work?

It's code like this -- and its pervasive ugliness throughout Phobos --
that slowly eroded my original pro-autodecoding stance.  It's becoming
clearer and clearer to me that it's just not pulling its own weight
against the dramatic increase in Phobos code complexity, nevermind the
detrimental performance consequences.


T

-- 
Obviously, some things aren't very obvious.

Re: char array weirdness

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

On Wed, Mar 30, 2016 at 03:22:48AM +, Jack Stouffer via Digitalmars-d-learn 
wrote:
> On Tuesday, 29 March 2016 at 23:42:07 UTC, H. S. Teoh wrote:
> >Believe it or not, it was only last year (IIRC, maybe the year
> >before) that Walter "discovered" that Phobos does autodecoding, and
> >got pretty upset over it.  If even Walter wasn't aware of this for
> >that long...
> 
> The link (I think this is what you're referring to) to that
> discussion: http://forum.dlang.org/post/lfbg06$30kh$1...@digitalmars.com
> 
> It's a shame Walter never got his way. Special casing ranges like this
> is a huge mistake.

To be fair, one *could* make a case of autodecoding, if it was done
right, i.e., segmenting by graphemes, which is what is really expected
by users when they think of "characters". This would allow users to
truly think in terms of characters (in the intuitive sense) when they
work with strings. However, segmenting by graphemes is, in general,
quite expensive, and few algorithms actually need to do this. Most don't
need to -- a pretty large part of string processing consists of looking
for certain markers, mostly punctuation and control characters, and
treating the stuff in between as opaque data. If we didn't have
autodecoding, would be a simple matter of searching for sentinel
substrings.  This also indicates that most of the work done by
autodecoding is unnecessary -- it's wasted work since most of the string
data is treated opaquely anyway.

The unfortunate situation in Phobos currently is that we are neither
doing it right (segmenting by graphemes), *and* we're inefficient
because we're constantly decoding all that data that the application is
mostly going to treat as opaque data anyway.  It's the worst of both
worlds.

I wish we could get consensus for implementing Walter's plan to phase
out autodecoding (as proposed in the linked thread above).


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

[Issue 15179] Local imports cause outer imports to be excluded from overload set

[via Digitalmars-d-bugs]

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

--- Comment #8 from Jesse Phillips  ---
(In reply to Steven Schveighoffer from comment #7)
> (In reply to Jesse Phillips from comment #6)
> > That doesn't solve the highjacking, Walter has made a big point about D's
> > anti-highjacking feature.
> 
> Yes, it does. Selective imports override any non-selective import because
> it's aliased into the local namespace.

It does not. Since I wrote code where selective imports was not necessary, an
update to a second library being used hijacked my call and the compiler gave no
warning. That is the hijack problem, the fact that I can modify my code to use
the desired function is not relevant to how the compiler is supposed to help
prevent hijacking: http://dlang.org/hijack.html

--

Re: char array weirdness

[Jack Stouffer via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 23:42:07 UTC, H. S. Teoh wrote:
Believe it or not, it was only last year (IIRC, maybe the year 
before) that Walter "discovered" that Phobos does autodecoding, 
and got pretty upset over it.  If even Walter wasn't aware of 
this for that long...


The link (I think this is what you're referring to) to that 
discussion: 
http://forum.dlang.org/post/lfbg06$30kh$1...@digitalmars.com


It's a shame Walter never got his way. Special casing ranges like 
this is a huge mistake.

Re: Blog article on new import changes

[xenon325 via Digitalmars-d-announce]

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:
I anticipate 2.071.0 is going to cause a lot of deprecation 
messages and strange errors to occur, due to the fixes of very 
long-standing import bugs.


I wrote a blog post (actually my first ever) on this, let me 
know what you think (and please, any clarifications/errors, let 
me know):


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


1.
In addition, importing a module using static, renamed, or 
selective imports, then the module was imported publicly, even 
though it was supposed to be private.


Not an English speaker, but this doesn't sound right (at least 
stylistically).
Reread it several times, but I couldn't get the meaning of the 
sentence, until opened bug report.


2.
With 2.070.2 and prior versions, compiling this works just 
fine. With 2.071.0 and above, you will get either a deprecation 
warning, or an error.


With 2.070.2, this compiled just fine. [...] With 2.071.0 and 
above, this will trigger a deprecation warning. In the future, 
the code will trigger an error.


In 2.070.2, this produces no warning or error. In 2.071.0 and 
beyond, this will produce a deprecation warning, and eventually 
an error.


Not sure if it's worth it to repeat after each example. Feels 
redundant.


3. I think it's OK to write just major compiler versions, no need 
for patch version: 2.070 and 2.071

Re: Part of D available to run at compile time

[rikki cattermole via Digitalmars-d-learn]

On 30/03/2016 11:29 AM, Carl Sturtivant wrote:


is there documentation on which parts of D are available to compile time
execution?


Rule of thumb, if it can be pure and @safe, you're good to go.

Re: I need some help benchmarking SoA vs AoS

[maik klein via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 21:27:15 UTC, ZombineDev wrote:

On Saturday, 26 March 2016 at 17:43:48 UTC, maik klein wrote:

On Saturday, 26 March 2016 at 17:06:39 UTC, ag0aep6g wrote:

On 26.03.2016 18:04, ag0aep6g wrote:

https://gist.github.com/aG0aep6G/a1b87df1ac5930870ffe/revisions


PS: Those enforces are for a size of 100_000 not 1_000_000, 
because I'm impatient.


Thanks, okay that gives me more more reliable results.
for 1_000_000

benchmarking complete access
AoS: 1 sec, 87 ms, 266 μs, and 4 hnsecs
SoA: 1 sec, 491 ms, 186 μs, and 6 hnsecs
benchmarking partial access
AoS: 7 secs, 167 ms, 635 μs, and 8 hnsecs
SoA: 1 sec, 20 ms, 573 μs, and 1 hnsec

This is sort of what I expected. I will do a few more 
benchmarks now. I probably also randomize the inputs.


Can you benchmark my implementation 
(http://dpaste.dzfl.pl/3de1e18756f8) against yours? It should 
have roughly the same API, except that mine doesn't support 
pre-allocation (reserving capacity) - I wanted to keep it 
minimalistic.
During access it should have the same performance, however the 
insertion behavior should be noticeably different. I'm 
interested to see if one larger allocation on insertion would 
be faster than a number of small ones (or vice-versa). Though, 
AoS should be the fastest in this regard (growth performance).


Yes I'll do it tomorrow, though I am not sure how much you can 
rely on the data. I think it really depends on how fragmented the 
heap currently is.


I will also benchmark memory access, just to see if there is any 
difference. I recently asked a question about it on SO 
https://stackoverflow.com/questions/36296960/pros-and-cons-of-one-big-buffer-vs-many-smaller-buffer?


Doesn't seem to be well received though.

Re: key in aa.keys, but aa[key] give range violation?

[Ali Çehreli via Digitalmars-d-learn]

On 03/29/2016 05:29 PM, Yuxuan Shui wrote:

On Wednesday, 30 March 2016 at 00:26:49 UTC, Yuxuan Shui wrote:

My code looks something like this:

bool[ulong][ulong] edge;
foreach(u; from)
foreach(v; to_)
edge[u][v] = true;
foreach(u; edge.keys) {
auto adj = edge[u];
//
}

And sometimes edge[u] would give Range violation error.


I guess I'm not supposed to do aa.remove() while iterate through it?


That was my first guess. No, you cannot mutate the container itself 
while iterating over it.


However, the sample that you've shown should be fine as edge.keys is an 
eagerly generated array of keys. In that case, you can remove from the 
aa. Perhaps your actual code is different?


Ali

Re: key in aa.keys, but aa[key] give range violation?

[Yuxuan Shui via Digitalmars-d-learn]

On Wednesday, 30 March 2016 at 00:26:49 UTC, Yuxuan Shui wrote:

My code looks something like this:

bool[ulong][ulong] edge;
foreach(u; from)
foreach(v; to_)
edge[u][v] = true;
foreach(u; edge.keys) {
auto adj = edge[u];
//
}

And sometimes edge[u] would give Range violation error.


I guess I'm not supposed to do aa.remove() while iterate through 
it?

Re: char array weirdness

[Basile B. via Digitalmars-d-learn]

On Wednesday, 30 March 2016 at 00:05:29 UTC, Steven Schveighoffer 
wrote:

On 3/29/16 7:42 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Tue, Mar 29, 2016 at 11:15:26PM +, Basile B. via 
Digitalmars-d-learn wrote:

On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:

void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 
's'];

pragma(msg, ElementEncodingType!(typeof(val)));
pragma(msg, typeof(val.front));
}

prints

char
dchar

Why?


I've seen you so many time as a reviewer on dlang that I 
belive this Q

is a joke.
Even if obviously nobody can know everything...

https://www.youtube.com/watch?v=l97MxTx0nzs

seriously you didn't know that auto decoding is on and that 
it gives

you a dchar...


Believe it or not, it was only last year (IIRC, maybe the year 
before)
that Walter "discovered" that Phobos does autodecoding, and 
got pretty
upset over it.  If even Walter wasn't aware of this for that 
long...


Phobos treats narrow strings (wchar[], char[]) as ranges of 
dchar. It was discovered that auto decoding strings isn't 
always the smartest thing to do, especially for performance.


So you get things like this: 
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/searching.d#L1622


That's right. Phobos insists that auto decoding must happen for 
narrow strings. Except that's not the best thing to do so it 
inserts lots of exceptions -- for narrow strings.


Mind blown?

-Steve


https://www.youtube.com/watch?v=JKQwgpaLR6o

Listen to this then it'll be more clear.

key in aa.keys, but aa[key] give range violation?

[Yuxuan Shui via Digitalmars-d-learn]

My code looks something like this:

bool[ulong][ulong] edge;
foreach(u; from)
foreach(v; to_)
edge[u][v] = true;
foreach(u; edge.keys) {
auto adj = edge[u];
//
}

And sometimes edge[u] would give Range violation error.

Re: char array weirdness

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/29/16 7:42 PM, H. S. Teoh via Digitalmars-d-learn wrote:

On Tue, Mar 29, 2016 at 11:15:26PM +, Basile B. via Digitalmars-d-learn 
wrote:

On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:

void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
pragma(msg, ElementEncodingType!(typeof(val)));
pragma(msg, typeof(val.front));
}

prints

char
dchar

Why?


I've seen you so many time as a reviewer on dlang that I belive this Q
is a joke.
Even if obviously nobody can know everything...

https://www.youtube.com/watch?v=l97MxTx0nzs

seriously you didn't know that auto decoding is on and that it gives
you a dchar...


Believe it or not, it was only last year (IIRC, maybe the year before)
that Walter "discovered" that Phobos does autodecoding, and got pretty
upset over it.  If even Walter wasn't aware of this for that long...


Phobos treats narrow strings (wchar[], char[]) as ranges of dchar. It 
was discovered that auto decoding strings isn't always the smartest 
thing to do, especially for performance.


So you get things like this: 
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/searching.d#L1622


That's right. Phobos insists that auto decoding must happen for narrow 
strings. Except that's not the best thing to do so it inserts lots of 
exceptions -- for narrow strings.


Mind blown?

-Steve

Re: Categorization of warnings

[tsbockman via Digitalmars-d]

On Monday, 28 March 2016 at 16:21:15 UTC, Johan Engelen wrote:
I just submitted a PR [1] that catagorizes warnings, such that 
you can do something like this:

dmd -w -Wno-not-reachable
which would error on any warning except the "statement not 
reachable" warnings (it completely disables that warning).


The motivation for the selective disabling/enabling of warnings 
was a recent discussion in the Learn forum [2].


Please read about it in detail in the first message of the PR 
[1].


- Johan

[1]  https://github.com/D-Programming-Language/dmd/pull/5592
[2]  
http://forum.dlang.org/thread/baupegcfvumouhgau...@forum.dlang.org


I think categorizing warnings could be useful, but must point out 
that for the "statement not reachable" problem (DMD 14835), 
specifically, this is not really a good long term solution.


The reason is that Phobos itself contains many statements which 
are "not reachable" according to the compiler's current flawed 
definition. (They aren't detected as such only because the 
constant folding and value range propagation capabilities are 
rather weak currently.)


If Phobos requires a -Wno-not-reachable switch to compile, then 
anything that uses Phobos will likely require the switch, also. 
At that point, it makes more sense to just fix/remove the 
warning, rather than selectively disabling it for some projects.

Re: debugger blues

[Marco Leise via Digitalmars-d]

Am Mon, 28 Mar 2016 19:29:38 +
schrieb cy :

> On Sunday, 27 March 2016 at 15:40:47 UTC, Marco Leise wrote:
> > Is it just me? I've never heard of a programming environment, 
> > let alone a system programming language providing that 
> > information.
> 
> Well, not by default certainly. It is a bit pie-in-the-sky […].

At first you framed it like it was something to be expected in
a PL. As a pie-in-the-sky for DMD on the other hand I agree
with you. Maybe it is enough that GDC provides this feature.
Or maybe you could turn the idea into a DIP (with GCC as the
reference implementation) so eventually DMD and LDC can provide
this as well.

> > "DOESN'T LET YOU PUT SPACES BETWEEN THE ARGUMENTS" is just 
> > silly and factually wrong.
> 
> No, it's factually true. You can provide arguments that have 
> spaces in them, but there is no way to put spaces between the 
> arguments to your logging function. I would expect that the 
> logger would be called with the arguments provided, but instead 
> the logging code uses a private function to stringify and 
> concatenate all the arguments, and provides it to the logger as 
> one single opaque string. This is certainly something that could 
> be improved.

It is straightforward to put spaces between arguments:
warningf("%s %s %s", "puts", "spaces", "inbetween");

If you refer to the common headers that go before each
message, those are indeed not configurable for existing Logger
implementations. Swapping them out is not complicated though:

import std.experimental.logger;
import std.stdio;

stdThreadLocalLog = new class FileLogger
{
this() { super(stderr, LogLevel.all); }

override protected void beginLogMsg(
string file, int line, string
funcName, string prettyFuncName,
string moduleName, LogLevel logLevel,
Tid threadId, SysTime timestamp,
Logger logger)
{
import std.string : lastIndexOf;
auto idx1 = file.lastIndexOf('/');
auto idx2 = funcName.lastIndexOf('.');
formattedWrite(this.file.lockingTextWriter(),
"%s %s %s %u ", timestamp,
file[idx1 + 1 .. $],
funcName[idx2 + 1 .. $], line);
}
};

warningf("%s", "<- the header now has spaces instead of ':' in it");

You could also make 'beginLogMsg' call a user provided
delegate for formatting to freely change the looks at runtime.
 
> What I did was write my own logging framework, that joins 
> arguments with spaces in between, and provides that as a single 
> argument to std.experimental.logging. But that requires me to 
> duplicate all the template boilerplate (func = __func__, file = 
> __file__, line = __line__ etc) so all the code in 
> std.experimental.logging to do that can't be used, reducing 
> std.experimental.logging to basically nothing other than writeln.

WTF? :p
If you wonder why some feature is not provided in the default
implementation, the answer is likely that Logger was meant to
be as light-weight as possible with the option to completely
carve it out and re-implement it. For example, if the header
could be formatted with a format string, "%s" would have been
the only option for the time stamp.

> > If you ask for a *guarantee* of no copy on struct return, then 
> > you are right.
> 
> I wish I was right. There are still some gotchas there, that I 
> don't fully understand. Things like:
> > BigStruct ret = returnsBigStructToo();
> 
> look the same as things like:
> > BigStruct ret = returnedbigstruct;
> 
> but the latter is actually a copy. D making paretheses optional 
> for properties makes it even more confusing.
> 
> > A a = b.myA // copy or emplacement?

I believe the idea is that to copy or not to copy a struct is
just an optimization step and in cases where this strictly
must not happen @disable this(this); catches all code that
would need to perform a copy to work. Maybe you can return
your structs by reference or pointer? It is hard to tell
without seeing the code, how it could be refactored with
Dlang's design choices in mind.

> But even taking that into account, I've had mysterious situations 
> where the pointer to a returned structure changed, from within 
> the function to without, without any apparant copying going on.

Be assured that if that happens without this(this) being
called, it is worth a bug report.

Re: char array weirdness

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

On Tue, Mar 29, 2016 at 11:15:26PM +, Basile B. via Digitalmars-d-learn 
wrote:
> On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:
> >void main () {
> >import std.range.primitives;
> >char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
> >pragma(msg, ElementEncodingType!(typeof(val)));
> >pragma(msg, typeof(val.front));
> >}
> >
> >prints
> >
> >char
> >dchar
> >
> >Why?
> 
> I've seen you so many time as a reviewer on dlang that I belive this Q
> is a joke.
> Even if obviously nobody can know everything...
> 
> https://www.youtube.com/watch?v=l97MxTx0nzs
> 
> seriously you didn't know that auto decoding is on and that it gives
> you a dchar...

Believe it or not, it was only last year (IIRC, maybe the year before)
that Walter "discovered" that Phobos does autodecoding, and got pretty
upset over it.  If even Walter wasn't aware of this for that long...

I used to be in favor of autodecoding, but more and more, I'm seeing
that it was a bad choice.  It's a special case to how ranges normally
work, and this special case has caused a ripple of exceptional corner
cases to percolate throughout all Phobos code, leaving behind a
string(!) of bugs over the years that, certainly, eventually got
addressed, but nevertheless it shows that something didn't quite fit in.
It also left behind a trail of additional complexity to deal with these
special cases that made Phobos harder to understand and maintain.

It's a performance bottleneck for string-processing code, which is a
pity because D could have stood the chance to win against C/C++ string
processing (due to extensive need to call strlen and strdup). But in
spite of this heavy price we *still* don't guarantee correctness. On the
spectrum of speed (don't decode at all) vs. correctness (segment by
graphemes, not by code units or code points) autodecoding lands in the
anemic middle where you get neither speed nor full correctness.

The saddest part of it all is that this is unlikely to change because
people have gotten so uptight about the specter of breaking existing
code, in spite of the repeated experiences of newbies (and
not-so-newbies like Walter himself!) wondering why strings have
ElementType == dchar instead of char, usually followed by concerns over
the performance overhead.


T

-- 
Designer clothes: how to cover less by paying more.

Debugging D DLL from C# app with C linkage for native Unity 5 plugin

[Thalamus via Digitalmars-d-learn]

Apologies if this has been discussed before, but I wasn't able to 
find anything similar on the forums or web. I can't seem to 
figure out how to debug a D DLL from a C# EXE. (My actual purpose 
here is to use D to build native plugins for Unity 5, but Unity 
and Mono aren't necessary to repro the problem I'm running into.)


The D DLL and C# are both built as 64-bit. (C# is not set to 
AnyCPU). Using VS 2015 and Visual D, I can drive the D DLL from 
the C# EXE without any problems, but the debugger doesn't load 
the D DLL symbols. The DLL and PDB are in the same folder as the 
C# EXE. Everything behaves the same if I link to the DLL 
statically using P/Invoke or dynamically using LoadLibrary.


Everything from the D DLL is exposed as extern(C), listed in the 
.def, etc. When I drive the DLL from a D EXE, I can break into 
the debugger easily, whether I attach at launch or attach to the 
process when it's already running.


I'm building the DLL using:

dmd  dllmain.d dll.def -w -wi -g 
-map -ofLogic.dll  -m64 
-debug -shared


Anyone know what I should try next? Am I missing something 
simple? :)


thanks!
Thalamus

Re: char array weirdness

[Jack Stouffer via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 23:15:26 UTC, Basile B. wrote:
I've seen you so many time as a reviewer on dlang that I belive 
this Q is a joke.

Even if obviously nobody can know everything...

https://www.youtube.com/watch?v=l97MxTx0nzs

seriously you didn't know that auto decoding is on and that it 
gives you a dchar...


It's not a joke. This is the first time I've run into this 
problem in my code. I just started using D more and more in my 
work and I've never written anything that was really string heavy.

Re: char array weirdness

[Basile B. via Digitalmars-d-learn]

On Monday, 28 March 2016 at 22:34:31 UTC, Jack Stouffer wrote:

void main () {
import std.range.primitives;
char[] val = ['1', '0', 'h', '3', '6', 'm', '2', '8', 's'];
pragma(msg, ElementEncodingType!(typeof(val)));
pragma(msg, typeof(val.front));
}

prints

char
dchar

Why?


I've seen you so many time as a reviewer on dlang that I belive 
this Q is a joke.

Even if obviously nobody can know everything...

https://www.youtube.com/watch?v=l97MxTx0nzs

seriously you didn't know that auto decoding is on and that it 
gives you a dchar...

Re: How to be more careful about null pointers?

[QAston via Digitalmars-d-learn]

On Monday, 28 March 2016 at 21:01:19 UTC, cy wrote:
I finally found the null pointer. It took a week. I was 
assigning "db = db" when I should have been assigning "this.db 
= db". Terrible, I know. But...


I invoked db.find_chapter.bindAll(8,4), when db was a null 
pointer. There was no null pointer error. No exception raised 
for dereferencing a null. I'm not in release mode. Assertions 
are enabled. Shouldn't that have raised a null pointer 
exception?


Instead, it accesses db as if db were not null, producing a 
garbage structure in find_chapter, which bindAll chokes on, 
then causes the whole program to segfault.


I realize enforce(db).find_chapter would work, but... I thought 
D was more careful about null pointers? At least enough to die 
on dereferencing them?


You can use a lint to warn you about silly mistakes, check out 
dscanner and possibly others.

Re: Part of D available to run at compile time

[Ali Çehreli via Digitalmars-d-learn]

On 03/29/2016 03:29 PM, Carl Sturtivant wrote:


is there documentation on which parts of D are available to compile time
execution?



This seems to be the official spec:

  https://dlang.org/spec/function.html#interpretation

See you at DConf! ;)

Ali

Part of D available to run at compile time

[Carl Sturtivant via Digitalmars-d-learn]

is there documentation on which parts of D are available to 
compile time execution?

Re: char array weirdness

[Marco Leise via Digitalmars-d-learn]

Am Mon, 28 Mar 2016 16:29:50 -0700
schrieb "H. S. Teoh via Digitalmars-d-learn"
:

> […] your diacritics may get randomly reattached to
> stuff they weren't originally attached to, or you may end up with wrong
> sequences of Unicode code points (e.g. diacritics not attached to any
> grapheme). Using filter() on Korean text, even with autodecoding, will
> pretty much produce garbage. And so on.

I'm on the same page here. If it ain't ASCII parsable, you
*have* to make a conscious decision about whether you need
code units or graphemes. I've yet to find out about the use
cases for auto-decoded code-points though.

> So in short, we're paying a performance cost for something that's only
> arguably better but still not quite there, and this cost is attached to
> almost *everything* you do with strings, regardless of whether you need
> to (e.g., when you know you're dealing with pure ASCII data).

An unconscious decision made by the library that yields the
least likely intended and expected result? Let me think ...
mhhh ... that's worse than iterating by char. No talking
back :p.

-- 
Marco

[Issue 15839] this.outer is of wrong type

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #6 from Martin Nowak  ---
(In reply to Kenji Hara from comment #4)
> Note that, compiler cannot determine whether the start() makes a closure
> environment or not at the place where 'this.outer' is used. Because of that,
> the .outer property should have void* type, to be consistent with the
> lexical scope nesting.

But this.outer always refers to the enclosing function even if no closure is
required, right? A this.outer that is typed as void* and either refers to an
enclosing function or an enclosing class would be highly confusing.

--

[Issue 15500] default construction disabled for struct constructor with default arguments

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||wiko...@gmail.com

--- Comment #8 from Martin Nowak  ---
*** Issue 15551 has been marked as a duplicate of this issue. ***

--

[Issue 15551] default construction disabled with default arguments

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Nowak  ---


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

--

[Issue 15845] Windows console cannot read properly UTF-8 lines

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0ae...@gmail.com ---
For -m32 (DIGITAL_MARS_STDIO) it seems to come down to this (with `chcp 65001`
in the console):


import std.stdio;

void main()
{
FILE* fps = core.stdc.stdio.stdin;
FLOCK(fps);
scope(exit) FUNLOCK(fps);

auto fp = cast(_iobuf*)fps;
assert(!(__fhnd_info[fp._file] & FHND_WCHAR)); /* passes; no wide
characters */
assert(!(fp._flag & _IOTRAN)); /* passes; no translated mode */

int c = FGETC(fp);
assert(c != -1); /* passes with 'a'; fails with 'ä' */
}


That is, Digital Mars's FGETC (_fgetc_nlock) returns -1 for non-ASCII
characters.

The issue does not manifest with a pipe: `echo ä | test` works.

--

Re: Joining AliasSeq/TypeTuple s

[Ali Çehreli via Digitalmars-d-learn]

On 03/29/2016 02:33 AM, Voitech wrote:

Hi, i want to join two or more tupples in to one, with mixing the
indexes like roundRobin but in compile time.

unittest{
import std.meta;
alias first=AliasSeq!(int, string,bool);
alias second=AliasSeq!("abc","def","ghi");
alias third=...

static assert(third==AliasSeq!(int, "abc", string, "def", bool, "ghi"));
}


Just a reminder that if you needed to concatenate, then it would be 
trivial due to automatic expansion of AliasSeq elements:


alias third = AliasSeq!(first, second);

Ali

Re: I need some help benchmarking SoA vs AoS

[ZombineDev via Digitalmars-d-learn]

On Saturday, 26 March 2016 at 17:43:48 UTC, maik klein wrote:

On Saturday, 26 March 2016 at 17:06:39 UTC, ag0aep6g wrote:

On 26.03.2016 18:04, ag0aep6g wrote:

https://gist.github.com/aG0aep6G/a1b87df1ac5930870ffe/revisions


PS: Those enforces are for a size of 100_000 not 1_000_000, 
because I'm impatient.


Thanks, okay that gives me more more reliable results.
for 1_000_000

benchmarking complete access
AoS: 1 sec, 87 ms, 266 μs, and 4 hnsecs
SoA: 1 sec, 491 ms, 186 μs, and 6 hnsecs
benchmarking partial access
AoS: 7 secs, 167 ms, 635 μs, and 8 hnsecs
SoA: 1 sec, 20 ms, 573 μs, and 1 hnsec

This is sort of what I expected. I will do a few more 
benchmarks now. I probably also randomize the inputs.


Can you benchmark my implementation 
(http://dpaste.dzfl.pl/3de1e18756f8) against yours? It should 
have roughly the same API, except that mine doesn't support 
pre-allocation (reserving capacity) - I wanted to keep it 
minimalistic.
During access it should have the same performance, however the 
insertion behavior should be noticeably different. I'm interested 
to see if one larger allocation on insertion would be faster than 
a number of small ones (or vice-versa). Though, AoS should be the 
fastest in this regard (growth performance).

Re: How to be more careful about null pointers?

[Marco Leise via Digitalmars-d-learn]

Am Tue, 29 Mar 2016 06:00:32 +
schrieb cy :

> struct Database {
>string derp;
>Statement prepare(string s) {
>   return Statement(1234);
>}
> }
> 
> struct Statement {
>int member;
>void bind(int column, int value) {
>   import std.stdio;
>   writeln("derp",member);
>}
> 
> }
> 
> 
> class Wrapper {
>Database something;
>Statement prep;
>this() {
>  something = Database("...");
>  prep = something.prepare("...");
>}
> }
> 
> Wrapper oops;
> void initialize() {
>oops = new Wrapper();
> }
> 
> class Entry {
>Wrapper parent;
>this(Wrapper parent) {
>  //this.parent = parent;
>  //oops
>  parent = parent;
>}
>void usefulmethod() {
>  parent.prep.bind(1,42);
>  //parent.prep.execute();
>  //parent.prep.reset();
>}
> }
> 
> void main() {
>initialize();
>auto entry = new Entry(oops);
>entry.usefulmethod();
> }
> 
> That program causes a segmentation fault on my machine. Somehow 
> despite never initializing Entry.parent, a class object (whose 
> default init is a null pointer), I can still call methods on it, 
> access members on it, and call methods on those members. No 
> warnings or errors. The segfault doesn't happen until the bind() 
> method.

Dlang aborts programs that run into invalid states. Common
invalid states are failing contract assertions, out of memory
conditions or in this case a null-pointer dereference.

When designing Dlang, Walter decided that null pointers don't
require checks as the operating system will eventually abort
the program and debuggers are designed to assist you in this
situation.

Some people with a different programming background feel that
a modern language should wrap every pointer access in a check
and possibly throw a recoverable Exception here or make
null-pointer opt-in to begin with. The topic is still open for
discussion:
http://wiki.dlang.org/Language_issues#Null_References

-- 
Marco

Re: Code coverage in Phobos

[Seb via Digitalmars-d]

On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
wrote:

On Monday, 28 March 2016 at 01:30:34 UTC, Seb wrote:
AFAIK dmd supports the `-cov` flag since quite some time, so I 
would be interested why there's no code coverage bot. There 
also seems to exist at least two external platforms that allow 
such code coverage analyzing [1, 2]. Is this already on your 
roadmap?


[1] https://github.com/codecov/example-d
[2] https://github.com/ColdenCullen/doveralls/issues/16

Anyways it seems pretty easy to hack something quick 
together that could be pretty helpful:


Yep. The difficulties are:

1. Getting data off the autotester. Currently it's nearly 
impossible, as is making any changes to it.


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

2. Collating data from multiple platforms, as there is a lot of 
platform-specific code in e.g. std.stdio, std.file, and most of 
Druntime.


Okay I see that for the long run we need a better way to handle 
the testing infrastructure :/


Can't we focus for the near future on getting a simple Phobos 
coverage tester that just compares the coverage of all files 
changes like your DAutoTest?
With this approach we can still prevent regression and show 
improvements.

Re: Code coverage in Phobos

[Walter Bright via Digitalmars-d]

On 3/29/2016 3:33 AM, Basile B. wrote:

Couldn't the coverage be done at compile time ?


The implementation for that would be utterly different.

Re: How to be more careful about null pointers?

[Ali Çehreli via Digitalmars-d-learn]

On 03/29/2016 11:57 AM, cy wrote:
> On Tuesday, 29 March 2016 at 06:21:49 UTC, Ali Çehreli wrote:
>> parent.prep.bind is translated to the following by the compiler:
>>
>> "Call bind() for the object at address... let's calculate... Wherever
>> parent is, we should add the offset of prep inside that object."
>
> Okay, that's helpful actually. So, when accessing members of an object,
> it won't trigger a NPE, because the object is not dereferenced
> immediately, but the expected offset to the member is dereferenced. D
> puts off resolving pointer addresses as much as possible, so instead of
> bind((*parent).(*prep)) it's more like bind(parentlocation + prepoffset)
> and only (this.)member resolves to (*(parentlocation + 
prepoffset).member).

>
> I thought it had an extra layer of pointer indirection, like if class
> object A has address 1234,

The class object would be sitting at that address. Our access to it is 
through a class variable:


Foo var = new Foo();

Although you don't see a pointer in sight, behind scenes 'var' is 
nothing but a pointer.


> and member A.b has offset 0x20, then you
> first dereference address 1234 (to get 4321 say) and then add 0x20 to
> that.

No, there is no dereferencing of 'var'. However, you could have 'Foo*', 
which would be the equivalent of a "pointer to  pointer" in C.


> But actually a class object is... already dereferenced, and is an
> integer representing the address to the object, not a pointer to that
> address.

Correct.

> Variables representing fixed, definite memory locations really throws me
> sometimes. You can't assign to a const, because that assigns to const
> marked memory

The object *may* really be on const-marked memory but not necessarily. 
You can have const variables anywhere; the const access is checked at 
compile time.


> and doesn't just move the variable somewhere else.

That does not happen for various reasons. Firstly, if we could mutate, 
what would 'const' mean? Then, the compiler would have to have a 
complete view of the program to update all other references, which would 
be slow and the semantics would be difficult.


> And
> NPE doesn't occur with a class, because setting it to NULL, and
> accessing a member is more like this in C:
>
> intptr_t a = 0;
> (struct B*)(a+0x20).member
>
> and less like this in C:
>
> intptr_t* a = 0;
> (struct B*)(*a+0x20).member

Yes.

Ali

Re: How to be more careful about null pointers?

[cy via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 06:21:49 UTC, Ali Çehreli wrote:

parent.prep.bind is translated to the following by the compiler:

"Call bind() for the object at address... let's calculate... 
Wherever parent is, we should add the offset of prep inside 
that object."


Okay, that's helpful actually. So, when accessing members of an 
object, it won't trigger a NPE, because the object is not 
dereferenced immediately, but the expected offset to the member 
is dereferenced. D puts off resolving pointer addresses as much 
as possible, so instead of bind((*parent).(*prep)) it's more like 
bind(parentlocation + prepoffset) and only (this.)member resolves 
to (*(parentlocation + prepoffset).member).


I thought it had an extra layer of pointer indirection, like if 
class object A has address 1234, and member A.b has offset 0x20, 
then you first dereference address 1234 (to get 4321 say) and 
then add 0x20 to that. But actually a class object is... already 
dereferenced, and is an integer representing the address to the 
object, not a pointer to that address.


Variables representing fixed, definite memory locations really 
throws me sometimes. You can't assign to a const, because that 
assigns to const marked memory, and doesn't just move the 
variable somewhere else. And NPE doesn't occur with a class, 
because setting it to NULL, and accessing a member is more like 
this in C:


intptr_t a = 0;
(struct B*)(a+0x20).member

and less like this in C:

intptr_t* a = 0;
(struct B*)(*a+0x20).member

[Issue 15848] out doesn't call opAssign()

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to lasssafin from comment #1)
> I'm not sure I follow: Why should opAssign be called?

Either a new Test is constructed by foo, but then the destructor should be
called on the old Test. Or the existing Test is used, but then opAssign should
be called instead of just writing Test.init over the old value.

I think the spec [1] is rather clear about which one should happen:

> out   parameter is initialized upon function entry with the default value for 
> its type

So I think the destructor should be called.


1 http://dlang.org/spec/function.html#parameters

--

[Issue 15847] It is not an error to call opAssign on an uninitialized object

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to monkeyworks12 from comment #2)
> No, we definitely don't want that. My point is that it is never valid to
> have opAssign called on a void initialized object that has a custom
> opAssign. It works for simple value types, but anything with a custom
> opAssign cannot allow it. Maybe void initialization should be disabled for
> types with custom opAssign.

I don't see how void initialization of types with a custom opAssign is bad
enough to disallow it. You just have to avoid calling the opAssign during
manual initialization, but that's entirely doable.


/* ... struct Test as in your code ... */
Test t = void;
t.n = int.init; /* manual initialization without calling opAssign */
t = 0; /* no problem */


A generic version (could also use memcpy or similar):

Test tinit = Test.init;
* cast(void[Test.sizeof]*)  = * cast(void[Test.sizeof]*) 


This is similar to how `cast(void*) someClassObject` can do something
surprising when it calls a custom opCast. But casts and void initialization are
dangerous, unsafe features to be used with much care. And a programmer who uses
them is expected to be aware of opCast and opAssign.

--

Re: Error: template instance does not match template declaration

[ref2401 via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 18:29:27 UTC, Ali Çehreli wrote:

On 03/29/2016 11:21 AM, ref2401 wrote:

So, dict is a template value parameter of type T[string]. I 
don't think you can use an associative array as a template 
value parameter. (Can we?)


However, it is possible to use anything as an alias template 
parameter.


If it's acceptable in your case, the following works:

private void impl(S, T, alias dict)(S arg)
if (is (typeof(dict) == T[S])) {

(Or T[string]).

Ali


alias works for me, thank you.

Re: Error: template instance does not match template declaration

[Ali Çehreli via Digitalmars-d-learn]

On 03/29/2016 11:21 AM, ref2401 wrote:

> private void impl(S, T, T[string] dict)(S arg) {
>  writeln("S: ", S.stringof);
>  writeln("T: ", T.stringof);
>  writeln("dict: ", dict);

So, dict is a template value parameter of type T[string]. I don't think 
you can use an associative array as a template value parameter. (Can we?)


However, it is possible to use anything as an alias template parameter.

If it's acceptable in your case, the following works:

private void impl(S, T, alias dict)(S arg)
if (is (typeof(dict) == T[S])) {

(Or T[string]).

Ali

Re: Blog article on new import changes

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/29/16 2:02 PM, Sebastiaan Koppe wrote:

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote:

I anticipate 2.071.0 is going to cause a lot of deprecation messages
and strange errors to occur, due to the fixes of very long-standing
import bugs.

I wrote a blog post (actually my first ever) on this, let me know what
you think (and please, any clarifications/errors, let me know):

http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


I would avoid 'generated' names like ex1_a and ex1_b, and go for
something concrete. E.g.

module car;
import tire;


Yeah, I probably could.

I wanted all my code in one gist, so I tried to come up with examples I 
could compile all at once. Worked great like dmd ex1*.d :)


I'll see if I can change it, I agree it would sound better.


Besided that, great and clear article.


Thanks

-Steve

Error: template instance does not match template declaration

[ref2401 via Digitalmars-d-learn]

OS: Win 8.1 Pro
DMD: v2.070.0
cmd: dmd main.d -ofconsole-app.exe -debug -unittest -wi

Code is successfully compiled until I uncomment test1 function 
call in the main.

If it's uncommented I get the following compile-time error:

main.d(58): Error: template instance impl!(string, bool, 
["y":true, "n":false]) does not match template declaration 
impl(S, T, Color[string] dict)(S arg)
main.d(62): Error: template instance mainentry.test1!string error 
instantiating


What have I done wrong?
Thank you.

import std.stdio;

enum Color { RED, GREEN }

private void impl(S, T, T[string] dict)(S arg) {
writeln("S: ", S.stringof);
writeln("T: ", T.stringof);
writeln("dict: ", dict);
}

unittest {
enum COLOR_MAP = [
"r": Color.RED,
"g": Color.GREEN
];

void test0(S)(S arg) {
impl!(S, Color, COLOR_MAP)(arg);
}

test0("000");
}

void test1(S)(S arg) {
impl!(S, bool, ["y": true, "n": false])(arg);
}

void main(string[] args) {
	// test1("111"); // if you uncomment this line you'll get a 
compile-time error

}

Re: the most D-ish GUI library

[Gerald via Digitalmars-d]

On Tuesday, 29 March 2016 at 17:37:15 UTC, Nick Sabalausky wrote:

Linux/GNOME (and any other Linux DE based on GTK):
Use the QGtkStyle theme:

It's a theme for Qt that *uses* GTK to render, therefore 
actually being native. (I've never actually used it though, 
since I think native GTK/GNOME/etc looks visually awful 
regardless of theme. And those file dialogs, ugh! Wish I could 
nuke those from my entire system.)


Well I'll disagree in that I much prefer the look of GTK 3 over 
Qt5, at least as I've seen it in KDE but that's a personal 
opinion. I run a Gnome/GTK3 environment so I avoid Qt apps as 
much as possible.


Note that an equivalent of QGtkStyle which goes the other way 
(rendering GTK programs using Qt) is no longer possible since 
GTK recently eliminated non-CSS themes (in a point release, no 
less).


I think this uses Gtk2 though and not Gtk3, there are some 
differences in how Gtk2 renders versus Gtk3 so it won't be 
completely seamless.


Therefore, Qt *is* the absolute winner here. It's basically 
native everywhere. GTK isn't, and without a major policy 
reversal, cannot be.


Even though I love Gtk I will agree with this, for cross platform 
work Qt is a better option then Gtk, just too bad about the lack 
of bindings.

[Issue 15848] out doesn't call opAssign()

[via Digitalmars-d-bugs]

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

lasssa...@gmail.com changed:

   What|Removed |Added

 CC||lasssa...@gmail.com

--- Comment #1 from lasssa...@gmail.com ---
I'm not sure I follow: Why should opAssign be called?

--

Re: Blog article on new import changes

[Sebastiaan Koppe via Digitalmars-d-announce]

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:
I anticipate 2.071.0 is going to cause a lot of deprecation 
messages and strange errors to occur, due to the fixes of very 
long-standing import bugs.


I wrote a blog post (actually my first ever) on this, let me 
know what you think (and please, any clarifications/errors, let 
me know):


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


I would avoid 'generated' names like ex1_a and ex1_b, and go for 
something concrete. E.g.


module car;
import tire;

Or whatever.

Besided that, great and clear article.

Re: Oh, my GoD! Goroutines on D

[H. S. Teoh via Digitalmars-d]

On Tuesday, 29 March 2016 at 17:10:02 UTC, Jin wrote:

On Tuesday, 29 March 2016 at 12:30:24 UTC, Dejan Lekic wrote:

+1
Wiki is absolutely the best solution to this, I agree. Plus, 
we already have a wiki so he should just go there and start 
writing. The community will incorrect grammar/syntax and typos.


http://wiki.dlang.org/Go_to_D


Since I know a bit of Russian, I took a shot at improving this 
article,
and got partway through the "Channels" section.  But now I need 
to get
back to work... so hopefully somebody else can work on improving 
the

English text. :-)


--T

Re: Pre-alpha D language online tour

[Bubbasaur via Digitalmars-d]

On Tuesday, 29 March 2016 at 16:26:27 UTC, André wrote:

...
I would appreciate if people could do some proof reading and 
just create pull requests for the content:


Nice work but I really think that the left content should be 
expandable. Some button like Try it or whatever should do the 
trick. It's a waste space mainly when there is nothing on the 
left side.


The same thing goes for the bottom content, I don't think it 
should be fixed.


Finally the font-size is too big for me.

Bubba.

Re: Blog article on new import changes

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/29/16 1:01 PM, Dicebot wrote:

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote:

I anticipate 2.071.0 is going to cause a lot of deprecation messages
and strange errors to occur, due to the fixes of very long-standing
import bugs.

I wrote a blog post (actually my first ever) on this, let me know what
you think (and please, any clarifications/errors, let me know):

http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


Worth mentioning that -transition=checkimports may slow down compilation
notably which is why it isn't the default.


Thanks, added a note.

-Steve

Re: the most D-ish GUI library

[Nick Sabalausky via Digitalmars-d]

On 03/28/2016 01:21 PM, WebFreak001 wrote:


You are right, i forgot Qt/KDE guys. KDE uses Qt for their programs and
stuff but GNOME and the Ubuntu team and most desktop environments do use
GTK instead of Qt. Qt is more common on OS X and Windows than on linux.
I guess there will never be an absolute winner to something because
there are always people using something different.



Win and Mac:
Qt looks native.

Linux/KDE:
Qt is native.

Linux/GNOME (and any other Linux DE based on GTK):
Use the QGtkStyle theme:

It's a theme for Qt that *uses* GTK to render, therefore actually being 
native. (I've never actually used it though, since I think native 
GTK/GNOME/etc looks visually awful regardless of theme. And those file 
dialogs, ugh! Wish I could nuke those from my entire system.)


Note that an equivalent of QGtkStyle which goes the other way (rendering 
GTK programs using Qt) is no longer possible since GTK recently 
eliminated non-CSS themes (in a point release, no less).


Therefore, Qt *is* the absolute winner here. It's basically native 
everywhere. GTK isn't, and without a major policy reversal, cannot be.

[Issue 15217] overloaded extern(C) function declarations are allowed

[via Digitalmars-d-bugs]

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

Johan Engelen  changed:

   What|Removed |Added

 CC||jbc.enge...@gmail.com

--- Comment #1 from Johan Engelen  ---
"GetMonitorInfoA" is also overloaded in this way in druntime,
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/winuser.d#L4425-L4428

--

Re: Pre-alpha D language online tour

[jmh530 via Digitalmars-d]

On Tuesday, 29 March 2016 at 16:26:27 UTC, André wrote:
Or just drop me a message where you find a bug and I'll have it 
fixed.




Looks good. A few suggestions, some content, some typo.

D Basics (fix capitalization?):

Page 3, code example at the bottom right does not compile with 
@system. Also, D allows pointer arithmetic in @trusted code, so 
the text above it is not completely accurate. I would change the 
line


D also allows pointer arithmetic. This is not allowed in code 
which is marked as @safe but only in @system code.


to

D allows pointer arithmetic, except in code that is marked as 
@safe


Page 4, This line on const is confusing

To a const object can't be written, but someone holding a 
mutable to the same object might just well.


I feel like the static keyword is complicated enough that it 
could get its own slide (or multiple). Why not just put the 
variable at the top level without static?


Page 7, the discussion on delegates could be clearer.

D Gems:
Page 3, put the code examples on a separate line.

Page 7, I would re-write the last line as

The attribute pure is automatically inferred by the compiler for 
templated functions and auto functions, where applicable (this is 
also true of @safe, nothrow, and @nogc).


Page 8, I was not aware of invariant. I feel like I have a struct 
somewhere that could use it!


Page 10, might also mention @safe.

Page 13, conditionnally is spelled wrong.

I feel like static if with templates could get a whole page by 
itself.


Concurrency:
Maybe re-name Multithreading? I wouldn't consider std.parallelism 
a way to implement concurrency.


VibeD:
Page 1: Define asynchronous I/O and why it matters. I see a short 
explanation near the end of Page 2, but I feel like it should be 
brought up to the front. Maybe make that big paragraph into a 
list of key vibe-d features and why they matter.

Re: Oh, my GoD! Goroutines on D

[Jin via Digitalmars-d]

On Tuesday, 29 March 2016 at 12:30:24 UTC, Dejan Lekic wrote:

+1
Wiki is absolutely the best solution to this, I agree. Plus, we 
already have a wiki so he should just go there and start 
writing. The community will incorrect grammar/syntax and typos.


http://wiki.dlang.org/Go_to_D

Re: Blog article on new import changes

[Dicebot via Digitalmars-d-announce]

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:
I anticipate 2.071.0 is going to cause a lot of deprecation 
messages and strange errors to occur, due to the fixes of very 
long-standing import bugs.


I wrote a blog post (actually my first ever) on this, let me 
know what you think (and please, any clarifications/errors, let 
me know):


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


Worth mentioning that -transition=checkimports may slow down 
compilation notably which is why it isn't the default.

Re: Pre-alpha D language online tour

[André via Digitalmars-d]

On Monday, 25 January 2016 at 18:17:09 UTC, André wrote:

Hi,

Inspired by the Go online language tour 
(https://tour.golang.org/) and the great experience it gave me 
learning the language I started a similar project for D some 
weeks ago. It's currently in a very pre-alpha state but I 
wanted to announce it in case someone had something similar in 
mind and is willing to contribute. The basic idea behind this 
tour is to introduce features of the language with short 
explanations and example code that is compiled and run online.


The code is located here:

https://github.com/stonemaster/dlang-tour

I've setup a server which always runs the latest version:

http://dlang-tour.steinsoft.net

This tour doesn't allow compiling online because the current 
implementation would just make it too easy to hijack the server 
:-) Compiling and running online can be activated when 
compiling locally though. My goal would be to integrate the 
tour with DPaste in the long run.


Working on this tour unfortunately stalled a little bit in this 
year but I am trying to work on the project constantly in the 
upcoming weeks. There is still a lot of content missing and, 
more importantly, good D source examples. But I have a rough 
guideline on which D topics I'd like to add content for.


Any kind of feedback is highly appreciated, of course.


Here are great news on the dlang-tour project: As of now I've 
written all content and the latest build is running on


http://dlang-tour.steinsoft.net

Somewhere ago I've implemented running code samples online (which 
are run in a Docker container on the server) so the tour is fully 
functional. There are still some polishing work to be left and 
some issues to be fixed before this should go public: 
https://github.com/stonemaster/dlang-tour/issues


I would appreciate if people could do some proof reading and just 
create pull requests for the content: 
https://github.com/stonemaster/dlang-tour/tree/master/public/content/en.
Or just drop me a message where you find a bug and I'll have it 
fixed.


Thanks,
André

Re: Blog article on new import changes

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/29/16 11:49 AM, Jack Stouffer wrote:

Here are some notes I jotted down when reading it


Thanks, all fixed.

Note, the "upcoming" note was added hastily before publishing because I 
realized 2.071 hasn't been released.


Now reads:

"In the upcoming version of D, several changes have been made to the 
import system"

Re: Blog article on new import changes

[Jack Stouffer via Digitalmars-d-announce]

On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer 
wrote:
I anticipate 2.071.0 is going to cause a lot of deprecation 
messages and strange errors to occur, due to the fixes of very 
long-standing import bugs.


I wrote a blog post (actually my first ever) on this, let me 
know what you think (and please, any clarifications/errors, let 
me know):


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/


This is an informative article, good job.

Here are some notes I jotted down when reading it

In the newest version of D upcoming, several changes have been 
made to the import system, including fixes for 2 of the oldest 
bugs in D history.


Grammatically, it's redundant to put "upcoming" where it is; 
numbers under 20 are typically written with their name.


However, until the fix was rendered, these module symbols were 
imported as if they were marked public.


This sentence is redundant.


This determines where the problem lies.


This sentence is also redundant.

Blog article on new import changes

[Steven Schveighoffer via Digitalmars-d-announce]

I anticipate 2.071.0 is going to cause a lot of deprecation messages and 
strange errors to occur, due to the fixes of very long-standing import bugs.


I wrote a blog post (actually my first ever) on this, let me know what 
you think (and please, any clarifications/errors, let me know):


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

Re: Oh, no UFCS for member functions

[Luís Marques via Digitalmars-d]

On Tuesday, 29 March 2016 at 15:08:05 UTC, Anonymouse wrote:
The ugly workaround if you really don't want to reorganise 
things (and/or use the tile function directly) is to make a 
top-level alias tile = Player.tile;


Cool, I was not aware of that workaround. Also, I wonder if this 
workaround doesn't argue somewhat against the rationale for not 
having member-function UFCS, whatever it was.

Re: Oh, no UFCS for member functions

[Anonymouse via Digitalmars-d]

On Tuesday, 29 March 2016 at 14:56:53 UTC, Luís Marques wrote:

Too bad this doesn't work:

struct Player
{
MapTile[] playerMap; // partial private knowledge of map
Location destination;

auto tile(Location loc)
{
return playerMap[loc];
}

void foo()
{
if(destination.tile.hasMonster)
...
}
}


By design. I don't remember the rationale, though.

The ugly workaround if you really don't want to reorganise things 
(and/or use the tile function directly) is to make a top-level 
alias tile = Player.tile;

Re: mir.combinatorics: reviewers and ideas are wanted

[Seb via Digitalmars-d-announce]

On Monday, 28 March 2016 at 15:30:56 UTC, Timon Gehr wrote:

Regarding ideas:
For each range, there should probably be a numeric function 
computing the length of that range. (e.g. here, binomial 
corresponds to combinations, there should be factorial 
corresponding to permutations etc.)


This table might provide some inspiration:


Thanks a lot for your input and ideas - I will work on it ;-)

Oh, no UFCS for member functions

[Luís Marques via Digitalmars-d]

Too bad this doesn't work:

struct Player
{
MapTile[] playerMap; // partial private knowledge of map
Location destination;

auto tile(Location loc)
{
return playerMap[loc];
}

void foo()
{
if(destination.tile.hasMonster)
...
}
}

[Issue 15847] It is not an error to call opAssign on an uninitialized object

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schue...@gmx.net
 Resolution|--- |INVALID

--- Comment #1 from Marc Schütz  ---
Your test cannot work reliably, but...

It is not a bug that opAssign() is called here. Using void initialization
doesn't mean "please turn the first assignment into a construction". That
wouldn't work in the general case. It means "don't initialize this variable,
I'll take care of it myself".

However, what you wrote on Github - that the assignment operator for the out
parameter isn't called - is still true. I've filed it here:
https://issues.dlang.org/show_bug.cgi?id=15848

--

[Issue 15848] New: out doesn't call opAssign()

[via Digitalmars-d-bugs]

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

  Issue ID: 15848
   Summary: out doesn't call opAssign()
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schue...@gmx.net

import std.stdio;

void foo(out Test x) {
writeln("x.n = ", x.n);
}

struct Test {
int n;
~this() {
writeln("~this()");
}
int opAssign(int val) {
writefln("opAssign(%s)", val);
return n = val + 1;
}
}

void main() {
Test t;
foo(t);
writeln("done");
}

// output:
x.n = 0
done
~this()

Conclusion:
Upon entering foo(), Test.opAssign() is not called. An argument could be made
that `out` shouldn't construct a new struct, not assign an existing one, but in
that case, it would have to call Test.~this(), which doesn't happen either.

--

[Issue 15847] New: It is not an error to call opAssign on an uninitialized object

[via Digitalmars-d-bugs]

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

  Issue ID: 15847
   Summary: It is not an error to call opAssign on an
uninitialized object
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: monkeywork...@hotmail.com

struct Test
{
int n;

int opAssign(int val)
{
assert(n == int.init, "n is in an uninitialized state");
return n = val;
}
}

void main()
{
Test t = void;
//opAssign should not be called here as t is uninitialized
t = 0; //BOOM
}

--

Re: the most D-ish GUI library

[Luis via Digitalmars-d]

On Friday, 25 March 2016 at 14:45:05 UTC, Nick Sabalausky wrote:

On 03/13/2016 06:33 PM, WebFreak001 wrote:


I prefer GtkD, its the most system native one on linux


I dispute that. Many people, like myself, use KDE rather than 
GNOME or Unity, and GTK programs are just as horrible to put up 
with in this environment as they are on Windows. Even more so 
since the GTK folks have now decided it's acceptable to remove 
an entire theming engine in a freaking point release. For that 
and various other reasons, GTK is a plague upon ANY operating 
system, and a big part of that ultimately comes down to 
colossal mismanagement - the one part of any project that's the 
hardest to fix.


I'm a KDE guy, I would love using Qt with D on way that at least 
would be equal easy that with Gtk. Sadly, using Qt with anything 
that isn't C++ usually would give you problems (MOC, Qt wrappers 
that usually get abandoned, etc)

Re: Why is separating class ind struct is bad?

[Danni Coy via Digitalmars-d]

> Could anybody explain what this mean and why this way is not modern?

This is in the context of users migrating from C++, and it is bad in
so far as it is not what a C++ programmer who hasn't read all the
documentation would expect.

The easiest path of migration would be if the programmer can design a
program the same way they would a C++ program but using D syntax.
this, transitive const and I think thread local by default make
migration in this way harder. (Though probably worth it in the long
run)

Re: Categorization of warnings

[Johan Engelen via Digitalmars-d]

On Tuesday, 29 March 2016 at 04:29:52 UTC, Dicebot wrote:

On 03/28/2016 08:05 PM, Steven Schveighoffer wrote:
Warnings can be an important part of the deprecation process. 
The next release of the compiler will illustrate that.


No. Deciding that warnings have any relation with deprecation 
process was huge mistake and, as far as I know, it is going to 
be fixed. Though it can easily be that something new and 
annoying has slipped into next release too.


I was very surprised I had to catagorize some warnings as 
"soon-deprecated". Let's get the remaining two "warnings" to 
deprecated status asap then?

https://dlang.org/deprecate.html
(they are warnings from 2.067)

Re: parsing fastq files with D

[rikki cattermole via Digitalmars-d-learn]

On 30/03/2016 1:46 AM, eastanon wrote:

On Thursday, 24 March 2016 at 06:34:51 UTC, rikki cattermole wrote:

void popFront() {
import std.string : indexOf;

if (source is null) {
isEmpty = true;
return;
}

void tidyInput() {
foreach(i, c; source) {
switch(c) {
case 0: .. case ' ':
break;
default:
source = source[i .. $];
return;
}
}

source = null;
}

tidyInput();


Do you mind to explain  what is really going on at popFront() and
tidyInput() functions?


popFront is a special function used with input ranges.
It has support in the language for e.g. foreach loops.
You also need empty and front to go along with it however.
With front returning a value and empty if there is any more items.

The if statement in popFront is just to make empty set correctly (delayed).

Now tidyInput basically just trims (on the left) the source and sets it 
to null if there is no more of it.

That way things like "   @Myid" will still work fine.

If you need an explanation about the rest of popFront, let me know!

Re: Categorization of warnings

[Dicebot via Digitalmars-d]

On 03/29/2016 03:34 PM, Steven Schveighoffer wrote:
> I think it might be simply deprecation. I can't remember.
> 
> Tested:
> 
> Yes, it is a deprecation, not a warning (compilation succeeds on -w). I
> stand corrected!

Thanks, no need for me to panic in that case :)

> This is in essence, still a warning. Just not one that fails
> compilation. It makes build messages from large projects basically
> unreadable.

There is essential difference. Warning indicates some error-prone code
and most projects do want to build with warnings enabled by default.
Deprecation is simply early indication of requested change and it is OK
for any projects to take weeks and months to clean up deprecatations as
the time allows.

The fact that deprecations don't break compilation by default is crucial
in dub ecosystem as otherwise each compiler release could make your dub
dependencies unusable until their maintainers make new release with
fixes. Deprecations provide that transitional step.

Also you can disable deprecation messages completely with `-d`.

Re: infer type argument in classe constructor?

[Puming via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 10:29:46 UTC, Simen Kjaeraas wrote:

On Tuesday, 29 March 2016 at 10:13:28 UTC, Puming wrote:

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type 
from src.

```


Nope. To see why, consider a class like this:

class A(T) {
  T data;
  this(int n) {
  }
}

void main() {
   auto a = new A(3); // What is T?
}


Sorry I don't see it. In this case, I don't see an ambiguity?

`int n` and T are not connected, so invoking A(3) means you are 
only setting the argument n to 3, so T can not be infered, and 
the compiler could just complain 'generic type T is not provided'.



The common solution is a simple 'create' function:

Decoder!T decoder(T)(T msg) {
return new Decoder!T(msg);
}

--
  Simen

Re: RFC: Units of measurement for D (Phobos?)

[Seb via Digitalmars-d]

On Tuesday, 22 March 2016 at 09:55:28 UTC, Zardoz wrote:


Impressive! I like the idea, in special when you can handled 
derived units and doing conversions like this :


convert!(kilo(newton))(200 * gram * meter / pow!2(second)));


Wow that's pretty sweet!
So @nordlow how about pushing this code to a separate repository 
and dub?

It seems that now there is enough interest in pushing this :)


I would like to move forward with std.experimental.unit(s).


+1 for pushing this to Phobos!

Re: parsing fastq files with D

[eastanon via Digitalmars-d-learn]

On Thursday, 24 March 2016 at 06:34:51 UTC, rikki cattermole 
wrote:

void popFront() {
import std.string : indexOf;

if (source is null) {
isEmpty = true;
return;
}

void tidyInput() {
foreach(i, c; source) {
switch(c) {
case 0: .. case ' ':
break;
default:
source = 
source[i .. $];
return;
}
}

source = null;
}

tidyInput();


Do you mind to explain  what is really going on at popFront() and 
tidyInput() functions?

Re: Categorization of warnings

[Steven Schveighoffer via Digitalmars-d]

On 3/29/16 8:24 AM, Dicebot wrote:

On Tuesday, 29 March 2016 at 12:21:59 UTC, Steven Schveighoffer wrote:

The next release will have a deprecation warning about selective
imports that mistakenly allow usage of FQN. You will see most likely.
Phobos had thousands of them.



Deprecation or a warning? It must be deprecation (as in, "don't fail on
-w"). If it isn't, probably it is time to raise some critical bugzilla
reports.


I think it might be simply deprecation. I can't remember.

Tested:

Yes, it is a deprecation, not a warning (compilation succeeds on -w). I 
stand corrected!


This is in essence, still a warning. Just not one that fails 
compilation. It makes build messages from large projects basically 
unreadable.


-Steve

Re: Oh, my GoD! Goroutines on D

[Dejan Lekic via Digitalmars-d]

On Monday, 28 March 2016 at 10:49:28 UTC, Jacob Carlborg wrote:
It would be useful with a wiki page, or similar, that describes 
and compares different ways of doing concurrency in D, both 
built-in and third party libraries like this and vibe.d. Also 
compare against other languages like Go, Erlang, Scala and so 
on.


+1
Wiki is absolutely the best solution to this, I agree. Plus, we 
already have a wiki so he should just go there and start writing. 
The community will incorrect grammar/syntax and typos.

Re: Better Phobos contribution guide

[Seb via Digitalmars-d]

On Friday, 25 March 2016 at 17:56:05 UTC, Xinok wrote:

- check: did you add enough tests?


I would extend this to emphasize "complete code coverage" in 
unit tests.


Yeah it would be great if we can check this automatically - see 
the other discussion:


http://forum.dlang.org/thread/vzmkecogfcpoojauq...@forum.dlang.org

As a last word, a couple of this things could be enforced - 
especially the style guide. Are there already plans to check 
for this automatically?


I believe the autotester already checks whitespace (are you 
using spaces or tabs?) though I could be wrong about this.


Yep it checks for tabs and trailing whitespace, but not for the 
style guide itself (e.g. whitespace between operators or allman 
brace style)


Overall, I think these would be good additions to the 
contribution guide.


Thanks @all for your helpful feedback! - I opened a PR with these 
ideas to Phobos:


https://github.com/D-Programming-Language/phobos/pull/4128

Re: Categorization of warnings

[Dicebot via Digitalmars-d]

On Tuesday, 29 March 2016 at 12:21:59 UTC, Steven Schveighoffer 
wrote:
The next release will have a deprecation warning about 
selective imports that mistakenly allow usage of FQN. You will 
see most likely. Phobos had thousands of them.


-Steve


Deprecation or a warning? It must be deprecation (as in, "don't 
fail on -w"). If it isn't, probably it is time to raise some 
critical bugzilla reports.

Re: Categorization of warnings

[Steven Schveighoffer via Digitalmars-d]

On 3/29/16 12:29 AM, Dicebot wrote:

On 03/28/2016 08:05 PM, Steven Schveighoffer wrote:

Warnings can be an important part of the deprecation process. The next
release of the compiler will illustrate that.


No. Deciding that warnings have any relation with deprecation process
was huge mistake and, as far as I know, it is going to be fixed. Though
it can easily be that something new and annoying has slipped into next
release too.



The next release will have a deprecation warning about selective imports 
that mistakenly allow usage of FQN. You will see most likely. Phobos had 
thousands of them.


-Steve

Re: Article on Introspective programming

[Nicholas Wilson via Digitalmars-d-announce]

On Monday, 28 March 2016 at 12:47:02 UTC, Nicholas Wilson wrote:


http://thewilsonator.github.io/update/2016/03/28/better-vulkan-bindings.html

I would like some feedback before this is posted to reddit.

Come to think of it, putting the project on github would be a 
good idea, but unfortunately I won't have the time for at least 
a week.


Oh well.

Comments and suggestions appreciated.

Nic


https://www.reddit.com/r/programming/comments/4cezy8/generating_better_vulkan_bindings_an_adventure_in/

Re: infer type argument in classe constructor?

[Edwin van Leeuwen via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 10:13:28 UTC, Puming wrote:

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type from 
src.

```


You can't directly. This is (AFAIK) because this()() can also be 
templated, making it impossible to just derive. The common way in 
D to deal with this/work around it is to create a helper function 
that can infer it:


```D
auto decoder(T)(T src)
{
  return new Decoder!T(src);
}

auto dec = decoder(src)
```

This pattern is widely used in phobos (e.g. tuple and Tuple)

Re: Code coverage in Phobos

[Basile B. via Digitalmars-d]

On Tuesday, 29 March 2016 at 09:39:49 UTC, Walter Bright wrote:

On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:
Ah, OK. Though, this is something that could be improved in 
the implementation
without changing the language. DMD should not emit code that's 
not called in the
module, and not callable from outside the module due to e.g. 
being private.
Probably would help with template bloat, too. LTO would 
probably take care of
that in theory, I wonder if LDC's or GDC's LTO doesn't have 
this issue (not that

it would help testing Phobos coverage).



Or one could write unit tests specifically for the helper 
functions. (I've done that.)


I've also done so in my user lib. Actually I've particpated to 
this topic because of this:


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

3 monthes ago I had never used D coverage feature. Initially I 
thought that the coverage file was generated by static analysis 
(until someone points me 
https://dlang.org/phobos/core_runtime.html#.dmd_coverDestPath)...


Couldn't the coverage be done at compile time ? (even if I 
directly see corner cases like functions only called by delegate)

Re: infer type argument in classe constructor?

[Simen Kjaeraas via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 10:13:28 UTC, Puming wrote:

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type from 
src.

```


Nope. To see why, consider a class like this:

class A(T) {
  T data;
  this(int n) {
  }
}

void main() {
   auto a = new A(3); // What is T?
}

The common solution is a simple 'create' function:

Decoder!T decoder(T)(T msg) {
return new Decoder!T(msg);
}

--
  Simen

infer type argument in classe constructor?

[Puming via Digitalmars-d-learn]

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type from 
src.

```

Re: Joining AliasSeq/TypeTuple s

[Adrian Matoga via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 09:33:40 UTC, Voitech wrote:
Hi, i want to join two or more tupples in to one, with mixing 
the indexes like roundRobin but in compile time.


unittest{
import std.meta;
alias first=AliasSeq!(int, string,bool);
alias second=AliasSeq!("abc","def","ghi");
alias third=...

static assert(third==AliasSeq!(int, "abc", string, "def", bool, 
"ghi"));

}


How to obtain this kind of functionality ? Is there maybe some 
builin template for this in phobos ? I couldn't find this.


Thank you
Voitech.


import std.meta : AliasSeq;

template RR(A...)
if (!(A.length & 1))
{
static if (A.length == 0)
alias RR = AliasSeq!();
else {
alias Left = A[0 .. $ / 2];
alias Right = A[$ / 2 .. $];
		alias RR = AliasSeq!(Left[0], Right[0], RR!(Left[1 .. $], 
Right[1 .. $]));

}
}

struct S(A...) {} // needed to reliably compare AliasSeq's for 
equality


unittest {
alias first = AliasSeq!(int, string, bool);
alias second = AliasSeq!("abc", "def", "ghi");
alias third = RR!(first, second);
	static assert(is(S!third == S!(int, "abc", string, "def", bool, 
"ghi")));

}

Re: string and char[] in Phobos

[Puming via Digitalmars-d-learn]

On Friday, 18 March 2016 at 20:06:27 UTC, Jonathan M Davis wrote:


When a function accepts const(char)[] than it can accept char[],
const(char)[], const(char[]), immutable(char)[], and 
immutable(char[]),

which, whereas if it accepts string, then all it accepts are
immutable(char)[] and immutable(char[]). So, it's more
So I need to use const(char)[] in my function definitions instead 
of in char[]?

restrictive, but if
you need to return a slice of the array you passed in, if your 
function
accepts const rather than mutable or immutable, then the slice 
has to be
const, and you've lost the type information, which is why inout 
exists -

Well, I never got inout until now, thanks!

[...]
I don't know what you're using in Phobos that takes string and 
returns char[]. That implies an allocation, and if the function 
is pure, char[] may have been selected, because it could be 
implicitly converted to string thanks to the fact that the 
compiler could prove that the char[] being returned had to have 
been allocated in the function and that there could be no other 
references to that array. But without knowing exactly which 
functions you're talking about, I can't really say. In general 
though, the solution that we've gone with is to templatize 
functions that operate on strings, and a function that's taking 
a string explicitly is most likely storing it, in which case, 
it needs an explicit type, and using an immutable value ensures 
that it doesn't change later.


I just got this feeling from using functions in the std.file 
module, like dirEntries and File constructor itself. After 
reading your explaination, it makes sense now. And with a second 
look up, most functions there ARE alread templatized. Thanks for 
your clarification.


On a side note, I'd strongly argue against using "in" on 
function arguments that aren't delegates. in is equivalent to 
const scope, and scope currently does nothing for any types 
other than delegates - but it might later, in which case, you 
could be forced to change your code, depending on the exact 
semantics of scope for non-delegates. But it does _nothing_ now 
with non-delegate types regardless, so it's a meaningless 
attribute that might change meaning later, which makes using it 
a very bad idea IMHO. Just use const if you want const and 
leave scope for delegates. I'd actually love to see in 
deprecated, because it adds no value to the language (since 
it's equivalent to const scope, which you can use explicitly), 
and it hides the fact that scope is used.


Well, this is too complicated level for me now. I'll get to that 
later when I learn more with the language.


My take away from your post:

- when the function is pure for the stringlike, use 
'const(char)[]' or 'inout(char)[]' when neccessary.

- when the argument is stored in the function, use string.
- manually convert stringlike objects to string with to!string 
when calling those functions.


are those above correct?



- Jonathan M Davis

Re: Code coverage in Phobos

[Walter Bright via Digitalmars-d]

On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:

Ah, OK. Though, this is something that could be improved in the implementation
without changing the language. DMD should not emit code that's not called in the
module, and not callable from outside the module due to e.g. being private.
Probably would help with template bloat, too. LTO would probably take care of
that in theory, I wonder if LDC's or GDC's LTO doesn't have this issue (not that
it would help testing Phobos coverage).



Or one could write unit tests specifically for the helper functions. (I've done 
that.)

Joining AliasSeq/TypeTuple s

[Voitech via Digitalmars-d-learn]

Hi, i want to join two or more tupples in to one, with mixing the 
indexes like roundRobin but in compile time.


unittest{
import std.meta;
alias first=AliasSeq!(int, string,bool);
alias second=AliasSeq!("abc","def","ghi");
alias third=...

static assert(third==AliasSeq!(int, "abc", string, "def", bool, 
"ghi"));

}


How to obtain this kind of functionality ? Is there maybe some 
builin template for this in phobos ? I couldn't find this.


Thank you
Voitech.

Re: char array weirdness

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 28, 2016 16:29:50 H. S. Teoh via Digitalmars-d-learn wrote:
> On Mon, Mar 28, 2016 at 04:07:22PM -0700, Jonathan M Davis via
> Digitalmars-d-learn wrote: [...]
>
> > The range API considers all strings to have an element type of dchar.
> > char, wchar, and dchar are UTF code units - UTF-8, UTF-16, and UTF-32
> > respectively. One or more code units make up a code point, which is
> > actually something displayable but not necessarily what you'd call a
> > character (e.g.  it could be an accent). One or more code points then
> > make up a grapheme, which is really what a displayable character is.
> > When Andrei designed the range API, he didn't know about graphemes -
> > just code units and code points, so he thought that code points were
> > guaranteed to be full characters and decided that that's what we'd
> > operate on for correctness' sake.
>
> [...]
>
> Unfortunately, the fact that the default is *not* to use graphemes makes
> working with non-European language strings pretty much just as ugly and
> error-prone as working with bare char's in European language strings.

Yeah. Operating at the code point level instead of the code unit level is
correct for more text than just operating at the code unit level (especially
if you're dealing with char rather than wchar), but ultimately, it's
definitely not correct, and there's plenty of text that will be processed
incorrectly as code points.

> I argue that auto-decoding, as currently implemented, is a net minus,
> even though I realize this is unlikely to change in this lifetime. It
> charges a constant performance overhead yet still does not guarantee
> things will behave as the user would expect (i.e., treat the string as
> graphemes rather than code points).

I totally agree, and I think that _most_ of the Phobos devs agree at this
point. It's Andrei that doesn't. But we have the twin problems of figuring
out how to convince him and how to deal with the fact that changing it would
break a lot of code. Unicoding is disgusting to deal with if you want to
deal with it correctly _and_ be efficient about it, but hiding it doesn't
really work.

I think that the first steps are to make it so that the algorithms in Phobos
will operate just fine on ranges of char and wchar in addition to dchar and
move towards making it irrelevant wherever we can. Some functions (like
filter) are going to have to be told what level to operate at and would be a
serious problem if/when we switched away from auto-decoding, but many others
(such as find) can be made not to care while still operating on Unicode
correctly. And if we can get the amount code impacted low enough (at least
as far as Phobos goes), then maybe we can find a way to switch away from
auto-decoding. Ultimately though, I fear that we're stuck with it and that
we'll just have to figure out how to make it work well for those who know
what they're doing while minimizing the performance impact of auto-decoding
on those who don't know what they're doing as much as we reasonably can.

- Jonathan M Davis

Re: Oh, my GoD! Goroutines on D

[sigod via Digitalmars-d]

On Monday, 28 March 2016 at 22:35:12 UTC, Jin wrote:

On Monday, 28 March 2016 at 19:29:55 UTC, Walter Bright wrote:

On 3/28/2016 6:10 AM, Jin wrote:

My english is too bad to write articles, sorry :-(


Baloney, your english is very good. Besides, I'm sure there 
will be many volunteers here to help you touch it up.


I just wrote the article on russin: 
https://habrahabr.ru/post/280378/
Translation to english: 
https://translate.google.com/translate?hl=ru=ru=en=https%3A%2F%2Fhabrahabr.ru%2Fpost%2F280378%2F


Create repository on GitHub. So, it will be easier for others to 
help with translation.

Re: Categorization of warnings

[Dicebot via Digitalmars-d]

On Tuesday, 29 March 2016 at 08:13:59 UTC, Johan Engelen wrote:

On Tuesday, 29 March 2016 at 04:35:11 UTC, Dicebot wrote:


Sadly, this isn't very useful. If there is one legitimate use 
of code warned about one wants to disable that specific place 
and not all warning of that kind in whole program. Which means 
it has to be controlled by some sort of pragma.


for which you would need categorization of warnings.


Not necessarily. "Ignore any warning in next statement" would 
work in practice too. Though categorization is indeed useful for 
clean separation - as part of such pragma.

Re: dlang.org makefile pains

[Atila Neves via Digitalmars-d]

On Thursday, 24 March 2016 at 18:56:00 UTC, H. S. Teoh wrote:
On Thu, Mar 24, 2016 at 06:51:32PM +, Piotrek via 
Digitalmars-d wrote:

On Tuesday, 22 March 2016 at 23:23:56 UTC, Jakob Ovrum wrote:
>Bump. Please help. If Martin is the only one who understands 
>the makefile then we have a serious problem.


Makefiles are for chosen people. That's why I suggested moving 
to a d build system. However I'm aware it's not political 
correct.

[...]

Since when?  I thought a year or two ago, when the same 
discussion came up, people seemed amiable to the idea of a 
D-based build system.


Of course, actually implementing a compelling candidate for 
such a system is another story.



T


There was this: 
http://forum.dlang.org/post/kjbmzcnhhzlimfkjc...@forum.dlang.org


Atila

Re: Categorization of warnings

[Johan Engelen via Digitalmars-d]

On Tuesday, 29 March 2016 at 04:35:11 UTC, Dicebot wrote:


Sadly, this isn't very useful. If there is one legitimate use 
of code warned about one wants to disable that specific place 
and not all warning of that kind in whole program. Which means 
it has to be controlled by some sort of pragma.


for which you would need categorization of warnings.

Re: Why is separating class ind struct is bad?

[Walter Bright via Digitalmars-d]

On 3/28/2016 9:56 PM, Dicebot wrote:

It is hard to argue that but I have never encountered any issues from
actual confusion between struct and class in C++ (because there isn't
any real difference), only from misusage of virtual types.


Misusage of virtual types is the confusion.



1. Want to switch between a class and a struct? You've got lots of
editing to do.


I'd prefer to do lot of editing as opposed to lot of reading through to
not introduce silent semantical bugs - which is exactly how switching
between struct and class looks now. This is a major benefit, not an issue.


My experience is the opposite. I've found it quick & easy to attempt different 
data structures in D because of the minimal editing. In C++, I (and I suspect 
most people) just go with their first design because it is too much of a pain to 
edit all the usages.


That is what I've dubbed "brittleness". One way I was able to quickly achieve 
speed in Warp was it was easy to try out different data structures. Much, much 
easier than in C++. The end result could be done in C++, but getting there would 
probably not have happened.




2. You'd have to invent a way to do 'alias ref MyClass T;'


No way. `typedef int* p_int_t` is one of worst popular C idioms in my
opinion. Typing extra three letters is a very minor price for having a
code which looks like what it does.


You'd have to give up on writing generic code, then.



Well, languages that simply declare everything a reference (JS) or
dropped support for inheritance based polymorphism (Go, Rust) are much
more consistent in that regard in my opinion :)


JS and Go throw a lot of capability under the bus in order to achieve 
consistency. It's a high price. I don't know enough about Rust to say what their 
tradeoffs here really are.




There isn't much point in discussin details at this point as the ship
has long sailed. But I definitely consider this one of underdesigned
parts of D language.


True dat.

Re: debugger blues

[Iain Buclaw via Digitalmars-d]

On 28 March 2016 at 21:29, cy via Digitalmars-d  wrote:

> On Sunday, 27 March 2016 at 15:40:47 UTC, Marco Leise wrote:
>
>> Is it just me? I've never heard of a programming environment, let alone a
>> system programming language providing that information.
>>
>
> Well, not by default certainly. It is a bit pie-in-the-sky, but only
> because it slows everything down. It's got the same cost as profiling. Many
> languages, even C in some cases, have support for this. With gcc for
> instance, if you use -finstrument-functions then it calls
> __cyg_profile_func_enter before every function call and
> __cyg_profile_func_exit afterwards. That can be used to accumulate _totals_
> of how many times a function was called (profiling) but it can also just
> dump the called functions in order.
>
> I certainly would be shocked as heck if a debugger could take
> non-instrumented code and add all that tracing and/or profiling stuff, but
> stranger things have happened in the murky realm of code debugging.
>
>
Most language agnostic features of gcc are possible in gdc too.  Coverage
and instrumentation come for free.

Re: libotr native D port

[Robert M. Münch via Digitalmars-d-announce]

On 2016-03-28 08:53:24 +, ketmar said:

subj. here[1]. not heavily tested, but it doesn't really matter, as 
nobody will use it anyway.



1. http://repo.or.cz/libotrd.git


Off-the-Record (OTR) Messaging is a cryptographic protocol used in 
well-known instant messaging clients such as Pidgin, ChatSecure, Adium
and others. It is designed to work on top of existing protocols and 
used worldwide to provide secure communication in insecure 
environments. OTR is regarded as highly secure and according to 
documents revealed by Edward Snowden one of the protocols that the NSA 
is not able to decrypt via cryptanalysis. The most commonly used 
implementation of OTR is "libotr" which is a pure C code implementation 
of the OTR protocol.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Oh, my GoD! Goroutines on D

[Jacob Carlborg via Digitalmars-d]

On 2016-03-29 01:53, Ali Çehreli wrote:


Seriously, I appreciate any documentation links that you can give to
complete my "homework" before DConf. :)


I was hoping someone could give _me_ the links, that's why I wrote the 
post ;)


--
/Jacob Carlborg

Re: How to be more careful about null pointers?

[Ali Çehreli via Digitalmars-d-learn]

On 03/28/2016 11:00 PM, cy wrote:

> struct Database {
>string derp;
>Statement prepare(string s) {
>  return Statement(1234);
>}
> }
>
> struct Statement {
>int member;
>void bind(int column, int value) {
>  import std.stdio;
>  writeln("derp",member);

Change that to  and it will not segfault. It will print a value 
as low as 20. Your program is thinking that the Statement object is at 
address 20. :(


>}
>
> }
>
>
> class Wrapper {
>Database something;
>Statement prep;
>this() {
>  something = Database("...");
>  prep = something.prepare("...");
>}
> }
>
> Wrapper oops;
> void initialize() {
>oops = new Wrapper();
> }
>
> class Entry {
>Wrapper parent;
>this(Wrapper parent) {
>  //this.parent = parent;
>  //oops
>  parent = parent;
>}
>void usefulmethod() {
>  parent.prep.bind(1,42);

parent.prep.bind is translated to the following by the compiler:

"Call bind() for the object at address... let's calculate... Wherever 
parent is, we should add the offset of prep inside that object."


Since 'parent' is a class reference, implemented in terms of a CPU 
pointer, which happens to be uninitialized, meaning that its value is 0, 
the overall address is the following on my machine:


  0 + 20

As you've observed, the program never accesses location 0 for 'parent', 
rather, calculates the member starting with 'parent' and tries to access 
a location inside the first page, which is reserved by the operating 
system to catch exactly situations like this.


Ali

[Issue 15840] std.typecons.RefCounted segfaults when checking isInitialized, then segfaults GDB

[via Digitalmars-d-bugs]

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

cy  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from cy  ---
Neh, there was a null pointer dereference not being caught, that ended up
causing this problem. Accessing garbage data cast to a RefCounted.

--

Re: How to be more careful about null pointers?

[cy via Digitalmars-d-learn]

On Monday, 28 March 2016 at 21:24:48 UTC, Adam D. Ruppe wrote:
If it didn't give the error, either you swallowed it or you 
didn't actually dereference null.


Okay, so it's not actually supposed to happen. Hopefully it's 
something I did wrong...


What is the db library you are using? Did you compile it along 
with your program or use a .lib with it?


d2sqlite3: https://github.com/biozic/d2sqlite3

Compiled it along with my program. And "Database.prepare" is 
neither static, nor final. I keep describing it wrong though, 
what I ended up doing. It's easier to just write a program to 
describe it. What I ended up doing was like this:


struct Database {
  string derp;
  Statement prepare(string s) {
return Statement(1234);
  }
}

struct Statement {
  int member;
  void bind(int column, int value) {
import std.stdio;
writeln("derp",member);
  }

}


class Wrapper {
  Database something;
  Statement prep;
  this() {
something = Database("...");
prep = something.prepare("...");
  }
}

Wrapper oops;
void initialize() {
  oops = new Wrapper();
}

class Entry {
  Wrapper parent;
  this(Wrapper parent) {
//this.parent = parent;
//oops
parent = parent;
  }
  void usefulmethod() {
parent.prep.bind(1,42);
//parent.prep.execute();
//parent.prep.reset();
  }
}

void main() {
  initialize();
  auto entry = new Entry(oops);
  entry.usefulmethod();
}

That program causes a segmentation fault on my machine. Somehow 
despite never initializing Entry.parent, a class object (whose 
default init is a null pointer), I can still call methods on it, 
access members on it, and call methods on those members. No 
warnings or errors. The segfault doesn't happen until the bind() 
method.