Re: Boston D Meetup: Strawman Structs

[Nicholas Wilson via Digitalmars-d-announce]

On Sunday, 23 July 2017 at 02:15:18 UTC, Steven Schveighoffer 
wrote:

On 7/21/17 8:49 PM, Nicholas Wilson wrote:
On Friday, 21 July 2017 at 21:55:01 UTC, Steven Schveighoffer 
wrote:

On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered 
while writing some MySQL serialization code. Hope you can 
attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431



I've set up a live stream for this. No guarantees of the 
quality, it will be audio + slideshow.


Waiting for people to arrive, so probably won't start until 
at least 6:30.


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



Great talk!


Thanks!



Regarding the inferred attribute problem with the concepts 
like Straw-man usage, this should not be a problem with my 
attributes DIP, since all special attributes become normal 
attributes and you could just have an AliasSeq of the required 
values.


Maybe I'm misunderstanding you, but my concern is that 
something like this:


struct StrawmanRange(T)
{
  ...
  void popFront() {}
}

So popFront would be inferred to be pure, @safe, and nothrow. 
However, since really we want to only do what was specified, we 
don't want the compiler inferring this. More specifically, I 
wouldn't want the `implements` function generating requirements 
that a suitable range struct must have @safe nothrow pure 
popFront. I don't think introspection can tell whether the 
attributes were specified or inferred.


I don't see how being able to combine attributes is going to be 
able to prevent compiler inference of them. Or maybe I am 
missing something?


-Steve


Its the combining with AliasSeq in conjunction with being normal 
(albeit compiler recognised) attributes that makes it work. It 
doesn't matter what the compiler infers because the struct knows, 
with RequiredAttributes, what attributes are _actually_ required 
E.g.


struct RequiredAttributes(Values...) 
if(AllSatisfy!(isCoreAttributeValue, Values))

{
alias values = AliasSeq!(Values);
}

 struct StrawmanRange(T)
 {
@RequiredAttributes!(): // i.e. no attributes required
// or use
//@RequiredAttributes!(safe,nothrow,nogc,pure): for very 
strict functions

// can apply this on a per symbol basis too.

@property T front();
bool empty();
void popFront() {}
 }

and reflect on the RequiredAttributes.values to force the 
"correct" attributes in `implements` and `describeDifferences`.


// roughly and ignoring optional methods
bool Implements(Strawman,T)()
{
foreach(m; __traits(allMembers, Strawman)
{
static if (!hasMember!(T,m)
return false;
else static if (!isCovariantWith!(__traits(getMember, T, 
m),getUDA!(__traits(getMember, Strawman, m), RequiredAttributes). 
values)

return false;
}
return true;
}

Re: Floating point operator <> and friends

[Walter Bright via Digitalmars-d]

On 7/22/2017 6:03 PM, Ali Çehreli wrote:

Are the following floating operators gone?

   !> !< !>= !<= <> !<> <>= !<>=

They still appear at least on the following pages:

   http://dlang.org/spec/lex.html#tokens

   https://wiki.dlang.org/Operator_precedence

Thanks to Andrew Edwards's warning and unless someone objects, I'm removing them 
from the book...


Ali



Yes, they're gone. They were a failure.

Re: How can I serialize a struct into a file in the style of C?

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

On Sunday, 23 July 2017 at 02:07:45 UTC, solidstate1991 wrote:
Well, it seems the toStringz() function adds a few garbage 
characters to the end of the filename


How are you using it? The only character it should be adding is 
the zero terminator.


I suspect you might be using it on a static array without slicing 
it down to size first...

Re: How can I serialize a struct into a file in the style of C?

[solidstate1991 via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 02:22:53 UTC, Mike Parker wrote:


I should add, though, that you're better off using either 
std.stdio.File or std.file. Use the former if you need to make 
multiple reads/writes to a file, the latter if you can pull it 
in or push it out all in one go. They take arrays as arguments, 
so if you have something like Data[], you can pass it directly 
to the appropriate functions. To write a single instance, 
you'll have to take the pointer and slice it. Either way, it's 
less code, less error prone, and more idiomatic than using the 
C API.


Well, it seems the toStringz() function adds a few garbage 
characters to the end of the filename, I might look into a way to 
read the data with Phobos instead of the C API.

Re: static foreach is now in github master

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/22/17 5:26 PM, Seb wrote:

On Saturday, 22 July 2017 at 21:13:47 UTC, Steven Schveighoffer wrote:

On Thursday, 20 July 2017 at 21:02:20 UTC, Seb wrote:


Oh because I thought run.dlang.io wasn't using `rdmd`.
However, there was a minor glitch today when I added support for 
flags and stdin to the docker images [2]. The good news is that it 
has been fixed [2] & everything should behave as usual.

Sorry for the inconvenience and continued happy hacking!

[1] https://github.com/dlang-tour/core-exec/pull/2
[2] https://github.com/dlang-tour/core-exec/pull/4



Now:
Compilation or running program took longer than 25 seconds. Aborted!

Hmm, seems to be a temporary error. It works fine for me. Are you still 
experiencing this?


Just tried again, now working (and displaying only one list of numbers) 
thanks.


-Steve

Floating point operator <> and friends

[Ali Çehreli via Digitalmars-d]

Are the following floating operators gone?

  !> !< !>= !<= <> !<> <>= !<>=

They still appear at least on the following pages:

  http://dlang.org/spec/lex.html#tokens

  https://wiki.dlang.org/Operator_precedence

Thanks to Andrew Edwards's warning and unless someone objects, I'm 
removing them from the book...


Ali

Re: static foreach is now in github master

[Seb via Digitalmars-d-announce]

On Saturday, 22 July 2017 at 21:13:47 UTC, Steven Schveighoffer 
wrote:

On Thursday, 20 July 2017 at 21:02:20 UTC, Seb wrote:


Oh because I thought run.dlang.io wasn't using `rdmd`.
However, there was a minor glitch today when I added support 
for flags and stdin to the docker images [2]. The good news is 
that it has been fixed [2] & everything should behave as usual.

Sorry for the inconvenience and continued happy hacking!

[1] https://github.com/dlang-tour/core-exec/pull/2
[2] https://github.com/dlang-tour/core-exec/pull/4



Now:
Compilation or running program took longer than 25 seconds. 
Aborted!


-Steve


Hmm, seems to be a temporary error. It works fine for me. Are you 
still experiencing this?

Re: Problem with integral promotions

[Walter Bright via Digitalmars-d]

On 7/22/2017 1:07 PM, Vladimir Panteleev wrote:

Git blames you:

https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9


Ah, thanks for finding this. It was in response to:

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

i.e. it was documenting existing behavior.

[Issue 17637] Integral promotion rules not being followed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16997] Integral promotion rules not being followed for negation expressions

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 5132] ~ unary operator silently different from C

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 5132] ~ unary operator silently different from C

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9

--

Re: Release D 2.075.0

[Walter Bright via Digitalmars-d-announce]

On 7/22/2017 2:04 AM, Martin Nowak wrote:
Also translating the C++ backend to D zero benefit to D users (at worst it 
introduces codegen bugs). I'm inclined to say we should rather spent our time on 
the various more important issues.
It was a good move for the frontend as that will allow us to make use of D 
features to improve the code/architecture and to eventually turn it into a 
proper library.
Converting the stable and well tested codebase of the backend, which will hardly 
receive any feature development, is unlikely to ever pay off.


It'll be converted anyway. :-)

I'm about half way through converting the DMC++ front end. It isn't as difficult 
as I expected. The -betterC is helping a lot, as well as the fact that DMC++ is 
still pretty much C code. Some years back Daniel Murphy and I removed a lot of 
the preprocessor trickery from it, which helps, too.


Note that DMC++ is now Boost licensed as well.

Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod 
converter, optimizer, code generator) makes the whole thing much more tractable, 
and who knows what we will be able to do with it!

