[Issue 17367] CodeView/MSCOFF: bad debug information for enumerators

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17367] CodeView/MSCOFF: bad debug information for enumerators

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/db9a6371b6b3b921b67d3c896b8dd57dbac8e31d
fix issue 17367 - force proper alignment for elements in an enumerator field
list

https://github.com/dlang/dmd/commit/bdec3b3dcc0024ee9fd685655b62b96d3b80c3a9
Merge pull request #6741 from rainers/issue_17367

fix issue 17367 - CodeView/MSCOFF: bad debug information for enumerators

--

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 01:32:33AM +, Jack Stouffer via Digitalmars-d wrote:
> On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
> > strncpy(tmp, desc->data1, bufsz);
> > if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
> > {
> > fclose(fp);
> > unlink("blah");
> > return IO_ERROR;
> > }
> > 
> > strncpy(tmp, desc->data2, bufsz);
> > if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
> > {
> > fclose(fp);
> > unlink("blah");
> > return IO_ERROR;
> > }
> 
> I think you cause a memory leak in these branches because you forget
> to free tmp before returning.

Well, there ya go. Case in point. Even when you're consciously trying to
write "proper" C code, there are just far too many ways things can go
wrong that slip-ups are practically inevitable.

Eventually, the idiom that I (and others) eventually converged on looks
something like this:

int myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
void *resource1, *resource2, *resource3;
int ret = RET_ERROR;

/* Vet arguments */
if (!blah || !bleh || !bluh)
return ret;

/* Acquire resources */
resource1 = acquire_resource(blah->blah);
if (!resource1) goto EXIT;

resource2 = acquire_resource(bleh->bleh);
if (!resource1) goto EXIT;

resource3 = acquire_resource(bluh->bluh);
if (!resource1) goto EXIT;

/* Do actual work */
if (do_step1(blah, resource1) == RET_ERROR)
goto EXIT;

if (do_step2(blah, resource1) == RET_ERROR)
goto EXIT;

if (do_step3(blah, resource1) == RET_ERROR)
goto EXIT;

ret = RET_OK;
EXIT:
/* Cleanup everything */
if (resource3) release(resource3);
if (resource2) release(resource2);
if (resource1) release(resource1);

return ret;
}

In other words, we just converged to what essentially amounts to a
try-catch block with the manual equivalent of RAII. After a while, this
is pretty much the only way to have any confidence at all that there
isn't any hidden resource leaks or other such errors in the code.

Of course, this is only the first part of the equation. There's also
managing buffers and arrays safely, which still needs to be addressed.
We haven't quite gotten there yet, but at least some of the code now has
started moving away from C standard library string functions completely,
and towards a common string buffer type where you work with a struct
wrapper with functions for appending data, extracting the result, etc..
IOW, we're slowly reinventing a properly-encapsulated string type that's
missing from the language.

So eventually, after so much effort chasing down pointer bugs, buffer
overflows, resource leaks, and the rest of C's endless slew of pitfalls,
we're gradually reinventing RAII, try-catch blocks, and string types all
over again. It's like historians are repeating each other^W^W^W^W^W I
mean, history is repeating itself. :-D  It makes me wonder how much
longer it will take for us to gradually converge onto features that
today we're enjoying in D. Will it take another decade of segfaults,
untraceable pointer bugs, security holes, and memory leaks?  Who knows.
I'm secretly hoping that between now and then, D finally takes off and
we can finally shed this dinosaur age language that should have died
after the 70's or latest the 80's, yet still persists to this day.


> Side note: scope(exit) is one of the best inventions in PLs ever.

Ironically, D has gone so far past the woes that still plague C coders
every day that scope(exit) is hardly ever used in D anymore. :-P  It has
its uses, certainly, but in my regular D code, I'm already benefitting
so much from D's other features that I can hardly think of a use case
for scope(exit) anymore, in the context of idiomatic D.  I do regularly
find myself wishing for scope(exit) in my C code, though!


T

-- 
Век живи - век учись. А дураком помрёшь.

D is really cool

[nkm1 via Digitalmars-d]

So I spent last week (or so) learning D, and it's a great 
language.
Initially I was apprehensive about GC (non generational, 
conservative...), but now I realize that I can use D as an 
improved C (combining malloc and GC :). I always liked C better 
than C++ anyway.
I know that every bloody n00b here says something about GC :), so 
now it's my turn. I do hope that non-GC experience will get 
better in the future. D is cool, though. So, just saying.

Re: Structure of platform specific vs non platform specific code

[rikki cattermole via Digitalmars-d-learn]

On 09/05/2017 7:08 PM, Igor wrote:

On Tuesday, 9 May 2017 at 15:37:44 UTC, Stefan Koch wrote:

On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote:

On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it in DLang.


This sounds very interesting.  Maybe make it a public github project?


It can only accessible for those who bought the game.


That is right. If I manage to keep it up at least a bit more I will put
it at https://github.com/HandmadeHero but that is only accessible for
those who buy the game.

Also thanks for the suggestions. I will definitely use it for
platformServices part.

In case you are interested in the reasoning for having platform code
that imports game code Casey explains that in case where you structure
all platform specific code in functions that other code should call you
are making a needlessly big interface polluting the API space. For
example you would need CreateWindow function in such library which games
would only need to call once at startup; they won't need to create and
close additional windows during their execution and they don't even need
to know "Window" is a thing. Also some of that code is so different on
some platforms that no API can cover it clearly. For example what should
one expect CreateWindow to do on Android platform.


A render point[0] versus window:

[0] 
https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/rendering.d
[1] 
https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/window/defs.d#L17

Access specifiers and visibility

[Andrew Edwards via Digitalmars-d-learn]

Attempting to update a git repo to current D, I encounter the 
following deprecation messages:


src/glwtf/signals.d-mixin-256(256,2): Deprecation: 
glwtf.input.BaseGLFWEventHandler._on_key_down is not visible from 
module glwtf.signals
src/glwtf/signals.d-mixin-256(256,2): Deprecation: 
glwtf.input.BaseGLFWEventHandler._on_key_up is not visible from 
module glwtf.signals
src/glwtf/signals.d-mixin-256(256,2): Deprecation: 
glwtf.input.BaseGLFWEventHandler._on_mouse_button_down is not 
visible from module glwtf.signals
src/glwtf/signals.d-mixin-256(256,2): Deprecation: 
glwtf.input.BaseGLFWEventHandler._on_mouse_button_up is not 
visible from module glwtf.signals


The offending line of code in signal.d for all four messages is:

_impl.addSlot(obj, cast(void 
delegate())mixin(""~method));


these methods are implemented in the following default 
constructor:


class BaseGLFWEventHandler : AEventHandler {
// [...]
this() {
on_key_down.connect!"_on_key_down"(this);
on_key_up.connect!"_on_key_up"(this);

on_mouse_button_down.connect!"_on_mouse_button_down"(this);

on_mouse_button_up.connect!"_on_mouse_button_up"(this);

}
// [...]
}

Which are implemented in the following abstract class:

abstract class AEventHandler {
// input
Signal!(int, int, int) on_key_down;
Signal!(int, int, int) on_key_up;
Signal!(int, int) on_mouse_button_down;
Signal!(int, int) on_mouse_button_up;
}

I'm not sure how to address this issue so am seeking guidance on 
how to update this code such that it complies with current D.


Thanks,
Andrew

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:

strncpy(tmp, desc->data1, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return IO_ERROR;
}

strncpy(tmp, desc->data2, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return IO_ERROR;
}


I think you cause a memory leak in these branches because you 
forget to free tmp before returning.


Side note: scope(exit) is one of the best inventions in PLs ever.

Re: "Rolling Hash computation" or "Content Defined Chunking"

[9il via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 18:17:45 UTC, notna wrote:


I hoped there may already be something in Mir or Weka.io or 
somewhere else... Will read the Golang, C and C++ source and 
see if my Dlang is good enough for ranges and the like magic...


Hello notha,

You may want to open a PR to mir-algorithm.  I will help to make 
code idiomatic.


https://github.com/libmir/mir-algorithm

Thanks,
Ilya

Re: Fantastic exchange from DConf

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 08:30 PM, H. S. Teoh via Digitalmars-d wrote:


In this sense I agree with Walter that warnings are basically useless,
because they're not enforced. Either something is correct and compiles,
or it should be an error that stops compilation. Anything else, and you
start having people ignore warnings.



Not 100% useless. I'd much rather risk a warning getting ignored that 
NOT be informed of something the compiler noticed but decided "Nah, some 
people ignore warnings so I'll just look the other way and keep my mouth 
shut". (Hogan's Compiler Heroes: "I see NUH-TING!!")


And then the flip side is that some code smells are just to pedantic to 
justify breaking the build while the programmer is in the middle of some 
debugging or refactoring or some such.


That puts me strongly in the philosophy of "Code containing warnings: 
Allowed while compiling, disallowed when committing (with allowances for 
mitigating circumstances)."


C/C++ doesn't demonstrate that warnings are doomed to be useless and 
"always" ignored. What it demonstrates is that warnings are NOT an 
appropriate strategy for fixing language problems.




As for avoiding de-facto-deprecated functions, I've already said it:
*everybody* knows strcat is bad, and strcpy is bad, and so on and so
forth.  So how come I still see new C code being written almost every
day that continues to use these functions?  It's not that the coders
refuse to cooperate... I've seen a lot of code in my project where
people meticulously use strncpy instead of strcat / strcpy -- I presume
out of the awareness that they are "bad".  But when push comes to shove
and there's a looming deadline, all scruples are thrown to the winds and
people just take the path of least resistance.  The mere fact that
strcat and strcpy exist means that somebody, sometime, will use them,
and usually to disastrous consequences.


The moral of this story: Sometimes, breaking people's code is GOOD! ;)



And *that's* the fundamental problem with C (and in the same principle,
C++): the correct way to write code is also a very onerous, fragile,
error-prone, and verbose way of writing code. The "obvious" and "easy"
way to write C code is almost always the wrong way.  The incentives are
all wrong, and so there's a big temptation for people to cut corners and
take the easy way out.


Damn straight :)



(Nevermind the elephant in the room that 80-90% of the "optimizations"
C/C++ coders -- including myself -- have programmed into their finger
reflexes are actually irrelevant at best, because either compilers
already do those optimizations for you, or the hot spot simply isn't
where we'd like to believe it is; or outright de-optimizing at worst,
because we've successfully defeated the compiler's optimizer by writing
inscrutable code.)


C++'s fundamental paradigm has always been "Premature-optimization 
oriented programming". C++ promotes POOP.




That's another fundamental problem with the C/C++ world: coding by
convention.  We all know all too well that *if* we'd only abide by
such-and-such coding guidelines and recommendations, our code would
actually stand a chance of being correct, safe, non-leaking, etc..


Luckily, there IS a way to enforce that proper coding conventions are 
actually adhered to: It's called "compile-time error". :)

Re: Thoughts on some code breakage with 2.074

[Adam Wilson via Digitalmars-d]

