[Issue 16215] Nested class unable to resolve outer class variables in certain scenarios

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ag0ae...@gmail.com

--

I have a problem with D

[Adam Sansier via Digitalmars-d]

Hi,

I have designed a class based system that involves 
self-delegation instead of override.


It is similar to event based programming.

I have defined an event as a container type that holds 
functions(or possibly delegates, but the desire is to avoid them).




class Base
{
   alias EventMethod = void function(Base _this);
   public Event!EventMethod MyEvents

   public MyEvent()
   {
   // Go ahead and inform subscribed handlers
   MyEvents(this);

   // Do other stuff here
   }
}

The outside world can attach their own method to the event as 
normal. They act as effective members to Base but with only 
access to public members.


Now, the normal workflow in OOP is to derive from Base

class Derived : Base
{

   public override MyEvent()
   {
  // must call super.TriggerMyEvents for design to work, else 
events won't be called. This is dangerous


  // Other work done here.
   }
}


To prevent the dangerous scenario of the deriving user from not 
calling the base class method, the workflow is changed to


class Derived : Base
{
public static myEvent(Derived _this)
{
// Other work done here
}

this()
{
   // Subscribe to Base's MyEvent
   MyEvents += 
}

}

The idea is that the Derived type tries to behave as much as 
possible like a non-derived type when it can. This separates 
certain behaviors from the base class. It helps in other areas of 
the design(because then those behaviors can be reused since they 
do not directly depend on the base type). It also free's up the 
methods to be overridable if necessary without breaking the event 
processing, since now the event processing is mainly done through 
subscriber model. Also, The derived class or anyone else can now 
unhook it's own event handling. If we need to temporarily 
"un-override" some behavior, we cannot do this in the inheritance 
model without mucking with the VTable which is dangerous.


Problems with this setup that are unfortunate but seem to be due 
to language limitations and no fundamental reasons:


If myEvent is static:

1. myEvent cannot use this, but _this is functionally the same. 
We have to prepend every access to the object's members with 
_this. It becomes very ugly code.


2. We also can only access public members because it is not a 
dynamic member. Yet it is clear that myEvent, being defined 
inside the class and having a _this ptr is meant to have full 
access like any normal member.


If myEvent is non-static:

1. Since Event only takes functions, we cannot directly add to 
it. There are some nasty hacks that seem to work but they have 
created other problems in the design.


2. It then invokes the GC even though there is no reason this is 
required. The design supplies the this ptr.



---

One has an either or situation here and neither are desirable.

It seems that D can do better.


1. Allow for module level, static member functions with a special 
_this parameter to act as a in between a function and a delegate. 
this = _this inside the body and has the class/struct type. The 
only difference between this an C++ delegates is that _this is 
explicitly passable.


This avoids the need to prefix _this to every member access.

2. Allow for C++ delegate style method. This is essentially 1 but 
hides the explicit passing of _this. It can be hacked though.


3. Allow access to private members of the enclosing type. For all 
practical purposes, it is part of the class construction and does 
not need to have the members hidden from it. It is both inside 
the module and inside the type and has a this type of parameter. 
It should be a first class citizen then.


4. Allow these new method types to be virtual. This is a bit of 
complexity that might not be desirable at this point though, but 
would allow them to be extended instead of acting like static or 
final methods.


The goal being to allow for derived types to participate in the 
oop hierarchy as general types do but to have special privileges. 
Maybe only protected members could be accessed by _this to allow 
for some level of control(but somewhat meaningless I believe).




These functions should be implicitly convertible to a function 
with first parameter of the class/struct type.


Maybe there is a cleaner way to accomplish this with templates 
though. I believe it essentially requires the assignment to this 
though, which I believe is illegal?




























import std.stdio;


class Event(T, P)
{
T[] callbacks;

void opCall(P p)
{
foreach(e; callbacks)
e(p);
}

void opOpAssign(string op, T)(T c)
{
static if (op == "~")
callbacks ~= c;
}
}


class Base
{
string test = "This is a test, only a test!";
alias EventMethod = void function(Base _this);
//alias EventMethod = void delegate(Base _this);
auto MyEvents = new 

Re: 4x faster strlen with 4 char sentinel

[Bauss via Digitalmars-d-announce]

On Tuesday, 28 June 2016 at 03:58:23 UTC, Jay Norwood wrote:

On Tuesday, 28 June 2016 at 03:11:26 UTC, Jay Norwood wrote:

On Tuesday, 28 June 2016 at 01:53:22 UTC, deadalnix wrote:
If we were in interview, I'd ask you "what does this returns 
if you pass it an empty string ?"


oops.  I see ... need to test for empty string.

nothrow pure size_t strlen2(const(char)* c) {
  if (c is null || *c==0)
 return 0;
  const(char)* c_save = c;
  while (*c){ c+=4; }
  while (*c==0){ c--; }
  c++;
  return c - c_save;
}


Why not just do

nothrow pure size_t strlen2(const(char)* c) {
  if (!c)
return 0;

  ...
}

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Tuesday, 28 June 2016 at 03:11:26 UTC, Jay Norwood wrote:

On Tuesday, 28 June 2016 at 01:53:22 UTC, deadalnix wrote:
If we were in interview, I'd ask you "what does this returns 
if you pass it an empty string ?"


oops.  I see ... need to test for empty string.

nothrow pure size_t strlen2(const(char)* c) {
  if (c is null || *c==0)
 return 0;
  const(char)* c_save = c;
  while (*c){ c+=4; }
  while (*c==0){ c--; }
  c++;
  return c - c_save;
}

Re: Where is the D deep learning library?

[jmh530 via Digitalmars-d]

On Monday, 27 June 2016 at 22:17:55 UTC, Martin Nowak wrote:

On 06/27/2016 08:13 PM, Guillaume Piolat wrote:
Not yet, but it could be useful for new types of audio effects 
and specific tasks like voiced/unvoiced detection.


There are many simpler solutions for that than using machine 
learning. Writing a simple neural network with backpropagation 
is fairly trivial, if you had that in mind to emulate existing 
audio effects, not sure if it works well though.


I could probably write a simple backpropogation one, but I would 
probably screw something up if I wrote my own convolutional 
neural network.


My suggestion is that anyone interested in deep learning might 
want to break it up into some more manageable projects.


For instance, one of the features of TensorFlow is 
auto-differentiation. This means that you can provide it 
arbitrary functions and it will calculate the gradients for you 
exactly instead of relying on numerical estimates. autodiff 
involves building an AST for a function and then walking it to 
generate the gradient. A D autodiff library would probably be 
easier to write than a comparable one in other languages since it 
could take advantage of all the compile time functionality.


Alternately, TensorFlow also works well with heterogeneous 
systems, so any work that improves D's capabilities with 
OpenCL/CUDA or MPI would be something that might make it easier 
to develop a D Deep Learning library.

Re: Get return type statically

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

On Tue, Jun 28, 2016 at 01:41:03AM +, Smoke Adams via Digitalmars-d-learn 
wrote:
> I have a type
> 
> public class SuperFunction(T)
> {
>   T t;
>   return(T) Do() { return t(); }
> }
> 
> where T is a delegate or function. First, I would like to be able to
> specify that this must be the case for SuperFunction so we can't pass
> non-function/delegates for T.

Try:

class SuperFunction(T)
if (is(T == function) || is(T == delegate))
{
...
}


> Second, How to specify the return type of Do to match that of T.

Maybe this?

import std.traits : ReturnType, Parameters;

ReturnType!T Do(Parameters!T args) { return t(args); }


T

-- 
INTEL = Only half of "intelligence".

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Tuesday, 28 June 2016 at 01:53:22 UTC, deadalnix wrote:
If we were in interview, I'd ask you "what does this returns if 
you pass it an empty string ?"


I'd say use this one instead, to avoid negative size_t. It is 
also a little faster for the same measurement.


nothrow pure size_t strlen2(const(char)* c) {
  if (c is null)
 return 0;
  const(char)* c_save = c;
  while (*c){ c+=4; }
  while (*c==0){ c--; }
  c++;
  return c - c_save;
}

2738
540
2744

Re: Registration-free COM client

[thedeemon via Digitalmars-d-learn]

On Monday, 27 June 2016 at 21:17:52 UTC, Thalamus wrote:

Hi everyone,

I've succeeded in using D as a client for regular (registered) 
COM servers in the past, but in this case, I'm building the 
server as well. I would like to avoid registering it if 
possible so XCOPY-like deployment remains an option. Can a 
registration-free COM client be built in D? If so, how can the 
code be setup to consume the manifest file, or alternately, is 
there a way to just point D to the correct assembly directly in 
code?


To load load a COM object from a given file (DLL or AX) without 
having it registered, just load the file with CoLoadLibrary() and 
use its DllGetClassObject() function to get IClassFactory which 
will give you any kind of object in this library.
Here's how I do it (in my case the requested object has 
"IBaseFilter" COM interface):


IBaseFilter createDSFilterFromFile(GUID guid, string dir, string 
fname) {

auto curdir = getcwd();
scope(exit) chdir(curdir);
chdir(dir); // in case the lib depends on other dlls nearby

	auto hinst = CoLoadLibrary( cast(wchar*) buildPath(dir, 
fname).toUTF16z, TRUE);

enforce!COMException(hinst);

	auto fnGetClassObject = cast(LPFNGETCLASSOBJECT) 
GetProcAddress(hinst, "DllGetClassObject");

enforce!COMException(fnGetClassObject);

IClassFactory factory;
auto iid = IID_IClassFactory;
	fnGetClassObject(, , 
cast(void**)).checkHR("fnGetClassObject failed");

enforce!COMException(factory);

IBaseFilter ibf;
	factory.CreateInstance(null, _IBaseFilter, 
cast(void**)).checkHR("factory.CreateInstance");

return ibf;
}

Re: Get return type statically

[Ali Çehreli via Digitalmars-d-learn]

On 06/27/2016 06:41 PM, Smoke Adams wrote:

I have a type

public class SuperFunction(T)
{
   T t;
   return(T) Do() { return t(); }
}

where T is a delegate or function. First, I would like to be able to
specify that this must be the case for SuperFunction so we can't pass
non-function/delegates for T. Second, How to specify the return type of
Do to match that of T.

e.g., SuperFunction!(bool function())

then return(T) should be bool.