Re: GtkD on android?

[Seb via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 18:59:44 UTC, FoxyBrown wrote:
With LDC's new ability to do android/arm, we are missing the 
ability to do GUI's? Can any of the current D solutions work 
such as GtkD or QtD? I'm looking for something somewhat 
lightweight, easy to use(I find GtkD a bit funky but it does 
seem to work and is relatively easy once one gets through the 
basics). I think having a GUI builder is crucial though as it 
makes it so much easier in the long run. Glade is a bit funky 
but functional and works.


Ideally I'd like to be able to make portable apps that just 
work across the board(mac, linux, windows, android) without 
much hassle.


Have a look at 
http://forum.dlang.org/post/mvcojnfustdtdaver...@forum.dlang.org

Re: Release D 2.075.0

[Walter Bright via Digitalmars-d-announce]

On 7/20/2017 1:20 AM, Vladimir Panteleev wrote:
Later that day, I mentioned in passing that we might make building D part of the 
build process (of a project using D code), since building the compiler took only 
3 seconds on my machine.


To quote my colleague:

"Whaaat? How can a compiler compile in 3 seconds?!"


Back in the 80's (!) computer magazines regularly ran C compiler benchmark 
results. (At one time I counted 30 C compilers available for the PC.)


I took a class at Standford on compilers, which included a lot of info on data 
flow analysis. I decided to implement it. Data flow analysis optimizations 
basically deleted the benchmark code, because it didn't do anything (lots of 
dead assignments). This compiler was released as Datalight Optimum C.


The article writer concluded that the compiler had a giant bug in it, because it 
ran the benchmarks impossibly fast, because it deleted the dead code. Instead of 
being lauded as the only C compiler on the PC that did global data flow 
analysis, it was labeled as a buggy piece of crap.


By the time we dug ourselves out of that PR disaster, other compilers had 
implemented it, too.


Ironically, these days DMD gets repeatedly charged with not doing data flow 
analysis, and clang is assumed to have invented data flow analysis.


Just goes to show the power of marketing :-)

Best syntax for a diagonal and vertical slice

[kerdemdemir via Digitalmars-d-learn]

We have awesome way for creating slices like:

a = new int[5];
int[] b = a[0..2];

But what about if I have 2D array and I don't want to go 
vertical. Something like :


int[3][3] matrix = [
[ 1, 2, 3 ],
[ 4, 5, 6 ],
[ 7, 8, 9 ]
];

I believe I can use std.range function "RoundRobin"(or maybe it 
won't work with 2D array directly) for having a good looking 
vertical slice which will have 1,4,7 or 2,5,8 or 3,6,9 in my 
example above.


And what if I want to go diagonal like 1,5,9 or 3,5,7 in the 
example above. Is there a good solution in std without using for 
loops?


I have one more requirement for fulfilling the task that I 
working on. This slices do not have to be the same size as the 
array. For example in the example above slice size could have 2 
instead of 3. In this case I need to have slices like 
1,5;2,6;4,8;5,9 ... and so on for diagonal case.


Erdem

Ps: Converting the 2D array to 1D array is possible in my case.

[Issue 15619] [REG 2.066] Floating-point x86_64 codegen regression, when involving array ops

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

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

--

Re: Problem with integral promotions

[ketmar via Digitalmars-d]

Jerry wrote:

What code would break? Are there any examples of D code that would break 
as a result of the change?


basically, any template that has small integral type T and does unary +/-/~ 
on it. and there *is* such code in phobos, and it's not explicitly tested 
for different integral sizes. when i added a warning, i had to fix phobos 
in several places, but i'm pretty sure that there are ALOT more.

Re: Problem with integral promotions

[Jerry via Digitalmars-d]

On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote:

Walter Bright wrote:

2. Codify existing practice, since it has been that way 
forever. Not matching C has caused problems, see 16997 and 
17637. It may cause more serious silent problems for people 
converting C code to D code.


i'd say "codify, and add warning". since i patched the warning 
into the compiler, i have no more problems with the current 
rules: compiler tells me about possible incompatibilities with 
C, and i can either add `()` to silent the warning, or 
explicitly cast to the type i want.


i think most other people will prefer to get warning instead of 
code breakage too. at least i hope so. ;-)


Good luck adding a warning into DMD. After years there still 
isn't a warning for unsigned/signed comparisons.


What code would break? Are there any examples of D code that 
would break as a result of the change?

Re: Problem with integral promotions

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 22 July 2017 at 10:44:04 UTC, Walter Bright wrote:

Note that the spec says:

"Note: unlike in C and C++, the usual integral promotions are 
not performed prior to the complement operation."


  http://dlang.org/spec/expression.html#complement_expressions

Where did that come from?


Git blames you:

https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9

Re: New Garbage Collector?

[Dmitry Olshansky via Digitalmars-d]

On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new GC. 
Just wanted to know if there's any updates on that. And what 
issues is it going to fix..


Personally, I would be greatly delighted if it acknowledges the 
Stop-The-World problem[1]. Going around it is shown not to be 
impossible[2]. I do understand it's not trivial task but how is 
the community/core devs supporting this?


[1] https://dlang.org/spec/garbage.html
[2] https://hub.docker.com/r/nimlang/nim/


I'm working on new GC. First iteration aims to be faster at 
allocation and at collection without changing the fundamental 
mark-sweep strategy. Second stage is getting concurrent 
collection. It wouldn't be a real-time miracle, but a pause time 
in the range of 10-20ms is possible.

Re: Problem with integral promotions

[Guillaume Piolat via Digitalmars-d]

On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote:

Walter Bright wrote:

2. Codify existing practice, since it has been that way 
forever. Not matching C has caused problems, see 16997 and 
17637. It may cause more serious silent problems for people 
converting C code to D code.