On 5/9/17 20:23, Patrick Schluter wrote:

On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote:

On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via
Digitalmars-d wrote:

> [...]

[...]

[...]

[...]

I don't represent any company, but I have to also say that I
*appreciate* breaking changes that reveal latent bugs in my code. In
fact, I even appreciate breakages that eventually force me to write
more readable code!  A not-so-recent example:

[...]


The code breakage annoyance has more to do with 3rd party libraries not
very actively maintained than with active codebases imho.


*cough* Umm, I think that's a false pointer.

If it's not actively maintained, should you really be relying on it? 
Where I work, current maintenance is one of the first questions we ask, 
followed immediately by determining whether or not we are able to 
maintain it ourselves should it go unmaintained.


If you're going to take on maintenance yourself, the library is already 
missing features and you're responsible for fixing it's existing 
implementation bugs anyways, might as well do the work of upgrading it 
while you're at it.


This is the point of Open Source, we have the opportunity to take 
unmaintained code and start maintaining it again.


Either way all I hear about is corp users not liking breaking changes. 
That has been demonstrated as a false concern time and time again.


If it's a matter of unmaintained libraries, those libraries probably 
have bigger problems than breaking compiler changes, fork and upgrade 
them or write your own. Because those have always been the only two 
choices you've ever had in practice anyways. Telling the world that we 
can't make breaking changes to the compiler because it might break an 
unmaintained library is irrational position and extreme position to 
take. It will *not* win us hearts and minds.


Let's stop hiding behind our misplaced fears over corp-users and 
unmaintained libraries so that we can start improving D for everyone who 
is using it today.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

[Issue 10645] Wrong codegen for shared struct with constructor and pass to atomicLoad

[via Digitalmars-d-bugs]

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

Andrew Edwards  changed:

   What|Removed |Added

 CC||edwards...@gmail.com

--- Comment #3 from Andrew Edwards  ---
Tested on 2017-05-10 with DMD v2.074.0 on both Ubuntu 16.04 and macOS Sierra.
Produces the expected output on both systems:

buf: Test(7), orig: Test(7)

--

Re: Thank you Sociomantic for hosting DConf!

[Nicholas Wilson via Digitalmars-d-announce]

On Tuesday, 9 May 2017 at 08:18:45 UTC, Walter Bright wrote:

http://dconf.org/2017/index.html

This was a huge success, from the full house, to the great 
talks, the cameraderie, and to the tsunami of Pull Requests 
that resulted from Sunday's hackathon!


(Definitely the post-conference hackathon will become a 
standard part of the schedule!)


I hope everyone who attended had a pleasant journey back home.

And now, back to work! Looking forward to next year.


Seconded, it was the most fun I've had in a long time.
Looking forward to doing it again next year!

Nic

Re: Jonathan Blow's presentation [OT]

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 02:14 PM, Ola Fosheim Grøstad wrote:


I've kinda stopped consuming music when travelling, but I personally
prefer large headsets that enclose the ear completely. Closed ones in
non-silent environment so you don't crank the volume up too much. A bit
clunky even if foldable of course... I used some from Ultrasone, not the
best quality, but decent. I think personal taste and musical style kinda
means that you have to test them in a store to make up your mind.


Hmm, regarding large over-the-ear ones, about a year or two ago I made 
the mistake of shelling out for one of Sony's "PlayStation Gold" 
headsets. Was initially thrilled with it (except they look hideous while 
they're being worn - like any Sony headset really), but then as with 
most other people who got them, it didn't take too long before I hit the 
infamous problem of its cheap plastic (on a $100 pair??? That's Sony I 
guess) cracking and breaking. :/




I guess you could ask at the https://www.head-fi.org/ forums, but not
sure if that site is good anymore? It was a useful resource a decade
ago, but seems to be rammed down with awful ads now? Unbearable.


Thanks, I'll take a look.


Btw people say that one should keep new headset playing some heavy bass
for 10? hours after purchasing before evaluating them, something about
the coils needing to be run in. Well, they are mechanical so I guess
that makes sense (tightening, friction or something). Maybe different
for cans without coils...


Interesting, first I've heard that. Good to know.

Re: Jonathan Blow's presentation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 07:47 PM, Era Scarecrow wrote:

since the console hardware
is seriously behind PC hardware.


Side nitpick: Console hardware is behind *gaming-PC* hardware. Important 
distinction.


Heck, my most powerful PC is a little behind PS3 (in terms of game 
performance, anyway) and does everything I need it to do and then some 
(including the vast majority of indie games, which I usually prefer anyway).


And ok, yea, that's just my own stuff but still, take a look at the 
laptop market: For anything that *doesn't* have Intel graphics, you're 
looking at easily around double the price. You can get a quite good 
latptop for $400 or less. But want one with an ATI or NVIDIA (and not 
their budget "comparable with Intel Graphics" lines)? Then you're 
looking at around $1,000. But what good does that ATI or NVIDIA chipset 
do (over an Intel) for anything other than 3D modeling/animation and 
non-indie gaming? Nada (but maybe suck the battery dry).


You could say "yea, well, that's for laptops, any serious gamer's gonna 
want a desktop". But then again you'd simply be talking "gaming PC" 
again. And these days, how much point is there really in a desktop (as 
opposed to laptop) for non-gaming, non-3dsMax/Maya purposes? Minimal.


Point being: There's a big difference between "PC" and "gaming PC". In 
the context of AAA gaming, it tends to get falsely assumed that all PCs 
are gaming-PC spec. Not so. Console hardware is only behind "high-end" 
PC hardware (what I mean by "high-end" in that sentence isn't so much 
"top of the line" but simply "costs more than the highest-end console 
available").

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Tue, May 09, 2017 at 11:09:27PM +, Guillaume Boucher via Digitalmars-d 
wrote:
> On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
> > Ouch.  Haha, even I forgot about this particularly lovely aspect of
> > C.  Hooray, freely call functions without declaring them, and
> > "obviously" they return int! Why not?
> 
> To be fair, most of your complaints can be fixed by enabling compiler
> warnings and by avoiding the use of de-facto-deprecated functions
> (strnlen).

The problem is that warnings don't work, because people ignore them.
Everybody knows warnings shouldn't be ignored, but let's face it, when
you make a 1-line code change and run make, and the output is 250 pages
long (large project, y'know), any warnings that are buried somewhere in
there won't even be noticed, much less acted on.

In this sense I agree with Walter that warnings are basically useless,
because they're not enforced. Either something is correct and compiles,
or it should be an error that stops compilation. Anything else, and you
start having people ignore warnings.

Yes I know, there's gcc -Werror and the analogous flags for the other
compilers, but in a sufficiently large project, -Werror is basically
impractical because too much of legacy code will just refuse to compile,
and it's not feasible to rewrite / waste time fixing it.

As for avoiding de-facto-deprecated functions, I've already said it:
*everybody* knows strcat is bad, and strcpy is bad, and so on and so
forth.  So how come I still see new C code being written almost every
day that continues to use these functions?  It's not that the coders
refuse to cooperate... I've seen a lot of code in my project where
people meticulously use strncpy instead of strcat / strcpy -- I presume
out of the awareness that they are "bad".  But when push comes to shove
and there's a looming deadline, all scruples are thrown to the winds and
people just take the path of least resistance.  The mere fact that
strcat and strcpy exist means that somebody, sometime, will use them,
and usually to disastrous consequences.

And *that's* the fundamental problem with C (and in the same principle,
C++): the correct way to write code is also a very onerous, fragile,
error-prone, and verbose way of writing code. The "obvious" and "easy"
way to write C code is almost always the wrong way.  The incentives are
all wrong, and so there's a big temptation for people to cut corners and
take the easy way out.

It's much easier to write this:

int myfunc(context_t *ctx) {
data_desc_t *desc = ctx->data;
FILE *fp = fopen(desc->filename, "w");
char *tmp = malloc(1000);
strcpy(tmp, desc->data1);
fwrite(tmp, strlen(tmp), 1, fp);
strcpy(tmp, desc->data2);
fwrite(tmp, strlen(tmp), 1, fp);
strcpy(desc->cache, tmp);
fclose(fp);
free(tmp);
return 0;
}

rather than this:

int myfunc(context_t *ctx) {
data_desc_t *desc;
FILE *fp;
char *tmp;
size_t bufsz;

if (!ctx) return INVALID_CONTEXT;
desc = ctx->data;

if (!desc->data1 || !desc->data2) return INVALID_ARGS;

fp = fopen("blah", "w");
if (!fp) return CANT_OPEN_FILE;

bufsz = desc->data1_len + desc->data2_len + 1;
tmp = malloc(bufsz);
if (!tmp) return OUT_OF_MEMORY;

strncpy(tmp, desc->data1, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return IO_ERROR;
}

strncpy(tmp, desc->data2, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return IO_ERROR;
}

if (desc->cache)
strncpy(desc->cache, tmp, sizeof(desc->cache));

if (fclose(fp) != 0)
{
WARN("I/O error");
free(tmp);
return IO_ERROR;
}
free(tmp);
return OK;
}

Most people would probably write something in between, which is neither
completely wrong, nor completely right. But it works for 90% of the
cases, and since it meets the deadline, it's "good enough".

Notice how much longer and more onerous it is to write the "correct"
version of the code than the easy way. A properly-designed language
ought to reverse the incentives: the default, "easy" way to write code
should be the "correct", safe, non-leaking way.  Potentially unsafe,
potentially resource-leaking behaviour should require work on the part

Re: Jonathan Blow's presentation

[Era Scarecrow via Digitalmars-d]

On Tuesday, 9 May 2017 at 23:47:46 UTC, Era Scarecrow wrote:
Seems some games they decided the small amount of time spent 
decompressing audio and textures was too high  since the 
console hardware is seriously behind PC hardware.


Found an appropriate articles Regarding Titanfall (a few years 
ago), although that's for PC and the reason for giving a boost to 
'underpowered PC's', although i could have sworn they did it for 
consoles more. Still ridiculous in my mind.


http://news.softpedia.com/news/Titanfall-Needs-50GB-of-Space-on-PC-Due-to-Uncompressed-Audio-Files-431586.shtml

http://www.pcworld.com/article/3128214/software-games/why-pc-game-downloads-are-so-damned-big.html

http://www.escapistmagazine.com/news/view/132922-Titanfall-Dev-Explains-The-Games-35-GB-of-Uncompressed-Audio

Re: Jonathan Blow's presentation

[Era Scarecrow via Digitalmars-d]

On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 05/08/2017 03:28 PM, Jack Stouffer wrote:

uncompressed audio.


Uncompressed? Seriously? I assume that really means FLAC or 
something rather than truly uncompressed, but even still...


Nope, uncompressed. Seems some games they decided the small 
amount of time spent decompressing audio and textures was too 
high, which is why some of the games are 50Gb in size, because 
it's more important to have larger textures than trying to push 
the HD textures and 4k stuff, vs actually having hardware that 
can handle it, since the console hardware is seriously behind PC 
hardware.

Re: Fantastic exchange from DConf

[Guillaume Boucher via Digitalmars-d]

On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:
Ouch.  Haha, even I forgot about this particularly lovely 
aspect of C. Hooray, freely call functions without declaring 
them, and "obviously" they return int! Why not?


To be fair, most of your complaints can be fixed by enabling 
compiler warnings and by avoiding the use of de-facto-deprecated 
functions (strnlen).  The remaining problems theoretically 
shouldn't occur by disciplined use of commonly accepted C99 
guidelines.  But I agree that even then and with the use of 
sanitizers writing correct C code remains very hard.

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 09.05.2017 23:56, Timon Gehr wrote:


core.exception.AssertError@ddmd/blockexit.d(90): Assertion failure

...


Thanks! (It's a known issue though:
https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d#L330.)


I guess the problem is that I do not propagate the error condition
properly, but I'm not sure how to do it. (In my frontend, error handling
control flow is automated almost completely.)


https://github.com/dlang/dmd/pull/6760/commits/0ac9556cb3a0e1ea1de02e97e7f05e866584de84

Re: Static foreach pull request

[Andrei Alexandrescu via Digitalmars-d]

On 5/10/17 1:00 AM, Andrei Alexandrescu wrote:

On 5/10/17 12:56 AM, Timon Gehr wrote:
Thanks! (It's a known issue though: 
https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d#L330.) 



I guess the problem is that I do not propagate the error condition 
properly, but I'm not sure how to do it. (In my frontend, error 
handling control flow is automated almost completely.)


Ignorant thought: guard the static foreach with a static if? -- Andrei


(as a lowering that is)

Re: Static foreach pull request

[Andrei Alexandrescu via Digitalmars-d]

On 5/10/17 12:56 AM, Timon Gehr wrote:
Thanks! (It's a known issue though: 
https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d#L330.) 



I guess the problem is that I do not propagate the error condition 
properly, but I'm not sure how to do it. (In my frontend, error handling 
control flow is automated almost completely.)


Ignorant thought: guard the static foreach with a static if? -- Andrei

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 09.05.2017 23:39, Guillaume Boucher wrote:

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:

If you are interested in static foreach making it into the language,
please play with the implementation and tell me how to break it.


Code:

void main() {
void f() { idonotexist(); }
static foreach(j;0..0) {
f();
}
}


Output:

test_staticforeach.d(3): Error: undefined identifier 'idonotexist'
Statement::blockExit(0x7f38d5cd35e0)
static foreach (j; __error)
{
f();
}

core.exception.AssertError@ddmd/blockexit.d(90): Assertion failure

...


Thanks! (It's a known issue though: 
https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d#L330.)


I guess the problem is that I do not propagate the error condition 
properly, but I'm not sure how to do it. (In my frontend, error handling 
control flow is automated almost completely.)

Re: Static foreach pull request

[Guillaume Boucher via Digitalmars-d]

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:
If you are interested in static foreach making it into the 
language, please play with the implementation and tell me how 
to break it.


Code:

void main() {
void f() { idonotexist(); }
static foreach(j;0..0) {
f();
}
}


Output:

test_staticforeach.d(3): Error: undefined identifier 'idonotexist'
Statement::blockExit(0x7f38d5cd35e0)
static foreach (j; __error)
{
f();
}

core.exception.AssertError@ddmd/blockexit.d(90): Assertion failure

??:? _d_assertp [0x72e590]
??:? _ZN9blockExit9BlockExit5visitEP9Statement [0x637bd0]
??:? _ZN7Visitor5visitEP22StaticForeachStatement [0x625b45]
??:? _ZN22StaticForeachStatement6acceptEP7Visitor [0x61ebf8]
??:? int ddmd.blockexit.blockExit(ddmd.statement.Statement, 
ddmd.func.FuncDeclaration, bool) [0x637b69]

??:? _ZN9blockExit9BlockExit5visitEP17CompoundStatement [0x637ef9]
??:? _ZN17CompoundStatement6acceptEP7Visitor [0x61dc61]
??:? int ddmd.blockexit.blockExit(ddmd.statement.Statement, 
ddmd.func.FuncDeclaration, bool) [0x637b69]

??:? _ZN15FuncDeclaration9semantic3EP5Scope [0x5bba3d]
??:? _ZN6Module9semantic3EP5Scope [0x563f31]
??:? int ddmd.mars.tryMain(ulong, const(char)**) [0x5e2b46]
??:? _Dmain [0x5e3a12]
??:? 
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFNlZv 
[0x7301da]
??:? scope void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x730124]
??:? scope void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() [0x730196]
??:? scope void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x730124]

