Re: Official compiler

[Jonathan M Davis via Digitalmars-d]

On Friday, 26 February 2016 at 06:19:27 UTC, Walter Bright wrote:
I wish LLVM would switch to the Boost license, in particular 
removing this clause:


"Redistributions in binary form must reproduce the above 
copyright notice, this list of conditions and the following 
disclaimers in the documentation and/or other materials 
provided with the distribution."


Reading it adversely means if I write a simple utility and 
include a few lines from LLVM, I have to include that license 
in the binary and a means to print it out. If I include a bit 
of code from several places, each with their own version of 
that license, there's just a bunch of crap to deal with to be 
in compliance.


That's why I tend to encourage folks to use the Boost license 
rather than the BSD license when it comes up (LLVM isn't 
BSD-licensed, but its license is very similar). While source 
attribution makes sense, I just don't want to deal with binary 
attribution in anything I write. It does make some sense when you 
don't want someone to be able to claim that they didn't use your 
code (even if you're not looking to require that they open 
everything up like the GPL does), but for the most part, I just 
don't think that that's worth it - though it is kind of cool that 
some commercial stuff (like the PS4) is using BSD-licensed code, 
and we know it, because they're forced to give attribution with 
their binaries.


- Jonathan M Davis

Re: dub: how to reference a compiled package

[asdf via Digitalmars-d-learn]

On Friday, 26 February 2016 at 04:03:15 UTC, BBasile wrote:

e.g the DMD equivalent for the two previous example is

DMD "sourceThis.d" "folder/interface.di" "folder/binary.a" 
-ofbin/thesoft


You can mix unlinked binaries and text-editor source files on 
commandline? Didn't know that when I tried this. 
http://imgur.com/AIgZGmW I ought to try these interface *.di 
files.


Just tried `ldc2 -H ` but it wouldn't do a C file 
also.

Re: dub: how to reference a compiled package

[Mike Parker via Digitalmars-d-learn]

On Friday, 26 February 2016 at 04:03:15 UTC, BBasile wrote:



The D interface file must be specified to DUB using

"sourceFiles" : ["folder/interface.di"],

either in a config or in the globals.

The binary, so either a .lib | .a or .obj | .o must be 
specified to DUB using


"DFlags" : ["folder/binary.a"],

Here again also accepted in a config or the globals.

This is because DUB doesn't consider such binary as source file 
but DMD or LDMD2 will accept them as source in the command line.


e.g the DMD equivalent for the two previous example is

DMD "sourceThis.d" "folder/interface.di" "folder/binary.a" 
-ofbin/thesoft


Why? As long as the interface file is on the import path, it 
shouldn't need to be passed along to DMD. When you import 
foo.bar, the compiler will look for both foo/bar.di and foo/bar.d.

Re: dub: how to reference a compiled package

[Mike Parker via Digitalmars-d-learn]

On Friday, 26 February 2016 at 03:19:26 UTC, mahdi wrote:


Great! Thanks.

I was looking for a feature like `jar` files in Java or 
`assemblies` in C# where all compiled code and metadata/symbols 
are stored together inside a single binary file.


I think same can be implemented for D language and it won't 
break any code because it is not touching the language itself, 
but the compiler.


The magic in Java isn't from Jar files, but from the fact that 
class binaries are distributed as byte code. All of the 
information from the source is still there. The compiler can 
learn everything it needs to know about imported classes simply 
by reading the byte code instead of the source.


In the model that D uses, I don't know enough about object file 
formats to know how much information would still be available if 
they were used at compile time, but I'm fairly certain it 
wouldn't allow the use of templates. There was a project several 
years ago that allowed loading D classes dynamically from object 
files, but I suspect if it were practical to use object files at 
compile time in the same way Java class files are used, someone 
would have implemented such a thing already (in C and C++ as 
well).


