Fallback 'catch-all' template functions

[Manu via Digitalmars-d]

So, consider a set of overloads:

  void f(T)(T t) if(isSomething!T) {}
  void f(T)(T t) if(isSomethingElse!T) {}
  void f(T)(T t) {}

I have a recurring problem where I need a fallback function like the
bottom one, which should be used in lieu of a more precise match.
This is obviously an ambiguous call, but this is a pattern that comes
up an awful lot. How to do it in D?

I've asked this before, and people say:

  void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}

Consider that more overloads are being introduced by users spread out
across many modules that define their own kind of T; this solution is
no good.

[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters

[via Digitalmars-d-bugs]

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

Thayne  changed:

   What|Removed |Added

 CC||astrotha...@gmail.com

--- Comment #7 from Thayne  ---
I still see this in dmd 2.071.1, and I see similar behavior for out contracts:

---
import std.stdio;
import std.conv;
import std.algorithm : canFind;

interface I {
string foo(int input)
in {
writefln("In in, input = %s", input);
}
out (result) {
writefln("In out, input = %s", input);
writefln("Result = %s", result);
assert(result.canFind(to!string(input)));
}
}

class C : I {
string foo(int input) in { assert(false); } body {
writefln("Input = %s", input);
return "Foo " ~ to!string(input);
}
}

void main() {
auto c = new C;

c.foo(5);
}
---

--

Re: Prevent copy of range in foreach

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 23:38:21 UTC, Yuxuan Shui wrote:



OK, this would work for cases like containers. But what if I 
represent buffered network input as a range (like File.byLine), 
and I don't want to copy the buffer all the time? Any 
suggestion on how to do that correctly?


Then the range should be constructed with a slice of the buffer 
if it's an array or with something pointer-based if it isn't 
(which requires a bit of bookkeeping). Ranges should be 
lightweight and should never require copying of the underlying 
data.

[Issue 16455] Wrong code when calling a struct delegate

[via Digitalmars-d-bugs]

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

apham  changed:

   What|Removed |Added

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

--- Comment #3 from apham  ---
need to move the setting "doPopFront = " out of constructor to make it
work. Can move it to empty() to complete the initialization

--

Re: dub test

[Lurker via Digitalmars-d]

On Wednesday, 24 August 2016 at 13:52:43 UTC, Andrei Alexandrescu 
wrote:

// This will always be true
assert(a >= 1 && a <= 5);
assert(a >= 0.0 && a <= 10.0);


Pretty sure you have a bug here :)

Re: Prevent copy of range in foreach

