how to avoid cycle detected?

2015-07-01 Thread aki via Digitalmars-d-learn

Following code causes run-time error.
How can I use static this() without causing error?
It's difficult to avoid this situation because
actual code is more complex.

file main.d:
void main() {
}

file a.d:
import b;
class A {
static this() {}
};

file b.d:
import a;
class B {
static this() {}
};

object.Exception@src\rt\minfo.d(162): Aborting: Cycle detected 
between modules w

ith ctors/dtors:
a - b - a




Re: Mutable reference to const objects

2015-07-01 Thread Yuxuan Shui via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 08:30:23 UTC, Yuxuan Shui wrote:

How do I express a mutable reference to a const object in D?

What I want to do is to define a variable, which refers a 
constant object, but I can change which constant object it is 
referring. Is this possible?


I wonder will something like:

class Const(T):
const(T) inner;
alias this inner;
}

work?


Mutable reference to const objects

2015-07-01 Thread Yuxuan Shui via Digitalmars-d-learn

How do I express a mutable reference to a const object in D?

What I want to do is to define a variable, which refers a 
constant object, but I can change which constant object it is 
referring. Is this possible?


Re: Mutable reference to const objects

2015-07-01 Thread Nicholas Wilson via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 08:33:44 UTC, Yuxuan Shui wrote:

On Wednesday, 1 July 2015 at 08:30:23 UTC, Yuxuan Shui wrote:

How do I express a mutable reference to a const object in D?

What I want to do is to define a variable, which refers a 
constant object, but I can change which constant object it is 
referring. Is this possible?


I wonder will something like:

class Const(T):
const(T) inner;
alias this inner;
}

work?


You want rebindable.

see http://dlang.org/phobos/std_typecons.html


Re: Nullable with reference types

2015-07-01 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, June 30, 2015 14:29:52 Steven Schveighoffer via Digitalmars-d-learn 
wrote:
 I know this is just back-of-envelope, but what's wrong with:

 alias Nullable(T) if(is(T == class)) = T;

 bool isNull(T)(T t) if(is(T == class)) { return t is null;}