The simplest thing is to define the return type as 'auto'.



Similarly, I would like to extra the T's parameters and make Do have
them also.

This way, SuperFunction!T.Do emulates T in every way.




std.traits is your friend. :)

import std.traits;

public class SuperFunction(alias func)
if (isCallable!func) {
auto Do(Parameters!func args) { return func(args); }
}

void main() {
auto sf = new SuperFunction!((int i) => i * 2);
assert(sf.Do(42) == 84);
}

Ali

Re: Where is the D deep learning library?

[bachmeier via Digitalmars-d]

On Monday, 27 June 2016 at 22:41:16 UTC, jmh530 wrote:

On Monday, 27 June 2016 at 22:24:00 UTC, Martin Nowak wrote:


normal to wait a whole day for Matlab.


Why I started learning D...


Me too, but then I found out that I could write correct code much 
faster in D. Quite different from C and C++. And also that it is 
fun writing D.

Re: Get return type statically

[Smoke Adams via Digitalmars-d-learn]

I should point out also that this should be inheritable.

Eventually I would like to create an algebra of SuperFunctions.

e.g., SF3 = SF1 + SF2

is a new super function that combines the parameter list of SF1 
and SF2 and unionizes their return type. Both functions are 
called by Do(which will ultimately be handled by opCall).


Other operations on the parameters can be created(intersection or 
subtraction, multiplication, etc...).


I believe, to do this, I will have to create a string mixin that 
formulates Do(...) properly using a CTFE.

Re: Local fixed sized arrays

[Ali Çehreli via Digitalmars-d-learn]

On 06/27/2016 04:02 PM, Smoke Adams wrote:
> On Monday, 27 June 2016 at 22:56:35 UTC, Ali Çehreli wrote:
>> On 06/27/2016 02:58 PM, Smoke Adams wrote:
>>> I'm in need of a way to create a local array that isn't GC'ed. It must
>>> be dynamic in the sense of setting the size at compile time but it will
>>> be used only in scope and only on structs.
>>>
>>> function x(int y)
>>> {
>>> bool[y] arr;
>>>
>>> arr ~= 3;
>>>
>>> }
>>>
>>> I care about slicing or anything but appending, removal, and 
indexing. I

>>> don't even need bounds checking. I don't see a need to get locked in to
>>> the GC for such simple cases.
>>>
>>>
>>
>> One way is to make x() a function template:
>>
>> import std.stdio;
>>
>> void x(int y)() {
>>bool[y] arr;
>>arr[y/2] = true;
>>writeln(arr);
>> }
>>
>> void main() {
>> x!5();
>> }
>>
>> Ali
>
> But the length depends on runtime behavior.

You said "setting the size at compile time", so I got confused. :)

> Might be 5 or 100. This doesn't handle it, does it?

No, it doesn't handle it. However, if the maximum length is reasonably 
small, then you can create the largest array and use first part of it:


import std.stdio;

enum maxElements = 100;

void foo(int y) {
bool[maxElements] storage;
bool[] x = storage[0..y];
x[y/2] = true;
writeln(x);
}

void main() {
foo(5);
}

However, the ~= operator on x would still involve the GC.

> I already make a simple malloc based array that does what I want. Looks
> like a normal array with ~=, [], foreach.

That's basically the same as std.container.Array, which already comes 
with a bool specialization:


import std.stdio;
import std.container;

void foo(int y) {
auto x = Array!bool();
x.length = y;
x[y/2] = true;
writeln(x[]);
}

void main() {
foo(5);
}

> Does what I need it to do.  Only works with BasicTypes of course.

I would expect yours to work with user-defined types as well.

Ali

Re: 4x faster strlen with 4 char sentinel

[deadalnix via Digitalmars-d-announce]

On Sunday, 26 June 2016 at 16:40:08 UTC, Jay Norwood wrote:
After watching Andre's sentinel thing, I'm playing with strlen 
on char strings with 4 terminating 0s instead of a single one.  
Seems to work and is 4x faster compared to the runtime version.


nothrow pure size_t strlen2(const(char)* c) {
 if (c is null)
   return 0;
 size_t l=0;
 while (*c){ c+=4; l+=4;}
 while (*c==0){ c--; l--;}
 return l+1;
}

This is the timing of my test case, which I can post if anyone 
is interested.

strlen\Release>strlen
2738
681


If we were in interview, I'd ask you "what does this returns if 
you pass it an empty string ?"

Re: Get return type statically

[Smoke Adams via Digitalmars-d-learn]

On Tuesday, 28 June 2016 at 01:41:03 UTC, "Smoke" Adams wrote:

I have a type

public class SuperFunction(T)
{
  T t;
  return(T) Do() { return t(); }
}

where T is a delegate or function. First, I would like to be 
able to specify that this must be the case for SuperFunction so 
we can't pass non-function/delegates for T. Second, How to 
specify the return type of Do to match that of T.


e.g., SuperFunction!(bool function())

then return(T) should be bool.

Similarly, I would like to extra the T's parameters and make Do 
have them also.


This way, SuperFunction!T.Do emulates T in every way.


I should mention that I am looking to make this as type safe as 
possible as if Do was declared exactly like T manually.

Get return type statically

[Smoke Adams via Digitalmars-d-learn]

I have a type

public class SuperFunction(T)
{
  T t;
  return(T) Do() { return t(); }
}

where T is a delegate or function. First, I would like to be able 
to specify that this must be the case for SuperFunction so we 
can't pass non-function/delegates for T. Second, How to specify 
the return type of Do to match that of T.


e.g., SuperFunction!(bool function())

then return(T) should be bool.

Similarly, I would like to extra the T's parameters and make Do 
have them also.


This way, SuperFunction!T.Do emulates T in every way.

[Issue 16215] New: Nested class unable to resolve outer class variables in certain scenarios

[via Digitalmars-d-bugs]

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

  Issue ID: 16215
   Summary: Nested class unable to resolve outer class variables
in certain scenarios
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pun...@coverify.org

This is one of the corner cases that I could reduce.

bool frop(int f) {return true;}
class Bar {
  int zoo;
  class Foo {
bool foo() {
  return (zoo).frop();
}
  }
}

$  dmd -c test.d
test.d(6): Error: need 'this' for 'zoo' of type 'int'

--

Re: AWS SDK

[Brad Roberts via Digitalmars-d]

On 6/27/16 10:53 AM, Brad Roberts via Digitalmars-d wrote:

On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote:

Is there an AWS library in the works for D? It's seriously the main
blocker for me to push adoption of the language internally.

If not, I can try to invest time into making one, but I could use help.

(fyi, there's one in the works for Rust: https://github.com/rusoto/rusoto)


I have some old code here:

https://github.com/braddr/downloads.dlang.org/tree/master/src

It has sig v2 signing and some s3 object related code.  Super minimal and sig 
v2 is out of date
(though still very usable, in most aws regions).

Ideally, someone would partner with aws -- there's a developer tools forum -- 
to add D to the suite
of languages.  I'm fairly sure they code generate at least a large part of the 
tool kits from the
api definitions for each of the tons of services.  Trying to manage them all by 
hand is a loosing
battle.

I've been tempted to do this a couple times, but the time investment would 
likely be more than I'm
willing to spend.


I've started talking with a few of the aws sdk engineers (some of who I worked with when I was 
there) today about their sdk and the tooling involved.  It might not be a horrible job to add 
another language to the mix.  I'm going to meet with them and dig through some of the tooling to get 
a better feel for it.


Later,
Brad

Re: Fiber local GC

[Martin Nowak via Digitalmars-d]

On Monday, 27 June 2016 at 22:55:39 UTC, deadalnix wrote:
Yeah, but you can blast the whole heap in between reuse, and 
that is great :)


Right, and you can already reset a fiber local allocator today, 
just put a reference to it in your Fiber subclass.

Re: 4x faster strlen with 4 char sentinel

[Mike Parker via Digitalmars-d-announce]

On Monday, 27 June 2016 at 19:51:48 UTC, Jay Norwood wrote:

I also found it strange, the non-zero initialization values for 
char, dchar, wchar.  I suppose there's some reason?


int [100]  to zeros.
char [100]  to 0xff;
dchar [100]   to 0x;
wchar [100]   to 0x;


The same reason float and double are default initialized to nan. 
char, wchar and dchar are default initialized to invalid unicode 
values.

Re: Release D 2.071.1

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 27 June 2016 at 22:11:53 UTC, Martin Nowak wrote:

Glad to announce D 2.071.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.071.0, see the 
changelog for more details.


http://dlang.org/changelog/2.071.1.html

-Martin


Glad to see this out :)

Re: Release D 2.071.1

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 27 June 2016 at 23:15:06 UTC, Robert burner Schadek 
wrote:

Awesome, releases are becoming more and more boring. I like it!


I wouldn't call 1.0 * -1.0 == 1.0 boring!

Re: Release D 2.071.1

[Robert burner Schadek via Digitalmars-d-announce]

Awesome, releases are becoming more and more boring. I like it!

Re: static if enhancement

[Stefan Koch via Digitalmars-d]

On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
On Monday, June 27, 2016 18:55:48 deadalnix via Digitalmars-d 
wrote:

On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
> [...]

Alright, I have to range myself with most here. While I'm all 
for not warning about unreachable code, I'm opposed to not 
compiling the rest of the code. This create non orthogonality 
between static if and control flow analysis, the kind that 
clearly do not pay for itselfr


Agreed. The code outside of the static if should be compiled 
regardless, because it's not part of the static if/else at all 
and therefore has not been marked as conditionally compilable. 
But if we don't warn about unreachable code, then the code 
after the static if can clearly be optimized out because it's 
unreachable. So, Andrei's code would become legal as long as 
the only problem with the code after the static if was that it 
was unreachable.


- Jonathan M Davis


It is true that that such unreachable warning can be annoying at 
times.
However it catches bugs. Especially in generic code Those 
warnings can be a blessing rather then a curse.


We should not swallow or gag errors!

Re: Local fixed sized arrays

[Smoke Adams via Digitalmars-d-learn]

On Monday, 27 June 2016 at 22:56:35 UTC, Ali Çehreli wrote:

On 06/27/2016 02:58 PM, Smoke Adams wrote:
I'm in need of a way to create a local array that isn't GC'ed. 
It must
be dynamic in the sense of setting the size at compile time 
but it will