i'd say "codify, and add warning".


I'd vote for the ketmar solution if workable.

Another argument for this is that C code that has already been 
converted to D, and is currently silently broken, would benefit 
from a new warning as a way of gathering attention. However 
matching C promotion might make this code work too but silently.

Re: Problem with integral promotions

[Walter Bright via Digitalmars-d]

This affects:

~ubyte: all values
-ubyte: all values
-byte: -128 (0x80)

~ushort: all values
-ushort: all values
-short: -32768 (0x8000)

GtkD on android?

[FoxyBrown via Digitalmars-d-learn]

With LDC's new ability to do android/arm, we are missing the 
ability to do GUI's? Can any of the current D solutions work such 
as GtkD or QtD? I'm looking for something somewhat lightweight, 
easy to use(I find GtkD a bit funky but it does seem to work and 
is relatively easy once one gets through the basics). I think 
having a GUI builder is crucial though as it makes it so much 
easier in the long run. Glade is a bit funky but functional and 
works.


Ideally I'd like to be able to make portable apps that just work 
across the board(mac, linux, windows, android) without much 
hassle.

Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

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

Am 21.07.2017 um 09:40 schrieb Andrea Fontana:

It has a lot of potential. I always hope that someone will start a 3d
Printer firmware written in D for a 32bit microcontroller.


I've actually started to implement a GCode processor in D a while ago, 
because I was unsatisfied with the open source firmwares that exist. 
It's more tailored towards CNC routers, but since those are pretty 
similar that shouldn't be a big problem. The bad news is that I don't 
have time to work on it anymore and it was still at a relatively early 
stage.

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hi Guys,

Due to improved ABI handling a subset of slices of complex 
structs work now :)


The following code will correctly compile with newCTFE.

struct NA
{
string name;
uint age;
}

NA[] make5(string name)
{
NA[] result;

foreach(i; 1 .. 6)
{
string nameN = name ~ [cast(immutable char)('0' + (i % 
10))];

result ~= [NA(nameN , i-1)];
}
return result;
}

static assert (make5("Tony") == [NA("Tony1", 0u), NA("Tony2", 
1u), NA("Tony3", 2u), NA("Tony4", 3u), NA("Tony5", 4u)]);


As soon as the foreach-loop is iterated more then 1000 times you 
will see a 7-10x speed improvement :)

Re: unresolved external symbol error (How to resolve?)

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

On Saturday, 22 July 2017 at 18:04:41 UTC, WhatMeWorry wrote:

And what do the _ModuleInfoZs mean?


You didn't compile in all your modules. Try adding each one to 
the dmd command line.

unresolved external symbol error (How to resolve?)

[WhatMeWorry via Digitalmars-d-learn]

Linking...
01_06_coord_systems.obj : error LNK2001: unresolved external 
symbol _D11common_game12__ModuleInfoZ
01_06_coord_systems.obj : error LNK2001: unresolved external 
symbol _D14post_processor12__ModuleInfoZ



I've gotten plenty of undefined external symbol errors in my time 
but how does one approach a "unresolved" error. Does this mean I 
have more than 1 occurrence of the symbol and the linker is 
confused?


And what do the _ModuleInfoZs mean?

I've got a package called common_game which has a module named 
post_processor.d


Any suggestions?  Thanks.

Re: D easily overlooked?

[aedt via Digitalmars-d]

On Saturday, 22 July 2017 at 14:20:24 UTC, Russel Winder wrote:

On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote:



[…]
D without the GC isn't at all interesting, might as well use Go 
in that case. So D only gets traction if it keeps a GC.


Go people are also trying to make their GC pretty fast afaik
https://news.ycombinator.com/item?id=12821586

Re: New Garbage Collector?

[Stefan Koch via Digitalmars-d]

On Saturday, 22 July 2017 at 16:35:03 UTC, Igor Shirkalin wrote:

On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:

On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new 
GC. Just wanted to know if there's any updates on that. And 
what issues is it going to fix..


Personally, I would be greatly delighted if it acknowledges 
the Stop-The-World problem[1]. Going around it is shown not 
to be impossible[2]. I do understand it's not trivial task 
but how is the community/core devs supporting this?


[1] https://dlang.org/spec/garbage.html
[2] https://hub.docker.com/r/nimlang/nim/


The new precise GC will be never added to druntime.
It is dead, man.


Are you real developer of new GC?


He's not he's just a naysayer :)

Re: New Garbage Collector?

[Igor Shirkalin via Digitalmars-d]

On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:

On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new 
GC. Just wanted to know if there's any updates on that. And 
what issues is it going to fix..


Personally, I would be greatly delighted if it acknowledges 
the Stop-The-World problem[1]. Going around it is shown not to 
be impossible[2]. I do understand it's not trivial task but 
how is the community/core devs supporting this?


[1] https://dlang.org/spec/garbage.html
[2] https://hub.docker.com/r/nimlang/nim/


The new precise GC will be never added to druntime.
It is dead, man.


Are you real developer of new GC?

Re: Cannot find std.datetime when linking after upgrade to 2.075.0

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 22, 2017 15:29:26 Domain via Digitalmars-d-learn wrote:
> On Friday, 21 July 2017 at 19:05:00 UTC, Jonathan M Davis wrote:
> > On Friday, July 21, 2017 15:33:45 Domain via
> >
> > Digitalmars-d-learn wrote:
> >> After upgrade dmd to latest 2.075.0, my project no longer
> >> build:
> >>
> >> zero.lib(core_cde_4a4f.obj) : error LNK2001: unresolved
> >> external symbol _D3std8d
> >> atetime9LocalTime6opCallFNaNbNeZyC3std8datetime9LocalTime
> >>
> >> and many more. All about std.datetime.
> >
> > Then it sounds like you need to make sure that you rebuild your
> > project and all of its dependencies (which you should be doing
> > with any compiler upgrade anyway, since they're not ABI
> > compatible). Your code should work just fine with std.datetime
> > and 2.075.0 without any changes, but it will need to be
> > recompiled.
> >
> > https://dlang.org/changelog/2.075.0.html#split-std-datetime
> >
> > - Jonathan M Davis
>
> Never mind. It looks like the installation files are corrupted. I
> remove the entire dmd, download and install again, everything
> work fine now.

Well, at least you finally figured it out and got it working.

- Jonathan M Davis

Re: D easily overlooked?

[Timon Gehr via Digitalmars-d]

On 22.07.2017 16:20, Russel Winder via Digitalmars-d wrote:

D without the GC isn't at all interesting, might as well use Go in that
case.


Uh, no.

Re: D easily overlooked?

[Moritz Maxeiner via Digitalmars-d]

On Saturday, 22 July 2017 at 15:13:12 UTC, Ali wrote:
On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner 
wrote:

On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by 
preventing stop-the-world