In principle, there's no reason why we can'd do something like that. It's
essentially what we do with the take and its return type (though that
doesn't require a free function for additional functionality). The question
would be whether it would break code to do so and whether it would be worth
the breakage if we did.

- Jonathan M Davis



Re: tkd - basic compilation problem

2015-07-01 Thread Jordi Sayol via Digitalmars-d-learn


El 30/06/15 a les 16:28, Paul via Digitalmars-d-learn ha escrit:
 Using dub I get this during linking:

 Building tkd-test ~master configuration application, build type debug.
 Compiling using dmd...
 Linking...
 /usr/bin/ld: cannot find -ltcl
 /usr/bin/ld: cannot find -ltk

 ...any suggestions please?


If you are in Debian, Ubuntu, Linuxmint, etc, you can use the d-apt repository:

http://d-apt.sourceforge.net/

There are deb packages for tkd:

$ sudo apt-get install libtkd-dev libtkd-doc

You can compile the example application included on libtkd-doc deb package to 
test if tkd is properly installed on your system:

For shared linking against libphobos2.so and libtkd.so:
$ dmd `pkg-config --cflags --libs tkd` -J/usr/share/libtkd-doc/example/media/ 
/usr/share/libtkd-doc/example/example.d

For static linking against libphobos2.a and libtkd.a:
$ dmd `pkg-config --cflags --libs tkd-static` 
-J/usr/share/libtkd-doc/example/media/ /usr/share/libtkd-doc/example/example.d

Best regards,
Jordi




Re: goroutines vs vibe.d tasks

2015-07-01 Thread Mathias Lang via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
Just creating a bunch (10k) of sleeping (for 100 msecs) 
goroutines/tasks.


Compilers
go: go version go1.4.2 linux/amd64
vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23

Code
go: http://pastebin.com/2zBnGBpt
vibe.d: http://pastebin.com/JkpwSe47

go version build with go build test.go
vibe.d version built with dub build --build=release test.d

Results on my machine:

go: 168.736462ms (overhead ~ 68ms)
vibe.d: 1944ms   (overhead ~ 1844ms)

Why creating of vibe.d tasks is so slow (more then 10 times)???


In your dub.json, can you use the following:

subConfigurations: {
vibe-d: libasync
},
dependencies: {
vibe-d: ~0.7.24-beta.3
},


Turns out it makes it much faster on my machine (371ms vs 
1474ms). I guess it could be a good thing to investigate if we 
can make it the default in 0.7.25.


Re: Same process to different results?

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 1:44 PM, Steven Schveighoffer wrote:


Schizophrenia of Phobos.

Phobos thinks a string is a range of dchar instead of a range of char.
So what cycle, take, and array all output are dchar ranges and arrays.

When you cast the dchar[] result to a string, (which is a char[]), it
then treats all the 0's in each dchar element as '\0', printing a blank
apparently.


This has to be one of the most obvious cases I've ever seen that phobos 
treating string as a range of dchar was the wrong decision. That one 
can't use ranges to make a new string is ridiculous. Just the thought of 
fixing this by re-encoding...


-Steve


Re: Template Declarations - Why not Template definitions?

2015-07-01 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, July 01, 2015 09:29:56 via Digitalmars-d-learn wrote:
 On Tuesday, 30 June 2015 at 21:06:58 UTC, WhatMeWorry wrote:
  Bonus question: Isn't a Zero-parameter template declaration
  pretty much worthless?

 Functions in templates get certain attributes inferred
 automatically, like `@nogc`, `pure`, `nothrow`, `@safe`. Some
 people use them for that purpose. (Because of IFTI, functions
 with empty template parameters can be called with the same syntax
 as normal functions, they don't need the `!()`.)

That and it lets you use auto ref. It also can be necessary when overloading
templated functions. It used to be that you couldn't overlooad a templated
function with a non-templated function, forcing you to have functions with
no template parameters if you wanted to have what would normally be a
non-templated function overload a templated function. That's now been fixed,
but the overload rules aren't quite the same between a non-templated
functions and a templated function with no parameters, so sometimes you
still need to templatize a function with empty parameters depending on what
you're trying to do with your function overloads.

- Jonathan M Davis



Re: how to avoid cycle detected?

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 5:09 AM, aki wrote:

Following code causes run-time error.
How can I use static this() without causing error?
It's difficult to avoid this situation because
actual code is more complex.

file main.d:
void main() {
}

file a.d:
import b;
class A {
 static this() {}
};

file b.d:
import a;
class B {
 static this() {}
};

object.Exception@src\rt\minfo.d(162): Aborting: Cycle detected between
modules with ctors/dtors:
a - b - a


You need to either factor out the static constructors to put them in a 
leaf module, replace one of them with intializers, or remove one of them.


It can be an exercise in ugly coding, but you can fix this.

I know it wasn't specifically asked, but the reason it exists is simple:

class A {
static int x;
static this() { x = B.x + 5;}
}

...

class B {
static int x;
static this() { x = A.x + 5;}
}

The runtime cannot introspect the code to detect the circular 
dependency, so it makes a conservative decision. I'm waiting on an 
introduction of RTInfo for modules [1] to allow us to mark static ctors 
as standalone, then we can probably fix this problem through a sort of 
trust the programmer mechanism.


-Steve

[1] https://issues.dlang.org/show_bug.cgi?id=10023


Re: Adam Ruppe's COM library - calling COM object from dynamic code eg VBA

2015-07-01 Thread Adam D. Ruppe via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 05:47:44 UTC, Laeeth Isharc wrote:
The COM object isn't recognised by dynamic languages such as 
Python and VBA, even after registering.


You use the regsvr32 program to do it?


Re: std.concurrent Tid vector initialization problem

2015-07-01 Thread via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 19:19:43 UTC, Charles Hixson wrote:

On Sunday, 28 June 2015 at 09:59:29 UTC, Marc Schütz wrote:

On Sunday, 28 June 2015 at 01:02:02 UTC, Charles Hixson wrote:
I'm planning an application where a series of threads each 
...gn.  Does anyone have a better idea?


(The rough estimate of the number of Tids is six, but that's 
likely to change from run to run.)


The most elegant solution I can think of is this:

struct Go { }

__gshared const Tid[] allTids;

void myfunc(...) {
receiveOnly!Go();
// do the work
}

shared static this() {
Tid[] tids;
foreach(thread; threads)
tids ~= spawn(myfunc, ...);
*cast(const(int)[]*) allTids = tids;
foreach(tid; allTids)
tid.send(Go());
}

I believe the cast is not even undefined behaviour, because 
it's not immutable, but I'm not sure. But the const-ness 
guards against accidental modification of `allTids` by a 
thread.


Alternatively, you could make `allTids` private, provide a 
public getter, and implement the threads in another module.


Or you could simply leave the global array mutable and be 
careful not to modify it.


Thanks.  That sounds similar to the approach that I had though 
of, except that you're doing it in a static this().


(I'd have answered sooner, but my D email seems to have died.  
Only the D groups are currently dead now, though my entire 
account was dead for a couple of weeks.  [ATT])


That `shared static this` isn't really necessary here. I 
originally had an immutable `allTids`, for which it was necessary.


Re: tkd - basic compilation problem

2015-07-01 Thread via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 07:37:48 UTC, Paul wrote:

On Tuesday, 30 June 2015 at 16:06:41 UTC, Marc Schütz wrote:

On Tuesday, 30 June 2015 at 15:25:27 UTC, Alex Parrill wrote:

On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote:

Using dub I get this during linking:

Building tkd-test ~master configuration application, build 
type debug.

Compiling using dmd...
Linking...
/usr/bin/ld: cannot find -ltcl
/usr/bin/ld: cannot find -ltk

...any suggestions please?


You need to install the libraries. Ex `sudo apt-get install 
libtcl8.5 libtk8.5`


Or the corresponding -dev packages.


Hmmm, I have libtcl8.6 and libtk8.6 installed already. The only 
dev packages I see are tclcl and tclap - I can't find any libtk 
-dev package.




Someone more familiar with Debian/Ubuntu than me may be able to 
help you here, sorry.


I was hoping to keep a tight rein on what was required to be 
installed to simplify deployment but its spiraling out of 
control again LOL.


The -dev packages are only required during development 
(specifically at link time), the resulting binary only needs the 
normal packages installed.


Re: Adam Ruppe's COM library - calling COM object from dynamic code eg VBA

2015-07-01 Thread Kagamin via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 09:32:23 UTC, Kagamin wrote:
I did it only for javascript, it doesn't need type library. 
First thing to do is to check whether registration succeeded. I 
prefer to register to HKCR for testing purposes.


fix HKCU


Re: Adam Ruppe's COM library - calling COM object from dynamic code eg VBA

2015-07-01 Thread Kagamin via Digitalmars-d-learn
I did it only for javascript, it doesn't need type library. First 
thing to do is to check whether registration succeeded. I prefer 
to register to HKCR for testing purposes.


Re: how to avoid cycle detected?

2015-07-01 Thread ketmar via Digitalmars-d-learn
On Wed, 01 Jul 2015 09:09:52 +, aki wrote:

 Following code causes run-time error.
 How can I use static this() without causing error?

you currently can't, sorry.

signature.asc
Description: PGP signature


Re: Static constructors guaranteed to run?

2015-07-01 Thread via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 07:55:20 UTC, ketmar wrote:

On Mon, 29 Jun 2015 17:22:17 +, Marc Schütz wrote:


On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
it doesn't, afair, but it's quite natural. if user type was 
throwed out as unused, it would be very strange to insist on 
keeping it's initialization code.


Yes, but I would instead expect that the static ctor prevents 
the type from becoming unused in the first place.


and i expect it to be thrown away. ;-) as we have module-scope 
static ctors to initialize various things that should be always 
initialized. and type static ctor -- by my logic deduction -- 
should only initialize internal type fields. and why should i 
even bother to initialize that internal fields if the type is 
not used anywhere?


The behaviour you expect makes more sense, for sure, but I was 
trying to guess what the current implementation might be doing 
without actually having to try it :-)