be used only in scope and only on structs.

function x(int y)
{
bool[y] arr;

arr ~= 3;

}

I care about slicing or anything but appending, removal, and 
indexing. I
don't even need bounds checking. I don't see a need to get 
locked in to

the GC for such simple cases.




One way is to make x() a function template:

import std.stdio;

void x(int y)() {
   bool[y] arr;
   arr[y/2] = true;
   writeln(arr);
}

void main() {
x!5();
}

Ali


But the length depends on runtime behavior. Might be 5 or 100. 
This doesn't handle it, does it?


I already make a simple malloc based array that does what I want. 
Looks like a normal array with ~=, [], foreach. Does what I need 
it to do. Only works with BasicTypes of course.

Re: Local fixed sized arrays

[Ali Çehreli via Digitalmars-d-learn]

On 06/27/2016 02:58 PM, Smoke Adams wrote:

I'm in need of a way to create a local array that isn't GC'ed. It must
be dynamic in the sense of setting the size at compile time but it will
be used only in scope and only on structs.

function x(int y)
{
bool[y] arr;

arr ~= 3;

}

I care about slicing or anything but appending, removal, and indexing. I
don't even need bounds checking. I don't see a need to get locked in to
the GC for such simple cases.




One way is to make x() a function template:

import std.stdio;

void x(int y)() {
   bool[y] arr;
   arr[y/2] = true;
   writeln(arr);
}

void main() {
x!5();
}

Ali

Re: Fiber local GC

[deadalnix via Digitalmars-d]

On Monday, 27 June 2016 at 22:51:05 UTC, Martin Nowak wrote:

On 06/25/2016 12:33 PM, Ola Fosheim Grøstad wrote:


It takes the same viewpoint. A go-routine (fiber) that is 
short-lived
(like a HTTP request handler) can release everything in one 
swipe

without collection.


Simple as don't allocate on a per-request basis if you want a 
fast program. It also trivial to attach an std.allocator to 
your custom Fiber. Also Fibers should be pooled and reused to 
avoid the setup cost (just measured 1.5µs on top of the 28ns to 
simply reset a fiber).


-Martin


Yeah, but you can blast the whole heap in between reuse, and that 
is great :)

Re: static if enhancement

[Jonathan M Davis via Digitalmars-d]

On Monday, June 27, 2016 18:55:48 deadalnix via Digitalmars-d wrote:
> On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
> > Me, because that's what it means to evaluate the condition at
> > compile time and only compiling in the appropriate branch. This
> > is additional and special behaviour and it destroys the
> > orthogonality of 'static if' and 'return'. (I don't feel
> > strongly about the change, but the idea that the new behavior
> > should be expected anyway is flawed.)
>
> Alright, I have to range myself with most here. While I'm all for
> not warning about unreachable code, I'm opposed to not compiling
> the rest of the code. This create non orthogonality between
> static if and control flow analysis, the kind that clearly do not
> pay for itselfr

Agreed. The code outside of the static if should be compiled regardless,
because it's not part of the static if/else at all and therefore has not
been marked as conditionally compilable. But if we don't warn about
unreachable code, then the code after the static if can clearly be optimized
out because it's unreachable. So, Andrei's code would become legal as long
as the only problem with the code after the static if was that it was
unreachable.

- Jonathan M Davis

Re: Fiber local GC

[Martin Nowak via Digitalmars-d]

On 06/25/2016 12:33 PM, Ola Fosheim Grøstad wrote:
> 
> It takes the same viewpoint. A go-routine (fiber) that is short-lived
> (like a HTTP request handler) can release everything in one swipe
> without collection.

Simple as don't allocate on a per-request basis if you want a fast
program. It also trivial to attach an std.allocator to your custom Fiber.
Also Fibers should be pooled and reused to avoid the setup cost (just
measured 1.5µs on top of the 28ns to simply reset a fiber).

-Martin

Re: Where is the D deep learning library?

[jmh530 via Digitalmars-d]

On Monday, 27 June 2016 at 22:24:00 UTC, Martin Nowak wrote:


normal to wait a whole day for Matlab.


Why I started learning D...

Re: GSoC 2016 - std.experimental.xml after a month

[Martin Nowak via Digitalmars-d]

On 06/25/2016 10:33 PM, Lodovico Giaretta wrote:
> 
> But my implementation does not maintain the state of the parents, so you
> can't get any info about the parent from the children, unless you use
> exit() (in which case, you can get the parent's name from the closing tag).
> 
> But your idea about a stack keeping all the context informations is
> quite valuable, given that some validations need them (e.g. checking
> that all prefixes have been declared, and retrieving prefix/namespace
> associations).

In any case it should be optional so that use cases that don't need
parent information can avoid the overhead.

Re: Where is the D deep learning library?

[Martin Nowak via Digitalmars-d]

On 06/27/2016 05:31 PM, Guillaume Piolat wrote:
> You don't need to match the manpower and stability of the established
> solution to make something useful. Perhaps there could be something
> distinctive enough to make it attractive?

Much faster turnaround times are a very distinctive feature. Many
science people find it somewhat normal to wait a whole day for Matlab.
I just rewrote a numpy prototype and achieved a 25x speedup. That's game
changing b/c it allowed me to actually iterate on ideas.

Re: Where is the D deep learning library?

[Martin Nowak via Digitalmars-d]

On 06/27/2016 08:13 PM, Guillaume Piolat wrote:
> Not yet, but it could be useful for new types of audio effects and
> specific tasks like voiced/unvoiced detection.

There are many simpler solutions for that than using machine learning.
Writing a simple neural network with backpropagation is fairly trivial,
if you had that in mind to emulate existing audio effects, not sure if
it works well though.

Re: static if enhancement

[ketmar via Digitalmars-d]

On Monday, 27 June 2016 at 11:05:49 UTC, cym13 wrote:
What's unintuitive about it (real question)? It would make it 
behave more like a standard if and early returns are very 
common, well understood and good practice:


void func(int* somepointer) {
if (somepointer == null)
return;
[rest of the code]
}

When seeing such code (which generally leads to cleaner 
functions) the meaning is quite obvious, I fail to see who 
would expect static if to behave otherwise.


here i am!

Release D 2.071.1

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.071.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.071.0, see the changelog
for more details.

http://dlang.org/changelog/2.071.1.html

-Martin

Re: Dynamic array of objects

[Alex Parrill via Digitalmars-d-learn]

On Monday, 27 June 2016 at 22:00:15 UTC, gummybears wrote:

Hi,

Today thought lets learn D. I am writing a compiler for a 
language

and read D compiles very fast.
Switched my compiler from C++ to D and ran my test suite to use 
D.
Doing somethin wrong as creating array of objects gives me a 
segmentation fault


Example

import std.stdio;

class Pair {
  float x;
  float y;
  this() { x = 0; y = 0; }
}


void main() {
  Pair[] arr;

  // segmentation fault on next line
  arr = new Pair[](10);
  arr[0].x = 3;
  arr[0].y = 4;
  writef("arr[0] = (%f,%f)",arr[0].x,arr[0].y);
}


You've allocated an array of 10 objects but didn't put any 
objects into it, so each of the entries is null (since classes 
are reference types in D). The line after the allocation fails as 
you try to access a null object.


Either fill out the array with new objects (`arr[0] = new 
Pair()`), or convert Pair to a struct (structs are value types).

Dynamic array of objects

[gummybears via Digitalmars-d-learn]

Hi,

Today thought lets learn D. I am writing a compiler for a language
and read D compiles very fast.
Switched my compiler from C++ to D and ran my test suite to use D.
Doing somethin wrong as creating array of objects gives me a 
segmentation fault


Example

import std.stdio;

class Pair {
  float x;
  float y;
  this() { x = 0; y = 0; }
}


void main() {
  Pair[] arr;

  // segmentation fault on next line
  arr = new Pair[](10);
  arr[0].x = 3;
  arr[0].y = 4;
  writef("arr[0] = (%f,%f)",arr[0].x,arr[0].y);
}

Local fixed sized arrays

[Smoke Adams via Digitalmars-d-learn]

I'm in need of a way to create a local array that isn't GC'ed. It 
must be dynamic in the sense of setting the size at compile time 
but it will be used only in scope and only on structs.


function x(int y)
{
   bool[y] arr;

   arr ~= 3;

}

I care about slicing or anything but appending, removal, and 
indexing. I don't even need bounds checking. I don't see a need 
to get locked in to the GC for such simple cases.

Forward References

[Jonathan Marler via Digitalmars-d-learn]

Do the various D compilers use multiple passes to handle forward 
references or some other technique?

Re: 4x faster strlen with 4 char sentinel

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 27 June 2016 at 21:41:57 UTC, Jay Norwood wrote:
measurements. I'm using a 100KB char array terminated by four 
zeros, and doing strlen on substring pointers into it 
incremented by 1 for 100K times.


But this is a rather atypical use case for zero terminated 
strings? It would make more sense to test it on a massive amount 
of short strings stuffed into a very large hash-table. 
(filenames, keys, user names, email adresses etc)

Re: dmd (>2.068) compiler error

[ag0aep6g via Digitalmars-d]

On 06/26/2016 09:01 AM, ted wrote:

Compilation of https://github.com/dcarp/asynchronous.

[...]

/usr/bin/dmd -ofbuild/events.d.o -debug -g -w -version=CryptoSafe 
-version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc  
  -
I../../../../.dub/packages/memutils-0.4.6/memutils/source/ 
-I../../../../.dub/packages/libasync-0.7.9/libasync/source/ -c 
src/asynchronous/libasync/events.d



for any dmd >2.068 causes the following error:
dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool): Assertion 
`fd->semanticRun == PASSsemantic3done' failed.
Aborted

However, it works find for dmd.2.068.

Any ideas?


I've filed an issue with reduced code:
https://issues.dlang.org/show_bug.cgi?id=16214

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Monday, 27 June 2016 at 20:43:40 UTC, Ola Fosheim Grøstad 
wrote:
Just keep in mind that the major bottleneck now is loading 64 
bytes from memory into cache. So if you test performance you 
have to make sure to invalidate the caches before you test and 
test with spurious reads over a very large memory area to get 
realistic results.


But essentially, the operation is not heavy, so to speed it up 
you need to predict and prefetch from memory in time, meaning 
no library solution is sufficient. (you need to prefetch memory 
way before your library function is called)


I doubt the external memory accesses are involved in these 
measurements. I'm using a 100KB char array terminated by four 
zeros, and doing strlen on substring pointers into it incremented 
by 1 for 100K times.  The middle of the three timings is for 
strlen2, while the two outer timings are for strlen during the 
same program execution.


I'm initializing the 100KB immediately prior to the measurement. 
The 100KB array should all be in L1 or L2 cache by the time I 
make even the first of the three time measurements.


The prefetch shouldn't have a problem predicting this.

2749
688
2783

2741
683
2738

[Issue 16214] New: [REG2.069] ICE: Assertion `fd->semanticRun == PASSsemantic3done' failed.