??:? _d_run_main [0x7300a2]
??:? main [0x5e411f]
??:? __libc_start_main [0xd4999510]

Re: Looking for an equivalent to C++ std::getline in D

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 19:11:08 UTC, Jonathan M Davis wrote:
LOL. I get the impression that it's often the tendancy of D 
folks is to get excited when D shows up as high in a list like 
Tiobe and to argue that the list doesn't mean much if D isn't 
high in the list.


AKA confirmation bias. Not unique to D folks :)

Re: Static foreach pull request

[Andrei Alexandrescu via Digitalmars-d]

On 5/9/17 3:46 PM, Timon Gehr wrote:

On 09.05.2017 08:17, rikki cattermole wrote:

On 09/05/2017 7:10 AM, Jack Stouffer wrote:

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:

...


I'm going to save you some time and tell you that Andrei and Walter are
going to require a DIP for this.


http://forum.dlang.org/thread/oenjmm$lds$1...@digitalmars.com


Also, the DIP has existed for three years, it's just not very polished:
https://wiki.dlang.org/DIP57


Cool! Now that you also have a proof of concept implementation, could 
you please flesh that up to make it solid and submit it as a PR? Thanks! 
-- Andrei

[Issue 17356] [Reg 2.075] __simd_sto no longer executed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

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

--

Trivially obvious to the most casual observer

[Walter Bright via Digitalmars-d]

On 5/9/2017 1:12 AM, Ethan Watson wrote:

So, as Walter would say, "It's trivially obvious to the casual observer."


I was surprised to learn at DConf that "trivially obvious to the most casual 
observer" was an unknown expression. Googling it shows only around 10 hits, none 
predating 2005.


I learned it at Caltech in the 1970s, where it was applied to concepts and 
proofs that were exceptionally difficult to follow.


I suppose that from now on if you hear the phrase, you can conclude that the 
source is from the set of:


1. techers

2. D programmers

:-)

Re: Looking for an equivalent to C++ std::getline in D

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, May 08, 2017 11:41:02 Daniel N via Digitalmars-d-learn wrote:
> On Monday, 8 May 2017 at 10:51:52 UTC, Ola Fosheim Grøstad wrote:
> > On Sunday, 7 May 2017 at 20:50:10 UTC, Patrick Schluter wrote:
> >> If you look on TIOBE [1] newest stats, D does not look so bad
> >> after all. It's ranked 23 with a 1.38% share. The so
> >
> > Tiobe is a "hoax".
> >
> > Stack overflow counts for alternative languages:
> >
> > "swift": 146,374
> > "scala": 65,594
> > "go": 22,212
> > "rust": 6,596
> > "d": 2,211
> > "nim": 167
>
> Stack-Overflow usage is clearly not representative of language
> usage.
> 1) Our forum is flourishing, why would any D developer use SO?
> 2) The number of questions is directly proportional with the
> difficulty of the language.(D is quite easy to learn, especially
> compared to rust).

There are a lot of different metrics that can be used to measure how popular
a language is. Tiobe and SO are just two of them. And with each metric, you
have to keep in mind how they get those numbers in order to figure out what
they indicate.

It's easy to tell that D is not as big as languages like C/C++, but it can
be much harder to tell how its usage compares to languages like Rust.

LOL. I get the impression that it's often the tendancy of D folks is to get
excited when D shows up as high in a list like Tiobe and to argue that the
list doesn't mean much if D isn't high in the list.

- Jonathan M Davis

Re: Thoughts on some code breakage with 2.074

[Patrick Schluter via Digitalmars-d]

On Tuesday, 9 May 2017 at 17:34:48 UTC, H. S. Teoh wrote:
On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via 
Digitalmars-d wrote:

> [...]

[...]

[...]

[...]

I don't represent any company, but I have to also say that I 
*appreciate* breaking changes that reveal latent bugs in my 
code. In fact, I even appreciate breakages that eventually 
force me to write more readable code!  A not-so-recent example:


[...]


The code breakage annoyance has more to do with 3rd party 
libraries not very actively maintained than with active codebases 
imho.

Re: "Rolling Hash computation" or "Content Defined Chunking"

[notna via Digitalmars-d-learn]

On Saturday, 6 May 2017 at 07:21:51 UTC, Johannes Pfau wrote:

Am Mon, 01 May 2017 21:01:43 +
schrieb notna :


Hi Dlander's.

Found some interesting reads ([1] [2] [3]) about the $SUBJECT 
and wonder if there is anything available in the Dland?!


If yes, pls. share.
If not, how could it be done (D'ish)

[1] -
https://moinakg.wordpress.com/2013/06/22/high-performance-content-defined-chunking/
 -
https://github.com/moinakg/pcompress/blob/master/rabin/rabin_dedup.c

[2] - 
https://restic.github.io/blog/2015-09-12/restic-foundation1-cdc


[3] - http://www.infoarena.ro/blog/rolling-hash

Thanks & regards


Interesting concept. I'm not aware of any D implementation but 
it shouldn't be difficult to implement this in D: 
https://en.wikipedia.org/wiki/Rolling_hash#Cyclic_polynomial


There's a BSD licensed haskell implementation, so a BSD 
licensed port

would be very easy to implement:
https://hackage.haskell.org/package/optimal-blocks-0.1.0
https://hackage.haskell.org/package/optimal-blocks-0.1.0/docs/src/Algorithm-OptimalBlocks-BuzzHash.html

To make an implementation D'ish it could integrate with either 
std.digest or process input ranges. If you want to use it 
exclusively for chunking your code can be more efficient 
(process InputRange until a boundary condition is met). When 
using input ranges, prefer some kind of buffered approach, 
Range!ubyte[] instead of Range!ubyte for better performance.


If you really want the rolling hash value for each byte in a 
sequence this will be less efficient as you'll have to enter 
data byte-by-byte. In this case it's extremely important for 
performance that your function can be inlined, so use templates:


ubyte[] data;
foreach(b; data)
{
// This needs to be inlined for performance reasons
rollinghash.put(b);
}

-- Johannes


Thanks for the feedback, Johannes.

I hoped there may already be something in Mir or Weka.io or 
somewhere else... Will read the Golang, C and C++ source and see 
if my Dlang is good enough for ranges and the like magic...

Re: Thank you Sociomantic for hosting DConf!

[Martin Tschierschke via Digitalmars-d-announce]

On Tuesday, 9 May 2017 at 17:44:12 UTC, Steven Schveighoffer 
wrote:

On 5/9/17 6:17 AM, Martin Tschierschke wrote:

On Tuesday, 9 May 2017 at 08:18:45 UTC, Walter Bright wrote:

http://dconf.org/2017/index.html




Last wish: Please change the text on the home page :)

  DConf 2017 is coming up: May 4-7 in Berlin, Germany.
  Secure your seat before it's sold out!