I have yet to see a (working, correct) non-STW GC that doesn't 
make other trade offs not acceptable for D (extra thread(s), 
memory barriers for all writes, etc.).
There's room for improvement of the current GC, but I 
sincerely doubt we will see one that's not STW.



or gets rid of the GC


And remove one of the primary reasons why one doesn't have to 
prototype in some script language (e.g. python)? No thanks.


Ocaml comes to mind, it is being used bu jane street for high 
frequency trading

and they dont complain

I think the key point it, is that if stw fast enough, it is 
good enough for most uses


I think a very fast GC should be next on the list for D


Ocaml's GC is stop-the-world for both its minor and major heap 
[1], so if someone wants to write another GC implementation for 
D, that's a good place to draw inspiration from, yes.


[1] 
https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html

Re: Cannot find std.datetime when linking after upgrade to 2.075.0

[Domain via Digitalmars-d-learn]

On Friday, 21 July 2017 at 19:05:00 UTC, Jonathan M Davis wrote:
On Friday, July 21, 2017 15:33:45 Domain via 
Digitalmars-d-learn wrote:
After upgrade dmd to latest 2.075.0, my project no longer 
build:


zero.lib(core_cde_4a4f.obj) : error LNK2001: unresolved 
external symbol _D3std8d 
atetime9LocalTime6opCallFNaNbNeZyC3std8datetime9LocalTime


and many more. All about std.datetime.


Then it sounds like you need to make sure that you rebuild your 
project and all of its dependencies (which you should be doing 
with any compiler upgrade anyway, since they're not ABI 
compatible). Your code should work just fine with std.datetime 
and 2.075.0 without any changes, but it will need to be 
recompiled.


https://dlang.org/changelog/2.075.0.html#split-std-datetime

- Jonathan M Davis


Never mind. It looks like the installation files are corrupted. I 
remove the entire dmd, download and install again, everything 
work fine now.

Re: D easily overlooked?

[Ali via Digitalmars-d]

On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote:

On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by 
preventing stop-the-world


I have yet to see a (working, correct) non-STW GC that doesn't 
make other trade offs not acceptable for D (extra thread(s), 
memory barriers for all writes, etc.).
There's room for improvement of the current GC, but I sincerely 
doubt we will see one that's not STW.



or gets rid of the GC


And remove one of the primary reasons why one doesn't have to 
prototype in some script language (e.g. python)? No thanks.


Ocaml comes to mind, it is being used bu jane street for high 
frequency trading

and they dont complain

I think the key point it, is that if stw fast enough, it is good 
enough for most uses


I think a very fast GC should be next on the list for D

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[MysticZach via Digitalmars-d]

On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
However, I think the presentation of the DIP needs some work. 
For example, the rationales and lines of reasoning that 
eventually led to the currently proposed syntax, both from the 
original draft of this DIP and from the ensuing discussion in 
the previous review thread, ought to be included (of course, in 
summarized form -- no need to repeat the back-and-forth of the 
original discussions, but just the eventual line of thought). 
If possible, some of the discarded alternatives could be 
mentioned along with the reasons why they were eventually 
decided against.


The first draft of the current proposal actually started with 
this approach: 
https://github.com/dlang/DIPs/commit/677c4e2bd5ff9b4bcbca35a28831560d5ce06f8c


Hopefully this will help:

https://github.com/dlang/DIPs/pull/88

Re: Cannot find std.datetime when linking after upgrade to 2.075.0

[Domain via Digitalmars-d-learn]

On Friday, 21 July 2017 at 19:05:00 UTC, Jonathan M Davis wrote:
On Friday, July 21, 2017 15:33:45 Domain via 
Digitalmars-d-learn wrote:
After upgrade dmd to latest 2.075.0, my project no longer 
build:


zero.lib(core_cde_4a4f.obj) : error LNK2001: unresolved 
external symbol _D3std8d 
atetime9LocalTime6opCallFNaNbNeZyC3std8datetime9LocalTime


and many more. All about std.datetime.


Then it sounds like you need to make sure that you rebuild your 
project and all of its dependencies (which you should be doing 
with any compiler upgrade anyway, since they're not ABI 
compatible). Your code should work just fine with std.datetime 
and 2.075.0 without any changes, but it will need to be 
recompiled.


https://dlang.org/changelog/2.075.0.html#split-std-datetime

- Jonathan M Davis


I have deleted all dependencies and rebuild everything, but still 
get those errors!


C:\Domain\d\game>dub build zero:plugin1 --arch=x86_64 --force
Building package zero:plugin1 in C:\Domain\d\game\
Fetching pegged 0.4.2 (getting selected version)...
Fetching msgpack-d 1.0.0-beta.6 (getting selected version)...
WARNING: A deprecated branch based version specification is used 
for the depende
ncy zero. Please use numbered versions instead. Also note that 
you can still use
 the dub.selections.json file to override a certain dependency to 
use a branch i

nstead.
Performing "debug" build using dmd for x86_64.
msgpack-d 1.0.0-beta.6: building configuration "library"...
pegged 0.4.2: building configuration "default"...
zero ~master: building configuration "library"...
zero:plugin1 ~master: building configuration "library"...
Linking...
src\plugins\plugin1\dll.def(4) : warning LNK4017: EXETYPE 
statement not supporte

d for the target platform; ignored
   Creating library 
.dub\build\library-debug-windows-x86_64-dmd_2075-1F996E49B53
F3A00022177DB92F8CC26\PlugIn1.lib and object 
.dub\build\library-debug-windows-x8

6_64-dmd_2075-1F996E49B53F3A00022177DB92F8CC26\PlugIn1.exp
PlugIn1.obj : error LNK2001: unresolved external symbol 
_D3std8datetime7SysTime8

toStringMxFNbNfZAya
PlugIn1.obj : error LNK2001: unresolved external symbol 
_D3std8datetime7SysTime8

__xopCmpFKxS3std8datetime7SysTimeKxS3std8datetime7SysTimeZi
PlugIn1.obj : error LNK2001: unresolved external symbol 
_D3std8datetime7SysTime8

opEqualsMxFNaNbNfKxS3std8datetime7SysTimeZb
zero.lib(formattedLogger_aa3_d61.obj) : error LNK2001: unresolved 
external symbo
l 
_D3std8datetime7SysTime8opEqualsMxFNaNbNfKxS3std8datetime7SysTimeZb
PlugIn1.obj : error LNK2001: unresolved external symbol 
_D3std8datetime7SysTime6

toHashMxFNaNbNiNfZm
zero.lib(formattedFileLogger_aa2_786.obj) : error LNK2001: 
unresolved external s
ymbol 
_D3std12experimental6logger4core6Logger11beginLogMsgMFNfAyaiAyaAyaAyaE3std