Re: Array operations, dynamic arrays and length

2015-07-01 Thread via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 22:37:34 UTC, ixid wrote:

int[] a = [1,1,1,1];
int[] b = [1,1,1,1];
int[] c;

c[] = a[] - b[];

c.writeln;

This outputs []. This feels wrong, it feels like something that 
should have exploded or set the length to 4. If the lengths of 
a and b are mismatched it throws an exception. It also throws 
an exception if a dynamic array is longer or a static array is 
not the same length but is happy when a dynamic array is 
shorter. Is this intended behaviour and if so why?


Yes, clearly a bug. Please open a bug report at 
https://issues.dlang.org/


Re: Nullable with reference types

2015-07-01 Thread via Digitalmars-d-learn
On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer 
wrote:

I know this is just back-of-envelope, but what's wrong with:

alias Nullable(T) if(is(T == class)) = T;

bool isNull(T)(T t) if(is(T == class)) { return t is null;}


That's what I intended. (Same for pointers and slices, BTW.)

I does however have a slightly different behaviour: In the 
current implementation, there can be instances for which `isNull` 
returns false, but whose payloads are nevertheless `null`.


Re: how to avoid cycle detected?

2015-07-01 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, July 01, 2015 09:09:52 aki via Digitalmars-d-learn wrote:
 Following code causes run-time error.
 How can I use static this() without causing error?
 It's difficult to avoid this situation because
 actual code is more complex.

 file main.d:
 void main() {
 }

 file a.d:
 import b;
 class A {
   static this() {}
 };

 file b.d:
 import a;
 class B {
   static this() {}
 };

 object.Exception@src\rt\minfo.d(162): Aborting: Cycle detected
 between modules w
 ith ctors/dtors:
 a - b - a

Modules which have static constructors (or destructors) cannot import each
other, because the runtime has no way of knowing which order they should be
run in or even if they _can_ be run in an order that guarantees that you
don't use any variables before they're initialized. So, you either need to
fix it so that your modules with static constructors aren't importing each
(even indirectly), or you need to stop using static constructors in at least
one of them.

The result of this seems to often be that you should avoid static
constructors where reasonably possible, but if your modules are independent
enough, they should be fine. They _do_ need to be fairly independent of each
other though, or you'll probably run into a problem with static constructors
and cyclical imports eventually.

- Jonathan M Davis



Concurrency in DLL

2015-07-01 Thread Chris via Digitalmars-d-learn
Would anyone know off the top of the head why a 
std.concurrency.send() message can fail in a DLL?


The DLL is loaded into Python and works (including the threading) 
when in a test program or mine and loaded via cytpes.CDLL() etc. 
However, embedded in a third party package, where it is loaded in 
the same way, the thread is never called (the DLL as such is 
loaded and available and works fine).


The thread is generated like this in the DLL:

import std.concurrency;

extern(C)
{
  export void methodCalledFromPython(const char* message)
  {
// convert message to string etc.
// now spawn thread in order to be able to return to
// main thread asap
auto dothis = spawn(doSomething, thisTid);
send(dothis, message.idup);
  }
}

// Method in same module
private void doSomething(Tid tid)
{
  receive(
   (string input)
   {
 // Do something with input
   }
  );
}

Is it to do with thisTid that conflicts with the main program 
somehow? However, in my test program it works fine. Anything I'm 
forgetting here?


Re: Nullable with reference types

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 5:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:

On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:

I know this is just back-of-envelope, but what's wrong with:

alias Nullable(T) if(is(T == class)) = T;

bool isNull(T)(T t) if(is(T == class)) { return t is null;}


That's what I intended. (Same for pointers and slices, BTW.)

I does however have a slightly different behaviour: In the current
implementation, there can be instances for which `isNull` returns false,
but whose payloads are nevertheless `null`.


I just realized this. With a Nullable!(T[]), you can have a type where:

x is null
x == null
x.isNull

all have different behavior. I'm really quite unconvinced that this has 
any good properties. I think we should fix it.


-Steve


Re: tkd - basic compilation problem

2015-07-01 Thread Paul via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 09:38:05 UTC, Marc Schütz wrote:
Someone more familiar with Debian/Ubuntu than me may be able to 
help you here, sorry.


I was hoping to keep a tight rein on what was required to be 
installed to simplify deployment but its spiraling out of 
control again LOL.


The -dev packages are only required during development 
(specifically at link time), the resulting binary only needs 
the normal packages installed.


Thanks Marc, I found the required packages... it threw me because 
they don't have any version number in the repo ... and the 
example works just fine now.


Re: Nullable with reference types

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 5:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:

On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:

I know this is just back-of-envelope, but what's wrong with:

alias Nullable(T) if(is(T == class)) = T;

bool isNull(T)(T t) if(is(T == class)) { return t is null;}


That's what I intended. (Same for pointers and slices, BTW.)

I does however have a slightly different behaviour: In the current
implementation, there can be instances for which `isNull` returns false,
but whose payloads are nevertheless `null`.


Oh. Sorry to say this, but that code is just broken. I frankly don't 
think we should concern ourselves with that use case. I wish I had paid 
more attention when this was all going down.


-Steve


Re: Pure delegate not quite pure?

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/30/15 9:29 PM, Tofu Ninja wrote:

On Wednesday, 1 July 2015 at 00:13:36 UTC, Jesse Phillips wrote:

On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:

On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer wrote:

Have you tried placing const on the function signature? i.e.:

pure int delegate() const d = () const {...

That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.



Nah, says its only available for non-static member functions.


hmm, it seems that this would be an appropriate enhancement. It
doesn't make sense on a function, but as it relates to delegates I'd
say it makes sense to allow const to be added.


const, immutable, shared, inout. Not sure if they all make sense on
delegates, but those are the options for member functions, so they might
apply to delegates as well.


immutable is probably incorrect without a cast, since immutable cannot 
be applied implicitly to non-immutable data, and if the data is all 
immutable already, no sense in tagging it immutable.


I really see use in allowing const.

inout is sketchy, I'm trying to think of how this applies, since inout 
is really for data types that are varied in their constancy. A function 
has only one addressable instance.


shared, well... I don't think we need it. Function stacks shouldn't be 
shared.


One thing you CAN do as a workaround, is put all your data to return 
into a static struct, and return delegates that address your data:


auto foo()
{
static struct Storage
{
int x = 4;
pure int dg() immutable { return x * x;} // should be strong-pure
}
immutable(Storage) s;
auto d = s.dg; // I *think* this allocates a closure, but if not, 
that's a bug.

writeln(d());
// s.x = 5; // invalid
return d;
}

Really, a delegate on a function stack is like a single-instance 
private-defined struct like written above.


-Steve


Re: Best way to count character spaces.

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 1:25 AM, H. S. Teoh via Digitalmars-d-learn wrote:

On Tue, Jun 30, 2015 at 06:33:32PM +, Taylor Hillegeist via 
Digitalmars-d-learn wrote:

So I am aware that Unicode is not simple... I have been working on a boxes
like project http://boxes.thomasjensen.com/

it basically puts a pretty border around stdin characters. like so:
  
/\   \
\_|Different all twisty a|
   |of in maze are you,   |
   |passages little.  |
   |   ___|_
\_/_/

but I find that I need to know a bit more than the length of the string
because of encoding differences

[...]

Use std.uni.byGrapheme. That's the only reliable way to count anything
remotely resembling the display length of the string, which is not to be
confused with the number of code points, which is also different from
the length of the string in bytes or the number of code units.

Note that even with byGrapheme, you may still need some post-processing,
because certain terminals may output Asian block characters in double
width, meaning that 1 grapheme takes up two columns on the screen. But
byGrapheme should get you started on the right footing.




BTW, this exercise would make an EXCELLENT blog post highlighting both 
the power of D's unicode support and the hairy issues of unicode.


I like the ascii er... unicode art concept :)

-Steve



Re: Template Declarations - Why not Template definitions?

2015-07-01 Thread via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 21:06:58 UTC, WhatMeWorry wrote:
Bonus question: Isn't a Zero-parameter template declaration 
pretty much worthless?


Functions in templates get certain attributes inferred 
automatically, like `@nogc`, `pure`, `nothrow`, `@safe`. Some 
people use them for that purpose. (Because of IFTI, functions 
with empty template parameters can be called with the same syntax 
as normal functions, they don't need the `!()`.)


Re: Static constructors guaranteed to run?

2015-07-01 Thread ketmar via Digitalmars-d-learn
On Wed, 01 Jul 2015 09:42:31 +, Marc Schütz wrote:

 The behaviour you expect makes more sense, for sure, but I was trying to
 guess what the current implementation might be doing without actually
 having to try it :-)

ah, sorry. i was talking about the ideal case with ideal compiler, not 
about current state of things. ;-)

signature.asc
Description: PGP signature


Re: Multi-dimensional fixed arrays

2015-07-01 Thread DLearner via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 22:04:24 UTC, Justin Whear wrote:



alias IntList = int[10];
IntList[3] myIntLists;
int[10][3] myOtherIntLists; // same type as above


I understand the rationale, but some issues:

1.  The rationale implicitly takes treats an n-dim array as a 
(n-1)-dim array x (1)-dim array.


Are we sure this is correct: FWIW, I think an n-dim array is just 
a set of n-tuple indexes each mapping 1-1 to array elements.

And no more structure than that.

So, although the order of the indexes is important (otherwise we 
find the wrong element), no subset of tuples (perhaps generated 
by holding one or more indexes constant) is more important than 
any other.


2. I _thought_  it was design goal of D that a valid C program, 
if it compiles under D at all, produces the same output.


That cannot be true if array index order altered.

3. Obscurity: Someone faced with the array definition 'int[a][b] 
foo;'
is going to instinctively think that the instruction 'bar = 
foo[x][y];'

means that, potentially, 0 = x  a and 0= y  b.
(Which is why if the current design is fixed, I suggested using 
() instead of [] as an alternate which does match access order to 
definition order)


Though, in the case of 3., (and really a different question),
there is case for a compiler option making valid range 1 = x = 
a and 1= y = b,

as off-by-one error is commonplace bug in C.


Re: Adam Ruppe's COM library - calling COM object from dynamic code eg VBA

2015-07-01 Thread Laeeth Isharc via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 13:43:08 UTC, Adam D. Ruppe wrote:

On Wednesday, 1 July 2015 at 05:47:44 UTC, Laeeth Isharc wrote:
The COM object isn't recognised by dynamic languages such as 
Python and VBA, even after registering.


You use the regsvr32 program to do it?


Yes...


Re: tkd - basic compilation problem

2015-07-01 Thread Paul via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 17:43:11 UTC, Gary Willoughby wrote:

On Tuesday, 30 June 2015 at 12:58:21 UTC, Paul wrote:

...


I really don't understand posts like this when literally all 
information needed is in the README file:


https://github.com/nomad-software/tkd

Just read RTFM.


I read that before posting, specifically the parts that say:

Tkd requires version 8.6 (or greater) of the Tcl/Tk libraries 
installed. A small exception is when creating a self-contained 
installation on Windows. See details below. Tcl/Tk itself 
requires the x11 libraries installed on Linux only.


and

On Linux and Mac OSX things are a little easier as both 
operating systems have Tcl/Tk installed by default. If however 
they do not have the latest version, the libraries can be updated 
via their respective package managers. The linked libraries are 
libtcl and libtk.


I can't see how they answer the questions I've asked (which 
admittedly are more related to the distro that D per se).






Re: tkd - basic compilation problem