It's on github, where's your PR? ;)

Actually, Vladimir already obliged.

https://github.com/dlang/dconf.org/pull/201

-Steve
Sorry, but my reference was misleading: please look at dlang.org, 
yes it is on github and yes I might figure out where, but I hope 
there will be someone who has it allready in his bookmarks, and 
don't need to try to clone it on an ipad :-)

Re: Jonathan Blow's presentation [OT]

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 9 May 2017 at 17:25:37 UTC, Nick Sabalausky 
(Abscissa) wrote:
me anyway) - Any idea offhand where to find a good set of 
clip-style headphones?


Unfortunately not. I try to avoid headphones these days, too easy 
to crank up the volume without noticing, especially if you have 
good ones which can go up to 120db without distortion...


That's something I've been dying to find for years (I don't 
like "earbuds" - I find sticking thing


Yeah, don't use consumer-earbuds, can easily damage your hearing.

At this point, I don't care about cost, would just like to find 
a reliable good-sounding (ie, at least comparable to Koss's 
sound quality) clip-style. Any leads? Is there even such a 
thing has high-end, or even mid-range clip headphones?


I've kinda stopped consuming music when travelling, but I 
personally prefer large headsets that enclose the ear completely. 
Closed ones in non-silent environment so you don't crank the 
volume up too much. A bit clunky even if foldable of course... I 
used some from Ultrasone, not the best quality, but decent. I 
think personal taste and musical style kinda means that you have 
to test them in a store to make up your mind.


I guess you could ask at the https://www.head-fi.org/ forums, but 
not sure if that site is good anymore? It was a useful resource a 
decade ago, but seems to be rammed down with awful ads now? 
Unbearable.


Btw people say that one should keep new headset playing some 
heavy bass for 10? hours after purchasing before evaluating them, 
something about the coils needing to be run in. Well, they are 
mechanical so I guess that makes sense (tightening, friction or 
something). Maybe different for cans without coils...

Re: Fantastic exchange from DConf

[Patrick Schluter via Digitalmars-d]

On Tuesday, 9 May 2017 at 16:55:54 UTC, H. S. Teoh wrote:

On Tue, May 09, 2017 at 08:18:09AM +, Patrick Schluter via

[...]
Ouch.  Haha, even I forgot about this particularly lovely 
aspect of C. Hooray, freely call functions without declaring 
them, and "obviously" they return int! Why not?


There's an even more pernicious version of this, in that the 
compiler blindly believes whatever you declare a symbol to be, 
and the declaration doesn't even have to be in a .h file or 
anything even remotely related to the real definition. Here's a 
(greatly) reduced example (paraphrased from an actual bug I 
discovered):


module.c:
---
int get_passwd(char *buf, int size);


yeah, this is a code smell. A not static declared function 
prototype in a C file. Raises the alarm bells automatically now. 
The same issue but much more frequent to observe, extern variable 
declaration in .c files. That one is really widespread and few 
see it as an anti-pattern. An extern global variable should 
always be put in the header file, never in the C file. Exactly 
for the same reason as your example with the wrong prototype 
below: non matching types the linker will join wrongly.



int func() {
char passwd[100];
if (!get_passwd(buf, 100)) return -1;
do_something(passwd);
}

passwd.c:
-
void get_passwd(struct user_db *db, struct login_record *rec) {
... // stuff
}

old_passwd.c:
-
/* Please don't use this code anymore, it's deprecated. */
/*  gratuitous useless comment */
int get_passwd(char *buf, int size) { ... /* old code */ }

Originally, in the makefile, module.o is linked with 
libutil.so, which in turn is built from old_passwd.o and a 
bunch of other stuff. Later on, passwd.o was added to 
libotherutil.so, which was listed after libutil.so in the 
linker command, so the symbol conflict was masked because the 
linker found the libutil.so version of get_passwd first.


Then one day, somebody changed the order of libraries in the 
makefile, and suddenly func() mysteriously starts 
malfunctioning because get_passwd now links to the wrong 
version of the function!


Worse yet, the makefile was written to be "smart", as in, it 
uses wildcards to pick up .so files (y'know, us lazy 
programmers don't wanna have to manually type out the name of 
every library).


Yeah, we also had makefiles using wildcards. It took a long time 
but I managed to get rid of them.


So when somebody tried to fix this bug by removing old_passwd.o 
from libotherutil.so altogether, the bug was still happening in 
other developers' machines, because a stale copy of the old 
version of libotherutil.so was still left in their source tree, 
so when *they* built the executable, it contains the bug, but 
the bug vanishes when built from a fresh checkout. Who knows 
how many hours were wasted chasing after this heisenbug.



[...]

>if (fp) fclose(fp); /* oops, uninitialized ptr deref */

Worse, you didn't check the return of fclose() on writing FILE.
fclose() can fail if the disk was full. As the FILE is 
buffered, the
last fwrite might not have flushed it yet. So it is the 
fclose() that

will try to write the last block and that can fail, but the app
wouldn't be able to even report it.

[...]

Haha, you're right.  NONE of the code I've ever dealt with even 
considers this case. None at all.  In fact, I don't even 
remember the last time I've seen C code that bothers checking 
the return value of fclose().  Maybe I've written it *once* in 
my lifetime when I was young and naïve, and actually bothered 
to notice the documentation that fclose() may sometimes fail. 
Even the static analysis tool we're using doesn't report it!!


I discovered that one only a few month ago. I have now around 30 
places in our code base to fix. It's only important for writing 
FILE. Reading FILE can ignore the return values.




So again Walter was spot on: fill up the disk to 99% full, and 
99% of C programs would start malfunctioning and showing all 
kinds of odd behaviours, because they never check the return 
code of printf, fprintf, or fclose, or any of a whole bunch of 
other syscalls that are regularly *assumed* to just work, when 
in reality they *can* fail.


The worst part of all this is, this kind of C code is prevalent 
everywhere in C projects, including those intended for 
supposedly security-aware software.  Basically, the language 
itself is just so unfriendly to safe coding practices that it's 
nigh impossible to write safe code in it.  It's *theoretically* 
possible, certainly, but in practice nobody writes C code that 
way.  It is a scary thought indeeed, how much of our current 
infrastructure relies on software running this kind of code.  
Something's gotta give, eventually. And it ain't gonna be 
pretty when it all starts crumbling 

Re: Scope checking on static array struct doesn't kick in

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 13:30:49 UTC, Nordlöw wrote:

I'll write a Bugzilla issue later today.


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

Re: What are we going to do about mobile?

[H. S. Teoh via Digitalmars-d]

On Tue, May 09, 2017 at 09:08:17AM +, Joakim via Digitalmars-d wrote:
[...]
> On the other hand, even if sales are doubling, that doesn't mean you
> aren't dying.  Consider Blackberry, whose sales rocketed up even after
> the iPhone was first introduced in 2007:
> 
> https://www.recode.net/2017/2/26/14742598/blackberry-sales-market-share-chart
> 
> Then, all of a sudden, people realized, "Why are we buying these
> old-fashioned keyboard smartphones?"

FWIW, my wife hated the touchphones and clung on to her Blackberry
keyboard for as long as she could. Now she has an iphone (grudgingly)
and slowly getting the hang of it, but still complains that touch typing
is annoying.

History is a cruel master.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert

[Issue 17388] New: [DIP1000] no escape analysis for auto return scope members

[via Digitalmars-d-bugs]

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

  Issue ID: 17388
   Summary: [DIP1000] no escape analysis for auto return scope
members
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: per.nord...@gmail.com

A file named `test_scope.d` containing

@safe pure nothrow @nogc:

struct S
{
@safe pure nothrow @nogc
inout(int)[] opSlice() inout return scope
{
return x[];
}
int[4] x;
}

int[] f()
{
S s;
return s[];
}

compiled with -dip1000 correctly errors as

test_scope.d(16,13): Error: escaping reference to local variable s

but if return type of `opSlice` is changed to `auto` the compiler acccepts it
which is wrong.

--

Re: Structure of platform specific vs non platform specific code

[Igor via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 15:37:44 UTC, Stefan Koch wrote:

On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote:

On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it 
in DLang.


This sounds very interesting.  Maybe make it a public github 
project?


It can only accessible for those who bought the game.


That is right. If I manage to keep it up at least a bit more I 
will put it at https://github.com/HandmadeHero but that is only 
accessible for those who buy the game.


Also thanks for the suggestions. I will definitely use it for 
platformServices part.


In case you are interested in the reasoning for having platform 
code that imports game code Casey explains that in case where you 
structure all platform specific code in functions that other code 
should call you are making a needlessly big interface polluting 
the API space. For example you would need CreateWindow function 
in such library which games would only need to call once at 
startup; they won't need to create and close additional windows 
during their execution and they don't even need to know "Window" 
is a thing. Also some of that code is so different on some 
platforms that no API can cover it clearly. For example what 
should one expect CreateWindow to do on Android platform.

Re: DConf 2017 Hackathon report

[ANtlord via Digitalmars-d]

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including 
what is started but is likely to be finished in the coming days 
or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


Is there some news about compiling dmd as library?

Re: Thank you Sociomantic for hosting DConf!

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/9/17 6:17 AM, Martin Tschierschke wrote:

On Tuesday, 9 May 2017 at 08:18:45 UTC, Walter Bright wrote:

http://dconf.org/2017/index.html

This was a huge success, from the full house, to the great talks, the
cameraderie, and to the tsunami of Pull Requests that resulted from
Sunday's hackathon!

(Definitely the post-conference hackathon will become a standard part
of the schedule!)

I hope everyone who attended had a pleasant journey back home.

And now, back to work! Looking forward to next year.

Yes, thank you everybody, who made this event happen.

Thank you, that it was in D. (short for Germany (Deutschland))
So it was easy to attend coming from Hamburg.

Specially, a big thank you to all the speakers, sharing their D experience.

Stay tuned for the announcement of the first great upcoming D Meet-up in
Hamburg :D

Last wish: Please change the text on the home page :)

  DConf 2017 is coming up: May 4-7 in Berlin, Germany.
  Secure your seat before it's sold out!


It's on github, where's your PR? ;)

Actually, Vladimir already obliged.

https://github.com/dlang/dconf.org/pull/201

-Steve

Re: Mir Algorithm v0.5.8: Interpolation, Timeseries and 17 new functions

[9il via Digitalmars-d-announce]

On Tuesday, 9 May 2017 at 17:35:18 UTC, 9il wrote:

OK, I changed return type for *Pos functions.
No they return positions :-)


Now*

Re: Thoughts on some code breakage with 2.074

[H. S. Teoh via Digitalmars-d]

