[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #5 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #3)
> bool fun(const int a) { return true; }
> bool gun(const int[3] a) { return true; }
> 
> void main()
> {
> static const int x1 = 1;
> static assert(fun(x1));
> static const int[3] x;
> static assert(gun(x));
> }
> 
> The int goes through, the int[3] does not although the pass by value
> protocol is the same for both.

You have to initialize the int[3], as you did with the int. I suppose the
compiler assumes that you're going to do run-time initialization via `static
this` when you're not initializing in the declaration. In that case, the value
can't be used at compile time, obviously.

[...]
> bool fun(const int a) { return true; }
> bool fun(ref const int a) { return true; }
> 
> void main()
> {
> static const int x1 = 1;
> static assert(fun(x1));
> }
> 
> Here, the code attempts to avoid the problem by overloading on ref. However,
> the call is resolved to the ref version even though it does not go through.
> This should definitely be fixed, otherwise we're in the position of making a
> workaround impossible.

You can work around by using an enum instead of a static const. That makes x1
an rvalue, and the ref overload isn't involved anymore.

It might be worthwhile to require enums for compile-time constants; i.e., ban
non-enum consts/immutables. The const/immutable qualifiers simply don't imply
compile-time constancy. enum does.

That would be a breaking change, of course. And it would break benign code such
as `static const a = 1; static const b = a + 1;`. But a clean cut may be better
than confusing special cases.

--

[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument

[via Digitalmars-d-bugs]

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

--- Comment #4 from uplink.co...@googlemail.com ---
As far as I can see there is no special treatment.

CTFE does only work on literals results of ctfe evaluations are always
literals.

--

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote:


That's the thing about C++: The right way is the obscure way, and the
straightforward way is the wrong way. And yesterday's right way is
today's wrong way. And apparently (it would seem), the only way NOT to
completely fuck *everything* up is to become an expert on every corner
of the language, and STAY an expert on all the latest changes. In the
immortal words (and voice) of Duke Nukem: "What a mess!"


Yep, this always reminds me of:

https://bartoszmilewski.com/2013/09/19/edward-chands/



That is *awesome*!

Although, I always saw Eddie Scissors as more of a retelling of 
Frankenstein.




D is not without its own flaws and WAT-worthy dark corners, mind you,
but in spite it its warts, I still prefer D any day over the masochistic
labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way
-- until next year) that is C++.



Yea, I really think it's more important than many of us realize to heed 
Herb Sutter's warning and not allow too much worrying about backwards 
compatibility thus leading D down the same path. When I see people here 
fret over "Yea, but it may cause breakage", on one hand I understand 
that can be the responsible stance, but OTOH it also makes me cringe 
because it's one more "cat" nibbling us to death - I don't want to see 
it follow in C++'s footsteps and allow these unfixed mistakes build up 
and damage what made D great in the first place. Especially since "small 
things that add up to more than the sum of their parts" is a big part of 
what makes D good in the first place.




The latest WAT I found in D is this one, see if you can figure it out:
How an alternation between two character types ends up being int is
beyond me, but even more inscrutible is why ch : wch produces int but
wch : dch produces uint.


Ouch. Although yea, guess that's another good reason to just decide 
Unicode == UTF-8 and be done with it ;) (I don't even care about UTF-8's 
supposed bloat in eastern alphabets - it's freaking *text* either way. 
Tale of Genji would be what, some tens of MB in UTF-8? Bah, trim down a 
few images and overengineered file formats and multimedia clutter if you 
need a shave a few measly MB so badly. If UTF-32'd won out, the complete 
works of Shakespeare would in the same boat, some tens of MB in the 
"wrong" format and we *still* wouldn't have the ASCII-simplicity of code 
points being equal to graphemes anyway. It's *text*. If your software's 
footprint or bandwidth is dominated by the size of a bloated text 
format, then *congratulations*, you officially have one of the smallest, 
most succinct software footprints in the world, so smile and be happy!)

Re: C++ Interfacing:'static' array function parameter contradiction

[Atila Neves via Digitalmars-d-learn]

On Friday, 28 April 2017 at 18:41:22 UTC, kinke wrote:

On Friday, 28 April 2017 at 18:07:49 UTC, ParticlePeter wrote:
Interesting, your example corresponds to my third case, the 
linker error. I am on Window, building an x64 App, afaik in 
that case the MS Visual Studio linker is used instead of 
optilink. Will add your findings to the bug report.


Apparently Microsoft's C++ compiler doesn't mangle `float 
arg[3]` parameters identically to `float* arg`:


void cppSArray(float color[3]) => ?cppSArray@@YAXQEAM@Z
void cppPtr(float* color) => ?cppPtr@@YAXPEAM@Z


The worst part about that is mangling aside, the two declarations 
are identical to the compiler.


Atila

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Ola Fosheim Grostad via Digitalmars-d-announce]

On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote:
On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky 
(Abscissa) via Digitalmars-d-announce wrote:

On 04/28/2017 04:26 PM, Atila Neves wrote:
> The other day I was reminded that in C++ land one has to 
> manually write `operator<<` to print things out and 
> `operator==` to compare things.


Not to mention you have to overload operator<, operator!=, 
operator==, operator>, operator<=, *and* operator>= in order to 
get the right results in all cases.


In D, you have to overload opEquals and opCmp.  Hmm, I wonder 
why I enjoy programming in D more than C++...


Comparison is better in C++. This is a weak spot in D. You could 
do the same in C++ as D if you wanted to. You can detect the 
presence of operator< in overload templates, but being explicit 
is not much work and more flexible. Just cut'n'paste the set you 
want...

Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:
This year, DConf has an extra day tacked on for problem solving 
in the form of a hackathon. The intent is to work on issues 
people find frustrating in the D ecosystem. While there will be 
time given at the event for proposals, and those involving 
third-party projects are welcome, it will help speed things 
along for the organizers to come in with a list of big issues 
to get the ball rolling.


To help in compiling the list, what are some major issues from 
the ecosystem that you'd like to see fixed?


Not so much major issue but I would like to:
* figure out a solution for 
https://github.com/ldc-developers/ldc/issues/2011
* consider the merits of standardising allocSize 
(https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L16) or equivalent among dmd/ldc/gdc
* get half precision floating point into the language /or/ 
ability to create __vector's of user types (need for intrinsics 
for GPU et al targets of dcompute).


I would also like to hold a mini hackathon/gauge interest in 
dcompute as we could benefit significantly from the ML craze.

Re: OT: Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov 
[ZombineDev] wrote:

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V,


I got you covered ;)
(LDC not CTFE though. It would be fiendishly complicated to do at 
CTFE as a fair amount of compiler magic is necessary.)

Re: C++ Interfacing:'static' array function parameter contradiction

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 28 April 2017 at 19:08:18 UTC, ParticlePeter wrote:

On Friday, 28 April 2017 at 17:57:34 UTC, Ali Çehreli wrote:

On 04/28/2017 08:56 AM, ParticlePeter wrote:
> C++ Function:
> bool cppFunc( float[3] color );
>
> D binding:
> extern(C++) bool cppFunc( float[3] color );
>
> Using with:
> float[3] my_color;
> cppFunc( my_color );
>
> -> Error: Internal Compiler Error: unable to pass static
array to

That part is a bug at least in the compiler message. Is it 
really an internal ctompiler error? Doesn't look like it: the 
compiler is talking to us happily. :)


My simple test works for me:

// deneme.cpp
float cppFunc(float color[3]) {
return color[0] + color[1] + color[2];
}

$ g++ -c deneme.cpp -o deneme_cpp.o

// deneme.d
extern(C++) float cppFunc(float * color);

void main() {
float[3] my_color = [ 1.5, 2.5, 3.5 ] ;
assert(cppFunc(my_color.ptr) == 7.5);
}

$ dmd deneme_cpp.o deneme.d -of=deneme

Builds and runs fine... on Linux... I don't know whether 
that's significant.


Ali


Btw, according to [1] your example should not work either, I 
doubt that there is a difference between C and C++ interfacing, 
it should be:


extern(C++) float cppFunc( ref float[3] color );

In my case its a linker error as well.

[1] http://dlang.org/spec/interfaceToC.html#passing_d_array


If you are having problems with the linker with Ali's you can do
```
extern(C++) bool cppFunc( float[3] color ); // correct signature, 
but causes compiler error


pragma(mangle, cppFunc.mangleof)
float cppFunc(float * color); // compatible signature but wrong 
mangling overridden with pragma(mangle,...)

llvm-d 2.1 - Support for LLVM 4.0.0

[Moritz Maxeiner via Digitalmars-d-announce]

Thanks to foerdi as of the new release 2.1.0, llvm-d supports 
LLVM 4.0.0.

[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--- Comment #3 from Andrei Alexandrescu  ---
Please let's keep this opened until we get to a resolution, thanks.

There are several issues here. First, consider this variation:

bool fun(const int a) { return true; }
bool gun(const int[3] a) { return true; }

void main()
{
static const int x1 = 1;
static assert(fun(x1));
static const int[3] x;
static assert(gun(x));
}

The int goes through, the int[3] does not although the pass by value protocol
is the same for both. Apparently float is also handled the same as int. At a
minimum we should include in the specification what types enjoy such special
treatment.

The second experiment:

bool fun(const int a) { return true; }
bool fun(ref const int a) { return true; }

void main()
{
static const int x1 = 1;
static assert(fun(x1));
}

Here, the code attempts to avoid the problem by overloading on ref. However,
the call is resolved to the ref version even though it does not go through.
This should definitely be fixed, otherwise we're in the position of making a
workaround impossible.

The third experiment:

bool fun(T)(auto ref const T a) { return true; }

void main()
{
static const int x1 = 1;
static assert(fun(x1));
}

Here, the code gives complete leeway to the compiler as to what version should
be called. Again, the compiler chooses the ref version to then refuse to let it
go through.

--

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Ali Çehreli via Digitalmars-d-announce]

On 04/28/2017 02:11 PM, Nick Sabalausky (Abscissa) wrote:

> D takes all the current (and former!) application domains
> of C/C++, and brings to it basic programmer sanity.

When I had asked Luís Marques what the title of the talk should be, he 
had said


  import sanity;

:)

