Re: CTFE casts of delegates

[Eyal Lotem via Digitalmars-d]

On Thursday, 5 January 2017 at 03:05:21 UTC, Jonathan M Davis 
wrote:
However, since code that legitimately casts a function to alter 
its attributes should be _very_ rare, it should also be quite 
rare that the problem even comes up.


It is very rare to have it in code, but the low-level function 
that does this rare thing (custom assertion function) may be very 
frequently called, indirectly.


So, I would think that making casts for attributes legal during 
CTFE wouldn't be a problem (though I could be missing 
something), but at the same time, if someone is actally asking 
for such a capability, that's very worrisome. That implies that 
pure and @nogc are not being used correctly and that casts are 
being used to try and force the compiler into submission, which 
risks nasty bugs when the compiler is then making assumptions 
about the code that are wrong thanks to the fact that it was 
lied to with casts.


Well, I did explain the reason for this cast. An 
aborting-assertion that discontinues execution (hard kill the 
process).


We expect these assertions to never happen. If they do, we don't 
really care about any GC or impure things that they do just 
before terminating the process.


We don't really want *all* code to be marked gc/impure because it 
directly or indirectly uses such assertions.

Re: Stack Space & Ackermann

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

On Thu, Jan 05, 2017 at 04:50:19AM +, Era Scarecrow via Digitalmars-d-learn 
wrote:
> Well re-watched a video regarding the Ackermann function which is a
> heavily recursive code which may or may not ever give a result in our
> lifetimes.  However relying on the power of memoize I quickly find
> that when the program dies (from 5 minutes or so) nearly instantly
> (and only using 9Mb of memory).
> 
> long ack(long m, long n) {
> long ans;
> 
> if (m == 0) ans = n + 1;
> else if (n==0) ans = ack(m-1, 1);
> //else ans = ack(m-1, ack(m, n-1)); // original
> else ans = memoize!ack(m-1, memoize!ack(m, n-1));
> 
> return ans;
> }
> 
> This is only due to the limited stackframe space.
[...]

For heavily-recursive functions like this one, you *really* want to be
revising the algorithm so that it *doesn't* recurse on the runtime
stack.  Keep in mind that the Ackermann function was originally
conceived specifically to prove that a certain elementary class of
recursive functions (called "primitive recursive" functions) cannot
perform certain computations. Very roughly speaking, primitive recursive
functions are "well-behaved" with regard to recursion depth; so the
Ackermann function was basically *designed* to have very bad
(unrestricted) recursion depth such that no primitive recursive function
could possibly catch up to it. Translated to practical terms, this means
that your runtime stack is pretty much guaranteed to overflow except for
the most trivial values of the function.