On Tue, May 09, 2017 at 02:13:34PM +0200, Adam Wilson via Digitalmars-d wrote:
> On 5/8/17 20:33, Brian Schott wrote:
> > Recently the EMSI data department upgraded the compiler we use to
> > build our data processing code to 2.074. This caused several of the
> > thousands of processes to die with signal 8 (floating point
> > exceptions). This was caused by the fix to issue 17243.
> > 
> > This is a good thing. We need more breaking changes like this.
[...]
> WUT.
> 
> All I hear on these forums is the abject terror of breaking changes
> making companies run screaming from D. You mean to say that companies
> don't actually mind breaking changes if it solves long-standing
> issues.
> 
> I'm shocked. SHOCKED I SAY!
> 
> ;-)
> 
> Can we PLEASE get more of this? I'm not saying up-end the language,
> but let's solve some problems. I doubt our corporate users will be
> very angry. I suspect that most reactions will fall between "minor
> irritation" and this one.
> 
> /me looks sideways at shared
[...]

I don't represent any company, but I have to also say that I
*appreciate* breaking changes that reveal latent bugs in my code. In
fact, I even appreciate breakages that eventually force me to write more
readable code!  A not-so-recent example:

/* Used to work, oh, I forget which version now, but it used to
 * work: */
MyType* ptr = ...;
if (someCondition && ptr) { ... }

After upgrading the compiler, I get a warning that using a pointer as a
condition is deprecated.  At first I was mildly annoyed... but then to
make the warning go away, I wrote this instead:

/* Look, ma! Self-documenting, readable code! */
MyType* ptr = ...;
if (someCondition && ptr !is null) { ... }

Much more readable, and makes intent so much clearer.  Eventually I was
very happy this supposedly "big bad" breaking change was made.

I wish Walter & Andrei & gang would introduce this sort of breakages
more often. They will both improve the language and impress users whose
code we are so afraid of breaking (I'm still not sure why).


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!

Re: Mir Algorithm v0.5.8: Interpolation, Timeseries and 17 new functions

[9il via Digitalmars-d-announce]

On Monday, 8 May 2017 at 14:26:35 UTC, jmh530 wrote:

On Monday, 8 May 2017 at 08:51:32 UTC, 9il wrote:

## New modules
...


Great work.

Some comments:

mir.timeseries is a welcome addition. Calling (time, data) 
pairs moments will confuse because moment has another meaning 
in statistics. Perhaps observation?


Thanks. Fixed.
Also, Series might also include data labels for columns. And 
access by data label.


I do not see good @nogc solution for now. PRs are welcome!


The second part of the example for
mir.ndslice.topology: slide
is not that intuitive. It seems like what you're basically 
doing is the same as

assert(sw == [8, 12, 16, 20, 24, 28, 32, 36]);
(or something) but it's just less obvious to do it by a formula.


Fixed

I don't know how strongly I feel about this, but I find the 
naming between minIndex/maxIndex and minPos/maxPos and 
minmaxIndex/minmaxPos strange. All three produce indices, it's 
just that the Pos do it backwards and minmax give both min and 
max. It seems like a lot of separate functions for things that 
could be done with one multi-purpose template. Regardless, if 
you keep it the way it is, then maybe given the plethora of 
finding functions, split it off to a separate module?


OK, I changed return type for *Pos functions.
No they return positions :-)

Thank you for the comments!

Best,
Ilya

Re: Turn .opApply into ranges

[Stefan Koch via Digitalmars-d]

On Tuesday, 9 May 2017 at 17:23:36 UTC, Yuxuan Shui wrote:
I wondered if I can turn struct that defines opApply into 
ranges.


And it turns out to be surprisingly easy:

https://gist.github.com/yshui/716cfe987c89997760cabc2c951ca430

Maybe we can phase out opApply support in foreach? ;)

BTW, is there a way to get the "element type" from .opApply?


This "conversion" relies on fibers which need heavy runtime 
support.

So no, opApply still has it's place.

Re: Jonathan Blow's presentation [OT]

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 12:58 PM, Ola Fosheim Grøstad wrote:


 Use a good headset (E.g. Sennheiser
HD600 or better) and preferably use the same headset the audio engineer
used... Loudspeaker in room -> not the same signal as on the CD.



You seem to know a thing or two about audio hardware (more than me 
anyway) - Any idea offhand where to find a good set of clip-style 
headphones? That's something I've been dying to find for years (I don't 
like "earbuds" - I find sticking thing inside my ears to be terribly 
uncomfortable, even compared to the occasion pinch of clip-style, and 
traditional are always just falling off in casual use).


I used to use Koss's clip-style (and loved the one with in-line volume 
control) since, despite being affordable, they were the only ones I'd 
ever found that didn't sound horrible (all the Sony ones of remotely 
comparable price sounded like complete trash no matter what the box 
claimed about its specs...and the Sonys are downright ugly to boot. 
Other brands didn't fare any better.)


Unfortunately, after a few years, both my Koss pairs crapped out (ie, no 
sound period out one or both speakers), and the non-free "warranty" 
replacements consistently crapped out the same way after about two 
months max (sounded good until then, though).


At this point, I don't care about cost, would just like to find a 
reliable good-sounding (ie, at least comparable to Koss's sound quality) 
clip-style. Any leads? Is there even such a thing has high-end, or even 
mid-range clip headphones?

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Tue, May 09, 2017 at 07:13:31AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/8/2017 1:55 PM, John Carter wrote:
> > On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
> > 
> > > Walter: I believe memory safety will kill C.
> > 
> > C/C++ has been granted an extension of life by the likes of valgrind
> > and purify and *-sanitizer.
> 
> I agree. But one inevitably runs into problems relying on valgrind and
> other third party tools:
> 
> 1. it isn't part of the language

And it doesn't catch everything.


> 2. it may not be available on your platform

And may not be compatible with your target architecture -- a lot of C
code, especially in the embedded realm, have curious target archs that
could be problematic for 3rd party tools that need to inject runtime
instrumentation.


> 3. somebody has to find it, install it, and integrate it into the
> dev/test process

This is a big one. Many large C projects have their own idiomatic way of
building, which is often incompatible with 3rd party tools.  This is a
major demotivator for people to want to use those tools, because it's a
big time investment to configure the tool to work with the build
scripts, and an error-prone and painful process to rework the build
scripts to work with the tool. "Why break our delicate tower-of-cards
build system that's worked just fine for 20 years, just to run this
new-fangled whatever 3rd party thingy promulgated by these young
upstarts these days?"


> 4. it's incredibly slow to run valgrind, so there are powerful
> tendencies to skip it

Yes, it's an extra step that the developer has to manually run, when he
is already under an unreasonable deadline to meet an unreasonable
customer request upon which hinges a $1M deal so you can't turn it down
no matter how unreasonable it is.  He barely has enough time to write
code that won't crash outright, nevermind writing *proper* code. Yet
another extra step to run manually? Forget it, not gonna happen.  Not
until a major crash happens on the customer's site that finally
convinces the PTB to dictate the use of valgrind as a part of regular
work routine.  Other than that, the chances of someone actually
bothering to do it are slim indeed.


> valgrind is a stopgap measure, and has saved me much grief over the
> years, but it is NOT the solution.

Yes, it's a patch over the current festering wound so that, at least for
the time being, the blood is out of sight.  But you can't wear that
patch forever. Sooner or later the gangrene be visible on the surface.
:-D


T

-- 
Change is inevitable, except from a vending machine.

Turn .opApply into ranges

[Yuxuan Shui via Digitalmars-d]

I wondered if I can turn struct that defines opApply into ranges.

And it turns out to be surprisingly easy:

https://gist.github.com/yshui/716cfe987c89997760cabc2c951ca430

Maybe we can phase out opApply support in foreach? ;)

BTW, is there a way to get the "element type" from .opApply?

[Issue 3075] Implement parameter contravariance

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #28 from Walter Bright  ---
Reopened because contravariance really should work.

--

Re: Fantastic exchange from DConf

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 06:29 AM, Adrian Matoga wrote:

On Tuesday, 9 May 2017 at 09:22:13 UTC, Joakim wrote:

On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote:

On Mon, May 08, 2017 at 06:33:08PM +, Jerry via Digitalmars-d wrote:

[...]


Is that a subtle joke, or are you being serious?

[...]


Heh, I saw you wrote the post and knew it would be long, then I kept
scrolling and scrolling... :)

Please, please, please submit this as a post on the D blog, perhaps
prefaced by the Walter/Scott exchange and with some links to the
issues you mention and the relevant portions of the D reference.  I
think it would do well.


+1