Ali

Re: COM Expertise needed: COM Callbacks

[Nierjerson via Digitalmars-d-learn]

On Friday, 28 April 2017 at 09:25:31 UTC, John Chapman wrote:

On Thursday, 27 April 2017 at 20:20:23 UTC, Nierjerson wrote:




QueryInterface is COM's version of opCast. It asks if you 
support the interface represented by an IID (riid). If you 
don't, then you return E_NOINTERFACE. If you do, then you point 
the result (pvObject) to yourself and return S_OK. Here's a 
basic implementation:


extern(Windows)
HRESULT QueryInterface(IID* riid, void** pvObject) {
  if (pvObject is null) return E_POINTER;
  *pvObject = null;

  if (*riid == IID_IUnknown) *pvObject = 
cast(void*)cast(IUnknown)this;
  else if (*riid == IID_IDispatch) *pvObject = 
cast(void*)cast(IDispatch)this;

  // and so on for all interfaces we support

  if (*pvObject is null) return E_NOINTERFACE;
  (cast(IUnknown)this).AddRef();
  return S_OK;
}



Your code works. I  had something similar but I think I was 
returning a null pointer on IID_Unknown or something similar. I 
now get a different error but it is a COM error rather than 
access violation. (error 80020009)

Re: Garbage Collector?

[Ola Fosheim Grostad via Digitalmars-d]

On Friday, 28 April 2017 at 21:21:13 UTC, jmh530 wrote:
To be fair, C++ effectively has multiple pointer types too with 
raw pointers, unique_ptr, shared_ptr, and weak_ptr. However, 
each of the extra ones has a unique purpose and are opt-in. As 
a result, people happily use them when it makes their lives 
easier.


Yes, they are not language types though, so no special effect on 
the compiler or runtime. The language types are pointers, 
 and &


By contrast, C++/CLI (I'm more familiar with that than managed 
C++) has pointer to managed heap and pointer to unmanaged heap. 
The concepts overlap more.


Yes, and I assume those are language types so that the compiler 
and runtime can take advantage of it?

Re: Blog post on automem

[Atila Neves via Digitalmars-d-announce]

On Friday, 28 April 2017 at 22:06:57 UTC, Nordlöw wrote:

On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:

Blog:
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/


Nice.

One thing, Atila; what about replacing

typeof(u1) u2;
move(u1, u2);

with

typeof(u1) u2 = move(u1);

or, alternatively,

typeof(u1) u2 = u1.move;

?


I only learned about the single argument move when Manu did the 
other day in his thread! I just changed the code and the 
README.md to read like your last example.


Atila

Re: COM Expertise needed: COM Callbacks

[Nierjerson via Digitalmars-d-learn]

On Friday, 28 April 2017 at 09:25:31 UTC, John Chapman wrote:

On Thursday, 27 April 2017 at 20:20:23 UTC, Nierjerson wrote:


I think the main issue though, is that I really don't know 
what is going on when I invoke the PS function. It seems to 
call the server method that takes the interface and then the 
server does it's "magic"(which is calling my QueryInterface) 
but how the implemented QueryInterface is suppose to respond 
is beyond me... I've tried some based stuff but nothing seem 
to work. The good news is that it is doing something(calling 
QueryInterface) which means that the server is at work.


Any more ideas?  I think the issue currently is is the 
QueryInterface(it is simply not doing what it is suppose to). 
I'll probably have to look at some other implementations to 
see what is going on.


QueryInterface is COM's version of opCast. It asks if you 
support the interface represented by an IID (riid). If you 
don't, then you return E_NOINTERFACE. If you do, then you point 
the result (pvObject) to yourself and return S_OK. Here's a 
basic implementation:


extern(Windows)
HRESULT QueryInterface(IID* riid, void** pvObject) {
  if (pvObject is null) return E_POINTER;
  *pvObject = null;

  if (*riid == IID_IUnknown) *pvObject = 
cast(void*)cast(IUnknown)this;
  else if (*riid == IID_IDispatch) *pvObject = 
cast(void*)cast(IDispatch)this;

  // and so on for all interfaces we support

  if (*pvObject is null) return E_NOINTERFACE;
  (cast(IUnknown)this).AddRef();
  return S_OK;
}



Ok, I tried this and returned this but it didn't work. I didn't 
clal AddRef though, but maybe I was in the right direction but 
had some other issue.


AddRef/Release perform the COM object's reference counting, so 
you should implement them too.


However, I don't understand why your icRBCColor class both 
implements and encapsulates IDispatch - the generated version 
cRGBColor from Gen.d just encapsulates it. Why do you need to 
instantiate an instance of icRGBColor? Can't you just use the 
rgb1 object you got from the dd.RGB() getter, assign the colour 
values to its Red, Blue, Green properties as needed, then call 
the dd.RGB(rgb1) setter? Does that not work?



cRGBColor and any class in Gen.d are not COM interfaces and can't 
be used. All they do is wrap the dynamic method invocation work 
that is required to interact with PS.


It may work that I could use them to set the values and then 
reset the instance but I feel that seems to be a waste. There is 
no need to really set the object if one is using the property 
setters. Although my method of creating a "direct" COM interface 
wrapper(one that inherits from IDispatch and simply delegates the 
work to the original com) seems to do basically the same, I plan 
on converting those COM Properties in to D properties and 
maintain state on both ends that are always in sync(possibly a 
bit slow, but should be easy to implement and allow one to work 
with COM in a more D like fashion.


I could, for example, just have those "c" classes inherit from 
IDispatch directly and then pass on the IDispatch COM calls to 
the underlying COM interface(which is stored in the c class). 
That would be a sort of combination of the two methods above and 
might be better as it avoids actually having to get any of the 
callback COM stuff working(the stuff I'm having a problem with 
now). I just wasn't sure if this method would work and didn't 
want to mess with the gen code too much before I had a better 
understanding of what is going on.


Regardless, getting the above code to work is still important as 
it will explain to me how it should work so that I understand for 
future purposes if this method does not go that route.


Thanks, I'll try to get it to work a again and report back.

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

   Severity|major   |critical

--- Comment #7 from Jack Stouffer  ---
Raising this to critical because this is actually a bug in DMD's type inference
and not a Phobos bug.

--

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Atila Neves via Digitalmars-d]

On Friday, 28 April 2017 at 18:04:06 UTC, jmh530 wrote:

On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila


I remember you had posted about this last year. It looks like 
you've added some stuff on ranges to it recently...interesting.


You might want to include an example in the Readme.md of using 
the concept as a template constraint for a function. Maybe like


void callfoo(T)(T x)
if (isFoo!T)
{
x.foo();
}

Foo foo;
callfoo(foo);


Done. I also added to the README that it has its own versions of 
the range constraints from Phobos that can be used with `@models`.


Atila

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

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

On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky (Abscissa) via 
Digitalmars-d-announce wrote:
> On 04/28/2017 04:26 PM, Atila Neves wrote:
> > The other day I was reminded that in C++ land one has to manually
> > write `operator<<` to print things out and `operator==` to compare
> > things.

Not to mention you have to overload operator<, operator!=, operator==,
operator>, operator<=, *and* operator>= in order to get the right
results in all cases.

In D, you have to overload opEquals and opCmp.  Hmm, I wonder why I
enjoy programming in D more than C++...


> What, seriously?!?
> 
> That's the thing about C++: The right way is the obscure way, and the
> straightforward way is the wrong way. And yesterday's right way is
> today's wrong way. And apparently (it would seem), the only way NOT to
> completely fuck *everything* up is to become an expert on every corner
> of the language, and STAY an expert on all the latest changes. In the
> immortal words (and voice) of Duke Nukem: "What a mess!"

Yep, this always reminds me of:

https://bartoszmilewski.com/2013/09/19/edward-chands/


> Seriously, I don't care about the political incorrectness of bashing
> or comparing to other languages, this right here is and always was D's
> killer feature, the whole reason I got into it in the first place and
> have stayed: D takes all the current (and former!) application domains
> of C/C++, and brings to it basic programmer sanity. 'Nuff said.

D is not without its own flaws and WAT-worthy dark corners, mind you,
but in spite it its warts, I still prefer D any day over the masochistic
labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way
-- until next year) that is C++.

The latest WAT I found in D is this one, see if you can figure it out:

char ch;
wchar wch;
dchar dch;

pragma(msg, typeof(true ? ch : ch));// char - OK
pragma(msg, typeof(true ? ch : wch));   // int - WAT?
pragma(msg, typeof(true ? wch : wch));  // wchar - OK
pragma(msg, typeof(true ? wch : dch));  // uint - WAT?
pragma(msg, typeof(true ? dch : dch));  // dchar - OK

How an alternation between two character types ends up being int is
beyond me, but even more inscrutible is why ch : wch produces int but
wch : dch produces uint.

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

Unfortunately, my dmd-fu isn't up to snuff so my hamfisted PR to fix
this problem didn't get very far: it broke a ton of stuff, which is a
big no-no, oh noes, we cannot afford to break code, even though
basically every dmd release breaks code! Oh well.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at 
it. -- Pete Bleackley

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

[Atila Neves via Digitalmars-d-announce]

On Sunday, 9 April 2017 at 15:52:50 UTC, Basile B. wrote:

On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote:
Using std.experimental.allocator? Tired of writing 
`scope(exit) allocator.dispose(foo);` in a language with RAII? 
Me too:




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



I think that the Array misses
- a reservation strategy, something like reserve() and 
allocBy().


reserve is done. What would allocBy be?


- dup / idup that return new distinct and deep copies.


dup is done. I'm trying to figure out how one would use .idup.


- maybe .ptr at least for reading with pointer arithmetic.


