Re: Static CT Factory

[Engine Machine via Digitalmars-d-learn]

On Friday, 19 August 2016 at 02:54:48 UTC, Basile B. wrote:

On Friday, 19 August 2016 at 01:53:22 UTC, Engine Machine wrote:

On Friday, 19 August 2016 at 01:25:10 UTC, Anonymouse wrote:

On Friday, 19 August 2016 at 01:10:42 UTC, Engine Machine

x = 1.234;

Ok, well, I guess the error comes from something else.


*x = 1.234 for when T verifies is(T == int*) produces an error.

You can put an aditional argument in the function header:

void foo(T)(auto ref T t = T.init)
{
static if (is(T == int))
auto x = new Thing!int;
else static if (is(T == double))
auto x = new Thing!double;
else
static assert(false, "incorrect type");
*x = t;
}


It was because I had a added a new type that I didn't account for 
in the static if chain ;/ The static assert is sort of required. 
We sort of need a static switch with required default so 
forgetting this stuff doesn't break later on(in strange ways) 
when new types are added.

Re: Why D is not popular enough?

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
Garbage collector is in a few libraries as well. I think the 
only problem I had with that is that the std.range library has 
severely reduced functionality when using static arrays.


std.range is one of the libraries that has never used the GC 
much. Only tiny parts of it ever have,


Moreover, dynamic arrays do not necessarily have to be GC'd. 
Heck, you can even malloc them if you want to 
(`(cast(int*)malloc(int.sizeof))[0 .. 1]` gives an int[] of 
length 1).


This has been a common misconception lately... :(


Well you could say the same for the same for int. Why isn't 
"int + int = long"?


Yeah, if I was designing things, I'd make it promote the smaller 
size to the larger size in the expression. So byte + byte = byte 
and byte + short goes to short, and so on. Moreover, I'd make it 
check both sides of the equation, so int = byte + byte would 
convert the bytes to ints first too. It'd be quite nice, and I 
think it would work in most cases... it might even work the same 
as C in most cases, though I'm not sure.


(the one thing people might find weird is auto a = b + c; means a 
is a byte if b and c are bytes. In C, it would be an int. but who 
writes that in C anyway.)



Alas, C insisted on making everything int all the time and D 
followed that :(

Re: [OT] of [OT] I am a developer and I hate documentation

[Adam D. Ruppe via Digitalmars-d]

On Friday, 19 August 2016 at 02:49:41 UTC, Yuxuan Shui wrote:
We should be able to automate this task if we do decide to move 
away from it. Can't be harder than converting C++ to D, 
right?


Yeah. I'm being a bit facetious there: I actually already did it 
and the result is on my dpldocs.info site.


There's still a few rough edges that I'm working on slowly but 
surely, but the bulk of the work has been done for a while.

Re: Static CT Factory

[Basile B. via Digitalmars-d-learn]

On Friday, 19 August 2016 at 01:53:22 UTC, Engine Machine wrote:

On Friday, 19 August 2016 at 01:25:10 UTC, Anonymouse wrote:

On Friday, 19 August 2016 at 01:10:42 UTC, Engine Machine

x = 1.234;

Ok, well, I guess the error comes from something else.


*x = 1.234 for when T verifies is(T == int*) produces an error.

You can put an aditional argument in the function header:

void foo(T)(auto ref T t = T.init)
{
static if (is(T == int))
auto x = new Thing!int;
else static if (is(T == double))
auto x = new Thing!double;
else
static assert(false, "incorrect type");
*x = t;
}

[Issue 16112] Replace ddoc with markdown

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
Does markdown allow defining macros?

--

Re: [OT] of [OT] I am a developer and I hate documentation

[Yuxuan Shui via Digitalmars-d]

On Friday, 19 August 2016 at 01:32:55 UTC, Adam D. Ruppe wrote:

On Thursday, 18 August 2016 at 23:50:34 UTC, karabuta wrote:
That will be way better, don't know why markdown is not used 
already.


ddoc is *significantly* older than markdown, especially for 
popular use.


When ddoc came out, *it* was the "clean" syntax for inline 
docs. But then Walter fell a bit too much in love with it...



Ddoc was poorly designed, Walter's lack of experience in web 
matters shows pretty clearly in it, but it wasn't necessarily a 
bad decision for its time, then it just got entrenched.


If we wanted to move away from it, someone would have to write 
a new generator and fork the docs and do thousands of changes 
to bring them to a new system


I don't know anyone crazy enough to do that.

http://dpldocs.info


We should be able to automate this task if we do decide to move 
away from it. Can't be harder than converting C++ to D, right?

Re: Static CT Factory

[Engine Machine via Digitalmars-d-learn]

On Friday, 19 August 2016 at 01:18:28 UTC, Adam D. Ruppe wrote:

On Friday, 19 August 2016 at 01:10:42 UTC, Engine Machine wrote:
I feel that in this case I feel that the scope of the static 
if should allow things to escape since, well, they are static 
if's.



They do.

What, exactly, did you do and what, exactly did you see as the 
error?


I get undefined identifier, but when create the variable outside 
it works.


I used Anonymouse code and it works so I guess the issue stems 
from something else.


My code is more complex and the stuff is in a foreach. I don't 
know why it isn't working since the simplified code is nearly 
identical. Maybe a branch wasn't being taken, I thought I covered 
them all.

Re: Static CT Factory

[Engine Machine via Digitalmars-d-learn]

On Friday, 19 August 2016 at 01:25:10 UTC, Anonymouse wrote:

On Friday, 19 August 2016 at 01:10:42 UTC, Engine Machine wrote:
I have a template that is suppose to create a type based on a 
template parameter


static if (T == "int")
{
   auto x = New!int();
}
else static if (T == "double")
{
   auto x = New!double();
}

x = 1.234;


This is just an example, I use custom types.

The static if's prevent x's scope from being after them, even 
though it should work perfectly fine. I can't declare x before 
because I don't know the type.


I'm not sure I understand. static if shouldn't introduce a new 
scope that way.


https://dpaste.dzfl.pl/7b63a6e52309

Mind that x might be a pointer.


Ok, well, I guess the error comes from something else.

Re: [OT] of [OT] I am a developer and I hate documentation

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 18 August 2016 at 23:50:34 UTC, karabuta wrote:
That will be way better, don't know why markdown is not used 
already.


ddoc is *significantly* older than markdown, especially for 
popular use.


When ddoc came out, *it* was the "clean" syntax for inline docs. 
But then Walter fell a bit too much in love with it...



Ddoc was poorly designed, Walter's lack of experience in web 
matters shows pretty clearly in it, but it wasn't necessarily a 
bad decision for its time, then it just got entrenched.


If we wanted to move away from it, someone would have to write a 
new generator and fork the docs and do thousands of changes to 
bring them to a new system


I don't know anyone crazy enough to do that.

http://dpldocs.info

Re: Static CT Factory

[Anonymouse via Digitalmars-d-learn]

On Friday, 19 August 2016 at 01:10:42 UTC, Engine Machine wrote:
I have a template that is suppose to create a type based on a 
template parameter


static if (T == "int")
{
   auto x = New!int();
}
else static if (T == "double")
{
   auto x = New!double();
}

x = 1.234;


This is just an example, I use custom types.

The static if's prevent x's scope from being after them, even 
though it should work perfectly fine. I can't declare x before 
because I don't know the type.


I'm not sure I understand. static if shouldn't introduce a new 
scope that way.


https://dpaste.dzfl.pl/7b63a6e52309

Mind that x might be a pointer.

Static CT Factory

[Engine Machine via Digitalmars-d-learn]

I have a template that is suppose to create a type based on a 
template parameter


static if (T == "int")
{
   auto x = New!int();
}
else static if (T == "double")
{
   auto x = New!double();
}

x = 1.234;


This is just an example, I use custom types.

The static if's prevent x's scope from being after them, even 
though it should work perfectly fine. I can't declare x before 
because I don't know the type.


The point is that I don't want to have to put x = 1.234; in each 
static if block when I should be able to do it perfectly fine 
afterwards.


My types that I'm creating all have a name field and I want to 
set it once after the object is created.


Luckily, all of them inherit from the same type and I can declare 
that before the static if block, but in general, that won't work.


I feel that in this case I feel that the scope of the static if 
should allow things to escape since, well, they are static if's. 
It would be similar to #ifdef.


I realize that D doesn't work this way, I'm asking for a nicer 
solution than having to duplicate the same code(x = 1.234 in this 
example) or having use a base class.

Re: [OT] of [OT] I am a developer and I hate documentation

[Seb via Digitalmars-d]

On Thursday, 18 August 2016 at 23:14:44 UTC, H. S. Teoh wrote:
On Fri, Aug 19, 2016 at 12:02:09AM +0200, Marco Leise via 
Digitalmars-d wrote: [...]
By the way, AFAIK someone implemented `code` as an alternative 
to $(D code) quite a while ago. So you can use that instead.  
I'd like ordered/unordered lists to also follow markup style 
one day. I find it more natural and readable than


$(OL
  $(LI first item)
  $(LI another important thing)
)

[...]

Sigh.  Eventually we're just reinventing Markdown in ddoc. Why 
can't we just use Markdown (with some ddoc extensions) in the 
first place?



T


In my childish naivity I opened an enhancement request recently:

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

Re: [OT] I am a developer and I hate documentation

[karabuta via Digitalmars-d]

On Thursday, 18 August 2016 at 08:40:23 UTC, Kagamin wrote:
Article: 
https://dzone.com/articles/why-developers-write-horrible-documentation-and-ho
Also: 
https://www.reddit.com/r/programming/comments/4y6pws/why_video_documentation_isnt_the_answer/


Ha ha ha! I read the article :) What sort of thinking went into 
writing this article?


Videos as documentation? So when you want to understand a single 
function, you just search for that section in the video which a 
bet will take more time. If you cannot write well (with all the 
corrections you can make when writing), how can you speak well in 
one shot.


So the question is, "Are programmers good verbal communicators 
than writers or vice versa"?


"Damian Wolf is an tech enthusiast and marketing professional. 
He loves to write about cloud technology, knowledge management 
and business performance.".

Mhmm, that's why.


Developers Don't Need Documentation



Video documentation is the answer.

This article is dangerous

Re: [OT] of [OT] I am a developer and I hate documentation

[karabuta via Digitalmars-d]

On Thursday, 18 August 2016 at 23:14:44 UTC, H. S. Teoh wrote:
On Fri, Aug 19, 2016 at 12:02:09AM +0200, Marco Leise via 
Digitalmars-d wrote: [...]
By the way, AFAIK someone implemented `code` as an alternative 
to $(D code) quite a while ago. So you can use that instead.  
I'd like ordered/unordered lists to also follow markup style 
one day. I find it more natural and readable than


$(OL
  $(LI first item)
  $(LI another important thing)
)

[...]

Sigh.  Eventually we're just reinventing Markdown in ddoc. Why 
can't we just use Markdown (with some ddoc extensions) in the 
first place?



T


That will be way better, don't know why markdown is not used 
already.


.

Cant imagine how a compiler generated documentation for D 
templates will look like :)