+ a kajillion (give or take a few hundred)

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Tue, May 09, 2017 at 08:18:09AM +, Patrick Schluter via Digitalmars-d 
wrote:
> On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote:
> > 
> > int my_func(mytype_t *input, outbuf_t *output_buf,
> > char *buffer, int size)
> > {
> > /* Typical lazy way of null-checking (that will blow up
> >  * later) */
> > myhandle_t *h = input ? input->handle : 0;
> > writer_t *w = output_buf ? output_buf->writer : 0;
> > char *block = (char *)malloc(size);
> 
> Hey, you've been outed as a C++ programmer. A real C programmer never
> casts a void *. In that specific case, casting away the malloc()
> return can mask a nasty bug. If you have forgotten to include the
> header declaring the function, the compiler would assume an int
> returning function and the cast would suppress the righteous warning
> message of the compiler. On 64 bit machines the returned pointer would
> be truncated to the lower half.  Unfortunately on Linux, as the heap
> starts in the lower 4 GiB of address space, the code would run for a
> long time before it crashed. On Solaris-SPARC it would crash directly
> as binaries are loaded address 0x1__ of the address space.

Ouch.  Haha, even I forgot about this particularly lovely aspect of C.
Hooray, freely call functions without declaring them, and "obviously"
they return int! Why not?

There's an even more pernicious version of this, in that the compiler
blindly believes whatever you declare a symbol to be, and the
declaration doesn't even have to be in a .h file or anything even
remotely related to the real definition. Here's a (greatly) reduced
example (paraphrased from an actual bug I discovered):

module.c:
---
int get_passwd(char *buf, int size);
int func() {
char passwd[100];
if (!get_passwd(buf, 100)) return -1;
do_something(passwd);
}

passwd.c:
-
void get_passwd(struct user_db *db, struct login_record *rec) {
... // stuff
}

old_passwd.c:
-
/* Please don't use this code anymore, it's deprecated. */
/*  gratuitous useless comment */
int get_passwd(char *buf, int size) { ... /* old code */ }

Originally, in the makefile, module.o is linked with libutil.so, which
in turn is built from old_passwd.o and a bunch of other stuff. Later on,
passwd.o was added to libotherutil.so, which was listed after libutil.so
in the linker command, so the symbol conflict was masked because the
linker found the libutil.so version of get_passwd first.

Then one day, somebody changed the order of libraries in the makefile,
and suddenly func() mysteriously starts malfunctioning because
get_passwd now links to the wrong version of the function!

Worse yet, the makefile was written to be "smart", as in, it uses
wildcards to pick up .so files (y'know, us lazy programmers don't wanna
have to manually type out the name of every library). So when somebody
tried to fix this bug by removing old_passwd.o from libotherutil.so
altogether, the bug was still happening in other developers' machines,
because a stale copy of the old version of libotherutil.so was still
left in their source tree, so when *they* built the executable, it
contains the bug, but the bug vanishes when built from a fresh checkout.
Who knows how many hours were wasted chasing after this heisenbug.


[...]
> > if (w->buffered) { /* oops, possible null deref */
> > strncpy(buffer, input->data, size); /* oops, 
> > unterminated string */
> > if (w->write(buffer, size) != 0)
> > /* hmm, is 0 the error status, or is it -1? */
> > /* also, what if w->write == null? */
> 
> Or is it inspired by fwrite, which returns the number of written
> records? In that case 0 return might be an error or not, depends on
> size.

Yep, fwrite has an utterly lovely interface. The epitome of API design.
:-D


[...]
> > if (fp) fclose(fp); /* oops, uninitialized ptr deref */
> 
> Worse, you didn't check the return of fclose() on writing FILE.
> fclose() can fail if the disk was full. As the FILE is buffered, the
> last fwrite might not have flushed it yet. So it is the fclose() that
> will try to write the last block and that can fail, but the app
> wouldn't be able to even report it.
[...]

Haha, you're right.  NONE of the code I've ever dealt with even
considers this case. None at all.  In fact, I don't even remember the
last time I've seen C code that bothers checking the return value of
fclose().  Maybe I've written it *once* in my lifetime when I was young
and naïve, and actually bothered to notice the documentation that
fclose() may sometimes fail. Even the static analysis tool we're using
doesn't report it!!

So again Walter was spot on: fill up the disk 

Re: Jonathan Blow's presentation

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 9 May 2017 at 16:26:35 UTC, Ola Fosheim Grøstad wrote:
Some things like phasing/smearing in high frequency content and 
imaging does affect the experience, although the effect is very


I want to add that of course, modern commercial music is already 
ruined by too much compression and dynamic abuse so it is 
distorted from the beginning... just to get a loud signal. Trash 
in -> trash out. Same with speakers. Regular speakers are poor. 
Use a good headset (E.g. Sennheiser HD600 or better) and 
preferably use the same headset the audio engineer used... 
Loudspeaker in room -> not the same signal as on the CD.


Anyway, it is a complicated topic. I went to a two hours lecture 
on it a week ago. We were told to use this book: Applied Signal 
Processing: A MATLAB™-Based Proof of Concept by Dutoit and 
Marqués. It comes with code in matlab so you can modify the mp3 
algorithms and explore the effects yourself. :)

Re: Jonathan Blow's presentation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/09/2017 04:44 AM, Patrick Schluter wrote:

On Tuesday, 9 May 2017 at 08:24:40 UTC, Nick Sabalausky (Abscissa) wrote:

On 05/09/2017 02:10 AM, Patrick Schluter wrote:

Interesting. Any links? Not familiar with what "c't" is.


https://www.heise.de/ct/artikel/Kreuzverhoertest-287592.html

So, I got some details wrong in my recollection from memory. They
compared 128 kbit/s, 256 kbit/s and CD. To remove bias, they burnt the
mp3 after decompression on CD so that the testers couldn't distinguish
between the 3 formats and played them in their high quality audio setup
in their studios. The result was surprizing in that there was no
difference between CD and 256K mp3, and only a slightly lower score for
128K mp3.


Not surprised the 128k MP3 was noticeable. Even I've been able to notice 
that when I was listening for it (although, in retrospect, it was likely 
a bad encoder, now that I think about it...)



They were also surprized that for some kind of music
(classical), the mp3 128K was even favored by some testers over the
other formats and they speculate that the encoding rounds out somehow
some roughness of the music.
They also had one tester who was 100% accurate at recognizing mp3 over
CD, but the guy had had a hearing accident in his youth where he lost
part of the hearing spectrum (around 8KHz) which breaks the
psycho-acoustic model and allows him to hear noise that is suppressed
for the not hearing impared.



Fascinating.

The 128k being sometimes favored for classical kinda reminds me of how 
some people prefer vinyl over CD/etc. Both are cases of audio data being 
lost, but in a way that is liked.



I don't know where I got the 160 KBit part of my message.



Your memory recall must've applied a low-pass filter over "128K" and 
"256K" ;)

Re: Fantastic exchange from DConf

[Martin Tschierschke via Digitalmars-d]

On Tuesday, 9 May 2017 at 09:22:13 UTC, Joakim wrote:

On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote:
On Mon, May 08, 2017 at 06:33:08PM +, Jerry via 
Digitalmars-d wrote:

[...]


Is that a subtle joke, or are you being serious?

[...]


Heh, I saw you wrote the post and knew it would be long, then I 
kept scrolling and scrolling... :)


Please, please, please submit this as a post on the D blog, 
perhaps prefaced by the Walter/Scott exchange and with some 
links to the issues you mention and the relevant portions of 
the D reference.  I think it would do well.


+=1; Yes, good idea!

Re: Jonathan Blow's presentation

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 9 May 2017 at 08:12:20 UTC, Ethan Watson wrote:
That's the point of the blind test. It isn't trivially obvious 
to the casual observer. You might think it is, but you're not a 
casual observer.


Well the point of a blind test is more to establish validity for 
something having a different effect, but not for establishing 
that it isn't different. i.e. false vs unknown, so in the latter 
case it would be inconclusive.


These 2 statements are very different:

1. we have not been able to establish that there was any 
perceived difference

2. we have established that there was no perceived difference

How would they research this? By asking if one is better than the 
other? Well, that is highly subjective. Because better has to do 
with expectations. Anyway, cognitive analysis of difference is 
rather at a high level and for many something sounds the same if 
they interpret the signal the same way. Whereas immersion is much 
more subtle and depends on your state of mind also, not only what 
you perceive. So not easy to measure! Our perceptual machine is 
not a fixed machine, our expectations and mood feeds back into 
the system.