2015-07-01 Thread Paul via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 18:38:27 UTC, Jordi Sayol wrote:


For shared linking against libphobos2.so and libtkd.so:
$ dmd `pkg-config --cflags --libs tkd` 
-J/usr/share/libtkd-doc/example/media/ 
/usr/share/libtkd-doc/example/example.d


For static linking against libphobos2.a and libtkd.a:
$ dmd `pkg-config --cflags --libs tkd-static` 
-J/usr/share/libtkd-doc/example/media/ 
/usr/share/libtkd-doc/example/example.d



Thank you Jordi, I've got everything installed ok now but those 
linking instructions might come in very handy!


Re: goroutines vs vibe.d tasks

2015-07-01 Thread rsw0x via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 18:09:19 UTC, Mathias Lang wrote:

On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:

[...]


In your dub.json, can you use the following:

subConfigurations: {
vibe-d: libasync
},
dependencies: {
vibe-d: ~0.7.24-beta.3
},


Turns out it makes it much faster on my machine (371ms vs 
1474ms). I guess it could be a good thing to investigate if we 
can make it the default in 0.7.25.


submit an issue on vibe.d's github, they'd probably like to know 
about this.


Re: wrong struct alignment

2015-07-01 Thread Adam D. Ruppe via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 20:01:08 UTC, dd0s wrote:

intscope_id; // 4
short  port; // 8 // -- this is 4 bytes instead of 2


That's expected because scope_id takes 4 bytes, so port has to be 
at 8 so it doesn't overlap the preceding int.



The extra two bytes you see in sizeof are probably at the *end* 
of the struct, not between the members.


To get rid of them, out align(2) on the outside too:

align(2)
struct yourthing {
  align(2):
members
}


That will trim the size. The align inside the struct packs the 
members, but still pads the end (which means an array of these 
structs will be aligned on the word boundary). The align on the 
outside removes the padding at the end, meaning an an array of 
the structs would be packed too.


wrong struct alignment

2015-07-01 Thread dd0s via Digitalmars-d-learn

i have the following struct, and i expect it to have 30 bytes
but sizeof tells me it has 32 bytes. dmd seems to still use 4byte 
alignment altough i specified to align 2bytes.


struct netadr_t {
align(2):
inttype; // 0
intscope_id; // 4
short  port; // 8 // -- this is 4 bytes instead of 2
intsock;   // 10

union {
ubyte[4]ip; // 14
ubyte[10] ipx;
ubyte[16] ip6;
}
}