Re: Why D is not popular enough?

[ag0aep6g via Digitalmars-d]

On 08/19/2016 12:50 AM, John Smith wrote:

Well there are some things I feel could be improved, a lot of the things
are really just minor but what is a deal breaker for me mostly is the
compilers. The GCC and Clang implementations are really far behind in
terms of the version, so they are missing a lot of features. A lot of
the features that I'd want to use D for.


LDC has been catching up quite nicely. LDC 1.0.0 (current release) is at 
front-end 2.070, and 1.1.0 (beta) is at 2.071 which matches the current 
DMD release.


https://github.com/ldc-developers/ldc/releases


In the download section it also
says "good optimization" but it honestly isn't. I rewrote a small
portion for one of my projects to test out D but looking at the assembly
a lot of it was questionable. I'd say DMD probably produced the best
assembly but then there's the problem that it doesn't support MMX
instructions.


I'm not very knowledgeable on optimized machine code, but as far I know, 
LDC/GDC usually produce significantly faster binaries than DMD. So when 
DMD comes out ahead, that's not typical. Might be an outlier.


[...]

Anyways for some more minor things. I really don't like __gshared, why
couldn't it just be named "gshared" instead. Don't like how that naming
convention is used in C/C++ either but I feel here in D it is completely
out of place. Nothing else uses a preceding "__" and from the
documentation it looks like it's made to stand out cause it shouldn't be
used.


That's exactly it. `__gshared` has a weird name because `shared` should 
generally be used instead. `__gshared` throws thread-safety out the 
window, while `shared` is supposed to at least make sure that the 
shared-ness is visible to the programmer.



But it is used a lot, and it wouldn't be possible to do certain
things without it. I forget but the dynamic library loader for D,
derelict, is one such case.


Those certain things should be relatively rare low-level tasks. When 
`__gshared` is used more than `shared`, then `shared` may (currently) be 
failing its goals. Of course, a low-level project like Derelict may just 
have more use for `__gshared`.



There's no "const T&" equivalent in D. Basically constant variables need
to be copied and non-constant variables can be passed with the use of
"ref". So you need to write two different functions that in essence do
the same thing.


You can pass const variables per ref: void foo(ref const int bar) {}

What you can't do is pass rvalues in such a parameter. That's what the 
other function/overload is needed for. That doesn't mean that everything 
is just fine as it is.


[...]

Garbage collector is in a few libraries as well. I think the only
problem I had with that is that the std.range library has severely
reduced functionality when using static arrays.


You may be aware of this, but you can slice a T[n] to get a T[] which is 
a range.


[...]

Well you could say the same for the same for int. Why isn't "int + int =
long"? Right now it is following the rule "int + int = int". Maybe cause
the values aren't as small but I could argue the same thing. If we add
2147483647 with 2147483647, the value stored is -2. Under the same sort
of thought, you probably wouldn't find that acceptable either correct?
At some point you are going to run out of types that have larger
storage. What is "cent + cent" going to have as a larger type? At some
point you just have to accept that you are working with a finite set of
numbers. For D the compromise happens with the type int. C/C++ just
accepts that and maintains consistency rather than flip floping at an
arbitrary type.


I don't think that C "just accepts that". It still promotes a sum of 
smaller types to int.


Observe:


#include

int main()
{
unsigned char a = 255;

printf("%d\n", (a + a) / 2); /* 255 */
printf("%d\n", (unsigned char)(a + a) / 2); /* 127 */

return 0;
}


If `a + a` were an unsigned char, we'd expect the two outputs to be the 
same.


The difference between D and C is that C has implicit narrowing. I.e., 
it lets you assign an int to a char just like that, throwing away the 
high bits. D requires a cast for it.


So, why is int the go-to type? I can't answer with authority, but for D 
I think it's just because that's what C does.

Re: [OT] of [OT] I am a developer and I hate documentation

[H. S. Teoh via Digitalmars-d]

On Fri, Aug 19, 2016 at 12:02:09AM +0200, Marco Leise via Digitalmars-d wrote:
[...]
> By the way, AFAIK someone implemented `code` as an alternative to $(D
> code) quite a while ago. So you can use that instead.  I'd like
> ordered/unordered lists to also follow markup style one day. I find it
> more natural and readable than
> 
> $(OL
>   $(LI first item)
>   $(LI another important thing)
> )
[...]

Sigh.  Eventually we're just reinventing Markdown in ddoc. Why can't we
just use Markdown (with some ddoc extensions) in the first place?


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

Re: Why D is not popular enough?

[Seb via Digitalmars-d]

Hei John, I read over the first part of your message and it seems 
that same information you got is quite outdated:


On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
Well there are some things I feel could be improved, a lot of 
the things are really just minor but what is a deal breaker for 
me mostly is the compilers. The GCC and Clang implementations 
are really far behind in terms of the version, so they are 
missing a lot of features. A lot of the features that I'd want 
to use D for.


That's not true for LDC - it's on par with the latest DMD version 
since a while now. It might be that the version shipped with your 
Linux distribution is a bit outdated.


http://forum.dlang.org/post/uxupejapglpeokaiq...@forum.dlang.org