12experimental6logger4core8LogLevelS3std11concurrency3TidS3std8datetime7SysTimeC
3std12experimental6logger4core6LoggerZv
zero.lib(formattedLogger_aa3_d61.obj) : error LNK2001: unresolved 
external symbo
l 
_D3std12experimental6logger4core6Logger11beginLogMsgMFNfAyaiAyaAyaAyaE3std12ex

perimental6logger4core8LogLevelS3std11concurrency3TidS3std8datetime7SysTimeC3std
12experimental6logger4core6LoggerZv
zero.lib(formattedLogger_aa3_d61.obj) : error LNK2019: unresolved 
external symbo
l _D3std8datetime7SysTime8fracSecsMxFNbNdNfZS4core4time8Duration 
referenced in f
unction 
_D4zero6logger15formattedLogger57__T15FormattedLoggerTS3std5stdio4File17

LockingTextWriterZ15FormattedLogger12LogFormatter8toStringMFMDFAxaZvS3std6format
18__T10FormatSpecTaZ10FormatSpecZv
zero.lib(formattedLogger_aa3_d61.obj) : error LNK2019: unresolved 
external symbo
l _D3std8datetime7SysTime14toISOExtStringMxFNbNfZAya referenced 
in function _D4z

ero6logger15formattedLogger57__T15FormattedLoggerTS3std5stdio4File17LockingTextW
riterZ15FormattedLogger12LogFormatter8toStringMFMDFAxaZvS3std6format18__T10Forma
tSpecTaZ10FormatSpecZv
.dub\build\library-debug-windows-x86_64-dmd_2075-1F996E49B53F3A00022177DB92F8CC2
6\PlugIn1.dll : fatal error LNK1120: 7 unresolved externals
Error: linker exited with status 1120
dmd failed with exit code 1120.

Re: D easily overlooked?

[Moritz Maxeiner via Digitalmars-d]

On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by 
preventing stop-the-world


I have yet to see a (working, correct) non-STW GC that doesn't 
make other trade offs not acceptable for D (extra thread(s), 
memory barriers for all writes, etc.).
There's room for improvement of the current GC, but I sincerely 
doubt we will see one that's not STW.



or gets rid of the GC


And remove one of the primary reasons why one doesn't have to 
prototype in some script language (e.g. python)? No thanks.

Re: The X Macro using D

[Martin Nowak via Digitalmars-d]

On Saturday, 22 July 2017 at 11:50:40 UTC, Stefan Koch wrote:

tuple map and array are all pretty expensive.

please profile.


Well a bit more compile time isn't the end of the world, and by 
far not the only metric (e.g. readability and maintainability 
also rank high). You're slightly obsessed with the template 
compile-time topic ;).


BTW, the term expensive is fairly subjective easily 
misunderstood. Sth. more specific would reduce the chance for 
confusion, e.g. "tuple map and array require longer to compile"

Re: D easily overlooked?

[Russel Winder via Digitalmars-d]

On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote:
> 
[…]
> Unless some miracle happens and makes the GC better by preventing 
> stop-the-world, or gets rid of the GC, D will not get any more 
> attention.

D without the GC isn't at all interesting, might as well use Go in that
case. So D only gets traction if it keeps a GC.

Except for the "actually on the metal" people who can prove they cannot
survive if there is a GC, and D does that already – but without the standard
library.

-- 
Russel.
=
Dr Russel Winder t:+44 20 7585 2200   voip:sip:
russel.win...@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:rus...@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

signature.asc
Description: This is a digitally signed message part

Re: D easily overlooked?

[aedt via Digitalmars-d]

On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote:

https://blog.sourced.tech/post/language_migrations/

A recent article where github programming languages popularity 
and migration got analysed was very interesting but it showed 
one noticeable thing:


[...]


Unless some miracle happens and makes the GC better by preventing 
stop-the-world, or gets rid of the GC, D will not get any more 
attention.

Re: Visual D no bp's on x64

[Rainer Schuetze via Digitalmars-d-debugger]

On 18.06.2017 20:25, Mike B Johnson wrote:
I could produce an issue when starting the mago debugger for the first 
time after firing up VS2015: it showed an error, though, instead of 
not doing anything at all. Maybe it's a different effect of the same 
problem. I have added a work around that fixes it for me: 
https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts 



BTW: the output window should show whether symbols for your 
application have been loaded. If not, you get the behavior that you 
reported.


Didn't work ;/

All I get on the output wndow is

"
C:\Windows\System32\dbghelp.dll unloaded.
The thread 0x1ea4 has exited with code -1 (0x).
The thread 0x1390 has exited with code -1 (0x).
The thread 0x1ac has exited with code -1 (0x).
The program '[492] Async.exe' has exited with code -1 (0x).
"


After installing VS2017 on a fresh Win10 install I could reproduce this 
issue: the mago debug engine failed to load the symbols when only VS2017 
is installed, because the COM-CLSID to load msdia140.dll changed. 
Switching to the VS debug engine worked, though.


Should be fixed in the next release.

[Issue 14875] A template instance with deprecated symbol/type needlessly repeats "Deprecation:" messages

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/f07f0909f8e5ed90381e149bb71e13aa2f560279
fix Issue 14875 - A template instance with deprecated symbol/type needlessly
repeats "Deprecation:" messages

https://github.com/dlang/dmd/commit/9c8a2604da7c643bdb95c4ca7566694d7e8de370
Merge pull request #4865 from 9rnsr/fix_deprecation

--

[Issue 13738] RTInfo generation on deprecated struct causes deprecation message

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to dmd-cxx at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/84c3642d4890cb9c30174b982712b6a8885d9f5a
Remove the RTInfo specific code for issue 13738

--

[Issue 14753] pragma(inline) hides the alias "string"

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/0b98ae3a89000291819613958e07ccc38da1abc0
fix Issue 14753 - pragma(inline) hides the alias "string"

https://github.com/dlang/dmd/commit/692c7a5a4e54d686aa4536ee9325e161bffbeec6
Merge pull request #4793 from 9rnsr/fix14753

--

[Issue 13720] [REG2.067] Adding trivial destructor to std.datetime causes Internal error: ..\ztc\cgelem.c 2418

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/5a67cc2c12b351a4649de5caeb5e6b30e109d611
fix Issue 13720 - Adding trivial destructor to std.datetime causes Internal
error: ..\ztc\cgelem.c 2418

https://github.com/dlang/dmd/commit/d66bf4d32448e9768abd22d56dcc54548dd3da3e
Merge pull request #4759 from 9rnsr/fix13720

--

[Issue 14459] String literal merge bug causes incorrect runtime program behavior

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/3252ddcf36f53928d04b62a601c0b7bb9d911cba
fix Issue 14459 - String literal merge bug causes incorrect runtime program
behavior

https://github.com/dlang/dmd/commit/fd8e527b2a950eaa437426e8201572e0da51000f
Merge pull request #4866 from 9rnsr/fix14459