[via Digitalmars-d-bugs]

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

  Issue ID: 16214
   Summary: [REG2.069] ICE: Assertion `fd->semanticRun ==
PASSsemantic3done' failed.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Found by ted who posted to D.General:
http://forum.dlang.org/post/nknukb$1oe6$1...@digitalmars.com

Reduced code (two files):


module a;
import b;

class LibasyncEventLoop : EventLoop {}


module b;
import a;

struct Appender() { int[] arr; }
struct Tuple() { alias A = Appender!(); }

class EventLoop
{
auto f() { auto x = [Tuple!().init]; }
}


`dmd -c a.d` fails with:


dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool):
Assertion `fd->semanticRun == PASSsemantic3done' failed.
Aborted (core dumped)


Compiles with 2.068. ICE occurs since 2.069.

--

Registration-free COM client

[Thalamus via Digitalmars-d-learn]

Hi everyone,

I've succeeded in using D as a client for regular (registered) 
COM servers in the past, but in this case, I'm building the 
server as well. I would like to avoid registering it if possible 
so XCOPY-like deployment remains an option. Can a 
registration-free COM client be built in D? If so, how can the 
code be setup to consume the manifest file, or alternately, is 
there a way to just point D to the correct assembly directly in 
code?


Some background info:

The project I'm working on requires a high degree of D and C# 
interop. Getting C# to invoke D via C linkage is simple, but I've 
encountered a lot of problems the other way around.


Although it's technically possible to get pointers to C# objects 
such that the same approach could be used, doing so would require 
large portions of the code to be marked unsafe, the objects to be 
instantiated as fixed, use of GCHandle.Alloc, etc., which has a 
high dev learning curve and scalability issues.


The typical solution is to use delegates as callbacks. This 
works, but it doesn't scale well to more complex scenarios. You 
can send a struct of delegates to the D layer and use that to 
access public methods in a class, but if one of those methods 
would normally return a instance of a different class and the 
caller will need to invoke methods within that other class, this 
approach breaks down. For example, 
MyClassInstance.MyProperty.DoSomething() can't be modeled as 
MyClassInstanceDelegate.MyPropertyDelegate.DoSomethingDelegate(). 
This fails marshaling, because delegates are not blittable. 
There's very likely a way to structure complex delegate 
hierarchies that would in the end be marshalable, but the 
implementation and maintenance overhead would be sizable.


This leaves COM, which seems like it would work fine, on Windows 
anyway. (I'm not sure about Linux, but maybe some combo of Mono 
and WINE would do it? Not a high prio right now.) I'm hoping, 
though, to avoid having to register the C# COM server to keep 
things as simple as possible.


thanks!

Re: 4x faster strlen with 4 char sentinel

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 27 June 2016 at 06:31:49 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote:
Ending strings with a single null byte/char is to save space. 
It was critical in the 70´s when C was created and memory 
space was very limited. That's not the case anymore and I 
guess the


Not only to save space, some CPUs also had cheap incrementing 
load/stores and branching on zero is faster than sacrificing 
another register for a counter.


I incidentally just found my 1992 implementation for Motorola 
68K, to illustrate:


_mystrcpy   
move.l  4(sp),a1; pointer for destination
move.l  8(sp),a0; pointer for source

mystrcpymove.l  a0,d0
1$  move.b  (a0)+,(a1)+ ; copy
bne.s   1$ ; jump back up if not zero
rts

As you can see it is a tight loop. Other CPUs are even tighter, 
and have single-instruction loops (even 8086?)


So not only storage, also performance on specific CPUs. Which is 
a good reason for keeping datatypes in standard libraries 
abstract, different CPUs favour different representations. Even 
on very basic datatypes.

Re: Another audio plugin in D

[Jacob Carlborg via Digitalmars-d-announce]

On 27/06/16 21:22, Guillaume Piolat wrote:


My wording was a bit strong.

As you may remember, the workaround involved "leaking" the dynlib.

On OS X I keep having a lingering crash which is a bit random, happens
with multiple instantiation/closing of a dynlib. It is a bit hard to
reproduce and I failed to remove it. It follows an hysteresis pattern,
when it's here it reproduces reliably, then disappear. With LDC-b2 I
thought it was gone (was codegen I thought), but seems still here somehow.

I'm not sure at all if it's related at all to dynlib unloading (wild
guess probability: 50%).


Ok, I see. We need to add proper support of dynamic libraries on OS X.

--
/Jacob Carlborg

[Issue 16213] New: CTFE internal error with static array $ as template argument

[via Digitalmars-d-bugs]

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

  Issue ID: 16213
   Summary: CTFE internal error with static array $ as template
argument
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kirsy...@gmail.com

Linux 64-bit DMD 2.072.0-devel-8ed6966-dirty DEBUG

enum Id(size_t i) = i;
void main() {
int[5] y;
y[ Id!($) - 1 ] = 3;
}
un_init_dollar.d(4): Error: CTFE internal error: trying to access uninitialized
var
core.exception.AssertError@dinterpret.d(2353): Assertion failure

??:? _d_assert [0x707f67]
??:? void ddmd.dinterpret.__assert(int) [0x5322ff]
dinterpret.d:2353
_ZN11Interpreter9getVarExpE3LocP10InterStateP11Declaration8CtfeGoal [0x523ba2]
dinterpret.d:2455 _ZN11Interpreter5visitEP6VarExp [0x5240b9]
expression.d:6669 _ZN6VarExp6acceptEP7Visitor [0x56fac9]
dinterpret.d:6304 _Z9interpretP10ExpressionP10InterState8CtfeGoal [0x52fab3]
dinterpret.d:723 _Z13ctfeInterpretP10Expression [0x51ffc3]
expression.d:3459 _ZN10Expression13ctfeInterpretEv [0x566e84]
dtemplate.d:5399
_ZN22TemplateValueParameter8matchArgEP5ScopeP10RootObjectmP5ArrayIP17TemplateParameterEPS4_IS3_EPP11Declaration
[0x554200]
dtemplate.d:5006
_ZN17TemplateParameter8matchArgE3LocP5ScopeP5ArrayIP10RootObjectEmPS3_IPS_ES7_PP11Declaration
[0x5534b8]
dtemplate.d:893
_ZN19TemplateDeclaration17matchWithInstanceEP5ScopeP16TemplateInstanceP5ArrayIP10RootObjectEPS4_IP10ExpressionEi
[0x54905b]
dtemplate.d:7574
_D4ddmd9dtemplate16TemplateInstance13findBestMatchMRPS4ddmd6dscope5ScopePS4ddmd4root5array41__T5ArrayTC4ddmd10expression10ExpressionZ5ArrayZ9__lambda3MFC4ddmd7dsymbol7DsymbolZi
[0x559204]
func.d:4052 int ddmd.func.overloadApply(ddmd.dsymbol.Dsymbol, scope int
delegate(ddmd.dsymbol.Dsymbol)) [0x597f96]
dtemplate.d:7559
_ZN16TemplateInstance13findBestMatchEP5ScopeP5ArrayIP10ExpressionE [0x558ade]
dtemplate.d:6058 _ZN16TemplateInstance8semanticEP5ScopeP5ArrayIP10ExpressionE
[0x555ad3]
dtemplate.d:6527 _ZN16TemplateInstance8semanticEP5Scope [0x5569c3]
expression.d:5776 _ZN8ScopeExp8semanticEP5Scope [0x56cc7b]
expression.d:7877 _ZN6BinExp11binSemanticEP5Scope [0x572d06]
expression.d:7890 _ZN6BinExp15binSemanticPropEP5Scope [0x572d90]
expression.d:14031 _ZN6MinExp8semanticEP5Scope [0x586ed6]
expression.d:12191 _ZN8IndexExp8semanticEP5Scope [0x581268]
opover.d:652 _ZN11op_overload10OpOverload5visitEP8ArrayExp [0x5dc9de]
expression.d:11792 _ZN8ArrayExp6acceptEP7Visitor [0x5803d9]
opover.d:1522 _Z11op_overloadP10ExpressionP5Scope [0x5dbdfa]
expression.d:3477 _ZN10Expression11op_overloadEP5Scope [0x566ed4]
expression.d:11764 _ZN8ArrayExp8semanticEP5Scope [0x58029c]
expression.d:12719 _ZN9AssignExp8semanticEP5Scope [0x582df6]
statementsem.d:92 _ZN24StatementSemanticVisitor5visitEP12ExpStatement
[0x60a8fb]
statement.d:1169 _ZN12ExpStatement6acceptEP7Visitor [0x5fd7f6]
statementsem.d:3409 ddmd.statement.Statement
ddmd.statementsem.semantic(ddmd.statement.Statement, ddmd.dscope.Scope*)
[0x618270]
statementsem.d:146 _ZN24StatementSemanticVisitor5visitEP17CompoundStatement
[0x60ab93]
statement.d:1346 _ZN17CompoundStatement6acceptEP7Visitor [0x5fe026]
statementsem.d:3409 ddmd.statement.Statement
ddmd.statementsem.semantic(ddmd.statement.Statement, ddmd.dscope.Scope*)
[0x618270]
func.d:1672 _ZN15FuncDeclaration9semantic3EP5Scope [0x5919dd]
dmodule.d:1047 _ZN6Module9semantic3Ev [0x537cf0]
mars.d:1397 int ddmd.mars.tryMain(ulong, const(char)**) [0x5c175a]
mars.d:1587 _Dmain [0x5c22ae]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x709fba]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x709f04]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x709f76]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x709f04]
??:? _d_run_main [0x709e75]
??:? main [0x5c27ff]
??:? __libc_start_main [0xbb2ff44]