In the download section it also says "good optimization" but it 
honestly isn't. I rewrote a small portion for one of my 
projects to test out D but looking at the assembly a lot of it 
was questionable. I'd say DMD probably produced the best 
assembly but then there's the problem that it doesn't support 
MMX instructions.


That's weird - LDC allows great optimization, see e.g. these two 
benchmarks:


https://github.com/kostya/benchmarks
http://forum.dlang.org/post/zxkkjezakirlfepnd...@forum.dlang.org

Even on 64-bit it still uses the FPU, which I can't really use. 
The FPU isn't consistent enough for simulations that run on 
separate computers and different OSs that need to be synced 
through a network.


Inconsistent FP math is a known issue, but most likely a 
fusedMath pragma will be added soon:


http://forum.dlang.org/post/hjaiavlfkoamenido...@forum.dlang.org
https://github.com/ldc-developers/ldc/issues/1669

Anyways for some more minor things. I really don't like 
__gshared, why couldn't it just be named "gshared" instead. 
Don't like how that naming convention is used in C/C++ either 
but I feel here in D it is completely out of place. Nothing 
else uses a preceding "__" and from the documentation it looks 
like it's made to stand out cause it shouldn't be used. But it 
is used a lot, and it wouldn't be possible to do certain things 
without it. I forget but the dynamic library loader for D, 
derelict, is one such case.


Yep you are correct about the motivation: __gshared got its ugly 
name to remind

the programmer about the dangerous world he wades into.
There are usually safer & more elegant ways, e.g.:

http://tour.dlang.io/tour/en/multithreading/std-parallelism
http://tour.dlang.io/tour/en/multithreading/synchronization-sharing
http://tour.dlang.io/tour/en/multithreading/message-passing

Re: Why D is not popular enough?

[John Smith via Digitalmars-d]

Well there are some things I feel could be improved, a lot of the 
things are really just minor but what is a deal breaker for me 
mostly is the compilers. The GCC and Clang implementations are 
really far behind in terms of the version, so they are missing a 
lot of features. A lot of the features that I'd want to use D 
for. In the download section it also says "good optimization" but 
it honestly isn't. I rewrote a small portion for one of my 
projects to test out D but looking at the assembly a lot of it 
was questionable. I'd say DMD probably produced the best assembly 
but then there's the problem that it doesn't support MMX 
instructions. Even on 64-bit it still uses the FPU, which I can't 
really use. The FPU isn't consistent enough for simulations that 
run on separate computers and different OSs that need to be 
synced through a network.


Anyways for some more minor things. I really don't like 
__gshared, why couldn't it just be named "gshared" instead. Don't 
like how that naming convention is used in C/C++ either but I 
feel here in D it is completely out of place. Nothing else uses a 
preceding "__" and from the documentation it looks like it's made 
to stand out cause it shouldn't be used. But it is used a lot, 
and it wouldn't be possible to do certain things without it. I 
forget but the dynamic library loader for D, derelict, is one 
such case.


There's no "const T&" equivalent in D. Basically constant 
variables need to be copied and non-constant variables can be 
passed with the use of "ref". So you need to write two different 
functions that in essence do the same thing. One way around the 
code duplication is using templates so that it auto generates 
these variants for you, but then there's code bloat cause each 
parameter could then be a copy or a "ref". This leads to a lot of 
extra copies, depending on the object and it's size it might not 
be desirable. It thus limits code where you could do a one line 
operation like: 
"someObject.process(otherObject.generateLargeConstantObject());". 
In this case there will be an extra copy made, and currently none 
of compilers are able to optimize it out. It seems like it is 
possible for the compiler to be able to optimize it so no copies 
are made but that's not the case currently which goes back my 
main argument I guess. I can see the value in not having a 
"const&" but the current implementation is flawed.


http://ideone.com/INGSsZ

Garbage collector is in a few libraries as well. I think the only 
problem I had with that is that the std.range library has 
severely reduced functionality when using static arrays.


I think there was more but it was a while since I used D and 
don't recall. There are significant improvements to D over C++ 
that I do love, really want to be able to use it. Whenever I run 
into an issue with C++ I just think about D and how I could have 
solved that problem easily.


On Sunday, 14 August 2016 at 18:45:06 UTC, Walter Bright wrote:
This rule was retained for D to make it easier to translate 
code from C/C++ to D. Changing the rule could result in subtle 
and invisible bugs for such translations and for C/C++ 
programmers who are so used to the integral promotion rules 
that they aren't even really aware of reliance upon them.


The reason C/C++ programmers, even experienced ones, are often 
unaware of this rule is there is another rule, implicit 
narrowing, so:


byte = byte + byte;

compiles without complaint. The trouble comes when byte has a 
value, say, 255, and the sum is 510. The assignment silently 
chops it to byte size, and 254 is stored in the result.


For D, we decided that silently converting 510 to 254 would not 
be acceptable. Hence an explicit cast would be required,


byte = cast(byte)(byte + byte);


Well you could say the same for the same for int. Why isn't "int 
+ int = long"? Right now it is following the rule "int + int = 
int". Maybe cause the values aren't as small but I could argue 
the same thing. If we add 2147483647 with 2147483647, the value 
stored is -2. Under the same sort of thought, you probably 
wouldn't find that acceptable either correct? At some point you 
are going to run out of types that have larger storage. What is 
"cent + cent" going to have as a larger type? At some point you 
just have to accept that you are working with a finite set of 
numbers. For D the compromise happens with the type int. C/C++ 
just accepts that and maintains consistency rather than flip 
floping at an arbitrary type.

Re: Aedi - a dependency injection library

[Rory McGuire via Digitalmars-d-announce]

On Thu, Aug 18, 2016 at 8:56 PM, Alexandru Ermicioi via
Digitalmars-d-announce  wrote:

> On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote:
>
>> On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" <
>> digitalmars-d-announce@puremagic.com> wrote:
>>
>>>
>>> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>>

 On 2016-08-16 11:41, Alexandru Ermicioi wrote:

 https://github.com/aermicioi/aedi
>


 If you use:

 ```d
 ```

 For the code block you'll get syntax highlighting for D.

>>>
>>>
>>> Thx, for info. Didn't know about such syntax. I'll update it with next
>>>
>> batch of modifications.
>>
>> Can this be used to do function
>> currying? http://stackoverflow.com/questions/36314/what-is-currying
>>
>> Seems like an interesting feature. I imagine it would use templates or a
>> wrapper struct instead of wrapped functions though.
>>
>
> Thank you, for sharing with an idea :)
>
> I'm not sure if I understand your proposition correctly.
>
> I assume that you meant the call of register function on container to
> register an object in it. If so, by applying currying, we would get
> something like:
>
> container.register!Type()("constructor")("setter", "setterArg"); // And
> so on.
>
> It's an interesting idea, but I'm not sure if it will allow an easy
> customization of register api :(.
>
> Could you please explain it in more detail?
>

No probs, example:
/
module m1;
/// this module contains standard functions / classes etc...
auto func1(Type1 v1, Type2 v2, Type3 v3) {
// do awesome stuff with all three instances
}

class A {
Type4 v4;
Type5 v5;
this(Type4 v4, Type5 v5) {
this.v4 =v4; this.v5=v5;
}
void changeMode(Type2 v2) {
v4.asdf(v2);
}
void opApply(...) {
/// do normal stuff with all these manually passed in instances
}
}

module auto_deps_m1;
/// this module has the curryied versions of the original functions and
classes from m1;
/// What I think would be cool, and I thinks its possible, would be to
automatically inject default instance parameters into classes (the Object),
and functions.
/// so func1 could for example be exposed in this module as:
auto func1(Type2 v2) {
   /// yeah, don't worry about passing the other stuff in, it was all setup
during dependency registration
}

class A {
Type4 v4; /// inject this
Type5 v5;
this(Type5 v5) {
this.v5 = v5; // we never registered a Type5 during dependency
registration
this.v4.changeMode(registered_v2); /// this got moved here due to
compile time dependency registration
}
void opApply(...) {
// do stuff, and all we had to supply in other modules that depend
on this one is the instance for v5
}
}

//


The function example is what I was thinking initially, but I don't see why
it couldn't be done with structs and classes as well.

I guess in m2 the code the programmer writes would be similar to:
mixin(registrationService.ct_register!(func1));

etc..

If its not possible right now I'd imagine its fairly close to possible.


disclaimer: I'm not very familiar with dependency injection in anything but
Javascript with AngularJS.

[Issue 16403] New: wrong "matches more than one template declaration" error with template specialization on alias parameters

[via Digitalmars-d-bugs]

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

  Issue ID: 16403
   Summary: wrong "matches more than one template declaration"
error with template specialization on alias parameters
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


struct S(T) {}

/* This should work, but fails: */

enum fails(alias Tmpl, alias Inst : Tmpl!A, A) = true;
enum fails(alias Tmpl, alias Inst) = false;
static assert(fails!(S, S!int)); /* Error: template test.fails matches more
than one template declaration */

/* These variations work: */

enum works1(alias Inst : S!A, A) = true;
enum works1(alias Inst) = false;
static assert(works1!(S!int)); /* passes */

enum works2(alias Tmpl, Inst : Tmpl!A, A) = true;
enum works2(alias Tmpl, Inst) = false;
static assert(works2!(S, S!int)); /* passes */


--

[Issue 10170] __traits(compiles,b.x)) incorrectly allows to access private members