[Yuxuan Shui via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 18:28:20 UTC, Ali Çehreli wrote:

On 08/31/2016 07:03 AM, Yuxuan Shui wrote:

> I want to make a hash table that uses
> std.experiment.allocator. The bucket is allocated from an
> allocator, and freed in ~this(). I don't want to copy the
whole
> bucket in this(this).

It sounds like you are conflating the concept of a container 
with the concept of a range. The range should be separate from 
the container and should be cheap to copy.


Ali


OK, this would work for cases like containers. But what if I 
represent buffered network input as a range (like File.byLine), 
and I don't want to copy the buffer all the time? Any suggestion 
on how to do that correctly?

[Issue 16457] New: std.regex postprocesses at ctRegex every time at runtime

[via Digitalmars-d-bugs]

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

  Issue ID: 16457
   Summary: std.regex postprocesses at ctRegex every time at
runtime
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Consider the following program, it will crash as it allocates _a lot_ of memory
before the garbage can be collected. 

void main()
{
import std.regex;
enum re = ctRegex!(`((c)(s)?)?ti`);
import core.memory : GC;
string text = "Lorem ipsum dolor sit amet, consectetur adipiscing elit";

foreach (i; 0..500_000_000)
{
if (auto m = matchAll(text, re)) {}
//if (i % 1_000_000)
//GC.collect();
}
}

On my machine (16G) it crashes at about 5M iterations.
The GC profile finds two hotspots (here 2M iterations): 

 204800200uint[] D main
std/regex/internal/parser.d:1607
  18400200std.regex.internal.ir.Bytecode[] D main
std/array.d:852

(the latter is insertInPlace)

After looking at the code it seems pretty weird, because "postprocess" should
be called while constructing the RegEx and once only.

--

Re: Debug prints in @nogc

[Yuxuan Shui via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 19:39:36 UTC, ag0aep6g wrote:

On 08/31/2016 09:23 PM, Yuxuan Shui wrote:
Correct me if I'm wrong. But I believe this is only true when 
the source
code of function is not available. Otherwise the compiler 
should always

know if a function is actually @nogc or not.


Attributes are only inferred in certain cases where the source 
code must be available anyway (templates, `auto` return value). 
For ordinary functions, the compiler only considers them @nogc 
when they're explicitly marked.


For example, the compiler won't let you do this, even though 
f's source code is available and it's obviously de-facto @nogc:



void f() {}
void main() @nogc { f(); }



That's a good point. By IMHO, all the (non-template) function in 
Phobos that can be marked @nogc, should be marked @nogc, 
otherwise it's a bug. If the function is in your own code, you 
should use @nogc, not assumeNogc.


After a second thought, the real use case of assumeNogc is 
probably virtual functions. But then again, it is kind of 
dangerous to use it even in this case.

[Issue 16455] Wrong code when calling a struct delegate

[via Digitalmars-d-bugs]

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

apham  changed:

   What|Removed |Added

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

--- Comment #2 from apham  ---
Based on this https://dlang.org/spec/function.html#closures and the code, the
struct var is not moving anywhere and not out of scope, so it must work

--

Re: Joakim Intreviews Walter for the D Blog

[Walter Bright via Digitalmars-d-announce]

On 8/30/2016 1:27 PM, Walter Bright wrote:

https://news.ycombinator.com/item?id=1239047


Well, that seems to be the wrong url :-(

Re: Why D is not popular enough?

[Walter Bright via Digitalmars-d]

On 8/31/2016 2:17 AM, Seb wrote:

Done (FYI the translations aren't officially published yet) ;-)


Danke schoen!

[Issue 16455] Wrong code when calling a struct delegate

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

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

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to apham from comment #0)
> struct NodeRange(S)
> {
[...]
> void delegate() doPopFront;
> 
> void doMove()
> {
[...]
> }
[...]
> this(Node!S aParent)
> {
[...]
> doPopFront = 
> }
[...]
> }

As far as I see, that code is invalid.  refers to the current location
of the struct. But structs can be copied and moved around (the compiler is even
allowed to do it on its own). Whenever that happens, doPopFront is invalidated.

Closing as invalid. Please reopen if you disagree.

--

[Issue 16456] RDMD: Add --include switch to override --exclude options

[via Digitalmars-d-bugs]

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

Andrej Mitrovic  changed:

   What|Removed |Added

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

--- Comment #1 from Andrej Mitrovic  ---
https://github.com/dlang/tools/commit/c568ac7a8159d3ddced1c18ff53556ea3beff14c

--

[Issue 16456] RDMD: Add --include switch to override --exclude options

[via Digitalmars-d-bugs]

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

Andrej Mitrovic  changed:

   What|Removed |Added

Summary|Add --include switch to |RDMD: Add --include switch
   |override --exclude options  |to override --exclude
   ||options

--

[Issue 16456] New: Add --include switch to override --exclude options

[via Digitalmars-d-bugs]

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

  Issue ID: 16456
   Summary: Add --include switch to override --exclude options
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

There are already some built-in excludes for Phobos, overriding these is useful
in case we want to make RDMD build a module using its own dependencies rather
than being expected to link with an existing phobos.lib

I can imagine this might be useful when working on new Phobos features.

https://github.com/dlang/tools/pull/183

--

[Issue 16431] rdmd runs dmd twice for single-files with no dependencies

[via Digitalmars-d-bugs]

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

Andrej Mitrovic  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Andrej Mitrovic  ---
Fixed right? Closing.

--

You can call Fiber.yield() inside a vectored exception handler (win32)

[Cauterite via Digitalmars-d]

In case anyone was wondering, in 32-bit Windows you can call 
Fiber.yield() from inside a vectored exception handler, and 
subsequently resume the fibre again.

As far as I can tell it works flawlessly.

Here's a little example:

---

extern(Windows) int on_exception_global(EXCEPTION_POINTERS* X) 
nothrow {

/* once installed, this function will be called for every
exception raised in the current process */

if (X.ExceptionRecord.ExceptionCode == STATUS_ACCESS_VIOLATION) {

Fibre.yield(); // can do!

// retry the instruction that raised the exception
return EXCEPTION_CONTINUE_EXECUTION;
};

// call next exception handler
return EXCEPTION_CONTINUE_SEARCH;
};

auto Hdl = enforce(AddVectoredExceptionHandler(
1, /* insert at front of exception-handler chain */
_exception_global
));

---

Careful about throwing from inside your exception handler (any 
kind of software or hardware exception, not limited to 
'Throwable'). Don't want to end up in an infinite loop.

Re: So why was typedef bad?

[Ali Çehreli via Digitalmars-d]

On 08/31/2016 06:44 AM, Ethan Watson wrote:

> And it makes that member private. You
> know what this means - if I try to parse over it for my serialisation
> pass for Binderoo, I can't use __traits( allMembers ) to get to it.

Hopefully, with enough whining we will have that behavior reversed. :) 
__traits(allMembers) should give "all members".


Ali

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Ali Çehreli via Digitalmars-d]

On 08/30/2016 03:24 PM, Ali Çehreli wrote:
> v2.071.2-b3 is bringing a change for this bug:
>
>   https://issues.dlang.org/show_bug.cgi?id=15907
>
> I don't agree with the current solution:
>
>   http://dlang.org/changelog/2.071.2.html#traits-members-visibility
>
> Modules should be able to use library templates without needing to mix
> them in first.
>
> Do you think the solution in the change log usable? I don't think so
> because silently skipping my private members is an unexpected behavior
> that will cause bugs.

Here is a regression caused by the above change:

interface I {
void foo();

package:

void foo(int);
}

string how(alias Base, alias func)() {
return "";
}

import std.typecons;
class C : AutoImplement!(I, how) {
}

void main() {
auto c = new C();
c.foo();
c.foo(42);// COMPILATION ERROR:
// deneme.o: In function `_Dmain':
// deneme.d:(.text._Dmain+0x39): undefined reference to 
`_D6deneme1I3fooMFiZv'

// collect2: error: ld returned 1 exit status
}

WAT?

It's not reasonable for the user to somehow suspect that AutoImplement 
may be using a D feature (__traits(allMembers) in this case) which 
happens to not see foo(int). (Note that AutoImplement may see foo(int) 
today but not tomorrow, if it's moved out of this package.)


The recommended solution of mixing in every template instance is not a 
viable solution because that would effectively remove IFTI from D. What 
a huge loss that would be. We can't afford that.


So, to be safe, every D code out there that happens to pass a struct to 
a piece of library function would have to


1) Know that that library function happens to be a template and

2) mixin the particular instantiation of that template.

That would be the only sane thing to do. Further, what happens if a 
function changes its implementation and becomes a template that happens 
to call __traits(allMembers)? How can the library notify its users to 
tell them to mixin an explicit instantiation?


Ali

[Issue 16455] New: Wrong code when calling a struct delegate

[via Digitalmars-d-bugs]

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

  Issue ID: 16455
   Summary: Wrong code when calling a struct delegate
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ap...@hotmail.com

Created attachment 1612
  --> https://issues.dlang.org/attachment.cgi?id=1612=edit
Test case

module Test;

import std.stdio : writeln;

class Node(S)
{
Node!S parent;
Node!S first;
Node!S next;
S text;

this()
{
}

this(S aText)
{
text = aText;
}

NodeRange!S children()
{
return NodeRange!S(this);
}

Node!S push(Node!S aNode)
{
assert(aNode.next is null);

aNode.parent = this;
if (first is null)
first = aNode;
else
{
aNode.next = first;
first = aNode;
}
return aNode;
}
}

struct NodeRange(S)
{
private:
Node!S parent;
Node!S current;
void delegate() doPopFront;

void doMove()
{
writeln("doMove()");
assert(current !is null);

current = current.next;
}

public:
this(Node!S aParent)
{
writeln("aParent.text: ", aParent.text);

parent = aParent;
current = aParent.first;
doPopFront = 
}

void popFront()
{
writeln("popFront()");
assert(current !is null);

// work if straight call
//doMove(); 

// access violation when calling delegate
// or current is not set correctly
doPopFront();  
}

@property 
{
bool empty()
{
return (current is null);
}

Node!S front()
{
return current;
}
}
}

void main()
{
Node!string tree = new Node!string();
Node!string first = tree.push(new Node!string("first"));
first.push(new Node!string("firstChild"));

NodeRange!string r = tree.first.children();

assert(!r.empty);
writeln("r.front.text: ", r.front.text);
assert(r.front.text == "firstChild");
r.popFront();

writeln("r.empty: ", r.empty);
assert(r.empty);
}

--

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:

On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
I just came up with a nifty little patch that makes it 
possible to ensure that a function is _only_ used at ctfe.

Or the opposite.

static assert(__ctfe, "This function is not supposed to be 
called outside of ctfe");
and static assert(!__ctfe, "This function is not supposed to 
be called during ctfe");


similarly you can use static if (__ctfe).

Is it worth trying to get it into master ?


Yes, please. I've often wished I could use `__ctfe` in a 
`static if`.


Sorry. It I overlooked a something rather important. static 
__ctfe is currently not possible and it's rather expensive to 
make it possible.

Re: Eclipse Paho D Library (finally) started

[Frank Pagliughi via Digitalmars-d-announce]

On Wednesday, 31 August 2016 at 18:06:07 UTC, Atila Neves wrote:

Are you aware of this?
https://github.com/atilaneves/mqtt


I had a vague idea of one or two similar projects underway. But 
90% of the code I just posted was written in early 2015. The 
initial delay getting it published was with the Eclipse legal 
process which dragged on for a few months, and just as it was 
done, they decided to move their development to GitHub. By that 
time I wasn't doing anything with D or MQTT, and the inertia died.


The idea from the beginning was do a fairly quick/simple wrapper 
library around the Paho C library, which would get the D version 
feature-complete and fully compliant in short time. Then the idea 
was to move on to a full D implementation for version 2.0. If 
there were any interest.


So this version doesn't do any of its own I/O; that's left to the 
C layer. Thus it doesn't require - and I'm not sure how it could 
be made compatible with - vibe.d


And originally I believe the Eclipse folks had wanted to keep 
external libraries to a minimum, but now exceptions to the rule 
seem to be the norm. So using vibe.d would probably be fine, 
assuming no license issues.

Re: Template not seeming to instantiate a second time with default alias parameter

[wobbles via Digitalmars-d-learn]

On Tuesday, 30 August 2016 at 21:35:29 UTC, ag0aep6g wrote:

On 08/30/2016 11:28 PM, wobbles wrote:

I'll have to try find a workaround for now :/


This seems to work and isn't too ugly:


class Node(T, alias func) {/*...*/}
alias Node(T) = Node!(T, (T t) => t*t);



Excellent - thanks for these.
This one will work for me :)

I was going to do something messy with a nested template and some 
static ifs. But, complicated things are complicated. This is much 
easier.

Thanks!

Re: Debug prints in @nogc

[ag0aep6g via Digitalmars-d-learn]

On 08/31/2016 09:23 PM, Yuxuan Shui wrote:

Correct me if I'm wrong. But I believe this is only true when the source
code of function is not available. Otherwise the compiler should always
know if a function is actually @nogc or not.


Attributes are only inferred in certain cases where the source code must 
be available anyway (templates, `auto` return value). For ordinary 
functions, the compiler only considers them @nogc when they're 
explicitly marked.


For example, the compiler won't let you do this, even though f's source 
code is available and it's obviously de-facto @nogc:



void f() {}
void main() @nogc { f(); }

Re: Debug prints in @nogc

[Yuxuan Shui via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 18:07:46 UTC, Cauterite wrote:

On Wednesday, 31 August 2016 at 16:17:51 UTC, Yuxuan Shui wrote:
No. When you use assumeUnique, you know something the compiler 
does know, and have to use assumeUnique to tell the compiler 
that (at least when you use it correctly). But when you use 
assumeNogc, it's always because you want to bypass compiler 
checks.


assumeNogc works the same way, you're telling the compiler 
something it doesn't know — that the function should be treated 
as @nogc. Using assumeNogc on a function that calls the GC is 
as unsafe as using assumeUnique on a reference that is not 
unique.


Correct me if I'm wrong. But I believe this is only true when the 
source code of function is not available. Otherwise the compiler 
should always know if a function is actually @nogc or not.

Re: Low level unit test library in druntime

[Jacob Carlborg via Digitalmars-d]

On 2016-08-31 12:06, Atila Neves wrote:


Right now I think you're right and the compiler needs to know. But let
me see what I can do about it with the language we have now.


Or using AST macros :)

--
/Jacob Carlborg

Image of D code on Norwegian IT news site

[simendsjo via Digitalmars-d]

An article about how outsourcing reduces the need for Norwegian 
developers. No links to D other than the image on top though. I 
wonder what they searched for to find this image.


http://www.digi.no/artikler/rader-norske-it-folk-til-a-droppe-programmering/279380

Re: Prevent copy of range in foreach

[Ali Çehreli via Digitalmars-d-learn]

On 08/31/2016 07:03 AM, Yuxuan Shui wrote:

> I want to make a hash table that uses
> std.experiment.allocator. The bucket is allocated from an
> allocator, and freed in ~this(). I don't want to copy the whole
> bucket in this(this).

It sounds like you are conflating the concept of a container with the concept 
of a range. The range should be separate from the container and should be cheap 
to copy.

Ali

[Issue 16447] Warn about auto return type when no return statement is present

[via Digitalmars-d-bugs]

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

Cauterite  changed:

   What|Removed |Added

 CC||cauter...@gmail.com

--- Comment #3 from Cauterite  ---
(In reply to b2.temp from comment #2)
> nvm, i've made it in dscanner.

Nevermind? Huh?
This sounds like a valid concern to me. There is no way your inline-assembly
example should be allowed to compile with auto return type.

--

[Issue 16454] Return in the body of a foreach in a constructor backed by opApply corrupts the object

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com
   Hardware|x86_64  |All
 OS|Mac OS X|All

--- Comment #1 from ag0ae...@gmail.com ---
Slightly reduced:


struct OpApply {
int opApply(int delegate(int) cb) { return 0; }
}

struct Bolinha {
int a = 0;
this(int dummy) {
OpApply moviadao;
foreach(int b; moviadao) return;
}
}

void main() {
import std.stdio;
writeln(Bolinha(0).a);
}


Also fails on Linux and Windows (wine).

--

Re: Debug prints in @nogc

[Cauterite via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 16:17:51 UTC, Yuxuan Shui wrote:
No. When you use assumeUnique, you know something the compiler 
does know, and have to use assumeUnique to tell the compiler 
that (at least when you use it correctly). But when you use 
assumeNogc, it's always because you want to bypass compiler 
checks.


assumeNogc works the same way, you're telling the compiler 
something it doesn't know — that the function should be treated 
as @nogc. Using assumeNogc on a function that calls the GC is as 
unsafe as using assumeUnique on a reference that is not unique.

Re: Eclipse Paho D Library (finally) started

[Atila Neves via Digitalmars-d-announce]

On Wednesday, 31 August 2016 at 14:14:36 UTC, Frank Pagliughi 
wrote:

Hey All,

First, my apologies. Over a year ago I had promised to put up a 
D library for MQTT, but a number of factors conspired against 
me in the intervening time.


[...]


Are you aware of this?

https://github.com/atilaneves/mqtt

Atila

Re: Multi-threading how-to

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

On Wed, Aug 31, 2016 at 05:53:27PM +, Cauterite via Digitalmars-d-learn 
wrote:
> On Wednesday, 31 August 2016 at 17:37:25 UTC, solidstate1991 wrote:
> > I decided to add a functionality that if multiple programs use the
> > same instance of the library on the same computer, the messages will
> > be passed directly instead of via networking.
> 
> What you're describing here is not actually multi-threading, it's
> multi-process…ing. The keyword you're looking for is "inter-process
> communication".
> 
> You have a huge range of possible options for implementing this. Your
> decision would depend on your operating system, your existing
> implementation with sockets, and desired performance.
> 
> My suggestion: try just using sockets between processes on the same
> PC. You might not even need to add any new code to support this
> method, and it might be faster than you'd expect.
[...]

If you're on Posix (Linux, *nix, etc.), you could also use pipes, which may
be easier to setup.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he 
said, "A double negative forms a positive. In some languages, though, such as 
Russian, a double negative is still a negative. However, there is no language 
wherein a double positive can form a negative." A voice from the back of the 
room piped up, "Yeah, yeah."

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 30, 2016 15:24:12 Ali Çehreli via Digitalmars-d wrote:
> v2.071.2-b3 is bringing a change for this bug:
>
>https://issues.dlang.org/show_bug.cgi?id=15907
>
> I don't agree with the current solution:
>
>http://dlang.org/changelog/2.071.2.html#traits-members-visibility
>
> Modules should be able to use library templates without needing to mix
> them in first.

Agreed. Having to mix stuff in for introspection is downright ugly. It makes
far more sense to provide everything and then check the attributes as
discussed elsewhere in this thread.

IMHO, having allMembers give different results depending on access level is
just plain broken.

I confess that I see no problem being able to examine symbols that are not
accessible due to the access level. They just shouldn't be usable or be
involved in overload sets. Looking at their declarations and attributes and
whatnot should be fine.

- Jonathan M Davis

Re: Multi-threading how-to

[Cauterite via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 17:37:25 UTC, solidstate1991 
wrote:
I decided to add a functionality that if multiple programs use 
the same instance of the library on the same computer, the 
messages will be passed directly instead of via networking.


What you're describing here is not actually multi-threading, it's 
multi-process…ing. The keyword you're looking for is 
"inter-process communication".


You have a huge range of possible options for implementing this. 
Your decision would depend on your operating system, your 
existing implementation with sockets, and desired performance.


My suggestion: try just using sockets between processes on the 
same PC. You might not even need to add any new code to support 
this method, and it might be faster than you'd expect.

[Issue 16454] New: Return in the body of a foreach in a constructor backed by opApply corrupts the object

[via Digitalmars-d-bugs]

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

  Issue ID: 16454
   Summary: Return in the body of a foreach in a constructor
backed by opApply corrupts the object
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: andrep...@gmail.com

import std.stdio;

struct OpApply {
int opApply(int delegate(int) cb) {
return cb(42);
}
}

struct Bolinha {
int a;
this(ref OpApply moviadao) {
foreach(int b; moviadao) {
this.a = b;
return;
}
}
};

void main() {
import std.stdio;

OpApply range;
writeln(Bolinha(range).a);
}

The expected print result was 42. But I get a random memory garbage instead.
The following minor modification in main will 'fix' the issue:

void main() {
import std.stdio;

OpApply range;
Bolinha littleBall = Bolinha(range);
writeln(littleBall.a);
}

--

Multi-threading how-to

[solidstate1991 via Digitalmars-d-learn]

I decided to write a shared library for OSC in D despite the lack 
of popularity.


I decided to add a functionality that if multiple programs use 
the same instance of the library on the same computer, the 
messages will be passed directly instead of via networking.


Unfortunately we barely touched multi-threading in college. Some 
suggestions?

Re: D to C++

[Laeeth Isharc via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 12:19:33 UTC, Cauterite wrote:

On Wednesday, 31 August 2016 at 11:43:12 UTC, Nick wrote:

That's quite nice, but not what I'm looking for.
What Calypso does, as far as I can see, is to make it possible 
to compile C++ and D together. I'm looking for a compiler that 
takes in D code and spits out either C or C++ code.


Your best option would be to use LDC with a C backend:
https://www.google.com/search?q=llvm++c+backend
No idea how well supported this is, I've never used LLVM myself.


Julia guys resurrected the C back end for LLVM.  Chap here posted 
about using this to compile D to bitcode to C to JS (last but 
using emscripten).  Even without last stage,  doesn't sound a 
great idea if you are under time pressure,  as the whole process 
is quite fragile.


It would be nice to have a robust C backend, even bearing in mind 
all problems with UB and difficulties one can imagine that might 
cause.

Re: D to C++

[bachmeier via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 12:13:38 UTC, Michael wrote:
I can't imagine that's been done, and I'm not sure it will be 
high on anybody's list of priorities I'm afraid. A lot of work 
was done on automating C++ -> D, but converting D, a language 
intended to replace C++, to C++ itself seems a little 
backwards. I get why you'd like to use it, but I don't think 
it's been done, sorry.


Given that you can call D from C++, I don't see the need for such 
a tool.

Re: Debug prints in @nogc

[Yuxuan Shui via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 15:52:18 UTC, Cauterite wrote:

On Wednesday, 31 August 2016 at 15:10:11 UTC, Seb wrote:
AssumeNogc is potentially dangerous, so I don't know whether 
it can make it directly, but only if you try you know ;-)


So is assumeUnique


No. When you use assumeUnique, you know something the compiler 
does know, and have to use assumeUnique to tell the compiler that 
(at least when you use it correctly). But when you use 
assumeNogc, it's always because you want to bypass compiler 
checks.

Re: Debug prints in @nogc

[Cauterite via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 15:10:11 UTC, Seb wrote:
AssumeNogc is potentially dangerous, so I don't know whether it 
can make it directly, but only if you try you know ;-)


So is assumeUnique

Re: Eclipse Paho D Library (finally) started

[Frank Pagliughi via Digitalmars-d-announce]

On Wednesday, 31 August 2016 at 14:24:17 UTC, Chris Wright wrote:

This would be a perfect time to mention what MQTT is.


Ha. Yes.

MQTT (Message Queue Telemetry Transport) is a broker-based 
publish/subscribe messaging system for IoT devices. It's a fairly 
light weight protocol that sits on top of TCP and makes 
provisions for systems that have unreliable connections.


So, basically, it's for small devices out in the real world that 
collect data and want to send that data back home to a cloud 
server.


It originated out of IBM more than a decade ago, and some of 
their code was donated to Eclipse and found a home under the 
"Paho" project. Since then Eclipse has started to gather a large 
number of IoT projects for both device-side data collection and 
for server-side analytics.

http://iot.eclipse.org/projects

An MQTT client could be a device that is gathering and publishing 
data, or it could be a server application that is subscribing to 
that data, aggregating, analyzing, or storing it. I figured that 
D would work pretty well on either side of that.

[Issue 16453] New: Missing @nogc annotations

[via Digitalmars-d-bugs]

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

  Issue ID: 16453
   Summary: Missing @nogc annotations
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

core.thread functions are not marked @nogc

For example: thread_isMainThread

--

Re: Debug prints in @nogc

[Seb via Digitalmars-d-learn]

On Tuesday, 30 August 2016 at 19:03:06 UTC, Nordlöw wrote:

On Tuesday, 30 August 2016 at 17:11:48 UTC, Johannes Pfau wrote:
Nice! Here's a slightly modified version: 
https://dpaste.dzfl.pl/8c5ec90c5b39


This version does not need an additional delegate. It can be 
used like this:


assumeNogc!writefln("foo %s", 42);
assumeNogc!writeln("foo", 42);


Marvellous!


+1


I update my cryptic but short-and-sweet `dln` at

https://github.com/nordlow/phobos-next/blob/master/src/dbg.d#L58

I would love to see this very useful little snippet make its 
way into Phobos somehow. Any suggestions on how?


I am trying to push for a dump method in Phobos, we could try to 
combine it:


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

AssumeNogc is potentially dangerous, so I don't know whether it 
can make it directly, but only if you try you know ;-)

Re: Prevent copy of range in foreach

[pineapple via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 14:03:20 UTC, Yuxuan Shui wrote:
I want to make a hash table that uses std.experiment.allocator. 
The bucket is allocated from an allocator, and freed in 
~this(). I don't want to copy the whole bucket in this(this).


Maybe I should use a reference counter or something?



A reference counter should solve the problem, but there's also 
the option of just making it a class instead of a struct

Re: Eclipse Paho D Library (finally) started

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-08-31 16:14, Frank Pagliughi wrote:

Hey All,

First, my apologies. Over a year ago I had promised to put up a D
library for MQTT, but a number of factors conspired against me in the
intervening time.

But this week, I finally got an initial version loaded. It will be a
part of the Eclipse Paho libraries for MQTT, and an official 1.0 release
should come about this fall.

The first release will be a wrapper around the Paho C library, and thus
should be protocol compliant and fairly feature-complete at the offset.
It also follows the Java and C++ API's pretty closely, so should make it
easy for people to jump around between languages.

The repository is here:

https://github.com/eclipse/paho.mqtt.d

I'm still quite a D novice, so any help, hints, tips, or bug reports
would be appreciated.


I would be nice to have something that is vibe.d compatible.

--
/Jacob Carlborg

Re: Beta D 2.071.2-b3

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-08-31 15:51, Chris Wright wrote:


And `instance_variable_get` in Ruby.


Or "send", "instance_eval" and so on. In Ruby it's more of a comment, 
"please do call this method directly" :)


--
/Jacob Carlborg

Re: Beta release vibe.d 0.7.30-beta.1

[Martin Tschierschke via Digitalmars-d-announce]

On Wednesday, 31 August 2016 at 09:00:47 UTC, Sönke Ludwig wrote:

Am 31.08.2016 um 10:57 schrieb Sönke Ludwig:

[...]

All changes:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

DUB package:
http://code.dlang.org/packages/vibe-d/0.7.30-beta.1

[1]: http://code.dlang.org/packages/vibe-sdlang

[2]: http://code.dlang.org/packages/diet-ng

Nice to read on the ongoing progress!

Can you give a road map of what will be next, may be as an 
interview to the D Blog?

When do you think vibe's version will be 1.0.0?

Regards mt.

Re: So why was typedef bad?

[Ethan Watson via Digitalmars-d]

On Wednesday, 31 August 2016 at 14:05:16 UTC, Chris Wright wrote:

Specifying the default value for the type.


Alias has the same problem in this case.

Making all typedefs from a base type implicitly convert to each 
other without warning unless you're careful, which should be a 
bug.


Which sounds like unique types constructed from other types are 
wanted instead of a typedef.


At the very least, if those were the actual problems, then it 
seems like std.typecons.Typedef has been transformed in to 
something other than a typedef simply for the crime of typedef 
being a subset of alias' functionality. Dropping typedef might 
make sense in favour of alias, but redirecting to something 
entirely different in the official documents... I know I just 
wasted some time evaluating its usefulness at least.


I'm making a distinction here between a typedef and a type mimic 
here because C++ interop is a big factor in our usage, so mixing 
up concepts between a language that's meant to make that easy is 
not ideal. Although looking at std.typecons.Typedef, I'd wonder 
if a typemimic language feature would have been a better way to 
go...

Re: Eclipse Paho D Library (finally) started

[Chris Wright via Digitalmars-d-announce]

On Wed, 31 Aug 2016 14:14:36 +, Frank Pagliughi wrote:
> Over a year ago I had promised to put up a D
> library for MQTT, but a number of factors conspired against me in the
> intervening time.

This would be a perfect time to mention what MQTT is.

Eclipse Paho D Library (finally) started

[Frank Pagliughi via Digitalmars-d-announce]

Hey All,

First, my apologies. Over a year ago I had promised to put up a D 
library for MQTT, but a number of factors conspired against me in 
the intervening time.


But this week, I finally got an initial version loaded. It will 
be a part of the Eclipse Paho libraries for MQTT, and an official 
1.0 release should come about this fall.


The first release will be a wrapper around the Paho C library, 
and thus should be protocol compliant and fairly feature-complete 
at the offset. It also follows the Java and C++ API's pretty 
closely, so should make it easy for people to jump around between 
languages.


The repository is here:

https://github.com/eclipse/paho.mqtt.d

I'm still quite a D novice, so any help, hints, tips, or bug 
reports would be appreciated.


Thanks,
Frank Pagliughi

deepak

[Deepak sharma via Digitalmars-d]

Sharma

Re: colour lib

[Chris Wright via Digitalmars-d]

On Wed, 31 Aug 2016 19:33:24 +1000, Manu via Digitalmars-d wrote:
> On 31 August 2016 at 17:58, Andrea Fontana via Digitalmars-d
>> I always think the perfect colour library should work using a superset
>> of all colour spaces, for example cie xyz (is it a superset, isn't
>> it?). isColour(T) then IMO should check if x,y,z properties exists (or
>> toXYZ() method).
> 
> Yeah... that would be wickedly slow.

That depends on how often you incur the conversion cost. If you're 
storing your whole image in your custom color type and converting to read 
every pixel, that's not so great. If you have an existing image with one 
colorspace and a user wants to add text in a color defined in a different 
colorspace, you only need to convert once, after the user uses the color 
picker.

If you have two images that you want to combine and they're using 
different colorspaces, you must incur that cost anyway, and the image 
library should support that. The color library shouldn't put up barriers.

Re: So why was typedef bad?

[Chris Wright via Digitalmars-d]

On Wed, 31 Aug 2016 13:44:51 +, Ethan Watson wrote:

> http://dlang.org/deprecate.html#typedef
> 
> "typedef is not flexible enough to cover all use cases. This is better
> done with a library solution."
> 
> [Citation needed]
> 
> What use cases is it not flexible enough for?

Specifying the default value for the type. Making all typedefs from a 
base type implicitly convert to each other without warning unless you're 
careful, which should be a bug (the default discriminator should be 
__MODULE__ + __LINE__, and instead it's null).

Re: Prevent copy of range in foreach

[Yuxuan Shui via Digitalmars-d-learn]

On Tuesday, 30 August 2016 at 20:30:12 UTC, Ali Çehreli wrote:

On 08/30/2016 12:06 PM, Yuxuan Shui wrote:
Is there a way to use a range defined with disabled post-blit 
in
foreach? In other words, is there a way to prevent foreach 
from copying

the range?


It's not possible. You can't do much with such a range anyway. 
For example, even r.take(10) requires to copy.


Why do you want to prevent copying? There may be other ways 
around the issue.


I want to make a hash table that uses std.experiment.allocator. 
The bucket is allocated from an allocator, and freed in ~this(). 
I don't want to copy the whole bucket in this(this).


Maybe I should use a reference counter or something?




Should I use move()?


I don't know but I guess you can have a member function to do 
that.


Ali

Re: Beta D 2.071.2-b3

[Chris Wright via Digitalmars-d-announce]

On Wed, 31 Aug 2016 08:22:31 +0200, Jacob Carlborg wrote:

> On 2016-08-31 02:04, Ali Çehreli wrote:
> 
>> P.S. While I'm on my soapbox, I've started to think private is
>> overrated anyway. A system language should allow to bypass that
>> protection. private should be a recommendation only.
> 
> I agree. Let private stop you from access symbols though the regular
> ways, but let reflection bypass.

Just like the JVM and .NET. And Python's double underscore name mangling, 
which is more to highlight that you're doing something funky. And Dart's 
mirrors. And `instance_variable_get` in Ruby.

Re: DIP1000

[ZombineDev via Digitalmars-d]

On Tuesday, 30 August 2016 at 16:12:19 UTC, Andrei Alexandrescu 
wrote:
I'd like to initiate collaboration on an effort to do DIP1000 
rigorously.


First we need to reduce D to a bare subset that only has 
integers, structs, pointers, and functions. That's a working 
subset of actual D code. The grammar I have in mind is at 
http://erdani.com/d/DIP1000.html.


There is no type deduction, member functions, classes, arrays, 
constructors, loops, etc. etc. etc. Only the ability to create 
arbitrarily complex graphs containing integers and pointers to 
other nodes.


On this language we need to define typing rules and evaluation 
semantics. Once we have those, we need to prove what we want: 
for scope variables the accessibility never outlives lifetime. 
As a consequence we're good to deallocate them early etc.


The model for typing, evaluation, and proofs is at 
https://www.cis.upenn.edu/~bcpierce/papers/fj-toplas.pdf. It 
would be great if those interested in helping could give the 
paper a close read.


Once we get this done we'll have a fantastic model for any 
other language changes.



Andrei


BTW, the Rust Mid-level IR (MIR) has a similar purpose: it lowers 
the complex AST to a sufficiently simpler one so that one can 
more easily do things like lifetime analysis / borrow checking on 
it. Similarly, Swift have a similar step in their compiler 
pipeline for ARC.


I don't know if such intermediate representation in the DMD FE is 
worth pursuing (obviously would be big development effort), but 
it may be worth having a look to see how such IR analysis is done 
in practice (on actual non-toy, non-purely academic languages), 
even if only for checking that your theoretical model captures 
sufficient information.


Here are some links, which I hope you would find helpful:

https://blog.rust-lang.org/2016/04/19/MIR.html (high-level 
non-technical introduction)


https://github.com/rust-lang/rfcs/blob/master/text/1211-mir.md 
(Rust RFC ~ equivalent of DIP)


https://news.ycombinator.com/item?id=10487502 (Presentation 
slides about Swift's compiler pipeline)

Re: Template visibility

[David Nadlinger via Digitalmars-d]

On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
But in this case, because instantiation happens within the 
scope of the binderoo.typedescriptor module instead of within 
the scope of the module the template is invoking from, it just 
can't see my new CTypeNameOverride specialisation.


This analysis is correct, and no, there is no direct way of 
emulating argument-dependent lookup (or the existence of a single 
global scope, for that matter) in D. You have to funnel in the 
information via the template parameter somehow, as you did with 
UDAs.


An alternative solution might be to make the your binderoo 
library use an explicit context, where such overrides can be 
registered manually at the point where both it and the vector 
library in question are in use (i.e. the client library/program). 
One option for this would be explicit context arguments, another 
to wrap the API into one giant template which injects that extra 
information (`alias myBinderoo = binderoo!(overrides, ...); 
myBinderoo.doSomething!foo(bar);`).


 — David

So why was typedef bad?

[Ethan Watson via Digitalmars-d]

http://dlang.org/deprecate.html#typedef

"typedef is not flexible enough to cover all use cases. This is 
better done with a library solution."


[Citation needed]

What use cases is it not flexible enough for?

This is tangentially related to my other topic about template 
visibility, specifically the alias I'm trying to do to my 
binderoo.math.vector.VectorFloat.


The problem with alias is that it won't instantiate an entirely 
new symbol. It's effectively a hard link to another symbol. 
Trying to resolve the module name won't actually give me what I 
want here.


Maybe the deprecated typedef will get me what I want? I can't 
make Visual D respect my -d command line properly, so I can't get 
in and quickly check if things are okay there.


Right, so off to the library solution, std.typecons.Typedef. Uh. 
This isn't a typedef. This embeds one type within another and 
tries to mimic that type as much as possible. And it makes that 
member private. You know what this means - if I try to parse over 
it for my serialisation pass for Binderoo, I can't use __traits( 
allMembers ) to get to it. Also, technically, since it's an 
object within an object it will need to double up on the JSON 
hierarchy to store it unless I get in and specialise it.


At the very least, it seems here that Typedef should actually be 
called TypeWrapper, it would actually make sense for its 
functionality there.


Which gets back to the keyword typedef. Sure, it's not as 
flexible as alias. And I don't even know if a typedef in one 
module would result in a symbol resolution to that module or not. 
But what was the actual problems with it?

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Basile B. via Digitalmars-d]

On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote:
Ugh, it really should just give everything and have getMember 
bypass it. That won't even break any code!


you're right. "allMembers" means "all" after all. Another reason 
why the idea of "allVisibleMembers" is good. Puristes will be 
able to use this traits without messing with "getProtection".

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 31 August 2016 at 08:33:28 UTC, Ethan Watson wrote:
That's how it used to work, but getProtection would fail if the 
symbol wasn't public. Which led to me using a workaround to 
something of this effect:


Yeah, I kinda regret the design of getProtection (which is 
basically 100% my fault, I implemented it myself and pushed it 
through without thinking about private - I was only interested in 
public vs export for my personal use case...), but if getMember 
worked on private things too, getProtection would never have to 
return inaccessible and it would be pretty again.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Adam D. Ruppe via Digitalmars-d]

Ugh, it really should just give everything and have getMember 
bypass it. That won't even break any code!

Re: Template visibility

[Ethan Watson via Digitalmars-d]

On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
I do have other instances inside the Binderoo code where I 
resolve the module names for symbols and mixin an import for 
that to make it all just work, but I'm getting tired of having 
to do that every time I come across this problem.


I also realised that won't work in this case, as getting the 
module of the SIMDVector alias will infact get the module 
binderoo.math.vector. std.typecons.Typedef might work out just 
fine in this case to do that with though.

[Issue 16451] std.conv.parse without auto-decoding

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

Summary|std.conv.parse withtout |std.conv.parse without
   |auto-decoding   |auto-decoding

--

[Issue 16451] std.conv.parse withtout auto-decoding

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #1 from Jack Stouffer  ---
Not all overloads of parse have had auto decoding removed

--

Re: Prevent copy of range in foreach

[mogu via Digitalmars-d-learn]

On Tuesday, 30 August 2016 at 19:06:46 UTC, Yuxuan Shui wrote:
Is there a way to use a range defined with disabled post-blit 
in foreach? In other words, is there a way to prevent foreach 
from copying the range?


Should I use move()?

国人？望加群：531010036 谢谢

[Issue 16452] New: charset in std.net.curl should be case-insensitive

[via Digitalmars-d-bugs]

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

  Issue ID: 16452
   Summary: charset in std.net.curl should be case-insensitive
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

--

[Issue 16452] charset in std.net.curl should be case-insensitive

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from greenify  ---
https://github.com/dlang/phobos/pull/4723

--

Template visibility

[Ethan Watson via Digitalmars-d]

https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/typedescriptor.d

Inside that is some code I have to translate D types to the C++ 
strings that we expect.


I'm in the middle of making a mathematical vector class that I 
will be sticking in Binderoo, but maps functionality to our 
internal SIMD vector class. As such, to keep Binderoo a clean 
interface for anyone to use, it will not contain any @CTypeName 
UDAS for Remedy-specific type info.


The problem comes when I try to alias to the expected type for 
our D code and provide a C++ string override, like so:


//
module remedy.rl.simdvector;

public import binderoo.math.vector;
public import binderoo.typedescriptor;

alias SIMDVector = binderoo.math.vector.VectorFloat;

enum CTypeNameOverride( T : SIMDVector ) = "r::SIMDVector";

pragma( msg, CTypeString!( SIMDVector ) );
//

The CTypeString template has no visibility to my 
CTypeNameOverride, and as such that pragma prints out 
"VectorFloat" instead of "r::SIMDVector".


Is there some way to mitigate this without needing to resort to 
mixins everywhere?  This is one of those things in C++ where if I 
specialise a template, any invocation of the template after that 
point will go to the specialised version. But in this case, 
because instantiation happens within the scope of the 
binderoo.typedescriptor module instead of within the scope of the 
module the template is invoking from, it just can't see my new 
CTypeNameOverride specialisation.


I do have other instances inside the Binderoo code where I 
resolve the module names for symbols and mixin an import for that 
to make it all just work, but I'm getting tired of having to do 
that every time I come across this problem.

[Issue 16447] Warn about auto return type when no return statement is present

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

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

--- Comment #2 from b2.t...@gmx.com ---
nvm, i've made it in dscanner.

--

Re: D to C++

[Cauterite via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 11:43:12 UTC, Nick wrote:

That's quite nice, but not what I'm looking for.
What Calypso does, as far as I can see, is to make it possible 
to compile C++ and D together. I'm looking for a compiler that 
takes in D code and spits out either C or C++ code.


Your best option would be to use LDC with a C backend:
https://www.google.com/search?q=llvm++c+backend
No idea how well supported this is, I've never used LLVM myself.

Re: D to C++

[Michael via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 11:43:12 UTC, Nick wrote:

On Tuesday, 30 August 2016 at 14:24:22 UTC, eugene wrote:

On Tuesday, 30 August 2016 at 13:33:44 UTC, Nick wrote:

Is it possible to compile from D to C++?

Explanation:
I do some competition programming and would like to write it 
in D instead of C++ :)


maybe will help https://wiki.dlang.org/Calypso


That's quite nice, but not what I'm looking for.
What Calypso does, as far as I can see, is to make it possible 
to compile C++ and D together. I'm looking for a compiler that 
takes in D code and spits out either C or C++ code.


I can't imagine that's been done, and I'm not sure it will be 
high on anybody's list of priorities I'm afraid. A lot of work 
was done on automating C++ -> D, but converting D, a language 
intended to replace C++, to C++ itself seems a little backwards. 
I get why you'd like to use it, but I don't think it's been done, 
sorry.

Re: DIP1000

[Kagamin via Digitalmars-d]

On Tuesday, 30 August 2016 at 16:12:19 UTC, Andrei Alexandrescu 
wrote:

http://erdani.com/d/DIP1000.html


Return values can't have `scope` annotation? If the container has 
trusted opAssign, use after free in this case is not accounted 
for?

[Issue 16447] Warn about auto return type when no return statement is present

[via Digitalmars-d-bugs]

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

--- Comment #1 from b2.t...@gmx.com ---
(In reply to b2.temp from comment #0)

> The return type here is "void"

forgot the end of the sentence: "instead of int, which the coder has forgot to
specify".

--

Re: Low level unit test library in druntime

[Marc Schütz via Digitalmars-d]

On Tuesday, 30 August 2016 at 15:45:26 UTC, Andrei Alexandrescu 
wrote:

On 08/30/2016 10:44 AM, Atila Neves wrote:
I'd much rather have `assert` be magical or have AST macros to 
make the

syntax for writing tests better than what it is now.


Same here. BTW I'd like unittests that "must not compile" and 
unittests that "must fail dynamically".


For the former case, the compiler should cooperate:

@incompilable unittest { ... }

fails if it passes compilation. So the compiler must know about 
that attribute.




There should be a way to specify the error message (or match it 
against a regex); otherwise the test could fail accidentally for 
totally unrelated reasons, and nobody would notice...

Re: Joakim Intreviews Walter for the D Blog

[qznc via Digitalmars-d-announce]

From the article:


We nailed it [simplicity] with arrays (Jan Knepper’s idea)


D arrays are a great example of simple, but not easy. For details 
see the Slices article section "Determinism". 
https://dlang.org/d-array-article.html

Re: Checking all elements are unique.

[pineapple via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 07:40:39 UTC, Dorian Haglund 
wrote:

Hello,

I have an array of objects of class C which contain a id member.
I want to figure out if all the id members are unique using 
functional primitives.


For example, if I have:

class C
{
  int id;
}

and an array of C 'Cs';

My idea was to do:

auto ids = Cs.map!(c => c.id);
assert(equal(ids.sort().uniq(), ids.sort()));

But it doesn't compile because I can't can call sort on ids.

Any idea why ? and how to solve my initial problem, which is to 
check all ids are unique.


Regards,

Dorian



Your post inspired me to write this addition to my D library, 
I'll commit it later today but you can use it straightaway by 
just adding this file. It will be far more efficient than any of 
the other solutions posted here.


The file - http://pastebin.com/RN2nagEn
The library - https://github.com/pineapplemachine/mach.d

Example usage:

import std.stdio;
import mach.range.unique;
class C{
this(int id){this.id = id;}
int id;
}
auto c0 = [new C(0), new C(1), new C(2), new C(3)];
auto c1 = [new C(0), new C(1), new C(2), new C(3), new C(0)];
c0.unique!(c => c.id).writeln; // true
c1.unique!(c => c.id).writeln; // false

Re: RDTSCP from dlang

[kookman via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 08:23:57 UTC, Basile B. wrote:

By the way maybe someone could post an ER in bugzilla to get 
RDTSCP available in iasm w/o using the byte code trick.


Someone beat me to it, but see here:
https://issues.dlang.org/show_bug.cgi?id=16449

[Issue 16449] add support for RDTSCP in iasm

[via Digitalmars-d-bugs]

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

thekook...@gmail.com changed:

   What|Removed |Added

 CC||thekook...@gmail.com

--- Comment #1 from thekook...@gmail.com ---
On hardware that supports it, is considerably more useful than RDTSC (which is
currently supported).

Ref Forum discussion:
https://forum.dlang.org/post/vdbucktbyidmtdgvt...@forum.dlang.org

--

Re: Why D is not popular enough?

[Chris via Digitalmars-d]

On Tuesday, 30 August 2016 at 18:22:59 UTC, Walter Bright wrote:

On 8/30/2016 3:42 AM, Chris wrote:

[...]


I agree it's time to remove comparisons with C++, although 
there is room for a "D for C++ Programmers" section and, of 
course, "Interfacing D to C++".


I think this will do D good in the long run.

Re: Low level unit test library in druntime

[Atila Neves via Digitalmars-d]

On Tuesday, 30 August 2016 at 15:45:26 UTC, Andrei Alexandrescu 
wrote:

On 08/30/2016 10:44 AM, Atila Neves wrote:
I'd much rather have `assert` be magical or have AST macros to 
make the

syntax for writing tests better than what it is now.


Same here. BTW I'd like unittests that "must not compile" and 
unittests that "must fail dynamically".


For the former case, the compiler should cooperate:

@incompilable unittest { ... }
fails if it passes compilation. So the compiler must know about 
that attribute.


Right now I think you're right and the compiler needs to know. 
But let me see what I can do about it with the language we have 
now.


For the latter case, no change in language is necessary, only 
in druntime:


@mustfail unittest { ... }


As previously mentioned, unit-threaded has this.

Atila

Re: Low level unit test library in druntime

[Atila Neves via Digitalmars-d]

On Tuesday, 30 August 2016 at 16:31:56 UTC, Dicebot wrote:

On 08/30/2016 07:17 PM, Jacob Carlborg wrote:
The reason to put in the druntime is because that's where the 
existing runner is located.


The advantage of this low level library is that:

* Third party unit test library don't need to reinvent the 
wheel


* All third party libraries using this low level library would 
be compatible and can be combined in the same project


* If we would like to, it would be easy to extend the existing 
runner, like not stopping on the first failure. _Not_ saying 
that we should


I definitely wouldn't want to use API like you proposed if I 
was to write my own test runner. Minimal common ground which 
would be cool to have is getting range/array of all unittest 
blocks together with their annotations. Anything more than that 
is optional luxury that specific test systems may define.


And any usage of classes in what is supposed to be a base 
ground API is immediate "no" for me :)


And never mind that any such low level library would suffer from 
the same problem unit-threaded did until dub fixed it: D can't 
reflect on packages so a program must be written that explicitly 
lists all modules that need to be looked at.


The current situation in druntime with the default runner doesn't 
work either because all unit tests end up being a single function 
pointer from the module.


There's a disconnect between what's possible at runtime with 
ModuleInfo and what's possible at compile-time with 
__traits(getUnittests). Fortunately for me, running unit-threaded 
itself as an executable with dub fixed the problem, but in the 
general case this proposal would suffer from the same problems. 
Unless we force everyone to use dub.


Atila

Re: Beta D 2.071.2-b3

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:


Allowing access to private members has a lot of implications, 
e.g. breaks lots of optimizations b/c you can't know who 
accesses sth.


"lots of optimizations"
Can you mention a few?

(I can only think of complicated stuff that requires pretty much 
whole-program analysis to prove validity, and in that case adding 
`private` doesn't help any more)


-Johan

Re: Checking all elements are unique.

[Rene Zwanenburg via Digitalmars-d-learn]

On Wednesday, 31 August 2016 at 08:38:11 UTC, Andrea Fontana 
wrote:

Something like this: https://dpaste.dzfl.pl/9fa55b2a7927 ?

Andrea


Or use findAdjacent:

auto idsAreUnique = ids.array.sort.findAdjacent.empty;

http://dlang.org/phobos/std_algorithm_searching.html#.findAdjacent

Re: colour lib

[Ethan Watson via Digitalmars-d]

On Wednesday, 31 August 2016 at 09:37:41 UTC, Andrea Fontana 
wrote:


So maybe I miss (more than) something reading source code. You 
should write a readme to explain how it works :)


I can probably chip in and help here at some point (both with 
documentation and ensuring the API is intuitive).

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Ethan Watson via Digitalmars-d]

On Wednesday, 31 August 2016 at 09:30:43 UTC, Ethan Watson wrote:
I'm okay with this. My PrivacyLevel workaround does exactly 
this in fact.


I keep forgetting that I'm all open sourced now and can just link 
directly to the full example.


https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/objectprivacy.d

Re: colour lib

[Andrea Fontana via Digitalmars-d]

On Wednesday, 31 August 2016 at 09:33:24 UTC, Manu wrote:
On 31 August 2016 at 17:58, Andrea Fontana via Digitalmars-d 
 wrote:

On Wednesday, 31 August 2016 at 06:17:15 UTC, Manu wrote:


On 31 August 2016 at 16:01, Chris Wright via Digitalmars-d 
 wrote:


The color models I'm aware of are HSV, HSL, RGB[A], CMYK, 
Lab, Pantone, and the Open Colour Standard.



I'll initially support, XYZ/xyY, RGB (which is a gigantic 
set), HSx, Lab,

Yuv.



I'm not sure what common operations they have.



All colours can add, subtract, scale luminance.



Perhaps you could provide a link to your existing library?



https://github.com/TurkeyMan/color



I always think the perfect colour library should work using a 
superset of
all colour spaces, for example cie xyz (is it a superset, 
isn't it?).
isColour(T) then IMO should check if x,y,z properties exists 
(or toXYZ()

method).


Yeah... that would be wickedly slow.


In this way every algorithm like "blend" or anything else 
could be implemented just for xyz (and eventually specialized 
for other colours if we want to avoid conversion overhead).


Basically the whole point of colour spaces is to do blends in 
different colour spaces. XYZ is not a great space for blending, 
xyY is functionally identical for blending as RGB, except that 
you need to do conversions on either side of the blend. RGB 
tend to be integer colour spaces, whereas XYZ/xyY are 
necessarily float colour spaces, which implies a lot of 
int<->float conversion, etc. RGB is not at all perceptually 
uniform, which is why colour spaces like Lab were invented; if 
you use Lab, then your intent is to blend in Lab. Same story 
for HSx spaces, you use them when you want to blend with a 
linear hue axis.




In this way it become easy to do
cross-colour operations (for example: apply a rgb mask over 
another color
space) and to implement new or strange color spaces (that 
automagically will
work with all "blend" & co.). To implement a new color spaces 
you just need
to map it to xyz (that should represent all - and more - 
visible colours:

rgb is a subset of visibile colours)


The meat of your idea is already implemented in my code there. 
The way it works is that you define your own custom colour 
type, and then add a 'sign post' member, ie, `alias 
ParentColour = XYZ!float;`, then you need to implement 
convertColor() for MyCustomColour -> XYZ and vice-versa. With 
that, your custom colour will be convertible to any other 
colour format; using a basic path-finding search (using the 
sign posts) it will find a path from any colour type to any 
other colour type, and perform the series of conversions 
required to get there. XYZ is a valid superset, so you can 
always rely on it as a centerpoint for colour conversions... 
but this is for conversion, not blending, which is the whole 
point of defining your own colour space.


So maybe I miss (more than) something reading source code. You 
should write a readme to explain how it works :)

Re: colour lib

[Manu via Digitalmars-d]

On 31 August 2016 at 18:04, Andrea Fontana via Digitalmars-d
 wrote:
> On Wednesday, 31 August 2016 at 07:58:36 UTC, Andrea Fontana wrote:
>
> I forgot that in this way it's quite easy to wrap external class/struct to
> make them works with library. If we have a custom COLOR class provided by
> another library we just need to write a toXYZ(COLOR c) method (if it doesnt
> provide x,y,z properties) and it works.

It's done.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Ethan Watson via Digitalmars-d]

On Wednesday, 31 August 2016 at 09:25:52 UTC, Basile B. wrote:
nice idea, but this doesn't change the fact that the traits 
that access the results of the "omniscient" allMember must be 
tweaked to access everything.


I'm okay with this. My PrivacyLevel workaround does exactly this 
in fact.


But I would like to be able to read (and write) all members of a 
class without needing to mixin a template and without having to 
resort to .tupleof. Use case here is the extensive struct use we 
have, if we want them to match C++ exactly then that's where 
mixins become potentially hairy.

Re: colour lib

[Manu via Digitalmars-d]

On 31 August 2016 at 17:58, Andrea Fontana via Digitalmars-d
 wrote:
> On Wednesday, 31 August 2016 at 06:17:15 UTC, Manu wrote:
>>
>> On 31 August 2016 at 16:01, Chris Wright via Digitalmars-d
>>  wrote:
>>>
>>> The color models I'm aware of are HSV, HSL, RGB[A], CMYK, Lab, Pantone,
>>> and the Open Colour Standard.
>>
>>
>> I'll initially support, XYZ/xyY, RGB (which is a gigantic set), HSx, Lab,
>> Yuv.
>>
>>
>>> I'm not sure what common operations they have.
>>
>>
>> All colours can add, subtract, scale luminance.
>>
>>
>>> Perhaps you could provide a link to your existing library?
>>
>>
>> https://github.com/TurkeyMan/color
>
>
> I always think the perfect colour library should work using a superset of
> all colour spaces, for example cie xyz (is it a superset, isn't it?).
> isColour(T) then IMO should check if x,y,z properties exists (or toXYZ()
> method).

Yeah... that would be wickedly slow.


> In this way every algorithm like "blend" or anything else could be
> implemented just for xyz (and eventually specialized for other colours if we
> want to avoid conversion overhead).

Basically the whole point of colour spaces is to do blends in
different colour spaces. XYZ is not a great space for blending, xyY is
functionally identical for blending as RGB, except that you need to do
conversions on either side of the blend. RGB tend to be integer colour
spaces, whereas XYZ/xyY are necessarily float colour spaces, which
implies a lot of int<->float conversion, etc. RGB is not at all
perceptually uniform, which is why colour spaces like Lab were
invented; if you use Lab, then your intent is to blend in Lab. Same
story for HSx spaces, you use them when you want to blend with a
linear hue axis.


> In this way it become easy to do
> cross-colour operations (for example: apply a rgb mask over another color
> space) and to implement new or strange color spaces (that automagically will
> work with all "blend" & co.). To implement a new color spaces you just need
> to map it to xyz (that should represent all - and more - visible colours:
> rgb is a subset of visibile colours)

The meat of your idea is already implemented in my code there. The way
it works is that you define your own custom colour type, and then add
a 'sign post' member, ie, `alias ParentColour = XYZ!float;`, then you
need to implement convertColor() for MyCustomColour -> XYZ and
vice-versa. With that, your custom colour will be convertible to any
other colour format; using a basic path-finding search (using the sign
posts) it will find a path from any colour type to any other colour
type, and perform the series of conversions required to get there. XYZ
is a valid superset, so you can always rely on it as a centerpoint for
colour conversions... but this is for conversion, not blending, which
is the whole point of defining your own colour space.

[Issue 8393] class in lambda causes linker trouble

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #5 from greenify  ---
works with with 2.071.1 (-> closing) - please reopen if you still have this
issue.

--

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Basile B. via Digitalmars-d]

On Wednesday, 31 August 2016 at 08:36:37 UTC, Ethan Watson wrote:

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:

I don't agree with the current solution:


I'm somewhat surprised myself that "allMembers doesn't return 
all members" needs highlighting.


Why not have a new trait "allVisibleMembers" and just fix the 
privacy issues?


nice idea, but this doesn't change the fact that the traits that 
access the results of the "omniscient" allMember must be tweaked 
to access everything.

[Issue 16250] GCAllocator should be at least @safe, nothrow

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from greenify  ---
supported with

https://github.com/dlang/phobos/pull/4680
https://github.com/dlang/phobos/pull/4681
https://github.com/dlang/phobos/pull/4682
https://github.com/dlang/phobos/pull/4683

--

Re: Checking all elements are unique.

[Dorian Haglund via Digitalmars-d-learn]

@Edwin: Thank you for the insight about indexed range.

@Adrea: Thanks, this looks good. Even if I found it a little 
obscure at first sight, it's better than my previous solution.

Re: Why D is not popular enough?

[Seb via Digitalmars-d]

On Wednesday, 31 August 2016 at 04:03:32 UTC, Walter Bright wrote:

On 8/30/2016 6:30 PM, ZombineDev wrote:

Your change just went live
http://tour.dlang.org ;)


Thanks! Note that the other languages need updating, too.


Done (FYI the translations aren't officially published yet) ;-)

[Issue 16451] std.conv.parse withtout auto-decoding

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16451] New: std.conv.parse withtout auto-decoding

[via Digitalmars-d-bugs]

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

  Issue ID: 16451
   Summary: std.conv.parse withtout auto-decoding
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

std.conv.parse can be done without auto-decoding.

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

--

[Issue 16450] New: makeArray and makeSlice could infer the ElementType

[via Digitalmars-d-bugs]

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

  Issue ID: 16450
   Summary: makeArray and makeSlice could infer the ElementType
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

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

--

[Issue 16450] makeArray and makeSlice could infer the ElementType

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Beta release vibe.d 0.7.30-beta.1

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

Main changes over 0.7.29:

  - Compiles on the latest DMD version
  - Added a new authorization framework for the web/REST interface
generators
  - Extended the serialization framework with more hooks and traits,
enabling the use of custom UDAs - vibe-sdlang [1] is an SDLang
serialization module that became possible this way
  - opDispatch has been removed from Bson/Json
  - Optional support for using diet-ng [2] has been added (simply add it
as a dependency and it will be used by render())
  - The HTTP client can now be used on Unix socket destinations
  - Added table support for the Markdown compiler

All changes:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

DUB package:
http://code.dlang.org/packages/vibe-d/0.7.30-beta.1

[1]: http://code.dlang.org/packages/vibe-sdlang