--

[Issue 14874] __traits(getFunctionAttributes) does not support the new `return` attribute

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to dmd-cxx at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/0c1fd7108015d06e120178b7d8de6cd7caad6283
Merge pull request #4868 from MetaLang/master

--

[Issue 14663] shared library test - link_linkdep - segfaults on FreeBSD 10

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/c011a559128e0c069140df4f7b3afd670403b081
fix Issue 14663  - shared library test - link_linkdep - segfaults on FreeBSD 10

https://github.com/dlang/dmd/commit/8dad102881c0183256b9440d348a71b387c4b378
Merge pull request #4838 from MartinNowak/fix14776

--

[Issue 14906] dmd dumps core at incorrect enum declaration

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/1a5b4098e7a7f0bbdfd3c8035a93d1e71471afc1
fix Issue 14906 - dmd dumps core at incorrect enum declaration

https://github.com/dlang/dmd/commit/d4b1b3a2b19fd0e32162876d6c182c79b63a93e7
Merge pull request #4881 from 9rnsr/fix14906

--

[Issue 14779] incorrect addressing of arguments in require/in-contract

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/9e6bc30b0997867d21b794b933cbf822e7d8cfa6
fix Issue 14779 - incorrect addressing of arguments in require/in-contract

https://github.com/dlang/dmd/commit/971b319e45c4e81825265fdb04363806a76bd4a0
Merge pull request #4803 from 9rnsr/fix14779

--

[Issue 14815] Destructor is not called for static array assignment

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/2d1ae10a72484a86365737987d7efb7389a456c0
fix Issue 14815 - Destructor is not called for static array assignment

https://github.com/dlang/dmd/commit/ddc90f382cac62116a4610c10bb39b21a20c30a3
Merge pull request #4824 from 9rnsr/fix14815

--

[Issue 2013] interface to interface dynamic cast is incorrect in some cases

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/2c28cecaf5a19b60a4e06865b5dbc558043be089
fix Issue 2013 - interface to interface dynamic cast is incorrect in some cases

https://github.com/dlang/dmd/commit/f78b25c9fb00bf024cd1d6e394f696bba4f2187b
Merge pull request #4819 from 9rnsr/fix1747_2013

--

[Issue 14876] Deprecation message is sometimes duplicated

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/d83017aac59bbe7aec516beaa447c994b86e5784
fix Issue 14876 - Deprecation message is sometimes duplicated

https://github.com/dlang/dmd/commit/9c8a2604da7c643bdb95c4ca7566694d7e8de370
Merge pull request #4865 from 9rnsr/fix_deprecation

--

[Issue 14829] [REG2.066.0] wrong code with -O -inline

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/bc2ae82f62fa1df91040c874542e8e6b9746178b
fix

https://github.com/dlang/dmd/commit/88bb355e8245c8fa6c1017a116cc8ea36c601a41
Merge pull request #4841 from WalterBright/fix14829

--

[Issue 14735] [REG2.068-b1] std.string.indexOf cannot deduce function for char argument

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/13a16e8e0344e90c3a03b87167d9a82b3cb7e24c
fix Issue 14735 - std.string.indexOf cannot deduce function for char argument

https://github.com/dlang/dmd/commit/fdfb5882ef701ebfda49a3cc3392b5fe4e0e95b8
Merge pull request #4779 from 9rnsr/fix14735

--

[Issue 14846] Insufficient context deduction with implicit nested lambda

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/35f348635b50842e9620c52db071f4d11af25199
fix Issue 14846 - Insufficient context deduction with implicit nested lambda

https://github.com/dlang/dmd/commit/9538fe5ea2a7e1d85e0b1a111790be31a52ebefe
Merge pull request #4848 from 9rnsr/fix14846

--

[Issue 14430] [REG2.060] Null parameter is detected as non-null.

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/b53c44ed001b113c2f44cf7590ef28630398a5df
fix Issue 14430 - [REG2.060] Null parameter is detected as non-null

https://github.com/dlang/dmd/commit/1ea328e298a9f6ee887917b62b34d32d8e109a0c
Merge pull request #4775 from WalterBright/fix14430

--

[Issue 14768] Error: index 174762 overflow for static array

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/b91401db907f113e5acbf9be4be69b97b286c198
fix Issue 14768 - Error: index 174762 overflow for static array

https://github.com/dlang/dmd/commit/64c473c62aa07030f4daf1b76fe04b445f0ebf1f
Merge pull request #4798 from 9rnsr/fix14768

--

[Issue 14653] scoped!range in foreach crashes

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/0fea84354ed1f4339a2910897bf9f1cab87b3384
fix Issue 14653 - scoped!range in foreach crashes

https://github.com/dlang/dmd/commit/e03bfc283f1f2d96bf159c2cba177235a8545d2f
Merge pull request #4797 from 9rnsr/fix14653

--

[Issue 14860] Destructor is not called for block assignment

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/fd8af3a98e1deb370aecf940c939f8a7794a850e
fix Issue 14860 - Destructor is not called for block assignment

https://github.com/dlang/dmd/commit/286906ba8ffe9e75905998fd99a6349b7a0f6b4e
Merge pull request #4856 from 9rnsr/fix14860

--

[Issue 6417] Wrong context for nested functions in virtual class member function contracts

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/b2f1367b3791a87f440d8531d228071a32ef7f2a
fix Issue 6417 - Wrong context for nested functions in virtual class member
function contracts

https://github.com/dlang/dmd/commit/82f91e2db26a0cf9cb09b4d802b7b72d6138673d
Merge pull request #4789 from 9rnsr/fix6417

--

[Issue 14710] VC-built DMD crashes on templated variadic function IFTI

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/7bf83a6ce5d1a83f52ce40b174c8ccfdcd6948a8
fix Issue 14710 - VC-built DMD crashes on templated variadic function IFTI

https://github.com/dlang/dmd/commit/260495940349194b072c5786759ce07c1ee3972c
Merge pull request #4751 from CyberShadow/pull-20150618-124347

--

[Issue 14588] [REG2.067] undefined reference error while linking with -debug option to a static library.

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/fcb7915ec75752a04892246be18632b077f7e2b7
fix Issue 14588 - undefined reference error while linking with -debug option to
a static library

https://github.com/dlang/dmd/commit/0e0519692b8913487d12050f7ea0ef5702d2d64e
Merge pull request #4787 from 9rnsr/fix14588

--

[Issue 14717] Ddoc macro recursion limit too low

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/3f444afaeffd70ca3eddf19512c4c51947de80e6
fix issue 14717 - Ddoc macro recursion limit too low

https://github.com/dlang/dmd/commit/ef5153823b8df089ad3a342106d5010f6d8f6304
Merge pull request #4799 from aG0aep6G/14717

--