Some things like phasing/smearing in high frequency content and 
imaging does affect the experience, although the effect is very 
subtle and you need good head sets and having heard the original 
many times to pinpoint where the differences are at higher 
bitrates. (at 300kbit/s it probably isn't all that easy).

Re: Fantastic exchange from DConf

[Patrick Schluter via Digitalmars-d]

On Tuesday, 9 May 2017 at 14:13:31 UTC, Walter Bright wrote:

On 5/8/2017 1:55 PM, John Carter wrote:

On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:


Walter: I believe memory safety will kill C.


C/C++ has been granted an extension of life by the likes of 
valgrind and purify

and *-sanitizer.


I agree. But one inevitably runs into problems relying on 
valgrind and other third party tools:


1. it isn't part of the language

2. it may not be available on your platform

3. somebody has to find it, install it, and integrate it into 
the dev/test process


4. it's incredibly slow to run valgrind, so there are powerful 
tendencies to skip it


valgrind is a stopgap measure, and has saved me much grief over 
the years, but it is NOT the solution.


And it doesn't catch everything. I had the case yesterday at work 
where one of the file converters that had been written 15 years 
ago, suddenly crashed in production*. It came from an upstream 
bug in a script that filled one attribute with garbage. I tried 
to reproduce the bug in the development environment and funily it 
didn't crash with newest version of the base library. The 
production library is one version behind. The garbage in the 
attribute triggered a buffer overflow in a fixed size array (496 
UTF-16 characters in a buffer of 200 character size). This 
converter is one of the last one with fixed sized arrays. The 
interesting observation was that valgrind catches the buffer 
overflow when linked with version 2.31 of the main library but is 
completely silent when using version 2.32. The changes in that 
library are minimal and in parts that have nothing to do with 
this app. It is solely the placement of variables in data iand 
the bss that change. It is surprizing to see such a big buffer 
overflow completely missed by valgrind.


TL;DR valgrind does not always catch buffer overflows especially 
if the memory overwritten is not in the head but in the data or 
the bss segment. There it cannot add guard pages as it does on 
the heap.


* To give a little context. I work at the European Commission on 
the central translation memory system called Euramis (probably 
the biggest in the world with more than a billion segments). The 
system is used intensively by all translators of all European 
institutions and without it, nothing would be possible. The issue 
with it is that the back end is written in C and the code goes 
back to 1990. Me and my colleagues managed to modernize the 
system and catch most of the code issues with intensive use of 
C99 idioms, newest gcc and clang diagnostics and also valgrind 
and such things.

Re: DConf 2017 Hackathon report

[Nemanja Boric via Digitalmars-d]

On Tuesday, 9 May 2017 at 16:14:57 UTC, Nemanja Boric wrote:

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, 
including what is started but is likely to be finished in the 
coming days or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


I've fixed the FreeBSD-Current exception handling issue, so
that exception handling is now working there as well (I also 
suspect
that it was broken pretty much on all libundwind 64bit systems, 
just worked by accident, since the optimizer didn't try too 
hard.


It's something I wanted to do for a long time, but there's 
never time,

so having a day dedicated to it was pretty helpful!

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

It was pretty cool finding Jonathan who filed the bug in the 
same room, then
chasing Walter to talk about it, after hearing all war stories, 
including,

but not limited to, blue meteors.


Oh, also working with Martin and chasing him around the rooms to 
get
my druntime PR for fiber stack overflow protection 
(https://github.com/dlang/druntime/pull/1698)
merged after months and months is also worth mentioning, although 
it didn't happen during the hackaton :-)

Re: Working code in an upcoming PR by Timon Gehr

[Yuxuan Shui via Digitalmars-d-announce]

On Tuesday, 9 May 2017 at 13:19:09 UTC, Timon Gehr wrote:

On 07.05.2017 19:03, Stanislav Blinov wrote:
On Sunday, 7 May 2017 at 16:57:58 UTC, Andrei Alexandrescu 
wrote:

[...]


I see only unsurprising Jpeg artifacts and not much more :)
It's too low resolution to make anything out.


It's approximately this:

---
alias Seq(T...)=T;

void main(){
import std.stdio: writeln;
import std.conv: to;
static foreach(i;Seq!(0,1,2)){
mixin(`int x`~to!string(i)~" = i;");
}
writeln(x0," ",x1," ",x2);
}

---
./src/dmd -run staticforeach.d
DMD v2.075.0-devel-fd4ff76 DEBUG
0 1 2
---

That was the first test case that worked.
I have made it almost feature-complete yesterday:

https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d


Yes! Finally!

Re: DConf 2017 Hackathon report

[Nemanja Boric via Digitalmars-d]

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including 
what is started but is likely to be finished in the coming days 
or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


I've fixed the FreeBSD-Current exception handling issue, so
that exception handling is now working there as well (I also 
suspect
that it was broken pretty much on all libundwind 64bit systems, 
just worked by accident, since the optimizer didn't try too hard.


It's something I wanted to do for a long time, but there's never 
time,

so having a day dedicated to it was pretty helpful!

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

It was pretty cool finding Jonathan who filed the bug in the same 
room, then
chasing Walter to talk about it, after hearing all war stories, 
including,

but not limited to, blue meteors.

[Issue 17354] An overload in a final class can silently hide base methods

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6731

--

[Issue 16600] Wrong error message for ambiguous mutable/immutable constructor

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #2 from Walter Bright  ---
Reopened as it is no longer an error:

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

--

Re: Structure of platform specific vs non platform specific code

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote:

On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it 
in DLang.


This sounds very interesting.  Maybe make it a public github 
project?


It can only accessible for those who bought the game.

Re: Structure of platform specific vs non platform specific code

[WhatMeWorry via Digitalmars-d-learn]

On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it in 
DLang.


This sounds very interesting.  Maybe make it a public github 
project?

[Issue 17387] static struct this(ref) not pure

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from ag0ae...@gmail.com ---
You have to mark the constructor as `pure`:

struct S { this(ref int val) pure { ++val; } }

Attributes are only inferred under special circumstances. You generally have to
be explicit with them. Closing as invalid. Please reopen if I'm missing the
point.

--

[Issue 17387] New: static struct this(ref) not pure

[via Digitalmars-d-bugs]

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

  Issue ID: 17387
   Summary: static struct this(ref) not pure
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

struct S { this(ref int val) { ++val; } }

pure unittest
{
int val = 3;
auto s = S(val);
assert(val == 4);
}

The above fails to compile with dmd v2.074.0:
purestaticstruct.d(6): Error: pure function 'purestaticstruct.__unittestL3_1'
cannot call impure constructor 'purestaticstruct.S.this'

If the struct is moved inside the unittest, it compiles as expected.

--

Re: -vcg-ast dmd command line switch

[Stefan Koch via Digitalmars-d]

On Sunday, 7 May 2017 at 15:16:48 UTC, Ali Çehreli wrote:
I've just commented on the following thread on the 'internals' 
newsgroup:


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


I think this should be improved to display code that is being 
mixed-in.


Ali


I just submitted a PR.
This will give you now all templates and mixin templates.
Of course it'll also print string-mixins.

[Issue 17386] Internal error: backend\cgcod.c 1841

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com

--

[Issue 17386] New: Internal error: backend\cgcod.c 1841

[via Digitalmars-d-bugs]

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

  Issue ID: 17386
   Summary: Internal error: backend\cgcod.c 1841
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugreport.seijifuj...@gmail.com

/*
Title: Internal error: backend\cgcod.c 1841
dmd version: dmd.2.074.0
dmd option: dmd -c -m64 -O -release 

Internal error conditions
-
1. dmd.2.073.0 - dmd.2.074.0 only
2. dmd option is "m64 - O - release"
3. asm.dlang.org confirmed that internal error occurred in "dmd nightly build,
- m64 - O - release"
4. The following code is minimized by Dustmite
*/
int[] bezier() {

int[] polygon ;
for (int i ; ; i++) {
double t = i ;
polygon[2 * i] = cast(int)(t * t );
}
}

/*
Original code:
location: dwt
org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\custom\CBanner.d(161):
int[] bezier(int x0, int y0, int x1, int y1, int x2, int y2, int x3, int y3,
int count) {


int[] bezier(int x0, int y0, int x1, int y1, int x2, int y2, int x3, int y3,
int count) {
// The parametric equations for a Bezier curve for x[t] and y[t] where 
0 <= t <=1 are:
// x[t] = x0 + 3 (x1 - x0) t + 3 (x0 + x2 - 2x1) t ^ 2 + (x3 - x0 + 3x1
- 3x2) t ^ 3
// y[t] = y0 + 3 (y1 - y0) t + 3 (y0 + y2 - 2y1) t ^ 2 + (y3 - y0 + 3y1
- 3y2) t ^ 3

double a0 = x0;
double a1 = 3 * (x1 - x0);
double a2 = 3 * (x0 + x2 - 2 * x1);
double a3 = x3 - x0 + 3 * x1 - 3 * x2;
double b0 = y0;
double b1 = 3 * (y1 - y0);
double b2 = 3 * (y0 + y2 - 2 * y1);
double b3 = y3 - y0 + 3 * y1 - 3 * y2;

int[] polygon = new int[2 * count + 2];
for (int i = 0; i <= count; i++) {
double t = cast(double) i / cast(double) count;
polygon[2 * i] = cast(int)(a0 + a1 * t + a2 * t * t + a3 * t * t *
t);
polygon[2 * i + 1] = cast(int)(b0 + b1 * t + b2 * t * t + b3 * t * t *
t);
}
return polygon;
}

/// Dustmite 
// dmd -c -m64 -O -release  CBanner_dmdInternalerror.d > out.txt
// dustmite src "dmd -c -m64 -O -release CBanner_dmdInternalerror.d | diff -
..\out.txt"

*/

--

Re: Fantastic exchange from DConf

[Walter Bright via Digitalmars-d]

On 5/8/2017 1:55 PM, John Carter wrote:

On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:


Walter: I believe memory safety will kill C.


C/C++ has been granted an extension of life by the likes of valgrind and purify
and *-sanitizer.


I agree. But one inevitably runs into problems relying on valgrind and other 
third party tools:


1. it isn't part of the language

2. it may not be available on your platform

3. somebody has to find it, install it, and integrate it into the dev/test 
process

4. it's incredibly slow to run valgrind, so there are powerful tendencies to 
skip it

valgrind is a stopgap measure, and has saved me much grief over the years, but 
it is NOT the solution.

Re: Error writing file a *.obj

[bachmeier via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 02:33:06 UTC, dummy wrote:

On Monday, 8 May 2017 at 12:29:27 UTC, bachmeier wrote:

On Monday, 8 May 2017 at 11:56:10 UTC, dummy wrote:


When i build some application with dub, i got this error:


I'm not a Dub user, but it has its own forum, so you might 
want to try there:

http://forum.rejectedsoftware.com/


Oh, i solve this problem my self...
because, the 'Ransomeware Protection' feature of Bitdefender 
InternetSecurity 2017.

dub and dmd working pretty when i turn off this feature.

Very sorry for noob question :/


This is not really a noob question. Since it affects new users 
trying to run a Hello World program, I wonder if it would be 
worthwhile to add that information to the error message. Most of 
the people trying out D will simply give up and blame the 
language.

Re: Structure of platform specific vs non platform specific code

[rikki cattermole via Digitalmars-d-learn]

On 09/05/2017 2:53 PM, Jacob Carlborg wrote:

On 2017-05-08 23:16, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it in DLang. I
got to Day 011: The Basics of Platform API Design where Casey explains
the best way to structure platform specific vs non-platform specific
code but his method cannot work in DLang since it uses modules and I am
wondering what would be the best way to achieve the same in DLang.

His way is to have these files:
- platform.cpp (includes game.cpp directly, not game.h)
- game.h (declares non-platform specific data types for communicating
with platform layer and both game functions that platform layer needs to
call and platform functions that game needs to call)
- game.cpp (includes game.h and defines declared game functions)

This scheme makes preprocessor actually merge all files into one but
logically game.* files see nothing that is platform specific.

The best idea for DLang I have is to separate platform into two modules:

- platform.d (contains only code that needs to call into game code so it
imports game.d)
- platformServices.d (contains only code that game needs to call but
wrapped in a common abstraction layer so game.d imports it)


When it comes to platform specific code, one way to do it is to use one
module per platform and then one common module that publicly imports the
platform specific modules:

module linux;

module windows;

module osx;

module platform;

version (linux)
public import linux;

else version (Windows)
public import windows;

else version (OSX)
public import osx;

else
static assert("unsupported platform");

Without having looked at the above mentioned guide (or whatever it is),
I would say that it would make more sense that if the game module
imports that platform module than the other way around.


Homemade hero is a video series by an experienced game dev on how to 
make a game from 0 to finish (still active!).

But yes this technique makes more sense for D then the original one.

Re: DConf 2017 Hackathon report

[Steven Schveighoffer via Digitalmars-d]

On 5/9/17 9:19 AM, Steven Schveighoffer wrote:

Aaaand, I'm not questioning whether the PR I made is sound, due to the
way template-instantiated static ctors work. I'll have to rethink how it
works.


*now* questioning...

-Steve

Re: Structure of platform specific vs non platform specific code

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-08 23:16, Igor wrote:

Hi,

I am following Casey Muratori's Handmade Hero and writing it in DLang. I
got to Day 011: The Basics of Platform API Design where Casey explains
the best way to structure platform specific vs non-platform specific
code but his method cannot work in DLang since it uses modules and I am
wondering what would be the best way to achieve the same in DLang.

His way is to have these files:
- platform.cpp (includes game.cpp directly, not game.h)
- game.h (declares non-platform specific data types for communicating
with platform layer and both game functions that platform layer needs to
call and platform functions that game needs to call)
- game.cpp (includes game.h and defines declared game functions)

This scheme makes preprocessor actually merge all files into one but
logically game.* files see nothing that is platform specific.

The best idea for DLang I have is to separate platform into two modules:

- platform.d (contains only code that needs to call into game code so it
imports game.d)
- platformServices.d (contains only code that game needs to call but
wrapped in a common abstraction layer so game.d imports it)


When it comes to platform specific code, one way to do it is to use one 
module per platform and then one common module that publicly imports the 
platform specific modules:


module linux;

module windows;

module osx;

module platform;

version (linux)
public import linux;

else version (Windows)
public import windows;

else version (OSX)
public import osx;

else
static assert("unsupported platform");

Without having looked at the above mentioned guide (or whatever it is), 
I would say that it would make more sense that if the game module 
imports that platform module than the other way around.


--
/Jacob Carlborg

Re: DIP 1004 Preliminary Review Round 1

[Mike Parker via Digitalmars-d]

On Tuesday, 9 May 2017 at 12:52:38 UTC, deadalnix wrote:

On Monday, 8 May 2017 at 08:25:24 UTC, Andrej Mitrovic wrote:

Thoughts?


It seems like the most sensible path forward. Mike ?


Works for me.

D language usage by hour of the day and workday/weekend

[Juanjo Alvarez via Digitalmars-d-announce]

A coworker from the data science department of my company did 
some commit-crunching and plotting over 452 million commits on 
github:


https://www.reddit.com/r/programming/comments/6a5bb8/workdays_vs_weekends_morning_vs_night_github/

Looks like (PST timezone) D programmers are more active from 
15:00 to 01:00 and weekends!

Re: Scope checking on static array struct doesn't kick in

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 12:25:29 UTC, Nordlöw wrote:

On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote:
I've tagged the ref-returning functions (in this case 
`opSlice`) with `return scope` for my statically allocated 
array struct at


Here's a simpler example

https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d


If I change the return value of `S.opSlice` to `int[]` correct 
`scope`-error handling kicks in.


Tha is, scope checking via -dip1000 works for

struct S
{
@safe pure nothrow @nogc
int[] opSlice() return scope
{
return x[];
}
int[4] x;
}

but not for

struct S
{
@safe pure nothrow @nogc
auto opSlice() return scope
{
return x[];
}
int[4] x;
}

.

I'll write a Bugzilla issue later today.

Re: Scope checking on static array struct doesn't kick in

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 12:25:29 UTC, Nordlöw wrote:

On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote:
I've tagged the ref-returning functions (in this case 
`opSlice`) with `return scope` for my statically allocated 
array struct at


Here's a simpler example

https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d


Looks like a bug, if you change "auto" to "int[]" it starts 
complaining in f(). I have a question though, why is the syntax 
like this:



auto opSlice() return scope;


?

I don't see such in the DIP, proposed there is simply "scope" to 
the left of the declaration, i.e.



scope auto opSlice();


Although with that syntax dmd complains about escaping 'this', as 
if it was scope { auto opSlice(); }.


Is 'return scope' the syntax that is supposed to be used and it's 
just not reflected in the DIP, or?..

Re: Working code in an upcoming PR by Timon Gehr

[Timon Gehr via Digitalmars-d-announce]

On 07.05.2017 19:03, Stanislav Blinov wrote:

On Sunday, 7 May 2017 at 16:57:58 UTC, Andrei Alexandrescu wrote:

Zoom in on the screen for a nice surprise! http://imgur.com/a/qjI4l --
Andrei


I see only unsurprising Jpeg artifacts and not much more :)
It's too low resolution to make anything out.


It's approximately this:

---
alias Seq(T...)=T;

void main(){
import std.stdio: writeln;
import std.conv: to;
static foreach(i;Seq!(0,1,2)){
mixin(`int x`~to!string(i)~" = i;");
}
writeln(x0," ",x1," ",x2);
}

---
./src/dmd -run staticforeach.d
DMD v2.075.0-devel-fd4ff76 DEBUG
0 1 2
---

That was the first test case that worked.
I have made it almost feature-complete yesterday:

https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d

Re: DConf 2017 Hackathon report

[Steven Schveighoffer via Digitalmars-d]

On 5/9/17 12:35 AM, Ali Çehreli wrote:

Please list what we've achieved during the hackathon, including what is
started but is likely to be finished in the coming days or months.

For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is now up to
date but I could not get to the still manual work of preparing the ebooks)