The other problem with your code, as written, is that it will quickly
and easily overflow any fixed-width integer such as long here. For
example, ack(4,1) == 65533, but ack(4,2) is a value that requires 65536
bits to represent (i.e., an integer that's 1 KB in size), and ack(4,3)
is a value that requires ack(4,2) bits to represent, i.e., the number of
bits required is a number so huge that it itself requires 1KB to
represent. This far exceeds any memory capacity of any computer system
in existence today, and we haven't even gotten to ack(4,4) yet.

You might at least be able to get to ack(4,2) if you use BigInt instead
of long (though be prepared for incredibly huge running times before the
answer ever appears!), but even BigInt won't help you once you get to
ack(4,3) and beyond.  And don't even think about ack(5,n) for any value
of n greater than 0, because those values are so ridiculously huge you
need special notation just to be able to write them down at all.

Because of this, your code as written most definitely does *not* compute
the Ackermann function except for the smallest arguments, because once
ack(m, n-1) overflows long, it can only return the answer module
long.max, which will be much smaller than the actual value, so the
nested recursion ack(m-1, ack(n, m-1)) actually will compute a value far
smaller than what the real Ackermann function would (and it would run
much faster than the real Ackermann function).

Not to mention, the recursive definition of the Ackermann function is
really bad for actually computing its values in a computer, because it
makes a huge number of recursive calls just to compute something as
simple as + and * (essentially what ack(1,n) and ack(2,n) do). In a
practical implementation you'd probably want to special case these
arguments to use faster, non-recursive code paths.  Using memoize
alleviates the problem somewhat, but it could be improved more.

Nonetheless, even if you optimize said code paths, you still won't be
able to get any sane results for m>4 or anything beyond the first few
values for m=4. The Ackermann function is *supposed* to be
computationally intractible -- that's what it was designed for. :-P


T

-- 
Do not reason with the unreasonable; you lose by definition.

Re: What are you planning, D related, for 2017 ?

[Joakim via Digitalmars-d]

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
Write your plan here, and let's take a rendez-vous next year, 
to check those plans !!


Actually build an Android app like I wanted to last year, except 
that my app idea has changed, with no cloud component this time:


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

Re: Stack Space & Ackermann

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 5 January 2017 at 06:20:28 UTC, rikki cattermole 
wrote:

foreach(i; 0 .. 6)

No need for iota.


 I thought that particular slice/range was depreciated. Still the 
few k that are lost in the iota doesn't seem to make a difference 
when i run the code again.

Re: Stack Space & Ackermann

[rikki cattermole via Digitalmars-d-learn]

On 05/01/2017 7:03 PM, Era Scarecrow wrote:

On Thursday, 5 January 2017 at 04:53:23 UTC, rikki cattermole wrote:

Well, you could create a fiber[0].

Fibers allow you to set the stack size at runtime.

[0] http://dlang.org/phobos/core_thread.html#.Fiber.this


 Well that certainly does seem to do the trick. Unfortunately I didn't
get the next output because I ran out of memory to allocate/reallocate
over 2Gb :P

 I suppose with a 64bit compiling the program might run a bit longer and
succeed further (with 24Gigs of ram), however the sheer amount of memory
required will make this little exercise more or less a waste of time.

 Still that was an interesting way around the (stackframe) problem, one
I'll keep I mind (should i need it again).

void m() {
foreach(i; iota(6))
foreach(j; iota(6)) {
writefln("Ackerman (%d,%d) is : %d", i,j,ack(i,j));
}
}

int main(string[] args) {
Fiber composed = new Fiber(, 2<<28); //512MB
composed.call();

return 0;
}

results:

Ackerman (3,5) is : 253
Ackerman (4,0) is : 13
Ackerman (4,1) is : 65533

core.exception.OutOfMemoryError@src\core\exception.d(693): Memory
allocation failed



You're using more memory then need to:

foreach(i; 0 .. 6)

No need for iota.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:

So guys.

basic function-calls are supported.

Hell YEAH!


Disabled for now. Since it pushes some buffers/caches to their 
limit. A more flexible solution is needed.
However the good news is that the ABI seems to work better than 
expected.

Now it's time to deal with this-pointers and method calls.

After remaining issues with nested switches have to be fixed.

Re: Stack Space & Ackermann

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 5 January 2017 at 04:53:23 UTC, rikki cattermole 
wrote:

Well, you could create a fiber[0].

Fibers allow you to set the stack size at runtime.

[0] http://dlang.org/phobos/core_thread.html#.Fiber.this


 Well that certainly does seem to do the trick. Unfortunately I 
didn't get the next output because I ran out of memory to 
allocate/reallocate over 2Gb :P


 I suppose with a 64bit compiling the program might run a bit 
longer and succeed further (with 24Gigs of ram), however the 
sheer amount of memory required will make this little exercise 
more or less a waste of time.


 Still that was an interesting way around the (stackframe) 
problem, one I'll keep I mind (should i need it again).


void m() {
foreach(i; iota(6))
foreach(j; iota(6)) {
writefln("Ackerman (%d,%d) is : %d", i,j,ack(i,j));
}
}

int main(string[] args) {
Fiber composed = new Fiber(, 2<<28); //512MB
composed.call();

return 0;
}

results:

Ackerman (3,5) is : 253
Ackerman (4,0) is : 13
Ackerman (4,1) is : 65533

core.exception.OutOfMemoryError@src\core\exception.d(693): Memory 
allocation failed

Re: Vision document for H1 2017

[Nicholas Wilson via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


Do we have a list of "high-impact research projects"?

Re: Stack Space & Ackermann

[rikki cattermole via Digitalmars-d-learn]

On 05/01/2017 5:50 PM, Era Scarecrow wrote:

 Well re-watched a video regarding the Ackermann function which is a
heavily recursive code which may or may not ever give a result in our
lifetimes. However relying on the power of memoize I quickly find that
when the program dies (from 5 minutes or so) nearly instantly (and only
using 9Mb of memory).

long ack(long m, long n) {
long ans;

if (m == 0) ans = n + 1;
else if (n==0) ans = ack(m-1, 1);
//else ans = ack(m-1, ack(m, n-1)); // original
else ans = memoize!ack(m-1, memoize!ack(m, n-1));

return ans;
}

 This is only due to the limited stackframe space. Doing a search I find
that the amount of stack space is decided on when the EXE is being
compiled and in the EXE header but I'm not sure which one needs to be
update (supposedly it's either 250k or 1Mb is the default), although
neither help in this case, nor do the other binary tools as they don't
recognize the binary format of D's exe output files)

 Alternatively if there's a way to tell the compiler a hint (either in D
or in the compiling/linking flags) or the specific offset of which 32bit
entry is the stack reserved space, I could continue my little
unimportant side experiments.

 Suggestions? Comments?


Well, you could create a fiber[0].

Fibers allow you to set the stack size at runtime.

[0] http://dlang.org/phobos/core_thread.html#.Fiber.this

Stack Space & Ackermann

[Era Scarecrow via Digitalmars-d-learn]

 Well re-watched a video regarding the Ackermann function which 
is a heavily recursive code which may or may not ever give a 
result in our lifetimes. However relying on the power of memoize 
I quickly find that when the program dies (from 5 minutes or so) 
nearly instantly (and only using 9Mb of memory).


long ack(long m, long n) {
long ans;

if (m == 0) ans = n + 1;
else if (n==0) ans = ack(m-1, 1);
//else ans = ack(m-1, ack(m, n-1)); // original
else ans = memoize!ack(m-1, memoize!ack(m, n-1));

return ans;
}

 This is only due to the limited stackframe space. Doing a search 
I find that the amount of stack space is decided on when the EXE 
is being compiled and in the EXE header but I'm not sure which 
one needs to be update (supposedly it's either 250k or 1Mb is the 
default), although neither help in this case, nor do the other 
binary tools as they don't recognize the binary format of D's exe 
output files)


 Alternatively if there's a way to tell the compiler a hint 
(either in D or in the compiling/linking flags) or the specific 
offset of which 32bit entry is the stack reserved space, I could 
continue my little unimportant side experiments.


 Suggestions? Comments?

Re: Vision document for H1 2017

[Basile B. via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


quote from the document:

Redoing compiler code into lowerings and __traits-based 
introspection that leverage client code, thus moving compiler 
smarts into simpler library facilities


To simplify introspection with library traits that use the 
compiler "__traits()" someone has to remove the restrictions 
related to protection attributes. This is not a new topic. 
Without this, the new library traits won't work well and people 
won't use them.

Re: Vision document for H1 2017

[Mike via Digitalmars-d-announce]

On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote:

Templatize dmd <-> druntime API


I'm curious as to why. I'm guessing this is for things like 
creating runtime type information?


This thread 
(http://forum.dlang.org/post/mr7a65$2hc$1...@digitalmars.com) should 
provide some context.


Mike

Re: Vision document for H1 2017

[rikki cattermole via Digitalmars-d-announce]

On 05/01/2017 8:22 AM, Andrei Alexandrescu wrote:

We release a brief Vision document summarizing the main goals we plan to
pursue in the coming six months. This half we are focusing on three
things: safety, lifetime management, and static introspection.

https://wiki.dlang.org/Vision/2017H1


Andrei


The suggestion I want to make related to druntime is, make 
TypeInfo/ModuleInfo actually have (opt-in) full reflection.
This can help decrease template bloat significantly for (de)serializers 
as well as making it so you don't have to explicitly tell your web 
router about all the routes (instead chuck a UDA down and be done with it!).


Andrei: we should talk in a few months about turning my (honors) 
dissertation into research papers. And maybe what I may end up doing for 
masters the following semester.

Re: CTFE casts of delegates

[Jonathan M Davis via Digitalmars-d]

On Wednesday, January 04, 2017 16:19:52 Seb via Digitalmars-d wrote:
> On Wednesday, 4 January 2017 at 16:06:11 UTC, Stefan Koch wrote:
> > On Wednesday, 4 January 2017 at 08:45:59 UTC, Eyal Lotem wrote:
> >> On Tuesday, 3 January 2017 at 09:44:38 UTC, Stefan Koch wrote:
> >>> I think that I can provide a dmd patch that would allow the
> >>> casts you want at ctfe.
> >>> However I would not propose it for inclusion myself.
> >>
> >> A cast that only fiddles with function attributes like @nogc
> >> should be perfectly safe, shouldn't it?
> >
> > Honestly I am not sure about it.
> > I guess I could enable this back-door for you and others.
>
> This back-door already exists, see e.g.:
>
> https://github.com/nordlow/phobos-next/blob/master/src/dbgio.d#L13
>
> and
>
> http://forum.dlang.org/post/nq4eol$2h34$1...@digitalmars.com
>
> > Patch will follow in the next days, I am not sure if it will be
> > merged though.
>
> There is assumeWontThrow
> (https://dlang.org/phobos/std_exception.html#.assumeWontThrow) in
> std.exception, so I think the chances for assumeNogc or
> assumePure aren't that bad ;-)

Well, assumeWontThrow is a completely different animal. There is a perfectly
legitimate way to make a function be nothrow while still call functions that
can throw exceptions - you have a catch(Exception) block in it and don't
throw any exceptons or call any non-nothrow functions outside of it. No such
thing exists for @nogc or pure. Those are type system issues, and in order
to make something @nogc that's calling functions that aren't @nogc or to
make something pure that's calling functions that aren't pure, you have to
subvert the type system. If the programmer does it, they have to make sure
that they do so in a way that doesn't violate the guarantees that the
compiler makes about @nogc or pure - which isn't necessarily easy. And in
general, it's a big red flag when code uses casts to make anything @nogc or
pure. So, putting something in the standard library specifically to support
such an idiom really doesn't seem like a good idea. Only experts should be
doing it, and even then, they should reconsider.

Now, as to having the ability to have casting muck with pure or @nogc with
CTFE, I don't know. It would be nice to have the same capabilties at compile
time that you have at runtime, and if a function is legitimately and
correctly using casts to deal with @nogc or pure, then it sucks that it
can't be done with CTFE. However, since code that legitimately casts a
function to alter its attributes should be _very_ rare, it should also be
quite rare that the problem even comes up.

>From an @safety perspective though, I don't see why it would be an
implementation issue to support such casts durintg CTFE. IIRC, you can't
mess with global or static variables in CTFE if they're mutable, and you
can't call C functions. So, in essence, _everything_ is pure during CTFE.
If I understand correctly, any attempt to call anything that was not
legitimately pure would fail for not being CTFE-able. And since AFAIK, you
pretty much _have_ to use the GC for everything during CTFE (you certainly
can't call malloc, and most pointer operations are forbidden, making stack
allocators and whatnot infeasible), I don't think that having a function be
@nogc when it really isn't @nogc would actually matter during CTFE.

So, I would think that making casts for attributes legal during CTFE
wouldn't be a problem (though I could be missing something), but at the same
time, if someone is actally asking for such a capability, that's very
worrisome. That implies that pure and @nogc are not being used correctly and
that casts are being used to try and force the compiler into submission,
which risks nasty bugs when the compiler is then making assumptions about
the code that are wrong thanks to the fact that it was lied to with casts.

- Jonathan M Davis

Re: Question on std.experimental

[Jack Stouffer via Digitalmars-d]

On Wednesday, 4 January 2017 at 21:44:16 UTC, Robert burner 
Schadek wrote:
On Wednesday, 4 January 2017 at 19:33:13 UTC, Jack Stouffer 
wrote:
Promotion of std.logger has been officially stalled until 
reference counted strings are part of D.


When? That is the first I hear about that.


???

You were the one who told me about it: 
https://github.com/dlang/phobos/pull/1500#issuecomment-155457980

Re: Vision document for H1 2017

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

On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote:
I'm curious as to why. I'm guessing this is for things like 
creating runtime type information?


There's a lot of benefits to it: it'd simplify the compiler a 
bit, it'd simplify making custom runtimes, and it'd give us 
options to both expand and minimize the runtime info with things 
like compiler switches in druntime.

Re: Vision document for H1 2017

[Chris Wright via Digitalmars-d-announce]

> Templatize dmd <-> druntime API

I'm curious as to why. I'm guessing this is for things like creating 
runtime type information?

Re: The future of DMD's JSON output

[Walter Bright via Digitalmars-d]

On 1/4/2017 6:27 PM, Chris Wright wrote:

On Fri, 30 Dec 2016 02:44:38 +, Chris Wright wrote:


DMD's JSON output hasn't changed since at least the switch from C++ to
D.
Is it deprecated or merely lacking maintainers? Is there a vision for
where it will go?


Having no response, I'm going to assume it's lacking maintainers, lacking
vision, and lacking sufficient attention to deprecate.



What it's lacking is someone who is using it. It's users who would drive 
something like this forward. It's most definitely in the camp of "build it, and 
they will come".

Re: The future of DMD's JSON output

[Chris Wright via Digitalmars-d]

On Fri, 30 Dec 2016 02:44:38 +, Chris Wright wrote:

> DMD's JSON output hasn't changed since at least the switch from C++ to
> D.
> Is it deprecated or merely lacking maintainers? Is there a vision for
> where it will go?

Having no response, I'm going to assume it's lacking maintainers, lacking 
vision, and lacking sufficient attention to deprecate.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Timon Gehr via Digitalmars-d]

On 05.01.2017 01:51, Andrei Alexandrescu wrote:

On 12/31/16 9:43 AM, Timon Gehr wrote:

On an unrelated note: I'm still not a fan of the with(import) syntax as
it morally promotes a lack of turtles (even if not technically so).


Could you please provide more detail? Thanks! -- Andrei


The declaration

with(import foo){ ... }

looks like an orthogonal combination of some import expression and the usual

with(foo){ ... }

statement. (This is true for all other statements and expressions with 
similar syntax.)


However, this is not in fact true here, the two constructs have 
different scoping rules.


Hence I think that the 'with(import foo){ ... }'-syntax would be better 
split into two orthogonal features:


1. allow 'import foo' as an expression that evaluates to the 
corresponding module symbol.


2. add 'static with' that is basically like 'with' but is a declaration 
and has different scoping rules.



I.e., my objection is that 'with' should not become 'static' just 
because it is applied to an import expression.

Re: Vision document for H1 2017

[Dibyendu Majumdar via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1



Hi, its interesting to view this in context of previous vision 
documents:


https://wiki.dlang.org/Vision/2015H1
https://wiki.dlang.org/Vision/2015H2
https://wiki.dlang.org/Vision/2016H1
https://wiki.dlang.org/Vision/2016H2

It seems safety and memory management have appeared in all of the 
documents, so presumably the goals haven't been achieved yet. I 
think it would be helpful to have more explicit definition of 
what it would mean for these features to be "done" and is that 
the aim for H1 2017.


C++ integration has disappeared? Is this now "done"?

Re: Vision document for H1 2017

[Paul O'Neil via Digitalmars-d-announce]

On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote:

We release a brief Vision document summarizing the main goals we plan to
pursue in the coming six months. This half we are focusing on three
things: safety, lifetime management, and static introspection.

https://wiki.dlang.org/Vision/2017H1


Andrei


What are the plans for the dub registry?  Have there been discussions 
already?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrei Alexandrescu via Digitalmars-d]

On 12/31/16 9:43 AM, Timon Gehr wrote:

On an unrelated note: I'm still not a fan of the with(import) syntax as
it morally promotes a lack of turtles (even if not technically so).


Could you please provide more detail? Thanks! -- Andrei

Re: Quick and dirty support for RISC-V

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 4 January 2017 at 17:12:54 UTC, e-y-e wrote:
In a previous post a few days ago, I asked what the easiest way 
of getting D code running on RISC-V would be. I thought the 
process might take quite a while and more knowledge of 
compilers, hardware etc than I currently have.


[...]


Excellent!

You said you did some hacking on LLVM so small LDC checklist:
Have you set all the correct predefined versions?
ABI?

If you have any questions please hop on to our gitter: 
https://gitter.im/ldc-developers/main

Re: Another XML DOM Package

[Daniel Kozák via Digitalmars-d-announce]

Guillaume Piolat via Digitalmars-d-announce 
 napsal St, led 4, 2017 v 11∶48 
:

On Friday, 30 December 2016 at 04:19:47 UTC, apz28 wrote:
This is my first package to learn D. Suggestion for improvement is 
welcome.


https://github.com/apz28/dlang-xml


Welcome here!

- you don't have to commit .sln files, dub can generate them as needed
- that is for a package that will be reused you can use dub :)
- no need to use @property, there was a recent discussion about it. I 
think you can ignore it altogether.


Yes he can but I still prefer it for documentation purposes :)



- you can use "final" before a class declaration to have all methods 
be final


  final class C { /* all methods are final /= }


	Most common and IMHO better pattern is put final as first thing in 
class like this:

class C {
final: // all methods after this are final
}

	It has some advantages (class C is not final so you can still use 
inheritance),
	marking class final does not need to mean all methods are final (it 
makes sense to mark them and in curent implementation it is)
	you can still add easy one method which is virtual. To be fair I 
mostly use struct instead of final clases





- no need for "public import std.exception : Exception;" to use 
Exception


imho the XML parser to beat in our ecosystem is kxml, which is small 
and serviceable

[Issue 17060] betterC std.allocator

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

Re: Another XML DOM Package

[Guillaume Piolat via Digitalmars-d-announce]

On Friday, 30 December 2016 at 04:19:47 UTC, apz28 wrote:
This is my first package to learn D. Suggestion for improvement 
is welcome.


https://github.com/apz28/dlang-xml


Welcome here!

- you don't have to commit .sln files, dub can generate them as 
needed

- that is for a package that will be reused you can use dub :)
- no need to use @property, there was a recent discussion about 
it. I think you can ignore it altogether.
- you can use "final" before a class declaration to have all 
methods be final


  final class C { /* all methods are final /= }

- no need for "public import std.exception : Exception;" to use 
Exception


imho the XML parser to beat in our ecosystem is kxml, which is 
small and serviceable

Re: Question on std.experimental

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 4 January 2017 at 21:59:29 UTC, Andrei Alexandrescu 
wrote:
On Wednesday, 4 January 2017 at 13:47:53 UTC, Ilya Yaroshenko 
wrote:

[...]


We should be able to take care of this with simple 
modularization techniques. And there's little worry about 
breakage because it's still experimental. Could you please 
submit fine-grained bug reports a la "this can't be done 
because this static constructor is in the same module as this 
independently useful artifact"? Or whatever the matter is. Then 
each issue can be looked at and decided upon properly. Thanks. 
-- Andrei


Have not reviewed std.allocator code for betterC mode. Basic idea 
is here https://issues.dlang.org/show_bug.cgi?id=17060


Thanks,
Ilya

[Issue 17060] New: betterC std.allocator

[via Digitalmars-d-bugs]

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

  Issue ID: 17060
   Summary: betterC std.allocator
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

Part 1
-

std.allocator can be split (virtually) into three parts:

1. OOP Interfaces, theAllocator, constructors and other global variables.
2. Always inlined code.
3. Generic code.

1: OOP code and global variables can be placed in separate module.

2: We have `pragma(inline, true)`. Each function for non-generuc stuff like
Mallocator can be marked with this pragma. The size of code seems to be small
enough to be always inlined.

3: Generic code should be already fine.



Part 2
-
std.allocator uses some functions from `core.*` and maybe `std.*`. They should
be betterC too. I don't know how to verify it for all compilers.

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16604] [std.getopt] defaultGetoptPrinter can't be used if an exception fires

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16959] bringToFront fails on char arrays

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16686] Can not spawn subprocess and read from File at same time

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16662] Can't call std.variant.visit from a pure function

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16656] move embedded zlib to a separate library

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16630] Compile errors with std.traits.arity and std.traits.ParameterStorageClassTuple

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16736] Retrieving cUrl time values is quite cumbersome

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16684] std.getopt, problem with the automatic handling of "h"

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16991] Make writeln documentation palatable

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16985] Enable runnable unittest on dlang.org after 2.073 release

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16615] std.process is missing functionality for child processes

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16984] Make more modules runnable on dlang.org

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16783] std.net.curl application throws an exception

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--

[Issue 16542] makeArray not usable with const initializer

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

Re: Question on std.experimental

[Andrei Alexandrescu via Digitalmars-d]

On Wednesday, 4 January 2017 at 13:47:53 UTC, Ilya Yaroshenko 
wrote:

On Wednesday, 4 January 2017 at 10:02:34 UTC, Adam Wilson wrote:

On 1/3/17 11:55 PM, Ilya Yaroshenko wrote:
On Wednesday, 4 January 2017 at 07:32:34 UTC, Adam Wilson 
wrote:



Has anything graduated yet?


No


So at what point well we? I mean that is the point after all...


ndslice is deprecated https://github.com/dlang/phobos/pull/4946
It is hard to maintain both Phobos and Mir forks.

Allocators are useful but they are not betterC. I will fork 
them anyway if I will need to use them for production.


We should be able to take care of this with simple modularization 
techniques. And there's little worry about breakage because it's 
still experimental. Could you please submit fine-grained bug 
reports a la "this can't be done because this static constructor 
is in the same module as this independently useful artifact"? Or 
whatever the matter is. Then each issue can be looked at and 
decided upon properly. Thanks. -- Andrei

[Issue 16355] __xpostblit incorrectly generated for a struct with a zero-length static array

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6400

--

Re: Vision document for H1 2017

[Arun Chandrasekaran via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 21:21:17 UTC, aberba wrote:


I like the social media part. More people, more man power, more 
noise about D.


I would read it as, with better signal-to-noise ratio.

Re: Question on std.experimental

[Robert burner Schadek via Digitalmars-d]

On Wednesday, 4 January 2017 at 19:33:13 UTC, Jack Stouffer wrote:
Promotion of std.logger has been officially stalled until 
reference counted strings are part of D.


When? That is the first I hear about that.

Re: [OT] static foreach

[Timon Gehr via Digitalmars-d]

On 04.01.2017 17:03, Stefan Koch wrote:

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:


[1] Both static if and static foreach (once it lands) need the same
kind of scoping rules.


Please do contact me if you are working on static foreach,


Not currently. I might implement it in 
https://github.com/tgehr/d-compiler soon though. I'll let you know.



there are dmd and implementation specific issues to be taken into account.


What kind of issues? The compiler implementation shouldn't matter for 
the definition of the static foreach behaviour.


Generation of the sequence of values assigned to the loop variables 
should be exactly like runtime foreach, scoping of the loop variables 
should be local. For scoping of the declarations within the static 
foreach body, there are multiple possibilities. (The most obvious thing 
is to just insert them into the outer scope, but then we need some other 
improvements in order to avoid having to string mixin each and every 
declaration in the body.)


There are some questions about which dependency structures should be 
allowed for the loop aggregate and the declarations in the loop body, 
but I think this is mostly orthogonal to static foreach itself.

Re: Vision document for H1 2017

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

On Wed, Jan 04, 2017 at 08:45:09PM +, Stefan Koch via 
Digitalmars-d-announce wrote:
[...]
> I claim dips on templates. (as in the colloquial english for asserting
> rights/ownership )
[...]

FYI, it's spelt "dibs" (with a 'b'). ;-)


T

-- 
It won't be covered in the book. The source code has to be useful for 
something, after all. -- Larry Wall

Re: What are you planning, D related, for 2017 ?

[Misu via Digitalmars-d]

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
Write your plan here, and let's take a rendez-vous next year, 
to check those plans !!


I want to release my MMO game on Steam this year !

Whats missing :

- Basic AI and Fights

[Issue 16694] ICE on taking address of `export` function (declaration-only)

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by PR https://github.com/dlang/dmd/pull/6259

--

Re: Vision document for H1 2017

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


I claim dips on templates. (as in the colloquial english for 
asserting rights/ownership )

I can't wait to improve that situation.

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

--- Comment #4 from bitter.ta...@gmx.com ---
(In reply to Jacob Carlborg from comment #2)
> (In reply to bitter.taste from comment #1)
> > This should be only a matter of using the Loc of the Dsymbol we're currently
> > mangling when an error is thrown.
> 
> I'm pretty sure it's reporting the error as "Internal Compiler Error"
> because the error should have been caught earlier, properly reported with
> file and line number.

Nah, it's just that every error that's thrown from cppmangle.d is prefixed with
"Internal Compiler Error" and uses Loc() as loc instead of using the one of the
symbol it is trying to mangle.
No type checking is done in the mangler, it's just that there's no C++ type a D
`string' maps to, you could effectively prevent the use of types that have no
1:1 mapping to C++ ones but that's another matter, this approach just works
(TM).

--

[Issue 16048] std.getopt: duplicated options are not detected

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/43880932f56f412eb5c3e4fcc395c507c1aa93ad
Throw error on duplicate long/short options

Fixes Issue 16048

--

Re: Parsing a UTF-16LE file line by line, BUG?

[Daniel Kozák via Digitalmars-d-learn]

Nestor via Digitalmars-d-learn  
napsal St, led 4, 2017 v 8∶20 :

On Wednesday, 4 January 2017 at 18:48:59 UTC, Daniel Kozák wrote:
Ok, I've done some testing and you are right byLine is broken, so 
please fill a bug


A bug? I was under the impression that this function was *intended* 
to work only with UTF-8 encoded files.


Impression is nice but there is nothing about it, so anyone who will 
read doc will expect it to work on any encoding.
And from doc I see there is a way how one can select encoding and even 
select Terminator and its type, and this does not works so I expect it 
is a bug.


Another wierd behaviour is when you read file as wstring it will try to 
decode it as utf8, then encode it to utf16, but even if it works (for 
utf8 files), and you end up with wstring lines (wstring[]) and you try 
to save it, it will automaticly save it as utf8. WTF this is really 
wrong and if it is intended it should be documentet better. Right now 
it is really hard to work with dlang stdio.


But I hoppe it will be deprecated someday and replace with something 
what support ranges and async io

Re: Parsing a UTF-16LE file line by line, BUG?

[pineapple via Digitalmars-d-learn]

On Wednesday, 4 January 2017 at 19:20:31 UTC, Nestor wrote:
On Wednesday, 4 January 2017 at 18:48:59 UTC, Daniel Kozák 
wrote:
Ok, I've done some testing and you are right byLine is broken, 
so please fill a bug


A bug? I was under the impression that this function was 
*intended* to work only with UTF-8 encoded files.


I'm not sure if this works quite as intended, but I was at least 
able to produce a UTF-16 decode error rather than a UTF-8 decode 
error by setting the file orientation before reading it.


import std.stdio;
import core.stdc.wchar_ : fwide;
void main(){
auto file = File("UTF-16LE encoded file.txt");
fwide(file.getFP(), 1);
foreach(line; file.byLine){
writeln(file.readln);
}
}

Re: Vision document for H1 2017

[Joakim via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu 
wrote:
We release a brief Vision document summarizing the main goals 
we plan to pursue in the coming six months. This half we are 
focusing on three things: safety, lifetime management, and 
static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


Nice, a list of concrete tasks, well done.

Only one criticism, some are too short: took me a bit to 
understand what "High-level shared library wrapper" meant, a 
better way to create and deal with shared libraries?  If so, only 
reason I got that is because of your recent forum posts asking 
about loading shared libraries.  Not sure what you want 
overhauled about the dub registry either, might want to expand on 
those, so someone interested could pick up on them.

Re: Question on std.experimental

[Jack Stouffer via Digitalmars-d]

On Wednesday, 4 January 2017 at 07:32:34 UTC, Adam Wilson wrote:
What are the exit conditions for graduating from 
std.experimental.* to std.*?


Has anything graduated yet?


Promotion of std.logger has been officially stalled until 
reference counted strings are part of D. I think this was done 
because the current code uses the GC a lot; not sure.


RC strings were being pushed heavily by Walter and Andrei until 
it was realized that in order for it to be @safe, there had to be 
a lot of holes in @safe plugged and new additions to the compiler.


Walter is still periodically working on @safe, but I'd say RC 
strings landing in master is two years away minimum.

Re: Parsing a UTF-16LE file line by line, BUG?

[Nestor via Digitalmars-d-learn]

On Wednesday, 4 January 2017 at 18:48:59 UTC, Daniel Kozák wrote:
Ok, I've done some testing and you are right byLine is broken, 
so please fill a bug


A bug? I was under the impression that this function was 
*intended* to work only with UTF-8 encoded files.

Vision document for H1 2017

[Andrei Alexandrescu via Digitalmars-d-announce]

We release a brief Vision document summarizing the main goals we plan to 
pursue in the coming six months. This half we are focusing on three 
things: safety, lifetime management, and static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei

Re: Terminix Year In Review

[Gerald via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 04:08:00 UTC, Adam D. Ruppe wrote:

On Monday, 2 January 2017 at 21:11:47 UTC, Getald wrote:
I'm not sure a textview would be viable, it might work for the 
command prompt but I doubt it would handle ncurses type 
applications like vi or nano very well.


I don't know GTK at all, but my terminal thing's frontend just 
needs keyboard and mouse input events and a canvas to draw onto 
(including text string drawing functions).


So I'm guessing the TextView is actually overfeatured for what 
I'd want.


Yep, that would be my expectation. I suspect you would just 
inherit from GtkWidget and go from there.

Re: Does anyone know of an sdl-mode for Emacs?

[Russel Winder via Digitalmars-d-learn]

On Wed, 2017-01-04 at 17:24 +, Atila Neves via Digitalmars-d-learn
wrote:
> It's getting tedious editing dub.sdl files with no editor 
> support. If nobody's written one, I will.
> 

Emacs has an sdlang-mode. It's on MELPA so installable via packages.

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

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

Re: Parsing a UTF-16LE file line by line?

[Daniel Kozák via Digitalmars-d-learn]

Daniel Kozák  napsal St, led 4, 2017 v 6∶33 :


Nestor via Digitalmars-d-learn  
napsal St, led 4, 2017 v 12∶03 :

Hi,

I was just trying to parse a UTF-16LE file using byLine, but 
apparently this function doesn't work with anything other than 
UTF-8, because I get this error:


"Invalid UTF-8 sequence (at index 1)"

How can I achieve what I want, without loading the entire file into 
memory?


Thanks in advance.
can you show your code, byLine should works ok, and post some example 
of utf16-le file which does not works


Ok, I've done some testing and you are right byLine is broken, so 
please fill a bug

Re: What are you planning, D related, for 2017 ?

[solidstate1991 via Digitalmars-d]

On Monday, 2 January 2017 at 15:16:31 UTC, Basile B. wrote:
Write your plan here, and let's take a rendez-vous next year, 
to check those plans !!


Main plans:
 - Finish the 0.9.1 version of my graphics engine. I have to 
finish the new collision detection algorithm that uses a bitarray 
instead of testing for transparency, also I will rearrange 
certain stuff for better readability. (also I'll finally make use 
of git to compile the main library and the editor)
 - Use said engine as my thesis if I can find a consultant in 
time (if not I'll do something else)

 - Finish the editor
 - Make use of the parallelism for rendering
 - Make a game in it (either a Touhou fan game or a game 
featuring our mascot, Dlangman)


Other plans:
 - Try to implement a custom shader that would do the fixed-point 
rendering on the GPU via alpha-blending onto a texture and taking 
care of the CLUT (currently done by the CPU via SSE2 and the 
in-line assembler)
 - Either implement a pre-existing language for AI and scripting 
(eg. Lisp) or write a new one based on D. Current plan for the 
latter is an ECMAScript and Prolog influenced language for 
general-purpose and AI programming, which either can be run from 
the source code or from a byte-code. This could be used in other 
projects too.

Re: Parsing a UTF-16LE file line by line?

[Daniel Kozák via Digitalmars-d-learn]

Nestor via Digitalmars-d-learn  
napsal St, led 4, 2017 v 12∶03 :

Hi,

I was just trying to parse a UTF-16LE file using byLine, but 
apparently this function doesn't work with anything other than UTF-8, 
because I get this error:


"Invalid UTF-8 sequence (at index 1)"

How can I achieve what I want, without loading the entire file into 
memory?


Thanks in advance.
can you show your code, byLine should works ok, and post some example 
of utf16-le file which does not works

Re: Crazy, sad but ... would you use D for your own facebook or pinterest?

[Jacob Carlborg via Digitalmars-d]

On 2017-01-04 15:04, Adam D. Ruppe wrote:


wc reports about 80,000 lines. But it isn't line count that affects
build speed in D: it is the content of those lines.


Yeah, for projects like DWT and Tango where very few compile time 
features are used it's really quick to compile. DWT takes around 6 
seconds for me to compile, just below 200 000 lines.


--
/Jacob Carlborg

Does anyone know of an sdl-mode for Emacs?

[Atila Neves via Digitalmars-d-learn]

It's getting tedious editing dub.sdl files with no editor 
support. If nobody's written one, I will.


Atila

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
The mangler shouldn't do the type checking.

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #2 from Jacob Carlborg  ---
(In reply to bitter.taste from comment #1)
> This should be only a matter of using the Loc of the Dsymbol we're currently
> mangling when an error is thrown.

I'm pretty sure it's reporting the error as "Internal Compiler Error" because
the error should have been caught earlier, properly reported with file and line
number.

--

Quick and dirty support for RISC-V

[e-y-e via Digitalmars-d]

In a previous post a few days ago, I asked what the easiest way 
of getting D code running on RISC-V would be. I thought the 
process might take quite a while and more knowledge of compilers, 
hardware etc than I currently have.


But technically, D code can now be run on RISC-V. Sort of.

I followed Nicholas Wilson's direction to get the RISC-V 
toolchain and LLVM built and working. This was the hardest part 
for me, about 5 seperate riscv-* items needed to be compiled/run 
correctly in order to build and run a simple helloworld.c program 
in an ISA simulator. This toolchain was used to build LDC (using 
the cmake flag -DLLVM_CONFIG=/bin/llvm-config).


To start off, druntime wouldn't build because it had no idea 
about RISC-V yet, but it wasn't a problem as runtime-less D is 
probably par for the course on the eventual architecture. 'make 
ldc2' worked fine so that was that.


I have no experience with compilers, so I had no clue where to 
begin in order to get helloworld.d running. Then I remembered 
Adam D Ruppe's opening advice from dconf 2014 talk, and decided 
to just try it and see if it works. Naturally the first time it 
didn't, but by silencing the very short trail of compile errors, 
and playing around with the build method & command arguments a 
little, I eventually got it to work! Mainly due to LLVM being an 
amazing piece of software but that's for another time.


Obviously this approach has a few drawbacks, but I can run D on a 
RISC-V ISA, which was my goal.


Drawbacks:

- Only tested on one toolchain built for one ISA (RV32IMAC)
- Must be betterC code, and also no correct consideration for 
OS-dependent items (such as errno)
- The process of compiling something is a little overwhelming, 
and undocumented for now

- The repo doesn't really follow a proper workflow
- And probably many more, very little is tested!

This was not meant to be a project for anyone other than myself, 
I just wanted to get something working. But now that it is, I 
will start the process of documenting how to compile things, 
migrating the source from gitlab to github and anything else that 
needs to be done.


For now though, these are the commands I used:

To build compiler:

git clone --recurse-submodules 
https://github.com/e-y-e/riscv-ldc.git

cd riscv-ldc
mkdir build && cd build
cmake .. -DLLVM_CONFIG=/bin/llvm-config
make -jN ldc2

To compile:

/build/bin/ldc2 -march=riscv -betterC 
-defaultlib= -output-ll helloworld.d

/bin/llc helloworld.ll
/bin/riscv32-unknown-elf-gcc -o helloworld 
helloworld.s


To run using riscv-isa-simulator:

/bin/spike --isa=RV32IMAC 
/riscv32-unknown-elf/bin/pk helloworld


Process requires:
https://github.com/riscv/riscv-gnu-toolchain
https://github.com/riscv/riscv-llvm
https://github.com/riscv/riscv-pk
https://github.com/riscv/riscv-fesvr
https://github.com/riscv/riscv-spike

Work is up at the following links so you can see how little 
modification was required:


- LDC: https://gitlab.com/e-y-e/riscv-ldc
- DRuntime: https://gitlab.com/e-y-e/riscv-druntime
- Phobos: https://gitlab.com/e-y-e/riscv-phobos

---

TL;DR: Got D running on RV32IMAC ISA Simulator with minimal 
modification. Wanted to share because it made me happy that it 
worked.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[deadalnix via Digitalmars-d]

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:
I don't fully agree. Nested imports, the way they have been 
implemented, pose a new symbol hijacking hazard.




I'd argue this was an existing bug in import handling. This is 
why I like to have very orthogonal definitions.


It adds basically no implementation complexity [1]. I consider 
the benefit real, but minor enough to oppose the DIP based on 
its wacky syntax.


[1] Both static if and static foreach (once it lands) need the 
same kind of scoping rules.


I know about [1], this is why I did not mentioned it. I don't 
really mind about implementation complexity, I care about 
complexity of the definition. For the following reasons:
 - If the implementation may be complex, it can be isolated 
and/or abstracted away.
 - Interaction with other parts of the language are more 
predictable, including future parts that do not exists yet.
 - It obviate the explosion of trivia experienced devs needs to 
know to use the language.

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
pull: https://github.com/dlang/phobos/pull/5013

--

Re: [OT] static foreach

[deadalnix via Digitalmars-d]

On Wednesday, 4 January 2017 at 16:03:29 UTC, Stefan Koch wrote:

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:

[1] Both static if and static foreach (once it lands) need the 
same kind of scoping rules.


Please do contact me if you are working on static foreach, 
there are dmd and implementation specific issues to be taken 
into account.


I think the best path forward is to define them properly.

Re: CTFE casts of delegates

[Stefan Koch via Digitalmars-d]

On Wednesday, 4 January 2017 at 16:19:52 UTC, Seb wrote:

There is assumeWontThrow 
(https://dlang.org/phobos/std_exception.html#.assumeWontThrow) 
in std.exception, so I think the chances for assumeNogc or 
assumePure aren't that bad ;-)


I understand that it did not work at ctfe.

Re: CTFE casts of delegates

[Seb via Digitalmars-d]

On Wednesday, 4 January 2017 at 16:06:11 UTC, Stefan Koch wrote:

On Wednesday, 4 January 2017 at 08:45:59 UTC, Eyal Lotem wrote:

On Tuesday, 3 January 2017 at 09:44:38 UTC, Stefan Koch wrote:

I think that I can provide a dmd patch that would allow the 
casts you want at ctfe.

However I would not propose it for inclusion myself.


A cast that only fiddles with function attributes like @nogc 
should be perfectly safe, shouldn't it?


Honestly I am not sure about it.
I guess I could enable this back-door for you and others.



This back-door already exists, see e.g.:

https://github.com/nordlow/phobos-next/blob/master/src/dbgio.d#L13

and

http://forum.dlang.org/post/nq4eol$2h34$1...@digitalmars.com

Patch will follow in the next days, I am not sure if it will be 
merged though.


There is assumeWontThrow 
(https://dlang.org/phobos/std_exception.html#.assumeWontThrow) in 
std.exception, so I think the chances for assumeNogc or 
assumePure aren't that bad ;-)

Re: CTFE casts of delegates

[Stefan Koch via Digitalmars-d]

On Wednesday, 4 January 2017 at 08:45:59 UTC, Eyal Lotem wrote:

On Tuesday, 3 January 2017 at 09:44:38 UTC, Stefan Koch wrote:

I think that I can provide a dmd patch that would allow the 
casts you want at ctfe.

However I would not propose it for inclusion myself.


A cast that only fiddles with function attributes like @nogc 
should be perfectly safe, shouldn't it?


Honestly I am not sure about it.
I guess I could enable this back-door for you and others.
Patch will follow in the next days, I am not sure if it will be 
merged though.

[OT] static foreach

[Stefan Koch via Digitalmars-d]

On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:

[1] Both static if and static foreach (once it lands) need the 
same kind of scoping rules.


Please do contact me if you are working on static foreach, there 
are dmd and implementation specific issues to be taken into 
account.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Timon Gehr via Digitalmars-d]

On 04.01.2017 16:00, deadalnix wrote:


Nested import are a language simplification. Declaration can appear
anywhere, import is a declaration, the fact that import couldn't appear
anywhere was an arbitrary limitation, and removing it makes the language
simpler. As such, the burden of proof is on maintaining the limitation
rather than removing it.
...


I don't fully agree. Nested imports, the way they have been implemented, 
pose a new symbol hijacking hazard.


(A symbol hijacking anecdote (not directly related): 
https://github.com/tgehr/d-compiler/pull/1#discussion-diff-89697186L85 )



This DIP is a language addition. Therefore, contrary to nested or lazy
import, the burden of proof is on it. This DIP should be considered as
follow: how much complexity does it add and how much benefit does it
bring, compared to alternatives.


It adds basically no implementation complexity [1]. I consider the 
benefit real, but minor enough to oppose the DIP based on its wacky syntax.



[1] Both static if and static foreach (once it lands) need the same kind 
of scoping rules.

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

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

--- Comment #2 from Ketmar Dark  ---
this was just a place to keep the temporary solution anyway. Steven took care
of that since, i believe. sorry, i forgot to close this myself.

and yes, i know that patches in bugzilla rots forever without any movement (and
patches published in NG are lost at the moment they put there ;-), but i am not
using github, so this is the only way i can contribute. alas.

--

Re: It is still not possible to use D on debian/ubuntu

[deadalnix via Digitalmars-d]

On Tuesday, 3 January 2017 at 00:16:52 UTC, Martin Nowak wrote:

On Monday, 2 January 2017 at 18:18:33 UTC, deadalnix wrote:
Plus the fix was actually released yesterday, so it's not like 
I'm lagging by much. The internal meddling nonsense that's 
going on is none of any user business.


Bug reports are dealt with on Bugzilla, shouldn't be surprising.
It's also fairly reasonable to ask you to search the Forum and 
Bugzilla for your topic and progress on that before posting a 
rant.


I understand this is frustrating to see users complain about 
something when it looks like it's been fixes ages ago when you 
are the nose into it.


But please understand that as far as D goes, if someone like me 
is not aware of something, it is fair to assume 99% of the 
populace isn't either.


This kind of thing as real effect in the real world. In past Nov, 
I saw 2 professional user drop D because of this kind of 
problems. These users don't complains and just move on to 
something else.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[deadalnix via Digitalmars-d]

There are quite a few fallacies in there.

On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu 
wrote:
Regarding the ongoing doubts about the advantages of inline 
imports: they are first and foremost a completion of the nested 
import feature. As such, most, if not all, arguments against 
inline imports apply equally to nested imports. Come to think 
of it, lazy imports vs nested imports:


* same improvement in compilation speed? check
* no language changes? check
* no nasty bugs in the aftermath (such as the infamous 
https://issues.dlang.org/show_bug.cgi?id=10378)? check

* scalable builds? check

Yet local imports are overwhelmingly superior to lazy imports 
because of one thing: they localize dependencies. They 
introduce modularity and its ancillary perks (fast and scalable 
builds, easier review and refactoring) not by engineering, but 
by organically placing dependencies spatially with their 
dependents. (The scope statement does the same thing with 
temporal dependencies.) That the DIP does not make it clear 
that it is a necessary and sufficient extension of local 
imports is a problem with it.




There is a major difference with this DIP.

Lazy import is not a language change, but a compiler 
implementation detail. As such, it doesn't require a DIP or 
anything specific.


Nested import are a language simplification. Declaration can 
appear anywhere, import is a declaration, the fact that import 
couldn't appear anywhere was an arbitrary limitation, and 
removing it makes the language simpler. As such, the burden of 
proof is on maintaining the limitation rather than removing it.


This DIP is a language addition. Therefore, contrary to nested or 
lazy import, the burden of proof is on it. This DIP should be 
considered as follow: how much complexity does it add and how 
much benefit does it bring, compared to alternatives.


The obvious benefit is localizing dependencies. I think I'm not 
too far off track by considering most of the speedup and scalable 
build can be achieved with lazy import and, while I'm sure there 
are example where this is superior, we are talking marginal gains 
as lazy and nested imports squeezed most of the juice already.


The cost is the language addition. The first obvious improvement 
that can be made to this DIP to reduce its cost is to not 
introduce a new syntax. As such, the addition is limited to 
allowing the existing syntax in a new place rather than adding a 
whole new syntax for imports.


I like the extra expressivity. I'm not 100% convinced it is worth 
the extra cost, but the more the cost is reduced, the more 
rational it seems to me that this option should be pursued.


I now am really glad we slipped local imports before the 
formalization of DIPs. The feature could have been easily 
demeaned out of existence.




Good you also notice how broken the DIP process is.

One suggestion: let's keep the DIP describing the change to be 
made. Some examples are fine to illustrate, but it is not the 
DIp's purpose to be easy to understand or expand too much in 
argumentation, or it'll be useless as a spec document, and trying 
to have the DIP be a spec, a tutorial, a essay on why the 
feature, and so on just lead to endless rewriting lead to 
perpetual motion but no progress.

[Issue 17036] Template default parametr does not works correctly

[via Digitalmars-d-bugs]

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

--- Comment #2 from Daniel Kozak  ---
yeah I am aware of all of this, but in all other cases(context) it is legal to
do this cast. It is even legal by language specification if I remember it
correctly.

I would fix it by myself but thera are many ways to fix this and i am not sure
which way is the best, so I hope someone with more skill try to fix it or
propose some solution or direction

--

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from greenify  ---
> for the time being, until the proper fix for cycle detection in module ctors 
> isn't complete.

AFAIK the cycle detection has been fixed
(https://github.com/dlang/druntime/pull/1602), so I think this makes this issue
obsolete (please reopen if you disagree)
As you might have realized your patch got quite stalled here, so in the future
either submitting a PR or posting it to the mailing list could lead to more
success ;-)

--

[Issue 16510] Request: RSA digital signature validation in phobos

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
There are a couple of DUB libraries that do implement RSA, e.g the botan
library: https://github.com/etcimon/botan

However it still would be nice to have it in std.digest

--

Re: Question on std.experimental

[Seb via Digitalmars-d]

On Wednesday, 4 January 2017 at 07:32:34 UTC, Adam Wilson wrote:
What are the exit conditions for graduating from 
std.experimental.* to std.*?


I think it should have been accepted by the community and there 
shouldn't be any design concern or usability issues.
However, this is a chicken-and-egg problem as most people don't 
want to use `experimental` thoroughly in production software.
Furthermore the exact criteria aren't defined which lead to the 
weird state that `std.experimental.allocator` is considered 
stable by most of the community.


The real issue is that moving from `experimental` to Phobos means 
that the API effectively can't be changed anymore due to aversion 
against deprecations and imho it's quite difficult to guarantee 
that an API is superb.



Has anything graduated yet?


1) allocator


You may want to see this discussion:

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

2) logger
--

I think sth. like the capability to do async logging is needed.

[1] https://github.com/dlang/phobos/pull/3194


3) typecons


Both `Wrap` and `Final` were added as part of 2.072.


ndslice is deprecated https://github.com/dlang/phobos/pull/4946
It is hard to maintain both Phobos and Mir forks.


Yep, I fully agree with Ilya here. Whenever there's a change in 
Mir, it will be released almost instantly with a new version. 
This means that thanks to DUB a user can easily upgrade to check 
out the greatest & latest, but also stay on a stable version if 
he wishes so.
With Phobos one is usually tied to the bundled Phobos version of 
one's DMD compiler release.
You may also see Ilya's proposal for a more modular standard 
library:


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

Re: Crazy, sad but ... would you use D for your own facebook or pinterest?

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 4 January 2017 at 07:08:25 UTC, aberba wrote:
Did you implement some form of clustering (session, storage, 
caching)?


I cheated (well, some would say "made a reasonable decision not 
to reinvent the wheel"): I ran two copies of the application and 
both talked to the same database (which itself has a replication 
feature for failover, so any one server could go down at a time 
without breaking things, but two down at once would most likely 
have been a problem). Session storage was done as a special case 
of database setup.


The application itself didn't know and didn't need to know about 
the server setup. We never hit a point where this was 
problematic. If it took off to millions of users, perhaps things 
would need to change, but it worked fine with our actual scale 
(we made a modest profit for the years it stayed up, so I don't 
consider it a failure per se, but as I said, the company 
eventually pivoted).

Re: Crazy, sad but ... would you use D for your own facebook or pinterest?

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 4 January 2017 at 12:44:08 UTC, Andrei Alexandrescu 
wrote:

How large was the codebase? Thx! -- Andrei


wc reports about 80,000 lines. But it isn't line count that 
affects build speed in D: it is the content of those lines.


When I optimized it, the source code actually got *bigger*, but I 
simplified templates and moved some stuff to runtime functions 
which build much, much faster than complicated template+CTFE 
instantiations.


See, the program used a lot of code generation so I'd just add a 
function to the class and all the web API and most the HTML 
components would be auto-generated from the function signature. 
By the time the D program was up to 10,000 lines, we already had 
more relevant functionality than the 100,000 line PHP program we 
were migrating away from, mostly thanks to the more efficient 
abstractions and generating boilerplate automatically. (Though, 
granted, the php did some stuff we didn't care about too, the 
feature sets were mostly comparable.)


However, adding a one line function to the source could result in 
a dozen templates being instantiated, which slows compile and 
makes for some huge binaries. When I changed it, it would do some 
metadata generation in the template, then pass off to as many 
reused instantiations as possible (so instead of 
generateFunction!foo doing everything, it would forward to 
generateFunctionArgumentCode!(ParameterType!foo) (well, we didn't 
have ParameterType back then, std.traits wasn't even around IIRC 
until after like 2012 and I did the bulk of this in 2010, but my 
homemade code did the same thing). Then, the compiler can reuse 
the same thing for common types like int and string. Also, these 
would generate data tables that a runtime function could load 
instead of *being* the whole function, cutting the generated code 
down significantly.)


Actually, I started all templated, then moved to a hybrid 
template + TypeInfo-like setup for various reasons... something 
to keep in mind as we talk about heavily templating druntime...


(The performance difference at runtime was negligible, though I 
didn't dive into it much, since the performance of most the code 
was never under pressure; when things got slow, it was because of 
a few specific functions. My CSS thing was slow, so I cached it, 
problem solved. A few database queries were slow, so I fixed the 
SQL, problem solved. The gains from fixing those 10-line hotspots 
were always the major fixes we needed.)

Re: Question on std.experimental

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 4 January 2017 at 10:02:34 UTC, Adam Wilson wrote:

On 1/3/17 11:55 PM, Ilya Yaroshenko wrote:
On Wednesday, 4 January 2017 at 07:32:34 UTC, Adam Wilson 
wrote:



Has anything graduated yet?


No


So at what point well we? I mean that is the point after all...


ndslice is deprecated https://github.com/dlang/phobos/pull/4946
It is hard to maintain both Phobos and Mir forks.

Allocators are useful but they are not betterC. I will fork them 
anyway if I will need to use them for production.

Re: ARC in D

[Nordlöw via Digitalmars-d]

On Monday, 2 January 2017 at 15:43:22 UTC, eugene wrote:

hello everyone,
is there any kind of smart pointers or something in D instead 
of GC?


Non-atomic RC wrapper type is here

http://dlang.org/phobos/std_typecons.html#.RefCounted

and instantiator for it here

http://dlang.org/phobos/std_typecons.html#.refCounted

It can be combined with containers such as the ones in

https://github.com/economicmodeling/containers

Note that these containers have their copy constructors disabled 
to prevent implicit (C++ style) copying.


Andrei probably knows more about _atomic_ RC.

[Issue 17036] Template default parametr does not works correctly

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
---
struct S0
{
void x[1];
}
pragma(msg, S0.init);
---

As you can see this outputs `S0([cast(ubyte)0u]`, let's assume that the
compiler is right and try using that value as initializer

---
auto x = S0([cast(ubyte)0u]; // and I thought you couldn't cast a ubyte into a
void
---

gives a fairly explicative error, which is what one would rightfully expect

---
cannot implicitly convert expression ([cast(ubyte)0u]) of type ubyte[] to
void[1]
---

on the other hand using the `.init` directly works perfectly..isn't that weird
?

---
auto x = S0.init; // works
---

Let's take a step back, where's the initializer coming from? Here it is [1],
you sneaky bastard! So what happens here is that a zero-initialized TypeSArray
is created with a void[1] type bolted on, the trick falls short when the struct
initializer (the aforementioned `S0([cast(ubyte)0u]` that now has a S0(void[1])
type) is run trough dtemplate `matchArg` and trough the CTFE engine where
nothing is done beside losing our bolted-on type.
What happens next is where the error originates, the new initializer gets
trough the semantic phase

---
ArrayLiteralExp::semantic('[cast(ubyte)0u]')
---

if you're familiar with the inner workings I'll also add that `type` is null
right now and the deduced type is `ubyte[]` which is the technically right
answer but the wrong one in this context. ugh.

Here's where the shit hits the fan

---
ArrayLiteralExp::implicitConvTo(this=[cast(ubyte)0u], type=ubyte[], t=void[1])
TypeDArray::implicitConvTo(to = void[1]) this = ubyte[]
---

What to do? One could try not to lose the hacked-up type of the array, relax
the rules for casts to `void[N]`, emit a `void` initializer instead of a
zeroing the array (which is what one would expect since void has no default
initializer), hope for the best, use another lang^Hthat's it!

[1] https://github.com/dlang/dmd/blob/master/src/mtype.d#L5040

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
This should be only a matter of using the Loc of the Dsymbol we're currently
mangling when an error is thrown.

--

Re: Crazy, sad but ... would you use D for your own facebook or pinterest?

[Andrei Alexandrescu via Digitalmars-d]

On 1/3/17 11:10 PM, Adam D. Ruppe wrote:

My compile+link time at one point hit 15 seconds so I optimized some
templates and got it down to 7. Still kinda slow but not *that* bad.


How large was the codebase? Thx! -- Andrei

Re: PostgreSQL native impl

[Jacob Carlborg via Digitalmars-d-announce]

On 2017-01-04 12:26, Nemanja Boric wrote:


Shameless plug, I've been working in my spare time on a similar project:
https://github.com/Burgos/postgres-native

Progress is super slow, though, but I'm really happy how the things are
working out, so just publishing here if somebody wants to take the
inspiration from the API or any part of it, or if somebody wants to help
:-)


There's already a bunch of Postgres drivers here [1], some are native 
ones, some uses the C library. ddb [2] is, I believe, the oldest native 
driver at code.dlang.org. That's the one I've been using. Compatible 
with vibe.d as well.


[1] http://code.dlang.org
[2] http://code.dlang.org/packages/ddb

--
/Jacob Carlborg

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 3 January 2017 at 12:57:22 UTC, Andrei Alexandrescu 
wrote:

On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote:
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu 
wrote:
DIP1005 gives consideration to the speed of compilation 
aspect in
larger proportion than speed's importance; the first and 
foremost
benefit of DIP1005 is it closes the gap on dependency 
encapsulation,

which had been very successfully narrowed by local imports.
I love that idea. But I still can't see why this requires any 
new
syntax. Simply extending the scope of local inports to include 
the

function header is enough.


I'll mention this possibility in the DIP.

Good.


Only for .di-generation it may be useful to move all local 
imports to
the declaration (maybe with this new syntax "with" before it) 
- but that
should be done with ALL local imports, because today the 
.di-files are

incomplete and will stay so if the new syntax is introduced but
"old-style" local imports still valid and not exported to the 
.di.

Or the old local imports become deprecated together with the
introduction of the new "with" syntax and vanish soon after 
that.


Local imports don't pertain to the interface, they are an 
implementation detail. Why would those be made a part of the 
.di?
.di are needed to ship with a library. If a function locally 
imports some type, the library is dependant on that import, so if 
I want to use the library, I have to install all stuff it depends 
on too. And to find out, what exactly the library depends on the 
.di is the place I look, so there need to be mentioned each and 
every import - no matter how deeply local that may be. If that is 
not the case it renders .di-files completely useless to me (as 
they are at the moment), because I need to find out the 
dependencies somewhere else (e.g. in some documentation of the 
library).
While it is likely that the dependencies of a library may be 
documented somewhere, this is not guaranteed. But .di-files are 
guaranteed to ship with a lib because else it cannot link - at 
least if it contains any templates, which is about 100% sure for 
a language like D. So I would like to see local imports in the 
.di-file, even if they are not strictly needed to compile because 
the imported types are not exposed in the function signature.

Direction of D

[Joakim via Digitalmars-d]

On Tuesday, 3 January 2017 at 09:28:06 UTC, Paulo Pinto wrote:


Allow me just to share a worthless outsider opinion.

I never contributed anything worthwhile and decided it was 
better to just focus on JVM, .NET languages., alongside C++, as 
those are the skills I get paid for, thus stop polluting D 
forums.


Looking from the outside, and watching what was reached from 
2016 roadmap, it is clear the DIPs evaluated thus dar aren't 
about fixing the library or runtime issues that prevent D's 
adoption at large as a systems programming language.


Without listing what you think those real issues are, such a 
pronouncement is useless.


Meanwhile Swift, Go and Rust have a clear roadmap how their 
future is supposed to look like, and drive just in that 
direction, with C++ taking all remaining good D ideas.


Heading in the wrong direction at full speed ahead is worse than 
meandering along in no discernible direction, because worst case, 
you will likely be closer to the right direction after simply 
meandering.  In any case, you clearly think D headed in some good 
directions, or C++ would have nothing to copy. ;)


As for the other roadmaps, I see it for Rust and Swift

https://github.com/aturon/rfcs/blob/roadmap-2017/text/-roadmap-2017.md
https://github.com/apple/swift-evolution

but nothing for Go.  Do you mean these milestone lists with 
hundreds of PRs attached?


https://github.com/golang/go/milestones

Or is it somewhere else that google can't easily find it?  You 
could read the changelog for the dmd/phobos master branches and 
get the same result as that Go list.


Those languages are all backed by large tech companies and are 
driven by their company agendas.  As I've pointed out in this 
forum before, with some quotes from Linus 
(http://forum.dlang.org/post/dluoruxmwxnfjtyvm...@forum.dlang.org), directed development is good for niches, which is where all those languages are now (iOS, network services, Servo), but only general-purpose tech lasts in the medium- to long-term.


D may never gain the resources it needs to make it that long, but 
a community employing D in _no one direction_, as Linus says 
happened with linux, is more likely to make it general-purpose 
enough to survive.


This DIP discussion and the latest ones about splitting the 
runtime again, don't do anything to earn D any credibility it 
might still have left.


I kind of agree that both are not that worthwhile, but without 
stating your reasons for thinking the discussion _alone_ hurts 
D's credibility, which I mostly disagree with as such discussion 
is a core part of the distributed OSS process, that opinion is 
again useless.

Re: PostgreSQL native impl

[Nemanja Boric via Digitalmars-d-announce]

On Tuesday, 3 January 2017 at 09:07:35 UTC, Arun Chandrasekaran 
wrote:

On Tuesday, 3 January 2017 at 01:08:28 UTC, Chris Wright wrote:

On Mon, 02 Jan 2017 20:29:55 +, Anton wrote:

Today i spent about hour to write pure-D simple PostgreSQL 
driver for

demonstration purposes.
I was looking for developers interested in complete 
PostgreSQL driver

(pure D)

That demo not implements auth, therefore requires trusted user

[1] https://github.com/anton-dutov/postgresql-native-d [2] 
https://www.postgresql.org/docs/9.6/static/protocol.html


Nice!

Looks like it wouldn't be much work to add prepared queries.

I notice you rolled your own uri library. Might I point you 
toward urld? It supports ipv6 hosts (probably handy) and 
unicode domain names (nice to have, probably not useful here).


http://code.dlang.org/packages/urld


This is really neat! I've been looking for one such. I'm used 
to https://github.com/cpp-netlib/uri in C++.


Shameless plug, I've been working in my spare time on a similar 
project: https://github.com/Burgos/postgres-native


Progress is super slow, though, but I'm really happy how the 
things are working out, so just publishing here if somebody wants 
to take the inspiration from the API or any part of it, or if 
somebody wants to help :-)


I hope in 2017 I'll build a simple web project around it, which 
should help alot.