Done.


- opBinary for "~" . Also you have bugs with operators:


Done.


```d
import std.experimental.allocator.mallocator;
UniqueArray!(int, Mallocator) a;
a ~= [0,1];
```

crashes directly.


Fixed.

Atila

Re: Blog post on automem

[Nordlöw via Digitalmars-d-announce]

On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:

Blog:
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/


Nice.

One thing, Atila; what about replacing

typeof(u1) u2;
move(u1, u2);

with

typeof(u1) u2 = move(u1);

or, alternatively,

typeof(u1) u2 = u1.move;

?

Re: Garbage Collector?

[H. S. Teoh via Digitalmars-d]

On Fri, Apr 28, 2017 at 09:50:49PM +, Atila Neves via Digitalmars-d wrote:
> On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad wrote:
> > On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad wrote:
> > «Back in the old DOS days, there were multiple pointer types (near
> > and far). Programmers put up with that because it was the only way,
> > but they HATED HATED HATED it.»
> 
> It's true, we did. It was awful.
[...]

I remember working with that.  It was a royal PITA.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at 
it. -- Pete Bleackley

Re: Garbage Collector?

[Atila Neves via Digitalmars-d]

On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
wrote:
On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
wrote:
«Back in the old DOS days, there were multiple pointer types 
(near and far). Programmers put up with that because it was the 
only way, but they HATED HATED HATED it.»


It's true, we did. It was awful.

Atila

[bug] error compiling dserver.d from sample

[Yohan SEROT via Digitalmars-d-debugger]

hello, i try to compile dserver.d but i got this error :

C:\D\dmd2\samples\d>dmd dserver.d
dserver.d(244): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szID'
dserver.d(245): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szCLSID'
dserver.d(246): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[512] szModule'
dserver.d(287): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szID'
dserver.d(288): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szCLSID'
dserver.d(289): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[256] szTemp'
dserver.d(348): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[256] szKey'

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dserver.obj(dserver)
 Error 42: Symbol Undefined _D6chello6CHello7__ClassZ
dserver.obj(dserver)
 Error 42: Symbol Undefined 
__D6chello6CHello6__ctorMWC4core3sys7windows6unknwn8IUnknownPFZvZC6chello6CHello@8

Error: linker exited with status 141717192

C:\D\dmd2\samples\d>dmd dserver.d -D
dserver.d(244): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szID'
dserver.d(245): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szCLSID'
dserver.d(246): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[512] szModule'
dserver.d(287): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szID'
dserver.d(288): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[128] szCLSID'
dserver.d(289): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[256] szTemp'
dserver.d(348): Deprecation: instead of C-style syntax, use 
D-style syntax 'char[256] szKey'

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dserver.obj(dserver)
 Error 42: Symbol Undefined _D6chello6CHello7__ClassZ
dserver.obj(dserver)
 Error 42: Symbol Undefined 
__D6chello6CHello6__ctorMWC4core3sys7windows6unknwn8IUnknownPFZvZC6chello6CHello@8

Error: linker exited with status 150912056

From a french noob

Re: Garbage Collector?

[jmh530 via Digitalmars-d]

On Friday, 28 April 2017 at 20:21:34 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
Both of these, however, show only that he doesn't seem to 
personally like multiple pointer types (and consequently 
doesn't seem to have any interest in working on them himself); 
that's not the same as him claiming that it "is a disaster" 
(in general, which is what you were implying).


There are other threads. This is a recurring topic...



To be fair, C++ effectively has multiple pointer types too with 
raw pointers, unique_ptr, shared_ptr, and weak_ptr. However, each 
of the extra ones has a unique purpose and are opt-in. As a 
result, people happily use them when it makes their lives easier.


By contrast, C++/CLI (I'm more familiar with that than managed 
C++) has pointer to managed heap and pointer to unmanaged heap. 
The concepts overlap more.

[Issue 17355] Path to lib64 and $(DMDInstallDir) not correct

[via Digitalmars-d-bugs]

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

--- Comment #3 from Thomas  ---
After a lot of uninstalling/installing DMD/VisualD, my previous global settings
for library path etc was still not "refreshed". I suspected some remains from
older installations so resided to removing all of Visual D remains in the
registry / VisualStudio settings manually. Quite a lot.

When I finally got a hopefully fresh set of global "Visual D Settings" it was
back to the same problem as before, $(DMDInstallDir) = .\


Though it seems to have found the path since in the registry it's correct.
Found two keys named "DMDInstallDir" = "C:\D\dmd2". Under:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD
and
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\ToolsOptionsPages\Projects\Visual
D Settings

Setting the "DMD install path" manually in the global settings will do as a
work-around but it does not seem to fill it in automatically.

Also, is there a need for an option to force clean/default settings during
installation maybe?

--

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 04/28/2017 04:26 PM, Atila Neves wrote:

The other day I was reminded that in
C++ land one has to manually write `operator<<` to print things out and
`operator==` to compare things.


What, seriously?!?

That's the thing about C++: The right way is the obscure way, and the 
straightforward way is the wrong way. And yesterday's right way is 
today's wrong way. And apparently (it would seem), the only way NOT to 
completely fuck *everything* up is to become an expert on every corner 
of the language, and STAY an expert on all the latest changes. In the 
immortal words (and voice) of Duke Nukem: "What a mess!"


Seriously, I don't care about the political incorrectness of bashing or 
comparing to other languages, this right here is and always was D's 
killer feature, the whole reason I got into it in the first place and 
have stayed: D takes all the current (and former!) application domains 
of C/C++, and brings to it basic programmer sanity. 'Nuff said.

Re: Garbage Collector?

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 20:21:34 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
Both of these, however, show only that he doesn't seem to 
personally like multiple pointer types (and consequently 
doesn't seem to have any interest in working on them himself); 
that's not the same as him claiming that it "is a disaster" 
(in general, which is what you were implying).


There are other threads. This is a recurring topic...


I am aware...



What you consider not pointless is your business, again, but 
if you don't try to get it in the core language, you have no 
foundation to complain that's it's not in there.


There are no example I know of where something has gone into 
the D language that is going against the aesthetics Walter 
value... Which isn't surprising.


There are also few examples of new features going in at the 
language level based on external DIPs. Do you have any good 
examples? (Not standard lib, but language features).


I myself know of no examples where people have actually done the 
work up to and including the point where there were no technical 
issues left and were then rejected.

get parameters of a function

[Alex via Digitalmars-d-learn]

Hi all,
I have a question about the Parameters trait from
https://dlang.org/phobos/std_traits.html#Parameters

The following code does not compile. Why?

import std.traits : Parameters;

void main()
{
static assert(is(Parameters!S1 == Parameters!S2));
}

struct S1
{
auto opCall() {}
auto opCall(int i){}
}

struct S2
{
auto opCall(int i){}
auto opCall() {}
}

So, of course, if I change the both opCall methods, e. g. in S1 
it will. But I'm wondering, how to use the trait in this case?


Is it mainly assumed to use it with functions without overloads?

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Atila Neves via Digitalmars-d-announce]

On Tuesday, 25 April 2017 at 13:57:53 UTC, XavierAP wrote:

On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:


I have to say it took me a very long time to come up with the 
title and the abstract. How could I sell D to C++ experts? 
Luckily, I asked Manu and among a long list of ideas he said 
"it's about saving time" and "time is money". How can you 
argue with that? ;)


I do agree, but C++ people may be less open to buy the whole 
package at once... The other speakers (Rust, Haskell) will talk 
about specific things that they regard as nicer in their 
languages compared to C++ (safe memory access,


@safe


concurrency in Rust;


std.concurrency

Funny story: the first ever (and really, only) program I wrote in 
Rust had a deadlock in it. I never did figure out why, I just 
stopped using threads to get rid of the problem. I know it's only 
anecdata, but "fearless concurrency" does not gel with my 
experience.


I don't even remember the last time I wrote a deadlock in C++, if 
ever. Not once in D, that's for sure. It's hard to deadlock when 
you hardly ever lock. :)


I have fearless concurrency now, in D. Message passing FTW.


side effect safety in Haskell).


pure

C++ users can more easily  agree to these individual points and 
later become interested in the other languages.


Well, let's show them the same points then ;)



It's true that D's paradigm is less different from C++ and it's 
more about being better designed and safer as a whole. It's 
like, sure you can write 80% of D programs in C++ with only 
twice the typing at most,


In my experience, _at least_ twice the typing, and 3 times as 
many bugs. And I'm talking about C++14 here. The other day I was 
reminded that in C++ land one has to manually write `operator<<` 
to print things out and `operator==` to compare things.


Atila

Re: Garbage Collector?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
Both of these, however, show only that he doesn't seem to 
personally like multiple pointer types (and consequently 
doesn't seem to have any interest in working on them himself); 
that's not the same as him claiming that it "is a disaster" (in 
general, which is what you were implying).


There are other threads. This is a recurring topic...

What you consider not pointless is your business, again, but if 
you don't try to get it in the core language, you have no 
foundation to complain that's it's not in there.


There are no example I know of where something has gone into the 
D language that is going against the aesthetics Walter value... 
Which isn't surprising.


There are also few examples of new features going in at the 
language level based on external DIPs. Do you have any good 
examples? (Not standard lib, but language features).

Re: Garbage Collector?

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
wrote:
Walter's position has always been that having more than a 
single pointer type is a disaster.


None of the threads I've read in the last couple of years 
regarding that support that claim.


He has restated this position many many times... Random 
snippets:


«Microsoft's Managed C++ had two pointer types, and it went 
over like a lead zeppelin.

»

http://forum.dlang.org/post/mclqt1$1e5n$1...@digitalmars.com


«Back in the old DOS days, there were multiple pointer types 
(near and far). Programmers put up with that because it was the 
only way, but they HATED HATED HATED it.»


http://forum.dlang.org/post/mcnv9u$e8p$1...@digitalmars.com