Nice!

For me:

- Don't want to exactly steal Jonathan's thunder, but during the 
conference (before the hackathon actually) he split (and I helped get 
approval for splitting) std.datetime into a package. That still needs 
some severe TLC on making the docs read better, but it should be viable. 
And now github can show diffs for the smaller files :)


- Merged a simple PR I had from April.

- Provided a bit of guidance to people on druntime internals.

- Created my first DMD PR (to make it so unittest imports are not 
counted for cycle detection).


And that's about it. That last one took a lot of effort, as I was 
dealing with an apparent bug in the BitArray type, thought I was losing 
my mind :)


Aaaand, I'm not questioning whether the PR I made is sound, due to the 
way template-instantiated static ctors work. I'll have to rethink how it 
works.


But it was very awesome to be able to go around and find the people to 
discuss a PR/idea without going through a forum thread. I think there's 
a psychological barrier that happens when you post a complete argument, 
and then your counterpart forms an interpretation in their mind of what 
the argument means, forms their complete counter argument, and neither 
side really understands what the other is saying or willing to do. Doing 
it in person allows so much more interaction -- you can cut off early 
any misinterpretations. It's also harder to be nasty in person :)


-Steve

[Issue 17349] Covariant overrides should be allowed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17354] An overload in a final class can silently hide base methods

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

Re: Thoughts on some code breakage with 2.074

[David Eckardt via Digitalmars-d]

On Tuesday, 9 May 2017 at 12:13:34 UTC, Adam Wilson wrote:
Can we PLEASE get more of this? I'm not saying up-end the 
language, but let's solve some problems. I doubt our corporate 
users will be very angry. I suspect that most reactions will 
fall between "minor irritation" and this one.


/me looks sideways at shared


Here is more of this. Writing industry D code I *love* breaking 
changes that reveal bugs in the code base.
A while ago I suggested changing cast(bool) semantics of 
floating-point types so that assert(x) fails if x is NaN 
(https://issues.dlang.org/show_bug.cgi?id=13489). It was rejected 
because it could break existing code and surprise C/C++ 
programmers (although the point of NaN is to surprise you IMHO).
I wonder what the ratio of valid to buggy code is that would 
break with this change. At least I enjoy it if my buggy code 
breaks.

Re: DLang quarterly EU?

[Steven Schveighoffer via Digitalmars-d]

On 5/7/17 6:01 PM, John Colvin wrote:

On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote:

I was speaking to Atila earlier about the things we like about DConf.
Sitting around talking to a bunch of computer scientists is fantastic,
and not something people generally get to do in their chosen careers
as a programmer.

EU nations are quite close together. Rather than a city meet up
monthly, what about a continental meet up quarterly?

This is quite feasible in Europe, since everything is quite close
together. I'm keen. Atila is keen. Anyone else think this is a great
idea?


Great idea. I'm in.


:( So jealous...  Two 10 hours flights for a weekend doesn't sound 
appealing enough.


Maybe I'll show up if it's held somewhere on my bucket list ;)

-Steve

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 09.05.2017 05:42, Timon Gehr wrote:

On 09.05.2017 05:06, Timon Gehr wrote:


...

Some examples:
https://github.com/tgehr/dmd/blob/71ab1280c88f9f0922fabf89ab3e7e1164b70e8b/src/test_staticforeach.d




Better link:
https://github.com/tgehr/dmd/blob/static-foreach/src/test_staticforeach.d



Moved: https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d

[Issue 3075] Implement parameter contravariance

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17349] Covariant overrides should be allowed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17349] Covariant overrides should be allowed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16600] Wrong error message for ambiguous mutable/immutable constructor

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17349

--

Re: DIP 1004 Preliminary Review Round 1

[deadalnix via Digitalmars-d]

On Monday, 8 May 2017 at 08:25:24 UTC, Andrej Mitrovic wrote:

Thoughts?


It seems like the most sensible path forward. Mike ?

[Issue 16303] covariant delegates should implicitly convert

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17349] Covariant overrides should be allowed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16303] covariant delegates should implicitly convert

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 3075] Implement parameter contravariance

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 09.05.2017 08:17, rikki cattermole wrote:

On 09/05/2017 7:10 AM, Jack Stouffer wrote:

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:

...


I'm going to save you some time and tell you that Andrei and Walter are
going to require a DIP for this.


http://forum.dlang.org/thread/oenjmm$lds$1...@digitalmars.com


Also, the DIP has existed for three years, it's just not very polished:
https://wiki.dlang.org/DIP57

Re: Scope checking on static array struct doesn't kick in

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote:
I've tagged the ref-returning functions (in this case 
`opSlice`) with `return scope` for my statically allocated 
array struct at


Here's a simpler example

https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d

Re: Thoughts on some code breakage with 2.074

[Adam Wilson via Digitalmars-d]

On 5/8/17 20:33, Brian Schott wrote:

Recently the EMSI data department upgraded the compiler we use to build
our data processing code to 2.074. This caused several of the thousands
of processes to die with signal 8 (floating point exceptions). This was
caused by the fix to issue 17243.

This is a good thing. We need more breaking changes like this.

Now that the floating point exceptions are properly enabled we were able
to track down some issues that were being silently ignored.


WUT.

All I hear on these forums is the abject terror of breaking changes 
making companies run screaming from D. You mean to say that companies 
don't actually mind breaking changes if it solves long-standing issues.


I'm shocked. SHOCKED I SAY!

;-)

Can we PLEASE get more of this? I'm not saying up-end the language, but 
let's solve some problems. I doubt our corporate users will be very 
angry. I suspect that most reactions will fall between "minor 
irritation" and this one.


/me looks sideways at shared

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 09.05.2017 09:26, Daniel N wrote:

On Tuesday, 9 May 2017 at 03:42:48 UTC, Timon Gehr wrote:

On 09.05.2017 05:06, Timon Gehr wrote:


...

Some examples:
https://github.com/tgehr/dmd/blob/71ab1280c88f9f0922fabf89ab3e7e1164b70e8b/src/test_staticforeach.d




Better link:
https://github.com/tgehr/dmd/blob/static-foreach/src/test_staticforeach.d


EPIC! Thank you so much for doing this!
...


Well, there was a hackaton, and I needed to do _something_. :)
I thought this will have the highest impact.


adds 'enum' and 'alias' on foreach loop variables to force one of the
two.
(Also works with existing foreach over AliasSeq.)


I was wondering, would it be possible to move this to a separate pull
request and get it merged before the rest? It would be useful on its own
and probably would stand a chance of getting merged much faster...
before every detail of static-foreach is agreed upon?



Yes, I'll do that.

Re: DLang quarterly EU?

[Jacob Carlborg via Digitalmars-d]

On 2017-05-07 07:41, Walter Bright wrote:

Dang, I wish I could participate in that!


I guess there could be a separate one for the United States.

--
/Jacob Carlborg

Re: DLang quarterly EU?

[Jacob Carlborg via Digitalmars-d]

On 2017-05-07 01:53, Ethan Watson wrote:

I was speaking to Atila earlier about the things we like about DConf.
Sitting around talking to a bunch of computer scientists is fantastic,
and not something people generally get to do in their chosen careers as
a programmer.

EU nations are quite close together. Rather than a city meet up monthly,
what about a continental meet up quarterly?

This is quite feasible in Europe, since everything is quite close
together. I'm keen. Atila is keen. Anyone else think this is a great idea?


+1.

--
/Jacob Carlborg

Re: Static foreach pull request

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 9 May 2017 at 09:17:06 UTC, Corey wrote:

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote:
(the implementation is the result of two days of exhausting 
trial-and-error figuring out how the DMD frontend works).


First time dealing with the frontend? Heck, two days sounds 
fast to me.


I guess having written your own D frontend from scratch must have 
helped!


https://github.com/tgehr/d-compiler

Scope checking on static array struct doesn't kick in

[Nordlöw via Digitalmars-d-learn]

I've tagged the ref-returning functions (in this case `opSlice`) 
with `return scope` for my statically allocated array struct at


https://github.com/nordlow/phobos-next/blob/master/src/arrayn.d

but for some reason the scope-checking (via -dip1000) allows both

https://github.com/nordlow/phobos-next/blob/bde41f92b5373dd1365ad19ef9d0ecee4eb2d2cd/src/arrayn.d#L350

and

https://github.com/nordlow/phobos-next/blob/bde41f92b5373dd1365ad19ef9d0ecee4eb2d2cd/src/arrayn.d#L390

to compile eventhough the life-time of the slices clearly 
outlives (is defined prior to) the lifetime of the fixed-length 
(stack-allocated) array/string struct instance.


Have I missed something or is this simply not yet supported?

Re: Fantastic exchange from DConf

[deadalnix via Digitalmars-d]

On Saturday, 6 May 2017 at 17:59:38 UTC, thedeemon wrote:

On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:

Walter: I believe memory safety will kill C.


And then null safety will kill D. ;)


I actually think this is more likely than memory safety killing 
C. Just because both are very important but D is just easier to 
kill than C for historical reasons.