That said, it might be an interesting enhancement for the 
compiler to support reading source or interface files from zip 
archives (which is I know is what you're getting at), allowing 
the required imports and the binary to be located in one place so 
that only a single path need be passed on the command line to 
find everything.

[Issue 15721] free error when calling Mallocator.dispose on interfaces

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

Summary|std.experimental.allocator  |free error when calling
   |dispose on interface|Mallocator.dispose on
   ||interfaces

--

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/18/2016 1:30 PM, Jonathan M Davis wrote:

It's not a strawman. Walter has state previously that he's explicitly avoided
looking at the source code for other compilers like gcc, because he doesn't want
anyone to be able to accuse him of stealing code, copyright infringement, etc.
Now, that's obviously much more of a risk with gcc than llvm given their
respective licenses, but it is a position that Walter has taken when the issue
has come up, and it's not something that I'm making up.

Now, if Walter were willing to give up on the dmd backend entirely, then
presumably, that wouldn't be a problem anymore regardless of license issues, but
he still has dmc, which uses the same backend, so I very much doubt that that's
going to happen.


It's still an issue I worry about. I've been (falsely) accused of stealing code 
in the past, even once accused of having stolen the old Datalight C compiler 
from some BYU students. Once a game company stole Empire, and then had the 
astonishing nerve to sic their lawyers on me accusing me of stealing it from 
them! (Showing them my registered copyright of the source code that predated 
their claim by 10 years was entertaining.)


More recently this came up in the Tango/Phobos rift, as some of the long term 
members here will recall.


So it is not an issue to be taken too lightly. I have the scars to prove it :-/

One thing I adore about github is it provides a legal audit trail of where the 
code came from. While that proves nothing about whether contributions are stolen 
or not, it provides a date stamp (like my registered copyright did), and if 
stolen code does make its way into the code base, it can be precisely excised. 
Github takes a great load off my mind.


There are other reasons to have dmd's back end. One obvious one is we wouldn't 
have had a Win64 port without it. And anytime we wish to experiment with 
something new in code generation, it's a heluva lot easier to do that with dmd 
than with the monumental code bases of gcc and llvm.


One thing that has changed a lot in my attitudes is I no longer worry about 
people stealing my code. If someone can make good use of my stuff, have at it. 
Boost license FTW!


I wish LLVM would switch to the Boost license, in particular removing this 
clause:

"Redistributions in binary form must reproduce the above copyright notice, this 
list of conditions and the following disclaimers in the documentation and/or 
other materials provided with the distribution."


Reading it adversely means if I write a simple utility and include a few lines 
from LLVM, I have to include that license in the binary and a means to print it 
out. If I include a bit of code from several places, each with their own version 
of that license, there's just a bunch of crap to deal with to be in compliance.

Re: no size yet for forward reference error

[Walter Bright via Digitalmars-d]

On 2/25/2016 9:07 PM, Erik Smith wrote:

Good to know that it's a bug - Thanks for the help.   I've created an issue to
track this:

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



Thanks for preparing the bug report.

You can probably work around the problem for the time being by making one of the 
mutually referencing structs a class.

[Issue 15721] std.experimental.allocator dispose on interface

[via Digitalmars-d-bugs]

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

--- Comment #2 from b2.t...@gmx.com ---
I think this is safe to change dispose to:

void dispose(A, T)(auto ref A alloc, T p)
if (is(T == class) || is(T == interface))
{
if (!p) return;
auto support = (cast(void*) cast(Object) p)[0 .. typeid(p).init.length];
destroy(p);
alloc.deallocate(support);
}
deallocate doesn't care about the the length of initial static layout of a
class.

--

[Issue 15721] std.experimental.allocator dispose on interface

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

  Component|installer   |phobos
   Hardware|x86_64  |All
 OS|Windows |All
   Severity|enhancement |normal

--

Minimise and collect by GC when OutOfMemory

[tcak via Digitalmars-d-learn]

Would it be a good idea to call "collect" and "minimize" methods 
of core.memory.GC when OutOfMemory error is received FOR A LONG 
RUNNING PROGRAM? or there won't be any benefit of that?


Example program: A web server that allocates and releases memory 
from heap continuously.

[Issue 15721] std.experimental.allocator dispose on interface

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #1 from b2.t...@gmx.com ---
GCAllocator is supported but Mallocator produces a free error:


import std.experimental.allocator.mallocator;
import std.experimental.allocator.gc_allocator;
import std.experimental.allocator;

interface Foo {}
class Bar: Foo {}

void main()
{
GCAllocator.instance.dispose(cast(Foo) GCAllocator.instance.make!Bar);
// comment the following line: OK
Mallocator.instance.dispose(cast(Foo) Mallocator.instance.make!Bar);
}
--

[Issue 15726] forward reference error for circular classes, RefCounted

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Severity|major   |regression

--

[Issue 15684] secure wiki formatting

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||xemail...@yahoo.co.uk

--- Comment #3 from b2.t...@gmx.com ---
*** Issue 15725 has been marked as a duplicate of this issue. ***

--

Re: no size yet for forward reference error

[Erik Smith via Digitalmars-d]

Good to know that it's a bug - Thanks for the help.   I've 
created an issue to track this:


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

Re: all functions that have a first arg of type T

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 26 February 2016 at 04:21:15 UTC, BBasile wrote:

On Friday, 26 February 2016 at 04:19:29 UTC, BBasile wrote:

static if (__traits(isStaticFunction,typeof(m2)))

static if (__traits(isStaticFunction, __traits(getMember, 
vulkan_input, m2


Sorry don't copy paste like this there's a superfluous right 
paren.


static if (__traits(isStaticFunction, __traits(getMember, 
vulkan_input, m2)))


thanks

Nic

Re: all functions that have a first arg of type T

[BBasile via Digitalmars-d-learn]

On Friday, 26 February 2016 at 04:19:29 UTC, BBasile wrote:

static if (__traits(isStaticFunction,typeof(m2)))

static if (__traits(isStaticFunction, __traits(getMember, 
vulkan_input, m2


Sorry don't copy paste like this there's a superfluous right 
paren.


static if (__traits(isStaticFunction, __traits(getMember, 
vulkan_input, m2)))

Re: all functions that have a first arg of type T

[BBasile via Digitalmars-d-learn]

On Friday, 26 February 2016 at 03:57:25 UTC, Nicholas Wilson 
wrote:

foreach(m; __traits(allMembers, vulkan_input))
{
static if (m.endsWith("_T"))
{
foreach(m2; __traits(allMembers, vulkan_input))
{
 static if 
(__traits(isStaticFunction,typeof(m2)))// <- what here?

 {
 enum fn = __traits(getMember,vulkan_input, m2);
 enum parameters = Parameters!(fn);
 static if (parameters[0] == m)
 writeln( m, ":",m2);
 }
}
}
}


static if (__traits(isStaticFunction,typeof(m2)))

static if (__traits(isStaticFunction, __traits(getMember, 
vulkan_input, m2

Re: dub: how to reference a compiled package

[BBasile via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 12:15:42 UTC, mahdi wrote:

Hi,

Suppose I have a package `mypack` in `~/mypack`. I run `dub` 
command on this package and have the compiled `mypack` file (OS 
is Linux).


Now I am working on my project. I know how to use the 
source-code of `mypack` package in the project but what if I 
only have the compiled binary? How can I reference and use the 
modules of the compiled `mypack`?


(I looked into the DUB homepage and it's Getting Started page 
but could not find anything).


As you've been told previous you need a D interface file. But 
additionally:


The D interface file must be specified to DUB using

"sourceFiles" : ["folder/interface.di"],

either in a config or in the globals.

The binary, so either a .lib | .a or .obj | .o must be specified 
to DUB using


"DFlags" : ["folder/binary.a"],

Here again also accepted in a config or the globals.

This is because DUB doesn't consider such binary as source file 
but DMD or LDMD2 will accept them as source in the command line.


e.g the DMD equivalent for the two previous example is

DMD "sourceThis.d" "folder/interface.di" "folder/binary.a" 
-ofbin/thesoft

all functions that have a first arg of type T

[Nicholas Wilson via Digitalmars-d-learn]

foreach(m; __traits(allMembers, vulkan_input))
{
static if (m.endsWith("_T"))
{
foreach(m2; __traits(allMembers, vulkan_input))
{
 static if (__traits(isStaticFunction,typeof(m2)))// 
<- what here?

 {
 enum fn = __traits(getMember,vulkan_input, m2);
 enum parameters = Parameters!(fn);
 static if (parameters[0] == m)
 writeln( m, ":",m2);
 }
}
}
}
m2 is a string
I've tried mixin: gives me Error: function 
vulkan_input.VK_MAKE_VERSION (int major, int minor, int patch) is 
not callable using argument types ()

and various combos of typeof and mixin

typeof(m2) is an __error
typeof(mixin(m2)) " T is not an expression". fails for m2 == uint 
etc and m2 == module gives module had no type


Nic

Re: how to initialise const variables

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

On Friday, 26 February 2016 at 02:32:44 UTC, Nicholas Wilson 
wrote:

struct A
{
 const (void *) p;
}

struct B
{
Aa;
this(void * _p)
{
a.p = _p;
}
}

I cannot change the definition of A
how do I initialise b.a.p?


Use a constructor for A instead of trying to write to one 
specific member:


a = A(_p);

const variable must be initialized in constructors. Structs have 
automatically defined constructors that take all the member 
variables so even if it isn't explicitly written, you can still 
do this.

Re: dub: how to reference a compiled package

[mahdi via Digitalmars-d-learn]

On Friday, 26 February 2016 at 02:49:20 UTC, Mike Parker wrote:

On Thursday, 25 February 2016 at 21:06:59 UTC, mahdi wrote:

On Thursday, 25 February 2016 at 16:45:46 UTC, Chris Wright


Thanks. Is there a way to use a D library without having 
access to it's source code? I tried `dmd -lib abcd.d` which 
creates a static library. But still I need to specify path to 
library's source files using -I option when compiling the code 
that uses that library.


So if we have just access to the library file, is it possible 
to use it in the code?


The compiler needs to know what symbols are available from any 
imports you use in your source. .di files exist to allow closed 
source projects to be distributed as binary. They are analagous 
to C or C++ header files. You could create them by hand like so:


// foo.d
struct S { int x, y; }
void addTwo(S s) { s.x += 2; s.y += 2; }

// foo.di
struct S { int x, y; }
void addTwo(S s);

The compiler needs to know about S and its types, and it needs 
to know the signature of addTwo. The .di file allows you to 
provide that while keeping the implementation of addTwo closed. 
When foo is imported in client code, the compiler will find 
foo.di and use that instead of foo.d.


However, the compiler must have the source for templates, as 
they are instantiated when they are used, not when the library 
is compiled. The same is true for any functions you want 
inlined. In the example above, addTwo can only be inlined when 
foo.d is used, since the compiler will not have the 
implementation with foo.di.


Great! Thanks.

I was looking for a feature like `jar` files in Java or 
`assemblies` in C# where all compiled code and metadata/symbols 
are stored together inside a single binary file.


I think same can be implemented for D language and it won't break 
any code because it is not touching the language itself, but the 
compiler.


Anyway, thanks.

Re: how to initialise const variables

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 26 February 2016 at 02:48:35 UTC, cym13 wrote:
On Friday, 26 February 2016 at 02:32:44 UTC, Nicholas Wilson 
wrote:

struct A
{
 const (void *) p;
}

struct B
{
Aa;
this(void * _p)
{
a.p = _p;
}
}

I cannot change the definition of A
how do I initialise b.a.p?


As you did:

void main() {
int i = 42;
B b = B();
int* p = cast(int*)b.a.p;
assert(*p == 42);
}



a.p = _p;

fails to compile
fixed by
a = typeof(a)(_p);

Re: Official compiler

[Jonathan M Davis via Digitalmars-d]

On Friday, 26 February 2016 at 00:56:22 UTC, Walter Bright wrote:

On 2/25/2016 3:06 PM, H. S. Teoh via Digitalmars-d wrote:

I remember you did a bunch of stuff to the optimizer after the
switchover to self-hosting; how much of a difference did that 
make? Are

there any low-hanging fruit left that could make dmd faster?


There's a lot of low hanging fruit in dmd. In particular, far 
too many templates are instantiated over and over.


LOL. That would be an understatement. IIRC, at one point, Don 
figured out that we were instantiating _millions_ of templates 
for the std.algorithm unit tests. The number of templates used in 
template constraints alone is likely through the roof. Imagine 
how many times something like isInputRange!string gets compiled 
in your typical program. With how template-heavy range-base code 
is, almost anything we can do to speed of the compiler with 
regards to templates is likely to pay off.


- Jonathan M Davis

Re: dub: how to reference a compiled package

[Mike Parker via Digitalmars-d-learn]

On Friday, 26 February 2016 at 02:49:20 UTC, Mike Parker wrote:


The compiler needs to know about S and its types, and it needs


S and its *members*

Re: dub: how to reference a compiled package

[Mike Parker via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 21:06:59 UTC, mahdi wrote:

On Thursday, 25 February 2016 at 16:45:46 UTC, Chris Wright


Thanks. Is there a way to use a D library without having access 
to it's source code? I tried `dmd -lib abcd.d` which creates a 
static library. But still I need to specify path to library's 
source files using -I option when compiling the code that uses 
that library.


So if we have just access to the library file, is it possible 
to use it in the code?


The compiler needs to know what symbols are available from any 
imports you use in your source. .di files exist to allow closed 
source projects to be distributed as binary. They are analagous 
to C or C++ header files. You could create them by hand like so:


// foo.d
struct S { int x, y; }
void addTwo(S s) { s.x += 2; s.y += 2; }

// foo.di
struct S { int x, y; }
void addTwo(S s);

The compiler needs to know about S and its types, and it needs to 
know the signature of addTwo. The .di file allows you to provide 
that while keeping the implementation of addTwo closed. When foo 
is imported in client code, the compiler will find foo.di and use 
that instead of foo.d.


However, the compiler must have the source for templates, as they 
are instantiated when they are used, not when the library is 
compiled. The same is true for any functions you want inlined. In 
the example above, addTwo can only be inlined when foo.d is used, 
since the compiler will not have the implementation with foo.di.

Re: how to initialise const variables

[cym13 via Digitalmars-d-learn]

On Friday, 26 February 2016 at 02:32:44 UTC, Nicholas Wilson 
wrote:

struct A
{
 const (void *) p;
}

struct B
{
Aa;
this(void * _p)
{
a.p = _p;
}
}

I cannot change the definition of A
how do I initialise b.a.p?


As you did:

void main() {
int i = 42;
B b = B();
int* p = cast(int*)b.a.p;
assert(*p == 42);
}

how to initialise const variables

[Nicholas Wilson via Digitalmars-d-learn]

struct A
{
 const (void *) p;
}

struct B
{
Aa;
this(void * _p)
{
a.p = _p;
}
}

I cannot change the definition of A
how do I initialise b.a.p?

Re: Official compiler

[Chris Wright via Digitalmars-d]

On Fri, 26 Feb 2016 00:48:15 +0100, Xavier Bigand wrote:

> Is dmd multi-threaded?

Not at present.

It should be relatively easy to parallelize IO and parsing, at least in 
theory. I think IO parallelism was removed with the ddmd switch, maybe? 
But you'd have to identify the files you need to read in advance, so 
that's not as straightforward.

D's metaprogramming is too complex for a 100% solution for parallelizing 
semantic analysis on a module level. But you could create a partial 
solution:
* After parsing, look for unconditional imports. Skip static if/else 
blocks, skip template bodies, but grab everything else.
* Make a module dependency graph from that.
* Map each module to a task.
* Merge dependency cycles into single tasks. You now have a DAG.
* While there are any tasks in the graph:
  - Find all leaf tasks in the graph.
  - Run semantic analysis on them in parallel.

When you encounter a conditional or mixed in import, you can insert it 
into the DAG if it's not already there, but it would be simpler just to 
run analysis right then and there.

Alternatively, you can find regular and conditional imports and try to 
use them all. But this requires you to hold errors until you're certain 
that the module is used, and you end up doing more work overall. And that 
could be *tons* more work. Consider:

  module a;
  enum data = import("ten_million_records.csv");
  mixin(createClassesFromData(data));

  module b;
  enum shouldUseModuleA = false;

  module c;
  import b;
  static if (shouldUseModuleA) import a;

And even if you ignored that, you'd still have to deal with mixed in 
imports, which can be the result of arbitrarily complex CTFE expressions.

While all of this is straightforward in theory, it probably isn't so 
simple in practice.

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/25/2016 3:06 PM, H. S. Teoh via Digitalmars-d wrote:

I remember you did a bunch of stuff to the optimizer after the
switchover to self-hosting; how much of a difference did that make? Are
there any low-hanging fruit left that could make dmd faster?


There's a lot of low hanging fruit in dmd. In particular, far too many templates 
are instantiated over and over.


The data structures need to be looked at, and the excessive memory consumption 
also slows things down.



On a related note, I discovered an O(n^2) algorithm in the front-end...
it's unlikely to be an actual bottleneck in practice (basically it's
quadratic in the number of fields in an aggregate), though you never
know. It actually does a full n^2 iterations, and seemed like it could
be at least pared down to n(n+1)/2, even without doing better than
O(n^2).


Please add a comment to the source code about this and put it in a PR.

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/25/2016 3:06 PM, David Nadlinger wrote:

On Thursday, 25 February 2016 at 22:03:47 UTC, Walter Bright wrote:

DMD did slow down because it was now being compiled by DMD instead of g++.

You can compile it using LDC just fine now. ;)


I think we should ask Martin to set that up for the release builds.


Also, dmd was doing multithreaded file I/O, but that was removed because speed
didn't matter .

Did we ever have any numbers showing that this in particular produced a tangible
performance benefit (even a single barnacle)?


On a machine with local disk and running nothing else, no speedup. With a slow 
filesystem, like an external, network, or cloud (!) drive, yes. I would also 
expect it to speed up when the machine is running a lot of other stuff.




LDC doesn't do so either. I think what rsw0x referred to is doing a normal
"C-style" parallel compilation of several compilation unit. I'm not sure why
this couldn't also be done with DMD, though.


-j should work just fine with dmd.

There's a lot internal to the compiler that can be parallelized - just about 
everything but the semantic analysis.

Re: how do you append arrays?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/25/16 4:39 PM, asdf wrote:


 if(line != "" && line != history[0]) {
 string[] x = [line];
 foreach(string i; history[0..99]) x ~= i;
 history = x;
 }


ugh!

history = line ~ history[0 .. $ - 1];

What you may want to consider is making history backwards referenced. 
That is, history[0] is the oldest line.


Then you could do:
history = history[1 .. $];
history ~= line;


Is there a good way to pick out matching prefixes of a string? Picking
out the first word without disrupting whitespace after the second word
would be nice =)

How do you read chars without waiting for a newline? That would be
needed to respond to the ANSI esapes for arrow keys...


If you are only getting characters after a newline, then you aren't 
interacting directly with the terminal (which requires some terminal 
access library). The terminal is letting the user edit the line, then 
when he hits return, it sends the whole line to your program. You won't 
get arrow key codes.


-Steve

Re: std.xml2 (collecting features)

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 25 February 2016 at 23:59:04 UTC, crimaniak wrote:
Where is only a couple of ad-hoc checks for attributes values. 
This language is not XPath-compatible, so most easy way to 
cover a lot of cases is regex check for attributes. Something 
like "script[src/https:.+\\.googleapis\\.com/i]"


The css3 selector standard offers three substring search: 
[attr^=foo] if it begins with foo, [attr$=foo] if it ends with 
foo, and [attr*=foo] if it includes foo somewhere. dom.d supports 
all three now.


So for your regex, you could probably match: 
[attr*=googleapis.com] well enough.

Re: std.xml2 (collecting features)

[crimaniak via Digitalmars-d]

On Sunday, 21 February 2016 at 23:57:40 UTC, Adam D. Ruppe wrote:

On Sunday, 21 February 2016 at 23:01:22 UTC, crimaniak wrote:
I will use it in my experiments, but getElementsBySelector() 
selector language need to be improved I think.


What, specifically, do you have in mind?


Where is only a couple of ad-hoc checks for attributes values. 
This language is not XPath-compatible, so most easy way to cover 
a lot of cases is regex check for attributes. Something like 
"script[src/https:.+\\.googleapis\\.com/i]"

Re: Official compiler

[Xavier Bigand via Digitalmars-d]

Le 25/02/2016 03:48, Walter Bright a écrit :

On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:

I've also heard from big users who want the performance more than
compile time
and hit difficulty in build scaling..


I know that performance trumps all for many users. But we can have both
- dmd and ldc/gdc.

My point is that compile speed is a valuable and distinguishing feature
of D. It's one that I have to constantly maintain, or it bit rots away.
It's one that people regularly dismiss as unimportant. Sometimes it
seems I'm the only one working on the compiler who cares about it.

For comparison, C++ compiles like a pig, I've read that Rust compiles
like a pig, and Go makes a lot of hay for compiling fast.


I think that you are very gentle with C++. It can be hell, when you are 
working on multiple platforms with different compiler and build systems 
it took a lot of efforts and time to maintain compilation time at a 
decent level.
I recently made optimizations on our build configurations after adding 
some boost modules at my day job. Our build time double instantly.

All optimizations have a great cost on at least an other point.
- PIMPL: Increase the code complexity, decrease performances
- Precompiled header: not standard, mingw is limited to 130Mo generated file
- Unity build: can be hard to add to many build system if 
auto-generated. compiler can crash with an out of memory (mingw will be 
the first)

- cleaning our includes: how doing that without tools?
- multi-threaded compilation: not standard, sometimes it have to be 
configured on computer


So thank you for having created a fast compiler even if I just can dream 
to be able to use it a day professionally.

IMO if Go is a fast compiler is just because dmd shows the way.

Is dmd multi-threaded?

PS: I don't understand why import modules aren't already here in c++, it 
make years that clang team is working on it.

Re: Pseudo-random numbers in [0, n), covering all numbers in n steps?

[Nicholas Wilson via Digitalmars-d]

On Thursday, 25 February 2016 at 17:27:25 UTC, Andrei 
Alexandrescu wrote:
So we have 
https://dlang.org/phobos/std_random.html#.randomCover which 
needs to awkwardly allocate memory to keep track of the 
portions of the array already covered.


This could be fixed by devising a PRNG that takes a given 
period n and generates all numbers in [0, n) in exactly n steps.


However, I've had difficulty finding such PRNGs. Most want the 
maximum period possible so they're not concerned with a given 
period. Any insights?


BTW I found this statement in the documentation rather odd: 
"These issues will be resolved in a second-generation 
std.random that re-implements random number generators as 
reference types." The documentation is not a place for making 
vague promises and speculations about future developments. I 
think it should be removed.



Thanks,

Andrei


The technical name for the property of distribution you describe 
is

 k-Dimensional Equidistribution (in this case k=1).
I would suggest taking a look at http://www.pcg-random.org.
They claim to have both arbitrary period and k-Dimensional 
Equidistribution


Nic

Re: Accessing all data in TypeTupple (AliasSeq) and stringify them

[Ali Çehreli via Digitalmars-d-learn]

On 02/25/2016 12:53 PM, Voitech wrote:


template TupleToString(TList...){

 string a;
 foreach(T;TList){ // Error: declaration expected, not 'foreach'
 a~=T.stringof;
 }
 enum string TupleToString=a;
}

Of course i can use template function, but wanted to know if can omit this.
Cheers Voitech



You have to wrap the logic in a function and call that function:

template TupleToString(TList...){

string make_a() {
string a;
foreach(T;TList){
a~=T.stringof;
}
return a;
}

enum string TupleToString=make_a();
}

Ali

Re: The D-9000 robot

[gtku via Digitalmars-d]

On Thursday, 25 February 2016 at 22:33:54 UTC, Walter Bright 
wrote:

My gawd, what are we doing:

   https://i.imgur.com/z8nxId1.gifv


Oh yeah, I've seen this the other day on HackerNews. Quite 
impressive how it walk in the snow.


http://spectrum.ieee.org/automaton/robotics/humanoids/.Vsz6oBcqyR8.hackernews

Re: Accessing all data in TypeTupple (AliasSeq) and stringify them

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 20:53:12 UTC, Voitech wrote:
On Thursday, 25 February 2016 at 14:29:30 UTC, Nicholas Wilson 
wrote:

On Thursday, 25 February 2016 at 13:16:43 UTC, Voitech wrote:

[...]


You can (see std.meta/(std.traits?) , with recursive 
templates), but there is nothing stopping from using 
for/foreach in a template


this should do what you want
string[] functionSig;
string[] params;
foreach(s; Parameters!T)) // returns AliasSeq of types
 {
   params ~=s.stringof;
 }
  string[] pits;
 foreach(p; ParameterIdentifierTuple!(T)); // returns AliasSeq 
of strings

{
   pits ~=p;
}
and the either join(er) or do as you see fit.
or use plain old for
for(auto i=0;i< pits.length; i++)
{
 functionSig ~= params[i];
 functionSig ~= pits[i];
}
writeln(functionSig);
// should print ["int" , "param0" , "string" , "param1"]

Nic


Thank You for answering, well i wanted to make all of this in 
template block, not using template functions (testing if it is 
possible), but i'm getting error when i try to create something 
like


template TupleToString(TList...){

string a;
foreach(T;TList){ // Error: declaration expected, not 
'foreach'

a~=T.stringof;
}
enum string TupleToString=a;
}

Of course i can use template function, but wanted to know if 
can omit this.

Cheers Voitech


See the recursive templates in std.meta;

this would be something like

 template TupleToString(TList...)
{
   static if(Tlist.length == 0)
  enum string TupleToString = "";
   else
 enum string TupleToString=TList[0].stringof ~ 
TupleToString(TList[1 . $];

 }

Nic

Re: Official compiler

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 25, 2016 at 02:03:47PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/25/2016 1:50 PM, Andrei Alexandrescu wrote:
> >Good to know, thanks! -- Andrei
> 
> DMD did slow down because it was now being compiled by DMD instead of
> g++.  Also, dmd was doing multithreaded file I/O, but that was removed
> because speed didn't matter .
[...]

I remember you did a bunch of stuff to the optimizer after the
switchover to self-hosting; how much of a difference did that make? Are
there any low-hanging fruit left that could make dmd faster?

On a related note, I discovered an O(n^2) algorithm in the front-end...
it's unlikely to be an actual bottleneck in practice (basically it's
quadratic in the number of fields in an aggregate), though you never
know. It actually does a full n^2 iterations, and seemed like it could
be at least pared down to n(n+1)/2, even without doing better than
O(n^2).


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

Re: Official compiler

[David Nadlinger via Digitalmars-d]

On Thursday, 25 February 2016 at 22:03:47 UTC, Walter Bright 
wrote:
DMD did slow down because it was now being compiled by DMD 
instead of g++.


You can compile it using LDC just fine now. ;)

Also, dmd was doing multithreaded file I/O, but that was 
removed because speed didn't matter .


Did we ever have any numbers showing that this in particular 
produced a tangible performance benefit (even a single barnacle)?



As I said, keeping the compiler speed up is a constant battle.


And this leaves me wondering why nobody ever wrote a 
comprehensive compiler performance tracking tool. There is Dash, 
my half-finished CI-style project (that a couple of people were 
interested in picking up after DConf, but which never really 
happened), and Vladimir's quite limited TrenD adaption of 
Mozilla's areweslimyet, but nobody really came up with something 
that would be part of our day-to-day development workflow.


Currently, dmd makes zero user of multicore. I didn't know that 
ldc did.


LDC doesn't do so either. I think what rsw0x referred to is doing 
a normal "C-style" parallel compilation of several compilation 
unit. I'm not sure why this couldn't also be done with DMD, 
though.


 — David

Re: Official compiler

[Atila Neves via Digitalmars-d]

On Thursday, 25 February 2016 at 22:38:45 UTC, Atila Neves wrote:

On Thursday, 25 February 2016 at 19:55:20 UTC, rsw0x wrote:

[...]


Would it be possible to point me in the directions of projects 
where you saw ldc being faster? I didn't try per-module, but on 
the projects I tried, dmd is still considerably faster when 
compiling per-package. And given that per-package is nearly 
always faster than per-module... 
(http://forum.dlang.org/post/yfykbayodugukemvo...@forum.dlang.org)


Atila


Forgot to say: I measured seconds ago on the most recent dmd and 
ldc with an 8-core CPU with hyperthreading (so 16 threads).


Atila

Re: Official compiler

[Atila Neves via Digitalmars-d]

On Thursday, 25 February 2016 at 19:55:20 UTC, rsw0x wrote:

On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
If we would make GDC or LDC the official compiler then the 
next question which pops up is about compilation speed




ldc is still significantly faster than clang, or gdc than gcc. 
I don't think this is that much of a valid concern, especially 
for smaller programs.


For larger programs, LDC with single-file compilation outdoes 
DMD by a large factor on any recent multi-core CPU for both 
debug and release builds in my tests. DMD did not scale across 
cores anywhere near as well as LDC.
OTOH, it does not benefit from singleobj this way when doing 
release builds.


Would it be possible to point me in the directions of projects 
where you saw ldc being faster? I didn't try per-module, but on 
the projects I tried, dmd is still considerably faster when 
compiling per-package. And given that per-package is nearly 
always faster than per-module... 
(http://forum.dlang.org/post/yfykbayodugukemvo...@forum.dlang.org)


Atila

Re: Calling python code from D

[asdf via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 21:46:40 UTC, asdf wrote:




Hi, me again. I'm having trouble making a demonstration and not 
sure if  is obsolete or not anyways. :/


Anyways take a look here. 
http://www.tutorialspoint.com/python/python_further_extensions.htm http://dlang.org/spec/interfaceToC.html

The D-9000 robot

[Walter Bright via Digitalmars-d]

My gawd, what are we doing:

   https://i.imgur.com/z8nxId1.gifv

Re: Calling python code from D

[jmh530 via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 21:46:40 UTC, asdf wrote:


I haven't tried this myself but D is supposed to have excellent 
interface to C code. Perhaps you can go that route. 
http://stackoverflow.com/questions/145270/calling-c-c-from-python


That question is the reverse, calling C from python, rather than 
calling python from C.


I think PyD is really your best option.

The problem with PyD's docs is that it's not obvious how to get 
to them from the github page. You actually have to go to the wiki 
page and then there's a link to older docs from Bitbucket or 
ReadTheDocs, but those links are broken. Here's the readthedocs 
page:


http://pyd.readthedocs.org/en/latest/

You would actually be interested in something like:

http://pyd.readthedocs.org/en/latest/embed.html

Re: Installing DUB on OSX

[Joel via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 11:06:09 UTC, Jacob Carlborg 
wrote:

On 2016-02-24 23:11, Joel wrote:


Error: Error writing file
'../../../.dub/packages/dsfml-2.1.0/libdsfml_system.a'
Joels-MacBook-Pro:DGuy joelcnz$


Is the full path of ../../../.dub/packages/dsfml-2.1.0 writable?


It is path: Macky -> Users/joelcnz and is writable. But .dub etc 
on the path isn't writable. (joelcnz/.dub)

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/25/2016 1:50 PM, Andrei Alexandrescu wrote:

Good to know, thanks! -- Andrei


DMD did slow down because it was now being compiled by DMD instead of g++. Also, 
dmd was doing multithreaded file I/O, but that was removed because speed didn't 
matter .


As I said, keeping the compiler speed up is a constant battle.

Currently, dmd makes zero user of multicore. I didn't know that ldc did.

[Issue 15725] New: [D Builtin Rationale]

[via Digitalmars-d-bugs]

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

  Issue ID: 15725
   Summary: [D Builtin Rationale]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: xemail...@yahoo.co.uk

When you click on "wiki" under "Community" menu at the top, it goes to
"https://wiki.dlang.org/; which does not have correct/complete formatting while
"   http://wiki.dlang.org/; has.

--

Re: Official compiler

[Andrei Alexandrescu via Digitalmars-d]

On 02/25/2016 02:55 PM, rsw0x wrote:

On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:

If we would make GDC or LDC the official compiler then the next
question which pops up is about compilation speed



ldc is still significantly faster than clang, or gdc than gcc. I don't
think this is that much of a valid concern, especially for smaller
programs.


For larger programs, LDC with single-file compilation outdoes DMD by a
large factor on any recent multi-core CPU for both debug and release
builds in my tests. DMD did not scale across cores anywhere near as well
as LDC.
OTOH, it does not benefit from singleobj this way when doing release
builds.


Good to know, thanks! -- Andrei

Re: Calling python code from D

[asdf via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 21:40:45 UTC, Wyatt wrote:
I have a project I started in Python before I realised I really 
don't enjoy Python.  It's been on the back-burner for a few 
years and I'd like to start again in D, but there's a 
particular python module (Mutagen) that I outright refuse to 
reimplement.  What's the state of the art in calling Python 
code from D?


I have a hunch PyD fits somewhere in this equation, but the 
documentation is pretty sparse, and what little I can find 
about this area makes it seem like a fairly tedious manual 
process.  Is there a less-painful and intensive way to truss 
things up?  Something to generate a simple D wrapper from a 
python module?


-Wyatt


I haven't tried this myself but D is supposed to have excellent 
interface to C code. Perhaps you can go that route. 
http://stackoverflow.com/questions/145270/calling-c-c-from-python

Calling python code from D

[Wyatt via Digitalmars-d-learn]

I have a project I started in Python before I realised I really 
don't enjoy Python.  It's been on the back-burner for a few years 
and I'd like to start again in D, but there's a particular python 
module (Mutagen) that I outright refuse to reimplement.  What's 
the state of the art in calling Python code from D?


I have a hunch PyD fits somewhere in this equation, but the 
documentation is pretty sparse, and what little I can find about 
this area makes it seem like a fairly tedious manual process.  Is 
there a less-painful and intensive way to truss things up?  
Something to generate a simple D wrapper from a python module?


-Wyatt

Re: how do you append arrays?

[asdf via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 19:21:31 UTC, Steven 
Schveighoffer wrote:

On 2/25/16 2:12 PM, Steven Schveighoffer wrote:
I believe you could use std.algorithm.copy, but probably need 
to do it

with retro as well.



Heh, or of course use memmove :)

-Steve


I got the history list working this morning but probably not very 
efficient. You can see:

 cut 
debug = 0;
import std.stdio;
import std.string;

void main() {
string line;
string[] history;
char cmd = '/',
 sep = ';',
 dot = '.',
 bak = '\\';

line = readln().chomp;
foreach(int i; 0..100) history ~= "";
debug(1) { stderr.writeln(history); }

while(!stdin.eof) {
string[] emit = line.split(sep);
foreach(string e; emit) {

/* how to do proper prefix and/or leading word? */
if(e[0] == cmd) { /* ... */ }
else if(e[0] == dot) { /* ... */ }
else if(e[0] == bak) { /* ... */ }
else writeln(e);
}

if(line != "" && line != history[0]) {
string[] x = [line];
foreach(string i; history[0..99]) x ~= i;
history = x;
}
debug(1) { stderr.writeln(history); }

line = readln().chomp;
}
}
 cut 

Is there a good way to pick out matching prefixes of a string? 
Picking out the first word without disrupting whitespace after 
the second word would be nice =)


How do you read chars without waiting for a newline? That would 
be needed to respond to the ANSI esapes for arrow keys...

Re: Installing DUB on OSX

[Joel via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 11:06:09 UTC, Jacob Carlborg 
wrote:

On 2016-02-24 23:11, Joel wrote:


Error: Error writing file
'../../../.dub/packages/dsfml-2.1.0/libdsfml_system.a'
Joels-MacBook-Pro:DGuy joelcnz$


Is the full path of ../../../.dub/packages/dsfml-2.1.0 writable?


.dub is grayed out on Finder, and isn't writable.

[Issue 4763] Few possible changes on std.stdio.File

[via Digitalmars-d-bugs]

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

Andre  changed:

   What|Removed |Added

 CC|alver...@gmail.com  |

--

[Issue 4763] Few possible changes on std.stdio.File

[via Digitalmars-d-bugs]

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

Andre  changed:

   What|Removed |Added

 CC||d.developer.an...@gmail.com
   Assignee|nob...@puremagic.com|d.developer.an...@gmail.com

--

Re: How to better organize dub project to get 3 exe from same codebase?

[Luis via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 20:55:33 UTC, Suliman wrote:

On Thursday, 25 February 2016 at 19:09:59 UTC, Suliman wrote:

Where to store shared classes?


{
"name": "123",
"authors": [
"Suliman"
],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Suliman",
"license": "proprietary",
"subPackages": [
{
"name": "App1",
"description": "App1",
"targetType": "executable",
"sourcePaths": ["source/App1"]
},

{
"name": "App2",
"description": "App2",
"targetType": "executable",
"sourcePaths": ["source/App2"]
},  
{
"name": "App3",
"description": "App3",
"targetType": "executable",
"sourcePaths": ["source/App3"]
}   


}

Should I link from subPackages to general source/ folder ?


I don't link nothing. I have some shared D source code files 
between the 3 files (on src/dcpu). So each subpackage generates a 
executable file, excluding the not common files of the other 
subpackages. It isn't the best way of doing this, but just works 
for my case.
Eventually i would change this. I think that alphaPhobos does 
what you are asking : 
https://github.com/rikkimax/alphaPhobos/blob/master/dub.sdl

Re: dub: how to reference a compiled package

[mahdi via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 16:45:46 UTC, Chris Wright wrote:

On Thu, 25 Feb 2016 12:15:42 +, mahdi wrote:


Hi,

Suppose I have a package `mypack` in `~/mypack`. I run `dub` 
command on this package and have the compiled `mypack` file 
(OS is Linux).


Now I am working on my project. I know how to use the 
source-code of `mypack` package in the project but what if I 
only have the compiled binary? How can I reference and use the 
modules of the compiled `mypack`?


(I looked into the DUB homepage and it's Getting Started page 
but could

not find anything).


First thing, you need D interface files. See: 
https://dlang.org/dmd-linux.html#interface-files


Note that D interface files still require you to include the 
full body of anything in a template, so you might have to 
modify your code somewhat for improved secrecy.


Copy the *.di files and binaries into another dub project and 
add a postBuildCommand to copy that binary to the output 
location.


I think that will work. dub might complain that it doesn't have 
any source files, in which case you'll have to provide at least 
one D file for it to compile, but that can be empty.


Thanks. Is there a way to use a D library without having access 
to it's source code? I tried `dmd -lib abcd.d` which creates a 
static library. But still I need to specify path to library's 
source files using -I option when compiling the code that uses 
that library.


So if we have just access to the library file, is it possible to 
use it in the code?

Re: no size yet for forward reference error

[Marc Schütz via Digitalmars-d]

Digger shows that it stopped working after this PR:
https://github.com/D-Programming-Language/dmd/pull/4457

I could reduce it as far as this:

struct RefCounted(T) {
struct Impl {
T _payload;
}

Impl* _store;

~this() {
destroy(_store._payload);
}
}

struct Connection(T) {
alias Statement = .Statement!T;
}

struct Statement(T) {
alias Connection = .Connection!T;

struct Payload {
Connection con;
}

RefCounted!Payload Data;
}

Connection!int x;

Re: How to better organize dub project to get 3 exe from same codebase?

[Suliman via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 19:09:59 UTC, Suliman wrote:

Where to store shared classes?


{
"name": "123",
"authors": [
"Suliman"
],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Suliman",
"license": "proprietary",
"subPackages": [
{
"name": "App1",
"description": "App1",
"targetType": "executable",
"sourcePaths": ["source/App1"]
},

{
"name": "App2",
"description": "App2",
"targetType": "executable",
"sourcePaths": ["source/App2"]
},  
{
"name": "App3",
"description": "App3",
"targetType": "executable",
"sourcePaths": ["source/App3"]
}   


}

Should I link from subPackages to general source/ folder ?

Re: Accessing all data in TypeTupple (AliasSeq) and stringify them

[Voitech via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 14:29:30 UTC, Nicholas Wilson 
wrote:

On Thursday, 25 February 2016 at 13:16:43 UTC, Voitech wrote:
Hi, I have some code processing functions definition in 
compile time, I want to override
them in some other class but not explicitly so created this 
code:


template MixinFunction(alias attributes,alias returnType,alias 
name,alias parameters,alias bodyy){


enum string MixinFunction = format(q{
%s %s %s(%s){

%s

}

},attributes,returnType,name,parameters,bodyy);
}
unittest{
	alias func=MixinFunction!("static","void","testFunc","int 
a,int b",q{


import std.stdio;
writeln("im void body");

});
pragma(msg,func);
mixin(func);
}

Now i acquired all data like return type, parameters but need 
to turn them into string for example function parameters must 
have form of:


for function func:
void func(int a,string b){}

alias parameters=Parameters!func;

returns me AliasSeq!(int,string)
I want to to turn them into string: like "int param0, string 
param1", but in template


template AliasSeqToString(TList...){

enum AliasSeqToString= ... //each ?


}
How to operate on TypeTuple/AliasSeq elemens withouth foreach ?


You can (see std.meta/(std.traits?) , with recursive 
templates), but there is nothing stopping from using 
for/foreach in a template


this should do what you want
string[] functionSig;
string[] params;
foreach(s; Parameters!T)) // returns AliasSeq of types
 {
   params ~=s.stringof;
 }
  string[] pits;
 foreach(p; ParameterIdentifierTuple!(T)); // returns AliasSeq 
of strings

{
   pits ~=p;
}
and the either join(er) or do as you see fit.
or use plain old for
for(auto i=0;i< pits.length; i++)
{
 functionSig ~= params[i];
 functionSig ~= pits[i];
}
writeln(functionSig);
// should print ["int" , "param0" , "string" , "param1"]

Nic


Thank You for answering, well i wanted to make all of this in 
template block, not using template functions (testing if it is 
possible), but i'm getting error when i try to create something 
like


template TupleToString(TList...){

string a;
foreach(T;TList){ // Error: declaration expected, not 
'foreach'

a~=T.stringof;
}
enum string TupleToString=a;
}

Of course i can use template function, but wanted to know if can 
omit this.

Cheers Voitech

[Issue 15678] BigInt("") should fail more prominently

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/3ad0489e36819780a5b9c8a486968f6ae2fe73d3
Merge pull request #3995 from quickfur/bigint_bounds

Issue 15678: BigInt("") should not break array bounds

--

Re: no size yet for forward reference error

[Jonathan M Davis via Digitalmars-d]

On Thursday, 25 February 2016 at 20:14:20 UTC, Marc Schütz wrote:
On Thursday, 25 February 2016 at 17:33:34 UTC, Jonathan M Davis 
wrote:
Actually, both of your examples compile for me - both with 
master and with 2.070.0. I'm running on x86_64 FreeBSD (which 
you probably aren't), which shouldn't matter for this sort of 
error, but I suppose that it's possible that it's somehow 
system-specific, much as I wouldn't expect it to be. So, I 
don't what to say. :|


You need to compile with `-unittest`.


Ah, yes. I see now. And yes, that fails to compile.

Well, given that you have types referring to each other, it's not 
all that hard to get a circular definition error. The most 
obvious is when you do something like


struct A
{
B b;
}

struct B
{
A a;
}

And while the code in question doesn't do anything that blatant, 
it is having types refer to each other. What's incredibly weird 
is that if the RefCounted!(Payload, RefCountedAutoInitialize.no) 
is changed to Payload, the code works. If there were going to be 
a circular definition problem, then I'd think that it would occur 
without RefCounted being involved.


I'd suggest copying RefCounted to your local file and using that 
version of it rather than introducing std.typecons into the mix, 
and then use dustmite to reduce it. Then you can track down which 
part of RefCounted is causing the problem. dustmite is now 
released with dmd, I believe, so you shouldn't need to track it 
down, and instructions for it can be found here:


https://github.com/CyberShadow/DustMite/wiki

- Jonathan M Davis

Re: no size yet for forward reference error

[Marc Schütz via Digitalmars-d]

On Thursday, 25 February 2016 at 17:33:34 UTC, Jonathan M Davis 
wrote:
Actually, both of your examples compile for me - both with 
master and with 2.070.0. I'm running on x86_64 FreeBSD (which 
you probably aren't), which shouldn't matter for this sort of 
error, but I suppose that it's possible that it's somehow 
system-specific, much as I wouldn't expect it to be. So, I 
don't what to say. :|


You need to compile with `-unittest`.

Re: Swift deprecate i++ and c-style for loop

[Jonathan M Davis via Digitalmars-d]

On Thursday, 25 February 2016 at 19:03:12 UTC, Steven 
Schveighoffer wrote:

On 2/24/16 3:47 PM, Ola Fosheim Grøstad wrote:
On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven 
Schveighoffer wrote:
I'm quite glad D stuck with the same type for arrays and 
array slices.


And how will you get around this when not having a GC?



I don't follow. D's arrays will always have a GC.

If you have a different type of array, it's a different type, 
it can do whatever it wants.


Remember that a dynamic array does not necessarily refer to 
GC-allocated memory. The dynamic array operations don't care 
about that at all, but it does make it so that you can have a 
problem figuring out when it's okay to free the memory that you 
sliced them from if you start passing them around all over the 
place and potentially storing them. So, in that regard, the fact 
that a dynamic array doesn't really own or manage its own memory 
can complicate things when the dynamic array was not allocated 
via the GC (be it because it was sliced from malloced memory or 
sliced from a static array or whatever).


There's also the issue that some folks disable the GC, which 
doesn't prevent dynamic arrays from working aside from the few 
operations that require the GC, but it does mean that you to be 
that much more careful about how you use them.


Personally, I think that using malloc or a static array to back a 
dynamic array works great if you're dealing with localized stuff 
that you're going to pass to pure, free functions (which 
therefore can't slice the dynamic array and store it elsewhere), 
but once you're dealing with dynamic arrays that get passed 
around and stored arbitrarily, it gets seriously iffy to slice 
malloced memory or static arrays and start passing those dynamic 
arrays around. It quickly becomes far more sensible to create a 
container that gives you range rather than deal with dynamic 
arrays.


- Jonathan M Davis

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote:

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
If we would make GDC or LDC the official compiler then the 
next question which pops up is about compilation speed




ldc is still significantly faster than clang, or gdc than gcc. 
I don't think this is that much of a valid concern, especially 
for smaller programs.


For larger programs, LDC with single-file compilation outdoes DMD 
by a large factor on any recent multi-core CPU for both debug and 
release builds in my tests. DMD did not scale across cores 
anywhere near as well as LDC.
OTOH, it does not benefit from singleobj this way when doing 
release builds.

Re: Unum II announcement

[Nick B via Digitalmars-d]

On Thursday, 25 February 2016 at 10:36:08 UTC, Robbert van Dalen 
wrote:

On Wednesday, 24 February 2016 at 21:43:59 UTC, Nick B wrote:
On Wednesday, 24 February 2016 at 20:11:39 UTC, Robbert van 
Dalen wrote:




Nick,

I've just asked Dr. Gustafson to create a group on his behalf 
and he was fine with it:

https://groups.google.com/forum/#!forum/unum-computing

 It would be nice if you'd subscribe to it:


Robbert,

I will subscribe, as you suggested.  I see that the new user 
group has been getting page views already. Thats quick.


Nick

Silicon Valley D Meetup February 25, 2016

[Ali Çehreli via Digitalmars-d-announce]

This time there is no speaker presentation. We will go over D's vision 
in 2016 and share tips and tricks:


  http://www.meetup.com/D-Lang-Silicon-Valley/events/228672525/

Ali

Re: How to detect if an array if dynamic or static

[Ali Çehreli via Digitalmars-d-learn]

On 02/25/2016 04:47 AM, sigod wrote:

>  void bar(ref int[] arr)
>
> Code wouldn't compile if you try to pass static array as `ref` argument.

To qualify further, static arrays cannot be passed as slice references 
because although there is an automatic slicing of static arrays, such 
slices are rvalues and rvalues cannot be bound to 'ref' parameters:


>  Error: function f436.bar (ref int[] arr) is not callable using
> argument types (int[3])

Ali

Re: Official compiler

[deadalnix via Digitalmars-d]

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
If we would make GDC or LDC the official compiler then the next 
question which pops up is about compilation speed




ldc is still significantly faster than clang, or gdc than gcc. I 
don't think this is that much of a valid concern, especially for 
smaller programs.

Re: no size yet for forward reference error

[Erik Smith via Digitalmars-d]

I'm running OSX 10.11.2, DMD v2.070 installed via homebrew with 
--devel flag.


erik

Re: how do you append arrays?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/25/16 2:12 PM, Steven Schveighoffer wrote:

I believe you could use std.algorithm.copy, but probably need to do it
with retro as well.



Heh, or of course use memmove :)

-Steve

Re: D in Ubuntu apps ecosystem

[Joakim via Digitalmars-d]

On Thursday, 25 February 2016 at 17:27:45 UTC, karabuta wrote:
Maybe you might only be thinking about Android or iOS, but 
Ubuntu Touch (a single Ubuntu OS meant to run across multiple 
devices from PC to Phones) is really gaining traction. The good 
news is that QML is officially the way to build apps and D 
already has dqml(https://github.com/filcuc/dqml). 
Back-end(optional) is also C++ with API bindings in Go and 
JavaScript. D currently has good support for C++.


SIDE NOTE: Ubuntu just lunched a phone with 4GB ram running on 
a x64 Octacore Arm processors in addition to a table with 
similar high spec, which can all pretty much handle D(even with 
GC) IMO. All subsequent devices will be high spec since the OS 
will run desktop apps on phone and even IoT.


But can such a powerful phone handle Ubuntu Touch? ;) The 
preliminary reviews for the Meizu Pro 5 Ubuntu Edition, which 
you're presumably referencing, are not good, even though the 
hardware is spec-ed out, because the Ubuntu software is 
supposedly slow and laggy.  I was hopeful for the previous Ubuntu 
on Android effort years ago, but it never went anywhere.  I bet 
this one won't either.


So, do you not think Ubuntu ecosystem makes a good and easy to 
enter market? Unfortunately, I don't have the fuel and engine 
power to make API bindings, so anyone willing to help here?


http://www.ubuntu.com/phone
http://www.ubuntu.com/phone/features
http://www.ubuntu.com/tablet
https://developer.ubuntu.com/en/apps/qml/


Well, it took us a long time to get on the currently most popular 
OS platforms, iOS and Android, and we still have no apps on 
there, so I don't think this tiny Ubuntu niche will get much dev 
effort.  But if you or someone else believes in and wants to 
develop for it, more power to you.

Re: How to detect if an array if dynamic or static

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/24/16 9:08 PM, Adam D. Ruppe wrote:

On Thursday, 25 February 2016 at 01:31:17 UTC, Chris Wright wrote:

When you get to GC-allocated stuff, there's no way to tell.


The GC is easy, you can simply ask it:

http://dpldocs.info/experimental-docs/core.memory.GC.addrOf.1.html

"If p references memory not originally allocated by this garbage
collector, if p is null, or if the garbage collector does not support
this operation, null will be returned."


The append operator uses this kind of logic to determine if it is safe
to append. The `capacity` property on slices can query, though it is
zero in some cases where the GC owns it, but it still needs reallocation
to be appended to (e.g. when the array is already at the max length of
the allocated block, or when the stomping protection kicks in. See:
http://dlang.org/d-array-article.html )


Just a slight nit -- it will only return 0 if the array slice doesn't 
end at the end of valid data as defined by the metadata. If it ends 
exactly at the max length of the block, then arr.capacity == arr.length.


It will also return 0 if the memory block in question wasn't allocated 
via the array allocation routine (and therefore has no metadata).


The correct answer is what you said, to use the GC to look up whether 
it's part of the GC.


-Steve

Re: how do you append arrays?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/25/16 8:24 AM, asdf wrote:

On Thursday, 25 February 2016 at 13:06:10 UTC, cym13 wrote:


In D the binary operator "~"  is used to concatenate both strings
(arrays of characters) and arrays. (also the ~= operator is
equivalent to lhs = lhs ~ rhs

Nic


Just a precision:  "lhs ~= rhs" isn't exactly equivalent to "lhs = lhs
~ rhs", those are two distinct operators that may deal with memory etc
in different ways. For arrays doing "lhs = lhs ~ rhs" will first
create (and allocate) the array corresponding  to "lhs ~ rhs" and then
assign this new array to lhs. On the other hand "lhs ~= rhs" realises
in-place append.


I tried both, the error this time is:
object.Exception@/data/data/com.termux/files/home/ldc/runtime/druntime/src/ldc/arrayinit.d(151):
overlapping array copy


overlapping copies are not supported.

In this case especially, the copying has to be done backwards.

I believe you could use std.algorithm.copy, but probably need to do it 
with retro as well.


-Steve

Re: D in Ubuntu apps ecosystem

[Zardoz via Digitalmars-d]

On Thursday, 25 February 2016 at 18:05:40 UTC, Adam D. Ruppe 
wrote:

On Thursday, 25 February 2016 at 17:27:45 UTC, karabuta wrote:
SIDE NOTE: Ubuntu just lunched a phone with 4GB ram running on 
a x64 Octacore Arm processors in addition to a table with 
similar high spec, which can all pretty much handle D(even 
with GC) IMO.


You can run D with GC with 16 MB - yes, megabytes - of RAM. 
It'd be more comfortable with 32, sure, but the garbage 
collector isn't *that* much of a memory hog.


D gc not would be the most faster on the wild, but isn't like 
Java wasting RAM.

[Issue 15723] GC memory leakade depending on source code size

[via Digitalmars-d-bugs]

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

--- Comment #2 from Denis Shelomovskij  ---
(In reply to Sobirari Muhomori from comment #1)
> That's probably zlib's crc table: 2048 random pointers in bss.

So it looks like we actually can't use C libraries statically linked with D
code as it will make GC almost useless.

> Does your application use zlib?

I have provided the whole test application in the description. As for my
utility, yes it does use zlib.

--

Re: How to better organize dub project to get 3 exe from same codebase?

[Suliman via Digitalmars-d-learn]

Where to store shared classes?

Re: How to better organize dub project to get 3 exe from same codebase?

[Zardoz via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 18:57:08 UTC, Suliman wrote:
I have got 3 small projects that have shared code base. At 
compile time they use few same classes. On runtime they use 
same config file. How to better to organize work with dub?


Try with subpacjages like I did :

name "dedcpu"
authors "Luis Panadero Guardeño"
targetType "none"
license "BSD 3-clause"
description "DCPU-16 tools"

subPackage {
  name "lem1802"
  description "Visual LEM1802 font editor"
  excludedSourceFiles "src/bconv.d"
  excludedSourceFiles "src/ddis.d"
  targetType "executable"
  targetName "lem1802"
  libs "gtkd" platform="windows"

  configuration "nogtk" {
platforms "windows"
  }
  configuration "gtk" {
platforms "posix"
dependency "gtk-d:gtkd" version="~>3.2.0"
  }


}

subPackage {
  name "bconv"
  description "Binary file conversor. Converts between different 
data files for DCPU-16 emulators"

  targetType "executable"
  targetName "bconv"
  excludedSourceFiles "src/lem1802_fontview.d"
  excludedSourceFiles "src/ddis.d"
  excludedSourceFiles "src/ui/*"
}

subPackage {
  name "ddis"
  description "Dis-assembler for DCPU-16. Generates a DCPU-16 
assembly dump from a binary file."

  targetType "executable"
  targetName "ddis"
  excludedSourceFiles "src/lem1802_fontview.d"
  excludedSourceFiles "src/bconv.d"
  excludedSourceFiles "src/ui/*"
}


 https://github.com/Zardoz89/DEDCPU-16/blob/master/dub.sdl

How to better organize dub project to get 3 exe from same codebase?

[Suliman via Digitalmars-d-learn]

I have got 3 small projects that have shared code base. At 
compile time they use few same classes. On runtime they use same 
config file. How to better to organize work with dub?

Re: Swift deprecate i++ and c-style for loop

[Steven Schveighoffer via Digitalmars-d]

On 2/24/16 3:47 PM, Ola Fosheim Grøstad wrote:

On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven Schveighoffer wrote:

I'm quite glad D stuck with the same type for arrays and array slices.


And how will you get around this when not having a GC?



I don't follow. D's arrays will always have a GC.

If you have a different type of array, it's a different type, it can do 
whatever it wants.


-Steve

Re: Pseudo-random numbers in [0, n), covering all numbers in n steps?

[tn via Digitalmars-d]

On Thursday, 25 February 2016 at 18:19:56 UTC, John Colvin wrote:
I don't know of an algorithm for generating random permutations 
that isn't in-place (or O(N) storage), but I'm not an expert on 
the topic so maybe one does exist.


These might be relevant:

http://stackoverflow.com/questions/10054732/create-a-random-permutation-of-1-n-in-constant-space

http://stackoverflow.com/questions/32182120/to-generate-random-permutation-of-a-array-in-on-time-and-o1-space

Re: Pseudo-random numbers in [0, n), covering all numbers in n steps?

[Andrei Alexandrescu via Digitalmars-d]

On 02/25/2016 01:19 PM, John Colvin wrote:

I don't think that's a good idea. A prng is closed path through a state
space and it doesn't matter where you start on said path, you're going
to follow the same closed path through the state space.


That's totally fine for some applications - those that simply want to 
iterate the input at most once in a random order. Far as I can tell this 
is the most frequent. I don't care for a second iteration to guarantee a 
different iteration schedule. And if I did, I'd have no trouble 
reseeding the generator. -- Andrei

Re: no size yet for forward reference error

[bachmeier via Digitalmars-d]

On Thursday, 25 February 2016 at 17:33:34 UTC, Jonathan M Davis 
wrote:


Actually, both of your examples compile for me - both with 
master and with 2.070.0. I'm running on x86_64 FreeBSD (which 
you probably aren't), which shouldn't matter for this sort of 
error, but I suppose that it's possible that it's somehow 
system-specific, much as I wouldn't expect it to be. So, I 
don't what to say. :|


- Jonathan M Davis


Same here. DMD 2.070.0 running on Linux Mint (built on Ubuntu 
14.04).

Re: Pseudo-random numbers in [0, n), covering all numbers in n steps?

[John Colvin via Digitalmars-d]

On Thursday, 25 February 2016 at 17:27:25 UTC, Andrei 
Alexandrescu wrote:
So we have 
https://dlang.org/phobos/std_random.html#.randomCover which 
needs to awkwardly allocate memory to keep track of the 
portions of the array already covered.


This could be fixed by devising a PRNG that takes a given 
period n and generates all numbers in [0, n) in exactly n steps.


However, I've had difficulty finding such PRNGs. Most want the 
maximum period possible so they're not concerned with a given 
period. Any insights?


I don't think that's a good idea. A prng is closed path through a 
state space and it doesn't matter where you start on said path, 
you're going to follow the same closed path through the state 
space.


I don't know of an algorithm for generating random permutations 
that isn't in-place (or O(N) storage), but I'm not an expert on 
the topic so maybe one does exist.

[Issue 11176] array.ptr in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #12 from Steven Schveighoffer  ---
(In reply to Kenji Hara from comment #11)
> I noticed that we already have equivalent but safer way [0]. Under @safe
> attribute, it checks the 'arr' boundaries and throws RangeError if the index
> access is invalid.
> 
> So, disabling arr.ptr would not have so big impact.

Excellent point! I think this solidifies the position we should have.

--

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 25 February 2016 at 17:57:49 UTC, David Nadlinger 
wrote:
I'm only playing devil's advocate because many people here make 
it seem as if there was no cost to supporting multiple 
compilers, while there most definitely is. This ranges from the 
blatant duplication of work over PR issues to the fact that big 
language/compiler features are all but impossible to implement 
for anybody but you, since you are the only one who knows how 
to implement them on DMD (and in the current situation, not 
having them available in DMD would be a deal-breaker).




It would be nice if the DMD frontend was completely uprooted from 
the DMD backend and put into separate git projects. The frontend 
should be completely agnostic from which backend it's using or 
else it's just more trouble the LDC/GDC developers have to deal 
with.

Re: D in Ubuntu apps ecosystem

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 25 February 2016 at 17:27:45 UTC, karabuta wrote:
SIDE NOTE: Ubuntu just lunched a phone with 4GB ram running on 
a x64 Octacore Arm processors in addition to a table with 
similar high spec, which can all pretty much handle D(even with 
GC) IMO.


You can run D with GC with 16 MB - yes, megabytes - of RAM. It'd 
be more comfortable with 32, sure, but the garbage collector 
isn't *that* much of a memory hog.

Re: Official compiler

[David Nadlinger via Digitalmars-d]

On Thursday, 25 February 2016 at 03:05:21 UTC, Walter Bright 
wrote:

On 2/18/2016 9:52 AM, Kai Nacke wrote:

I really like the compiler diversity.


Me too. Having 3 major implementations is a great source of 
strength for D.


I like it too. I just think that we can't afford it at this 
point, and that this is a major impediment for improving the 
quality of the D ecosystem.


 — David

Re: Official compiler

[David Nadlinger via Digitalmars-d]

On Thursday, 25 February 2016 at 02:58:08 UTC, Walter Bright 
wrote:
A big chunk of that was getting D to catch C++ exceptions. And 
before I did this work, neither GDC nor LDC did, either. It's 
not a simple matter of just turning it on given Dwarf EH.


That's beside the point, the C++ interop needed to be worked out 
either way and is not specific to the DMD backend. In that stupid 
example I gave, I was referring to the DWARF EH implementation 
itself, which will have taken you a non-negligible amount of time 
due to all the barely documented details, unless you are even 
more of a super-human compiler implementation expert than I 
already know you are. ;)


Don't get me wrong, I couldn't care less about the details of how 
long it took whom to implement C++ EH interop (or the fact that 
it did exist before in LDC/Calypso, and in the form of prototypes 
for vanilla GDC/LDC, etc.).


I'm only playing devil's advocate because many people here make 
it seem as if there was no cost to supporting multiple compilers, 
while there most definitely is. This ranges from the blatant 
duplication of work over PR issues to the fact that big 
language/compiler features are all but impossible to implement 
for anybody but you, since you are the only one who knows how to 
implement them on DMD (and in the current situation, not having 
them available in DMD would be a deal-breaker).


Sure, the fact that you know all the nitty-gritty details of one 
backend might make implementing certain changes easier for you, 
as you pointed out. But the fact that this one backend is obscure 
compared to the usual suspects, poorly documented and 
license-encumbered pretty much ensures that you will remain the 
only person to tackle such projects in the future.


 — David

Re: Shared static constructors from C# EXE

[Thalamus via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 16:05:37 UTC, Benjamin Thaut 
wrote:

On Thursday, 25 February 2016 at 14:42:14 UTC, Thalamus wrote:

your entry point.


Hi Guillaume,

Thanks for responding so quickly! I had found that wiki page 
before and I'd been following the "DLLs with a C Interface" 
section closely. I had forgotten to add -shared when building 
the DLL, but the behavior didn't change when I added it. So, I 
added a call to Runtime.initialize() as the first line of the 
endpoint I'm exposing. (I also made sure that this was the 
only endpoint invoked and that it was only invoked once just 
to be cautious.) I can see Runtime.initialize() being called, 
but the Class A shared static constructor still is not called 
when run from the C# EXE.


Do you have any other ideas?

In the meantime, I'm working on putting together a minimal 
repro source, but the scenario is a bit complicated so there's 
a lot of details to whittle away.


thanks!
Gene


You shouldn't be calling Runtime.initialize() manually. Just do 
the following in one of your source files:


import core.sys.windows.dll;
mixin SimpleDllMain;

This will generate a DllMain that will correctly initialize and 
deinitialize druntime.


Kind Regards
Benjamin Thaut


Thanks Benjamin. When I went to whittle this down to its barest 
essentials, though, the repro is pretty simple. It involves LIBs, 
but not Dlls, and it doesn't require anything but a single D EXE.


NOTE: if attempting to repro any of this, you must do a clean 
build after changing build.cmd or main.d before you'll see a 
change in behavior. I have the shared static ctors output files 
to make it really easy to see.


If you have Class A:

module ClassA;

import std.file;
import std.stdio;

export class ClassA
{
shared static this()
{
File file = File(r"c:\A.txt", "w");
file.writeln("Called A's shared static constructor."); 
file.flush();

file.close();
}
}

and you have Class B:

module ClassB;

import std.file;
import std.stdio;

export class ClassB
{
shared static this()
{
File file = File(r"c:\B.txt", "w");
file.writeln("Called B's shared static constructor."); 
file.flush();

file.close();
}
}

and you have main.d:

void main()
{
}

And you build it in one step into an EXE:

dmd -m64 -debug ClassA.d ClassB.d main.d -ofDriver.exe

Then you run Driver.exe, both A.txt and B.txt are created.

But, if you build it as a LIB and then link the LIB to the EXE:

dmd -c -lib -m64 -debug ClassA.d ClassB.d -ofInit.lib
dmd -m64 -debug Init.lib main.d -ofDriver.exe

When you run Driver.exe, neither are created. If you then add 
"import ClassA" to main.d and clean build, only A.txt will be 
created, or instead if you add "import ClassB", then only B.txt 
is created. Also, if either of these is included, Driver.exp and 
Driver.lib are emitted by the build, whereas otherwise they 
aren't.


It looks from this like a class in a linked LIB that is not 
directly imported will not have its shared static constructor 
called. Am I missing something obvious? :)


Long term I will need all this not only in separate LIBs but in 
separate DLLs. My scenario is roughly like this (-> indicate 
dependencies):


ClassA : IClass -> ClassManagement
ClassB : IClass -> ClassManagement
EntryPoint -> ClassManagement, ClassB, IClass

Then EntryPoint asks ClassManagement to give it an instance of 
ClassB's complement (ClassA). ClassManagement only knows anything 
about any of these classes via TypeInfo_Class object mappings, 
and it uses Object.factory to instantiate them. EntryPoint and 
its dependencies then work with that object via the IClass 
interface. I've gotten this to work in C# easily and C++ with 
some effort. (Class map population was, of course, very different 
for each, though.)


I can probably figure out a way to make this work for now, but if 
there's a way to ensure shared static ctors are run in this 
scenario without importing modules across separation boundaries, 
it would be a very good thing.


thanks!
Gene

Pseudo-random numbers in [0, n), covering all numbers in n steps?

[Andrei Alexandrescu via Digitalmars-d]

So we have https://dlang.org/phobos/std_random.html#.randomCover which 
needs to awkwardly allocate memory to keep track of the portions of the 
array already covered.


This could be fixed by devising a PRNG that takes a given period n and 
generates all numbers in [0, n) in exactly n steps.


However, I've had difficulty finding such PRNGs. Most want the maximum 
period possible so they're not concerned with a given period. Any insights?


BTW I found this statement in the documentation rather odd: "These 
issues will be resolved in a second-generation std.random that 
re-implements random number generators as reference types." The 
documentation is not a place for making vague promises and speculations 
about future developments. I think it should be removed.



Thanks,

Andrei

Re: no size yet for forward reference error

[Jonathan M Davis via Digitalmars-d]

On Thursday, 25 February 2016 at 04:23:52 UTC, Erik Smith wrote:
Here's a better reduction of the problem.  Commenting out 
either of the lines marked HERE eliminates the error.   It's 
some kind of interaction with templates, RefCounted, and the 
cross referencing types.


erik


module database;
import std.typecons;

unittest {
auto con = Connection!int();
}

struct Connection(T) {
alias Statement = .Statement!T;   // HERE
}

struct Statement(T) {
alias Connection = .Connection!T;

private:

struct Payload {
Connection con;
this(Connection con_) {con = con_;}
}

alias RefCounted!(Payload, RefCountedAutoInitialize.no) 
Data;

Data data_;  // HERE
}


Actually, both of your examples compile for me - both with master 
and with 2.070.0. I'm running on x86_64 FreeBSD (which you 
probably aren't), which shouldn't matter for this sort of error, 
but I suppose that it's possible that it's somehow 
system-specific, much as I wouldn't expect it to be. So, I don't 
what to say. :|


- Jonathan M Davis

Re: How to detect if an array if dynamic or static

[jmh530 via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 21:48:14 UTC, mahdi wrote:

Suppose we have a function like this:

void diss(int[] array) ...

How can we detect is `array` is static (fixed size) or dynamic, 
inside the function body?


I don't see that anyone has mentioned it but:

https://dlang.org/phobos/std_traits.html#isStaticArray
https://dlang.org/phobos/std_traits.html#isDynamicArray

D in Ubuntu apps ecosystem

[karabuta via Digitalmars-d]

Maybe you might only be thinking about Android or iOS, but Ubuntu 
Touch (a single Ubuntu OS meant to run across multiple devices 
from PC to Phones) is really gaining traction. The good news is 
that QML is officially the way to build apps and D already has 
dqml(https://github.com/filcuc/dqml). Back-end(optional) is also 
C++ with API bindings in Go and JavaScript. D currently has good 
support for C++.


SIDE NOTE: Ubuntu just lunched a phone with 4GB ram running on a 
x64 Octacore Arm processors in addition to a table with similar 
high spec, which can all pretty much handle D(even with GC) IMO. 
All subsequent devices will be high spec since the OS will run 
desktop apps on phone and even IoT.


So, do you not think Ubuntu ecosystem makes a good and easy to 
enter market? Unfortunately, I don't have the fuel and engine 
power to make API bindings, so anyone willing to help here?


http://www.ubuntu.com/phone
http://www.ubuntu.com/phone/features
http://www.ubuntu.com/tablet
https://developer.ubuntu.com/en/apps/qml/

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On Wednesday, 17 February 2016 at 20:11:10 UTC, anonymous wrote:

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136


No response to that either. I've also tried emailing two other 
addresses and Twitter. Nothing. What now?

[Issue 15711] Incorrect type inferring of [char]/string when passed via recursive template, extracting it from a structure field

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|RESOLVED|REOPENED
 CC||ag0ae...@gmail.com
 Resolution|INVALID |---

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Alexander Tumin from comment #2)
> According to cast table from https://dlang.org/spec/const3.html this is not
> bug at all and should be the defined behavior; const(char)[], what ['z'] is,
> cannot be implicitly converted to immutable(char)[], which what the string
> is.

`['z']` is an array literal, though. They're more flexible than that.

For example, dmd accepts these:

immutable(int)[] a = [1, 2, 3];
string s = ['z'];
Quu q = Quu(['z']);


I see no reason why the code in the description should be rejected when
`Quu(['z'])` is accepted usually. Reopening.

--

Re: Official compiler

[karabuta via Digitalmars-d]

On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright 
wrote:

On 2/17/2016 4:35 PM, Chris Wright wrote:

And since DMD is
something like twice as fast as LDC, there's at least some 
argument in

favor of keeping it around.


When I meet someone new who says they settled on D in their 
company for development, I casually ask why they selected D?


  "Because it compiles so fast."

It's not a minor issue.


+1 Well spoken

Re: Official compiler

[David Nadlinger via Digitalmars-d]

On Thursday, 25 February 2016 at 09:04:17 UTC, Russel Winder 
wrote:
I wonder if anyone has noticed, or appreciated that, all the 
trendy, hipster cloud based CI servers support Go, sometimes 
C++ and C (sort of), but not Rust, or D.


Travis CI, which is probably the one "trendy, hipster" service 
most would think of, has been supporting D for quite some while 
now due to Martin Nowak's great work. (He put Iain's name and 
mine on it too, but we didn't really contribute at all.)


Of course, there is always room for improving the integration 
with this and similar services. When I'm saying that dividing the 
attention between three compilers is a strategic mistake, it's 
not because I doubt that having multiple compilers is not a nice 
thing to have. It certainly is. But I'm convinced that expending 
the same amount of effort on the wider ecosystem would get us 
much farther.


 — David

Re: dub: how to reference a compiled package

[Chris Wright via Digitalmars-d-learn]

On Thu, 25 Feb 2016 12:15:42 +, mahdi wrote:

> Hi,
> 
> Suppose I have a package `mypack` in `~/mypack`. I run `dub` command on
> this package and have the compiled `mypack` file (OS is Linux).
> 
> Now I am working on my project. I know how to use the source-code of
> `mypack` package in the project but what if I only have the compiled
> binary? How can I reference and use the modules of the compiled
> `mypack`?
> 
> (I looked into the DUB homepage and it's Getting Started page but could
> not find anything).

First thing, you need D interface files. See:
https://dlang.org/dmd-linux.html#interface-files

Note that D interface files still require you to include the full body of 
anything in a template, so you might have to modify your code somewhat 
for improved secrecy.

Copy the *.di files and binaries into another dub project and add a 
postBuildCommand to copy that binary to the output location.

I think that will work. dub might complain that it doesn't have any 
source files, in which case you'll have to provide at least one D file 
for it to compile, but that can be empty.

Re: Official compiler

[karabuta via Digitalmars-d]

On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis 
wrote:

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
even if DMD is the official reference compiler, the download 
page http://dlang.org/download.html already mentions "strong 
optimization" as pro of GDC/LDC vs. "very fast compilation 
speeds" as pro of DMD.


If we would make GDC or LDC the official compiler then the 
next question which pops up is about compilation speed


Yeah. dmd's compilation speed has been a huge win for us and 
tends to make a very good first impression. And as far as 
development goes, fast compilation speed matters a lot more 
than fast binaries. So, assuming that they're compatible enough 
(which ideally they are but aren't always), I would argue that 
the best approach would be to use dmd to develop your code and 
then use gdc or ldc to build the production binary. We benefit 
by having all of these compilers, and I seriously question that 
changing which one is the "official" one is going to help any. 
It just shifts which set of complaints we get.


- Jonathan M Davis


Yep. Fast compilation during development must not be sacrificed 
for fast binaries. What are you really building to have fast 
binaries during development?


However, I strongly agree with cleaning up the language instead 
of adding more features.