[Issue 1747] class to base interface static cast is incorrect in some cases

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/5cefffdfd8dca40403674e9c12b990a17e40aaa9
fix Issue 1747 - class to base interface static cast is incorrect in some cases

https://github.com/dlang/dmd/commit/f78b25c9fb00bf024cd1d6e394f696bba4f2187b
Merge pull request #4819 from 9rnsr/fix1747_2013

--

[Issue 14541] "duplicate COMDAT" linker error with the template forward reference in Tuple.opAssign

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/1112eec29eef531663de289f17800ad4a10fee50
fix Issue 14541 - "duplicate COMDAT" linker error with the template forward
reference in Tuple.opAssign

https://github.com/dlang/dmd/commit/0b0d37363727385299c76a52c8ddb5c9db47afd8
Merge pull request #4814 from 9rnsr/fix14541

Issue 14541 - "duplicate COMDAT" linker error with the template forward
reference in Tuple.opAssign

--

[Issue 14682] [REG2.037] Incorrect interpretation of ~ []

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/4d5c653d83984e85ba3976702c4f59a95b8d087a
fix Issue 14682 - Incorrect interpretation of ~ []

https://github.com/dlang/dmd/commit/67b82717d2e189974a1662ded8a8229791977eb9
Merge pull request #4742 from 9rnsr/fix14682

--

[Issue 14731] [REG2.068a] Error location insufficient when CTFE

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/99b8bcacca542cfc3ab4dff3b8dc9c0fd9348e72
fix Issue 14731 - Error location insufficient when CTFE

https://github.com/dlang/dmd/commit/d284ad7b6b155e04db4f9582216f70b8e0a4b991
Merge pull request #4771 from 9rnsr/fix14731

--

[Issue 14747] compiler insists on unnecessary return statement

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/615110a78f1bad4b46df58fc743302dac1708f18
fix Issue 14747 - compiler insists on unnecessary return statement

https://github.com/dlang/dmd/commit/442cb436f6ebf4a8ce7367e742ae2d3c180ba953
Merge pull request #4790 from 9rnsr/fix14747

--

[Issue 14754] [REG2.068b1] 64bit wrong code with -inline

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/46acdb60537358bd742543d55e97e22eeacc33a5
fix Issue 14754 - 64bit wrong code with -inline

https://github.com/dlang/dmd/commit/92c37006e20eb900febff03fb287a58648c5b36c
Merge pull request #4795 from 9rnsr/fix14754

--

[Issue 9383] Wrong context for contracts if closure [dis]appears in override function

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/47d9320e73b7fc6e95ef6bb9d9b571ab8a4548d8
fix Issue 9383 - Wrong context for contracts if closure [dis]appears in
override function

https://github.com/dlang/dmd/commit/8e8781489d7fdcfe486020644ed31b2f8d774d8e
Merge pull request #4788 from 9rnsr/fix9383

--

[Issue 14699] [REG2.062] ICE: segfaults on array with zero size

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/5d70b1a0d07cc16ef579360fc697116f5ef630d0
fix Issue 14699 - ICE: segfaults on array with zero size

https://github.com/dlang/dmd/commit/94a6afd4f7c0ad60a6eab608ee28b15bd4e264d8
Merge pull request #4744 from 9rnsr/fix14699

--

[Issue 2091] D2 final cannot be applied to variable

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/397752ba67e2db4868865b57ddfcd6f76724f386
fix Issue 2091 - D2 final cannot be applied to variable

https://github.com/dlang/dmd/commit/b9864b41576e3d20df0969e2731c19f663b55a31
Merge pull request #4714 from 9rnsr/fix2091

--

[Issue 14510] Bad tail call optimization with static arrays

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/af82ac6208a576ddae3bfab6b3ec2e4c211015a3
fix Issue 14510 - Bad tail call optimization with static arrays

https://github.com/dlang/dmd/commit/6071f1dbd7c5d70d9b0c4781e8d5efad0f6d95c6
Merge pull request #4778 from WalterBright/fix14510

--

[Issue 14572] cannot build dmd from source anymore: 'g++ -m64: No such file or directory'

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/1cfeb7f601e4befcba00354142a2cb556cf7b1d7
fix Issue 14572 (Take 2) - Cannot build from source: 'g++ -m64: No such file or
directory'

https://github.com/dlang/dmd/commit/963f4c09243395d760a63d2f8001b8de53a132b7
Merge pull request #4772 from JinShil/fix14572

--

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hi Guys,

Another work-filled two day went by.
And here is the fruit of the labor:

int[2][3] split(int[6] a)
{
  int[2][3] result;
  foreach (i; 0 .. typeof(result[0]).length)
  {
foreach (j; 0 .. result.length)
{
  auto idx = i*result.length + j;

  result[j][i] = a[idx];
}
  }
  return result;
}

static assert(split([1,2,3,4,5,6]) == [[1, 4], [2, 5], [3, 6]]);

The above code does now work at ctfe.

Meaning we are well on our way of supporting multidimensional 
arrays.

Multidimensional Slices however are a little tricker.

Re: The X Macro using D

[Stefan Koch via Digitalmars-d]

On Friday, 21 July 2017 at 20:44:13 UTC, Enamex wrote:

On Thursday, 20 July 2017 at 22:02:32 UTC, Walter Bright wrote:

[...]


How about this (if I'm not mistaken, this's only one template 
instantiation per tuple-type):


[...]


tuple map and array are all pretty expensive.

please profile.

Re: Problem with integral promotions

[ketmar via Digitalmars-d]

Walter Bright wrote:

2. Codify existing practice, since it has been that way forever. Not 
matching C has caused problems, see 16997 and 17637. It may cause more 
serious silent problems for people converting C code to D code.


i'd say "codify, and add warning". since i patched the warning into the 
compiler, i have no more problems with the current rules: compiler tells me 
about possible incompatibilities with C, and i can either add `()` to 
silent the warning, or explicitly cast to the type i want.


i think most other people will prefer to get warning instead of code 
breakage too. at least i hope so. ;-)

Problem with integral promotions

[Walter Bright via Digitalmars-d]

They are supposed to match C. But they don't for unary operators + - ~, and as 
far as I can tell never did.


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

Note that the spec says:

"Note: unlike in C and C++, the usual integral promotions are not performed 
prior to the complement operation."


  http://dlang.org/spec/expression.html#complement_expressions

Where did that come from?

And the spec says nothing about unary - or unary +.

  http://dlang.org/spec/expression.html#unary-expression

It's been like this at least since D1, both the code and the Spec.

So, we have a choice:

1. Fix it so it matches C, as has been generally promised. Fixing it will break 
existing code such as:


  https://github.com/dlang/phobos/pull/5646

but worse, it may silently break code. I don't know of a reasonable way to 
detect this.


2. Codify existing practice, since it has been that way forever. Not matching C 
has caused problems, see 16997 and 17637. It may cause more serious silent 
problems for people converting C code to D code.