[via Digitalmars-d-bugs]

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

Artem Borisovskiy  changed:

   What|Removed |Added

 CC||kolo...@bk.ru
   Severity|normal  |major

--

Re: [OT] of [OT] I am a developer and I hate documentation

[Marco Leise via Digitalmars-d]

Am Thu, 18 Aug 2016 14:59:08 +
schrieb Chris :

> On Thursday, 18 August 2016 at 14:31:47 UTC, Adam D. Ruppe wrote:
> It would be a good starting point for documentation stubs, not a 
> substitute for a proper, full-fledged documentation. The most 
> annoying thing about writing docs is the amount of boilerplate, 
> not the doc itself, cf:
> 
> /**
> Find $(D value) _among $(D values), returning the 1-based index
> of the first matching value in $(D values), or $(D 0) if $(D 
> value)
> is not _among $(D values). The predicate $(D pred) is used to
> compare values, and uses equality by default.
> Params:
>  pred = The predicate used to compare the values.
>  value = The value to search for.
>  values = The values to compare the value to.
> Returns:
>  0 if value was not found among the values, otherwise the 
> index of the
>  found value plus one is returned.
> 
> [...]
> */
> 
> If `Params` and `Returns` were generated automagically, at least 
> as stubs, then it would be easier to write the "true" 
> description, i.e. if you had something like:
> 
> /**
> 
> Params:
>  pred =
>  value =
>  values =
> Returns:
>  (unit) 0 || index + 2
> */

My take on it is to document the Params where they are
declared:

int mul2(int x /** the value to be multiplied by 2 */)
{
  return 2*x;
}

People have been doing that in the past with or without
documentation generators for the benefit that you don't need
to repeat yourself and don't need to update the docs after an
argument name refactoring.

By the way, AFAIK someone implemented `code` as an alternative
to $(D code) quite a while ago. So you can use that instead.
I'd like ordered/unordered lists to also follow markup style
one day. I find it more natural and readable than

$(OL
  $(LI first item)
  $(LI another important thing)
)

-- 
Marco

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

[Yuxuan Shui via Digitalmars-d]

On Thursday, 18 August 2016 at 07:04:41 UTC, Jacob Carlborg wrote:

On 2016-08-18 03:21, Yuxuan Shui wrote:


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


You mean:

void foo(scope void delegate() dg);

Or:

void bar(void delegate() dg);

scope void delegate() a = {};
bar(a);


Delegates are pretty much a struct that holds references, right? 
So they are kinda like pointers.


I wish I can enforce scope rules (DIP1000) on them. For example, 
scope delegate should not be able to hold reference to variables 
with shorter lifetime than the delegate itself. With this we then 
could have delegates in @nogc code.

Re: Aedi - a dependency injection library

[Alexandru Ermicioi via Digitalmars-d-announce]

On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote:
On 16 Aug 2016 20:45, "Alexandru Ermicioi via 
Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> 
wrote:


On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg 
wrote:


On 2016-08-16 11:41, Alexandru Ermicioi wrote:


https://github.com/aermicioi/aedi



If you use:

```d
```

For the code block you'll get syntax highlighting for D.



Thx, for info. Didn't know about such syntax. I'll update it 
with next

batch of modifications.

Can this be used to do function
currying? 
http://stackoverflow.com/questions/36314/what-is-currying


Seems like an interesting feature. I imagine it would use 
templates or a wrapper struct instead of wrapped functions 
though.


Thank you, for sharing with an idea :)

I'm not sure if I understand your proposition correctly.

I assume that you meant the call of register function on 
container to register an object in it. If so, by applying 
currying, we would get something like:


container.register!Type()("constructor")("setter", "setterArg"); 
// And so on.


It's an interesting idea, but I'm not sure if it will allow an 
easy customization of register api :(.


Could you please explain it in more detail?

Re: Why 16Mib static array size limit?

[Ali Çehreli via Digitalmars-d]

On 08/18/2016 05:20 AM, Johan Engelen wrote:

> `arr` is a global symbol that can be modified by code
> not seen by the compiler. So no assumptions can be made about the
> contents of arr.ptr and arr.length

Yet there is the following text in the spec:

* https://dlang.org/spec/statement.html#ForeachStatement

  "The aggregate must be loop invariant, meaning that elements to
   the aggregate cannot be added or removed from it in the
   NoScopeNonEmptyStatement."

I think the spirit of the spec includes other code outside of 
NoScopeNonEmptyStatement as well. If so, if elements are added to the 
array from other code (e.g. other threads) it should be a case of "all 
bets are off". So, I think both .ptr and .length could be cached.


Ali

Re: [OT] of [OT] I am a developer and I hate documentation

[H. S. Teoh via Digitalmars-d]

On Thu, Aug 18, 2016 at 04:56:32PM +, ketmar via Digitalmars-d wrote:
> On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:
> > if the stub reads:
> > 
> > /**
> >  * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> >  * Params:
> >  *  x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> >  *  y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> >  * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
> >  */
> > int myFunc(int x, int y) { ... }
> > 
> > :-P
> i assure you that programmers will still be too lazy to fill the docs.
> but they *will* spend alot of time rebuilding (or hex-editing if there
> is no source) their IDE to replace the message.

Haha, too true!


T

-- 
Without geometry, life would be pointless. -- VS

Re: RSA library

[Andre via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 14:29:54 UTC, Adam D. Ruppe wrote:

On Thursday, 18 August 2016 at 09:00:58 UTC, Andre Pany wrote:
Is there a D library which can be built with a plain x86 DMD 
and without dll dependencies?


Not that I know of, and I don't think the win32 api includes 
rsa256 (though .net does!).


The botan lib though, why doesn't it work on 32 bit optlink? 
You might be able to hack it by just taking the algorithms you 
need and compiling yourself.


It is a statement from the botan github readme, maybe due to a 
dependency.


I will try the windows api, from the description it seems exactly 
what i need. I will also check wheter the specific botan part 
could be extracted.

Thanks a lot.

Kind regards
Andre

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

[Dicebot via Digitalmars-d]

On Thursday, 18 August 2016 at 06:29:07 UTC, Ali Çehreli wrote:

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

Right.

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

However, as my test code demonstrates, even when the lambda 
refers to stack local variable, closure is NOT allocated in the 
case of the function call. As far as I can tell, the actual 
reason for the allocation is the struct object that filter() 
returns.


I am trying to understand why the struct object requires the 
closure allocation. I made myself believe that this is the 
reason: Being an alias template parameter, the lambda is a part 
of the type (the instantiation of the struct template). Even 
though the compiler could determine that the single object does 
not escape, its type can be used again.


Your main mistake seems to be an expectation of complete flow 
analysis in compiler while in fact it is virtually non-existent. 
DMD frontend can't prove that references to stack don't escape in 
all but most simple cases (where all involved code is fully 
inlined and no actual function/struct has to be generated).


For example, in your struct case it can't know that you won't 
eventually return that struct instance from function or do 
something similar. Such analysis is simply not performed, thus it 
has to generate code conservatively. The problem you mention is 
likely to be present with current frontend too but that is not a 
crucial technical limitation on its own because fully qualified 
type of such S instantiation would include function-local context 
and compiler can use it to tell that type can be optimized as 
function-local unless any references escape.


From my own encounters vast majority of issues of that kind could 
be solved by one of two relatively simple solutions:


1) Being able to capture context in lambda by value (Right now I 
tend to use custom structs with `opCall` instead of built-in 
lambdas for such cases)


2) Allowing compiler to treat `pragma(inline, true)` functions as 
ones that never generate own object code and thus can be analyzed 
in usage contexts separately.