since i'm interfacing with a c library the struct layout has to 
be equal :(




Re: wrong struct alignment

2015-07-01 Thread anonymous via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 20:01:08 UTC, dd0s wrote:

i have the following struct, and i expect it to have 30 bytes
but sizeof tells me it has 32 bytes. dmd seems to still use 
4byte alignment altough i specified to align 2bytes.


struct netadr_t {
align(2):
inttype; // 0
intscope_id; // 4
short  port; // 8 // -- this is 4 bytes instead of 2
intsock;   // 10

union {
ubyte[4]ip; // 14
ubyte[10] ipx;
ubyte[16] ip6;
}
}

since i'm interfacing with a c library the struct layout has to 
be equal :(


Disclaimer: My understanding of all things alignment is limited.

`pragma(msg, netadr_t.sock.offsetof);` prints 10LU, so port 
seems to really only take 2 bytes. The struct itself has padding 
at the end. You can eliminate that with an `align(1)` on the 
struct:


align(1) struct netadr_t {
align(2):
...
}



Re: Array operations, dynamic arrays and length

2015-07-01 Thread Alex Parrill via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 22:37:34 UTC, ixid wrote:

int[] a = [1,1,1,1];
int[] b = [1,1,1,1];
int[] c;

c[] = a[] - b[];

c.writeln;

This outputs []. This feels wrong, it feels like something that 
should have exploded or set the length to 4. If the lengths of 
a and b are mismatched it throws an exception. It also throws 
an exception if a dynamic array is longer or a static array is 
not the same length but is happy when a dynamic array is 
shorter. Is this intended behaviour and if so why?


I don't think this is a bug.

Since you don't initialize `c` to anything, it defaults to an 
empty slice. Array [] operations apply to each element of a 
slice, but `c` doesn't have any elements, so it does nothing.


Change `int[] c;` to `int[] c = new int[4];` and it works.


Re: Nullable with reference types

2015-07-01 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, July 01, 2015 08:43:59 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
 On 7/1/15 5:45 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
  On Tuesday, 30 June 2015 at 18:29:31 UTC, Steven Schveighoffer wrote:
  I know this is just back-of-envelope, but what's wrong with:
 
  alias Nullable(T) if(is(T == class)) = T;
 
  bool isNull(T)(T t) if(is(T == class)) { return t is null;}
 
  That's what I intended. (Same for pointers and slices, BTW.)
 
  I does however have a slightly different behaviour: In the current
  implementation, there can be instances for which `isNull` returns false,
  but whose payloads are nevertheless `null`.

 I just realized this. With a Nullable!(T[]), you can have a type where:

 x is null
 x == null
 x.isNull

 all have different behavior. I'm really quite unconvinced that this has
 any good properties. I think we should fix it.

It most definitely is _not_ good practice, and I would be fine with fixing
it, but at the same time, I could see someone screaming about code breakage,
though most likely, they'd simply end up triggering bugs in their code that
were hidden by the current behavior.

- Jonathan M Davis



Re: Pure delegate not quite pure?

2015-07-01 Thread Tofu Ninja via Digitalmars-d-learn
On Wednesday, 1 July 2015 at 12:34:35 UTC, Steven Schveighoffer 
wrote:
immutable is probably incorrect without a cast, since immutable 
cannot be applied implicitly to non-immutable data, and if the 
data is all immutable already, no sense in tagging it immutable.


I really see use in allowing const.

inout is sketchy, I'm trying to think of how this applies, 
since inout is really for data types that are varied in their 
constancy. A function has only one addressable instance.


shared, well... I don't think we need it. Function stacks 
shouldn't be shared.


One thing you CAN do as a workaround, is put all your data to 
return into a static struct, and return delegates that address 
your data:


auto foo()
{
static struct Storage
{
int x = 4;
pure int dg() immutable { return x * x;} // should be 
strong-pure

}
immutable(Storage) s;
auto d = s.dg; // I *think* this allocates a closure, but 
if not, that's a bug.

writeln(d());
// s.x = 5; // invalid
return d;
}

Really, a delegate on a function stack is like a 
single-instance private-defined struct like written above.


-Steve


The benefit of tagging it immutable would be to require the 
delegate to always have an immutable context, for instance, I am 
accepting a delegate as an argument to a function, but currently 
right now I have no way to guarantee that the context i receive 
is immutable. If it was marked immutable, then the supplier of 
the delegate would be forced to use only immutable things in the 
context. That's the primary benefit I see.


ie: void doSomethingWithDelegate(int delegate() pure @nogc @safe 
nothrow immutable del)


That actually compiles, but it will only accept delegates to 
member functions. ._.


I dont really know enough about shared and inout to comment on if 
they could be useful, I only mentioned them because you can put 
them on member functions.




Re: Array operations, dynamic arrays and length

2015-07-01 Thread via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 19:09:36 UTC, Alex Parrill wrote:

I don't think this is a bug.

Since you don't initialize `c` to anything, it defaults to an 
empty slice. Array [] operations apply to each element of a 
slice, but `c` doesn't have any elements, so it does nothing.


I _do_ think it's a bug. Compare:

import std.stdio;

void main() {
int[] a = [1,1,1,1];
int[] b = [1,1,1,1];
int[] c;
int[2] d;

c[] = a[] - b[];  // works
c.writeln;// []
d[] = a[] - b[];  // works
d.writeln;// [0, 0]
d[] = a[];// throws!
// object.Error@(0): Array lengths don't match for copy: 
4 != 2

}

So, in the case of subtraction, it assigns only as many elements 
as the destination has, but for direct assignment, it throws an 
error. This is clearly inconsistent.


Re: wrong struct alignment

2015-07-01 Thread dd0s via Digitalmars-d-learn

thank you both, indeed missed that truncation step


Re: Same process to different results?

2015-07-01 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jul 01, 2015 at 02:14:49PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
 On 7/1/15 1:44 PM, Steven Schveighoffer wrote:
 
 Schizophrenia of Phobos.
 
 Phobos thinks a string is a range of dchar instead of a range of
 char.  So what cycle, take, and array all output are dchar ranges and
 arrays.
 
 When you cast the dchar[] result to a string, (which is a char[]), it
 then treats all the 0's in each dchar element as '\0', printing a
 blank apparently.
 
 This has to be one of the most obvious cases I've ever seen that
 phobos treating string as a range of dchar was the wrong decision.
 That one can't use ranges to make a new string is ridiculous. Just the
 thought of fixing this by re-encoding...
[...]

Yeah, although Andrei has vetoed all suggestions of getting rid of
autodecoding, this is one of the glaring cases where it's obviously a
bad idea.

It almost makes me want to create my own custom string type that serves
up char instead of dchar.


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.


Same process to different results?

2015-07-01 Thread Taylor Hillegeist via Digitalmars-d-learn

When I run the code (compiled on DMD 2.067.1):


--
import std.algorithm;
import std.stdio;
import std.range;

string A=AaA;
string B=BbBb;
string C=CcCcC;

void main(){
int L=25;

  int seg1len=(L-B.length)/2;
  int seg2len=B.length;
  int seg3len=L-seg1len-seg2len;

  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array).writeln;

  string q = cast(string)
  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array);

  q.writeln;

}
---

I get a weird result of
AaAAaAAaAABbBbCcCcCCcCcCC
A   a   A   A   a   A   A   a   A   A   B   b   B   b   C   c   C 
  c   C   C   c   C   c   C   C


Any ideas why?




Re: Same process to different results?

2015-07-01 Thread Taylor Hillegeist via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 17:06:01 UTC, Adam D. Ruppe wrote:
I betcha it is because A, B, and C are modified by the first 
pass. A lot of the range functions consume their input.


Running them one at a time produces the same result.

for some reason:

  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array).writeln;

is different from:

  string q = cast(string)
  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array);
  q.writeln;

I was wondering if it might be the cast?


Re: Same process to different results?

2015-07-01 Thread Steven Schveighoffer via Digitalmars-d-learn

On 7/1/15 1:00 PM, Taylor Hillegeist wrote:

When I run the code (compiled on DMD 2.067.1):


--
import std.algorithm;
import std.stdio;
import std.range;

string A=AaA;
string B=BbBb;
string C=CcCcC;

void main(){
 int L=25;

   int seg1len=(L-B.length)/2;
   int seg2len=B.length;
   int seg3len=L-seg1len-seg2len;

   (A.cycle.take(seg1len).array
   ~B.cycle.take(seg2len).array
   ~C.cycle.take(seg3len).array).writeln;

   string q = cast(string)
   (A.cycle.take(seg1len).array
   ~B.cycle.take(seg2len).array
   ~C.cycle.take(seg3len).array);

   q.writeln;

}
---

I get a weird result of
AaAAaAAaAABbBbCcCcCCcCcCC
A   a   A   A   a   A   A   a   A   A   B   b   B   b   C   c   C   c
C   C   c   C   c   C   C

Any ideas why?


Schizophrenia of Phobos.

Phobos thinks a string is a range of dchar instead of a range of char. 
So what cycle, take, and array all output are dchar ranges and arrays.


When you cast the dchar[] result to a string, (which is a char[]), it 
then treats all the 0's in each dchar element as '\0', printing a blank 
apparently.


-Steve


Re: Same process to different results?

2015-07-01 Thread anonymous via Digitalmars-d-learn
On Wednesday, 1 July 2015 at 17:13:03 UTC, Taylor Hillegeist 
wrote:

  string q = cast(string)
  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array);
  q.writeln;