Also fails in DMD 2.071.0, 2.070.0, 2.069.2, 2.069.0, 2.068.0, 2.067.1,
2.067.0, and 2.065.0.

The length of a static array is a compile-time constant, as 2.071.0 accepts the
code when using "y.length" instead of $, so $ should also be a compile-time
constant when using a static array or ct-compatible opDollar (such as enum
opDollar(size_t i) = 0).

--

Re: 4x faster strlen with 4 char sentinel

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 27 June 2016 at 19:51:48 UTC, Jay Norwood wrote:
Your link's use of padding pads out with a variable number of 
zeros, so that a larger data type can be used for the compare 
operations.  This isn't the same as my example, which is 
simpler due to not having to fiddle with alignment and data 
type casting.


That's true, and it is fun to think about different string 
implementations. Just keep in mind that prior to the 90s, text 
was the essential datatype for many programmers and inventing new 
ways to do strings is heavily explored. I remember the first 
exercise we got at the university when doing the OS course was to 
implement "strlen", "strcpy" and "strcmp" in C or machine 
language. It can be fun.


Just keep in mind that the major bottleneck now is loading 64 
bytes from memory into cache. So if you test performance you have 
to make sure to invalidate the caches before you test and test 
with spurious reads over a very large memory area to get 
realistic results.


But essentially, the operation is not heavy, so to speed it up 
you need to predict and prefetch from memory in time, meaning no 
library solution is sufficient. (you need to prefetch memory way 
before your library function is called)

[Issue 16212] New: Segfault using "with" for field access inside switch statement

[via Digitalmars-d-bugs]

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

  Issue ID: 16212
   Summary: Segfault using "with" for field access inside switch
statement
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kirsy...@gmail.com

struct S {
   int field;
}
void main() {
   S s = S(3);
   switch (1) with (s) {
   case 1:
   field = 555; // segfault
   break;
   default:
   break;
}
}

Linux 64-bit DMD 2.071.0 and 2.070.0:

$ dmd -g switchwithbug.d
$ gdb switchwithbug
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
do_lookup_x (new_hash=new_hash@entry=129119144, 
old_hash=old_hash@entry=0x7fffdcf0, 
result=result@entry=0x7fffdd00, scope=0x7fff022b, i=i@entry=0, 
flags=flags@entry=1, skip=skip@entry=0x0, 
undef_map=undef_map@entry=0x77ffe1c8) at dl-lookup.c:83
83dl-lookup.c: No such file or directory.
(gdb) bt
#0  do_lookup_x (new_hash=new_hash@entry=129119144, 
old_hash=old_hash@entry=0x7fffdcf0, 
result=result@entry=0x7fffdd00, scope=0x7fff022b, i=i@entry=0, 
flags=flags@entry=1, skip=skip@entry=0x0, 
undef_map=undef_map@entry=0x77ffe1c8) at dl-lookup.c:83
#1  0x77de4961 in _dl_lookup_symbol_x (
undef_name=0x40cd71 "pthread_mutex_destroy", undef_map=0x77ffe1c8, 
ref=ref@entry=0x7fffddb8, symbol_scope=0x77ffe520, 
version=0x77fd3b18, type_class=type_class@entry=1, flags=1, 
skip_map=skip_map@entry=0x0) at dl-lookup.c:737
#2  0x77de9527 in _dl_fixup (l=, 
reloc_arg=) at ../elf/dl-runtime.c:111
#3  0x77df04d5 in _dl_runtime_resolve ()
at ../sysdeps/x86_64/dl-trampoline.S:45
#4  0x0043e1b5 in thread_term ()
#5  0x00433503 in gc_term ()
#6  0x004265a0 in rt_term ()
#7  0x00423421 in rt.dmain2._d_run_main() ()
#8  0x004233a1 in rt.dmain2._d_run_main() ()
#9  0x00423312 in _d_run_main ()
#10 0x00422b80 in main ()


DMD 2.069.2 and 2.069.0: No issue!


DMD 2.068.0, 2.067.1, 2.067.0, and even 2.065.0:
Program received signal SIGSEGV, Segmentation fault.
0x0041d3b3 in D main () at switchwithbug.d:8
8   field = 555;

Disassembly shows that "__withSym" hidden variable is not initialized:
   S s = S(3);
0x0041d3a8  <_Dmain+8>:  movl   $0x3,-0x10(%rbp)
   switch (1) with (s) {
   case 1:
   field = 555;
0x0041d3af  <_Dmain+15>:  mov-0x8(%rbp),%rax
0x0041d3b3  <_Dmain+19>:  movl   $0x22b,(%rax)
   break;
0x0041d3b9  <_Dmain+25>:  xor%eax,%eax
   default:
   break;
}
}


This bug isn't limited to DMD either, making me think it is a front-end issue:

$ gdc --version
gdc (crosstool-NG 1.20.0 - 20150405-2.066.1-f378f9ab41) 4.9.2

Program received signal SIGSEGV, Segmentation fault.
strcmp () at ../sysdeps/x86_64/multiarch/../strcmp.S:132
132../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0  strcmp () at ../sysdeps/x86_64/multiarch/../strcmp.S:132
#1  0x77de3e6c in check_match (sym=0x770dec08) at dl-lookup.c:177
#2  0x77de47e6 in do_lookup_x (new_hash=new_hash@entry=245674643, 
old_hash=old_hash@entry=0x7fffdb60, 
result=result@entry=0x7fffdb70, scope=, 
i=, i@entry=0, flags=flags@entry=1, skip=skip@entry=0x0, 
undef_map=undef_map@entry=0x77ffe1c8) at dl-lookup.c:249
#3  0x77de4961 in _dl_lookup_symbol_x (undef_name=0x4012d3 "munmap", 
undef_map=0x77ffe1c8, ref=ref@entry=0x7fffdc28, 
symbol_scope=0x77ffe520, version=0x77fd2030, 
type_class=type_class@entry=1, flags=1, skip_map=skip_map@entry=0x0)
at dl-lookup.c:737
#4  0x77de9527 in _dl_fixup (l=, 
reloc_arg=) at ../elf/dl-runtime.c:111
#5  0x77df04d5 in _dl_runtime_resolve ()
at ../sysdeps/x86_64/dl-trampoline.S:45
#6  0x0042daf9 in Dtor (this=...)
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/gc/gc.d:3149
#7  Dtor (this=...)
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/gc/gc.d:1433
#8  gc.gc.GC.Dtor() (this=...)
---Type  to continue, or q  to quit---
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/gc/gc.d:285
#9  0x00418d96 in gc_term ()
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/gc/proxy.d:148
#10 0x00407cb0 in rt_term ()
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/rt/dmain2.d:195
#11 0x00407d29 in runAll (this=0x7fffdda0)
at
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/rt/dmain2.d:415
#12 0x004079af in rt.dmain2._d_run_main() (
this=this@entry=0x7fffdda0, dg=...)
at

[Issue 16211] New: [REG 2.058] Cyclic dependencies broken again

[via Digitalmars-d-bugs]

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

  Issue ID: 16211
   Summary: [REG 2.058] Cyclic dependencies broken again
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com
CC: c...@dawg.eu

The code that triggered https://issues.dlang.org/show_bug.cgi?id=4384 is once
again compiling. Since a long time (2011).

We currently have cycles in Phobos without realizing it because of this. We
need to rethink how we do cycle detection. It was reworked in this PR:
https://github.com/dlang/druntime/pull/114

However, one problem with this is a module with no ctors is once again marked
as being "visited", so if it's needed 2+ times for a cycle, the cycle goes
undetected.

I don't want to necessarily go back to the alloca version, but perhaps we can
remove the stack-based search and use recursion once again. I'm almost certain
we will need at least 2x number of modules, but I'm not sure the limit. We also
have to prevent infinite loops, which is why the original code was so weird.

CC'ing Martin as he wrote the pull causing this.

--

Re: Getting the template name of a template instantiation

[Nordlöw via Digitalmars-d-learn]

On Monday, 27 June 2016 at 17:17:19 UTC, John wrote:

import std.traits;
__traits(identifier, TemplateOf!(S!int));


Scratch that, this is what you want:

import std.traits;
static assert(__traits(isSame, TemplateOf!(S!int), S));


I believe this is what

import std.traits : isInstanceOf;

is for.

Thanks! I found both useful.

Re: static if enhancement

[Claude via Digitalmars-d]

On Monday, 27 June 2016 at 11:05:49 UTC, cym13 wrote:
What's unintuitive about it (real question)? It would make it 
behave more like a standard if and early returns are very 
common, well understood and good practice:


void func(int* somepointer) {
if (somepointer == null)
return;
[rest of the code]
}


From this perspective, you are right. But mixing "return" or 
"throw" which belong to the "run-time world", and "static if" 
which is "compile-time" feels wrong somehow to me.


But maybe I'm biased by my C experience. It's like mixing 
"return" and "#if".


Some other negative responses in this thread may also give a 
better explanation of what I mean.


The other thing is that, introducing that will not break any code 
(a priori). But if the change is made, and it turns out to not 
pay enough or lead to some abuse (more on the readability part), 
going backward shall introduce code-breakage.


Also, I agree with QAston comments about errors on unreachable 
code.


Maybe "static return" is a good compromise?...

[Issue 10291] formattedWrite() to an Appender fails silently after Appender.clear()

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #3 from Jack Stouffer  ---
(In reply to yazan.dabain from comment #2)
> This currently correctly fails to compile, and a note has been added to the
> documentation. Shouldn't this be closed?

Yup

--

Re: Diff between function and delegate

[Mathias Lang via Digitalmars-d-learn]

On Monday, 27 June 2016 at 19:34:06 UTC, "Smoke" Adams wrote:

I have

alias fnc = void function(Object);
alias del = void delegate();

Does func avoid the GC? I am passing in this to Object so I 
don't technically need a delegate or a "context". I want to be 
sure that I'm actually gaining something here by doing this.


I read somewhere that delegates only require the GC when they 
use objects outside their scope. Do delegates always use the GC 
or only in certain cases?


Delegate don't GC allocate when:
- You take a pointer to a member function
- The function accept a `scope` delegate and you pass a literal
- You use `scope myDG = (Params) { body... }`

[Issue 6409] std.array.empty for associative arrays too

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
What's the rationale? Why not just aa.length == 0?

--

[Issue 13256] Update std.array.front to support all strings uniformly

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |WONTFIX

--- Comment #1 from Jack Stouffer  ---
This is not going to be fixed, at least not in D2. Just search for
"auto-decoding" in the news group for the discussions.

--

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Monday, 27 June 2016 at 16:38:58 UTC, Ola Fosheim Grøstad 
wrote:
Yes, and the idea of speeding up strings by padding out with 
zeros is not new. ;-) I recall suggesting it back in 1999 when 
discussing the benefits of having a big endian cpu when sorting 
strings. If it is big endian you can compare ascii as 32/64 bit 
integers, so if you align the string and pad out with zeros 
then you can speed up strcmp() by a significant factor. Oh, 
here it is:


Your link's use of padding pads out with a variable number of 
zeros, so that a larger data type can be used for the compare 
operations.  This isn't the same as my example, which is simpler 
due to not having to fiddle with alignment and data type casting.


I didn't find a strlen implementation for dchar or wchar in the D 
libraries.


I also found it strange, the non-zero initialization values for 
char, dchar, wchar.  I suppose there's some reason?


int [100]  to zeros.
char [100]  to 0xff;
dchar [100]   to 0x;
wchar [100]   to 0x;

Re: Beta D 2.071.1-b2

[Martin Nowak via Digitalmars-d-announce]

On 06/16/2016 08:43 PM, Jack Stouffer wrote:
> On Sunday, 29 May 2016 at 21:53:23 UTC, Martin Nowak wrote:
>> Second beta for the 2.071.1 release.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.071.1.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
> 
> This release would fix some pretty serious bugs. What's the holdup?

I couldn't find enough time to fix
https://issues.dlang.org/show_bug.cgi?id=16085. Let's do the point
release now anyhow and follow-up later on.

Re: Beta D 2.071.1-b2

[Martin Nowak via Digitalmars-d-announce]

On 06/16/2016 09:47 PM, deadalnix wrote:
> 196418a8b3ec1c5f284da5009b4bb18e3f70d99f still not in after 3 month.
> This is typesystem breaking. While I understand it wasn't picked for
> 2.071 , I'm not sure why it wasn't for 2.071.1 .

Because it didn't target stable.

[Issue 12916] std.array index based insert

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #1 from Jack Stouffer  ---
std.array.insertInPlace

--

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 19:39:20 UTC, luminousone wrote:

OpenCL is for micro threading, not simd.


What is your point? Clang++ vector extensions use OpenCL 
semantics, so you need to look up the OpenCL spec to figure out 
what it supports. It is not well-documented in the Clang 
documentation.


Are you trolling me?

[Issue 16210] New: std.utf.byUTF can be made into a bidirectional range

[via Digitalmars-d-bugs]

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

  Issue ID: 16210
   Summary: std.utf.byUTF can be made into a bidirectional range
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

... for certain inputs at least.

Currently it's only a forward range.

--

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 19:34:18 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote:
Its the nature of being compatible with C, it might not be 
explicitly stated in the spec, but the only place to put the 
vtable pointer and stay compatible with C structs is at the 
end.


No... You are making way too many assumptions.


By all means believe whatever delusion fits your corner of the 
universe.

Re: static if enhancement

[cym13 via Digitalmars-d]

On Monday, 27 June 2016 at 18:55:48 UTC, deadalnix wrote:

On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
Me, because that's what it means to evaluate the condition at 
compile time and only compiling in the appropriate branch. 
This is additional and special behaviour and it destroys the 
orthogonality of 'static if' and 'return'. (I don't feel 
strongly about the change, but the idea that the new behavior 
should be expected anyway is flawed.)




Alright, I have to range myself with most here. While I'm all 
for not warning about unreachable code, I'm opposed to not 
compiling the rest of the code. This create non orthogonality 
between static if and control flow analysis, the kind that 
clearly do not pay for itself.


Okay, I'm convinced.

[Issue 16209] New: std.string.isNumeric can work with forward ranges

[via Digitalmars-d-bugs]

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

  Issue ID: 16209
   Summary: std.string.isNumeric can work with forward ranges
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

isNumeric can be modified to work with forward ranges, not just random access
ranges.

--

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 18:58:25 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote:
Regarding C++ I found this to be a fun read: 
http://yosefk.com/c++fqa/ :-)


A lot of it makes sense... C++ is what happens when you evolve, 
evolve, evolve and evolve a language from a starting-point that 
was not a high level language, desperately trying to hone it 
into high level shoes... Those shoes will never fit perfectly, 
obviously.


It gets even more expansive when you add inn compiler 
extensions. For instance gcc/clang simd extensions is basically 
taking in parts of OpenCL into C++. In order to figure out how 
they work you have to read the OpenCL spec... I only found out 
today that I can do "simd.even" and "simd.odd" to get even and 
odd elements from a simd register in Clang... after 
implementing it manually first. ;-/


OpenCL is for micro threading, not simd. OpenCL allows you to run 
thousands of instances of the same function in parallel, in 
either the cpu and/or the gpu.


SIMD or single instruction multiple data, is for instruction 
level parallelism,aka vector add op that adds 4 floats to 4 other 
floats in a single cpu instruction.

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote:
Its the nature of being compatible with C, it might not be 
explicitly stated in the spec, but the only place to put the 
vtable pointer and stay compatible with C structs is at the end.


No... You are making way too many assumptions.

Diff between function and delegate

[Smoke Adams via Digitalmars-d-learn]

I have

alias fnc = void function(Object);
alias del = void delegate();

Does func avoid the GC? I am passing in this to Object so I don't 
technically need a delegate or a "context". I want to be sure 
that I'm actually gaining something here by doing this.


I read somewhere that delegates only require the GC when they use 
objects outside their scope. Do delegates always use the GC or 
only in certain cases?

Re: Call to Action: making Phobos @safe

[Walter Bright via Digitalmars-d]

On 6/27/2016 8:14 AM, Robert burner Schadek wrote:

On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote:

It's a wiki, feel free to add it.


I have to say that reply really makes me angry. I created that list so Andrei
and you have an easy to find spot where you can write down tasks so people can
work on them. You did not disagree with the list at the time, and didn't
disagree so far. I really think it is clear that these are two list that you two
are maintaining, how else should anybody know what work is pre-approved and
where D is going.

I think I'm not asking too much here, if I ask you to decide if you want to
maintain that list or if you want to delete it. The current limbo state is just
making things worse.


Sorry to have offended you, I worded things badly. Thank you for making the 
list. It's just that I'm feeling a bit overwhelmed at the moment with trying to 
get things done and being asked to do more every day, and I'd like to delegate.

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 16:48:16 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote:
easy to implement. In C++ the exact position of the vtable 
depends on what is in the base most class, it might be 8bytes 
in, maybe 20, maybe 200, you just don't know, And certainly 
the runtime can't know.


I know what the usual implementation is, but I don't believe it 
is required by the spec. So it is implementation defined and 
the runtime most certainly can know if that is part of the 
requirement. As I said, you don't even need to use a vtable 
AFAIK.


Can show me the section in the spec where it is required? I 
can't find it.


Its the nature of being compatible with C, it might not be 
explicitly stated in the spec, but the only place to put the 
vtable pointer and stay compatible with C structs is at the end. 
You will notice in D you can't inherit from a struct, this isn't 
merely design choice.

Re: executeShell doesn't work but system does