Re: [OT] of [OT] I am a developer and I hate documentation

[Fool via Digitalmars-d]

On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:

/**
 * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Params:
 *  x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 *  y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 */
int myFunc(int x, int y) { ... }


s/\/$USERNAME/g

/**
 * S. TEOH WAS TOO LAZY TO FILL THIS IN
 * Params:
 *  x = S. TEOH WAS TOO LAZY TO FILL THIS IN
 *  y = S. TEOH WAS TOO LAZY TO FILL THIS IN
 * Returns: S. TEOH WAS TOO LAZY TO FILL THIS IN
 */
int myFunc(int x, int y) { ... }

:-P

Re: DIP1000: Scoped Pointers

[Dicebot via Digitalmars-d-announce]

On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
> That will just leave one hole in conjunction with the @trusted
> destructor, which is (presumably) not easy to fix without much larger
> changes to the type system, as well as to how container types are built.
> It is still vulnerable to artificial shortening of the elements'
> lifetime, e.g. by using opAssign() or destroy():
> 
> @safe {
> RefCountedSlice!int s = ...;
> scope int* el;
> el = [0];
> s = RefCountedSlice.init;
> *el = 12; // oops
> }

I asked Walter about this in more details and right now plan is to
address it in a separate DIP that provides more integration between
reference counting and compiler. Within DIP1000 terms such destructor
must not be marked as @safe - essentially, it will only enable @safe
usage of stack allocated data in its initial form.

> A similar issue affects the library implementation of isolated memory
> that I did a while ago:
> 
> @safe {
> class C { int* x; }
> 
> // c is guaranteed to be only reachable through this variable
> Isolated!C c = makeIsolated!C();
> 
> // c.x is a @property that returns a specially wrapped reference to
> // the actual C.x field - with this DIP this is similar to a 'scope'
> // return, but acts transitively
> Scoped!(int*) x = c.x;
> 
> // one of the benefits of Isolated!T is that it allows @safe
> // conversion to immutable:
> immutable(C) ci = c.freeze();
> // c gets cleared by freeze() to disallow any further modifications
> 
> // but, oops, x is still there and can be used to modify the now
> // immutable contents of ci.x
> *x = 12;
> }
> 
> Disallowing the assignment of scope return references to local scope
> references (either by default, or using some form of additional
> inference/annotation) would solve this particular issue, but not the
> issue in general (the assignment/destruction could for example happen in
> a nested function call).

Note that using scope return in its most basic form will exactly prevent
the assigning of reference to a variable because it limits lifetime to
expression.




signature.asc
Description: OpenPGP digital signature

Re: DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

On 08/12/2016 01:24 PM, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
> 
> What about:
> 
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
> 
> fcs["bar"].a = 1337;  // log n
> fcs["bar"].b = 1338;  // log n
> 
> ? I need to pay log n twice to assign two members

Note though that while it won't work with example of `RefCountedSlice`
implementation in DIP (which marks return value as scope reducing
lifetime to expression), it should be possible to instead mark method
itself (== hidden `this` argument) as `return scope` thus saying that
return value has same lifetime as `this`.





signature.asc
Description: OpenPGP digital signature

Re: [OT] of [OT] I am a developer and I hate documentation

[ketmar via Digitalmars-d]

On Thursday, 18 August 2016 at 16:17:15 UTC, H. S. Teoh wrote:

if the stub reads:

/**
 * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Params:
 *  x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 *  y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 */
int myFunc(int x, int y) { ... }

:-P
i assure you that programmers will still be too lazy to fill the 
docs. but they *will* spend alot of time rebuilding (or 
hex-editing if there is no source) their IDE to replace the 
message.

Re: [OT] of [OT] I am a developer and I hate documentation

[ketmar via Digitalmars-d]

On Thursday, 18 August 2016 at 15:38:03 UTC, Chris wrote:

However, this would be very useful as a stub.
and it will stay as stub forever. more than that: with 
autogenerated stubs people will start answer: "stop complaining 
about documentation! i have each my function documented, can't 
you see?!"

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