[Issue 16997] Integral promotion rules not being followed for negation expressions

[via Digitalmars-d-bugs]

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

--- Comment #8 from Walter Bright  ---
Note that the spec says:

"Note: unlike in C and C++, the usual integral promotions are not performed
prior to the complement operation."

  http://dlang.org/spec/expression.html#complement_expressions

And the spec says nothing about unary - or unary +.

  http://dlang.org/spec/expression.html#unary-expression

--

[Issue 16997] Integral promotion rules not being followed for negation expressions

[via Digitalmars-d-bugs]

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

--- Comment #7 from Walter Bright  ---
Unary + and unary ~ are also broken in the same way.

--

Re: New Garbage Collector?

[tetyys via Digitalmars-d]

On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:

The new precise GC will be never added to druntime.
It is dead, man.


Why?

Re: New Garbage Collector?

[Temtaime via Digitalmars-d]

On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new GC. 
Just wanted to know if there's any updates on that. And what 
issues is it going to fix..


Personally, I would be greatly delighted if it acknowledges the 
Stop-The-World problem[1]. Going around it is shown not to be 
impossible[2]. I do understand it's not trivial task but how is 
the community/core devs supporting this?


[1] https://dlang.org/spec/garbage.html
[2] https://hub.docker.com/r/nimlang/nim/


The new precise GC will be never added to druntime.
It is dead, man.

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[via Digitalmars-d-bugs]

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

--- Comment #3 from Rainer Schuetze  ---
I recently analyzed this a bit: dmd now attaches both lines 3 and 6 to the
DWARF info for the loop increment, and gdb selects 6 now.

dmd also elides some unconditional jumps, even in debug builds. I suspect
avoiding this can help.

>> When breaking inside test2, the call stack will look like it is being
>> called by test1();
> I don't observe such behaviour with an older dmd.

gdb seems to be a bit better in this regard than the VS debugger: even if the
return address after the call instruction is annotated with a different line,
it still displays the line of the call itself. VS shows the line after the call
(if there are no call cleanup instructions).

--

[Issue 16997] Integral promotion rules not being followed for negation expressions

[via Digitalmars-d-bugs]

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

--- Comment #6 from Walter Bright  ---
*** Issue 17637 has been marked as a duplicate of this issue. ***

--

[Issue 17637] Integral promotion rules not being followed

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #1 from Walter Bright  ---
16997 has a more succint test case.

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

--

[Issue 17320] Visual Studio 2017 is not detected

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Nowak  ---
https://github.com/dlang/installer/pull/227

--

Re: Release D 2.075.0

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 20 July 2017 at 18:22:36 UTC, Patrick Schluter wrote:

1 cpu on 2.4 GHz Westmere, gcc 6.2 version 2.067


They don't sell single-core CPUs any longer ;). What matters is 
the time you have to wait.

Re: Creating a new type, to get strong-ish type checking and restrict usage to certain operations, using struct perhaps

[Moritz Maxeiner via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 06:08:59 UTC, Cecil Ward wrote:

On Saturday, 22 July 2017 at 03:18:29 UTC, Cecil Ward wrote:

[...]


I saw David Nadlinger's units package. I'd like to know how the 
strong typing works.


By wrapping in structs and overloading operators [1][2][3][4].

[1] 
https://github.com/klickverbot/phobos/blob/units/std/units.d#L727
[2] 
https://github.com/klickverbot/phobos/blob/units/std/units.d#L736
[3] 
https://github.com/klickverbot/phobos/blob/units/std/units.d#L756
[4] 
https://github.com/klickverbot/phobos/blob/units/std/units.d#L765

Re: Creating a new type, to get strong-ish type checking and restrict usage to certain operations, using struct perhaps

[Moritz Maxeiner via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 03:18:29 UTC, Cecil Ward wrote:
I guess part of my question, which I didn't really highlight 
well enough, is the issue of strong typing. [...]


Going back to the original example of packed bcd stored in a 
uint64_t say, first thing is that I want to ban illegal mixing 
of arbitrary binary values in ordinary uint64_tmtypes with 
decimal types, again no assignment, addition, comoarisons etc 
across types at all allowed. And no friendly automagically 
conversions [...]


All of this should be covered by wrapping in structs and 
overloading the appropriate operators for the types in question 
[1][2][3], which is why the BCDInteger struct shell I wrote has 
the "Overload operators" comment.


[1] https://dlang.org/spec/operatoroverloading.html#binary
[2] https://dlang.org/spec/operatoroverloading.html#assignment
[3] https://dlang.org/spec/operatoroverloading.html#op-assign

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[Moritz Maxeiner via Digitalmars-d]

On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:


How about this in current syntax? (that's what I do)

int func(int a)
in
{
assert(a >= 0);
}
out(result)
{
assert(result >= 2);
}
body
{
return 2 * a;
}


I can only restate my opinion against the above as "too verbose" 
for the common use case of simple conditions such as null 
pointer, range empty, etc. Until in contracts are injected at the 
call site, the above is essentially equivalent to this less 
verbose version:

---
int func(int a)
{
assert (a >= 0); // > should be used here, though

int result;
scope (success) assert (result >= 2);

return result = 2*a;
}
---


an improvement could be:

int func(int a)
in assert(a >= 0);
out(result) assert(result >= 2);
body
{
return 2 * a;
}

just like an in-line if-else statement


Summary of issues with that (that you can also find in the Round 
1 discussion):
- Free semicolons within the function signature are inconsistent 
with the rest of D
- The `body` keyword is redundant here; imho it should also have 
been removed (deprecation first) from the current contract syntax 
instead of being replaced by `do`, because it's inconsistent with 
the rest of D to require a keyword to delimit the *end* of an 
optional element, but since those (shell) contracts are extremely 
verbose, anyway, it doesn't matter much
- There already is the verbose syntax to specify contracts as 
"shells" that are to be explicitly filled with whatever checks 
one needs (assert, enforce, etc.), i.e. requiring the user to 
couple a contract with its implementation; the new syntax allows 
the user to specify contracts as what they originally are (in the 
DbC context): abstract promises between caller and callee with 
the user not needing to worry about the implementation.
- Imho the reason why current contract syntax is used only by few 
people is its verbosity; the more succinct the new syntax, the 
higher chance I think it has of yielding more widespread use

[Issue 982] Codeview: symbols of enum type are declared integer

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de
   Hardware|x86 |All
Version|D1 (retired)|D2

--- Comment #1 from Rainer Schuetze  ---
still in git master

--

Re: Creating a new type, to get strong-ish type checking and restrict usage to certain operations, using struct perhaps

[Cecil Ward via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 03:18:29 UTC, Cecil Ward wrote:

[...]


I saw David Nadlinger's units package. I'd like to know how the 
strong typing works.