I was wondering if it might be the cast?


Yes, the cast is wrong. You're reinterpreting (not converting) an 
array of `dchar`s (UTF-32 code units) as an array of `char`s 
(UTF-8 code units).


If you print the numeric values of the string, e.g. via 
std.string.representation, you can see that every actual 
character has three null bytes following it:


import std.string: representation;
writeln(q.representation);

[65, 0, 0, 0, 97, 0, 0, 0, 65, 0, 0, 0, 65, 0, 0, 0, 97, 0, 0, 0, 
65, 0, 0, 0, 65, 0, 0, 0, 97, 0, 0, 0, 65, 0, 0, 0, 65, 0, 0, 0, 
66, 0, 0, 0, 98, 0, 0, 0, 66, 0, 0, 0, 98, 0, 0, 0, 67, 0, 0, 0, 
99, 0, 0, 0, 67, 0, 0, 0, 99, 0, 0, 0, 67, 0, 0, 0, 67, 0, 0, 0, 
99, 0, 0, 0, 67, 0, 0, 0, 99, 0, 0, 0, 67, 0, 0, 0, 67, 0, 0, 0]



Use std.conv.to for less surprising conversions. And don't use 
casts unless you know exactly what you're doing.


Re: tkd - basic compilation problem

2015-07-01 Thread Gary Willoughby via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 12:58:21 UTC, Paul wrote:

...


I really don't understand posts like this when literally all 
information needed is in the README file:


https://github.com/nomad-software/tkd

Just read RTFM.


Re: Same process to different results?

2015-07-01 Thread Taylor Hillegeist via Digitalmars-d-learn
On Wednesday, 1 July 2015 at 17:00:51 UTC, Taylor Hillegeist 
wrote:

When I run the code (compiled on DMD 2.067.1):


--
import std.algorithm;
import std.stdio;
import std.range;

string A=AaA;
string B=BbBb;
string C=CcCcC;

void main(){
int L=25;

  int seg1len=(L-B.length)/2;
  int seg2len=B.length;
  int seg3len=L-seg1len-seg2len;

  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array).writeln;

  string q = cast(string)
  (A.cycle.take(seg1len).array
  ~B.cycle.take(seg2len).array
  ~C.cycle.take(seg3len).array);

  q.writeln;

}
---

I get a weird result of
AaAAaAAaAABbBbCcCcCCcCcCC
A   a   A   A   a   A   A   a   A   A   B   b   B   b   C   c   
C

  c   C   C   c   C   c   C   C

Any ideas why?


Some way or another the type was converted to a dchar[]
during this process:

 A.cycle.take(seg1len).array
~B.cycle.take(seg2len).array
~C.cycle.take(seg3len).array

Why would it change the type so sneaky like?... Except for maybe 
its the default behavior with string due to 32bits = (typically 
one grapheme)?

I bet cycle did this.


Re: tkd - basic compilation problem

2015-07-01 Thread Paul via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 16:06:41 UTC, Marc Schütz wrote:

On Tuesday, 30 June 2015 at 15:25:27 UTC, Alex Parrill wrote:

On Tuesday, 30 June 2015 at 14:28:49 UTC, Paul wrote:

Using dub I get this during linking:

Building tkd-test ~master configuration application, build 
type debug.

Compiling using dmd...
Linking...
/usr/bin/ld: cannot find -ltcl
/usr/bin/ld: cannot find -ltk

...any suggestions please?


You need to install the libraries. Ex `sudo apt-get install 
libtcl8.5 libtk8.5`


Or the corresponding -dev packages.


Hmmm, I have libtcl8.6 and libtk8.6 installed already. The only 
dev packages I see are tclcl and tclap - I can't find any libtk 
-dev package.


I was hoping to keep a tight rein on what was required to be 
installed to simplify deployment but its spiraling out of control 
again LOL.


Re: Packing enums

2015-07-01 Thread ketmar via Digitalmars-d-learn

On Monday, 29 June 2015 at 22:05:47 UTC, qznc wrote:


Something like this:

enum X { A, B, C };
enum Y { foo, bar, baz };
alias both = TwoEnums!(X,Y);
static assert(both.sizeof == 1);
both z;
z.X = B;
z.Y = bar;


that's so easy that it's not even funny...

enum X { A, B, C };
enum Y { foo, bar, baz };


align(1) struct TwoEnums(E0, E1) if (is(E0 == enum)  is(E1 == 
enum)) {

  private import std.string : format;
  static assert(E0.min = 0  E1.min = 0  E0.max  256  
E1.max  256  E0.max+E1.max  256, enums can't be packed);
  static assert(E0.max  0  E1.max  0, can't pack dummy 
enums);

align(1):
  ubyte v_;
  template opDispatch(string mt) {
static if (mt == E0.stringof) {
  @property E0 implE0 () { return cast(E0)(v_%E0.max); }
  @property void implE0 (E0 nv) { v_ = 
cast(ubyte)((v_/E0.max)*E0.max+cast(ubyte)nv); }

  alias opDispatch = implE0;
} else static if (mt == E1.stringof) {
  @property E1 implE1 () { return cast(E1)(v_/E0.max); }
  @property void implE1 (E1 nv) { v_ = 
cast(ubyte)((v_%E0.max)+cast(ubyte)nv*E0.max); }

  alias opDispatch = implE1;
} else {
  static assert(0);
}
  }
}

alias both = TwoEnums!(X, Y);
static assert(both.sizeof == 1);

void main () {
  import std.stdio;
  both z;
  writeln(z.X,  ; , z.Y, ; v_=, z.v_); // A ; foo; v_=0

  z.X = X.B;
  writeln(z.X,  ; , z.Y, ; v_=, z.v_); // B ; foo; v_=1

  z.Y = Y.bar;
  writeln(z.X,  ; , z.Y, ; v_=, z.v_); // B ; bar; v_=3
}


Re: is it safe to call `GC.removeRange` in dtor?

2015-07-01 Thread ketmar via Digitalmars-d-learn
thank you both. then i think that it should be explicitly stated 
in core.memory.


Re: goroutines vs vibe.d tasks

2015-07-01 Thread Daniel Kozák via Digitalmars-d-learn

Same problem still extreamly slow

On Wed, 01 Jul 2015 03:28:01 +
rsw0x anonym...@anonymous.com wrote:

 On Tuesday, 30 June 2015 at 15:18:36 UTC, Jack Applegame wrote:
  Just creating a bunch (10k) of sleeping (for 100 msecs) 
  goroutines/tasks.
 
  Compilers
  go: go version go1.4.2 linux/amd64
  vibe.d: DMD64 D Compiler v2.067.1 linux/amd64, vibe.d 0.7.23
 
  Code
  go: http://pastebin.com/2zBnGBpt
  vibe.d: http://pastebin.com/JkpwSe47
 
  go version build with go build test.go
  vibe.d version built with dub build --build=release test.d
 
  Results on my machine:
 
  go: 168.736462ms (overhead ~ 68ms)
  vibe.d: 1944ms   (overhead ~ 1844ms)
 
  Why creating of vibe.d tasks is so slow (more then 10 times)???
 
 how do they compare if you replace the sleep with yield?



Re: Static constructors guaranteed to run?

2015-07-01 Thread ketmar via Digitalmars-d-learn
On Mon, 29 Jun 2015 17:22:17 +, Marc Schütz wrote:

 On Monday, 29 June 2015 at 11:36:42 UTC, ketmar wrote:
 it doesn't, afair, but it's quite natural. if user type was throwed out
 as unused, it would be very strange to insist on keeping it's
 initialization code.
 
 Yes, but I would instead expect that the static ctor prevents the type
 from becoming unused in the first place.

and i expect it to be thrown away. ;-) as we have module-scope static 
ctors to initialize various things that should be always initialized. and 
type static ctor -- by my logic deduction -- should only initialize 
internal type fields. and why should i even bother to initialize that 
internal fields if the type is not used anywhere?

signature.asc
Description: PGP signature


etc.c.zlib help

2015-07-01 Thread Matthew Gamble via Digitalmars-d-learn
I am trying to make the transition from C++ to D. I've hit a snag 
with the etc.c.zlib module where any attempt to use this module 
to open a file yields an error:

Error 42: Symbol Undefined __lseeki64.

Here is a simple example of code that gives the error upon 
compilation.


import std.stdio;
import etc.c.zlib;

void main(string[] args)
{
	char[] fName = C:\\Users\\Matthew 
Gamble\\Documents\\sample.bam\0.dup;

char[] mode =r\0.dup;
gzFile bamFile; //no error here
	bamFile = gzopen(fName[0],mode[0]); //this is where the error 
hits

}

I'm using DMD32 D Compiler v2.067.1 on a windows 8 64 bit 
machine. Working from either Visual D in Visual Studio 2013 
Community and Coedit as IDEs gives the error. I'm probably doing 
something obviously wrong, so have mercy. If etc.c.zlib is not 
the preferred way to read from a binary gzipped file any advice 
would be appreciated. Thanks.




Re: how to avoid cycle detected?

2015-07-01 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, July 01, 2015 08:52:38 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
 The runtime cannot introspect the code to detect the circular
 dependency, so it makes a conservative decision. I'm waiting on an
 introduction of RTInfo for modules [1] to allow us to mark static ctors
 as standalone, then we can probably fix this problem through a sort of
 trust the programmer mechanism.

I wouldn't mind that, but Walter shot that idea down previously when I was
arguing for adding a way to the language to tell the compiler that a static
constructor didn't depend on anything else. He didn't want a trust the
programmer mechanism in this case. I don't remember what his arguments were
though.

- Jonathan M Davis


Re: proper way to calculate toHash() for string

2015-07-01 Thread aki via Digitalmars-d-learn

On Tuesday, 30 June 2015 at 19:36:24 UTC, Jacob Carlborg wrote:

On 30/06/15 16:19, aki wrote:


Please suggest me if anyone have an idea.


You can use TypeInfo.getHash [1] to get the hash of a given 
value. Something like:


string a = foo;
typeid(a).getHash(a)

[1] http://dlang.org/phobos/object.html#.TypeInfo.getHash


Wow, this is what I was looking for.
It's generic way. Thank you for good suggestion.
Your 2 lines code is also a good explanation for the
manual of getHash. Because it's not obvious what is
the argument for the getHash.



Re: Array operations, dynamic arrays and length

2015-07-01 Thread J Miller via Digitalmars-d-learn

On Wednesday, 1 July 2015 at 21:15:13 UTC, Marc Schütz wrote:

On Wednesday, 1 July 2015 at 19:09:36 UTC, Alex Parrill wrote:

I don't think this is a bug.

Since you don't initialize `c` to anything, it defaults to an 
empty slice. Array [] operations apply to each element of a 
slice, but `c` doesn't have any elements, so it does nothing.


I _do_ think it's a bug. Compare:

import std.stdio;

void main() {
int[] a = [1,1,1,1];
int[] b = [1,1,1,1];
int[] c;
int[2] d;

c[] = a[] - b[];  // works
c.writeln;// []
d[] = a[] - b[];  // works
d.writeln;// [0, 0]
d[] = a[];// throws!
// object.Error@(0): Array lengths don't match for 
copy: 4 != 2

}

So, in the case of subtraction, it assigns only as many 
elements as the destination has, but for direct assignment, it 
throws an error. This is clearly inconsistent.


Bug. c[] = a[] op b[] produces [] for operators - and 
/, but object.Error@(0): Array lengths don't match for vector 
operation: 0 != 4 for operators + and *. Wat.


Oh, and to make things really confusing, auto e = a[] - b[] and 
int[] e = a[] - b[] both cause Error: array operation a[] - 
b[] without destination memory not allowed.


Using dmd 2.067.0.