[Smoke Adams via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 16:02:18 UTC, ag0aep6g wrote:

On 06/26/2016 05:37 PM, Smoke Adams wrote:

[...]


Unsolicited spelling correction: no 'i' in "deprecated".


[...]


`system` directly prints its output, `executeShell` returns it 
in a tuple with the status code. Maybe cls works by printing 
some specific clear code. If so, you have to print the output 
of the command.


[...]


neither work but

wait(spawnShell("cls"));  

Re: Another audio plugin in D

[Guillaume Piolat via Digitalmars-d-announce]

On Monday, 27 June 2016 at 18:59:35 UTC, Jacob Carlborg wrote:

On 27/06/16 13:02, Guillaume Piolat wrote:

Unloading of shared libraries on OS X continues to be a 
problem though,

it would be nice if it worked in 64-bit.


I know the current situation is not ideal, but does it cause 
any problems?


My wording was a bit strong.

As you may remember, the workaround involved "leaking" the dynlib.

On OS X I keep having a lingering crash which is a bit random, 
happens with multiple instantiation/closing of a dynlib. It is a 
bit hard to reproduce and I failed to remove it. It follows an 
hysteresis pattern, when it's here it reproduces reliably, then 
disappear. With LDC-b2 I thought it was gone (was codegen I 
thought), but seems still here somehow.


I'm not sure at all if it's related at all to dynlib unloading 
(wild guess probability: 50%).

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote:
Regarding C++ I found this to be a fun read: 
http://yosefk.com/c++fqa/ :-)


A lot of it makes sense... C++ is what happens when you evolve, 
evolve, evolve and evolve a language from a starting-point that 
was not a high level language, desperately trying to hone it into 
high level shoes... Those shoes will never fit perfectly, 
obviously.


It gets even more expansive when you add inn compiler extensions. 
For instance gcc/clang simd extensions is basically taking in 
parts of OpenCL into C++. In order to figure out how they work 
you have to read the OpenCL spec... I only found out today that I 
can do "simd.even" and "simd.odd" to get even and odd elements 
from a simd register in Clang... after implementing it manually 
first. ;-/

Re: static if enhancement

[deadalnix via Digitalmars-d]

On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
Me, because that's what it means to evaluate the condition at 
compile time and only compiling in the appropriate branch. This 
is additional and special behaviour and it destroys the 
orthogonality of 'static if' and 'return'. (I don't feel 
strongly about the change, but the idea that the new behavior 
should be expected anyway is flawed.)




Alright, I have to range myself with most here. While I'm all for 
not warning about unreachable code, I'm opposed to not compiling 
the rest of the code. This create non orthogonality between 
static if and control flow analysis, the kind that clearly do not 
pay for itself.

Re: Another audio plugin in D

[Jacob Carlborg via Digitalmars-d-announce]

On 27/06/16 13:02, Guillaume Piolat wrote:


Unloading of shared libraries on OS X continues to be a problem though,
it would be nice if it worked in 64-bit.


I know the current situation is not ideal, but does it cause any problems?

--
/Jacob Carlborg

C++17 is feature complete

[default0 via Digitalmars-d]

Regarding C++ I found this to be a fun read: 
http://yosefk.com/c++fqa/ :-)

Re: AWS SDK

[jadbox via Digitalmars-d]

On Monday, 27 June 2016 at 17:53:32 UTC, Brad Roberts wrote:

https://github.com/braddr/downloads.dlang.org/tree/master/src

It has sig v2 signing and some s3 object related code.  Super 
minimal and sig v2 is out of date (though still very usable, in 
most aws regions).


Ideally, someone would partner with aws -- there's a developer 
tools forum -- to add D to the suite of languages.  I'm fairly 
sure they code generate at least a large part of the tool kits 
from the api definitions for each of the tons of services.  
Trying to manage them all by hand is a loosing battle.


I've been tempted to do this a couple times, but the time 
investment would likely be more than I'm willing to spend.


Yep, the sdk would need to be autogenerated from their spec 
files. I use a great number of services from s3, Kinesis, SQS, 
SNS, Redshift, DynamoDB, EC2 cmds, Route 53 reconfiguring. This 
is a common story for most cloud developers. With the advent of 
microservices, it's a relatively easy sell to get developers to 
try a new language for a small service, but most of these 
services rely on cloud drivers.

Re: static if enhancement

[Timon Gehr via Digitalmars-d]

On 27.06.2016 13:05, cym13 wrote:

On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote:

On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:

We are talking about early returns (checking for something and
returning as soon as possible) which are a well-known and efficient
way to reduce indentation levels and increase modularity. You can't
come and say "What? You want it to work? Man, you should have thought
your code better!": the very reason this subject is discussed is to
allow people to deal with indentation levels!


I didn't want to sound like that. But my post was unclear. Though, in
the example, it looks nice, and I understand one would want such a
feature. I think it could be abused in some other cases and make the
code less readable.

I had in mind some cross-platform libraries written in C with #if
#elif and #endif all other the place (used with compiler switches).
And I reckon the current "static if" is a good tool that fits well
with the rest of the language to properly mark different sections of
code, and have different implementations. The fact it gives another
indentation level could be seen as an opportunity to better modularize
code (it's what I meant).

So I find that special case (having code after a "static if()
{return;}" treated like in the "else" block) a bit unintuitive, and
could be prone to bad practice and confusion.


What's unintuitive about it (real question)? It would make it behave
more like a standard if and early returns are very common, well
understood and good practice:

void func(int* somepointer) {
 if (somepointer == null)
 return;
 [rest of the code]
}

When seeing such code (which generally leads to cleaner functions) the
meaning is quite obvious, I fail to see who would expect static if to
behave otherwise.


Me, because that's what it means to evaluate the condition at compile 
time and only compiling in the appropriate branch. This is additional 
and special behaviour and it destroys the orthogonality of 'static if' 
and 'return'. (I don't feel strongly about the change, but the idea that 
the new behavior should be expected anyway is flawed.)



Of course knowing how it works it makes sense that
making it work that way isn't easy


It's rather easy.


but it sounds more like a leaky
abstraction than something more intuitive to me.


My preferred option is to simply add 'static return' to avoid the 
context-dependence.

Re: Where is the D deep learning library?

[Guillaume Piolat via Digitalmars-d]

On Monday, 27 June 2016 at 16:41:15 UTC, jmh530 wrote:

On Monday, 27 June 2016 at 15:31:07 UTC, Guillaume Piolat wrote:


Well I get the manpower thing, everything we do is quite 
labour-intensive. I'm just curious nobody started such an 
effort (but there was with DlangScience, gamedev, web...). And 
with such a hyped area, getting successful is a real 
possibility for someone who would be a domain expert.




Do you have a particular need for a machine learning library?

I'm just asking because I feel like the examples you mentioned 
(DlangScience, gamedev, web) are areas where there are people 
actively working on things in large part because they want to 
use them on specific applications. It seems like it is much 
easier to get people to contribute when they actually need 
something.


Not yet, but it could be useful for new types of audio effects 
and specific tasks like voiced/unvoiced detection.

Re: Where is the D deep learning library?

[Jack Stouffer via Digitalmars-d]

On Monday, 27 June 2016 at 15:31:07 UTC, Guillaume Piolat wrote:
Well I get the manpower thing, everything we do is quite 
labour-intensive. I'm just curious nobody started such an 
effort (but there was with DlangScience, gamedev, web...).


D doesn't even have the building blocks in D code. Ndslice and 
the upcoming BLAS in D are nessesary steps if we want a idiomatic 
D machine learning library. And that's just the foundational work.


You don't need to match the manpower and stability of the 
established solution to make something useful. Perhaps there 
could be something distinctive enough to make it attractive?


Unfortunately, academics (who are usually the target audience for 
these libraries) are very set in their ways. You'll need 
something that surpasses the functionality of the current 
solutions and is just as easy to use in order for it to catch on 
:/

Re: AWS SDK

[Brad Roberts via Digitalmars-d]

On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote:

Is there an AWS library in the works for D? It's seriously the main
blocker for me to push adoption of the language internally.

If not, I can try to invest time into making one, but I could use help.

(fyi, there's one in the works for Rust: https://github.com/rusoto/rusoto)


I have some old code here:

https://github.com/braddr/downloads.dlang.org/tree/master/src

It has sig v2 signing and some s3 object related code.  Super minimal 
and sig v2 is out of date (though still very usable, in most aws regions).


Ideally, someone would partner with aws -- there's a developer tools 
forum -- to add D to the suite of languages.  I'm fairly sure they code 
generate at least a large part of the tool kits from the api definitions 
for each of the tons of services.  Trying to manage them all by hand is 
a loosing battle.


I've been tempted to do this a couple times, but the time investment 
would likely be more than I'm willing to spend.

Re: 4x faster strlen with 4 char sentinel

[Brad Roberts via Digitalmars-d-announce]

On 6/26/2016 11:47 AM, Jay Norwood via Digitalmars-d-announce wrote:

On Sunday, 26 June 2016 at 16:59:54 UTC, David Nadlinger wrote:

Please keep general discussions like this off the announce list, which
would e.g. be suitable for announcing a fleshed out collection of
high-performance string handling routines.

A couple of quick hints:
 - This is not a correct implementation of strlen, as it already
assumes that the array is terminated by four zero bytes. That
iterating memory with a stride of 4 instead of 1 will be faster is a
self-evident truth.
 - You should be benchmarking against a "proper" SIMD-optimised strlen
implementation.

 — David



This is more of just an observation that the choice of the single zero
sentinel for C string termination comes at a cost of 4x strlen speed vs
using four terminating zeros.

I don't see a SIMD strlen implementation in the D libraries.

The strlen2 function I posted works on any string that is terminated by
four zeros, and returns the same len as strlen in that case, but much
faster.

How to get strings initialized with four terminating zeros at compile
time is a separate issue.  I don't know the solution, else I might
consider doing more with this.


Yup.. there's a reason that many many hours have been spent optimizing 
strlen and other memory related length and comparison routines.  They 
are used a lot and the number of ways of making them fast varies almost 
as much as the number of cpu's that exist.  This effort is embedded in 
the code gen of compilers (other than dmd) and libc runtimes.  Trying to 
re-invent it is noble, and very educational, but largely redundant.

[Issue 16208] New: moduleinfo importedModules contains needless duplicates

[via Digitalmars-d-bugs]

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

  Issue ID: 16208
   Summary: moduleinfo importedModules contains needless
duplicates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

When trying to debug a module cycle issue, I stumbled across the realization
that each time a module imports another module, that reference is added to the
list of imported modules, even if it's already there.

The compiler should eliminate these duplicates, as it slows down runtime
startup during module cycle detection, and bloats the executable.

Especially when idiomatic D code is supposed to import locally only when
needed. Each of these local imports adds another reference.

--

Re: Getting the template name of a template instantiation

[John via Digitalmars-d-learn]

On Monday, 27 June 2016 at 17:14:23 UTC, John wrote:

On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:

If I have a template parameter

E = S!int

where

struct S(T) { S x; }

how can I extract the template name part `S` from E`?

Something like:

static assert(is(templateName!(S!int) == S));

Is this already in Phobos somewhere?


import std.traits;
__traits(identifier, TemplateOf!(S!int));


Scratch that, this is what you want:

import std.traits;
static assert(__traits(isSame, TemplateOf!(S!int), S));

Re: Getting the template name of a template instantiation

[Ali Çehreli via Digitalmars-d-learn]

On 06/27/2016 09:54 AM, Lodovico Giaretta wrote:

On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:

If I have a template parameter

E = S!int

where

struct S(T) { S x; }

how can I extract the template name part `S` from E`?

Something like:

static assert(is(templateName!(S!int) == S));

Is this already in Phobos somewhere?


If I recall correctly, std.traits contains a TemplateOf trait, that
should do exactly what you want.


Yes, isIntanceOf:

  https://dlang.org/phobos/std_traits.html#isInstanceOf

Ali

Re: [Semi OT] About code review

[Johan Engelen via Digitalmars-d-announce]

On Monday, 27 June 2016 at 00:01:34 UTC, deadalnix wrote:
Several people during DConf asked abut tips and tricks on code 
review. So I wrote an article about it:


http://www.deadalnix.me/2016/06/27/on-code-review/


It's a nice read.

One comment: perhaps the balance has tipped a bit much to "making 
a good PR", rather than "doing a good review". I feel the merit 
of a review is to improve the contribution, rather than to decide 
whether it is mergable or not.  Although it is in the article, I 
think it could be given a little more attention: the review 
itself should contribute to the project, i.e. the reviewer should 
(try hard to) propose alternatives if something should/could be 
improved. Criticism is very easy, _constructive_ criticism isn't; 
I think the latter is needed to gain a contributor, and the first 
does the opposite.


-Johan

Re: Getting the template name of a template instantiation

[John via Digitalmars-d-learn]

On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:

If I have a template parameter

E = S!int

where

struct S(T) { S x; }

how can I extract the template name part `S` from E`?

Something like:

static assert(is(templateName!(S!int) == S));

Is this already in Phobos somewhere?


import std.traits;
__traits(identifier, TemplateOf!(S!int));

Re: Getting the template name of a template instantiation

[Lodovico Giaretta via Digitalmars-d-learn]

On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:

If I have a template parameter

E = S!int

where

struct S(T) { S x; }

how can I extract the template name part `S` from E`?

Something like:

static assert(is(templateName!(S!int) == S));

Is this already in Phobos somewhere?


If I recall correctly, std.traits contains a TemplateOf trait, 
that should do exactly what you want.

Re: Where is the D deep learning library?

[jmh530 via Digitalmars-d]

On Monday, 27 June 2016 at 15:31:07 UTC, Guillaume Piolat wrote:


Well I get the manpower thing, everything we do is quite 
labour-intensive. I'm just curious nobody started such an 
effort (but there was with DlangScience, gamedev, web...). And 
with such a hyped area, getting successful is a real 
possibility for someone who would be a domain expert.




Do you have a particular need for a machine learning library?

I'm just asking because I feel like the examples you mentioned 
(DlangScience, gamedev, web) are areas where there are people 
actively working on things in large part because they want to use 
them on specific applications. It seems like it is much easier to 
get people to contribute when they actually need something.

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote:
easy to implement. In C++ the exact position of the vtable 
depends on what is in the base most class, it might be 8bytes 
in, maybe 20, maybe 200, you just don't know, And certainly the 
runtime can't know.


I know what the usual implementation is, but I don't believe it 
is required by the spec. So it is implementation defined and the 
runtime most certainly can know if that is part of the 
requirement. As I said, you don't even need to use a vtable AFAIK.


Can show me the section in the spec where it is required? I can't 
find it.

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 16:10:13 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote:
C++ post pended vtable pointers, Are not implementation 
dependent.


I don't know what «post pended vtable pointers» means. Which 
section of the C++ spec are you referring to?


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf


Member name lookup, Virtual functions, some where in their.

When you declare an object,

class a{
  int b;
  int c;
  //** the compiler puts a hidden variable here called the vtable 
pointer **//

  void **vtble;
  virtual void somefunc();
}

All of your virtual functions are referenced from this table; So 
that inherited classes will call the correct function based on 
the type of said object and the overrides in said object.


C#, D, put the vtable as the very first item in the base most 
class, C++ puts this as the last item in the base most class, C# 
and D use the first item in the vtable for type information 
generated by the compiler at compile time. Because the vtable is 
in the same place in ALL objects type reflection is very easy to 
implement. In C++ the exact position of the vtable depends on 
what is in the base most class, it might be 8bytes in, maybe 20, 
maybe 200, you just don't know, And certainly the runtime can't 
know.


Granted their are really bloated, slow, and memory chugging ways 
around this, such as storing a list of every allocated object in 
memory somewhere, and having reflection calls search this using 
an objects memory address.

Re: static if enhancement

[QAston via Digitalmars-d]

On Monday, 27 June 2016 at 00:31:39 UTC, Jonathan M Davis wrote:
On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via 
Digitalmars-d wrote:


I would think that it's highly unintuitive to think that code 
outside of a static if would be treated as part of an else of a 
static if just because the static if happens to return at the 
end. Certainly, if the code after the static if couldn't 
compile if the static if code didn't return, I definitely think 
that the code following it needs to be in an else. Really, it 
seems to me that this comes down to a complaint about the 
compiler producing errors on unreachable code - which is the 
sort of thing that I tend to think should not be treated as an 
error - _especially_ with how badly it tends to interact with 
generic code.


+1

So, as long as the code following the static if is valid 
without being in an else for the static if, I'm all for having 
the compiler just optimize out everything after the return 
without complaining - but if we're going to do that, it really 
shouldn't be specific to static ifs. That would be unreasonably 
inconsistent IMHO. And I don't think that it's a good idea to 
treat code following a static if as if it were in an else just 
because of a return statement or break statement or some other 
control statement in the static if which would cause the code 
after it to be skipped. That would be confusing and 
inconsistent IMHO, much as it would be nice to avoid the extra 
braces and indentation.


So, if we're going to change things here, I think that the 
approach is to stop having the compiler complain about 
unreachable code, which I think is very reasonable in light of 
how annoying that can get - particularly with generic code - 
though I'm sure that some folks will be unhappy about that just 
like some folks want the compiler to complain about unused 
variables (though we don't do that in part because of how badly 
it interacts with various D features - like highly templatized 
code - and that's pretty much the main reason that having the 
compiler complain about unreachable code is so problematic, 
which could be an argument to have it stop complaining about 
it).




I'm one of those folks who think that errors about unreachable 
code are important and I'm perfectly willing to pay the price of 
usually short changes to code to keep things clear. Especially in 
generic code, as for me not knowing what's going on is far more 
annoying than having to maintain a bit of structure.


That said, when faced with choice between having unreachability 
error removed and having a change in the language making every 
static if more complex, I definitely prefer having errors removed 
and the code being optimized out. Errors can be always added by 
external tools. Inconsistencies in the language can't be fixed 
externally. The proposed language change brings an inconsistency 
for a trivial gain. Ignoring unreachable code is a consistent 
change, so in my opinion a much better solution.

Getting the template name of a template instantiation

[Nordlöw via Digitalmars-d-learn]

If I have a template parameter

E = S!int

where

struct S(T) { S x; }

how can I extract the template name part `S` from E`?

Something like:

static assert(is(templateName!(S!int) == S));

Is this already in Phobos somewhere?

Re: 4x faster strlen with 4 char sentinel

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 27 June 2016 at 16:22:56 UTC, Jay Norwood wrote:
This strlen2 doesn't require special alignment or casting of 
char pointer types to some larger type. That keeps the strlen2 
implementation fairly simple.


Yes, and the idea of speeding up strings by padding out with 
zeros is not new. ;-) I recall suggesting it back in 1999 when 
discussing the benefits of having a big endian cpu when sorting 
strings. If it is big endian you can compare ascii as 32/64 bit 
integers, so if you align the string and pad out with zeros then 
you can speed up strcmp() by a significant factor. Oh, here it is:


http://disinterest.org/resource/MUD-Dev/1999q1/009759.html

Of course, this is all moot now, little endian + simd has made 
such tricks redundant. Simd probably makes your strlen2 redundant 
too. The bottle neck tends to be memory access/prefetching for 
simple algorithms.

Logical location of template instantiations

[Lodovico Giaretta via Digitalmars-d]

import std.conv, core.memory;

struct S
{
int x;
private this(int val)
{
x = val;
}
}

void main()
{
auto ptr = cast(S*)GC.malloc(S.sizeof);
auto s = ptr.emplace(3);
}

This code does not work, as  the call `ptr.emplace(3)` creates a 
new concrete implementation of emplace with parameters `S` and 
`int`, which logically belongs to module std.conv, and so has no 
access to the private constructor.


But, logically speaking, as I'm able to construct objects of S, I 
should also be able to emplace them (which is the same thing, 
logically) while inside my module. What I mean is that in this 
situation it would be better if the call `ptr.emplace(3)` created 
a new concrete implementation of emplace inside the module that 
called it, to have the correct access permissions.


This is not the first time I run into this limitation (not only 
with functions, but also with structs), so I wonder: wouldn't it 
be worth a way to get this behaviour?


Thank you for your time.

Lodovico Giaretta

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Monday, 27 June 2016 at 06:31:49 UTC, Ola Fosheim Grøstad 
wrote:
Besides there are plenty of other advantages to using a 
terminating sentinel depending on the use scenario. E.g. if you 
want many versions of the same tail or if you are splitting a 
string at white space (overwrite a white space char with a 
zero).


This strlen2 doesn't require special alignment or casting of char 
pointer types to some larger type. That keeps the strlen2 
implementation fairly simple.


The implementation is only testing one char per increment.  It 
doesn't require the extra xor processing used in some of the 
examples.


I haven't checked if there is a strlen for dchar or wchar, but it 
should also speed up those.

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote:
C++ post pended vtable pointers, Are not implementation 
dependent.


I don't know what «post pended vtable pointers» means. Which 
section of the C++ spec are you referring to?


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 15:59:30 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote:
C++ has post pended vtable pointers on class objects, its 
unlikely good reflection can ever be added to the language, as 
the vtable may be in a different place in every object their 
is no way to access it universally for object type 
information. Some Compile time type reflection might be 
possible, But I bet it ends up being flimsy.


Huh? IIRC it is implementation defined in C++. There are C++ 
compilers/tools that provide more extensive reflection, but it 
is not part of the standard beyond simple typeid reflection.


C++ post pended vtable pointers, Are not implementation dependent.

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote:
C++ has post pended vtable pointers on class objects, its 
unlikely good reflection can ever be added to the language, as 
the vtable may be in a different place in every object their is 
no way to access it universally for object type information. 
Some Compile time type reflection might be possible, But I bet 
it ends up being flimsy.


Huh? IIRC it is implementation defined in C++. There are C++ 
compilers/tools that provide more extensive reflection, but it is 
not part of the standard beyond simple typeid reflection.

Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Monday, 27 June 2016 at 06:16:57 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote:

On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

On 6/26/2016 10:18 AM, Enamex wrote:
  - template arguments that accept constant values of any 
type whatsoever

'template';


Still adding D features, I see!


Now if only they could bring over some of D's superior 
template syntax, all of the <>'s are so damned ugly, Or type 
reflection features(is this even possible in c++?).


Ugh, D's template syntax is far from superior :-(.

What kind of type reflection are you thinking of? C++ has 
static type traits and some very limited dynamic reflection for 
classes with virtual functions, but C++ is nowhere near 
Python's capabilities.


C++ does have a special interest group working on reflection:

https://root.cern.ch/blog/status-reflection-c


D's template syntax is vastly superior to C++...

C++ has post pended vtable pointers on class objects, its 
unlikely good reflection can ever be added to the language, as 
the vtable may be in a different place in every object their is 
no way to access it universally for object type information. Some 
Compile time type reflection might be possible, But I bet it ends 
up being flimsy.

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 15:49:20 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 27 June 2016 at 15:43:03 UTC, luminousone wrote:
Modern C++ is a train-wreck, I don't think we should consider 
D features around the flaws of another language.


RAII is the same in C++, but actually better supported in C++ 
atm.


I meant: Issues around RAII are the same in D as in C++.