I had not read these, thank you :)
Both of these, however, show only that he doesn't seem to 
personally like multiple pointer types (and consequently doesn't 
seem to have any interest in working on them himself); that's not 
the same as him claiming that it "is a disaster" (in general, 
which is what you were implying).




You can easily find more... No point in trying to get that into 
the core language (but it is necessary to get proper 
destruction of GC managed objects in a reasonable way).


What you consider not pointless is your business, again, but if 
you don't try to get it in the core language, you have no 
foundation to complain that's it's not in there.

Re: Garbage Collector?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 17:48:47 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
I'm hoping to put all information in one place. Then when 
someone on Reddit or HN or here starts making claims about the 
GC, I can give them one link that shows all of their options.


That's nice. Just get your hopes up for it having an effect.


Typo, I meant "don't"... Sloppy of me. Documentation is nice, but:

1. People will complain that it isn't possible.

2. When possible people will complain that it isn't in the 
standard library.


3. When in "std" people will complain that not enough libraries 
use it.


4. When libraries use it people will complain that it doesn't 
work with older libs.


5. When older libs have been rewritten to support it they will 
complain that it is better in Rust and C++ and not compatible 
with Rust and C++.


Anyway, my main point is that programmers coming from such 
languages will most certainly complain if it isn't in the 
standard library because of interoperability between libraries, 
but that is basically just the bottom of the hill that you have 
to climb to get to a level where people stop complaining.

[Issue 5659] Conditional operator, array literal, and std.traits.CommonType return a wrong common type

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17141

--

Re: Garbage Collector?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
wrote:
Walter's position has always been that having more than a 
single pointer type is a disaster.


None of the threads I've read in the last couple of years 
regarding that support that claim.


He has restated this position many many times... Random snippets:

«Microsoft's Managed C++ had two pointer types, and it went over 
like a lead zeppelin.

»

http://forum.dlang.org/post/mclqt1$1e5n$1...@digitalmars.com


«Back in the old DOS days, there were multiple pointer types 
(near and far). Programmers put up with that because it was the 
only way, but they HATED HATED HATED it.»


http://forum.dlang.org/post/mcnv9u$e8p$1...@digitalmars.com


You can easily find more... No point in trying to get that into 
the core language (but it is necessary to get proper destruction 
of GC managed objects in a reasonable way).

[Issue 17359] New: C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

[via Digitalmars-d-bugs]

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

  Issue ID: 17359
   Summary: C++ Interfacing: function with 'static' array
parameter cannot be linked (x64)
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: particlepe...@gmx.de

C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

C++ prototype:
bool cppFunc( float[3] color );

D binding (as described here [1])
extern(C++) bool cppFunc( ref float color );

Using with:
float[3] my_color;
cppFunc( my_color );

Building with dmd 2.0.73.1:
-> error LNK2001: unresolved external symbol "bool __cdecl cppFunc(float
(&)[3])" Binding.exe : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
dmd failed with exit code 1120.

Same problem but slightly different error messages with LDC. 

The issue is discussed here in additional detail [2].

Summary:
Ali mentions that following variant works for him on linux:
"
// deneme.cpp
float cppFunc(float color[3]) {
return color[0] + color[1] + color[2];
}

$ g++ -c deneme.cpp -o deneme_cpp.o

// deneme.d
extern(C++) float cppFunc(float * color);

void main() {
float[3] my_color = [ 1.5, 2.5, 3.5 ] ;
assert(cppFunc(my_color.ptr) == 7.5);
}