[Lodovico Giaretta via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 16:19:41 UTC, Johan Engelen wrote:
On Thursday, 18 August 2016 at 11:43:03 UTC, Lodovico Giaretta 
wrote:
Which compiler version are you using? On DMD 2.071.0 this does 
not work.


Note: this does work with LDC 1.1.0 even though it is based on 
DMD 2.071.


https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta2


Well, LDC 1.1.0 is based on DMD 2.071.1, while I tested the above 
code on asm.dlang.org with DMD 2.071.0, so maybe on DMD 2.071.1 
it works too. On nightly it works for sure.
So again nothing wrong here, just a matter of having the most 
recent compiler version.

Re: [OT] of [OT] I am a developer and I hate documentation

[H. S. Teoh via Digitalmars-d]

On Thu, Aug 18, 2016 at 03:38:03PM +, Chris via Digitalmars-d wrote:
> On Thursday, 18 August 2016 at 15:12:52 UTC, H. S. Teoh wrote:
> > Nah, this kind of so-called "documentation" is no better than
> > reading the code itself. It's just like code comments that basically
> > repeat what the code does, which is useless because you can already
> > read the code.
> > 
> > What you want are comments / docs that explain things that are *not*
> > immediately obvious from the code, such as:
> > - High-level discussion of *why* this code does what it does;
> > - Relevant examples of *how* to use it, in the context of what it was
> >   intended for (i.e., not just a dumb `auto x = myFunc(123);` which says
> >   nothing about how to use it in real life).
> > - *When* to use this code, and when not to use it.
> > - Any gotchas to watch out for (e.g. this function may return the wrong
> >   result if the input is poorly-conditioned)
> > - What algorithm(s) are used to compute the result, and why said
> >   algorithms were chosen, their advantages / disadvantages, etc.
> > 
> > Even more obvious parts of the docs also need proper explanation. For
> > example, compare:
> > 
> > /**
> >  * Repeats a string.
> >  * Params:
> >  *  x = a string
> >  *  y = an int
> >  * Returns: a string.
> >  */
> > string repeat(string x, int y) { ... }
> 
> However, this would be very useful as a stub. To write "Repeats a
> string by the specified number of times." is trivial. Often a function
> can be explained in one or two sentences, like "Saves output as WAV
> file. Returns true on success, otherwise false.". The rest is a real
> pita. All that boilerplate for
> 
> bool saveWAV(string path)
> {
>   // ...
>   if (...)
> return true;
>   return false
> }
> 
> That's the real killer. Hey, if dmd can generate files with code
> coverage, it could generate files with doc stubs.
[...]

Shouldn't that be the job of the IDE?  If the IDE always generated doc
stubs for non-private functions, that could be good encouragement for
the coder to actually fill it in! Esp. if the stub reads:

/**
 * THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Params:
 *  x = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 *  y = THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 * Returns: THE PROGRAMMER WAS TOO LAZY TO FILL THIS IN
 */
int myFunc(int x, int y) { ... }

:-P


T

-- 
"Holy war is an oxymoron." -- Lazarus Long

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

[Johan Engelen via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 11:43:03 UTC, Lodovico Giaretta 
wrote:

On Thursday, 18 August 2016 at 11:11:10 UTC, mogu wrote:


Compiler Error exactly. The minimal code is(dmd or ldc2 in 
ubuntu 16.04 lts):

```
extern (C++, struct)
class A {}
```

Error: identifier expected for C++ namespace found 'struct' 
when expecting ')' declaration expected, not ')'


Which compiler version are you using? On DMD 2.071.0 this does 
not work.


Note: this does work with LDC 1.1.0 even though it is based on 
DMD 2.071.


https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta2

Re: [OT] of [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 15:12:52 UTC, H. S. Teoh wrote:



Nah, this kind of so-called "documentation" is no better than 
reading the code itself. It's just like code comments that 
basically repeat what the code does, which is useless because 
you can already read the code.


What you want are comments / docs that explain things that are 
*not*

immediately obvious from the code, such as:
- High-level discussion of *why* this code does what it does;
- Relevant examples of *how* to use it, in the context of what 
it was
  intended for (i.e., not just a dumb `auto x = myFunc(123);` 
which says

  nothing about how to use it in real life).
- *When* to use this code, and when not to use it.
- Any gotchas to watch out for (e.g. this function may return 
the wrong

  result if the input is poorly-conditioned)
- What algorithm(s) are used to compute the result, and why said
  algorithms were chosen, their advantages / disadvantages, etc.

Even more obvious parts of the docs also need proper 
explanation. For example, compare:


/**
 * Repeats a string.
 * Params:
 *  x = a string
 *  y = an int
 * Returns: a string.
 */
string repeat(string x, int y) { ... }


However, this would be very useful as a stub. To write "Repeats a 
string by the specified number of times." is trivial. Often a 
function can be explained in one or two sentences, like "Saves 
output as WAV file. Returns true on success, otherwise false.". 
The rest is a real pita. All that boilerplate for


bool saveWAV(string path)
{
  // ...
  if (...)
return true;
  return false
}

That's the real killer. Hey, if dmd can generate files with code 
coverage, it could generate files with doc stubs.

Re: [OT] of [OT] I am a developer and I hate documentation

[H. S. Teoh via Digitalmars-d]

On Thu, Aug 18, 2016 at 01:19:13PM +, Chris via Digitalmars-d wrote:
[...]
> Isn't there a way to auto-generate a minimal documentation with the
> help of the compiler? As in
> 
> int myFunction(int a, int b)
> {
>   if (a > -1)
> return a + b;
>   return -1;
> }
> 
> // auto-gen:
> Returns `int`, if `a` is greater than -1, else returns -1.
> Parameters: `int`, `int`; Returns `int`.
> 
> Something like that.

Nah, this kind of so-called "documentation" is no better than reading
the code itself. It's just like code comments that basically repeat what
the code does, which is useless because you can already read the code.

What you want are comments / docs that explain things that are *not*
immediately obvious from the code, such as:
- High-level discussion of *why* this code does what it does;
- Relevant examples of *how* to use it, in the context of what it was
  intended for (i.e., not just a dumb `auto x = myFunc(123);` which says
  nothing about how to use it in real life).
- *When* to use this code, and when not to use it.
- Any gotchas to watch out for (e.g. this function may return the wrong
  result if the input is poorly-conditioned)
- What algorithm(s) are used to compute the result, and why said
  algorithms were chosen, their advantages / disadvantages, etc.

Even more obvious parts of the docs also need proper explanation. For
example, compare:

/**
 * Repeats a string.
 * Params:
 *  x = a string
 *  y = an int
 * Returns: a string.
 */
string repeat(string x, int y) { ... }

versus:

/**
 * Repeats a string by the specified number of times.
 * Params:
 *  x = the string to repeat
 *  y = the number of times to repeat the string
 * Returns: the input string repeated y times.
 */
string repeat(string x, int y) { ... }

The first example has completely worthless docs, because it says nothing
that the function signature itself doesn't already tell you. The second
is better because it describes what the parameters are supposed to
signify, and defines the result more precisely.

Autogenerated docs give you the first kind of docs. You need human
effort to write the second kind.


T

-- 
In theory, there is no difference between theory and practice.

Re: [OT] of [OT] I am a developer and I hate documentation

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 18 August 2016 at 14:59:08 UTC, Chris wrote:
It would be a good starting point for documentation stubs, not 
a substitute for a proper, full-fledged documentation.


Oh yeah, if it was in the source itself, I can see the point of 
that. IDEs can and probably should do that at least.

Re: [OT] of [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 14:59:08 UTC, Chris wrote:


(unit) 0 || index + 1, that is.

Re: [OT] I am a developer and I hate documentation

[H. S. Teoh via Digitalmars-d]

On Thu, Aug 18, 2016 at 08:40:23AM +, Kagamin via Digitalmars-d wrote:
> Article:
> https://dzone.com/articles/why-developers-write-horrible-documentation-and-ho
> Also: 
> https://www.reddit.com/r/programming/comments/4y6pws/why_video_documentation_isnt_the_answer/

The first article claims that video documentation is better. I think
that's BS. Making video docs takes MUCH MORE resources and effort than
written docs, meaning that it's even less likely to get done, and less
likely to be kept up-to-date as the code inevitably changes.

I agree with the second article that video docs aren't the answer. I
much rather have poorly-written docs that are searchable than video docs
that are unsearchable. I mean, come on, do you seriously want to watch a
video repeatedly every time you need to look up one specific detail
buried somewhere therein?  That's ridiculously inefficient. Give me
written docs any day.


T

-- 
Just because you can, doesn't mean you should.

Re: [OT] of [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 14:31:47 UTC, Adam D. Ruppe wrote:

On Thursday, 18 August 2016 at 13:19:13 UTC, Chris wrote:
Isn't there a way to auto-generate a minimal documentation 
with the help of the compiler? As in


I think that would be useless for anything other than toy 
functions. You can just view the source and learn more than 
that.


Good documentation tells you something that is hard to tell 
from the source alone... it tells you there's a forest among 
these trees.


But even just plain tree thing, the doc can just list the 
prototype and have a view source thing rather than try to parse 
the code into English anyway.


It would be a good starting point for documentation stubs, not a 
substitute for a proper, full-fledged documentation. The most 
annoying thing about writing docs is the amount of boilerplate, 
not the doc itself, cf:


/**
Find $(D value) _among $(D values), returning the 1-based index
of the first matching value in $(D values), or $(D 0) if $(D 
value)

is not _among $(D values). The predicate $(D pred) is used to
compare values, and uses equality by default.
Params:
pred = The predicate used to compare the values.
value = The value to search for.
values = The values to compare the value to.
Returns:
0 if value was not found among the values, otherwise the 
index of the

found value plus one is returned.

[...]
*/

If `Params` and `Returns` were generated automagically, at least 
as stubs, then it would be easier to write the "true" 
description, i.e. if you had something like:


/**

Params:
pred =
value =
values =
Returns:
(unit) 0 || index + 2
*/

Re: [OT] of [OT] I am a developer and I hate documentation

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 18 August 2016 at 13:19:13 UTC, Chris wrote:
Isn't there a way to auto-generate a minimal documentation with 
the help of the compiler? As in


I think that would be useless for anything other than toy 
functions. You can just view the source and learn more than that.


Good documentation tells you something that is hard to tell from 
the source alone... it tells you there's a forest among these 
trees.


But even just plain tree thing, the doc can just list the 
prototype and have a view source thing rather than try to parse 
the code into English anyway.

Re: RSA library

[Kagamin via Digitalmars-d-learn]

Well, windows api has RSA 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa375534%28v=vs.85%29.aspx is it different from RSA256?

Re: RSA library

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

On Thursday, 18 August 2016 at 09:00:58 UTC, Andre Pany wrote:
Is there a D library which can be built with a plain x86 DMD 
and without dll dependencies?


Not that I know of, and I don't think the win32 api includes 
rsa256 (though .net does!).


The botan lib though, why doesn't it work on 32 bit optlink? You 
might be able to hack it by just taking the algorithms you need 
and compiling yourself.

[Issue 16402] ICE when reinterpreting a function as a long[2]

[via Digitalmars-d-bugs]

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

Cauterite  changed:

   What|Removed |Added

   Keywords||ice, ice-on-valid-code

--

[Issue 16402] New: ICE when reinterpreting a function as a long[2]

[via Digitalmars-d-bugs]

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

  Issue ID: 16402
   Summary: ICE when reinterpreting a function as a long[2]
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cauter...@gmail.com

( https://dpaste.dzfl.pl/01922868e611 )

void f() {};
void main() {
auto X = *cast(long[2]*) 
};

// Internal error: backend\cod2.c 3971

The `2` in `long[2]` can be any number > 1.
On x86-32 the same bug is also triggered by `int[2]` and `uint[2]`.

This works fine:

auto Ptr = cast(long[2]*) 
auto X = *Ptr;

It can also be triggered with the enclosing function:

void main() {
auto X = *cast(long[2]*)  // Internal error …
};

--

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

[pineapple via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 11:43:03 UTC, Lodovico Giaretta 
wrote:

On Thursday, 18 August 2016 at 11:11:10 UTC, mogu wrote:
On Thursday, 18 August 2016 at 10:45:14 UTC, Lodovico Giaretta 
wrote:


Which kind of error? An error message by the compiler? One by 
the linker? The compiler crashes?




Compiler Error exactly. The minimal code is(dmd or ldc2 in 
ubuntu 16.04 lts):

```
extern (C++, struct)
class A {}
```

Error: identifier expected for C++ namespace found 'struct' 
when expecting ')' declaration expected, not ')'


Which compiler version are you using? On DMD 2.071.0 this does 
not work. On nightly build it compiles without errors. So 
probably it is a feature that is present, but didn't ship yet. 
I suggest you download the latest beta or a nightly build from 
the site.


Wouldn't this be more syntactically consistent if it were "Cpp" 
instead of "C++"?

Re: Autotester farm is down

[jmh530 via Digitalmars-d]

On Thursday, 18 August 2016 at 08:06:21 UTC, wobbles wrote:


Ah yes, I forgot about windows :/


How expensive is Azure?

Re: [OT] of [OT] I am a developer and I hate documentation

[Stefan Koch via Digitalmars-d]

On Thursday, 18 August 2016 at 13:19:13 UTC, Chris wrote:

Isn't there a way to auto-generate a minimal documentation with 
the help of the compiler? As in


int myFunction(int a, int b)
{
  if (a > -1)
return a + b;
  return -1;
}

// auto-gen:
Returns `int`, if `a` is greater than -1, else returns -1.
Parameters: `int`, `int`; Returns `int`.

Something like that.


Would you like a patch ? that will at least autogen Returns 
`int`, Parameters: `int a`, `int b`;


No automatic Semantics though.

Re: [OT] of [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 12:20:01 UTC, Seb wrote:

On Thursday, 18 August 2016 at 11:28:10 UTC, Chris wrote:

Warning - this is has gone quite off-topic, so before you start 
to criticize the following sentence, let's better focus on the 
bigger issue here: documentation for most D packages is 
terrible.


There is a fix: s/sex/porn/g


I knew this would come up, but it's not true either. Then you 
could also throw in (forced) prostitution etc. However, in one 
way documentation is how sex: more people talk about it than 
actually do it!


Isn't there a way to auto-generate a minimal documentation with 
the help of the compiler? As in


int myFunction(int a, int b)
{
  if (a > -1)
return a + b;
  return -1;
}

// auto-gen:
Returns `int`, if `a` is greater than -1, else returns -1.
Parameters: `int`, `int`; Returns `int`.

Something like that.

Re: [OT] I am a developer and I hate documentation

[Kagamin via Digitalmars-d]

On Thursday, 18 August 2016 at 09:29:02 UTC, Chris wrote:

I'm not convinced.


Just liked the catchy title :)
Video instead of docs is terrible indeed.

[Issue 16179] [REG2.072] git HEAD: multiSort no longer callable with delegate with context

[via Digitalmars-d-bugs]

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #2 from John Colvin  ---
Here's a subtly different example that doesn't actually access the frame, but
the compiler says it does:

import std.algorithm : multiSort;

struct N
{
string p;
string q;
}

auto foo(N[] t)
{
t.multiSort!((u, v) => u.q < v.q,
(u, v) => u.p < v.p);
}

with a similar error message:

phobos/std/algorithm/sorting.d(897): Error: static function
blah.foo.multiSortImpl!((u, v) => u.q < v.q, (u, v) => u.p < v.p).multiSortImpl
cannot access frame of function blah.foo
phobos/std/algorithm/sorting.d(915): Error: static function
blah.foo.multiSortImpl!((u, v) => u.p < v.p).multiSortImpl cannot access frame
of function blah.foo
phobos/std/algorithm/sorting.d(902): Error: template instance
blah.foo.multiSortImpl!((u, v) => u.p < v.p) error instantiating
phobos/std/algorithm/sorting.d(929):instantiated from here:
multiSortImpl!((u, v) => u.q < v.q, (u, v) => u.p < v.p)
blah.d(11):instantiated from here: multiSort!(N[])

note that the error message also exhibits
https://issues.dlang.org/show_bug.cgi?id=16401  so it's possible this is
actually a compiler bug

--

Re: Why 16Mib static array size limit?

[Johan Engelen via Digitalmars-d]

On Thursday, 18 August 2016 at 12:20:50 UTC, Johan Engelen wrote:


I don't know if we can mark `private` global variables as 
internal. If so, wow :-)


Nevermind, not possible. Templates, cross-module inlining, and 
probably other reasons.

Re: Why 16Mib static array size limit?

[Johan Engelen via Digitalmars-d]

On Thursday, 18 August 2016 at 01:18:03 UTC, Yuxuan Shui wrote:

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


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


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


Perhaps not smart enough, but it is very close to being smart 
enough. Perhaps we, the LDC devs, weren't smart enough in using 
the LLVM backend. ;-)


For Ali's code, `arr` is a global symbol that can be modified by 
code not seen by the compiler. So no assumptions can be made 
about the contents of arr.ptr and arr.length, and thus `arr[i]` 
could index into `arr` itself.


Now, if we tell [*] the compiler that `arr` is not touched by 
code outside the module... the resulting machine code is 
identical with and without POINTER!


It's an interesting case to look further into. For example with 
Link-Time Optimization, delaying codegen until linktime, we can 
internalize many symbols (i.e. telling the compiler no other 
module is going to do anything with it) allowing the compiler to 
reason better about the code and generate faster executables. 
Ideally, without much user effort. It's something I am already 
looking into.


I don't know if we can mark `private` global variables as 
internal. If so, wow :-)


-Johan


[*] Unfortunately `private arr` does not have the desired effect 
(it does not make it an `internal` LLVM variable), so you have to 
hack into the LLVM IR file to make it happen.

[OT] of [OT] I am a developer and I hate documentation

[Seb via Digitalmars-d]

On Thursday, 18 August 2016 at 11:28:10 UTC, Chris wrote:
On Thursday, 18 August 2016 at 09:49:17 UTC, Shachar Shemesh 
wrote:




Documentation is like sex.

When it's good, it's very good.

When it's bad. it's still better than nothing.


Your comparison is not 100% correct. While those who enjoy 
making love are the same people who are doing it, writing docs 
is enjoyed by others, but not by the one(s) doing it.


Warning - this is has gone quite off-topic, so before you start 
to criticize the following sentence, let's better focus on the 
bigger issue here: documentation for most D packages is terrible.


There is a fix: s/sex/porn/g

[Issue 16401] New: incorrect fully qualified name in error message

[via Digitalmars-d-bugs]

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

  Issue ID: 16401
   Summary: incorrect fully qualified name in error message
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

% cat multisortBreak.d
import std.algorithm.sorting : multiSort;
bool foo(int a, int b){ return true; }

void main()
{
int[] a = [1,2,3];
a.multiSort!((a,b) => foo, foo);
}

% dmd multisortBreak.d
multisortBreak.d(7): Error: template multisortBreak.main.multiSort!((a, b) =>
foo, foo).multiSort cannot deduce function from argument types !()(int[]),
candidates are:
/usr/local/Cellar/dmd/2.071.2-b1/include/dlang/dmd/std/algorithm/sorting.d(790):
   multisortBreak.main.multiSort!((a, b) => foo,
foo).multiSort(Range)(Range r) if (validPredicates!(ElementType!Range, less))

multiSort is erroneously being reported as a member of multisortBreak.main

--

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

[Lodovico Giaretta via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 11:11:10 UTC, mogu wrote:
On Thursday, 18 August 2016 at 10:45:14 UTC, Lodovico Giaretta 
wrote:


Which kind of error? An error message by the compiler? One by 
the linker? The compiler crashes?




Compiler Error exactly. The minimal code is(dmd or ldc2 in 
ubuntu 16.04 lts):

```
extern (C++, struct)
class A {}
```

Error: identifier expected for C++ namespace found 'struct' 
when expecting ')' declaration expected, not ')'


Which compiler version are you using? On DMD 2.071.0 this does 
not work. On nightly build it compiles without errors. So 
probably it is a feature that is present, but didn't ship yet. I 
suggest you download the latest beta or a nightly build from the 
site.

Re: [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 09:49:17 UTC, Shachar Shemesh 
wrote:




Documentation is like sex.

When it's good, it's very good.

When it's bad. it's still better than nothing.


Your comparison is not 100% correct. While those who enjoy making 
love are the same people who are doing it, writing docs is 
enjoyed by others, but not by the one(s) doing it.

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

[mogu via Digitalmars-d-learn]

On Thursday, 18 August 2016 at 10:45:14 UTC, Lodovico Giaretta 
wrote:


Which kind of error? An error message by the compiler? One by 
the linker? The compiler crashes?




Compiler Error exactly. The minimal code is(dmd or ldc2 in ubuntu 
16.04 lts):

```
extern (C++, struct)
class A {}
```

Error: identifier expected for C++ namespace found 'struct' when 
expecting ')' declaration expected, not ')'

[Issue 10591] Error: only one main allowed doesn't show location of conflicting main symbols

[via Digitalmars-d-bugs]

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #3 from John Colvin  ---
Just ran in to this, I'm actually struggling to find the offending main
function in a large codebase (could be in some dependency that's wrongly
configured to compile in execultable mode instead of library). Grep doesn't cut
it, the compiler should tell me.

--

Re: [OT] I am a developer and I hate documentation

[Shachar Shemesh via Digitalmars-d]

On 18/08/16 11:40, Kagamin wrote:

Article:
https://dzone.com/articles/why-developers-write-horrible-documentation-and-ho

Also:
https://www.reddit.com/r/programming/comments/4y6pws/why_video_documentation_isnt_the_answer/



Documentation is like sex.

When it's good, it's very good.

When it's bad. it's still better than nothing.

Re: Berlin D Meetup August 2016

[Rory McGuire via Digitalmars-d-announce]

Man I wish I was in Berlin. Will be awesome if we get to see a video of
this.

R

On Thu, Aug 18, 2016 at 11:09 AM, Ben Palmer via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Hi All,
>
> The August Berlin D Meetup will be happening at 20:00 on Friday the 26th
> of August at Berlin Co-Op (http://co-up.de/) on the fifth floor. Note
> that this is the fourth Friday of the month rather than the standard third
> Friday.
>
> Stefan Koch is going to tell his war-stories about implementing CTFE.
> Expect juicy bits of dmd code and a few rants as well as a birds-eye-view
> of how the new engine is going to work.
>
> There likely won't be slides but instead a few live demos of what the new
> engine will be capable of.
>
> Sociomantic have come to the party once more and will be sponsoring food
> (including vegetarian options) and drinks (both alcoholic and
> non-alcoholic).
>
> More details are available on the meetup page here:
> http://www.meetup.com/Berlin-D-Programmers/events/233371803/
>
> Thanks,
> Ben.
>

Re: [OT] I am a developer and I hate documentation

[Chris via Digitalmars-d]

On Thursday, 18 August 2016 at 08:40:23 UTC, Kagamin wrote:
Article: 
https://dzone.com/articles/why-developers-write-horrible-documentation-and-ho
Also: 
https://www.reddit.com/r/programming/comments/4y6pws/why_video_documentation_isnt_the_answer/


I'm not convinced. The resulting video may be more confusing than 
no documentation at all.
Apart from that, I don't wanna talk (poor listeners) or be 
"watched" (poor me) while programming.


Looks like they're trying to market video-doc platforms and apps, 
this, or companies in the USofA are too lazy to go through the 
code that the NSA ripped for them. No, let the industrial spies 
do at least some work - let them be industrious spies!

Berlin D Meetup August 2016

[Ben Palmer via Digitalmars-d-announce]

Hi All,

The August Berlin D Meetup will be happening at 20:00 on Friday 
the 26th of August at Berlin Co-Op (http://co-up.de/) on the 
fifth floor. Note that this is the fourth Friday of the month 
rather than the standard third Friday.


Stefan Koch is going to tell his war-stories about implementing 
CTFE. Expect juicy bits of dmd code and a few rants as well as a 
birds-eye-view of how the new engine is going to work.


There likely won't be slides but instead a few live demos of what 
the new engine will be capable of.


Sociomantic have come to the party once more and will be 
sponsoring food (including vegetarian options) and drinks (both 
alcoholic and non-alcoholic).


More details are available on the meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/events/233371803/


Thanks,
Ben.

[OT] I am a developer and I hate documentation

[Kagamin via Digitalmars-d]

Article: 
https://dzone.com/articles/why-developers-write-horrible-documentation-and-ho
Also: 
https://www.reddit.com/r/programming/comments/4y6pws/why_video_documentation_isnt_the_answer/

[Issue 4463] [AA] double.init in associative array seems 0.0

[via Digitalmars-d-bugs]

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

--- Comment #3 from MichaelZ  ---
... having said that, the double behaviour is explicitly brought up in the pull
request discussion pertaining to 3825: see quickfur's first comment on
https://github.com/dlang/dmd/pull/1465.

--

[Issue 4463] [AA] double.init in associative array seems 0.0

[via Digitalmars-d-bugs]

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

MichaelZ  changed:

   What|Removed |Added

 CC||dlang@bregalad.de

--- Comment #2 from MichaelZ  ---
@hsteoh: I don't believe it is related to 3825; 3825 has been apparently fixed
(for d2) in 2013 (q.v.), but the behaviour described by bearophile_hugs is
still present in dmd 2.071.0  :-|

--

Re: Autotester farm is down

[wobbles via Digitalmars-d]

On Wednesday, 17 August 2016 at 23:13:52 UTC, Brad Roberts wrote:

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

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

[...]


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

paying for power and internet bandwidth for it forever either.

Now that we have the foundation - this should all be fundable 
(hell, I'm sure most of us here

wouldn't mind donating if it took that!)


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


Ah yes, I forgot about windows :/

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

[Jacob Carlborg via Digitalmars-d]

On 2016-08-18 03:21, Yuxuan Shui wrote:


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


You mean:

void foo(scope void delegate() dg);

Or:

void bar(void delegate() dg);

scope void delegate() a = {};
bar(a);

--
/Jacob Carlborg

Re: Why 16Mib static array size limit?

[Walter Bright via Digitalmars-d]

On 8/17/2016 9:16 PM, Chris Wright wrote:

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


Global variables are pretty much spawn of the devil. You're right that dmd does 
not make a special effort optimizing them.


The way to deal with it:

1. minimize use of globals

2. if using them in a hot loop, copy a reference to the global into a local 
variable, and use the local variable in the loop instead.


This also gets around the problem that thread local storage address calculation 
is slow and inefficient on all platforms.

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

[Ali Çehreli via Digitalmars-d]

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

Right.

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

However, as my test code demonstrates, even when the lambda refers to 
stack local variable, closure is NOT allocated in the case of the 
function call. As far as I can tell, the actual reason for the 
allocation is the struct object that filter() returns.


I am trying to understand why the struct object requires the closure 
allocation. I made myself believe that this is the reason: Being an 
alias template parameter, the lambda is a part of the type (the 
instantiation of the struct template). Even though the compiler could 
determine that the single object does not escape, its type can be used 
again.


I'm wondering whether that's the reason. If so, the compiler could prove 
that the type is used only once and not allocate the closure.


Note that although they look the same to us, S!(() => i) and S!(() => i) 
are different types to the compiler because the two lambdas are 
different anonymous objects, effectively making the struct template 
instances different.


Ali