Re: Virtual Classes?

[Basile B. via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 03:58:00 UTC, Meta wrote:

On Thursday, 18 August 2016 at 02:55:49 UTC, Basile B. wrote:

On Thursday, 18 August 2016 at 02:51:48 UTC, Meta wrote:
On Thursday, 18 August 2016 at 00:49:49 UTC, Engine Machine 
wrote:

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?


Yes, D's `alias this` feature supports this.

https://dlang.org/spec/class.html#alias-this


No read carefully, alias this does not the same thing, 
particularly when the time comes to override the inner type.


How doesn't it? You define a member with the same name in the 
outer class and it'll override the inner one.


You can't call the most derived from a variable that has a lesser 
derived type:



class Foo
{
Internal internal;

class Internal {void stuff() {"base".writeln;}}

this() {internal = new Internal;}

alias internal this;
}

class Bar: Foo
{
void stuff() {"derived".writeln;}
}

void main(string[] args)
{
Foo f = new Bar;
f.stuff(); // "base", not "derived".
}
°

From what i've read, "virtual classes" respect the OOP principles.

Re: DerelictGL3.reload with specified path question.

[Mike Parker via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 03:54:24 UTC, WhatMeWorry wrote:


When I saw the .dll in OpenGL.dll, I immediately thought: just 
Windows. But does this hold true for the linux shared opengl 
libraries as well? Is this why DerelictGL3.reload() does not 
take a path argument.  But then why 
doesDerelictGL3.load(lib)take an argument?


The load method is what actually loads the shared library. On 
Windows, that's OpenGL32.dll. All of the platform-specific 
library names are configured at the top of gl3.d [1]. In addition 
to loading the library, it also loads the functions up to OpenGL 
1.1, but no higher. This is because the availability of other 
functions are dependent on the version of the active OpenGL 
context.


The reload method *does not* load the shared library, nor does it 
load the 1.1 functions. It loads the functions from OpenGL 
versions 1.2 and higher in addition to all available extensions 
(well, those for which support has been added to DerelictGL3). 
It's named reload because it should be called every time you 
switch contexts to make sure the functions are pointed in the 
right place. This is an artifact of the way OpenGL is handled on 
Windows. In practice, it's really only a problem there when 
switching between contexts that have different properties, but it 
simplifies the binding implementation and provides a uniform 
interface across platforms.


I'm current working on a new version of the library that will 
allow you to specify which OpenGL versions and extensions you 
want to load and will also let you wrap everything in a struct so 
that you can have one instance for each context, but the 
distinction between load and reload will still exist.


[1] 
https://github.com/DerelictOrg/DerelictGL3/blob/master/source/derelict/opengl3/gl3.d#L47

Re: Why 16Mib static array size limit?

[Chris Wright via Digitalmars-d]

On Thu, 18 Aug 2016 01:18:03 +, Yuxuan Shui wrote:

> On Thursday, 18 August 2016 at 00:20:32 UTC, Chris Wright wrote:
>> On Wed, 17 Aug 2016 22:12:25 +, Yuxuan Shui wrote:
>>> But doing so would be incorrect if D doesn't provide strong aliasing
>>> guarantees. And if D does provide these guarantees,
>>> we won't need to do this manually.
>>
>> The language can analyze all code that affects a local variable in many
>> cases. You don't always need the language to guarantee it's impossible
>> if the compiler can see that the user isn't doing anything funky.
> 
> That's right. But for Ali's code, the compiler is clearly not smart
> enough.

Most of the time, the compiler can successfully make those optimizations 
for local variables. The compiler can seldom make them for global 
variables. You get into whole program analysis territory pretty fast.

So it's not surprising that the compiler doesn't handle global variables 
as well as it does local ones.

Re: Virtual Classes?

[Meta via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 02:55:49 UTC, Basile B. wrote:

On Thursday, 18 August 2016 at 02:51:48 UTC, Meta wrote:
On Thursday, 18 August 2016 at 00:49:49 UTC, Engine Machine 
wrote:

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?


Yes, D's `alias this` feature supports this.

https://dlang.org/spec/class.html#alias-this


No read carefully, alias this does not the same thing, 
particularly when the time comes to override the inner type.


How doesn't it? You define a member with the same name in the 
outer class and it'll override the inner one.

Re: DerelictGL3.reload with specified path question.

[WhatMeWorry via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 03:11:17 UTC, WhatMeWorry wrote:
On Wednesday, 17 August 2016 at 23:21:59 UTC, Rene Zwanenburg 
wrote:
On Wednesday, 17 August 2016 at 22:59:31 UTC, WhatMeWorry 
wrote:
I want to store all my shared/dynamic libraries within a 
special directory relative to where the application directory 
is. All of the derelictXX.loads(path) compiles except 
DerelictGL3.reload(lib);  which doesn't seem to be 
implemented.


Don't ever ship OpenGL.dll with your application: it's 
provided by the graphics driver. The only exception to this 
rule that I can think of is if you want to use a software 
implementation for some reason


Understood. Thanks.  I assume everything else is good to go.


When I saw the .dll in OpenGL.dll, I immediately thought: just 
Windows. But does this hold true for the linux shared opengl 
libraries as well? Is this why DerelictGL3.reload() does not take 
a path argument.  But then why doesDerelictGL3.load(lib)take an 
argument?

Re: DerelictGL3.reload with specified path question.

[WhatMeWorry via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 23:21:59 UTC, Rene Zwanenburg 
wrote:

On Wednesday, 17 August 2016 at 22:59:31 UTC, WhatMeWorry wrote:
I want to store all my shared/dynamic libraries within a 
special directory relative to where the application directory 
is. All of the derelictXX.loads(path) compiles except 
DerelictGL3.reload(lib);  which doesn't seem to be implemented.


Don't ever ship OpenGL.dll with your application: it's provided 
by the graphics driver. The only exception to this rule that I 
can think of is if you want to use a software implementation 
for some reason


Understood. Thanks.  I assume everything else is good to go.

Re: Virtual Classes?

[Basile B. via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 02:51:48 UTC, Meta wrote:
On Thursday, 18 August 2016 at 00:49:49 UTC, Engine Machine 
wrote:

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?


Yes, D's `alias this` feature supports this.

https://dlang.org/spec/class.html#alias-this


No read carefully, alias this does not the same thing, 
particularly when the time comes to override the inner type.

Re: Virtual Classes?

[Meta via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 00:49:49 UTC, Engine Machine wrote:

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?


Yes, D's `alias this` feature supports this.

https://dlang.org/spec/class.html#alias-this

Re: Compiler analysis of single-use types? Escape analysis of types?

[Meta via Digitalmars-d]

On Wednesday, 17 August 2016 at 21:25:00 UTC, Ali Çehreli wrote:
I'm wondering whether there is such a thing as single-use of a 
type in compiler technology. I think if the compiler could 
determine that a type is used only once, it could apply 
optimizations.


A colleague of mine raised the issue of D's use of the GC even 
for seemingly local delegates. For example, even though 
everything remains local for the following lambda, countAbove() 
cannot be @nogc:


auto countAbove(int[] a, int limit) {
return a.filter!(x => x >= limit).count();
}

The reason is due to the fact that filter() returns a struct 
object that takes the delegate as an alias template parameter. 
Here is a reduction of the issue with my understanding in 
comments:


void foo(alias dg)() {
dg();
}

struct S(alias dg) {
void bar() {
dg();
}
}

void main() {
int i;

/* The following call can be marked as @nogc because foo() 
does

 * not escape the delegate. (It can indeed appear in @nogc
 * code today.) */
foo!(() => i)();

/* The following expression does not escape the delegate
 * either. (Note that object 's' is not escaped.) So, one 
would
 * expect the following code be @nogc as well. However, 
2.071 does

 * allocate from the GC. */
S!(() => i) s;

/* Although one would expect that last line above to be 
@nogc as
 * well, I can see one potential issue there that warrants 
the GC
 * use: Although no reference to the local 'i' is escaped, 
the

 * *type* of 's' can be obtained perhaps by typeof() to make
 * another object of the same type, which may be escaped. */
typeof(s) s2;

/* s2 carries another alias to local 'i' through its 
*type*! */

}

If the compiler could see that 's' is not escaped *and* it's 
type is used only once, then the expression with the second 
lambda could be @nogc as well. Does that make sense? Is there 
such a thing?


Thank you,
Ali


If I understand correctly, this is exactly what linear types are 
(i.e., what Rust uses... or maybe that was affine types, which 
are similar). D actually does have fairly primitive support for 
affine types with `@disable this()`, opAssign and `this (this)`.

Re: Virtual Classes?

[Basile B. via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 00:49:49 UTC, Engine Machine wrote:

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?


Not naturally. The ancestor must be specified for the inner 
"virtual class":


°°°
class Foo
{
class Internal
{
void stuff() {}
}
}

class Bar: Foo
{
class Internal: Foo.Internal
{
override void stuff() {}
}
}
°°°

However the ancestor inner class is well inherited (in the scope 
of a derived class Internal resolves to the parent definition or 
to the internal override when applicable).


Note that I find the wikipedia example very bad. "Parts" doesn't 
define anything to override.

Re: Autotester farm is down

[Seb via Digitalmars-d]

On Wednesday, 17 August 2016 at 23:47:33 UTC, Walter Bright wrote:

On 8/17/2016 4:13 PM, Brad Roberts via Digitalmars-d wrote:
Several of the machines are run out of aws.  The cost of 
running a windows
instance inside aws is pretty awful.  Shrug.. it's a wash, for 
the most part.


For the ones in house, I wonder if it would be cost effective 
to replace them with ones that draw less power. For example, 
Win7 laptops can be picked up at the pawn shop for about $150. 
Put an SSD drive in them, max out the ram, turn off the 
display, and run them. Of course, they'll be slow, but that may 
not matter if 2 or 3 running in parallel can replace a single 
power hungry machine.


Some points that I can throw into the discussion:

1) There are several small companies (e.g. http://winity.io/) 
that offer moderately cheap Windows VPS machines, but I don't 
know how much power you get in the end
2) I don't think that the connection is an issue as long as one 
has a decent down link (even this could be avoided if we cache 
the git clone locally)

3) I really like the idea of stocking up some laptops :)
4) I heard that in Moldavia one only pays about 7€/month for a 
100M/down connection ;-)
5) At my universities every group has its owns clusters, because 
bureaucracy is so complicated that you can't get access to the 
big ones, and as you would expect, they usually idle around the 
entire day ...
6) AppVeyor (http://appveyor.com) provides one concurrent job 
(with 2 cores) for free for open-source projects and if I read 
their pricing correctly they charge 25$ for each additional 
concurrent job as OSS get a heavy discount. Since they switched 
to their new Hypervisor [1], the builds are even twice as fast 
than Travis (for mir) :)


[1] 
https://www.appveyor.com/blog/2016/07/16/migration-to-rackspace/

Re: Compiler analysis of single-use types? Escape analysis of types?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 18 August 2016 at 00:59:43 UTC, Dicebot wrote:

On 08/18/2016 12:25 AM, Ali Çehreli wrote:

[...]


I believe actual reason is that aliased lambda has to allocate 
a closure because it refers to stack local variable (limit). 
This compiles just fine:


auto countAbove(int[] a, int limit) @nogc {
return a.filter!(x => x >= 1).count();
}


I wish we could have something like "scoped" delegates...

Re: Why 16Mib static array size limit?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 18 August 2016 at 00:20:32 UTC, Chris Wright wrote:

On Wed, 17 Aug 2016 22:12:25 +, Yuxuan Shui wrote:
But doing so would be incorrect if D doesn't provide strong 
aliasing guarantees. And if D does provide these guarantees, 
we won't need to do this manually.


The language can analyze all code that affects a local variable 
in many cases. You don't always need the language to guarantee 
it's impossible if the compiler can see that the user isn't 
doing anything funky.


That's right. But for Ali's code, the compiler is clearly not 
smart enough.

compile error while use `extern(C++, class)`

[mogu via Digitalmars-d-learn]

From spec (Interfacing to C++) 
https://dlang.org/spec/cpp_interface.html:


```
When mapping a D class onto a C++ struct, use extern(C++, struct) 
to avoid linking problems with C++ compilers (notably MSVC) that 
distinguish between C++'s class and struct when mangling. 
Conversely, use extern(C++, class) to map a D struct onto a C++ 
class.

```

But this compiles error. Please help, thanks.

Re: Compiler analysis of single-use types? Escape analysis of types?

[Dicebot via Digitalmars-d]

On 08/18/2016 12:25 AM, Ali Çehreli wrote:
> I'm wondering whether there is such a thing as single-use of a type in
> compiler technology. I think if the compiler could determine that a type
> is used only once, it could apply optimizations.
> 
> A colleague of mine raised the issue of D's use of the GC even for
> seemingly local delegates. For example, even though everything remains
> local for the following lambda, countAbove() cannot be @nogc:
> 
> auto countAbove(int[] a, int limit) {
> return a.filter!(x => x >= limit).count();
> }
> 
> The reason is due to the fact that filter() returns a struct object that
> takes the delegate as an alias template parameter. Here is a reduction
> of the issue with my understanding in comments:

I believe actual reason is that aliased lambda has to allocate a closure
because it refers to stack local variable (limit). This compiles just fine:

auto countAbove(int[] a, int limit) @nogc {
return a.filter!(x => x >= 1).count();
}



signature.asc
Description: OpenPGP digital signature

Virtual Classes?

[Engine Machine via Digitalmars-d-learn]

https://en.wikipedia.org/wiki/Virtual_class

Can D do stuff like this naturally?

Re: Why 16Mib static array size limit?

[Chris Wright via Digitalmars-d]

On Wed, 17 Aug 2016 22:12:25 +, Yuxuan Shui wrote:
> But doing so would be incorrect if D doesn't provide strong aliasing
> guarantees. And if D does provide these guarantees, we won't need to do
> this manually.

The language can analyze all code that affects a local variable in many 
cases. You don't always need the language to guarantee it's impossible if 
the compiler can see that the user isn't doing anything funky.

Re: Why 16Mib static array size limit?

[Chris Wright via Digitalmars-d]

On Wed, 17 Aug 2016 21:37:11 +, ketmar wrote:

> On Wednesday, 17 August 2016 at 13:27:14 UTC, deadalnix wrote:
>> Especially since there are already ways to do this is a way that makes
>> the AA happy
> exactly the thing i was writing about. "hey, you, meatbag! i, Teh Great
> Machine, said that you have to use unions, not pointers! what? making a
> pointer to union point into the middle of the buffer is exactly the same
> aliasing problem, so unions doesn't solve anything? I, Teh Great
> Machine, don't care. it is your problems, meatbag, i'm not here to serve
> you."

It makes your intent more obvious. It's more obvious to other humans as 
well as the compiler. For me, it's a win with no downsides. For you, 
don't use @safe and you opt out of this class of optimizations and the 
related restrictions.

Re: Autotester farm is down

[Brad Roberts via Digitalmars-d]

On 8/17/16 4:47 PM, Walter Bright via Digitalmars-d wrote:

On 8/17/2016 4:13 PM, Brad Roberts via Digitalmars-d wrote:

Several of the machines are run out of aws.  The cost of running a windows
instance inside aws is pretty awful.  Shrug.. it's a wash, for the most part.


For the ones in house, I wonder if it would be cost effective to replace them 
with ones that draw
less power. For example, Win7 laptops can be picked up at the pawn shop for 
about $150. Put an SSD
drive in them, max out the ram, turn off the display, and run them. Of course, 
they'll be slow, but
that may not matter if 2 or 3 running in parallel can replace a single power 
hungry machine.


More slow machines would increase throughput, but would also hurt latency.  Both are important, for 
different reasons.  MOST of the equipment is old hardware, so newer machines would also tend to be 
faster.  I'd be willing to accept donations of any i5 or better hardware (maybe i3, reluctantly). 
Even better would be for me to just get shell access to machines that someone else hosts.  It 
doesn't need to all be centralized in my house.

Re: Autotester farm is down

[Walter Bright via Digitalmars-d]

On 8/17/2016 4:13 PM, Brad Roberts via Digitalmars-d wrote:

Several of the machines are run out of aws.  The cost of running a windows
instance inside aws is pretty awful.  Shrug.. it's a wash, for the most part.


For the ones in house, I wonder if it would be cost effective to replace them 
with ones that draw less power. For example, Win7 laptops can be picked up at 
the pawn shop for about $150. Put an SSD drive in them, max out the ram, turn 
off the display, and run them. Of course, they'll be slow, but that may not 
matter if 2 or 3 running in parallel can replace a single power hungry machine.

Re: Why 16Mib static array size limit?

[Walter Bright via Digitalmars-d]

On 8/17/2016 3:12 PM, Yuxuan Shui wrote:

But doing so would be incorrect if D doesn't provide strong aliasing guarantees.
And if D does provide these guarantees, we won't need to do this manually.


It would be correct for that loop if the user does it.

Re: DerelictGL3.reload with specified path question.

[Rene Zwanenburg via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 22:59:31 UTC, WhatMeWorry wrote:
I want to store all my shared/dynamic libraries within a 
special directory relative to where the application directory 
is. All of the derelictXX.loads(path) compiles except 
DerelictGL3.reload(lib);  which doesn't seem to be implemented.


Don't ever ship OpenGL.dll with your application: it's provided 
by the graphics driver. The only exception to this rule that I 
can think of is if you want to use a software implementation for 
some reason.

Re: Autotester farm is down

[Brad Roberts via Digitalmars-d]

On 8/17/16 3:27 PM, wobbles via Digitalmars-d wrote:

On Monday, 15 August 2016 at 22:33:26 UTC, Brad Roberts wrote:

Network connectivity issues.  That set of machines runs out of my house and the 
comcast connection
isn't happy, apparently.

On 8/15/16 12:55 PM, Lodovico Giaretta via Digitalmars-d wrote:

I don't know much about PRs and the autotester, so I'm probably wrong, but...
It looks like [1] the autotester farm is down: most hosts have been unreachable 
for more than two
hours and a half, as of this writing.

This may slow down the PRs, as all FreeBSD and all Windows hosts are gone.

Is it known and expected (maybe maintainance)?

[1] https://auto-tester.puremagic.com/hosts/


I wonder how much it would cost to host this in AWS?
I imagine it wouldn't be that big a job (famous last words)... plus - I'm sure 
you don't want to be
paying for power and internet bandwidth for it forever either.

Now that we have the foundation - this should all be fundable (hell, I'm sure 
most of us here
wouldn't mind donating if it took that!)


Several of the machines are run out of aws.  The cost of running a windows instance inside aws is 
pretty awful.  Shrug.. it's a wash, for the most part.

Re: Autotester farm is down

[wobbles via Digitalmars-d]

On Monday, 15 August 2016 at 22:33:26 UTC, Brad Roberts wrote:
Network connectivity issues.  That set of machines runs out of 
my house and the comcast connection isn't happy, apparently.


On 8/15/16 12:55 PM, Lodovico Giaretta via Digitalmars-d wrote:
I don't know much about PRs and the autotester, so I'm 
probably wrong, but...
It looks like [1] the autotester farm is down: most hosts have 
been unreachable for more than two

hours and a half, as of this writing.

This may slow down the PRs, as all FreeBSD and all Windows 
hosts are gone.


Is it known and expected (maybe maintainance)?

[1] https://auto-tester.puremagic.com/hosts/


I wonder how much it would cost to host this in AWS?
I imagine it wouldn't be that big a job (famous last words)... 
plus - I'm sure you don't want to be paying for power and 
internet bandwidth for it forever either.


Now that we have the foundation - this should all be fundable 
(hell, I'm sure most of us here wouldn't mind donating if it took 
that!)

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote:
On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" 
< digitalmars-d-announce@puremagic.com> wrote:


Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting compiletime-parsers to run.



Nice tease with the "compile time parsers to run" aside.

We're salivating here. What exactly did you mean by that?

Which compile time parser are you using for testing?

PS: thanks for the updates!


I am using ctfe-bf for a start and others of my own design.
Of course pegged is also on the menu.

Re: Why 16Mib static array size limit?

[Yuxuan Shui via Digitalmars-d]

On Wednesday, 17 August 2016 at 19:36:17 UTC, Walter Bright wrote:

On 8/17/2016 5:20 AM, deadalnix wrote:
Controlling aliasing is really the #1 optimization barrier 
these days, so I

don't think it's that good of a thing.

Almost every single one case where Rust end up being faster 
than C++ is because
their type system allow for more AA information available for 
the optimizer.


AA is also key to do non GC memory management at language 
level.


At least for this case, as I mentioned in another post, if the 
pointer and length of the global is cached in a local, it can 
be cached in a register. The contents of locals don't have 
aliasing problems because if their addresses are not taken, 
nobody can point to them. Optimization relies heavily on that.


But doing so would be incorrect if D doesn't provide strong 
aliasing guarantees. And if D does provide these guarantees, we 
won't need to do this manually.

Re: Why 16Mib static array size limit?

[ketmar via Digitalmars-d]

On Wednesday, 17 August 2016 at 13:27:14 UTC, deadalnix wrote:
Especially since there are already ways to do this is a way 
that makes the AA happy
exactly the thing i was writing about. "hey, you, meatbag! i, Teh 
Great Machine, said that you have to use unions, not pointers! 
what? making a pointer to union point into the middle of the 
buffer is exactly the same aliasing problem, so unions doesn't 
solve anything? I, Teh Great Machine, don't care. it is your 
problems, meatbag, i'm not here to serve you."

Compiler analysis of single-use types? Escape analysis of types?

[Ali Çehreli via Digitalmars-d]

I'm wondering whether there is such a thing as single-use of a type in 
compiler technology. I think if the compiler could determine that a type 
is used only once, it could apply optimizations.


A colleague of mine raised the issue of D's use of the GC even for 
seemingly local delegates. For example, even though everything remains 
local for the following lambda, countAbove() cannot be @nogc:


auto countAbove(int[] a, int limit) {
return a.filter!(x => x >= limit).count();
}

The reason is due to the fact that filter() returns a struct object that 
takes the delegate as an alias template parameter. Here is a reduction 
of the issue with my understanding in comments:


void foo(alias dg)() {
dg();
}

struct S(alias dg) {
void bar() {
dg();
}
}

void main() {
int i;

/* The following call can be marked as @nogc because foo() does
 * not escape the delegate. (It can indeed appear in @nogc
 * code today.) */
foo!(() => i)();

/* The following expression does not escape the delegate
 * either. (Note that object 's' is not escaped.) So, one would
 * expect the following code be @nogc as well. However, 2.071 does
 * allocate from the GC. */
S!(() => i) s;

/* Although one would expect that last line above to be @nogc as
 * well, I can see one potential issue there that warrants the GC
 * use: Although no reference to the local 'i' is escaped, the
 * *type* of 's' can be obtained perhaps by typeof() to make
 * another object of the same type, which may be escaped. */
typeof(s) s2;

/* s2 carries another alias to local 'i' through its *type*! */
}

If the compiler could see that 's' is not escaped *and* it's type is 
used only once, then the expression with the second lambda could be 
@nogc as well. Does that make sense? Is there such a thing?


Thank you,
Ali

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

Re: std.experimental.logger threading design

[Robert burner Schadek via Digitalmars-d]

On Wednesday, 17 August 2016 at 07:48:02 UTC, kookman wrote:
I was interested low(er) cost logging and stumbled across a 
proposal by Max Klimov from about 16 months ago to add an 
AsyncLogger to std.experimental.logger (ref 
http://forum.dlang.org/thread/lcsjtxorbbagmbvbl...@forum.dlang.org). The resulting PR 3194 has been dormant for some time. I was going to resuscitate it, but I wanted to change the approach - rather than make AsyncLogger a generic wrapper for another logger type, I wanted to make a specialist logger that was designed to always be the stdThreadLocalLogger. It would be a stub that merely sends a LogEntry (as a message) to the stdSharedLogger (which would be any logger type).


When taking a closer look at std.experimental.logger I realized 
that with the current design, becauseThreadLocalLog is just 
another Logger, it is paying all the cost of  sychronization, 
even though it is thread local.


Am I interpreting the purpose of stdThreadLocalLogger 
differently to how it was intended?


stdThreadLocalLog's log functions are synchronized because they 
read global and instance global data structures. And I didn't 
want make in possible to introduce the possibilities for race 
conditions. Thats why the logXXX member functions of Logger are 
synchronized.


You can still build up a LogEntry and send it, it just has to be 
in synchronized block.

Re: Why 16Mib static array size limit?

[Walter Bright via Digitalmars-d]

On 8/17/2016 5:20 AM, deadalnix wrote:

Controlling aliasing is really the #1 optimization barrier these days, so I
don't think it's that good of a thing.

Almost every single one case where Rust end up being faster than C++ is because
their type system allow for more AA information available for the optimizer.

AA is also key to do non GC memory management at language level.


At least for this case, as I mentioned in another post, if the pointer and 
length of the global is cached in a local, it can be cached in a register. The 
contents of locals don't have aliasing problems because if their addresses are 
not taken, nobody can point to them. Optimization relies heavily on that.

Re: Sequence separation

[ag0aep6g via Digitalmars-d-learn]

On 08/17/2016 09:21 PM, Lodovico Giaretta wrote:

import std.traits: TemplateOf;
static if (__traits(isSame, TemplateOf!(x.args[2]), MySequence))
{
...
}

std.traits.TemplateOf extracts the symbol representing the
uninstantiated template.

__traits(isSame, symbol1, symbol2) evaluates at compile time to true if
and only if the two symbols represent the same thing (be it a type, an
uninstantiated template, an instantiated one or whatever else).


Look at that! Much better.

TemplateOf is implemented with a template specialization, which can 
handle other things than types, unlike `is(...)`.


Using that directly, without going to std.traits, isMySequence could be 
done like this:



enum isMySequence(alias thing : MySequence!args, args ...) = true;
enum isMySequence(alias thing) = false;


That's just me toying around with the language, of course. The 
isSame+TemplateOf version is perfectly fine.

Re: Sequence separation

[Engine Machine via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 19:15:48 UTC, ag0aep6g wrote:

On 08/17/2016 08:38 PM, Engine Machine wrote:

[...]

[...]

[...]


With MySequence being a type, you can do this:


static if (is(x.args[2] == MySequence!Args, Args ...))
{
  ...
}



It works! Nifty that you can do that with is.

Aside from this check, there is probably not much use for 
MySequence being a type. So I'm be tempted to find a way to do 
the check with a raw template MySequence.


As you said, another enum alone doesn't cut it. The faker can 
just add the same enum.


But a private enum of a private type might do it:


template MySequence(Args ...)
{
/* ... length and args ... */
private enum id = Id();
}

private struct Id {}

enum isMySequence(alias seq) =  is(typeof(seq.id) == Id);


Other modules can't use the Id type directly, because it's 
private. And they can't use typeof(MySequence!foo.id), because 
the id member is private, too.


However, I wouldn't be surprised if this can be circumvented 
too.


Well, the is does work and that probably is the best solution. I 
don't mind the extra type at this point. Of course, a library 
solution for this type of stuff would be nice. I'd rather not 
have to even use a type but rather use arrays:

[a,b,[c,d]].

Re: Sequence separation

[Engine Machine via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 19:21:57 UTC, Lodovico Giaretta 
wrote:

On Wednesday, 17 August 2016 at 19:15:48 UTC, ag0aep6g wrote:



[...]


import std.traits: TemplateOf;
static if (__traits(isSame, TemplateOf!(x.args[2]), MySequence))
{
...
}

std.traits.TemplateOf extracts the symbol representing the 
uninstantiated template.


__traits(isSame, symbol1, symbol2) evaluates at compile time to 
true if and only if the two symbols represent the same thing 
(be it a type, an uninstantiated template, an instantiated one 
or whatever else).


Thanks!

To note, it error's if there is no match ;/

Re: ISO D

[bachmeier via Digitalmars-d]

On Wednesday, 17 August 2016 at 11:34:01 UTC, eugene wrote:

On Wednesday, 17 August 2016 at 10:47:35 UTC, qznc wrote:

On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:

will ISO D be in future or not?


What would be the benefits?


unified language standard?


As a former Common Lisp user, I have to disagree rather strongly 
with that idea. IMO the worst thing for Common Lisp is the ANSI 
standard. You have several issues:


- One group argues that the CLHS is all you need. Then you're 
using a language largely defined in the late 1970's.
- There will never be an updated standard due to cost and 
impossibility of getting compromise on the original standard.
- To do anything useful - or at least modern - with the language, 
you're in the land of non-standard extensions and people telling 
you to use the standard. Any attempt to modernize the language by 
getting rid of awful names like 'princ' are quickly beaten down 
because princ is in the standard.


CL is largely a 40-year old language (not since standardization 
was complete, but since the language itself was defined) and 
there is little hope that it will be modernized. If D had a base 
of millions of developers and tens of thousands of commercial 
users, it would be different. Standardization would be at least 
as much of a disaster for D as it was for CL. Even C++, which 
mostly has users because of legacy code and a lot of money on the 
line, has found it necessary to continually update the language.

Moderately interesting: writing efficient serializers in C# (Wire implementation)

[Chris Wright via Digitalmars-d]

https://rogeralsing.com/2016/08/16/wire-writing-one-of-the-fastest-net-serializers/

It's interesting to compare what C# does and what people do in C# 
to promote speed over obviousness of implementation, with what D 
does by default and what's natural to do in D.


A direct comparison isn't trivial -- C# uses runtime reflection 
and D uses primarily compile-time.


Some specific parts that stood out to me:

* Looking up typeinfo
In D, TypeInfo is just an instance of some class that extends 
TypeInfo. When you write `typeof(foo)`, the compiler transforms 
that into a reference to the appropriate TypeInfo instance. On 
.NET, the primitive operation is to get a type handle for the 
type (done at compile time), and at runtime .NET performs a 
lookup based on that type handle.


* Dictionaries are slower than switch statements. Not surprising.

* Passing preallocated buffers. D has that concept baked in at 
this point; it's almost easier to use Appender!string than to 
append to a string. But this was apparently not natural in C#.


* When you are attempting to serialize millions of objects per 
second, virtual call overhead and uninlined functions matter. 
Wire uses code generation to eliminate both of these problems.


* In .NET, it's apparently not fast to create an uninitialized 
object. You can examine the bytecode for a function (including 
constructors) to determine whether a type has any code, which 
might include side effects, in its constructor.


In D, we can inspect the ClassInfo flags:

```D
if ((Foo.classinfo.m_flags & ClassInfo.ClassFlags.hasCtor) == 0) {
  // static if is here just to ensure that this isn't compiled 
for types that

  // don't have a no-args ctor
  static if (is(typeof(new Foo))) {
obj = new Foo;
goto initialized;
  }
}
obj = hackyManualInitialization!Foo;
initialized:
```

(As an aside, I think I'm warming up to goto as an alternative to 
setting a flag and checking it later.)

Re: Sequence separation

[Engine Machine via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 18:38:48 UTC, Engine Machine 
wrote:
On Wednesday, 17 August 2016 at 08:37:32 UTC, Lodovico Giaretta 
wrote:
On Tuesday, 16 August 2016 at 23:18:28 UTC, Adam D. Ruppe 
wrote:

[...]


You mean something like:

struct MySequence(Args...)
{
enum length = Args.length;
alias args = Args;
}

alias x = MySequence!(a, b, MySequence!(c, d));

static assert(x.length == 3)
static assert(x.args[2].length == 2);


Thanks, basically works.

How can I test, though, if a argument uses a MySequence? I 
can't do if (Args[0] == MySequence) because MySequence is 
templated. While I could test for a length, that doesn't work 
because some types have a length. I could add another enum to 
MySequence, but again, not safe.


I could do some string tests, but that doesn't work.

in your exmaple,

if (x.args[2] == MySequence) ??

I simply need to differentiate between a parameter/arg being a 
MySequence and not.


I guess I'll go with something like

static if ((a.Args[2]).stringof[0..11] == "MySequence!")

Doesn't feel entirely safe but probably will work without issue.

Maybe there is a better way?

Re: Sequence separation

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 19:15:48 UTC, ag0aep6g wrote:

On 08/17/2016 08:38 PM, Engine Machine wrote:
On Wednesday, 17 August 2016 at 08:37:32 UTC, Lodovico 
Giaretta wrote:

[...]

You mean something like:

struct MySequence(Args...)
{
enum length = Args.length;
alias args = Args;
}

alias x = MySequence!(a, b, MySequence!(c, d));

static assert(x.length == 3)
static assert(x.args[2].length == 2);


Thanks, basically works.

How can I test, though, if a argument uses a MySequence? I 
can't do if
(Args[0] == MySequence) because MySequence is templated. While 
I could
test for a length, that doesn't work because some types have a 
length. I

could add another enum to MySequence, but again, not safe.

I could do some string tests, but that doesn't work.

in your exmaple,

if (x.args[2] == MySequence) ??

I simply need to differentiate between a parameter/arg being a
MySequence and not.


With MySequence being a type, you can do this:


static if (is(x.args[2] == MySequence!Args, Args ...))
{
  ...
}


Aside from this check, there is probably not much use for 
MySequence being a type. So I'm be tempted to find a way to do 
the check with a raw template MySequence.


import std.traits: TemplateOf;
static if (__traits(isSame, TemplateOf!(x.args[2]), MySequence))
{
...
}

std.traits.TemplateOf extracts the symbol representing the 
uninstantiated template.


__traits(isSame, symbol1, symbol2) evaluates at compile time to 
true if and only if the two symbols represent the same thing (be 
it a type, an uninstantiated template, an instantiated one or 
whatever else).

Re: Sequence separation

[ag0aep6g via Digitalmars-d-learn]

On 08/17/2016 08:38 PM, Engine Machine wrote:

On Wednesday, 17 August 2016 at 08:37:32 UTC, Lodovico Giaretta wrote:

[...]

You mean something like:

struct MySequence(Args...)
{
enum length = Args.length;
alias args = Args;
}

alias x = MySequence!(a, b, MySequence!(c, d));

static assert(x.length == 3)
static assert(x.args[2].length == 2);


Thanks, basically works.

How can I test, though, if a argument uses a MySequence? I can't do if
(Args[0] == MySequence) because MySequence is templated. While I could
test for a length, that doesn't work because some types have a length. I
could add another enum to MySequence, but again, not safe.

I could do some string tests, but that doesn't work.

in your exmaple,

if (x.args[2] == MySequence) ??

I simply need to differentiate between a parameter/arg being a
MySequence and not.


With MySequence being a type, you can do this:


static if (is(x.args[2] == MySequence!Args, Args ...))
{
  ...
}


Aside from this check, there is probably not much use for MySequence 
being a type. So I'm be tempted to find a way to do the check with a raw 
template MySequence.


As you said, another enum alone doesn't cut it. The faker can just add 
the same enum.


But a private enum of a private type might do it:


template MySequence(Args ...)
{
/* ... length and args ... */
private enum id = Id();
}

private struct Id {}

enum isMySequence(alias seq) =  is(typeof(seq.id) == Id);


Other modules can't use the Id type directly, because it's private. And 
they can't use typeof(MySequence!foo.id), because the id member is 
private, too.


However, I wouldn't be surprised if this can be circumvented too.

Re: Sequence separation

[Engine Machine via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 08:37:32 UTC, Lodovico Giaretta 
wrote:

On Tuesday, 16 August 2016 at 23:18:28 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 August 2016 at 19:17:27 UTC, Engine Machine 
wrote:

alias x = AliasSeq!(a, b, AliasSeq!(c, d));

results in a flat sequence. I would like to be able to keep 
them separate so I can have sub sequences.


wrap them in a struct.


You mean something like:

struct MySequence(Args...)
{
enum length = Args.length;
alias args = Args;
}

alias x = MySequence!(a, b, MySequence!(c, d));

static assert(x.length == 3)
static assert(x.args[2].length == 2);


Thanks, basically works.

How can I test, though, if a argument uses a MySequence? I can't 
do if (Args[0] == MySequence) because MySequence is templated. 
While I could test for a length, that doesn't work because some 
types have a length. I could add another enum to MySequence, but 
again, not safe.


I could do some string tests, but that doesn't work.

in your exmaple,

if (x.args[2] == MySequence) ??

I simply need to differentiate between a parameter/arg being a 
MySequence and not.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Just a small update today.
> if(__ctfe) and if(!__ctfe)
> now get special treatment.
> Also working on getting compiletime-parsers to run.
>

Nice tease with the "compile time parsers to run" aside.

We're salivating here. What exactly did you mean by that?

Which compile time parser are you using for testing?

PS: thanks for the updates!

Re: Why 16Mib static array size limit?

[Johan Engelen via Digitalmars-d]

How about the specific case of array indexing?
Is it UB to have `arr[i]` ever point into `arr` itself, or can we 
make it UB?


-Johan

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting compiletime-parsers to run.

Re: Unum II announcement

[H. S. Teoh via Digitalmars-d]

On Wed, Aug 17, 2016 at 03:44:48AM +, Nick B via Digitalmars-d wrote:
> On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:
[...]
> > Thanks to operator overloading and alias this, we can probably do a
> > pretty good job implementing unums as a library so that people can
> > try it out.
> 
> It may be easier to link to the reference C implementation first.

Easier, certainly. But I think D may offer some advantages over a purely
C implementation. It's worth exploring, at any rate.


> I note that I haven't seen any feedback from Walter or Andrei. I can
> only assume that neither are interested in this subject.
[...]

More likely, they are too busy with other things to respond.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it 
often, use it unsparingly, to subdue your listeners into submission!

Re: Why 16Mib static array size limit?

[Steven Schveighoffer via Digitalmars-d]

On 8/17/16 10:38 AM, deadalnix wrote:

On Wednesday, 17 August 2016 at 14:21:32 UTC, Steven Schveighoffer wrote:

void * is almost useless. In D you can assign a void[] from another
void[], but other than that, there's no way to write the memory or
read it.

In C, void * is also allowed to alias any other pointer. But char * is
also allowed to provide arbitrary byte reading/writing.

I'd expect that D also would provide a similar option.



Yes, but everything can alias with void*/void[] . Thus, you can cast
from void* to T* "safely".


Sure, but how do you implement, let's say, byte swapping on an integer?

ubyte[] x = [0 .. 1];
foreach(i; 0 .. x.length / 2)
   swap(x[i], x[$-i-1]);

So if the compiler can assume that x can't point at myInt, and thus 
myInt can't have changed, then we have a problem.


You just can't do this with void (or at least not very easily).

-Steve

Re: ISO D

[Chris Wright via Digitalmars-d]

On Wed, 17 Aug 2016 14:28:24 +, TencoDK wrote:

> On Wednesday, 17 August 2016 at 14:19:08 UTC, Dejan Lekic wrote:
>> On Wednesday, 17 August 2016 at 12:57:59 UTC, TencoDK wrote:
>>>
>>> I dropped D once about a year ago because the new DMD version has
>>> broken backward compatibility. Some libraries have stopped
>>
>> You could have used STABLE DMD (v1), right? Assuming that you
>> *intentionally* used the unstable (v2) DMD, I would say it is unfair to
>> complain...
> 
> That make sense. Though, I think, this must be a common misunderstanding
> among newcomers.
> D1 seems more like "an old, deprecated alpha version with support
> dropped a long time ago".

Far from alpha. But it's deprecated, and support for it ended in 2012. 
code.dlang.org shows four projects that support D1. You can't find any 
information on D1 at dlang.org -- no downloads, changelog, spec, 
anything. There is no official, simple way to use a library from an old D 
version. Dub defaults to building everything with the system D compiler. 
New features and bugfixes provide an incentive to use the latest compiler 
version.

The effect of it is that, if you have a library, it needs to support the 
most recent D version. If you have the time, you can support parallel 
branches for several versions of D, but that's laborious, so most people 
mix library feature development with language change updates.

This is true even of incremental updates -- if I want to support a 
company that standardized on DMD 2.044 as well as the majority who are on 
DMD 2.070 and higher, that's probably going to mean two branches of 
development. D1 and D2 even more so.

Re: having a trivial anonymous function call in template prevents compilation?

[Cauterite via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 13:33:26 UTC, Steven 
Schveighoffer wrote:

I think the OP's case is a bug. Please file.


Thanks, I've filed it. Just wanted to get a second opinion before 
concluding that it's a bug.

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

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

Cauterite  changed:

   What|Removed |Added

 CC||cauter...@gmail.com

--- Comment #5 from Cauterite  ---
related: https://issues.dlang.org/show_bug.cgi?id=7804

--

Re: Establishing a recommended statndard for documenting dub packages

[Chris Wright via Digitalmars-d]

On Tue, 16 Aug 2016 19:59:16 +, Karabuta wrote:

> Looking through documentations for the various packages available in the
> dub registry, I noticed that some packages have very good documentation
> whilst others are quite not there yet. ...
> 
> Therefore I suggest the community put-up some kind of documentation
> guideline to standardize the learning curve for packages/libraries. The
> IPFS project (ipfs.io) has something like this which makes some things
> easy to pick up and has motivated me to suggest this idea. What is your
> opinion on this?

Something like:

* Purpose / features

Sell me on your project in two sentences. Then talk about what other neat 
or handy things the project does.

* Installation

How to install it, if there are any non-obvious steps. For instance, if I 
have to install any external libraries, like GTK+ or libevent.

This should include an up-to-date dub.json dependencies line.

* Code examples

For the most common use cases, a human-readable description of what the 
use case is, followed by a code example implementing that use case. This 
should include import statements.

* Any important caveats to use

eg: in order to use this, you must compile with a specific version flag. 
Assumes Gregorian calendar transition happened on 15 October 1582, before 
which the Armenian calendar was in use.

* License

[Issue 16400] New: naked variadic C function emits broken prologue

[via Digitalmars-d-bugs]

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

  Issue ID: 16400
   Summary: naked variadic C function emits broken prologue
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cauter...@gmail.com

extern(C) void f(int, ...) {
asm {naked; ret;};
};

void main() {
assert(*(cast(ubyte*) ) == 0xc3); // fails
f(0); // corrupts the stack
};

--

The generated instructions in `f` are:
lea eax, [ebp+0C];
mov [ebp-4], eax;
ret;
which is obviously wrong, since it's supposed to be a naked function, and it
has no business reading the previous stack frame's EBP.

Note that if you give `f` fixed arity `extern(C) void f(int)` there is no
problem.

--

[Issue 16400] naked variadic C function emits broken prologue

[via Digitalmars-d-bugs]

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

Cauterite  changed:

   What|Removed |Added

   Keywords||iasm, wrong-code

--

Re: Why 16Mib static array size limit?

[deadalnix via Digitalmars-d]

On Wednesday, 17 August 2016 at 14:21:32 UTC, Steven 
Schveighoffer wrote:
void * is almost useless. In D you can assign a void[] from 
another void[], but other than that, there's no way to write 
the memory or read it.


In C, void * is also allowed to alias any other pointer. But 
char * is also allowed to provide arbitrary byte 
reading/writing.


I'd expect that D also would provide a similar option.

-Steve


Yes, but everything can alias with void*/void[] . Thus, you can 
cast from void* to T* "safely".

Re: Why 16Mib static array size limit?

[deadalnix via Digitalmars-d]

On Wednesday, 17 August 2016 at 13:41:09 UTC, jmh530 wrote:

On Wednesday, 17 August 2016 at 12:20:28 UTC, deadalnix wrote:


Controlling aliasing is really the #1 optimization barrier 
these days, so I don't think it's that good of a thing.


Almost every single one case where Rust end up being faster 
than C++ is because their type system allow for more AA 
information available for the optimizer.


AA is also key to do non GC memory management at language 
level.


AA? Associative Array?


Alias Analysis. This is a common compiler acronym.

Associative array are called map by everybody outside this forum.

Re: ISO D

[TencoDK via Digitalmars-d]

On Wednesday, 17 August 2016 at 14:19:08 UTC, Dejan Lekic wrote:

On Wednesday, 17 August 2016 at 12:57:59 UTC, TencoDK wrote:


I dropped D once about a year ago because the new DMD version 
has broken backward compatibility. Some libraries have stopped


You could have used STABLE DMD (v1), right? Assuming that you 
*intentionally* used the unstable (v2) DMD, I would say it is 
unfair to complain...


That make sense. Though, I think, this must be a common 
misunderstanding among newcomers.
D1 seems more like "an old, deprecated alpha version with support 
dropped a long time ago".

Re: Why 16Mib static array size limit?

[Steven Schveighoffer via Digitalmars-d]

On 8/16/16 7:23 PM, Charles Hixson via Digitalmars-d wrote:

On 08/16/2016 01:49 PM, Steven Schveighoffer via Digitalmars-d wrote:

On 8/16/16 4:11 PM, Yuxuan Shui wrote:

Wait, doesn't D have strict aliasing rules? ubyte* () should not be
allowed to alias with ubyte** ().


Even if it did, I believe the wildcard is ubyte*. Just like in C,
char* can point at anything, ubyte is D's equivalent.


I think what you say is true (look at the code of std.outbuffer), but
IIRC the documentation says that's supposed to be the job of void*.


void * is almost useless. In D you can assign a void[] from another 
void[], but other than that, there's no way to write the memory or read it.


In C, void * is also allowed to alias any other pointer. But char * is 
also allowed to provide arbitrary byte reading/writing.


I'd expect that D also would provide a similar option.

-Steve

[Issue 16399] New: template with func. ptr. argument and anon. func. in the template body, rejects its argument

[via Digitalmars-d-bugs]

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

  Issue ID: 16399
   Summary: template with func. ptr. argument and anon. func. in
the template body, rejects its argument
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cauter...@gmail.com

( https://dpaste.dzfl.pl/79301f12e5fc )

// -- Example: --

template A(alias Arg) {
enum A = Arg;
enum Unrelated = ({return 0;})(); // Error: expression & asdf is not a
valid template value argument
};

void main() {
enum FnPtr = 
enum _ = A!FnPtr;
};

void asdf() {};

// --

remove the "enum Unrelated =" line and it compiles fine.
this also compiles fine: https://dpaste.dzfl.pl/fca15065a4cf

--

Re: ISO D

[Dejan Lekic via Digitalmars-d]

On Wednesday, 17 August 2016 at 12:57:59 UTC, TencoDK wrote:


I dropped D once about a year ago because the new DMD version 
has broken backward compatibility. Some libraries have stopped


You could have used STABLE DMD (v1), right? Assuming that you 
*intentionally* used the unstable (v2) DMD, I would say it is 
unfair to complain...

Re: Why 16Mib static array size limit?

[jmh530 via Digitalmars-d]

On Wednesday, 17 August 2016 at 12:20:28 UTC, deadalnix wrote:


Controlling aliasing is really the #1 optimization barrier 
these days, so I don't think it's that good of a thing.


Almost every single one case where Rust end up being faster 
than C++ is because their type system allow for more AA 
information available for the optimizer.


AA is also key to do non GC memory management at language level.


AA? Associative Array?

Re: Why 16Mib static array size limit?

[Timon Gehr via Digitalmars-d]

On 17.08.2016 15:41, jmh530 wrote:

On Wednesday, 17 August 2016 at 12:20:28 UTC, deadalnix wrote:


Controlling aliasing is really the #1 optimization barrier these days,
so I don't think it's that good of a thing.

Almost every single one case where Rust end up being faster than C++
is because their type system allow for more AA information available
for the optimizer.

AA is also key to do non GC memory management at language level.


AA? Associative Array?


(Alias Analysis.)

Re: having a trivial anonymous function call in template prevents compilation?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/17/16 9:23 AM, Lodovico Giaretta wrote:

On Wednesday, 17 August 2016 at 13:21:16 UTC, Cauterite wrote:

On Wednesday, 17 August 2016 at 13:18:06 UTC, Adam D. Ruppe wrote:

Best you can do is use them in an alias argument directly, but you
cannot use them in an enum argument.


I think you missed the point; it works perfectly fine without having
this `({return 0;})()` in the template body (which, as far as I can
see, doesn't appear to interact at all with the template argument).


I think he meant that  ({ return 0;})() cannot be executed at compile
time and assigned to an enum. That's why the instantiation is failing.


Yes, it can: https://dpaste.dzfl.pl/fca15065a4cf

I think the OP's case is a bug. Please file.

-Steve

Re: Why 16Mib static array size limit?

[deadalnix via Digitalmars-d]

On Wednesday, 17 August 2016 at 12:32:20 UTC, ketmar wrote:
from my PoV, this kind of "optimizing" is overrated. i'm 
absolutely unable to understand why should i obey orders from 
machine instead of machine obeys my orders. if i want to go 
wild with pointers, don't tell me that i can't, just compile my 
code! C is literally ridden with this shit, and in the end it 
is a freakin' pain to write correct C code (if it is possible 
at all for something comlex).


Because making 99.9% of the code slower because of a fringe use 
case isn't sound engineering. Especially since there are already 
ways to do this is a way that makes the AA happy, for instance 
using unions.

Re: DIP1000: Scoped Pointers

[Chris Wright via Digitalmars-d-announce]

On Wed, 17 Aug 2016 13:53:37 +0300, Dicebot wrote:

> On 08/17/2016 04:01 AM, Chris Wright wrote:
>> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>>> You need to add one more level of indirection for things to start
>>> going complicated.
>> 
>> Presumably scope is transitive, so things shouldn't get horribly
>> complex.
> 
> It is not transitive and it is not a type qualifier.

Non-scope is transitive, rather -- you can't have a non-scope pointer to 
a scope item (at least in @safe code).

Re: having a trivial anonymous function call in template prevents compilation?

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 13:21:16 UTC, Cauterite wrote:
On Wednesday, 17 August 2016 at 13:18:06 UTC, Adam D. Ruppe 
wrote:
Best you can do is use them in an alias argument directly, but 
you cannot use them in an enum argument.


I think you missed the point; it works perfectly fine without 
having this `({return 0;})()` in the template body (which, as 
far as I can see, doesn't appear to interact at all with the 
template argument).


I think he meant that  ({ return 0;})() cannot be executed at 
compile time and assigned to an enum. That's why the 
instantiation is failing.

Re: having a trivial anonymous function call in template prevents compilation?

[Cauterite via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 13:18:06 UTC, Adam D. Ruppe wrote:
Best you can do is use them in an alias argument directly, but 
you cannot use them in an enum argument.


I think you missed the point; it works perfectly fine without 
having this `({return 0;})()` in the template body (which, as far 
as I can see, doesn't appear to interact at all with the template 
argument).

Re: having a trivial anonymous function call in template prevents compilation?

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

On Wednesday, 17 August 2016 at 13:09:40 UTC, Cauterite wrote:
Just by having a random `({return 0;})()` in the template body, 
suddenly the template rejects its arguments. I'm so confused, 
is this a bug? Or am I missing something?


Function pointers and delegates are not valid compile time 
variables.


Best you can do is use them in an alias argument directly, but 
you cannot use them in an enum argument.

having a trivial anonymous function call in template prevents compilation?

[Cauterite via Digitalmars-d-learn]

// -- Example: --

template A(alias Arg) {
enum A = Arg;
	enum Unrelated = ({return 0;})(); // this line prevent 
compilation

};

void main() {
enum FnPtr = 
enum _ = A!FnPtr;
};

void asdf() {};

// ( https://dpaste.dzfl.pl/79301f12e5fc )

Just by having a random `({return 0;})()` in the template body, 
suddenly the template rejects its arguments. I'm so confused, is 
this a bug? Or am I missing something?

Re: ISO D

[TencoDK via Digitalmars-d]

On Wednesday, 17 August 2016 at 10:43:01 UTC, Russel Winder wrote:
On Wed, 2016-08-17 at 08:02 +, eugene via Digitalmars-d 
wrote:

Hello, everyone,
will ISO D be in future or not?


I am not sure this would be a good thing. Given the history of 
Fortran, C, and C++, avoiding ISO standardization processes 
 would seem to be a good thing for any other programming 
language. Even the Java process is fairly dreadful.


Having a sensible version release programme is more important 
that a standard, though having a formal language specification 
in machine readable format is a good idea.



avoiding ISO standardization processes  would seem to be a good 
thing for any other programming language


I disagree. ISO, or not ISO, D should be standardized/stabilized.

I dropped D once about a year ago because the new DMD version has 
broken backward compatibility. Some libraries have stopped 
compiling, and it caused a huge mess in dub package manager.
I was trying to build Dash engine with dub, spent some days with 
this package hell, and ended up with removing dub from my PC.


As for C++98, it didn't change since 1998, and I'm pretty sure I 
can compile anything written in C++98 even today.
I can't say I love C++, but I like its versioning. C++98, C++11, 
C++14 seems to be different languages, and nobody's trying to 
compile C++11 code with C++98 compiler.


Regards,
Alexey

Re: typeof.stringof wrong type

[Eugene Wissner via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 12:39:18 UTC, ag0aep6g wrote:

On 08/17/2016 02:08 PM, Eugene Wissner wrote:
I have a problem, that .stringof doesn't return what I'm 
expecting.

Consider the following:

template A(string T)
{
enum A : bool
{
yes = true,
}
}

void main()
{
A!"asdf" a1;
typeof(a1) a2;
mixin(typeof(a1).stringof ~ " a3;");
}

I get an error: some.d-mixin-13|13 error| Error: template 
some.A(string

T) is used as a type

Why the second line in main() works but the third one not?
typeof(a1).stringof seems to ignore the string template 
parameter T.

pragma(msg, typeof(a1).stringof) would  return just "A".

Is it a bug?


Not exactly a bug. .stringof gives you a simple, readable name. 
It's not meant to be used in code generation. You can use 
std.traits.fullyQualifiedName instead:


import std.traits: fullyQualifiedName;
mixin(fullyQualifiedName!(typeof(a1)) ~ " a3;");


What I find strange is that if A isn't a enum, but a class the 
.stringof returns the full type name, therefore I would expect it 
behave the same in the code above.
I will test later fullyQualifiedName, the example above is very 
simplified version of the code I had problem with. Thanks anyway

Re: Establishing a recommended statndard for documenting dub packages

[Karabuta via Digitalmars-d]

On Tuesday, 16 August 2016 at 21:05:29 UTC, jmh530 wrote:

On Tuesday, 16 August 2016 at 19:59:16 UTC, Karabuta wrote:
Looking through documentations for the various packages 
available in the dub registry, I noticed that some packages 
have very good documentation whilst others are quite not there 
yet. ...


Therefore I suggest the community put-up some kind of 
documentation guideline to standardize the learning curve for 
packages/libraries. The IPFS project (ipfs.io) has something 
like this which makes some things easy to pick up and has 
motivated me to suggest this idea. What is your opinion on 
this?


How about that standard applies to phobos while we're at it?


Why not?

[Issue 16398] New: aligned allocator: aligned reallocation is not defined

[via Digitalmars-d-bugs]

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

  Issue ID: 16398
   Summary: aligned allocator: aligned reallocation is not defined
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

std.experimental.allocator.mallocator. AlignedMallocator does not have
alignedRealocate

--

Re: Binderoo - we're open sourcing our binding system

[Meta via Digitalmars-d]

On Wednesday, 17 August 2016 at 06:51:51 UTC, Ethan Watson wrote:

On Tuesday, 16 August 2016 at 17:53:20 UTC, Meta wrote:

On Tuesday, 16 August 2016 at 12:30:14 UTC, Ethan Watson wrote:
Looking through your slides, I noticed that there's no need to 
pass `typeof(this)` to GenerateStubsFor.


Correct. Notice a few slides after that with the BindAllImports 
mixin that it does exactly what you say. At that point, since 
this is something of an introduction of the language, it's more 
about introducing the concept of typeof fully.


Gotcha. I don't know if you answered this already, but will this 
talk be part of the free content in the GDC Vault or otherwise 
available for watching?

Re: typeof.stringof wrong type

[ag0aep6g via Digitalmars-d-learn]

On 08/17/2016 02:08 PM, Eugene Wissner wrote:

I have a problem, that .stringof doesn't return what I'm expecting.
Consider the following:

template A(string T)
{
enum A : bool
{
yes = true,
}
}

void main()
{
A!"asdf" a1;
typeof(a1) a2;
mixin(typeof(a1).stringof ~ " a3;");
}

I get an error: some.d-mixin-13|13 error| Error: template some.A(string
T) is used as a type

Why the second line in main() works but the third one not?
typeof(a1).stringof seems to ignore the string template parameter T.
pragma(msg, typeof(a1).stringof) would  return just "A".

Is it a bug?


Not exactly a bug. .stringof gives you a simple, readable name. It's not 
meant to be used in code generation. You can use 
std.traits.fullyQualifiedName instead:


import std.traits: fullyQualifiedName;
mixin(fullyQualifiedName!(typeof(a1)) ~ " a3;");

Re: Why 16Mib static array size limit?

[ketmar via Digitalmars-d]

On Wednesday, 17 August 2016 at 12:20:28 UTC, deadalnix wrote:

On Tuesday, 16 August 2016 at 20:19:32 UTC, ketmar wrote:

On Tuesday, 16 August 2016 at 20:11:12 UTC, Yuxuan Shui wrote:

Wait, doesn't D have strict aliasing rules?


luckily, no. at least this is not enforced by dmd. and it is 
great.


Controlling aliasing is really the #1 optimization barrier 
these days, so I don't think it's that good of a thing.


Almost every single one case where Rust end up being faster 
than C++ is because their type system allow for more AA 
information available for the optimizer.


AA is also key to do non GC memory management at language level.


from my PoV, this kind of "optimizing" is overrated. i'm 
absolutely unable to understand why should i obey orders from 
machine instead of machine obeys my orders. if i want to go wild 
with pointers, don't tell me that i can't, just compile my code! 
C is literally ridden with this shit, and in the end it is a 
freakin' pain to write correct C code (if it is possible at all 
for something comlex).

Re: ISO D

[Dicebot via Digitalmars-d]

On 08/17/2016 02:34 PM, eugene wrote:
> On Wednesday, 17 August 2016 at 10:47:35 UTC, qznc wrote:
>> On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:
>>> will ISO D be in future or not?
>>
>> What would be the benefits?
> 
> unified language standard?

Unified among whom? There is only one feature complete D frontend right
now. I'd say that the moment second competing frontend appears would be
exactly the proper time to think about formal standartization.



signature.asc
Description: OpenPGP digital signature

From the D Blog: Inside D Version Manager

[Mike Parker via Digitalmars-d-announce]

Jacob Carlborg put together a guest post describing the history 
and implementation of D Version manager. If you've never heard of 
it, take a look. It's a useful utility to have installed.


Blog:
https://dlang.org/blog/2016/08/17/inside-d-version-manager/

Reddit:
https://www.reddit.com/r/programming/comments/4y58kc/inside_d_version_manager/

Re: Why 16Mib static array size limit?

[deadalnix via Digitalmars-d]

On Tuesday, 16 August 2016 at 20:19:32 UTC, ketmar wrote:

On Tuesday, 16 August 2016 at 20:11:12 UTC, Yuxuan Shui wrote:

Wait, doesn't D have strict aliasing rules?


luckily, no. at least this is not enforced by dmd. and it is 
great.


Controlling aliasing is really the #1 optimization barrier these 
days, so I don't think it's that good of a thing.


Almost every single one case where Rust end up being faster than 
C++ is because their type system allow for more AA information 
available for the optimizer.


AA is also key to do non GC memory management at language level.

typeof.stringof wrong type

[Eugene Wissner via Digitalmars-d-learn]

I have a problem, that .stringof doesn't return what I'm 
expecting. Consider the following:


template A(string T)
{
enum A : bool
{
yes = true,
}
}

void main()
{
A!"asdf" a1;
typeof(a1) a2;
mixin(typeof(a1).stringof ~ " a3;");
}

I get an error: some.d-mixin-13|13 error| Error: template 
some.A(string T) is used as a type


Why the second line in main() works but the third one not? 
typeof(a1).stringof seems to ignore the string template parameter 
T.

pragma(msg, typeof(a1).stringof) would  return just "A".

Is it a bug?

Re: ISO D

[Seb via Digitalmars-d]

On Wednesday, 17 August 2016 at 11:34:01 UTC, eugene wrote:

On Wednesday, 17 August 2016 at 10:47:35 UTC, qznc wrote:

On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:

will ISO D be in future or not?


What would be the benefits?


unified language standard?


While the spec might not be 100% perfect, it tries to be a 
unified language standard. After all D already has four different 
compilers: DMD, LDC, GDC, and SDC.


So imho the best thing to do is to improve the "dirty" bits in 
the spec that have hidden assumptions or aren't clear enough, but 
that's a steady process which is done without an ISO spec. 
Besides who do you prefer to have control over the language: the 
D Foundation or an international company (which you have to keep 
on your payroll)?

Re: Unum II announcement

[Seb via Digitalmars-d]

On Wednesday, 17 August 2016 at 03:44:48 UTC, Nick B wrote:

On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote:
On Sun, Aug 14, 2016 at 09:08:31PM +, Nick B via 
Digitalmars-d wrote:


While I certainly hope this research would eventually 
revolutionize numerical applications, it would take a long 
time before it would catch on, and until then, I think it's 
better to have unums available as a library rather than 
introducing it into the language itself. Having it available 
via dub or something like that would probably be a very good 
idea.


I totally agree.

Thanks to operator overloading and alias this, we can probably 
do a pretty good job implementing unums as a library so that 
people can try it out.


It may be easier to link to the reference C implementation 
first.


I note that I haven't seen any feedback from Walter or Andrei. 
I can only assume that neither are interested in this subject.


Nick


FWIW I skimmed through the paper and it looks very interesting 
and I would definitely experiment with it if it's available in 
D(ub).


If you want Andrei or Walter's opinion on whether they could in 
principle imagine Unum as part of Phobos or even the language, 
you should ping them directly via mail.

Re: ISO D

[eugene via Digitalmars-d]

On Wednesday, 17 August 2016 at 10:47:35 UTC, qznc wrote:

On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:

will ISO D be in future or not?


What would be the benefits?


unified language standard?

Re: ISO D

[Jonathan M Davis via Digitalmars-d]

On Wednesday, August 17, 2016 09:25:38 eugene via Digitalmars-d wrote:
> is it probably 5 years for ISO D to happen or more?

I don't think that any of us know where D will be in 5 years. Having an ISO
standard at some point is certainly a possibility, but it's not even clear
that it's something that we're going to want. Some languages have ISO
standards, some don't, and there are very successful languages in both
categories.

So, having an ISO standard is a possibility but not a goal, and when we will
have one - if ever - is a complete unknown beyond the fact that it's not
happening right now.

- Jonathan M Davis

Re: Log in an @nogc function

[Saurabh Das via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 10:47:54 UTC, Guillaume Piolat 
wrote:

On Wednesday, 17 August 2016 at 10:45:01 UTC, Saurabh Das wrote:
Is there any way I can log to a terminal or a file from inside 
an @nogc function?


Thanks,
Saurabh


import core.stdc.stdio;
printf("am logging C-style\n");


Damn I should have tried that. I feel stupid now :(

Thank you!! :)
SD

Re: DIP1000: Scoped Pointers

[Dicebot via Digitalmars-d-announce]

On 08/17/2016 04:01 AM, Chris Wright wrote:
> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>> You need to add one more level of indirection for things to start going
>> complicated.
> 
> Presumably scope is transitive, so things shouldn't get horribly complex.

It is not transitive and it is not a type qualifier.




signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers

[Dicebot via Digitalmars-d-announce]

On 08/17/2016 10:53 AM, Mike wrote:
> On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
>>
>>>   If DIP1000 is implemented, it will change that behavior, so the
>>> allocation will instead be on the GC heap, but the compiler will do some
>>> flow-control analysis to prevent escaping references.  Is that right?
>>>
>>> Mike
>>>
>>
>> Not correct, the class would still be on the stack so we can have
>> reference semantics during assignment etc, but the instance is on the
>> stack so its faster and the function the code is inside can optionally
>> be nogc.
>>
>> DIP1000 will just make the compiler check that a stack instance does
>> not escape its scope (though it doesn't cover all cases).
>>
>> struct Astruct {} // - on stack by default
>> class Aclass  {} // - on heap by default
>> void main() {
>> Astruct a = new Astruct; // override, now Astruct is on the heap
>> (because of "new")
>> Aclass c = new Aclass; // on the heap as per-usual
>> scope Aclass c1 = new Aclass; // override, now class is on the stack
>> (most obvious use: to make all references use the same instance)
>> }
> 
> Got it!  Thank you!  But it still appears that what's illustrated on the
> deprecations page is not being deprecated.
> 
> Mike

Yes, it will have to be updated - but I didn't want to adjust it before
DIP1000 spec is finalized. Rationale that was driving deprecation of
scope storage class is becoming obsolete with DIP1000 implemented but
not before.



signature.asc
Description: OpenPGP digital signature

Re: ARSD PNG memory usage

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 16 August 2016 at 16:40:30 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 August 2016 at 16:29:18 UTC, Guillaume Piolat 
wrote:
Hey, I also stumbled upon this with imageformats decoding PNG. 
Image loading makes 10x the garbage it should.

Let's see what this threads unveils...


leet me know how it is now


Reverted back to a stb_image translation to avoid the problem 
altogether (though it's a bit slower now). Rewriting offending 
allocations in std.zlib was harder than expected.

Re: ISO D

[qznc via Digitalmars-d]

On Wednesday, 17 August 2016 at 08:02:42 UTC, eugene wrote:

will ISO D be in future or not?


What would be the benefits?

Re: Log in an @nogc function

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 17 August 2016 at 10:45:01 UTC, Saurabh Das wrote:
Is there any way I can log to a terminal or a file from inside 
an @nogc function?


Thanks,
Saurabh


import core.stdc.stdio;
printf("am logging C-style\n");

Log in an @nogc function

[Saurabh Das via Digitalmars-d-learn]

Is there any way I can log to a terminal or a file from inside an 
@nogc function?


Thanks,
Saurabh

Re: ISO D

[Russel Winder via Digitalmars-d]

On Wed, 2016-08-17 at 08:02 +, eugene via Digitalmars-d wrote:
> Hello, everyone,
> will ISO D be in future or not?

I am not sure this would be a good thing. Given the history of Fortran,
C, and C++, avoiding ISO standardization processes  would seem to be a
good thing for any other programming language. Even the Java process is
fairly dreadful.

Having a sensible version release programme is more important that a
standard, though having a formal language specification in machine
readable format is a good idea.

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

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

Re: ISO D

[ciechowoj via Digitalmars-d]

On Wednesday, 17 August 2016 at 09:25:38 UTC, eugene wrote:

is it probably 5 years for ISO D to happen or more?


On the topic: 
https://forum.dlang.org/thread/wzifwqtytvkqmecbf...@forum.dlang.org

Re: Binderoo - we're open sourcing our binding system

[Daniel Kozak via Digitalmars-d]

But this works:

http://www.slideshare.net/EthanWatson5/


Dne 17.8.2016 v 11:32 Arjan via Digitalmars-d napsal(a):

On Tuesday, 16 August 2016 at 14:31:54 UTC, Ethan Watson wrote:
Slides are up at 
http://www.slideshare.net/EthanWatson5/d-using-an-emerging-language-in-quantum-break


I'm getting an error and can't see the slide content. Is it just me?

Re: Binderoo - we're open sourcing our binding system

[Daniel Kozak via Digitalmars-d]

No, same here, but one day ago it worked ok for me.


Dne 17.8.2016 v 11:32 Arjan via Digitalmars-d napsal(a):

On Tuesday, 16 August 2016 at 14:31:54 UTC, Ethan Watson wrote:
Slides are up at 
http://www.slideshare.net/EthanWatson5/d-using-an-emerging-language-in-quantum-break


I'm getting an error and can't see the slide content. Is it just me?

Re: Binderoo - we're open sourcing our binding system

[Arjan via Digitalmars-d]

On Tuesday, 16 August 2016 at 14:31:54 UTC, Ethan Watson wrote:
Slides are up at 
http://www.slideshare.net/EthanWatson5/d-using-an-emerging-language-in-quantum-break


I'm getting an error and can't see the slide content. Is it just 
me?

Re: ISO D

[eugene via Digitalmars-d]

On Wednesday, 17 August 2016 at 08:48:12 UTC, Jonathan M Davis 
wrote:
On Wednesday, August 17, 2016 08:02:42 eugene via Digitalmars-d 
wrote:

Hello, everyone,
will ISO D be in future or not?


The future? Maybe. But it's unlikely to happen soon. As a 
whole, the language is pretty solid, but there are details that 
still need to be ironed out spec-wise, there are a few cases 
where features need to be completed or expanded, and we're 
likely to be adding a feature or two to solve some of the 
current problems (e.g. Walter is working on adding ref-counting 
to the language so that less depends on the GC). So, while D's 
language definition is _far_ more stable than it once was, it's 
still in enough flux that a standard wouldn't make a lot of 
sense yet.


- Jonathan M Davis


is it probably 5 years for ISO D to happen or more?

Re: ISO D

[Jonathan M Davis via Digitalmars-d]

On Wednesday, August 17, 2016 08:02:42 eugene via Digitalmars-d wrote:
> Hello, everyone,
> will ISO D be in future or not?

The future? Maybe. But it's unlikely to happen soon. As a whole, the
language is pretty solid, but there are details that still need to be ironed
out spec-wise, there are a few cases where features need to be completed or
expanded, and we're likely to be adding a feature or two to solve some of
the current problems (e.g. Walter is working on adding ref-counting to the
language so that less depends on the GC). So, while D's language definition
is _far_ more stable than it once was, it's still in enough flux that a
standard wouldn't make a lot of sense yet.

- Jonathan M Davis

Re: Sequence separation

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 16 August 2016 at 23:18:28 UTC, Adam D. Ruppe wrote:
On Tuesday, 16 August 2016 at 19:17:27 UTC, Engine Machine 
wrote:

alias x = AliasSeq!(a, b, AliasSeq!(c, d));

results in a flat sequence. I would like to be able to keep 
them separate so I can have sub sequences.


wrap them in a struct.


You mean something like:

struct MySequence(Args...)
{
enum length = Args.length;
alias args = Args;
}

alias x = MySequence!(a, b, MySequence!(c, d));

static assert(x.length == 3)
static assert(x.args[2].length == 2);

Re: DIP1000: Scoped Pointers

[John Colvin via Digitalmars-d-announce]

On Wednesday, 17 August 2016 at 07:53:49 UTC, Mike wrote:
Got it!  Thank you!  But it still appears that what's 
illustrated on the deprecations page is not being deprecated.


Mike


I imagine that will change if/when DIP1000 is accepted.

ISO D

[eugene via Digitalmars-d]

Hello, everyone,
will ISO D be in future or not?

Re: DIP1000: Scoped Pointers

[Mike via Digitalmars-d-announce]

On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:


  If DIP1000 is implemented, it will change that behavior, so 
the
allocation will instead be on the GC heap, but the compiler 
will do some
flow-control analysis to prevent escaping references.  Is that 
right?


Mike



Not correct, the class would still be on the stack so we can 
have reference semantics during assignment etc, but the 
instance is on the stack so its faster and the function the 
code is inside can optionally be nogc.


DIP1000 will just make the compiler check that a stack instance 
does not escape its scope (though it doesn't cover all cases).


struct Astruct {} // - on stack by default
class Aclass  {} // - on heap by default
void main() {
Astruct a = new Astruct; // override, now Astruct is on the 
heap

(because of "new")
Aclass c = new Aclass; // on the heap as per-usual
scope Aclass c1 = new Aclass; // override, now class is on 
the stack

(most obvious use: to make all references use the same instance)
}


Got it!  Thank you!  But it still appears that what's illustrated 
on the deprecations page is not being deprecated.


Mike

std.experimental.logger threading design

[kookman via Digitalmars-d]

I was interested low(er) cost logging and stumbled across a 
proposal by Max Klimov from about 16 months ago to add an 
AsyncLogger to std.experimental.logger (ref 
http://forum.dlang.org/thread/lcsjtxorbbagmbvbl...@forum.dlang.org). The resulting PR 3194 has been dormant for some time. I was going to resuscitate it, but I wanted to change the approach - rather than make AsyncLogger a generic wrapper for another logger type, I wanted to make a specialist logger that was designed to always be the stdThreadLocalLogger. It would be a stub that merely sends a LogEntry (as a message) to the stdSharedLogger (which would be any logger type).


When taking a closer look at std.experimental.logger I realized 
that with the current design, becauseThreadLocalLog is just 
another Logger, it is paying all the cost of  sychronization, 
even though it is thread local.


Am I interpreting the purpose of stdThreadLocalLogger differently 
to how it was intended?