$ dmd deneme_cpp.o deneme.d -of=deneme
"
Comment:
This varinat leads to the same compiler error (with "bool __cdecl
cppFunc(float*)" message) on windows compiled for x64.


kinke points out:
" 
Microsoft's C++ compiler doesn't mangle `float arg[3]` parameters identically
to `float* arg`:

void cppSArray(float color[3]) => ?cppSArray@@YAXQEAM@Z
void cppPtr(float* color) => ?cppPtr@@YAXPEAM@Z
"

This contradicts Alis variant but not the 'ref' variant. But I belief that the
'ref' variant is also a mangling problem.


[1] http://dlang.org/spec/interfaceToC.html#passing_d_array
[2] https://forum.dlang.org/post/qcmrdrebuuhjfendy...@forum.dlang.org

--

[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||uplink.co...@googlemail.com
 Resolution|--- |INVALID

--- Comment #2 from uplink.co...@googlemail.com ---
This code demands an Lvalue to be used at ctfe.
remove the ref from fun and it will work.

We cannot allow the ref-fun to compile.

--

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

--- Comment #5 from hst...@quickfur.ath.cx ---
Hmph.  Looks like the problem is that the very first thing typeMerge() does is
to do integer promotion on the incoming types. Thus, right from the start,
we've already lost the original character types. The only reason this hasn't
shown up earlier is because when the two types are equal, typeMerge() is not
called. So we're essentially only saved "by accident".

Oddly enough, there is an `if (op != TOKquestion || ...)`, which *seems* to
suggest that the intent of the code is *not* to do integer promotions if ?: is
involved. However, the second clause of the if condition, `t1b.ty != t2b.ty`,
appears to be always true, so the check for ?: would appear to be always
irrelevant.  It would seem that && was intended here rather than ||, but I've
to look more carefully to make sure this isn't going to cause massive code
breakage...

--

Re: C++ Interfacing:'static' array function parameter contradiction

[ParticlePeter via Digitalmars-d-learn]

On Friday, 28 April 2017 at 17:57:34 UTC, Ali Çehreli wrote:

On 04/28/2017 08:56 AM, ParticlePeter wrote:
> C++ Function:
> bool cppFunc( float[3] color );
>
> D binding:
> extern(C++) bool cppFunc( float[3] color );
>
> Using with:
> float[3] my_color;
> cppFunc( my_color );
>
> -> Error: Internal Compiler Error: unable to pass static
array to

That part is a bug at least in the compiler message. Is it 
really an internal ctompiler error? Doesn't look like it: the 
compiler is talking to us happily. :)


My simple test works for me:

// deneme.cpp
float cppFunc(float color[3]) {
return color[0] + color[1] + color[2];
}

$ g++ -c deneme.cpp -o deneme_cpp.o

// deneme.d
extern(C++) float cppFunc(float * color);

void main() {
float[3] my_color = [ 1.5, 2.5, 3.5 ] ;
assert(cppFunc(my_color.ptr) == 7.5);
}

$ dmd deneme_cpp.o deneme.d -of=deneme

Builds and runs fine... on Linux... I don't know whether that's 
significant.


Ali


Btw, according to [1] your example should not work either, I 
doubt that there is a difference between C and C++ interfacing, 
it should be:


extern(C++) float cppFunc( ref float[3] color );

In my case its a linker error as well.

[1] http://dlang.org/spec/interfaceToC.html#passing_d_array

nogc v0.0.1: @nogc variants of `std.exception.enforce`, `std.conv.text` - Basically `@nogc` exceptions. Sorta.

[Atila Neves via Digitalmars-d-announce]

Writing `@nogc` code? Want to throw exceptions? Yeah, I know, 
painful. We can do this already:


void foo() @nogc {
static const exception = new Exception("message can't 
change");
if() throw exception; // no information about 
 is possible

}

But, we get limited information and no information at all that's 
available at runtime. We also have to have one of those 
exceptions for each error condition in the function. All in all, 
not ideal. So:



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


And this compiles:

// text is @system because it returns a slice to a static array
// if you need to store the string you'll need to make a copy
// since consecutive calls will return the same slice and it will
// be mutated
@nogc @system unittest { // look ma, @nogc!
import nogc.conv: text;
// works with basic types and user defined structs/classes
assert(text(1, " ", "foo", " ", 2.0) == "1 foo 2.00");
}


// enforce is @safe, since it internally makes a call to `text` 
but
// immediately throws an exception, and casting it to `string` 
makes

// it immutable. Ugly but it works.
@nogc @safe unittest { // still @nogc!
import nogc.exception: enforce;
import nogc.conv: text;
const expected = 1;
const actual = 1;
enforce(actual == expected, "Expected: ", expected, " but 
got: ", actual);

}


Notice that you don't call `text` after the condition in 
`enforce`. In practical use, I nearly always called 
`std.exception.enforce` with a second argument of 
`std.conv.text(...)`, so might as well make it easier here. 
Obviously `enforce(, "...")` still works since it's a 
special case of passing in variadic arguments anyway.


Atila

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Looks like this is implemented in the hairball function typeMerge() in
src/ddmd/dcast.d.  I'll try to trace through and see if I can find an obvious
problem, but I'm not sure if I'll be able to.

--

Re: C++ Interfacing:'static' array function parameter contradiction

[kinke via Digitalmars-d-learn]

On Friday, 28 April 2017 at 18:07:49 UTC, ParticlePeter wrote:
Interesting, your example corresponds to my third case, the 
linker error. I am on Window, building an x64 App, afaik in 
that case the MS Visual Studio linker is used instead of 
optilink. Will add your findings to the bug report.


Apparently Microsoft's C++ compiler doesn't mangle `float arg[3]` 
parameters identically to `float* arg`:


void cppSArray(float color[3]) => ?cppSArray@@YAXQEAM@Z
void cppPtr(float* color) => ?cppPtr@@YAXPEAM@Z

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

  Component|phobos  |dmd

--

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

--- Comment #3 from hst...@quickfur.ath.cx ---
Unfortunately, it looks like CommonType is implemented using the ?: ternary
operator, meaning that it's the *compiler* that's producing these crazy
results.

--

[Issue 17141] CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #2 from hst...@quickfur.ath.cx ---
It's not just CommonType!(dchar, char); it's a whole slew of cases that are
incorrectly handled:


void main() {
import std.range;

struct CharRange(C) {
C ch = 'a';
@property C front() { return ch; }
@property bool empty() { return ch == C.init; }
void popFront() { ch = C.init; }
}

CharRange!char charRange;
CharRange!wchar wcharRange;
CharRange!dchar dcharRange;

pragma(msg, "char + char: ", ElementType!(typeof(chain(charRange,
charRange;
pragma(msg, "char + wchar: ", ElementType!(typeof(chain(charRange,
wcharRange;
pragma(msg, "wchar + char: ", ElementType!(typeof(chain(wcharRange,
charRange;
pragma(msg, "char + dchar: ", ElementType!(typeof(chain(charRange,
dcharRange;
pragma(msg, "dchar + char: ", ElementType!(typeof(chain(dcharRange,
charRange;
pragma(msg, "wchar + wchar: ", ElementType!(typeof(chain(wcharRange,
wcharRange;
pragma(msg, "wchar + dchar: ", ElementType!(typeof(chain(wcharRange,
dcharRange;
pragma(msg, "dchar + wchar: ", ElementType!(typeof(chain(dcharRange,
wcharRange;
pragma(msg, "dchar + dchar: ", ElementType!(typeof(chain(dcharRange,
dcharRange;
}


Output:

char + char: char
char + wchar: int
wchar + char: int
char + dchar: uint
dchar + char: uint
wchar + wchar: wchar
wchar + dchar: uint
dchar + wchar: uint
dchar + dchar: dchar


Seems like the only time the correct common type is deduced, as far as
character types are concerned, is when both are types are the same. All the
other cases are worthy of a WAT?.

--

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:

[ ... ]


Hi Guys, I just implemented sliceAssigment.

meaning the following code will now compile:

uint[] assignSlice(uint from, uint to, uint[] stuff)
{
uint[] slice;
slice.length = to + 4;
foreach (uint i; 0 .. to + 4)
{
slice[i] = i + 1;
}

slice[from .. to] = stuff;
return slice;
}

static assert(assignSlice(1, 4, [9, 8, 7]) == [1, 9, 8, 7, 5, 
6, 7, 8]);


as always ... I spoke too soon :(
while running test I forgot to specify -bc-ctfe ...

Although I use the same code for slicing ... it seems it 
misbehaves in the usecase.

Kafka site needs to be updated with D modules

[Ali Çehreli via Digitalmars-d]

There are three D modules that I could identify that provide Kafka 
bindings[1] by searching for "kafka" on the code registry:


  http://code.dlang.org/

Could people in the know please update the Kafka site with necessary 
information like what version of Kafka they support, etc.


Thank you,
Ali

[1] https://cwiki.apache.org/confluence/display/KAFKA/Clients

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jack Stouffer  ---
(In reply to hsteoh from comment #2)
> `ElementType!(typeof(chain(s, "\n")))` returns `uint`. That's the problem.
> Now, why ElementType should return `uint` is a different story... gonna
> investigate now.

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

--

Re: Blog post on automem

[Ali Çehreli via Digitalmars-d-announce]

On 04/28/2017 11:26 AM, qznc wrote:


There is a RefCounted in std.typecons as well. The article does not
explain the differences though.


The article gives a difference:


D’s standard library has Unique and RefCounted in std.typecons but they 
predate std.experimental.allocator and so “bake in” the allocation strategy.



Ali

Re: Blog post on automem

[qznc via Digitalmars-d-announce]

On Friday, 28 April 2017 at 15:39:07 UTC, Swoorup Joshi wrote:

On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
Atila was kind enough to do a write up on his automem library 
for the D Blog, talking about why he did it and showing some 
of the implementation details. This is officially part of the 
GC series. The next post in the series will be my @nogc post 
(I've pushed it back to after DConf).


[...]


Automem is something, that should just be there in the standard 
library.


There is a RefCounted in std.typecons as well. The article does 
not explain the differences though.

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #2 from hst...@quickfur.ath.cx ---
`ElementType!(typeof(chain(s, "\n")))` returns `uint`. That's the problem. Now,
why ElementType should return `uint` is a different story... gonna investigate
now.

--

Re: Move construction from !is(T == typeof(this))

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 18:05:41 UTC, Steven Schveighoffer 
wrote:

On 4/28/17 12:56 PM, Ola Fosheim Grøstad wrote:
Isn't that an odd stance given that "struct" is supposed to be 
a value

type?



Not really, but thanks for asking.


Well, it counters the very definition of a value... I guess what 
you are saying is that the conventions are changing for struct 
over time, but that puts .init in a very odd position.

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

--- Comment #1 from Jack Stouffer  ---
possibly introduced in https://github.com/dlang/phobos/pull/5229

--

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

   Severity|enhancement |regression

--

[Issue 17358] New: [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

  Issue ID: 17358
   Summary: [REG 2.074.0] std.stdio.File.lockingTextWriter.put no
longer accepts chains of characters
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

This compiled in 2.073.2 and doesn't anymore

void main()
{
import std.stdio;
import std.range;
import std.conv;

auto f = File("test", "w");
auto s = 42.toChars;
f.lockingTextWriter.put(chain(s, "\n"));
}

test2.d(12): Error: template std.stdio.File.LockingTextWriter.put cannot deduce
function from argument types !()(Result), candidates are:
/usr/local/Cellar/dmd/2.074.0/include/dlang/dmd/std/stdio.d(2742):   
std.stdio.File.LockingTextWriter.put(A)(A writeme) if
((isSomeChar!(Unqual!(ElementType!A)) || is(ElementType!A : const(ubyte))) &&
isInputRange!A && !isInfinite!A)
/usr/local/Cellar/dmd/2.074.0/include/dlang/dmd/std/stdio.d(2773):   
std.stdio.File.LockingTextWriter.put(C)(C c) if (isSomeChar!C || is(C :
const(ubyte)))

To be honest, I have no idea what is going on here, because the sig constraint

pragma(msg, (isSomeChar!(Unqual!(ElementType!A)) || is(ElementType!A :
const(ubyte))) && isInputRange!A && !isInfinite!A);

prints "true".

--

Re: problem with std.variant rounding

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

On Fri, Apr 28, 2017 at 04:42:28PM +, via Digitalmars-d-learn wrote:
[...]
> writefln(text("%.", i, "f"), x);
[...]

There's no need to use text() here:

writefln("%.*f", i, x);

does what you want.


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all I 
can take." -- Calvin & Hobbes

Re: Move construction from !is(T == typeof(this))

[Steven Schveighoffer via Digitalmars-d]

On 4/28/17 12:56 PM, Ola Fosheim Grøstad wrote:

On Thursday, 27 April 2017 at 12:28:38 UTC, Steven Schveighoffer wrote:

My solution would be to push the duplication onto the user. I'm not a
fan of implicit copying. It's also wasteful in the case of immutable
data.


Isn't that an odd stance given that "struct" is supposed to be a value
type?



Not really, but thanks for asking.

-Steve

Re: C++ Interfacing:'static' array function parameter contradiction

[ParticlePeter via Digitalmars-d-learn]

On Friday, 28 April 2017 at 17:57:34 UTC, Ali Çehreli wrote:

On 04/28/2017 08:56 AM, ParticlePeter wrote:
> C++ Function:
> bool cppFunc( float[3] color );
>
> D binding:
> extern(C++) bool cppFunc( float[3] color );
>
> Using with:
> float[3] my_color;
> cppFunc( my_color );
>
> -> Error: Internal Compiler Error: unable to pass static
array to

That part is a bug at least in the compiler message. Is it 
really an internal ctompiler error? Doesn't look like it: the 
compiler is talking to us happily. :)


My simple test works for me:

// deneme.cpp
float cppFunc(float color[3]) {
return color[0] + color[1] + color[2];
}

$ g++ -c deneme.cpp -o deneme_cpp.o

// deneme.d
extern(C++) float cppFunc(float * color);

void main() {
float[3] my_color = [ 1.5, 2.5, 3.5 ] ;
assert(cppFunc(my_color.ptr) == 7.5);
}

$ dmd deneme_cpp.o deneme.d -of=deneme

Builds and runs fine... on Linux... I don't know whether that's 
significant.


Ali


Interesting, your example corresponds to my third case, the 
linker error. I am on Window, building an x64 App, afaik in that 
case the MS Visual Studio linker is used instead of optilink. 
Will add your findings to the bug report.

Re: Garbage Collector?

[H. S. Teoh via Digitalmars-d]

On Fri, Apr 28, 2017 at 04:03:18PM +, bachmeier via Digitalmars-d wrote:
> On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:
> 
> > you could save yourself the bug by writing:
> > 
> > auto x = malloc(...);
> > scope(exit) free(x);
> > // ... however many pages of stuff you want, you don't have to
> > // remember to write free() afterwards!
> > 
> > Yes, D comes with a GC... doesn't mean you have to use it if you
> > don't want to, though!
> 
> I usually use the GC, so I have limited knowledge in this area. How
> common is this pattern in D code? Is it better than using reference
> counted structs? Is there any advantage to using the GC in this
> scenario?

To be honest, in my own D code I'm not overly concerned with the GC, and
even when I am, and want to control when / how often the GC collects, I
usually just use GC.disable() and then GC.collect() explicitly.  I've
seen performance gains of about 30-40% just by carefully reducing the
frequency of GC collections (IMO the default is a bit too eager), but of
course that depends on exactly what your application is doing.  In my
case, that was in the context of batch-oriented, CPU-intensive
computations that allocate often and mostly keeps live data.  YMMV if
your program is doing something else or has other patterns of memory
access.

But my point was that, if you really wanted to, you *could* use C-style
memory management in D code. D won't stop you from doing that. The
malloc heap is distinct from the GC heap so you won't run into
conflicts.  Of course, that also means you can't use D features that
currently require the GC, such as closures and dynamic arrays. But if
you're doing C-style memory management you probably already want to
implement your own way of handling array allocations and closure
functionality anyway. You can still pass slices of things around to
things like Phobos range algorithms (excepting the few that might
allocate -- hence marking your code with @nogc for the compiler to
enforce this), so generally a decent chunk of Phobos should still be
usable.

Even Phobos itself uses malloc/free directly in several places, for
various reasons, so I wouldn't say it's exactly a foreign thing to do in
D code.


> I would like to add this info to the wiki (I don't seen it there).

That would be very nice, thanks!


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit 
forever.

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[jmh530 via Digitalmars-d]

On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila


I remember you had posted about this last year. It looks like 
you've added some stuff on ranges to it recently...interesting.


You might want to include an example in the Readme.md of using 
the concept as a template constraint for a function. Maybe like


void callfoo(T)(T x)
if (isFoo!T)
{
x.foo();
}

Foo foo;
callfoo(foo);

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/28/2017 01:09 PM, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }



Hmm, close, but if I'm reading the source right, it looks like a type 
doesn't have to use the UDA in order for isXXX or "static 
assert(models..." to be satisfied, which was the whole issue I had. 
(Also, it'd be nice if it didn't require both isXXX and checkXXX to be 
manually written, because given a checkXXX function, the isXXX function 
is just boilerplate.)


Although I guess the checkXXX function could simply include a check the 
the UDA. Be nice if that was taken care of automatically though. Now if 
only we could get Phobos to do that...


I do, however, like the improved diagnostics this offers, and the fact 
that the checkXXX function uses a much saner (simpler, easier to 
read/remember/understand) syntax than the usual `is(typeof((){ ... })))` 
mess. I may use this.

Re: C++ Interfacing:'static' array function parameter contradiction

[Ali Çehreli via Digitalmars-d-learn]

On 04/28/2017 08:56 AM, ParticlePeter wrote:
> C++ Function:
> bool cppFunc( float[3] color );
>
> D binding:
> extern(C++) bool cppFunc( float[3] color );
>
> Using with:
> float[3] my_color;
> cppFunc( my_color );
>
> -> Error: Internal Compiler Error: unable to pass static array to

That part is a bug at least in the compiler message. Is it really an 
internal ctompiler error? Doesn't look like it: the compiler is talking 
to us happily. :)


My simple test works for me:

// deneme.cpp
float cppFunc(float color[3]) {
return color[0] + color[1] + color[2];
}

$ g++ -c deneme.cpp -o deneme_cpp.o

// deneme.d
extern(C++) float cppFunc(float * color);

void main() {
float[3] my_color = [ 1.5, 2.5, 3.5 ] ;
assert(cppFunc(my_color.ptr) == 7.5);
}

$ dmd deneme_cpp.o deneme.d -of=deneme

Builds and runs fine... on Linux... I don't know whether that's significant.

Ali

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

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

[ ... ]


Hi Guys, I just implemented sliceAssigment.

meaning the following code will now compile:

uint[] assignSlice(uint from, uint to, uint[] stuff)
{
uint[] slice;
slice.length = to + 4;
foreach (uint i; 0 .. to + 4)
{
slice[i] = i + 1;
}

slice[from .. to] = stuff;
return slice;
}

static assert(assignSlice(1, 4, [9, 8, 7]) == [1, 9, 8, 7, 5, 6, 
7, 8]);

Re: Garbage Collector?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
I'm hoping to put all information in one place. Then when 
someone on Reddit or HN or here starts making claims about the 
GC, I can give them one link that shows all of their options.


That's nice. Just get your hopes up for it having an effect. One 
of the key points of having it in the core distribution 
(compiler) is for library interoperability. Using multiple 
solutions ends up in chaos in real world projects...

Re: C++ Interfacing:'static' array function parameter contradiction

[ParticlePeter via Digitalmars-d-learn]

On Friday, 28 April 2017 at 17:15:54 UTC, kinke wrote:

On Friday, 28 April 2017 at 15:56:17 UTC, ParticlePeter wrote:

So what next? How can I interface to the cpp function?


*** C++:

bool cppFunc(float ()[3])
{
color[0] = 1;
color[1] = 2;
color[2] = 3;
return true;
}

*** D:

extern(C++) bool cppFunc(ref float[3] color);

void main()
{
float[3] my_color;
cppFunc(my_color);
assert(my_color == [ 1, 2, 3 ]);
}


The c++ lib is not mine and your answer implies extra work on the 
c++ from my side. Possible, but not desired, I think calling my 
original c++ function should interface with an d pointer. That 
being said, I think Kagamin is right.

Re: Garbage Collector?

[bachmeier via Digitalmars-d]

On Friday, 28 April 2017 at 17:06:51 UTC, jmh530 wrote:

On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:


I usually use the GC, so I have limited knowledge in this 
area. How common is this pattern in D code? Is it better than 
using reference counted structs? Is there any advantage to 
using the GC in this scenario?


I would like to add this info to the wiki (I don't seen it 
there).


You can also use automem
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/


I'm hoping to put all information in one place. Then when someone 
on Reddit or HN or here starts making claims about the GC, I can 
give them one link that shows all of their options. There's this 
page:

https://wiki.dlang.org/Memory_Management
but that isn't comprehensive or as to-the-point as it needs to be.

Re: C++ Interfacing:'static' array function parameter contradiction

[kinke via Digitalmars-d-learn]

On Friday, 28 April 2017 at 15:56:17 UTC, ParticlePeter wrote:

So what next? How can I interface to the cpp function?


*** C++:

bool cppFunc(float ()[3])
{
color[0] = 1;
color[1] = 2;
color[2] = 3;
return true;
}

*** D:

extern(C++) bool cppFunc(ref float[3] color);

void main()
{
float[3] my_color;
cppFunc(my_color);
assert(my_color == [ 1, 2, 3 ]);
}

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Atila Neves via Digitalmars-d]

On Friday, 28 April 2017 at 01:12:39 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:


Wasn't one major selling point of compile time introspection / 
duck
typing that we could stop using interfaces such... naming 
schemes?


Not that I speak for everyone, but the way I see it, no, the 
duck typing aspect is just something that's to be tolerated. 
The real gold is simply being freed from both the rigid mess 
and the runtime costs of class/interface hierarchies. I wish we 
DID have to include some kind of "implements ForwardRange" or 
"enum _thisStructImplements_ForwardRange" or some such to 
declare a type actually intends to be a ForwardRange (or 
whatever) and isn't merely qualifying as one by coincidence.


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila

Re: Garbage Collector?

[jmh530 via Digitalmars-d]

On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:


I usually use the GC, so I have limited knowledge in this area. 
How common is this pattern in D code? Is it better than using 
reference counted structs? Is there any advantage to using the 
GC in this scenario?


I would like to add this info to the wiki (I don't seen it 
there).


You can also use automem
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

Re: Move construction from !is(T == typeof(this))

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 27 April 2017 at 12:28:38 UTC, Steven Schveighoffer 
wrote:
My solution would be to push the duplication onto the user. I'm 
not a fan of implicit copying. It's also wasteful in the case 
of immutable data.


Isn't that an odd stance given that "struct" is supposed to be a 
value type?

Re: problem with std.variant rounding

[via Digitalmars-d-learn]

On Friday, 28 April 2017 at 16:42:28 UTC, Petar Kirov 
[ZombineDev] wrote:

On Friday, 28 April 2017 at 16:24:55 UTC, Suliman wrote:

On Friday, 28 April 2017 at 15:45:25 UTC, Suliman wrote:

I am using https://github.com/mysql-d/mysql-native
It's return from DB variant data-type.

My DB include value: 56.051151 (double type in DB)

I need to extract it. I tried several variants:

writeln(point[3].coerce!float);
writeln(point[3].coerce!string);
writeln(point[3].coerce!double);

but all of them return me it as: 56.0512

How to return exactly 56.051151 ?


import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;
writeln(x);
}


56.0512


The precision is still there, you're just not requesting it:

import std.conv : text;
import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;

foreach (i; 0 .. 10)
writefln(text("%.", i, "f"), x);
}

56
56.1
56.05
56.051
56.0512
56.05115
56.051151
56.0511513
56.05115128
56.051151276


How to return exactly 56.051151 ?


Specify the number of digits after the decimal point manually, 
e.g. writefln("%.6f", x) will print 56.051151.


BTW, you should always try to use the same floating-point type, 
so if you use 64-bit doubles in the database, you should also use 
double in your D code, otherwise you may accumulate rounding 
errors after each conversion. When converting to smaller 
floating-point types (real -> double and double -> float) you are 
essentially throwing out precision. For example:


import std.conv : text;
import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;

foreach (i; 0 .. 16)
{
writefln(text("%.", i, "f"), b.coerce!float);
writefln(text("%.", i, "f"), b.coerce!double);
}
}

Notice how the floats and doubles differ at i >= 6.

56
56
56.1
56.1
56.05
56.05
56.051
56.051
56.0512
56.0512
56.05115
56.05115
56.051151
56.051151
56.0511513
56.0511510
56.05115128
56.05115100
56.051151276
56.051151000
56.0511512756
56.051151
56.05115127563
56.0511510
56.051151275635
56.05115100
56.0511512756348
56.051151000
56.05115127563477
56.051151
56.051151275634766
56.0511507

Re: problem with std.variant rounding

[Suliman via Digitalmars-d-learn]

On Friday, 28 April 2017 at 16:49:18 UTC, kinke wrote:

On Friday, 28 April 2017 at 16:24:55 UTC, Suliman wrote:

import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;
writeln(x);
}


56.0512


void main()
{
import core.stdc.stdio;
import std.stdio;

double d = 56.051151;
writeln(d);
printf("%g %f %a\n\n", d, d, d);

real r = 56.051151L;
writeln(r);
printf("%Lg %Lf %La\n", r, r, r);
}

=>

56.0512
56.0512 56.051151 0x1.c068c1db0142fp+5

56.0512
56.0512 56.051151 0x1.c068c1db0142f61ep+5

So using write[ln]() to check floating-point values isn't a 
good idea as you may lose precision; hex formatting (or a 
proper debugger) is a much better choice. Additionally, your 
value isn't *exactly* representable; you may want to read up on 
floating-point representations if that's unclear.


Yeah! It was issue with rounding during writeln

Re: problem with std.variant rounding

[kinke via Digitalmars-d-learn]

On Friday, 28 April 2017 at 16:24:55 UTC, Suliman wrote:

import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;
writeln(x);
}


56.0512


void main()
{
import core.stdc.stdio;
import std.stdio;

double d = 56.051151;
writeln(d);
printf("%g %f %a\n\n", d, d, d);

real r = 56.051151L;
writeln(r);
printf("%Lg %Lf %La\n", r, r, r);
}

=>

56.0512
56.0512 56.051151 0x1.c068c1db0142fp+5

56.0512
56.0512 56.051151 0x1.c068c1db0142f61ep+5

So using write[ln]() to check floating-point values isn't a good 
idea as you may lose precision; hex formatting (or a proper 
debugger) is a much better choice. Additionally, your value isn't 
*exactly* representable; you may want to read up on 
floating-point representations if that's unclear.

Re: C++ Interfacing:'static' array function parameter contradiction

[Kagamin via Digitalmars-d-learn]

Report a bug.

Re: problem with std.variant rounding

[via Digitalmars-d-learn]

On Friday, 28 April 2017 at 16:24:55 UTC, Suliman wrote:

On Friday, 28 April 2017 at 15:45:25 UTC, Suliman wrote:

I am using https://github.com/mysql-d/mysql-native
It's return from DB variant data-type.

My DB include value: 56.051151 (double type in DB)

I need to extract it. I tried several variants:

writeln(point[3].coerce!float);
writeln(point[3].coerce!string);
writeln(point[3].coerce!double);

but all of them return me it as: 56.0512

How to return exactly 56.051151 ?


import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;
writeln(x);
}


56.0512


The precision is still there, you're just not requesting it:

import std.conv : text;
import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;

foreach (i; 0 .. 10)
writefln(text("%.", i, "f"), x);
}

56
56.1
56.05
56.051
56.0512
56.05115
56.051151
56.0511513
56.05115128
56.051151276


How to return exactly 56.051151 ?


Specify the number of digits after the decimal point manually, 
e.g. writefln("%.6f", x) will print 56.051151.

Re: problem with std.variant rounding

[Suliman via Digitalmars-d-learn]

On Friday, 28 April 2017 at 15:45:25 UTC, Suliman wrote:

I am using https://github.com/mysql-d/mysql-native
It's return from DB variant data-type.

My DB include value: 56.051151 (double type in DB)

I need to extract it. I tried several variants:

writeln(point[3].coerce!float);
writeln(point[3].coerce!string);
writeln(point[3].coerce!double);

but all of them return me it as: 56.0512

How to return exactly 56.051151 ?


import std.stdio;
import std.variant;

void main()
{
Variant b = 56.051151;
float x = b.coerce!float;
writeln(x);
}


56.0512

Re: Persistent key-value-store for D?

[krylon via Digitalmars-d-learn]

On Friday, 28 April 2017 at 16:01:58 UTC, yawniek wrote:

On Wednesday, 26 April 2017 at 17:06:52 UTC, krylon wrote:
I looked at the DUB package registry and asked Google quite a 
bit now, but I did not found such a package for D. So my first 
question is - did I not look hard enough? I found a 
reimplentation of QDBM [1] (the spiritual ancestor of 
Tokyocabinet), but it does not seem to handle concurrency at 
all. Are there other options along those lines? (If there was 
one that also provides transactions, that would be awesome!)


If I understand what I have read so far correctly, it is 
possible to access libraries written in C or C++ from D - in 
that case, I could just use Tokyocabinet directly, but I have 
not found any pointers on how to do this. Is this a feasible 
option, and if so, where can I find documentation on how to do 
this?



i recommend leveldb
http://code.dlang.org/packages/d-leveldb
its easy to use and mostly faster than tokyocabinet ( only very 
specifically tuned tokyo btrees  outperform leveldb)


i used above library with great success. it also shows you how 
to do c bindings.


Thank you for the suggestion!

For the moment I am using LMDB, as suggested in another reply, 
and it works well.

LevelDB seems to have a cleaner interface, though, at least in D.
I'll keep that in mind for future projects.

Re: Garbage Collector?

[bachmeier via Digitalmars-d]

On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:


you could save yourself the bug by writing:

auto x = malloc(...);
scope(exit) free(x);
// ... however many pages of stuff you want, you don't have to
// remember to write free() afterwards!

Yes, D comes with a GC... doesn't mean you have to use it if 
you don't want to, though!


I usually use the GC, so I have limited knowledge in this area. 
How common is this pattern in D code? Is it better than using 
reference counted structs? Is there any advantage to using the GC 
in this scenario?


I would like to add this info to the wiki (I don't seen it there).

Re: Persistent key-value-store for D?

[yawniek via Digitalmars-d-learn]

On Wednesday, 26 April 2017 at 17:06:52 UTC, krylon wrote:
I looked at the DUB package registry and asked Google quite a 
bit now, but I did not found such a package for D. So my first 
question is - did I not look hard enough? I found a 
reimplentation of QDBM [1] (the spiritual ancestor of 
Tokyocabinet), but it does not seem to handle concurrency at 
all. Are there other options along those lines? (If there was 
one that also provides transactions, that would be awesome!)


If I understand what I have read so far correctly, it is 
possible to access libraries written in C or C++ from D - in 
that case, I could just use Tokyocabinet directly, but I have 
not found any pointers on how to do this. Is this a feasible 
option, and if so, where can I find documentation on how to do 
this?



i recommend leveldb
http://code.dlang.org/packages/d-leveldb
its easy to use and mostly faster than tokyocabinet ( only very 
specifically tuned tokyo btrees  outperform leveldb)


i used above library with great success. it also shows you how to 
do c bindings.

C++ Interfacing:'static' array function parameter contradiction

[ParticlePeter via Digitalmars-d-learn]

C++ Function:
bool cppFunc( float[3] color );

D binding:
extern(C++) bool cppFunc( float[3] color );

Using with:
float[3] my_color;
cppFunc( my_color );

-> Error: Internal Compiler Error: unable to pass static array to 
extern(C++) function.

Error: Use pointer instead.


Using with:
cppFunc( my_color.ptr );

-> Error: function cppFunc( float[3] color ) is not callable 
using argument types (float*)



Altering D binding:
extern(C++) bool cppFunc( float* color );

Using with:
cppFunc( my_color.ptr );

-> error LNK2001: unresolved external symbol "bool __cdecl 
cppFunc(float *)" Binding.exe : fatal error LNK1120: 1 unresolved 
externals

Error: linker exited with status 1120
dmd failed with exit code 1120.


So what next? How can I interface to the cpp function?

Re: OT: Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov 
[ZombineDev] wrote:

[...]

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V, WebAssembly, etc. using CTFE.
* CTFE-driven code diagnostics (linting)
* Adding semantic to user defined attributes:
  E.g. @asyncSafe attribute for use in libraries like vibe.d 
that allows calling only
  functions marked as @asyncSafe from @asyncSafe code. That way 
libraries can
  introduce *and enforce* correct use of UDAs without any need 
for language changes.

* ...


Thanks for the summary :)

problem with std.variant rounding

[Suliman via Digitalmars-d-learn]

I am using https://github.com/mysql-d/mysql-native
It's return from DB variant data-type.

My DB include value: 56.051151 (double type in DB)

I need to extract it. I tried several variants:

writeln(point[3].coerce!float);
writeln(point[3].coerce!string);
writeln(point[3].coerce!double);

but all of them return me it as: 56.0512

How to return exactly 56.051151 ?

Re: Garbage Collector?

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
I'm sorry, but that's just plain wrong. D does not have 
ownership pointers because nobody that wants them has stepped 
up and
1) Done the work of drafting an informal proposal that 
*actually deals with _all_ of the issues involved*


Wrong. This has been discussed and hashed out to death over and 
over again. The solutions are on the table.


No. Every single thread I read in the last couple of years ended 
with Walter pointing out issues that need to be "hashed out" and 
then nobody doing it.




Walter's position has always been that having more than a 
single pointer type is a disaster.


None of the threads I've read in the last couple of years 
regarding that support that claim.




That makes further work on it pointless.


What you consider worth working on is your business, of course :)

Re: Blog post on automem

[Swoorup Joshi via Digitalmars-d-announce]

On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
Atila was kind enough to do a write up on his automem library 
for the D Blog, talking about why he did it and showing some of 
the implementation details. This is officially part of the GC 
series. The next post in the series will be my @nogc post (I've 
pushed it back to after DConf).


[...]


Automem is something, that should just be there in the standard 
library.

Re: Garbage Collector?

[H. S. Teoh via Digitalmars-d]

On Fri, Apr 28, 2017 at 09:01:03AM +, Moritz Maxeiner via Digitalmars-d 
wrote:
> On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
[...]
> > Is it so hard for developers when you declare a variable, to later
> > also clean it up???
> > 
> > var x = 1;
> > // Do work
> > x.free;
> 
> If you write it like that, yes, because often it's not just one such
> make/dispose pair per scope, but multiple, possibly overlapping ones
> and people make mistakes. And the more complex a piece of code gets
> the harder it becomes to decipher such pairs and/or decide if the
> "closing" dispose is missing.
> This is one of the reasons why scope guards are good:
> 
> var x = 1;
> scope (exit) x.free
> // Do work
> 
> This, as code becomes more complex, allows for much easier reading
> (and understanding) of lifetimes.
[...]

Elephant in the room: D lets you call the C library's malloc() and
free(). If you absolute insist that you don't want to use the GC, go
right ahead and import core.c.stdlib, and malloc and free away.  As
mentioned above, D's scope guards will even help you avoid mistakes by
keeping allocation and free in the same scope together, i.e., instead of
writing:

auto x = malloc(...);
// do stuff
// and more stuff
// and more stuff
// so many pages of stuff you forgot about x
free(x);// very likely you'll forget this by now

you could save yourself the bug by writing:

auto x = malloc(...);
scope(exit) free(x);
// ... however many pages of stuff you want, you don't have to
// remember to write free() afterwards!

Yes, D comes with a GC... doesn't mean you have to use it if you don't
want to, though!


T

-- 
Doubt is a self-fulfilling prophecy.

Re: Blog post on automem

[jmh530 via Digitalmars-d-announce]

On Friday, 28 April 2017 at 14:40:03 UTC, Mike Parker wrote:
Atila was kind enough to do a write up on his automem library 
for the D Blog, talking about why he did it and showing some of 
the implementation details. This is officially part of the GC 
series. The next post in the series will be my @nogc post (I've 
pushed it back to after DConf).




I was just looking at automem, but it's nice to have a blog post 
written up too!

[Issue 17357] New: DMD wrongly considers template instance class as nested

[via Digitalmars-d-bugs]

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

  Issue ID: 17357
   Summary: DMD wrongly considers template instance class as
nested
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pun...@coverify.org

When compiled with github HEAD, I get:
test.d(6): Error: outer class Foo 'this' needed to 'new' nested class Frop
For now the workaround is to declare Frop static.

// static
class Frop(alias t) { }

void build(G)(G g) {
  alias E = typeof(g.tupleof[0]);
  g.tupleof[0] = new E;
}

class Tx {
  class Foo  {
Frop!a cp_a;
int a;
  }
  Foo bar;
  this() { bar = new Foo; }
}

void main() {
  Tx tx ;
  tx = new Tx;
  tx.bar.build;
}

--

Re: Garbage Collector?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
I'm sorry, but that's just plain wrong. D does not have 
ownership pointers because nobody that wants them has stepped 
up and
1) Done the work of drafting an informal proposal that 
*actually deals with _all_ of the issues involved*


Wrong. This has been discussed and hashed out to death over and 
over again. The solutions are on the table.


Walter's position has always been that having more than a single 
pointer type is a disaster.


That makes further work on it pointless.

(Although, arguably, D kinda has several pointer types already).

[Issue 7102] std.numeric.gcd with BigInts too

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |FIXED

--

[Issue 7102] std.numeric.gcd with BigInts too

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/35bbd3611ee4a977f2bedf98e8b15160eb01fd11
Merge pull request #5350 from quickfur/issue7102a

Fix issue 7102: std.numeric.gcd overload that works with non-builtin types
merged-on-behalf-of: Jack Stouffer 

--

Blog post on automem

[Mike Parker via Digitalmars-d-announce]

Atila was kind enough to do a write up on his automem library for 
the D Blog, talking about why he did it and showing some of the 
implementation details. This is officially part of the GC series. 
The next post in the series will be my @nogc post (I've pushed it 
back to after DConf).


When I publish the next one, I'll add a page to the blog with 
each post in the series linked under two categories: 'GC 
Fundamentals' and 'Memory Management Strategies'. Atila's post 
sits squarely in the latter. If you have a particular strategy 
you use for working with D's GC, please let me know and we can 
talk about a post (guest post or otherwise).


Blog:
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

Reddit:
https://www.reddit.com/r/programming/comments/682xzc/automem_a_library_for_cstyle_raii_in_d/

Re: CTFE Status 2

[Nordlöw via Digitalmars-d]

On Friday, 28 April 2017 at 13:13:16 UTC, Stefan Koch wrote:

Do you mean no Jit?


Of course there will be a JIT.


Ah, I misunderstood you formulation.


But currently I am fixing busy bugs in the generated IR.
So the implementation of jit will have to wait a little.


Ok. Thanks.

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Dominikus Dittes Scherkl via Digitalmars-d]

On Friday, 28 April 2017 at 13:19:47 UTC, Chris wrote:
On Thursday, 27 April 2017 at 12:29:48 UTC, Steven 
Schveighoffer wrote:

On 4/24/17 1:43 AM, Nick Sabalausky (Abscissa) wrote:

"Dashing, awesome, ultra-attractive programmer with an 
impeccably fine

taste in languages."

It's a bit long and doesn't include the letter D


FIFY

-Steve


D-veloper.


Yeah, I suggested that 4 days ago, but got no responses. So it 
seems nobody is pleased with this term :-(

Re: OT: Re: DConf Hackathon Ideas

[via Digitalmars-d]

On Friday, 28 April 2017 at 10:09:32 UTC, Moritz Maxeiner wrote:
On Friday, 28 April 2017 at 09:52:29 UTC, Petar Kirov 
[ZombineDev] wrote:


AST introspection - given a function definition (!= 
declaration, i.e. the body is available) f, the expression 
__traits(ast, f) should return an instance of FuncDeclaration 
(https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.




This sounds interesting, but could you expand on what this 
enables/improves compared to CTFE+mixins?


CTFE and mixins are building blocks, needed to for my idea to 
actually useful.
Currently if you want to introspect a piece of code (function 
body) at compile time,
you need to duplicate the code in a string and then pass this 
string to a
CTFE-able D parser. As you can imagine, even with Stefan's new 
CTFE engine,
this would be orders of magnitude slower than just reusing the 
work that parser
inside the compiler *has already done* anyway. This makes such 
code introspection

infeasible for large projects. Strings (at least until mixined)
can contain uncompilable source (though lexically valid, in the 
case of q{}),
further complicating the matter. Additionally, the fact that you 
need to
keep the source code and the strings in sync is just stupid, 
violating DRY

at a whole new level.

In addition to AST introspection, AST transformation should be as 
easy as:


mixin template profileFunctionStatements(alias func, string 
newFunctionName)

{
enum funcAst = __traits(ast, func);
enum newAst = insertProfiling(funcAst, newFunctionName);
mixin(newAst.toString());

// a further optimization would be AST mixins, which
// could directly be used by the compiler, instead of
// first converting the AST to string and then
// parsing it after mixing:
mixin(newAst);
}

void main()
{
int local = 42;

void fun(int[] arr)
{
import std.conv : text;
import std.file : remove, write;
arr[] += local;
string s = text(arr);
"delete-me.txt".write(s);
}

mixin profileFunctionStatements!(print, `funInstrumented`);

import std.array : array;
import std.range : iota;
funInstrumented(1.iota.array);
}

Output:
{  arr[] += local;  } took 0.002 miliseconds to execute.
{  string s = text(arr);  } took 1.8052 miliseconds to execute.
{ "delete-me.txt".write(s); } took 7.746 miliseconds to execute.

Where funInstrumented could be generated to something like this:

void funInstrumented(int[] arr)
{
import std.datetime : __Sw = StopWatch, __to = to; // 
generated

import std.stdio : __wfln = writefln; // generated
import std.conv : text;
import std.file : remove, write;

__Sw __sw; // generated

__sw.start(); // generated
arr[] += local;
__sw.stop(); // generated
__wfln("{ %s } took %s miliseconds to execute.",
q{ arr[] += local; },
__sw.peek().__to!("msecs", double)); // generated

__sw.start(); // generated
string s = text(arr);
__sw.stop(); // generated
__wfln("{ %s } took %s miliseconds to execute.",
q{ string s = text(arr); },
__sw.peek().__to!("msecs", double)); // generated

__sw.start(); // generated
"delete-me.txt".write(s);
 __sw.stop(); // generated
__wfln("{%s} took %s miliseconds to execute.",
q{ "delete-me.txt".write(s); },
__sw.peek().__to!("msecs", double)); // generated
}

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V, WebAssembly, etc. using CTFE.
* CTFE-driven code diagnostics (linting)
* Adding semantic to user defined attributes:
  E.g. @asyncSafe attribute for use in libraries like vibe.d that 
allows calling only
  functions marked as @asyncSafe from @asyncSafe code. That way 
libraries can
  introduce *and enforce* correct use of UDAs without any need 
for language changes.

* ...

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Chris via Digitalmars-d]

On Thursday, 27 April 2017 at 12:29:48 UTC, Steven Schveighoffer 
wrote:

On 4/24/17 1:43 AM, Nick Sabalausky (Abscissa) wrote:

"Dashing, awesome, ultra-attractive programmer with an 
impeccably fine

taste in languages."

It's a bit long and doesn't include the letter D


FIFY

-Steve


D-veloper.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Friday, 28 April 2017 at 13:03:42 UTC, Nordlöw wrote:

On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
After a little of exploration of the JIT, I have now 
determined that a simple risc architecture is still the best.

(codegen for scaled loads is hard :p)


Do you mean no Jit?


Of course there will be a JIT.

But currently I am fixing busy bugs in the generated IR.
So the implementation of jit will have to wait a little.

Re: CTFE Status 2

[Nordlöw via Digitalmars-d]

On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
After a little of exploration of the JIT, I have now determined 
that a simple risc architecture is still the best.

(codegen for scaled loads is hard :p)


Do you mean no Jit?

Re: DConf Hackathon Ideas

[Jacob Carlborg via Digitalmars-d]

On 2017-04-27 19:06, Andre Pany wrote:


Another big issue for me is using dub in a company. Big companies do not
want to use the official dub repository due to security issues.


That would be nice.

--
/Jacob Carlborg

[Issue 17352] [REG 2.075a] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

[via Digitalmars-d-bugs]

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

--- Comment #4 from Ketmar Dark  ---
yeah. but the frontend will check for conflicting overloads only when `foo()`
will be called. i guess this was done to gain some compilation speed by not
checking each symbol against other symbols (O(n^2), i think).

but this can be done differently, by using a hash table of all emited mangled
names. this should be amortized O(n), and virtually painless.

i mean, yes, the frontend should check for conflicting overloads even if they
weren't called anywhere.

--

OT: Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

On Friday, 28 April 2017 at 09:52:29 UTC, Petar Kirov 
[ZombineDev] wrote:


AST introspection - given a function definition (!= 
declaration, i.e. the body is available) f, the expression 
__traits(ast, f) should return an instance of FuncDeclaration 
(https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.




This sounds interesting, but could you expand on what this 
enables/improves compared to CTFE+mixins?